Chiffrement interrogeable

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

Le chiffrement interrogeable vous permet de rechercher des enregistrements chiffré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 qui est 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 par correspondance exacte ou des requêtes complexes plus personnalisées sur vos données cryptées.

Note

Le chiffrement interrogeable du SDK AWS Database Encryption diffère du chiffrement symétrique interrogeable défini dans la recherche universitaire, tel que le chiffrement symétrique interrogeable.

Une balise est une balise HMAC (code d'authentification des messages basée sur le hachage) tronquée qui crée une carte entre le texte brut et les valeurs cryptées d'un champ. Lorsque vous écrivez une nouvelle valeur dans un champ crypté configuré pour un chiffrement interrogeable, le SDK AWS Database Encryption calcule un HMAC sur la valeur du texte brut. Cette sortie HMAC correspond un à un (1:1) à la valeur en texte brut de ce champ. La sortie HMAC est tronquée de sorte que plusieurs valeurs de texte brut distinctes correspondent à la même balise HMAC tronquée. Ces faux positifs limitent la capacité d'un utilisateur non autorisé à identifier des informations distinctives concernant la valeur en texte brut. Lorsque vous interrogez une balise, le SDK AWS Database Encryption filtre automatiquement ces faux positifs et renvoie le résultat en texte clair de votre requête.

Le nombre moyen de faux positifs générés pour chaque balise est déterminé par la longueur de balise restante après la troncature. Pour vous aider à déterminer la longueur de balise appropriée pour votre implémentation, voir Détermination de la longueur de balise.

Note

Le chiffrement interrogeable est conçu pour être implémenté dans de nouvelles bases de données non remplies. Toute balise configurée dans une base de données existante ne mappe que les nouveaux enregistrements chargés dans la base de données. Il n'existe aucun moyen pour une balise de mapper les données existantes.

Rubriques

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

• Scénario de chiffrement interrogeable

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

L'utilisation de balises pour effectuer des requêtes sur des données cryptées réduit les coûts de performance associés aux bases de données crypté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 crypté du champ. Lorsque vous chiffrez et signez un champ à l'aide du SDK AWS Database Encryption, 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 crypté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 brut d'un champ chiffré, il peut être en mesure d'effectuer une analyse statistique sur les balises pour en savoir plus sur la distribution de votre jeu de données et, dans des cas extrêmes, identifier les valeurs de texte en clair auxquelles une balise est associée. La façon dont vous configurez vos balises peut atténuer ces risques. En particulier, le choix de la bonne longueur de balise peut vous aider à préserver la confidentialité de votre ensemble de données.

Sécurité contre performance

• Plus la longueur de la balise est courte, plus la sécurité est préservée.

• Plus la longueur de la balise est longue, plus les performances sont préservées.

Le chiffrement interrogeable peut ne pas être en mesure de fournir les niveaux de performance et de sécurité souhaités pour tous les ensembles de données. Passez en revue votre modèle de menace, vos exigences de sécurité et vos besoins en matière de performances avant de configurer des balises.

Tenez compte des exigences d'unicité suivantes pour déterminer si le chiffrement interrogeable convient à votre jeu de données.

Distribution

Le niveau de sécurité préservé par une balise dépend de la distribution de votre jeu de données. Lorsque vous configurez un champ crypté pour un chiffrement interrogeable, le SDK AWS Database Encryption calcule un HMAC sur les valeurs en texte brut écrites dans ce champ. Toutes les balises calculées pour un champ donné sont calculées à l'aide de la même clé, à l'exception des bases de données mutualisées qui utilisent une clé distincte pour chaque locataire. Cela signifie que si la même valeur de texte en clair est écrite plusieurs fois dans le champ, la même balise HMAC est créée pour chaque instance de cette valeur de texte en clair.

Vous devez éviter de créer des balises à partir de champs contenant des valeurs très courantes. Prenons l'exemple d'une base de données qui stocke l'adresse de chaque résident de l'État de l'Illinois. Si vous créez une balise à partir du City champ crypté, la balise calculée sur « Chicago » sera surreprésentée en raison du fort pourcentage de la population de l'Illinois qui vit à Chicago. Même si un utilisateur non autorisé ne peut lire que les valeurs cryptées et les valeurs des balises, il peut être en mesure d'identifier les enregistrements contenant des données concernant les résidents de Chicago si la balise préserve cette distribution. Pour minimiser la quantité d'informations distinctives révélées sur votre distribution, vous devez suffisamment tronquer votre balise. La longueur de balise requise pour masquer cette distribution inégale entraîne des coûts de performance importants qui peuvent ne pas répondre aux besoins de votre application.

Vous devez analyser attentivement la distribution de votre jeu de données afin de déterminer dans quelle mesure vos balises doivent être tronquées. La longueur restante de la balise après la troncature est directement liée à la quantité d'informations statistiques pouvant être identifiées concernant votre distribution. Vous devrez peut-être choisir des longueurs de balise plus courtes pour minimiser suffisamment la quantité d'informations distinctives révélées à propos de votre jeu de données.

Dans les cas extrêmes, vous ne pouvez pas calculer la longueur d'une balise pour un ensemble de données réparti de manière inégale afin d'équilibrer efficacement les performances et la sécurité. Par exemple, vous ne devez pas créer une balise à partir d'un champ contenant le résultat d'un test médical pour une maladie rare. Étant donné que les NEGATIVE résultats devraient être nettement plus répandus dans l'ensemble de données, les POSITIVE résultats peuvent être facilement identifiés en fonction de leur rareté. Il est très difficile de masquer la distribution lorsque le champ ne comporte que deux valeurs possibles. Si vous utilisez une longueur de balise suffisamment courte pour masquer la distribution, toutes les valeurs en texte brut correspondent à la même balise HMAC. Si vous utilisez une longueur de balise plus longue, il est évident de savoir quelles balises correspondent à des valeurs en texte brutPOSITIVE.

Corrélation

Nous vous recommandons vivement d'éviter de créer des balises distinctes à partir de champs comportant des valeurs corrélées. Les balises construites à partir de champs corrélés nécessitent des longueurs de balise plus courtes afin de 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 minutieusement votre jeu 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 peuvent ne pas être adaptées à votre jeu de données.

Par exemple, vous ne devez pas créer deux balises distinctes à partir des ZIPCode champs City et, 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 jeu 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 qui sont des faux 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 de texte brut. Par exemple, vous ne devez pas créer une balise à partir de preferredPhone champs mobilePhone et 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. Cela se traduit par deux balises HMAC différentes pour la même valeur de 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 jeu de données en utilisant des longueurs de balises plus courtes. Toutefois, la longueur de la balise ne garantit pas que chaque valeur unique de votre jeu de données produira un certain nombre de faux positifs qui minimisent efficacement la quantité d'informations distinctives révélées à propos de votre jeu de données. La longueur de la balise estime uniquement le nombre moyen de faux positifs produits. Plus votre jeu de données est réparti de manière inégale, moins la longueur de la balise est efficace pour déterminer le nombre moyen de faux positifs produits.

Examinez attentivement la distribution des champs à partir desquels vous créez des balises et déterminez dans quelle mesure vous devrez tronquer la longueur des balises pour répondre à vos exigences de sécurité. Les rubriques suivantes de ce chapitre supposent que vos balises sont distribuées de manière uniforme et ne contiennent pas de données corrélées.

Scénario de chiffrement interrogeable

L'exemple suivant montre une solution de chiffrement simple avec fonction de recherche. Dans l'application, les champs d'exemple utilisés dans cet exemple peuvent ne pas répondre aux recommandations d'unicité de distribution et de corrélation pour les balises. Vous pouvez utiliser cet exemple à titre de référence pour découvrir les concepts de chiffrement pouvant faire l'objet de recherches dans ce chapitre.

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, LastNameFirstName, 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 cryptées localement avant d'être téléchargées dans la base de données. Les données cryptées qui sont 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 brut é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 de texte brut du champ. LastName Chaque sortie HMAC est tronquée de sorte qu'elle ne correspond plus exactement à la valeur du texte en clair. Par exemple, le hachage complet et le hachage tronqué pour Jones peuvent ressembler à ce qui suit.

Hachage complet

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

Hachage tronqué

b35099d408c833

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

Le SDK AWS Database Encryption filtre automatiquement les faux positifs et renvoie le résultat en texte clair de votre requête.