Lo strumento di crittografia Split-Trust (STET) consente il trasferimento sicuro dei dati delle chiavi in e fuori da Google Cloud in modo verificabile e protetto crittograficamente da insider di Google Cloud .
Ciò si ottiene utilizzando due sistemi di gestione delle chiavi (KMS), uno interno a Google Cloude l'altro esterno. Anche se un KMS viene compromesso, il secondo è in vigore per contribuire a mantenere privati i tuoi dati.
Di seguito sono riportati una serie di esempi che riguardano i dati trasmessi a Cloud Storage e calcolati utilizzando le VM di Compute Engine. Gli esempi illustrano livelli di sicurezza crescenti per spiegare come STET si inserisce nel tuo flusso di sicurezza.
Livello 1: Cloud Storage
Quando importi i dati in Google Cloud, puoi utilizzare Cloud Storage per renderli disponibili per i tuoi carichi di lavoro cloud. Puoi caricare i dati dai tuoi ambienti di computing on-premise in un bucket Cloud Storage, concedere al tuo workload l'accesso a questo bucket e fare in modo che il workload (o più workload) utilizzi questi dati quando necessario. Questa strategia evita la complessità di creare una connessione attiva direttamente al workload per inviargli i dati di cui ha bisogno.
Cloud Storage cripta sempre i dati at-rest. Tuttavia, se affidi a Cloud Storage la crittografia, questo servizio ha accesso ai dati non criptati (testo non criptato) prima della crittografia, nonché alle chiavi di crittografia utilizzate per creare i dati criptati (testo criptato). A seconda del modello di minaccia, potrebbe essere opportuno criptare i dati prima di inviarli a Cloud Storage, in modo che Cloud Storage non abbia mai visibilità del testo non criptato.
Livello 2: crittografia lato client
Quando utilizzi la crittografia lato client, cripti i dati prima di caricarli in Cloud Storage e li decripti solo dopo averli scaricati nel tuo workload. Di conseguenza, Cloud Storage ha accesso al testo cifrato, ma non al testo non crittografato. 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 workload l'accesso alla chiave di crittografia necessaria per decriptare i dati. Si tratta di un'attività potenzialmente difficile, in quanto la chiave di crittografia consente di rimuovere il livello originale di crittografia e ottenere visibilità sui dati.
Livello 3: gestione delle chiavi esterne
Un approccio comune a questo problema di gestione delle chiavi è l'utilizzo di un servizio di gestione delle chiavi (KMS) dedicato che contiene le chiavi e gestisce l'accesso. A ogni tentativo di crittografia o decrittografia, deve essere inviata una richiesta al KMS. Il KMS ha la capacità di concedere l'accesso in base a vari criteri per garantire che solo le parti appropriate possano decriptare i dati.
I sistemi KMS possono richiedere diversi criteri prima di autorizzare l'accesso alla chiave di crittografia, ma in genere richiedono una credenziale che corrisponda a un criterio configurato nel KMS. Pertanto, chiunque sia in possesso di queste credenziali potrà accedere alla chiave di crittografia e decriptare i dati.
Livello 4: Confidential Computing
Le istanze Confidential VM vengono eseguite con la memoria criptata, fornendo protezioni aggiuntive contro l'accesso involontario ai dati durante l'utilizzo. Per molti modelli di minaccia, le istanze Confidential VM sono più affidabili delle istanze standard, il che consente di utilizzarle per i carichi di lavoro sensibili.
Se il tuo modello di minaccia si basa su Confidential Computing, un problema è garantire che un workload venga eseguito in un'istanza Confidential VM. L'attestazione remota è un mezzo con cui il workload può dimostrare a una parte remota di essere in esecuzione in un'istanza Confidential VM e può confermare molte altre proprietà relative alla configurazione e all'ambiente del workload. Poiché le attestazioni vengono generate dalla piattaforma, il workload non può creare attestazioni false che non riflettono il suo ambiente effettivo.
Un KMS può richiedere e valutare queste attestazioni prima di consentire l'accesso alle chiavi. Questo requisito contribuisce a garantire che solo il workload previsto possa decriptare i dati, anche se le credenziali normali sono compromesse.
Livello 5: fiducia suddivisa
Quando utilizzi un singolo KMS, questo ha il controllo esclusivo sulle chiavi di crittografia. Se l'operatore KMS dovesse acquisire il testo cifrato dei tuoi dati criptati, avrebbe tutto il necessario per decriptarli nel testo non criptato. Sebbene questo rischio possa essere accettabile se il KMS è gestito da un'entità completamente attendibile, alcuni modelli di minaccia creano la necessità di rimuovere il controllo unilaterale dal KMS.
Con STET, hai la possibilità di dividere questa attendibilità tra due sistemi KMS, in modo che nessuno dei due disponga di informazioni sufficienti per decriptare i tuoi dati. Per decriptare i dati, sarebbe necessaria la collusione tra entrambi gli operatori KMS (e l'accesso al testo criptato).
Se utilizzi Confidential VM, STET facilita anche la crittografia e la decrittografia dei dati utilizzando 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 crittografato siano l'origine dei dati (ad esempio, un sistema on-premise) e il consumer dei dati (ad esempio, un workload in esecuzione in un'istanza Confidential VM).
Per maggiori informazioni sull'utilizzo di STET, consulta il repository GitHub e la guida rapida.
Confidential Space con STET
Se utilizzi Confidential Space, STET può utilizzare il token di attestazione di Confidential Space come prova di 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 workload 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.
Puoi creare una configurazione STET che includa informazioni come il nome del pool di identità del workload (WIP), gli URI Cloud KMS e le informazioni di decriptazione. STET utilizza quindi queste informazioni per integrarle nella configurazione di Confidential Space.
Per maggiori informazioni, consulta il repository GitHub e la Guida all'integrazione di Confidential Space.