J'ai besoin de créer un service d'identité qui utilise une clé fournie par le client pour chiffrer les valeurs d'ID sensibles pour le stockage dans RDS, mais qui doit également nous permettre de rechercher un enregistrement plus tard à l'aide de l'ID en texte brut. Nous aimerions utiliser un algorithme de chiffrement déterministe simple pour cela, mais il semble que l'API KMS ne vous permette pas de spécifier l'IV, vous ne pouvez donc jamais obtenir un texte en clair identique à chiffrer deux fois à la même valeur.
Nous avons également l'obligation de rechercher les données en utilisant une autre valeur non sécurisée, de récupérer la valeur sécurisée chiffrée et de la déchiffrer - le hachage unidirectionnel ne fonctionnera donc malheureusement pas.
Pris ensemble, cela signifie que nous ne serons pas en mesure d'effectuer notre recherche de l'ID sécurisé sans la force brute de parcourir tous les enregistrements et de les déchiffrer et de les comparer à la valeur en texte brut, au lieu de simplement chiffrer la valeur de recherche en clair à l'aide d'un IV et en utilisant cette valeur chiffrée comme index pour rechercher l'enregistrement correspondant dans la base de données.
Je suppose que c'est une exigence assez courante pour des choses comme les SSN et autres, alors comment les gens résolvent-ils cela?
Merci d'avance.
3 Réponses :
rechercher un enregistrement plus tard en utilisant l'ID en texte brut
Vous perdez alors un peu de sécurité. Peut-être pourriez-vous stocker un hachage (par exemple sha-256) de l'ID le long des données chiffrées, ce qui faciliterait la recherche de l'enregistrement, mais ne rétablirait pas la valeur
Cette approche suppose que l'ID provient d'un espace de message raisonnablement grand (il y a potentiellement beaucoup d'ID), il n'est donc pas possible de créer une carte pour chaque valeur possible
L'API KMS ne vous permet pas de spécifier l'IV, vous ne pouvez donc jamais obtenir un texte en clair identique à chiffrer deux fois avec la même valeur.
oui, KMS semble fournir son propre IV pour le cryptage en appliquant les bonnes pratiques de sécurité
Il s'agit essentiellement d'un pipeline de transformation de données dans lequel nous avons des fichiers d'entrée avec des ID sensibles en texte brut que nous voulons tokenize / remplacer, puis effectuer un certain nombre d'étapes de traitement différentes en utilisant l'ID tokenisé (de sorte que la journalisation et les ensembles de données envoyés entre les étapes n'aient pas les identifiants sensibles du tout), puis lors d'une étape de sortie, réinsérez les identifiants sensibles, si nécessaire. Le hachage en conjonction avec le chiffrement serait une solution, mais je ne vois même pas de moyen de faire un hachage SHA générique sur des données à l'aide d'une clé KMS. Les fonctions semblent globalement assez limitées.
@MikeB vous pouvez créer un hachage cryptographique normal (aucun KMS n'est nécessaire). KMS pourrait être utilisé pour crypter les ID d'origine stockés jusqu'à ce que le reste des données soit traité.
Oui - merci - c'est exactement ce que nous avons fini par faire, en utilisant l'extension pgencrypt pour le rendre facile
si je comprends bien votre cas d'utilisation, votre flux est comme ceci:
Si le client réutilise la clé, ce n'est en fait pas si difficile à accomplir.
Créez une clé KMS pour le client.
Utilisez cette clé KMS pour crypter l'IV du client et la clé que le client a spécifiée, et les stocker dans Amazon Secrets Manager - de préférence avec un espace de noms d'une manière ou d'une autre par le client. Une structure Json comme celle-ci:
{ "iv": "somerandomivvalue", "clé": "somerandomkey" }
vous permettrait d'analyser facilement les valeurs. ASM vous permet également d'effectuer une rotation des clés de manière transparente - ce qui est vraiment très pratique.
Si vous êtes paranoïaque, vous pouvez prendre un hachage cryptographique du nom du client (ou autre) et de l'espace de noms par là.
RDS stocke désormais l'ID numérique du client, les valeurs non sécurisées et une valeur d'espace de noms (ou une méthode de dérivation de l'emplacement) dans ASM.
Il va sans dire que vous devez limiter l'accès au coffre-fort du gestionnaire de secrets.
Pour utiliser la solution:
Avantages: vous cryptez et décryptez les valeurs secrètes dans ASM avec une clé KMS sous votre contrôle total, et vous pouvez stocker et récupérer l'état dont vous avez besoin pour décrypter les valeurs client de manière sécurisée.
D'autres auront probablement de meilleures solutions cryptographiques, mais cela devrait être le cas pour une première tentative.
Nous avons pensé à faire cette chose même si vous l'avez étoffée plus en détail avec l'idée d'espace de noms. L'inconvénient est qu'il expose la clé client à notre code lambda client - nous espérions garder toutes les opérations de cryptage en toute sécurité dans les limites de KMS, mais je suppose que ce n'est tout simplement pas possible étant donné qu'il n'y a aucun moyen de spécifier un IV pour KMS il n'y a même pas d'opérations de hachage de données, ce qui aurait été notre alternative - que KMS crypte à la fois pour une colonne et hachage pour la colonne de recherche. Je n'arrête pas de penser que cela doit être résolu de manière sécurisée étant donné la maturité d'AWS.
En fin de compte, nous avons décidé de continuer à utiliser KMS pour la clé de chiffrement / déchiffrement fournie par le client de la colonne d'ID sensible, mais nous avons également activé l'extension PostgreSQL pgcrypt pour fournir des hachages sécurisés pour les recherches. Donc, en plus de notre colonne chiffrée, nous avons ajouté une colonne id_hash et nous opérons sur la table quelque chose comme ceci:
`INSÉRER DANS LES VALEURS DE L'employé ..., id_hash = ENCODE (HMAC ('SENSITIVE_ID + SECRET_SALT', 'SECRET_PASSPHRASE', 'sha256'), 'hex');
SELECT FROM employé WHERE division_id = ??? AND id_hash = ENCODE (HMAC ('SENSITIVE_ID + SECRET_SALT', 'SECRET_PASSPHRASE', 'sha256'), 'hex'); `
Nous aurions pu faire le hachage côté client, mais comme l'algorithme est essentiel pour les recherches ultérieures, nous avons aimé la simplicité d'avoir la base de données faire le hachage pour nous.
J'espère que cela sera utile à quiconque recherche une solution.
Oui, c'était l'intention de ma réponse. Cependant, veuillez noter que le hachage cryptographique est conçu pour être résistant aux collisions, mais il ne peut être mathématiquement garanti qu'il est unique. Si vous travaillez avec des données réglementées et vérifiées (par exemple, des paiements, des dossiers de santé), vous voudrez peut-être vérifier et vous assurer ou gérer qu'il n'y a pas de doublons