View a markdown version of this page

Chiffrement consultable - AWS SDK de chiffrement de base de données
Les balises sont-elles adaptées à mon ensemble de données ?Scénario de chiffrement consultable

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Chiffrement consultable

Notre bibliothèque de chiffrement côté client a été renommée SDK de chiffrement de AWS base de données. Ce guide du développeur fournit toujours des informations sur le client de chiffrement DynamoDB.

Le chiffrement consultable vous permet de rechercher des enregistrements cryptés sans déchiffrer l'intégralité de la base de données. Cela se fait à l'aide de balises, qui créent une carte entre la valeur en texte brut écrite dans un champ et la valeur cryptée réellement stockée dans votre base de données. Le SDK AWS Database Encryption stocke la balise dans un nouveau champ qu'il ajoute à l'enregistrement. Selon le type de balise que vous utilisez, vous pouvez effectuer des recherches de correspondance exacte ou des requêtes complexes plus personnalisées sur vos données chiffrées.

Note

Le chiffrement consultable dans le SDK AWS de chiffrement de base de données est différent du chiffrement symétrique consultable défini dans la recherche universitaire, tel que le chiffrement symétrique consultable.

Une balise est une balise HMAC ( Hash-Based Message Authentication Code) tronquée qui associe une valeur de champ en texte brut à un identifiant chiffré et consultable. Lorsque vous écrivez une valeur dans un champ chiffré configuré pour le chiffrement consultable, le SDK de chiffrement de AWS base de données calcule un HMAC sur la valeur en texte brut. Cette sortie HMAC correspond un à un (1:1) à la valeur en texte brut de ce champ. Le SDK tronque intentionnellement la sortie HMAC afin que plusieurs valeurs de texte clair distinctes entrent en collision sur la même balise. Ces collisions (faux positifs) limitent la capacité d'un utilisateur non autorisé à déduire des informations sensibles à partir de modèles de fréquence. Lorsque vous interrogez une balise, le SDK AWS Database Encryption filtre automatiquement ces faux positifs et renvoie le résultat en texte brut de votre requête. Pour résoudre davantage ce problème de fuite de fréquence, les balises sont partitionnées, ce qui permet à des valeurs de texte brut identiques de produire des valeurs de balise différentes d'une partition à l'autre. Lorsque la table n'utilise qu'une seule partition, ce comportement correspond naturellement aux balises traditionnelles non partitionnées.

Le nombre moyen de faux positifs pour chaque balise dépend de la longueur restante de la balise après troncature et du nombre de partitions. Pour obtenir de l'aide pour déterminer la longueur de balise appropriée pour votre implémentation, consultez la section Détermination de la longueur de balise.

Note

Le chiffrement consultable est conçu pour être mis en œuvre dans de nouvelles bases de données non peuplées. Toute balise configurée dans une base de données existante ne cartographiera que les nouveaux enregistrements téléchargés dans la base de données, il n'y a aucun moyen pour une balise de mapper des données existantes.

Rubriques

Les balises sont-elles adaptées à mon ensemble de données ?

L'utilisation de balises pour effectuer des requêtes sur des données chiffrées réduit les coûts de performance associés aux bases de données chiffrées côté client. Lorsque vous utilisez des balises, il existe un compromis inhérent entre l'efficacité de vos requêtes et la quantité d'informations révélées sur la distribution de vos données. La balise ne modifie pas l'état chiffré du champ. Lorsque vous chiffrez et signez un champ avec le SDK de chiffrement AWS de base de données, la valeur en texte brut du champ n'est jamais exposée à la base de données. La base de données stocke la valeur chiffrée aléatoire du champ.

Les balises sont stockées à côté des champs cryptés à partir desquels elles sont calculées. Cela signifie que même si un utilisateur non autorisé ne peut pas voir les valeurs en texte clair d'un champ crypté, il peut être en mesure d'effectuer une analyse statistique sur les balises pour en savoir plus sur la distribution de votre ensemble de données et, dans les cas extrêmes, identifier les valeurs en texte clair auxquelles une balise correspond. Une configuration appropriée des balises est essentielle pour atténuer ces risques. La sélection d'une longueur de balise et d'un schéma de partitionnement appropriés préserve la confidentialité en garantissant un nombre suffisant de collisions et en atténuant les attaques basées sur les fréquences en limitant la concentration de valeurs dans une balise unique.

Sécurité et performance

  • La réduction de la longueur des balises et l'augmentation du nombre de partitions améliorent la sécurité en augmentant le nombre de collisions et en réduisant les fuites de fréquence,

  • L'allongement de la longueur des balises et le nombre réduit de partitions améliorent les performances en réduisant le nombre de faux positifs et le nombre de requêtes différées.

Dans de nombreux scénarios pratiques, une configuration bien choisie peut équilibrer ces objectifs concurrents. Cependant, le chiffrement consultable peut ne pas être en mesure de fournir les niveaux de sécurité et de performance souhaités pour chaque ensemble de données.

Avant de configurer des balises, examinez attentivement votre modèle de menace, vos exigences en matière de sécurité et vos besoins en termes de performances, et prenez en compte les caractéristiques uniques de votre ensemble de données afin de déterminer si le chiffrement consultable est un choix approprié.

Diffusion

Les propriétés de sécurité d'une balise dépendent à la fois de la distribution des données sous-jacentes et de la manière dont la balise est configurée, notamment du nombre de partitions utilisées. Lorsque vous configurez un champ chiffré pour le chiffrement consultable, le SDK de chiffrement AWS de base de données calcule un HMAC pour chaque valeur en texte brut écrite dans ce champ et déduit la balise à l'aide d'une clé cryptographique. Les balises sont calculées dans le contexte d'une partition, ce qui permet à des valeurs de texte brut identiques de produire des valeurs de balises différentes d'une partition à l'autre. Lorsque la table n'utilise qu'une seule partition, les valeurs identiques en texte brut correspondent toujours à la même balise HMAC tronquée, ce qui permet de préserver les modèles de fréquence du jeu de données d'origine.

Les champs dont la distribution est très asymétrique nécessitent une attention particulière. Prenons l'exemple d'une base de données qui enregistre la ville de résidence de tous les résidents de l'Illinois. Si vous créez une balise à partir du City champ crypté, la valeur « Chicago » apparaîtra beaucoup plus fréquemment que dans les autres villes. Même si un utilisateur non autorisé ne peut accéder qu'aux éléments chiffrés et aux valeurs des balises, ce déséquilibre peut lui permettre de déduire quels enregistrements correspondent aux résidents de Chicago en observant des balises surreprésentées. Le fait de tronquer la balise peut réduire cette fuite en provoquant davantage de collisions, mais la longueur de balise requise pour masquer suffisamment un biais important peut entraîner une surcharge de performance significative en raison de l'augmentation du nombre de faux positifs.

Pour configurer les balises en toute sécurité, vous devez analyser la distribution de fréquence de vos données et comprendre comment la troncature et le partitionnement interagissent. Le nombre de bits conservés dans une balise détermine la quantité d'informations statistiques exposées, tandis que le nombre de partitions limite la concentration que peut atteindre une valeur de balise unique. La réduction de la longueur des balises et l'augmentation du nombre de partitions réduisent les fuites de fréquence, mais augmentent le nombre de faux positifs et le nombre de requêtes. L'allongement de la longueur des balises et le nombre réduit de partitions améliorent l'efficacité des requêtes, mais fournissent davantage d'informations sur la distribution sous-jacente.

Dans certains cas extrêmes, les charges de travail ne sont pas viables lorsque la table n'utilise qu'une seule partition. Les attributs présentant de très petites populations ou des résultats binaires très déséquilibrés, tels que les résultats de tests médicaux où les valeurs NÉGATIVES dominent, ne peuvent pas être protégés uniquement par la troncature. Avec une partition, une balise suffisamment courte pour masquer la distribution regroupe toutes les valeurs en une seule balise, tandis qu'une balise plus longue permet d'identifier facilement les valeurs rares. Dans ces cas, des balises partitionnées sont nécessaires pour permettre le chiffrement consultable. En répartissant des valeurs surreprésentées sur plusieurs partitions, cette approche réduit la taille des classes d'équivalence et limite les fuites de fréquence d'une manière impossible lors de l'utilisation d'une seule partition.

Corrélation

Nous vous recommandons vivement d'éviter de créer des balises distinctes à partir de champs contenant des valeurs corrélées. Les balises construites à partir de champs corrélés nécessitent des longueurs de balise plus courtes pour minimiser suffisamment la quantité d'informations révélées sur la distribution de chaque ensemble de données à un utilisateur non autorisé. Vous devez analyser soigneusement votre ensemble de données, notamment son entropie et la distribution conjointe des valeurs corrélées, afin de déterminer dans quelle mesure vos balises doivent être tronquées. Si la longueur des balises qui en résulte ne répond pas à vos besoins en termes de performances, les balises ne conviennent peut-être pas à votre ensemble de données.

Par exemple, vous ne devez pas créer deux balises City et deux ZIPCode champs distincts, car le code postal sera probablement associé à une seule ville. Généralement, les faux positifs générés par une balise limitent la capacité d'un utilisateur non autorisé à identifier des informations distinctives concernant votre ensemble de données. Mais la corrélation entre les ZIPCode champs City et signifie qu'un utilisateur non autorisé peut facilement identifier les résultats faussement positifs et distinguer les différents codes postaux.

Vous devez également éviter de créer des balises à partir de champs contenant les mêmes valeurs en texte brut. Par exemple, vous ne devez pas créer de balise à partir de preferredPhone champs mobilePhone et de champs, car ils contiennent probablement les mêmes valeurs. Si vous créez des balises distinctes à partir des deux champs, le SDK AWS de chiffrement de base de données crée les balises pour chaque champ sous des clés différentes. Il en résulte deux balises HMAC différentes pour la même valeur en texte brut. Il est peu probable que les deux balises distinctes présentent les mêmes faux positifs et un utilisateur non autorisé pourrait être en mesure de distinguer différents numéros de téléphone.

Même si votre jeu de données contient des champs corrélés ou présente une distribution inégale, vous pouvez peut-être créer des balises qui préservent la confidentialité de votre ensemble de données en utilisant des longueurs de balise plus courtes. Cependant, la longueur des balises ne garantit pas que chaque valeur unique de votre ensemble de données produira un certain nombre de faux positifs qui minimiseront efficacement la quantité d'informations distinctives révélées à propos de votre ensemble de données. La longueur de la balise estime uniquement le nombre moyen de faux positifs produits. Plus votre jeu de données est inégalement distribué, moins la longueur de balise est efficace pour déterminer le nombre moyen de faux positifs produits.

Évaluez soigneusement la distribution des champs que vous choisissez de baliser et déterminez le niveau de troncature requis pour répondre à vos exigences de sécurité. Les rubriques suivantes de ce chapitre supposent que, au sein de chaque partition, les valeurs des balises sont distribuées de manière uniforme et que les données sous-jacentes n'introduisent pas de corrélations susceptibles d'affaiblir ces hypothèses.

Scénario de chiffrement consultable

L'exemple suivant illustre une solution de chiffrement consultable et illustre les concepts de base abordés dans ce chapitre. Dans ce scénario, certaines valeurs de champ apparaissent très fréquemment, ce qui entraînerait de grandes classes d'équivalence et une augmentation des fuites de fréquence si une seule partition était utilisée. Pour résoudre ce problème, la configuration utilise plusieurs partitions afin que les valeurs très fréquentes soient distribuées de manière plus uniforme, réduisant ainsi les fuites tout en préservant la possibilité d'effectuer des recherches d'égalité efficaces.

Prenons l'exemple d'une base de données nommée Employees qui suit les données des employés d'une entreprise. Chaque enregistrement de la base de données contient des champs appelés EmployeeID LastName, FirstName, et Address. Chaque champ de la Employees base de données est identifié par la clé primaireEmployeeID.

Voici un exemple d'enregistrement en texte brut dans la base de données.

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Si vous avez marqué les FirstName champs LastName et comme ENCRYPT_AND_SIGN dans vos actions cryptographiques, les valeurs de ces champs sont chiffrées localement avant d'être téléchargées dans la base de données. Les données cryptées téléchargées sont entièrement aléatoires, la base de données ne reconnaît pas ces données comme étant protégées. Il détecte simplement les entrées de données typiques. Cela signifie que l'enregistrement réellement stocké dans la base de données peut ressembler à ce qui suit.

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Si vous devez interroger la base de données pour obtenir des correspondances exactes dans le LastName champ, configurez une balise standard nommée LastNamepour mapper les valeurs en texte clair écrites dans le LastName champ aux valeurs cryptées stockées dans la base de données.

Cette balise calcule les HMAC à partir des valeurs en texte brut du champ. LastName Chaque sortie HMAC est tronquée de sorte qu'elle ne correspond plus exactement à la valeur en texte brut. Par exemple, le hachage complet et le hachage tronqué pour Jones peuvent ressembler à ce qui suit.

Hachage complet

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

Hachage tronqué

b35099d408c833

Dans un ensemble de données comptant de nombreux employés, certains noms de famille tels que Jones, Smith ou Johnson peuvent apparaître beaucoup plus fréquemment que d'autres. Pour réduire les fuites de fréquence et limiter la taille des classes d'équivalence des balises, vous devez configurer la LastNamebalise pour qu'elle utilise plusieurs partitions.

Lorsque les partitions sont activées, chaque élément est attribué à une partition au moment de l'écriture, et le numéro de partition est intégré dans la dérivation des balises. Par conséquent, les employés portant le même nom de famille peuvent être mappés à des valeurs de balise différentes selon les partitions. Cela répartit les noms très fréquents sur plusieurs partitions, réduisant ainsi la surreprésentation d'une valeur de balise unique.

Une fois la balise standard configurée, vous pouvez effectuer des recherches d'égalité sur le LastName terrain. Par exemple, si vous souhaitez effectuer une rechercheJones, utilisez la LastNamebalise pour effectuer la requête suivante.

LastName = Jones

Lorsque vous recherchez un nom de famille spécifique à haute fréquence, tel que Jones, l'application doit émettre une requête par partition à l'aide de la LastNamebalise. Le SDK AWS Database Encryption déchiffre ensuite les résultats et filtre automatiquement les faux positifs, renvoyant les enregistrements en texte brut corrects.