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.
# Considérations et restrictions
AWS Clean Rooms vous aide, vous et vos partenaires, à analyser et à collaborer sur des ensembles de données collectifs afin de générer de nouvelles informations sans révéler les données sous-jacentes. Vérifiez que votre configuration de collaboration des données est conforme aux exigences de confidentialité, de sécurité, légales et de conformité de votre organisation.
AWS Clean Rooms propose divers contrôles visant à améliorer la confidentialité pour votre cas d'utilisation de la collaboration sur les données :
+ [Analyses autorisées ](custom-allowed-analyses.md)
+ [Colonnes de sortie interdites ](disallowed-output-columns.md)
+ [Seuils d'agrégation minimaux ](custom-min-agg-thresholds.md)
+ [Contrôles de comparaison ](custom-comparison-controls.md)
+ [Confidentialité différentielle ](custom-diff-privacy.md)
Envisagez des contrôles de comparaison lorsque votre table contient des colonnes à faible cardinalité ou quasi-identifiantes, telles que le code postal ou la tranche d'âge, ou lorsque l'exécuteur de requêtes n'est pas totalement fiable. Pour de plus amples informations, veuillez consulter [Contrôles de comparaison](custom-comparison-controls.md).
## Hypothèses concernant des requêtes potentiellement contradictoires
Pour vous aider, ainsi que vos partenaires, à maintenir les contrôles dont vous avez besoin, AWS Clean Rooms émet les hypothèses suivantes concernant la collaboration en matière de données renforcée en matière de confidentialité :
+ Supposons que l'exécuteur de requêtes essaie d'exfiltrer des données au niveau de l'utilisateur
+ Supposons que d'autres fournisseurs de données tentent d'exfiltrer des données au niveau des utilisateurs
+ Supposons que l'exécuteur de requêtes et d'autres fournisseurs de données s'entendent pour exfiltrer les données au niveau de l'utilisateur
## Limitations
Prenez en compte les limitations suivantes :
+ L'agrégation des données imposée par des seuils d'agrégation minimaux ne permet pas à elle seule de répondre aux autres risques d'exfiltration potentiels tels que la différenciation des attaques. Pour de plus amples informations, veuillez consulter [Différencier les attaques](#custom-differencing-attacks).
+ La surface SQL pour les requêtes utilisant des seuils d'agrégation minimaux est limitée. Pour une liste complète des constructions SQL prises en charge et non prises en charge, consultez. [Fonctionnalités SQL pour des contrôles d'agrégation et de comparaison minimaux](custom-sql-capabilities.md)
+ Les seuils d'agrégation minimaux et les contrôles de comparaison ne fonctionnent pas actuellement avec la confidentialité [ différentielle](custom-diff-privacy.md).
+ Le seuil d'agrégation minimum n'est pas appliqué à COUNTCOUNT(DISTINCT), ou APPROX\_COUNT\_DISTINCT fonctionne sur une seule table sans regroupement ni jointure.
## Différencier les attaques
Une attaque par différenciation se produit lorsqu'une personne exécute deux requêtes qui diffèrent d'une seule personne, puis soustrait les résultats pour isoler les données de cette personne, même si chaque requête seule ne renvoie que des agrégats.
Par exemple :
+ Requête A : WHERE département SUM (salaire) = « Ventes » → 1 000 000
+ Requête B : WHERE département SUM (salaire) = AND nom « Ventes » \! = « Jane » → 950 000
+ Différence : Jane gagne 50 000 dollars.
Chaque requête passe un contrôle de taille de groupe minimale (seuil d'agrégation minimum), mais la combinaison révèle la valeur d'une personne concernée en exécutant plusieurs requêtes. Un seuil par requête ne permet pas de prendre en compte ce vecteur d'attaque différencié.
Pour réduire le risque d'attaques de masse, adoptez des budgets d'accès aux données et des politiques de confidentialité différentielles.