Concetti di crittografia

Flusso di alto livello

• Controlli una chiave principale nel tuo cloud che OpenAI non vede mai

• La tua chiave principale viene utilizzata per crittografare le chiavi di crittografia dei dati (DEK) utilizzate da OpenAI

• OpenAI utilizza le DEK per crittografare i tuoi dati inattivi. Una DEK viene crittografata dalla tua chiave principale, generando una eDEK (DEK crittografata), che viene archiviata insieme ai tuoi dati

• Per leggere i dati, OpenAI prende l'eDEK, richiede al tuo KMS di decifrarla per ottenere la DEK e quindi decifra i tuoi dati

Come funziona la crittografia EKM?

Consulta il nostro articolo per informazioni dettagliate: Panoramica di OpenAI Enterprise Key Management (EKM)

OpenAI conserva le mie DEK?

No: archiviamo le DEK crittografate (eDEK), generate dal tuo KMS. Per decrittografare i dati, chiediamo al tuo KMS di decrittografare l'eDEK nella DEK.

OpenAI memorizza nella cache le mie DEK?

Sì, solo in memoria. Questo serve a migliorare le prestazioni, evitando di interrogare il tuo KMS a ogni richiesta di crittografia/decrittografia dei dati. Le DEK non vengono mai scritte nell'archiviazione.

Autorizzazioni cloud

Quali autorizzazioni avrà OpenAI sul mio KMS?

Solo le autorizzazioni che ci concedi tramite la policy che imposti. Ci servono almeno le operazioni di crittografia/decrittografia. Crea anche una nuova chiave nel tuo cloud KMS per OpenAI invece di riutilizzare chiavi esistenti destinate alla produzione.

Quando OpenAI ottiene le autorizzazioni per accedere al mio KMS?

Tutti questi passaggi devono essere stati eseguiti: 1. l'identità di OpenAI deve essere stata riconosciuta (tramite policy di attendibilità, identità del carico di lavoro, ecc. a seconda del provider cloud), 2. deve essere stata creata una policy per accedere al KMS e 3. all'identità di OpenAI deve essere stata assegnata l'autorizzazione ad accedere alla policy. Se il KMS viene creato senza che tutti questi passaggi siano stati eseguiti, OpenAI non avrà accesso.

Devo archiviare la mia chiave principale nel mio cloud?

No: sta a te decidere come gestire la tua chiave principale. Puoi avere una soluzione gestita nel cloud oppure una soluzione esterna, in cui la tua chiave viene memorizzata separatamente. OpenAI deve semplicemente chiamare le operazioni di crittografia/decrittografia sul tuo KMS: il modo in cui la chiave principale esegue effettivamente la crittografia/decrittografia è un dettaglio di implementazione che per noi rimane opaco.

Ciclo di vita della chiave

Rotazione DEK/eDEK (controllata da OpenAI)

Con quale frequenza vengono ruotate le DEK/eDEK?

Ogni 24 ore nel percorso di crittografia (richiesta di una coppia di chiavi DEK/eDEK)

Ogni 1 ora per il percorso della chiave di decrittografia (DEK -> eDEK)

Devo fare qualcosa quando la DEK cambia?

No, la rotazione di DEK/eDEK avviene all'interno di OpenAI. Finché la tua chiave principale rimane valida, tutti le eDEK crittografate con la tua chiave principale possono continuare a essere decrittografate nella DEK, che viene poi utilizzata per decrittografare i tuoi dati.

Rotazione e revoca della chiave principale (controllata da te)

Con quale frequenza avvengono la rotazione delle chiavi e la revoca delle chiavi?

Questo è determinato da te, poiché OpenAI non ha visibilità sulla tua chiave principale.

Qual è la differenza tra la rotazione delle chiavi e la revoca delle chiavi?

La revoca delle chiavi rimuove l'accesso ai dati crittografati con chiavi meno recenti. La rotazione delle chiavi crittografa i dati con una nuova chiave, ma mantiene l'accesso in lettura ai dati meno recenti.

Cosa succede se revoco la mia chiave principale?

Se una chiave viene revocata o i permessi vengono rimossi, l'area di lavoro diventerà inutilizzabile una volta scadute le chiavi memorizzate nella cache. A quel punto, OpenAI non può più decrittografare i dati archiviati né crittografare nuovi dati. Di fatto, i dati sono “frammentati“.

Quanto rapidamente ha effetto la revoca?

OpenAI memorizza nella cache le DEK in memoria per garantire prestazioni e resilienza. La revoca entra generalmente in vigore entro un'ora, una volta scadute le chiavi memorizzate nella cache e non riuscita la nuova convalida.

La revoca può essere testata in modo sicuro?

Testare la revoca in un'area di lavoro di produzione non è consigliato perché renderà i dati esistenti permanentemente inaccessibili. Tuttavia, i clienti possono (e dovrebbero) testare la revoca in un ambiente sandbox per verificare il comportamento corretto e convalidare i propri presupposti di fiducia.

Se una chiave viene revocata definitivamente, è possibile recuperare l'area di lavoro associando una nuova chiave?

No. Una volta persa la chiave, i dati sono irrecuperabili per progettazione. L'unica soluzione è creare una nuova area di lavoro.

Cosa dovremmo fare se un'area di lavoro diventa inaccessibile a causa di modifiche alle chiavi?

La correzione prevista consiste nel creare una nuova area di lavoro. L'aggiornamento del KMS non recupererà i dati esistenti.

Qual è il piano di ripristino se decidiamo di non utilizzare più CMEK?

Attualmente, non esiste alcun piano di rollback. Una volta creata un'area di lavoro con CMEK, tutti i dati associati vengono crittografati utilizzando chiavi gestite dal cliente e non è possibile accedervi senza di esse. L'unico modo per interrompere l'utilizzo di CMEK è creare una nuova area di lavoro: i dati esistenti crittografati rimarranno permanentemente inaccessibili.

Cosa succede quando ruoto la chiave principale?

Verrà generato nuovo materiale crittografico per la crittografia, quindi le nuove richieste di crittografia utilizzeranno la nuova chiave. Tuttavia, l'identificatore KMS (ARN o nome chiave) rimane invariato e i dati precedenti sono ancora decrittografabili. Molti provider cloud offrono la rotazione automatica delle chiavi (AWS, GCP, Azure).

OpenAI crittografa nuovamente i dati meno recenti quando ruoto la mia chiave principale?

No. Il nuovo materiale crittografico verrà utilizzato solo per crittografare nuovi dati.

Quanto tempo ci vuole perché la rotazione o la revoca della chiave abbiano effetto?

1 ora. Questo perché le DEK/eDEK vengono memorizzate nella cache in memoria e convalidiamo nuovamente queste voci con il tuo KMS ogni ora.

Modifica dell'identificatore KMS

La modifica dell'identificatore KMS è una revoca o una rotazione della chiave?

Revoca della chiave. Una chiave non può decrittografare dati crittografati da un'altra chiave.

OpenAI può aiutarmi a cambiare l'identificatore KMS per la mia area di lavoro ChatGPT?

Se confermi che intendi revocare la tua chiave, possiamo aiutarti a farlo per un'area di lavoro ChatGPT. Tieni presente che quando l'ARN KMS viene aggiornato, i dati meno recenti rimarranno inaccessibili; quindi, dopo la modifica, ti ritroverai con un insieme di dati accessibili e inaccessibili.

OpenAI può aiutarmi a cambiare l'identificatore KMS per un progetto API?

Se stai utilizzando l'API, questa semplifica l'archiviazione e la creazione di nuovi progetti. Ti invitiamo quindi ad archiviare il progetto i cui dati non sono accessibili, registrare una nuova configurazione EKM con OpenAI e creare un nuovo progetto API con la nuova chiave KMS.

E se volessi cambiare regolarmente il mio identificatore KMS autonomamente?

Questo non è consigliato, poiché probabilmente non vorrai revocare regolarmente la chiave. Tuttavia, puoi comunque farlo se utilizzi un provider cloud che supporta un alias di chiave KMS (esempio AWS). Puoi registrare quell'alias della chiave KMS con OpenAI e poi, nel tuo provider cloud, puoi sostituire in qualsiasi momento l'identificatore KMS sottostante a cui punta l'alias per effettuare una revoca della chiave.

Comportamento beta vs. GA

Ci sono rischi noti o modifiche a livello di sistema quando si utilizza la versione beta della crittografia in produzione?

L'ambiente beta è funzionalmente equivalente a GA e non sono previsti passaggi di migrazione. Il rischio principale è che alcune funzionalità relative a casi limite potrebbero non supportare ancora i contenuti crittografati a causa di percorsi del codice incompleti. Questi sono rari e sono in corso di risoluzione. I dati sono completamente crittografati e protetti indipendentemente da questi potenziali problemi.

Ci saranno passaggi di migrazione da beta a GA?

No. Le aree di lavoro che utilizzano la beta della crittografia saranno automaticamente supportate in GA senza alcun intervento da parte dell'utente.

Dettagli tecnici aggiuntivi

Crittografia envelope e autorizzazioni

Dobbiamo concedere a OpenAI le autorizzazioni GenerateDataKey per EKM?

No. OpenAI richiede solo le autorizzazioni di crittografia e decrittografia sulla chiave KMS. L'autorizzazione GenerateDataKey non è necessaria per l'integrazione EKM.

OpenAI utilizza la crittografia envelope per i dati dei clienti?

Sì. OpenAI utilizza un modello di crittografia envelope:

• KMS cliente: gestisce le chiavi di crittografia della chiave (KEK). OpenAI non vede né memorizza mai le KEK.

• Infrastruttura OpenAI: genera e gestisce le chiavi di crittografia dei dati (DEK). Ogni DEK viene crittografata (avvolta) con la tua KEK prima dell'archiviazione.

• Flusso di dati:

  • I dati dei clienti sono crittografati con una DEK.

  • Quella DEK viene crittografata con la tua KEK, ottenendo una eDEK.

  • L'eDEK viene archiviata insieme ai dati crittografati.

  • Per decrittografare i dati, OpenAI richiede al KMS di decrittografare l'eDEK, recupera la DEK e decrittografa il contenuto.

Perché OpenAI ha scelto questo modello invece di lasciare che KMS gestisse sia le KEK che le DEK?

Esistono due approcci comuni alla crittografia envelope:

KEK e DEK gestite da KMS

Vantaggi: implementazione più semplice, non è necessario mantenere un'infrastruttura di crittografia.

Svantaggi: ogni richiesta di crittografia/decrittografia passa per il KMS, aumentando la latenza, i costi e introducendo un punto unico di vulnerabilità.

KEK gestite da KMS / DEK gestite da OpenAI (il nostro approccio)

Vantaggi: latenza e costi significativamente inferiori, migliore scalabilità e affidabilità, e funzionamento continuo durante interruzioni parziali di KMS (fino al TTL della cache DEK).

Svantaggi: implementazione leggermente più complessa per OpenAI.

Questo design consente a OpenAI di offrire solide garanzie di sicurezza, riducendo al minimo il rischio operativo e i costi per i clienti.

Ogni quanto vengono ruotate le DEK?

Ogni DEK viene ruotata circa ogni 60 minuti. Ciò fornisce isolamento temporale: anche se una DEK venisse in qualche modo compromessa, l'impatto sarebbe limitato ai dati crittografati all'interno di quella finestra di un'ora.

Volume delle richieste KMS e osservabilità

Vediamo molte meno richieste KMS rispetto al numero di messaggi degli utenti. Dovrebbero corrispondere questi numeri?

No, non saranno direttamente correlati.

Poiché OpenAI memorizza le DEK nella cache in memoria per motivi di prestazioni, le chiamate a KMS vengono effettuate solo quando una DEK deve essere decrittografata: non a ogni operazione di crittografia o decrittografia. Di conseguenza, puoi aspettarti:

• Meno richieste KMS rispetto alle interazioni degli utenti.

• Picchi occasionali si verificano quando le DEK memorizzate nella cache scadono (circa ogni ora) o quando è necessario accedere a dati crittografati meno recenti.

• Chiamate aggiuntive durante il recupero dei dati storici, ad esempio quando un utente continua una conversazione di lunga durata e devono essere caricate DEK precedenti.

Il numero esatto di richieste KMS dipende dallo stato della cache, dal comportamento degli utenti, dai modelli di accesso ai dati e dalla lunghezza della conversazione e non sarà quindi direttamente correlato al volume dei messaggi.