Semplifica la crittografia dei dati con lo strumento di crittografia Split-Trust

Per Google, la crittografia end-to-end ha lo scopo di ottenere una visione semplice: che i dati dei clienti siano protetti in modo verificabile da qualsiasi accesso non autorizzato del cliente non appena lascia il data center del cliente e arriva in Google Cloud. Il nostro obiettivo è fornire un meccanismo di distribuzione sicura delle chiavi che consenta il traffico in entrata e in uscita dalle chiavi in entrata e in uscita in Google Cloud, in modo proveniente e crittograficamente protetto dagli addetti ai lavori di Google Cloud.

L'ambito di questa funzionalità sono i dati trasmessi a Cloud Storage e calcolati mediante VM di Compute Engine. Questa panoramica riguarda le tecnologie di crittografia esistenti per Cloud Storage, Compute Engine e gestori di chiavi esterni. Descrive le loro lacune per quanto riguarda la nostra vision e il modo in cui questa funzionalità contribuisce a colmare queste lacune.

Cloud Storage

Quando importi dati in Google Cloud, puoi utilizzare Cloud Storage per renderli disponibili ai carichi di lavoro cloud. Puoi caricare i dati da ambienti di computing on-premise in un bucket Cloud Storage, concedere al carico di lavoro l'accesso a quel bucket e fare in modo che il carico di lavoro (o più carichi di lavoro) li consumi quando necessario. Questa strategia evita la complessità di creare una connessione attiva direttamente al carico di lavoro per inviargli i dati di cui ha bisogno.

Cloud Storage cripta sempre i dati at-rest. Tuttavia, se affidi a Cloud Storage la crittografia per te, questa ha necessariamente accesso ai dati non criptati (testo non crittografato) prima della crittografia, nonché alle chiavi di crittografia utilizzate per creare i dati criptati (testo crittografato). 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à sul testo normale.

Crittografia lato client

Se utilizzi la crittografia lato client, i dati vengono criptati prima di essere caricati in Cloud Storage e vengono decriptati solo dopo essere stati scaricati nel carico di lavoro. Di conseguenza, Cloud Storage ha accesso al testo crittografato, ma non al testo normale. Cloud Storage aggiunge un altro livello di crittografia prima dell'archiviazione, ma la protezione principale dei dati è la crittografia eseguita prima del caricamento.

Con questo approccio, ora devi consentire al carico di lavoro di accedere alla chiave di crittografia necessaria per decriptare i dati. Anche questa è un'attività potenzialmente difficile, in quanto la chiave di crittografia consente di rimuovere il livello originale di crittografia e di ottenere visibilità dei dati.

Gestione delle chiavi esterna

Un approccio comune a questo problema di gestione delle chiavi consiste nell'utilizzare un Key Management Service (KMS) dedicato che detiene le chiavi e ne gestisce l'accesso. A ogni tentativo di crittografia o decriptazione deve essere inviata una richiesta al KMS. Il KMS ha la possibilità di concedere l'accesso in base a vari criteri per garantire che solo le parti appropriate possano decriptare i dati.

I sistemi KMS hanno la capacità 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 sul KMS. Pertanto, chiunque sia in possesso di tale credenziale potrà accedere alla chiave di crittografia e decriptare i dati.

Confidential Computing

Con l'offerta Confidential Virtual Machine (Confidential VM) di Google Cloud, le VM di Compute Engine vengono eseguite con la memoria criptata, fornendo protezioni aggiuntive contro gli accessi involontari ai dati durante l'utilizzo. Per molti modelli di minacce, le Confidential VM sono più affidabili delle VM standard, quindi possono essere utilizzate per carichi di lavoro sensibili.

Se il tuo modello di minaccia si basa su Confidential Computing, un problema è garantire che un carico di lavoro sia in esecuzione in una Confidential VM. Attestazione remota è un mezzo tramite il quale il carico di lavoro può dimostrare a una parte remota di essere effettivamente in esecuzione in una VM riservata e confermare molte altre proprietà sulla configurazione e l'ambiente del carico di lavoro. Poiché le attestazioni sono generate dalla piattaforma, il carico di lavoro non può creare false attestazioni che non includano il suo ambiente effettivo.

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

Lo strumento di crittografia Split-Trust (STET) facilita la crittografia e la decriptazione dei dati utilizzando chiavi archiviate in un KMS che richiede attestazioni.

Suddividi trust

Quando si utilizza un singolo KMS, quest'ultimo ha il controllo esclusivo sulle chiavi di crittografia. Se l'operatore KMS acquisisse il testo crittografato dei tuoi dati criptati, avrebbe tutto il necessario per decriptarlo nel testo non crittografato. 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 suddividere questo trust tra due sistemi KMS e nessuno dei due dispone di informazioni sufficienti per decriptare i tuoi dati. Richiedere la colluzione tra gli operatori KMS (e l'accesso al testo crittografato) per decriptare i dati.

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 consumatore dei dati (ad esempio, un carico di lavoro in esecuzione in una VM riservata).

Per ulteriori informazioni sull'utilizzo dello strumento di crittografia di Split-Trust, consulta il repository GitHub e la guida rapida.