Considérations relatives à l'utilisation de l'informatique cryptographique pour Clean Rooms

Cryptographic Computing for Clean Rooms (C3R) vise à optimiser la protection des données. Toutefois, certains cas d'utilisation peuvent bénéficier de niveaux inférieurs de protection des données en échange de fonctionnalités supplémentaires. Vous pouvez faire ces compromis spécifiques en modifiant C3R à partir de sa configuration la plus sécurisée. En tant que client, vous devez être conscient de ces compromis et déterminer s'ils sont adaptés à votre cas d'utilisation. Les compromis à prendre en compte sont les suivants :

Pour plus d'informations sur la façon de définir les paramètres de ces scénarios, consultezParamètres de calcul cryptographique.

Autoriser les données mixtes cleartext et cryptées dans vos tables

Le chiffrement de toutes les données côté client garantit une protection maximale des données. Cela limite toutefois certains types de requêtes (par exemple, la fonction d'SUMagrégation). Le risque lié à l'autorisation des cleartext données est qu'il est possible que toute personne ayant accès aux tables cryptées puisse déduire certaines informations sur les valeurs cryptées. Cela pourrait être fait en effectuant une analyse statistique des données cleartext et des données associées.

Par exemple, imaginez que vous disposiez des colonnes de City etState. La City colonne est chiffrée cleartext et State elle est cryptée. Lorsque vous voyez la valeur Chicago dans la City colonne, cela vous permet de déterminer avec une forte probabilité que State c'est le casIllinois. En revanche, si une colonne l'est City et l'autre l'estEmailAddress, il cleartext City est peu probable que a révèle quoi que ce soit à propos d'un chiffréEmailAddress.

Pour plus d'informations sur le paramètre de ce scénario, consultezParamètre Autoriser cleartext les colonnes.

Autoriser les valeurs répétées dans les fingerprint colonnes

Pour l'approche la plus sûre, nous supposons que chaque fingerprint colonne contient exactement une instance d'une variable. Aucun élément ne peut être répété dans une fingerprint colonne. Le client de chiffrement C3R mappe ces cleartext valeurs en valeurs uniques impossibles à distinguer des valeurs aléatoires. Il est donc impossible de déduire des informations les concernant à cleartext partir de ces valeurs aléatoires.

Le risque de valeurs répétées dans une fingerprint colonne est que les valeurs répétées se traduisent par des valeurs répétées d'apparence aléatoire. Ainsi, toute personne ayant accès aux tables cryptées pourrait, en théorie, effectuer une analyse statistique des fingerprint colonnes susceptible de révéler des informations sur cleartext les valeurs.

Encore une fois, supposons que la fingerprint colonne soitState, et que chaque ligne du tableau corresponde à un ménage américain. En effectuant une analyse de fréquence, on pourrait déduire quel état est California et lequel est Wyoming avec une probabilité élevée. Cette inférence est possible car il California compte beaucoup plus de résidents que. Wyoming En revanche, supposons que la fingerprint colonne porte sur un identifiant de ménage et que chaque ménage apparaisse dans la base de données entre 1 et 4 fois dans une base de données contenant des millions d'entrées. Il est peu probable qu'une analyse de fréquence révèle des informations utiles.

Pour plus d'informations sur le paramètre de ce scénario, consultezParamètre Autoriser les doublons.

Assouplissement des restrictions relatives au fingerprint nom des colonnes

Par défaut, nous supposons que lorsque deux tables sont jointes à l'aide de fingerprint colonnes chiffrées, ces colonnes portent le même nom dans chaque table. La raison technique de ce résultat est que, par défaut, nous dérivons une clé cryptographique différente pour chiffrer chaque fingerprint colonne. Cette clé est dérivée d'une combinaison de la clé secrète partagée pour la collaboration et du nom de colonne. Si nous essayons de joindre deux colonnes portant des noms de colonne différents, nous dérivons des clés différentes et nous ne pouvons pas calculer une jointure valide.

Pour résoudre ce problème, vous pouvez désactiver la fonctionnalité qui déduit les clés du nom de chaque colonne. Le client de chiffrement C3R utilise ensuite une clé dérivée unique pour toutes les fingerprint colonnes. Le risque est qu'un autre type d'analyse de fréquence puisse être effectué qui pourrait révéler des informations.

Utilisons à nouveau l'Stateexemple City et. Si nous dérivons les mêmes valeurs aléatoires pour chaque fingerprint colonne (en n'incorporant pas le nom de la colonne). New Yorkpossède la même valeur aléatoire dans les State colonnes City et. New York est l'une des rares villes des États-Unis où le City nom est le même que le State nom. En revanche, si votre ensemble de données contient des valeurs complètement différentes dans chaque colonne, aucune information n'est divulguée.

Pour plus d'informations sur le paramètre de ce scénario, consultezParamètre JOIN d'autorisation des colonnes avec des noms différents.

Déterminer comment NULL les valeurs sont représentées

L'option qui s'offre à vous est de savoir s'il faut traiter les NULL valeurs de manière cryptographique (chiffrement et HMAC) comme toute autre valeur. Si vous ne traitez pas NULL les valeurs comme les autres valeurs, des informations peuvent être révélées.

Supposons, par exemple, que NULL la Middle Name colonne cleartext indique les personnes sans deuxième prénom. Si vous ne chiffrez pas ces valeurs, vous divulguez les lignes de la table cryptée qui sont utilisées pour les personnes sans deuxième prénom. Ces informations peuvent être un signal d'identification pour certaines personnes dans certaines populations. Mais si vous traitez des NULL valeurs de manière cryptographique, certaines requêtes SQL agissent différemment. Par exemple, les GROUP BY clauses ne regrouperont pas fingerprint NULL les valeurs dans fingerprint des colonnes.

Pour plus d'informations sur le paramètre de ce scénario, consultezParamètre de conservation NULL des valeurs.