Split-trust Encryption Tool

Lo strumento di crittografia con attendibilità divisa (STET) fornisce un meccanismo di distribuzione che consente il trasferimento sicuro dei dati delle chiavi in entrata e in uscita da Google Cloud in modo verificabile e criptato per proteggerli dagli addetti ai lavori di Google Cloud .

Questo risultato viene ottenuto utilizzando due sistemi di gestione delle chiavi (KMS), uno interno aGoogle Cloude l'altro esterno. Anche se un KMS è compromesso, il secondo è attivo per contribuire a mantenere privati i tuoi dati.

Di seguito è riportata una serie di esempi che coinvolgono i dati trasmessi a Cloud Storage e calcolati utilizzando le VM Compute Engine. Gli esempi illustrano i diversi livelli di sicurezza per spiegare come STET si inserisce nel flusso di sicurezza.

Livello 1: Cloud Storage

Un diagramma di flusso dal calcolo on-premise a Compute Engine

Quando importi i dati in Google Cloud, puoi utilizzare Cloud Storage per mettere a disposizione i dati per i tuoi carichi di lavoro cloud. Puoi caricare i dati dai tuoi ambienti di calcolo on-premise in un bucket Cloud Storage, concedere al tuo carico di lavoro l'accesso a quel bucket e fare in modo che il carico di lavoro (o più carichi di lavoro) consumi questi dati quando necessario. Questa strategia evita la complessità di creare una connessione attiva direttamente al carico di lavoro per inviargli i dati di cui necessita.

Cloud Storage cripta sempre i dati at-rest. Tuttavia, se affidi a Cloud Storage la crittografia per tuo conto, questo avrà accesso ai dati non criptati (testo non cifrato) prima della crittografia, nonché alle chiavi di crittografia utilizzate per creare i dati criptati (testo cifrato). A seconda del tuo modello di minacce, potrebbe essere opportuno criptare i dati prima di inviarli a Cloud Storage, in modo che Cloud Storage non abbia mai visibilità al testo non cifrato.

Livello 2: crittografia lato client

Un diagramma di flusso dal calcolo on-premise a Compute Engine

Quando utilizzi la crittografia lato client, cripta i dati prima che vengano caricati in Cloud Storage e decriptali solo dopo averli scaricati nel tuo carico di lavoro. Di conseguenza, Cloud Storage ha accesso al testo cifrato, ma non al testo non cifrato. Cloud Storage aggiunge un altro livello di crittografia prima di archiviarli, ma la protezione principale dei dati è la crittografia eseguita prima del caricamento.

Con questo approccio, ora devi concedere al carico di lavoro l'accesso alla chiave di crittografia necessaria per decriptare i dati. Si tratta di un'operazione potenzialmente difficile, in quanto la chiave di crittografia consente di rimuovere il livello di crittografia originale e ottenere visibilità sui dati.

Livello 3: gestione delle chiavi esterne

Un diagramma di flusso dal calcolo on-premise a Compute Engine con un gestore delle chiavi esterno

Un approccio comune a questo problema di gestione delle chiavi è utilizzare un servizio di gestione delle chiavi (KMS) dedicato che gestisce le chiavi e l'accesso a queste. A ogni tentativo di crittografia o decrittografia, deve essere inviata una richiesta al KMS. KMS ha la capacità di concedere l'accesso in base a vari criteri per garantire che solo le parti appropriate siano in grado di decriptare i dati.

I sistemi KMS hanno la possibilità di richiedere una serie di criteri diversi prima di autorizzare l'accesso alla chiave di crittografia, ma in genere richiedono una credenziale che corrisponda a un criterio configurato su KMS. Pertanto, qualsiasi interessato in possesso di questa credenziale potrà accedere alla chiave di crittografia e decriptare i dati.

Livello 4: Confidential Computing

Un diagramma di flusso dal calcolo on-premise a Compute Engine con un gestore delle chiavi esterno e l'attestazione

Le istanze Confidential VM vengono eseguite con la memoria criptata, offrendo protezioni aggiuntive contro l'accesso indesiderato ai dati durante l'uso. Per molti modelli di minacce, le istanze Confidential VM sono più attendibili di quelle standard, il che consente di usarle per i workload sensibili.

Se il tuo modello di minacce si basa su Confidential Computing, un problema è assicurarti che un workload venga eseguito in un'istanza Confidential VM. L'attestazione remota è un mezzo attraverso il quale il workload può dimostrare a una parte remota di essere eseguito in un'istanza VM Confidential e può confermare molte altre proprietà relative alla configurazione e all'ambiente del workload. Poiché le attestazioni vengono generate dalla piattaforma, il carico di lavoro non può creare attestazioni false che non riflettono il suo ambiente reale.

Un KMS può richiedere e valutare queste attestazioni prima di consentire l'accesso alle chiavi. Questo requisito contribuisce a garantire che solo il carico di lavoro previsto sia autorizzato a decriptare i dati, anche se le credenziali normali sono compromesse.

Livello 5: attendibilità divisa

Un diagramma di flusso dal calcolo on-premise a Compute Engine con attendibilità suddivisa

Quando utilizzi un singolo KMS, questo ha il controllo esclusivo sulle chiavi di crittografia. Se l'operatore KMS acquisisse il testo cifrato dei tuoi dati criptati, avrebbe tutto il necessario per decriptarlo in testo normale. Sebbene questo rischio possa essere accettabile se la KMS è gestita da un'entità completamente attendibile, alcuni modelli di minacce rendono necessario rimuovere il controllo unilaterale dalla KMS.

Con STET, hai la possibilità di suddividere questa attendibilità tra due sistemi KMS, senza che nessuno dei due abbia informazioni sufficienti per decriptare i tuoi dati. Per decriptare i dati, è necessaria la collusione tra entrambi gli operatori KMS (e l'accesso al testo cifrato).

Se utilizzi una VM con accesso protetto, STET semplifica anche la crittografia e la decrittografia dei dati utilizzando le chiavi archiviate in un KMS che richiede attestazioni.

Nel complesso, STET contribuisce a garantire che le uniche entità che hanno accesso ai tuoi dati in testo non cifrato siano l'autore dei dati (ad esempio un sistema on-premise) e il consumatore dei dati (ad esempio un carico di lavoro in esecuzione in un'istanza Confidential VM).

Per ulteriori informazioni sull'utilizzo di STET, consulta il repository GitHub e la guida rapida.

Confidential Space con STET

Un diagramma di flusso dal calcolo on-premise a Compute Engine con attendibilità suddivisa e Confidential Space

Se utilizzi Confidential Space, STET può utilizzare il token di attestazione di Confidential Space come prova dell'attestazione quando accede alla chiave di crittografia della chiave (KEK) archiviata in Cloud KMS.

STET gestisce l'accesso alle chiavi Cloud KMS per il tuo carico di lavoro e supporta l'utilizzo di Confidential Space per eseguire l'attestazione per il flusso di lavoro di crittografia, il flusso di lavoro di decrittografia o entrambi i flussi di lavoro di crittografia e decrittografia.

Puoi creare una configurazione STET che includa informazioni quali il nome del pool di identità del workload (WIP), gli URI Cloud KMS e le informazioni sulla decrittografia. STET utilizza poi queste informazioni per integrarsi nella configurazione di Confidential Space.

Per saperne di più, consulta il repository GitHub e la guida all'integrazione di Confidential Space.