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.

Directives pour le client de chiffrement C3R

Le client de chiffrement C3R est un outil qui permet aux entreprises de rassembler des données sensibles afin de tirer de nouvelles informations de l'analyse des données. L'outil limite cryptographiquement ce qui peut être appris par n'importe quelle partie et AWS au cours du processus. Bien que cela soit d'une importance vitale, le processus de sécurisation cryptographique des données peut entraîner une surcharge importante en termes de ressources de calcul et de stockage. Il est donc important de comprendre les inconvénients liés à l'utilisation de chaque paramètre et de savoir comment optimiser les paramètres tout en maintenant les garanties cryptographiques souhaitées. Cette rubrique se concentre sur les implications en termes de performances des différents paramètres du client et des schémas de chiffrement C3R.

Tous les paramètres de chiffrement du client de chiffrement C3R fournissent des garanties cryptographiques différentes. Les paramètres de collaboration sont les plus sécurisés par défaut. L'activation de fonctionnalités supplémentaires lors de la création d'une collaboration affaiblit les garanties de confidentialité, ce qui permet d'effectuer des activités telles que l'analyse des fréquences sur le texte chiffré. Pour plus d'informations sur l'utilisation de ces paramètres et leurs implications, consultezInformatique cryptographique pour Clean Rooms.

Implications sur les performances pour les types de colonnes

C3R utilise trois types de colonnes : cleartext, fingerprint, et sealed. Chacun de ces types de colonnes fournit des garanties cryptographiques différentes et a des utilisations prévues différentes. Dans les sections suivantes, les implications du type de colonne sur les performances sont abordées ainsi que l'impact de chaque paramètre sur les performances.

Cleartext columns

Cleartext les colonnes ne sont pas modifiées par rapport à leur format d'origine et ne sont en aucun cas traitées cryptographiquement. Ce type de colonne ne peut pas être configuré et n'a aucune incidence sur les performances de stockage ou de calcul.

Fingerprint columns

Fingerprint les colonnes sont destinées à être utilisées pour joindre des données sur plusieurs tables. À cette fin, la taille du texte chiffré obtenu doit toujours être la même. Toutefois, ces colonnes sont affectées par les paramètres de collaboration. Fingerprint les colonnes peuvent avoir différents degrés d'impact sur la taille du fichier de sortie en fonction du cleartext contenu dans l'entrée.

Frais généraux de base pour fingerprint columns

Il existe des frais généraux de base pour fingerprint colonnes. Ce surcoût est constant et remplace la taille du cleartext octets.

Données contenues dans le fingerprint les colonnes sont traitées cryptographiquement par le biais d'une fonction HMAC (code d'authentification de message basé sur le hachage), qui transforme les données en un code d'authentification de message (MAC) de 32 octets. Ces données sont ensuite traitées via un encodeur base64, ce qui ajoute environ 33 % à la taille des octets. Il est précédé d'une désignation C3R à 8 octets pour désigner le type de colonne à laquelle appartiennent les données et la version du client qui les a produites. Le résultat final est de 52 octets. Ce résultat est ensuite multiplié par le nombre de lignes pour obtenir le surcoût total de base (utilisez le nombre total de null valeurs non égales s'il preserveNulls est défini sur true).

L'image suivante montre comment BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

Le texte chiffré de sortie dans fingerprint les colonnes seront toujours de 52 octets. Cela peut entraîner une diminution significative de la capacité de stockage si l'entrée cleartext les données mesurent en moyenne plus de 52 octets (par exemple, adresses postales complètes). Cela peut représenter une augmentation significative de la capacité de stockage si l'entrée cleartext les données ont en moyenne moins de 52 octets (par exemple, l'âge du client).

Paramètres de collaboration pour fingerprint columns

Paramètre preserveNulls

Lorsque le paramètre au niveau de la collaboration preserveNulls est false (par défaut), chaque null valeur est remplacée par 32 octets uniques et aléatoires et traitée comme si ce n'était pas le cas. null Le résultat est que chaque null valeur est désormais de 52 octets. Cela peut ajouter des exigences de stockage importantes pour les tables contenant très peu de données par rapport à ce paramètre true et à ce que null les valeurs sont transmises sous forme null de.

Si vous n'avez pas besoin des garanties de confidentialité de ce paramètre et que vous préférez conserver null les valeurs de vos ensembles de données, activez le preserveNulls paramètre au moment de la création de la collaboration. Le preserveNulls paramètre ne peut pas être modifié une fois la collaboration créée.

Exemple de données pour un fingerprint column

Voici un exemple d'ensemble de données d'entrée et de sortie pour un fingerprint colonne avec les paramètres à reproduire. D'autres paramètres de collaboration n'ont allowDuplicates pas d'impact sur les résultats et peuvent être définis au fur true et à mesure que allowCleartext false vous essayez de reproduire localement.

Exemple de secret partagé : wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Exemple d'identifiant de collaboration : a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: True ce paramètre n'a aucune incidence sur les performances ou les exigences de stockage. Toutefois, ce paramètre rend le choix du nom de colonne non pertinent lors de la reproduction des valeurs indiquées dans les tableaux suivants.

Résolution des problèmes fingerprint columns

Pourquoi le texte chiffré se trouve-t-il dans mon fingerprint colonnes plusieurs fois supérieures à la taille du cleartext ça y est entré ?

Texte chiffré dans un fingerprint la longueur de la colonne est toujours de 52 octets. Si vos données d'entrée étaient petites (par exemple, l'âge des clients), elles indiqueront une augmentation significative de leur taille. Cela peut également se produire si le preserveNulls paramètre est réglé surfalse.

Pourquoi le texte chiffré se trouve-t-il dans mon fingerprint colonnes plusieurs fois plus petites que la taille du cleartext ça y est entré ?

Texte chiffré dans un fingerprint la longueur de la colonne est toujours de 52 octets. Si vos données d'entrée sont volumineuses (par exemple, les adresses complètes des clients), leur taille diminuera considérablement.

Comment savoir si j'ai besoin des garanties cryptographiques fournies par preserveNulls ?

Malheureusement, la réponse est que cela dépend. Au minimum, Paramètres de calcul cryptographique il convient de vérifier la manière dont le preserveNulls paramètre protège vos données. Cependant, nous vous recommandons de faire référence aux exigences de votre organisation en matière de traitement des données et à tout contrat applicable à la collaboration correspondante.

Pourquoi dois-je supporter la surcharge de base64 ?

Pour garantir la compatibilité avec les formats de fichiers tabulaires tels que CSV, le codage base64 est nécessaire. Bien que certains formats de fichiers tels que Parquet peut prendre en charge les représentations binaires des données, il est important que tous les participants à une collaboration représentent les données de la même manière pour garantir des résultats de requête corrects.

Sealed columns

Sealed les colonnes sont destinées à être utilisées pour transférer des données entre les membres d'une collaboration. Le texte chiffré de ces colonnes n'est pas déterministe et a un impact significatif sur les performances et le stockage en fonction de la configuration des colonnes. Ces colonnes peuvent être configurées individuellement et ont souvent le plus grand impact sur les performances du client de chiffrement C3R et sur la taille du fichier de sortie qui en résulte.

Frais généraux de base pour sealed columns

Il existe des frais généraux de base pour sealed colonnes. Ce surcoût est constant et, en plus de la taille du cleartext et le remplissage (le cas échéant) d'octets.

Avant tout chiffrement, les données contenues dans sealed les colonnes sont précédées d'un caractère de 1 octet désignant le type de données contenues. Si le rembourrage est sélectionné, les données sont ensuite complétées et ajoutées avec 2 octets indiquant la taille du pad. Une fois ces octets ajoutés, les données sont traitées cryptographiquement à l'aide d'AES-GCM et stockées avec le IV (12 octets), nonce (32 octets), et Auth Tag (16 octets). Ces données sont ensuite traitées via un encodeur base64, ce qui ajoute environ 33 % à la taille des octets. Les données sont précédées d'une désignation C3R de 7 octets pour indiquer le type de colonne auquel elles appartiennent et la version du client utilisée pour les produire. Le résultat est un surdébit de base final de 91 octets. Ce résultat peut ensuite être multiplié par le nombre de lignes pour obtenir le surcoût total de base (utilisez le nombre total de valeurs non nulles s'il preserveNulls est défini sur true).

L'image suivante montre comment BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

Paramètres de collaboration pour sealed columns

Paramètre preserveNulls

Lorsque le paramètre au niveau de la collaboration preserveNulls est false (par défaut), chaque null valeur est unique, aléatoire de 32 octets et traitée comme si ce n'était pas le cas. null Le résultat est que chaque null valeur est désormais de 91 octets (plus si elle est complétée). Cela peut ajouter des exigences de stockage importantes pour les tables contenant très peu de données par rapport à ce paramètre true et à ce que null les valeurs sont transmises sous forme null de.

Si vous n'avez pas besoin des garanties de confidentialité de ce paramètre et que vous préférez conserver null les valeurs de vos ensembles de données, activez le preserveNulls paramètre au moment de la création de la collaboration. Le preserveNulls paramètre ne peut pas être modifié une fois la collaboration créée.

Paramètres du schéma sealed colonnes : types de rembourrage

Type de pad none

La sélection d'un type de pad none n'ajoute aucun rembourrage au cleartext et n'ajoute aucune surcharge supplémentaire à la surcharge de base décrite précédemment. L'absence de rembourrage permet d'obtenir la taille de sortie la plus économe en espace. Cependant, il n'offre pas les mêmes garanties de confidentialité que les types de rembourrage fixed et de max rembourrage. Cela est dû au fait que la taille du sous-jacent cleartext est perceptible à partir de la taille du texte chiffré.

Type de pad fixed

La sélection d'un type de pad fixed est une mesure de protection de la vie privée qui permet de masquer la longueur des données contenues dans une colonne. Cela se fait en rembourrant tous les cleartext à celui fourni pad_length avant qu'il ne soit crypté. Toute donnée dépassant cette taille entraîne l'échec du client de chiffrement C3R.

Étant donné que le rembourrage est ajouté au cleartext avant d'être chiffré, AES-GCM dispose d'un mappage 1 à 1 de cleartext en octets de texte chiffré. Le codage base64 ajoutera 33 %. La surcharge de stockage supplémentaire du rembourrage peut être calculée en soustrayant la longueur moyenne du cleartext à partir de la valeur de pad_length et en la multipliant par 1,33. Le résultat est le surcoût moyen de remplissage par enregistrement. Ce résultat peut ensuite être multiplié par le nombre de lignes pour obtenir la surcharge de remplissage totale (utilisez le nombre total de null valeurs non égales si la valeur preserveNulls est définie surtrue).

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

Nous vous recommandons de sélectionner le minimum pad_length qui englobe la plus grande valeur d'une colonne. Par exemple, si la plus grande valeur est de 50 octets, une valeur pad_length de 50 est suffisante. Une valeur supérieure à cette valeur ne fera qu'augmenter la charge de stockage.

Le rembourrage fixe n'entraîne aucune surcharge de calcul significative.

Type de pad max

La sélection d'un type de pad max est une mesure de protection de la vie privée qui permet de masquer la longueur des données contenues dans une colonne. Cela se fait en rembourrant tous les cleartext à la plus grande valeur de la colonne plus la valeur supplémentaire pad_length avant qu'elle ne soit chiffrée. En général, le max rembourrage fournit les mêmes garanties que le fixed rembourrage pour un seul ensemble de données, tout en permettant de ne pas connaître le plus grand cleartext valeur dans la colonne. Cependant, le max remplissage peut ne pas fournir les mêmes garanties de confidentialité que le fixed remplissage entre les mises à jour, car la valeur la plus élevée des ensembles de données individuels peut être différente.

Nous vous recommandons de sélectionner une valeur supplémentaire pad_length de 0 lorsque vous utilisez le max rembourrage. Cette longueur permet à toutes les valeurs d'avoir la même taille que la plus grande valeur de la colonne. Une valeur supérieure à cette valeur ne fera qu'augmenter la charge de stockage.

Si le plus grand cleartext la valeur est connue pour une colonne donnée, nous vous recommandons d'utiliser plutôt le type fixed pad. L'utilisation fixed du rembourrage assure la cohérence entre les ensembles de données mis à jour. L'maxutilisation du remplissage permet de compléter chaque sous-ensemble de données à la valeur la plus élevée du sous-ensemble.

Exemple de données pour un sealed column

Voici un exemple d'ensemble de données d'entrée et de sortie pour un sealed colonne avec les paramètres à reproduire. D'autres paramètres de collaboration tels que allowCleartextallowJoinsOnColumnsWithDifferentNames, et allowDuplicates n'ont pas d'impact sur les résultats et peuvent être définis au fur true et à mesure que false vous essayez de reproduire localement. Bien qu'il s'agisse des paramètres de base à reproduire, le sealed La colonne n'est pas déterministe et les valeurs changent à chaque fois. L'objectif est d'afficher les octets entrants par rapport aux octets sortants. Les pad_length valeurs d'exemple ont été choisies intentionnellement. Ils montrent que le fixed rembourrage donne les mêmes valeurs que le max rembourrage avec les pad_length paramètres minimaux recommandés ou lorsqu'un rembourrage supplémentaire est souhaité.

Exemple de secret partagé : wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Exemple d'identifiant de collaboration : a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

Type de pad none

Type de tampon fixed (exemple 1)

Dans cet exemple, pad_length c'est 62 et la plus grande entrée est 62 octets.

Type de tampon fixed (exemple 2)

Dans cet exemple, pad_length c'est 162 et la plus grande entrée est 62 octets.

Type de tampon max (exemple 1)

Dans cet exemple, la valeur pad_length est 0 et la plus grande entrée est de 62 octets.

Type de tampon max (exemple 2)

Dans cet exemple, pad_length c'est 100 et la plus grande entrée est 62 octets.

Résolution des problèmes sealed columns

Pourquoi le texte chiffré se trouve-t-il dans mon sealed colonnes plusieurs fois supérieures à la taille du cleartext ça y est entré ?

Cela dépend de plusieurs facteurs. D'une part, du texte chiffré dans un Cleartext la longueur de la colonne est toujours d'au moins 91 octets. Si vos données d'entrée étaient petites (par exemple, l'âge des clients), elles indiqueront une augmentation significative de leur taille. Ensuite, si vous avez preserveNulls défini ce paramètre sur false et que vos données d'entrée contenaient un grand nombre de null valeurs, chacune de ces null valeurs aura été transformée en 91 octets de texte chiffré. Enfin, si vous utilisez le rembourrage, par définition, des octets sont ajoutés au cleartext données avant qu'elles ne soient cryptées.

La plupart de mes données se trouvent dans un sealed la colonne est vraiment petite et je dois utiliser un rembourrage. Puis-je simplement supprimer les grandes valeurs et les traiter séparément pour économiser de l'espace ?

Nous vous déconseillons de supprimer des valeurs importantes et de les traiter séparément. Cela modifie les garanties de confidentialité fournies par le client de chiffrement C3R. En tant que modèle de menace, supposons qu'un observateur puisse voir les deux ensembles de données chiffrés. Si l'observateur constate qu'une colonne d'un sous-ensemble de données est plus ou moins remplie qu'un autre sous-ensemble, il peut tirer des conclusions sur la taille des données de chaque sous-ensemble. Supposons, par exemple, qu'une fullName colonne soit complétée à un total de 40 octets dans un fichier et à 800 octets dans un autre fichier. Un observateur peut supposer qu'un ensemble de données contient le nom le plus long du monde (747 octets).

Dois-je fournir un rembourrage supplémentaire lorsque j'utilise ce type de max rembourrage ?

Non Lorsque vous utilisez le max rembourrage, nous recommandons que lepad_length, également connu sous le nom de rembourrage supplémentaire au-delà de la plus grande valeur de la colonne, soit défini sur 0.

Puis-je simplement en choisir une grande pad_length lorsque j'utilise un fixed rembourrage pour ne pas me demander si la plus grande valeur convient ?

Oui, mais la grande longueur du pad est inefficace et utilise plus d'espace de stockage que nécessaire. Nous vous recommandons de vérifier la valeur la plus élevée et de la pad_length définir sur cette valeur.

Comment savoir si j'ai besoin des garanties cryptographiques fournies par preserveNulls ?

Malheureusement, la réponse est que cela dépend. Au minimum, Informatique cryptographique pour Clean Rooms il convient de vérifier la manière dont le preserveNulls paramètre protège vos données. Cependant, nous vous recommandons de faire référence aux exigences de votre organisation en matière de traitement des données et à tout contrat applicable à la collaboration correspondante.

Pourquoi dois-je supporter la surcharge de base64 ?

Pour garantir la compatibilité avec les formats de fichiers tabulaires tels que CSV, le codage base64 est nécessaire. Bien que certains formats de fichiers tels que Parquet peut prendre en charge les représentations binaires des données, il est important que tous les participants à une collaboration représentent les données de la même manière pour garantir des résultats de requête corrects.

Résolution des problèmes liés aux augmentations imprévues de la taille du texte chiffré

Supposons que vous ayez chiffré vos données et que la taille des données obtenues soit étonnamment importante. Les étapes suivantes peuvent vous aider à identifier l'endroit où l'augmentation de taille s'est produite et les mesures que vous pouvez prendre, le cas échéant.

Identification de l'endroit où l'augmentation de taille s'est produite

Avant de pouvoir déterminer pourquoi vos données chiffrées sont nettement plus volumineuses que vos cleartext données, vous devez d'abord identifier où se situe l'augmentation de taille. Cleartext les colonnes peuvent être ignorées en toute sécurité car elles sont inchangées. Regardez le reste fingerprint and sealed colonnes, et choisissez-en une qui semble significative.

Identifier la raison pour laquelle l'augmentation de taille s'est produite

A fingerprint colonne ou sealed la colonne peut contribuer à l'augmentation de la taille.

L'augmentation de taille provient-elle d'un fingerprint colonne ?

Si la colonne qui contribue le plus à l'augmentation du stockage est fingerprint colonne, cela est probablement dû au fait que cleartext les données sont petites (par exemple, l'âge du client). Chaque résultat fingerprint le texte chiffré a une longueur de 52 octets. Malheureusement, rien ne peut être fait à ce sujet sur une column-by-column base solide. Pour plus d'informations, voir Frais généraux de base pour fingerprint columns les détails de cette colonne, notamment son impact sur les exigences de stockage.

L'autre cause possible de l'augmentation de la taille d'un fingerprint la colonne est le paramètre de collaboration,preserveNulls. Si le paramètre de collaboration pour preserveNulls est désactivé (paramètre par défaut), toutes les null valeurs dans fingerprint les colonnes seront devenues 52 octets de texte chiffré. Rien ne peut être fait pour cela dans le cadre de la collaboration actuelle. Le preserveNulls paramètre est défini au moment de la création d'une collaboration et tous les collaborateurs doivent utiliser le même paramètre pour garantir des résultats de requête corrects. Pour plus d'informations sur ce preserveNulls paramètre et sur l'impact de son activation sur les garanties de confidentialité de vos données, consultezInformatique cryptographique pour Clean Rooms.

L'augmentation de taille provient-elle d'un sealed colonne ?

Si la colonne qui contribue le plus à l'augmentation du stockage est sealed colonne, quelques détails pourraient contribuer à l'augmentation de la taille.

Si l'icône cleartext les données sont petites (par exemple, l'âge du client), chacune résultant sealed le texte chiffré a une longueur d'au moins 91 octets. Malheureusement, rien ne peut être fait à ce sujet. Pour plus d'informations, voir Frais généraux de base pour sealed columns les détails de cette colonne, notamment son impact sur les exigences de stockage.

La deuxième cause principale de l'augmentation du stockage dans sealed les colonnes sont du rembourrage. Le rembourrage ajoute des octets supplémentaires au cleartext avant qu'il ne soit chiffré pour masquer la taille des valeurs individuelles d'un ensemble de données. Nous vous recommandons de définir le rembourrage à la valeur minimale possible pour votre ensemble de données. Au minimum, le pad_length fixed remplissage doit être défini de manière à inclure la plus grande valeur possible dans la colonne. Tout paramètre supérieur n'ajoute aucune garantie de confidentialité supplémentaire. Par exemple, si vous savez que la plus grande valeur possible d'une colonne peut être de 50 octets, nous vous recommandons de la pad_length définir sur 50 octets. Toutefois, si le sealed la colonne utilise le max remplissage, nous vous recommandons de définir la valeur sur pad_length 0 octet. Cela est dû au fait que le max rembourrage fait référence au rembourrage supplémentaire au-delà de la plus grande valeur de la colonne.

La dernière cause possible de l'augmentation de la taille d'un sealed la colonne est le paramètre de collaboration,preserveNulls. Si le paramètre de collaboration pour preserveNulls est désactivé (paramètre par défaut), toutes les null valeurs dans sealed les colonnes seront devenues 91 octets de texte chiffré. Rien ne peut être fait pour cela dans le cadre de la collaboration actuelle. Le preserveNulls paramètre est défini au moment de la création d'une collaboration, et tous les collaborateurs doivent utiliser le même paramètre pour garantir des résultats de requête corrects. Pour plus d'informations sur ce paramètre et sur l'impact de son activation sur les garanties de confidentialité de vos données, consultezInformatique cryptographique pour Clean Rooms.