Considerazioni sull'utilizzo del calcolo crittografico per Clean Rooms - AWS Clean Rooms

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Considerazioni sull'utilizzo del calcolo crittografico per Clean Rooms

Cryptographic Computing for Clean Rooms (C3R) mira a massimizzare la protezione dei dati. Tuttavia, alcuni casi d'uso potrebbero trarre vantaggio da livelli inferiori di protezione dei dati in cambio di funzionalità aggiuntive. È possibile apportare questi compromessi specifici modificando C3R dalla sua configurazione più sicura. In qualità di cliente, dovreste essere consapevoli di questi compromessi e determinare se sono appropriati per il vostro caso d'uso. I compromessi da considerare includono quanto segue:

Per ulteriori informazioni su come impostare i parametri per questi scenari, vedere. Parametri di calcolo crittografico

Consentire l'inserimento di dati misti cleartext e crittografati nelle tabelle

La crittografia di tutti i dati lato client offre la massima protezione dei dati. Tuttavia, ciò limita determinati tipi di interrogazioni (ad esempio, la funzione di SUM aggregazione). Il rischio di consentire cleartext i dati è che è possibile che chiunque abbia accesso alle tabelle crittografate possa dedurre alcune informazioni sui valori crittografati. Ciò potrebbe essere fatto eseguendo un'analisi statistica sui cleartext dati associati.

Ad esempio, immagina di avere le colonne di City eState. La City colonna è cleartext e la State colonna è crittografata. Quando vedi il valore Chicago nella City colonna, ciò ti aiuta a determinare con alta probabilità che State èIllinois. Al contrario, se una colonna è City e l'altra lo èEmailAddress, cleartext City è improbabile che a riveli qualcosa su una colonna crittografataEmailAddress.

Per ulteriori informazioni sul parametro per questo scenario, vedereParametro Allow columns cleartext.

Consentire valori ripetuti nelle fingerprint colonne

Per un approccio più sicuro, assumiamo che ogni fingerprint colonna contenga esattamente un'istanza di una variabile. Nessun elemento può essere ripetuto in una fingerprint colonna. Il client di crittografia C3R mappa questi cleartext valori in valori unici che sono indistinguibili dai valori casuali. Pertanto, è impossibile dedurre informazioni su di da questi valori casuali. cleartext

Il rischio di valori ripetuti in una fingerprint colonna è che valori ripetuti si traducano in valori ripetuti dall'aspetto casuale. Pertanto, chiunque abbia accesso alle tabelle crittografate potrebbe, in teoria, eseguire un'analisi statistica delle fingerprint colonne che potrebbe rivelare informazioni sui valori. cleartext

Ancora una volta, supponiamo che la fingerprint colonna sia State e che ogni riga della tabella corrisponda a una famiglia statunitense. Effettuando un'analisi della frequenza, si potrebbe dedurre quale stato è California e quale è Wyoming con alta probabilità. Questa inferenza è possibile perché California ha molti più residenti di. Wyoming Al contrario, supponiamo che la fingerprint colonna si trovi su un identificativo della famiglia e che ogni famiglia sia apparsa nel database da 1 a 4 volte in un database di milioni di voci. È improbabile che un'analisi della frequenza possa rivelare informazioni utili.

Per ulteriori informazioni sul parametro per questo scenario, consultaParametro Consenti duplicati.

Allentamento delle restrizioni sul modo in cui fingerprint vengono denominate le colonne

Per impostazione predefinita, si presume che quando due tabelle vengono unite utilizzando fingerprint colonne crittografate, tali colonne abbiano lo stesso nome in ogni tabella. Il motivo tecnico di questo risultato è che, per impostazione predefinita, deriviamo una chiave crittografica diversa per crittografare ogni colonna. fingerprint Tale chiave deriva da una combinazione della chiave segreta condivisa per la collaborazione e del nome della colonna. Se proviamo a unire due colonne con nomi di colonna diversi, deriviamo chiavi diverse e non possiamo calcolare un join valido.

Per risolvere questo problema, puoi disattivare la funzionalità che ricava le chiavi dal nome di ogni colonna. Quindi, il client di crittografia C3R utilizza un'unica chiave derivata per tutte le colonne. fingerprint Il rischio è che si possa eseguire un altro tipo di analisi della frequenza che potrebbe rivelare informazioni.

Usiamo nuovamente l'Stateesempio City and. Se ricaviamo gli stessi valori casuali per ogni fingerprint colonna (non incorporando il nome della colonna). New Yorkha lo stesso valore casuale nelle colonne City andState. New York è una delle poche città degli Stati Uniti in cui il City nome è uguale al State nome. Al contrario, se il set di dati ha valori completamente diversi in ogni colonna, non viene divulgata alcuna informazione.

Per ulteriori informazioni sul parametro per questo scenario, vedere. Consenti colonne con JOIN nomi diversi (parametro)

Determinazione della modalità di rappresentazione NULL dei valori

L'opzione disponibile è se elaborare i valori crittograficamente (cifrare e HMAC) come qualsiasi altro NULL valore. Se non elaborate NULL i valori come qualsiasi altro valore, è possibile che vengano rivelate delle informazioni.

Ad esempio, supponiamo che NULL nella Middle Name colonna in si cleartext indichino persone senza secondi nomi. Se non si crittografano questi valori, si rivelano quali righe della tabella crittografata vengono utilizzate per le persone senza secondi nomi. Queste informazioni potrebbero essere un segnale identificativo per alcune persone in alcune popolazioni. Ma se si elaborano NULL valori crittograficamente, alcune query SQL agiscono in modo diverso. Ad esempio, le GROUP BY clausole non fingerprint NULL raggrupperanno i valori in colonne. fingerprint

Per ulteriori informazioni sul parametro per questo scenario, vedere. Parametro NULL Mantiene i valori