Considérations relatives à l'utilisation du cryptage déterministe

Options d'API pour l'identification des champs filtrables

Les champs cryptés en utilisant le schéma de cryptage déterministe peuvent être filtrés. Vous pouvez utiliser la méthode isFilterable() afin de déterminer le schéma de chiffrement d'un champ crypté particulier. Si le champ peut être filtré, la méthode renvoie true.

Cependant, vous ne pouvez pas détecter ou définir explicitement le schéma de cryptage déterministe via l'API.

Champs et autres données disponibles

Le cryptage déterministe est disponible pour les types de champ personnalisés URL, adresse e-mail, téléphone, texte et zone de texte. Elle n'est pas disponible pour d'autres types de données, notamment :

• Types de champ personnalisés date, date/heure, zone de texte longue, zone de texte enrichi ou description
• Chatter
• Fichiers et pièces jointes

Sensibilité à la casse

Lorsque vous utilisez le cryptage déterministe sensible à la casse, la casse est importante. Dans les rapports, les vues de liste et les requêtes SOQL dans les champs cryptés, les résultats sont sensibles à la casse. Ainsi, une requête SOQL sur un objet Contact, où LastName = 'Jones’, renvoie uniquement Jones, pas jones ou JONES. De la même façon, lorsque le schéma déterministe sensible à la casse teste l'unicité, chaque version de « Jones » est unique.

Chat

Le champ Énoncé de l'objet Suggestion d'énoncé prend en charge uniquement le cryptage déterministe insensible à la casse. L'interface utilisateur affiche le cryptage probabiliste sensible à la casse et le cryptage déterministe sensible à la casse, mais ces schémas ne sont pas opérationnels actuellement.

Le champ Nom de l'acteur de l'objet Entrée de la conversation prend en charge le cryptage déterministe sensible à la casse, mais pas le cryptage déterministe insensible à la casse.

Champs composés

Même avec le cryptage déterministe, certains types de recherche ne fonctionnent pas lorsque les données sont cryptées avec le cryptage déterministe sensible à la casse. Les valeurs concaténaténées, telles que les noms composés, ne correspondent pas à des valeurs séparées. Par exemple, le texte chiffré du nom composé « William Jones » est différent de la concaténation des textes chiffrés « William » et « Jones ».

Select Id from Contact Where Name = 'William Jones'

Select Id from Contact Where FirstName = 'William’ And LastName ='Jones' 
 

Les schémas de cryptage déterministes sensibles et insensibles à la casse prennent en charge les champs composés, mais uniquement avec les requêtes à colonne individuelle.

Conversion des enregistrements de compte et de contact en comptes personnels

Lorsque vous convertissez des enregistrements de compte et de contact en Comptes personnels, synchronisez vos données. La synchronisation réinitialise les index qui permettent le filtrage insensible à la casse.

Impossible de rechercher en utilisant l'outil Fusionner les comptes

Lorsque le champ Nom du compte ou Nom du contact est crypté avec le cryptage probabiliste ou déterministe, la recherche de comptes ou de contacts dupliqués à fusionner ne renvoie aucun résultat.

Allocations de champ personnalisé

Pour prendre en charge les requêtes insensibles à la casse, Salesforce stocke un double minuscule de vos données en tant que champ personnalisé dans la base de données. Ces doublons sont nécessaires pour les requêtes insensibles à la casse, mais ils sont pris en compte dans le nombre total de champs personnalisés. Par exemple, si vous avez 200 champs personnalisés dans votre organisation et que vous choisissez d'en crypter un avec le cryptage déterministe insensible à la casse, le total de vos champs personnalisés est de 201.

ID externe

Le cryptage déterministe insensible à la casse prend charge les champs personnalisés ID externe Texte et E-mail, mais pas les autres champs personnalisés ID externe. Lorsque vous créez ou modifiez ces champs, utilisez l'une des combinaisons de paramètres de champ recommandées.

Vous ne pouvez pas enregistrer en même temps les modifications apportées aux options Unique - Sensible à la casse et Crypté. Changez un paramètre, enregistrez-le, puis changez le suivant.

Opérateurs de filtrage

Dans les rapports et les vues de liste, les opérateurs « égal à » et « différent de » sont pris en charge avec le cryptage déterministe sensible à la casse. Les autres opérateurs, tels que « contient » ou « commence par », ne renvoient pas de correspondance exacte et ne sont pas pris en charge. Les fonctionnalités qui s'appuient sur des opérateurs non pris en charge, telles que les filtres Affiner par, ne sont pas prises en charge non plus.

Le cryptage déterministe insensible à la casse prend en charge les vues de liste et les rapports. Cependant, l'interface utilisateur affiche tous les opérateurs, y compris ceux qui ne sont pas pris en charge pour les données cryptées. Pour consulter la liste des opérateurs pris en charge disponibles dans Salesforce Classic, consultez Utilisation de données cryptées dans des formules.

Filtrage des enregistrements par chaînes

Vous pouvez rechercher des enregistrements en utilisant des chaînes. Cependant, dans les chaînes les virgules agissent en tant qu'instructions OR. Si votre chaîne inclut une virgule, placez votre chaîne entre guillemets. Par exemple, une recherche de “Universal Containers, Inc, Berlin” renvoie les enregistrements qui contiennent la chaîne complète, virgule incluse. Les recherches de Universal Containers, Inc, Berlin renvoient les enregistrements qui incluent « Universal Containers » ou « Inc » ou « Berlin ».

Formules

Les champs cryptés avec le schéma de cryptage probabiliste ne peuvent pas être référencés dans des requêtes SOQL WHERE. Cependant, vous pouvez utiliser des requêtes SOQL WHERE avec des champs non-formule cryptés avec le schéma de cryptage déterministe. Nom est un exemple de champ sans formule.

Index

Important

Lorsque votre schéma de cryptage inclut des champs de cryptage utilisés dans des index, utilisez le cryptage déterministe pour ces champs.

Si vous choisissez de crypter des champs qui font partie d'un index ou qui ont des exigences d'unicité, cela a des conséquences importantes. Lisez attentivement cette section pour comprendre les problèmes.

Le cryptage déterministe sensible à la casse et insensible à la casse est pris en charge.

• Le cryptage déterministe sensible à la casse prend en charge les index à une colonne, les index uniques sensibles à la casse à une colonne, les index à deux colonnes et les index personnalisés dans les champs standard et personnalisés.
• Le cryptage déterministe insensible à la casse offre une prise en charge limitée pour les index standard dans les champs standard ci-dessous.
  • Contact - E-mail
  • E-mail - Relation
  • Piste - E-mail
  • Nom

Prenez connaissance des considérations relatives aux performances ci-dessous avant de crypter des champs d'index.

• Mauvaises performances de requête : Les requêtes sur des champs cryptés avec le cryptage déterministe insensible à la casse peuvent être peu performantes avec des tableaux volumineux. Pour optimiser les performances des requêtes, utilisez des index personnalisés au lieu d'index standard. Pour définir des index personnalisés, contactez le Support client de Salesforce.
• Filtrage des champs de référence : Les champs de référence qui référencent le champ Nom s'appuient également sur des index. Pour filtrer sur le champ Nom dans les vues de liste et les rapports, filtrez par le champ Nom standard au lieu d'un champ de référence.
• Processus d'activation long : Le processus d'activation est plus long lorsque vous allez appliquer le cryptage déterministe à un champ contenant de nombreux enregistrements. Le processus d'activation reconstruit également les index de champ.

Suivez ces meilleures pratiques si vous choisissez de crypter les champs d'index.

• Garantissez un cryptage cohérent : Lors de l'utilisation du cryptage déterministe dans des champs indexés ou qui ont des exigences d'unicité, assurez-vous que toutes les valeurs sont cryptées avec la même clé déterministe. Cela garantit une identification fiable des doublons entre les enregistrements.
• Effectuer la synchronisation du cryptage : Nous recommandons d'effectuer une Synchronisation du cryptage peu de temps après avoir apporté des modifications susceptibles d'affecter l'unicité des index, par exemple changer le schéma de cryptage ou permuter le secret locataire Cryptage déterministe.
• Planifier les temps d'arrêt : Planifiez ces modifications pendant les heures creuses afin de limiter les interruptions. La synchronisation du cryptage est exécutée par lots et peut prendre plus ou moins de temps selon la structure de l'entité, le volume d'enregistrements et les champs impliqués. Avec notre équipe de support, planifiez les temps d'arrêt nécessaires.

Rotation des clés et disponibilités des filtres

L'ajout, le retrait ou la modification d'un schéma de cryptage déterministe reconstruit vos index. L'activité des utilisateurs dans les champs cryptés entraîne des données dupliquées dans les index, ce qui peut interférer avec les opérations de synchronisation. Après avoir permuté le matériel de clé déterministe ou changé le schéma de cryptage d'un champ en cryptage déterministe sensible à la casse ou en cryptage déterministe insensible à la casse, synchronisez vos données avec votre clé active dès que possible. La synchronisation applique le matériel de clé actif aux données existantes et nouvelles. Si vous ne synchronisez pas vos données, le filtrage et les requêtes sur les champs qui contiennent des attributs uniques ne renvoient pas de résultats précis.

Vous pouvez synchroniser vous-même des données dans des champs standard et personnalisés dans la page Statistiques de cryptage et Data Sync, dans Configuration. Pour synchroniser toutes les autres données ou des volumes de données importants, contactez le Support client de Salesforce. Pour plus d'informations sur la synchronisation des données, consultez Synchronisation de votre cryptage des données avec le service de cryptage en arrière-plan.

Next Best Action Recommendations

Avec le cryptage déterministe, vous pouvez utiliser des champs cryptés dans des conditions de chargement uniquement avec l'opérateur égal à ou différent de.

Retrait du cryptage déterministe des champs

Si vous retirez le cryptage d'un champ crypté avec le cryptage déterministe, Shield Platform Encryption nécessite un certain temps pour décrypter ce champ dans toute votre organisation. La taille de votre organisation détermine la durée de ce processus. Par conséquent, le champ ne présente pas les caractéristiques de filtrage et de tri d'un champ non crypté tant que cette mise à jour n'est pas terminée.

Instructions SOQL GROUP BY

Assemblez les clauses where conformément aux règles dans Les opérateurs de comparaison.

Le cryptage déterministe ne prend pas en charge la clause GROUP BY. Si vous spécifiez GROUP BY en utilisant un champ déterministe, vos regroupements ne seront pas précis ni cohérents.

Instructions SOQL LIKE et STARTS WITH

Le cryptage déterministe prend en charge uniquement les correspondances exactes, sensibles à la casse. Les opérateurs de comparaison qui renvoient des correspondances partielles ne sont pas pris en charge. Par exemple, les instructions LIKE et STARTS WITH ne sont pas prises en charge.

Instructions SOQL ORDER BY

Le cryptage déterministe ne conserve pas l'ordre de tri des données cryptées dans la base de données. Par conséquent, ORDER BY n'est pas pris en charge.