Per Google, la crittografia end-to-end ha lo scopo di ottenere una visione semplice: che i dati dei clienti siano verificabili 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 delle chiavi sicure che consenta il traffico in entrata e in uscita dalle chiavi sicure all'interno e all'esterno di Google Cloud in un modo verificabile e crittograficamente protetto dagli utenti interni di Google Cloud.
L'ambito di questa funzionalità sono i dati trasmessi a Cloud Storage e calcolati con le VM di Compute Engine. Questa panoramica illustra le tecnologie di crittografia esistenti per Cloud Storage, Compute Engine e gestori di chiavi esterni. Descrive le sue lacune in merito alla nostra vision e al modo in cui la funzionalità contribuisce a colmare queste lacune.
Cloud Storage
Durante l'importazione di dati in Google Cloud, puoi utilizzare Cloud Storage per rendere i dati 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 carico di lavoro l'accesso a tale bucket e fare in modo che il carico di lavoro (o più carichi di lavoro) li utilizzi 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 l'esecuzione della crittografia per te, questo avrà necessariamente accesso ai dati non criptati (testo non crittografato) 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à con testo non crittografato.
Crittografia lato client
Quando utilizzi la crittografia lato client, i dati vengono criptati prima di essere caricati in Cloud Storage e decriptati solo dopo essere stati scaricati nel carico di lavoro. Di conseguenza, Cloud Storage ha accesso al testo di crittografia, ma non al testo normale. Cloud Storage aggiunge un ulteriore 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. Si tratta di un'attività potenzialmente difficile, in quanto la chiave di crittografia offre la possibilità di rimuovere il livello di crittografia originale e ottenere visibilità sui dati.
Gestione esterna chiavi
Un approccio comune a questo problema di gestione delle chiavi consiste nell'utilizzare un servizio di gestione delle chiavi (KMS) dedicato che contiene 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 siano in grado di decriptare i dati.
I sistemi KMS possono richiedere una serie di criteri diversi prima di autorizzare l'accesso alla chiave di crittografia, ma in genere richiedono una credenziale che corrisponde a un criterio configurato sul KMS. Pertanto, qualsiasi parte posseduta di tale credenziale sarà in grado di accedere alla chiave di crittografia e di decriptare i dati.
Confidential Computing
Con l'offerta Confidential VM (Confidential VM) di Google Cloud, le VM di Compute Engine vengono eseguite con la propria memoria criptata, offrendo protezioni aggiuntive contro l'accesso involontario ai dati durante l'uso. Per molti modelli di minacce, le Confidential VM sono più attendibili delle VM standard, il che ne consente l'utilizzo per carichi di lavoro sensibili.
Se il tuo modello di minacce si basa sul Confidential Computing, un problema è assicurare che un carico di lavoro sia in esecuzione in una Confidential VM. Attestazione remota indica un mezzo con cui 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 sull'ambiente del carico di lavoro. Poiché le attestazioni sono generate dalla piattaforma, il carico di lavoro non può creare false attestazioni che non includono 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 carico di lavoro previsto sia autorizzato a decriptare i dati, anche se le normali credenziali sono state compromesse.
Lo strumento di crittografia Split-Trust (STET) semplifica la crittografia e la decriptazione dei dati utilizzando chiavi archiviate in un KMS che richiede le attestazioni.
Dividi trust
Quando utilizzi un singolo KMS, questo ha il controllo esclusivo sulle chiavi di crittografia. Se l'operatore KMS acquisisce il testo di crittografia dei dati criptati, avrà tutto ciò che serve per decriptarlo in testo non crittografato. Sebbene questo rischio possa essere accettabile se il KMS è gestito da un'entità completamente attendibile, alcuni modelli di minacce creano la necessità di rimuovere il controllo unilaterale dal KMS.
Con STET, hai la possibilità di suddividere questo trust tra due sistemi KMS, nessuno dei due dispone di informazioni sufficienti per decriptare i dati. Richiederà la collisione tra gli operatori KMS (e l'accesso al testo di crittografia) per decriptare i dati.
Insieme, 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 Confidential VM).
Per ulteriori informazioni sullo strumento di crittografia Split Trust, consulta il repository GitHub e la guida rapida.