Panoramica della sicurezza di Confidential Space

Questo documento descrive i controlli di sicurezza di Confidential Space e come il sistema è progettato per mitigare un'ampia gamma di minacce. Confidential Space è progettato per consentire alle parti di condividere dati riservati (ad esempio dati regolamentati o informazioni che consentono l'identificazione personale (PII)) con un workload mantenendo la riservatezza e la proprietà dei dati. Confidential Space contribuisce a creare l'isolamento in modo che i dati siano visibili solo al carico di lavoro e ai proprietari originali dei dati.

Puoi utilizzare Confidential Space per scenari in cui non puoi stabilire un rapporto di fiducia con l'operatore del workload o tra le parti originali che hanno creato i dati confidenziali. Ad esempio, gli istituti finanziari possono utilizzare Confidential Space per collaborare tra loro per identificare frodi o analizzare attività di riciclaggio di denaro. Confidential Space consente l'analisi di set di dati dei clienti, mantenendo al contempo la riservatezza delle identità dei clienti.

Componenti di un sistema Confidential Space

Confidential Space utilizza un Trusted Execution Environment (TEE) progettato per rilasciare i secret solo ai carichi di lavoro autorizzati. Un processo di attestazione e un'immagine del sistema operativo protetta contribuiscono a proteggere il carico di lavoro e i dati che elabora da un operatore non attendibile.

Un sistema Confidential Space è composto da tre componenti principali:

  • Un workload: un'immagine containerizzata con un sistema operativo protetto che viene eseguita in un TEE basato sul cloud. Utilizzi Confidential Computing come TEE che offre funzionalità di isolamento hardware e attestazione remota.
  • Google Cloud Attestation: un provider di token OpenID Connect (OIDC). Utilizzi questo servizio per verificare le citazioni di attestazione per TEE e rilasciare i token di autenticazione. I token contengono attributi di identificazione per il carico di lavoro.
  • Una risorsa protetta:una risorsa cloud gestita come una chiave Cloud Key Management Service o un bucket Cloud Storage. La risorsa è protetta da una policy di autorizzazione che concede l'accesso a token di identità federata autorizzati. Un passaggio intermedio, che utilizza i pool di identità per i workload, trasforma i token OIDC in token di identità federata che IAM può utilizzare.

Il sistema contribuisce a garantire che l'accesso alle risorse protette venga concesso solo ai carichi di lavoro autorizzati. Inoltre, Confidential Space aiuta a proteggere il workload da ispezioni e manomissioni, prima e dopo l'attestazione.

In un sistema Confidential Space, ci sono tre parti:

  • L'autore del workload, che crea un'immagine containerizzata che include un'applicazione che ha accesso alle risorse protette. L'autore non ha accesso ai dati o ai risultati. Inoltre, l'autore non controlla l'accesso ai dati o ai risultati.
  • L'operatore del workload, che esegue il workload in un progetto Google Cloud . L'operatore in genere dispone di privilegi amministrativi completi per il progetto. L'operatore può gestire risorse come istanze, dischi e regole di rete di Compute Engine e può interagire con qualsiasi API che agisce su queste risorse. Google Cloud Google Cloud L'operatore non ha accesso ai dati o ai risultati e non può influenzare o modificare il codice o l'ambiente di esecuzione. Inoltre, l'operatore non controlla l'accesso ai dati o ai risultati.
  • I proprietari delle risorse (o i collaboratori dei dati), che possiedono la risorsa protetta. Il proprietario di una risorsa può accedere ai propri dati, impostare le autorizzazioni e accedere ai risultati. Non possono accedere ai dati di altri proprietari di risorse o modificare il codice autonomamente.

Confidential Space supporta un modello di trust in cui l'autore del carico di lavoro, l'operatore del carico di lavoro e i proprietari delle risorse sono parti separate che non si fidano reciprocamente.

Il seguente diagramma mostra i componenti e le parti del sistema. Il workload si trova in un progetto separato dalla risorsa protetta.

Sistema e componenti di Confidential Space.

Esempi di trattamento sicuro dei dati

Confidential Space ti aiuta a preservare la privacy di un utente durante la condivisione dei dati. La seguente tabella descrive tre esempi di casi d'uso.

Caso d'uso Scenario di esempio
Modello di crittografia funzionale In un modello di crittografia funzionale, Alice vuole condividere il risultato dei suoi dati riservati con Bob, senza rivelare l'intero set di dati. Alice cripta il suo set di dati e protegge la chiave di crittografia dei dati (DEK) in Cloud KMS nel suo progetto. Alice scrive un programma che implementa il carico di lavoro e condivide il binario con Bob. Alice configura KMS per concedere al programma l'accesso alla DEK. Il carico di lavoro viene eseguito in Confidential Space di Bob, decripta ed elabora il set di dati di Alice e scrive il risultato in Cloud Storage di Bob.
Calcolo multipartitico Nel calcolo multi-parte, Alice e Bob vogliono condividere il risultato tra loro, preservando la riservatezza dei set di dati di input. Analogamente al modello di crittografia funzionale, Alice e Bob criptano i rispettivi set di dati e proteggono le DEK nelle istanze Cloud KMS nei loro progetti. Creano insieme un programma che determina i risultati e lo eseguono in unoConfidential Spacele. Alice e Bob configurano KMS per concedere al programma l'accesso alle DEK. Il programma legge ed elabora entrambi i set di dati e scrive il risultato in unbucket Cloud Storagege condiviso.
Azioni chiave Uno schema più complesso utilizza l'idea delle quote della chiave. Una condivisione della chiave è una chiave privata suddivisa tra Alice, Bob e altri proprietari in modo che la conoscenza delle singole condivisioni non dia accesso al set di dati criptato. In questo schema, la fiducia è suddivisa tra più proprietari. La chiave privata viene assemblata solo in un TEE con limitazioni da un carico di lavoro autorizzato.

In questi esempi, solo il workload ha accesso al set di dati criptato e può elaborarlo. Confidential Space contribuisce a garantire che nessuno possa eseguire operazioni non controllate sui dati di cui non è proprietario. I proprietari dei dati controllano come vengono utilizzati i loro dati e quali carichi di lavoro sono autorizzati ad agire su di essi.

Proteggere l'integrità e la riservatezza di un carico di lavoro

Per proteggere il workload da un operatore non attendibile, Confidential Space implementa i seguenti controlli di sicurezza:

  • Una procedura di attestazione rileva le modifiche all'immagine del workload o al relativo TEE. Questo controllo contribuisce a proteggere l'integrità del workload prima dell'attestazione.
  • Un'immagine di base protetta contribuisce a ridurre la superficie di attacco e impedisce all'operatore del workload di accedere o compromettere l'istanza in fase di runtime. Questo controllo contribuisce a proteggere l'integrità e la riservatezza di un workload dopo l'attestazione. Insieme, questi controlli di sicurezza contribuiscono a proteggere il workload, i relativi secret e i dati che elabora.

Procedura di attestazione

Il processo di attestazione si basa sull'avvio con misurazioni e sulle misurazioni estese del runtime di Shielded VM. Questo processo acquisisce le misurazioni della sequenza di avvio in un registro protetto e di sola estensione nel dispositivo Trusted Platform Module virtuale (vTPM).

Le misurazioni riguardano i componenti di fase iniziale di avvio, il kernel caricato e l'immagine del container. Inoltre, includono proprietà dell'ambiente come un flag che indica che l'istanza è una VM confidenziale. Il vTPM firma (o cita) queste misurazioni utilizzando una chiave di attestazione certificata considerata attendibile da Google Cloud Attestation.

Il seguente diagramma mostra i componenti di un sistema Confidential Space e il modo in cui ogni componente partecipa al processo di attestazione.

I componenti del sistema e le parti coinvolte nel processo di attestazione.

Il processo di attestazione dipende dai seguenti componenti:

  • Firmware guest:un componente immutabile che è una parte attendibile di Google Cloud.
  • Immagine di Confidential Space attestata:un'immagine protetta basata su Container-Optimized OS che viene letta dal disco di avvio collegato.
  • Componenti di avvio anticipato:bootloader e kernel che interagiscono con il vTPM per misurare i componenti di avvio in un registro di configurazione della piattaforma (PCR).

  • Launcher: un componente che scarica il binario del workload dal repository di immagini e misura il container e la sua configurazione in un PCR. Il launcher legge la sua configurazione dal server di metadati dell'istanza.

  • Codice di gestione dell'attestazione:codice responsabile della preparazione di una citazione PCR e della restituzione della citazione, della chiave di attestazione e del log eventi completo del vTPM.

  • Google Cloud Attestation: un servizio che verifica la citazione, riproduce il log eventi, emette il token OIDC e lo restituisce con gli attributi per la policy di accesso al workload.

Immagine protetta

L'immagine di Confidential Space è un sistema operativo minimalista e monoscopo. L'immagine esegue il launcher del container, che a sua volta avvia un singolo container. L'immagine Confidential Space si basa sui miglioramenti della sicurezza esistenti di Container-Optimized OS e aggiunge i seguenti vantaggi:

  • Partizioni del disco criptate con protezione dell'integrità:l'immagine di Confidential Space include le seguenti partizioni:
    • Una partizione root-fs e una partizione OEM che include il binario del launcher. Queste partizioni sono immutabili e protette da dm-verity.
    • Una partizione scrivibile temporanea che archivia il binario del workload scaricato. dm-crypt cripta questa partizione e ne protegge l'integrità.
    • Una partizione tmp-fs mappata alla RAM. In un TEE Confidential VM, la memoria della VM è criptata. Inoltre, il sistema swap-fs è disattivato, il che contribuisce a impedire a un sistema operativo configurato in modo errato di archiviare i dati sul disco.
  • Connessioni di rete autenticate e criptate: il launcher utilizza TLS per autenticare Google Cloud Attestation e proteggere i suoi link di comunicazione.
  • Varie misurazioni di avvio:queste misurazioni includono gli argomenti della riga di comando del kernel, la configurazione di dm-verity per root-fs e il binario del carico di lavoro.

  • Accesso remoto e strumenti specifici per il cloud disattivati:questi strumenti includono sshd e OS Login.

  • Transizioni di stato ridotte:ad esempio, il launcher esegue un singolo container e poi termina.

Modello di minaccia e mitigazioni

Questa sezione descrive i modelli di minaccia che Confidential Space aiuta a mitigare e i nuovi rischi introdotti da Confidential Space.

I seguenti attacchi non rientrano nell'ambito di questo documento:

  • Attacchi alla catena di fornitura del software che si applicano al firmware Unified Extensible Firmware Interface (UEFI) guest, al bootloader e al kernel dell'immagine Confidential Space, al runtime del container e alle dipendenze di terze parti per il carico di lavoro. I collaboratori dei dati presuppongono che i proprietari delle risorse abbiano esaminato e controllato l'immagine del container prima di condividere la risorsa con un criterio di autorizzazione.
  • Attacchi a Google Cloud, ad esempio VM Escape.

Possibili attacchi

Confidential Space è progettato per difendersi da tre possibili attacchi:

  • Un operatore di workload dannoso:un operatore di workload dannoso può modificare i contenuti del disco, intercettare le connessioni di rete e tentare di compromettere l'ambiente di esecuzione attendibile (TEE) in fase di runtime. Un operatore malintenzionato può espandere la superficie di attacco o limitare l'ambiente di runtime. Ad esempio, un operatore malintenzionato può aggiungere una console seriale per introdurre nuovi vettori di attacco. Come altro esempio, un operatore malintenzionato può limitare le risorse, ad esempio limitando la memoria di un ospite, modificando lo spazio su disco o le regole del firewall. Questi vincoli potrebbero attivare errori di I/O che potrebbero portare a casi di errore testati in modo insufficiente.
  • Un client di attestazione dannoso: questo utente malintenzionato si connette a Google Cloud Attestation e invia messaggi di log degli eventi firmati ma non validi.
  • Un proprietario di risorse malintenzionato:un proprietario di risorse malintenzionato ha il controllo completo sul set di dati criptato utilizzato dal workload. Questo malintenzionato potrebbe presentare input non validi o dati distorti e tentare di attivare vulnerabilità di analisi nel workload o tentare di aggirare i controlli della privacy.

Superfici di attacco

La tabella seguente descrive le superfici di attacco disponibili per gli autori degli attacchi.

Attaccante Target Superficie di attacco Rischi
Operatore del workload TEE, Workload Letture del disco

Qualsiasi elemento letto dal disco è sotto il controllo dell'autore dell'attacco.

Servizi come dischi permanenti multi-writer e collegamenti dinamici dei dischi consentono a un malintenzionato di modificare i contenuti dei dischi in modo dinamico e a suo piacimento.
Operatore del workload TEE, Workload Scritture su disco Tutto ciò che viene scritto sul disco è visibile a un malintenzionato. Consulta le funzionalità di snapshot dei dischi e di importazione.
Operatore del workload TEE, Workload Server di metadati Gli attributi dell'istanza letti dal server dei metadati sono sotto il controllo dell'autore dell'attacco, inclusi lo script di avvio e le variabili di ambiente.
Operatore del workload TEE, Workload Rete Le connessioni di rete esterne al repository di immagini o Google Cloud Attestation possono essere intercettate. Questo attacco viene eseguito utilizzando un VPC privato con un'istanza Cloud Router rivolta al pubblico.
Client di attestazione Google Cloud Attestation Messaggi di log eventi e attestazione Google Cloud Attestation ha una logica complessa e basata sulla crittografia, difficile da scrivere in modo difensivo.
Proprietario risorsa Workload Set di dati criptato

Un malintenzionato può compromettere i set di dati di input del workload, il che significa che i dati criptati non sono necessariamente dati attendibili.

Google Cloud infrastruttura

Google Cloud include l'hypervisor Compute Engine, vTPM per la VM confidenziale, il firmware UEFI guest e un'istanza di Google Cloud Attestation ospitata. Il materiale delle chiavi sensibili, come le chiavi di firma vTPM e OIDC, è progettato per essere protetto in modo sicuro.

L'infrastruttura di Google è progettata per isolare logicamente i dati di ciascun cliente da quelli di altri clienti e utenti, anche quando sono archiviati sullo stesso server fisico. L'accesso amministrativo per il personale di assistenza e gli ingegneri è limitato, controllato e trasparente per i clienti. Inoltre, la crittografia della memoria in linea nelle Confidential VM contribuisce a proteggere la riservatezza della memoria dell'istanza. La crittografia della memoria in linea rende inefficace l'ispezione diretta o il logging accidentale della memoria (log di arresto anomalo del kernel). Per ulteriori informazioni su come proteggiamo la nostra piattaforma, consulta la Panoramica sulla sicurezza di Google.

Minacce e mitigazioni

Un file system criptato con protezione dell'integrità è progettato per ridurre i rischi derivanti da attacchi al disco. Inoltre, dopo che il codice viene letto dal disco, viene misurato e i dati non vengono più riletti dal disco. I secret non vengono mai divulgati in formato di testo normale al disco o a qualsiasi dispositivo esterno, ad esempio una console seriale.

I rischi derivanti dagli attacchi di rete vengono mitigati grazie a canali autenticati e criptati end-to-end. L'accesso alla rete esterna, ad esempio SSH, è disabilitato nell'immagine. Un protocollo di attestazione contribuisce a proteggere la sequenza di avvio e qualsiasi configurazione letta dal server di metadati. Infine, i workload di Confidential Space dovrebbero utilizzare controlli di privacy differenziale per mitigare i rischi derivanti da set di dati distorti.

Le tabelle seguenti descrivono le minacce e le mitigazioni:

Attacchi al processo di avvio con misurazioni

Questa tabella descrive le potenziali minacce e le strategie di mitigazione correlate al processo di avvio verificato.

Minaccia Attenuazione Implementazione della mitigazione

Un malintenzionato avvia una Shielded VM con un firmware precedente che non supporta l'avvio misurato.

In caso di esito positivo, un malintenzionato potrebbe riprodurre misurazioni arbitrarie e sconfiggere l'attestazione remota.

Questa minaccia viene mitigata dal control plane Google Cloud .

Confidential Space aggiunge un dispositivo vTPM e un firmware UEFI aggiornato. Inoltre, Confidential Space consente l'avvio con misurazioni, che non può essere disattivato.

 Entro l'infrastruttura Google Cloud

Un malintenzionato sovrascrive il firmware UEFI nella memoria fisica guest, riavvia il guest, che reimposta i registri vTPM ed esegue il firmware modificato.

Se l'attacco va a buon fine, un malintenzionato può riprodurre misurazioni arbitrarie e sconfiggere l'attestazione remota.

 Questa minaccia viene mitigata dall'hypervisor. Al riavvio dell'ospite, l'hypervisor carica una copia pulita del firmware UEFI nella memoria ospite. Le modifiche precedenti nella memoria guest vengono eliminate. Inoltre, il riavvio guest è l'unico evento che reimposta il vTPM. All'interno di Google Cloud e con l'attivazione di Confidential Computing
Un malintenzionato modifica i file di configurazione non misurati, il che influisce negativamente sull'esecuzione del programma.

Questa minaccia viene mitigata dalla procedura di attestazione. Tutti i file binari eseguibili e i rispettivi file di configurazione vengono misurati completamente prima dell'esecuzione.

In particolare, vengono misurate le variabili di avvio protetto, la configurazione di grub e gli argomenti della riga di comando del kernel.

La revisione della sicurezza ha rilevato che nessuna misurazione è stata omessa nel processo di attestazione.

 All'interno dell'immagine Confidential Space
Un malintenzionato attiva vulnerabilità di corruzione della memoria nei componenti di avvio iniziali e ottiene l'esecuzione di codice.

I componenti di avvio anticipato sono scritti in linguaggio C. Questi componenti elaborano dati utente non attendibili e potrebbero essere vulnerabili a problemi di danneggiamento della memoria. Per un esempio recente, vedi BootHole.

Questo rischio viene mitigato dalla procedura di attestazione: i componenti di fase iniziale di avvioo devono misurare tutti i dati controllati dall'utente prima di elaborarli. Un attacco BootHole utilizza un grub.cfg modificato per ottenere l'esecuzione del codice e disattivare l'avvio protetto.

Tuttavia, in un sistema Confidential Space, questo attacco non supera l'attestazione, poiché le misurazioni di grub.cfg non corrispondono alla configurazione prevista.

Un rischio correlato deriva dalla logica complessa del file system. Vulnerabilità passate come Sequoia dimostrano che i driver del file system elaborano strutture di dati complesse e possono essere vulnerabili a problemi di danneggiamento della memoria.

Questo rischio viene mitigato utilizzando la protezione dell'integrità dm-verity e dm-crypt a livello di blocco e disattivando i montaggi automatici.

All'interno dell'immagine Confidential Space
Un malintenzionato modifica i binari di fase iniziale di avvio sul disco dopo che sono stati letti e misurati, prima che vengano letti ed eseguiti (TOCTOU del disco).

I componenti di avvio anticipato sono stati creati per macchine bare metal e potrebbero non prevedere l'ambiente dinamico del cloud. I componenti di avvio potrebbero presupporre che i contenuti del disco non possano cambiare durante l'esecuzione, il che è un presupposto errato per gli ambienti cloud.

Questo rischio viene mitigato utilizzando la programmazione difensiva: i contenuti del disco sono di sola lettura dopo l'utilizzo del pattern read, measure, execute.

La revisione della sicurezza per l'immagine di Confidential Space non ha identificato problemi TOCTOU nei componentfase iniziale di avvioli come UEFI, Shim o GNU GRUB.

 All'interno dell'immagine Confidential Space
Un malintenzionato modifica i driver del dispositivo e i servizi in modalità utente sul disco dopo il caricamento del kernel.

Questa minaccia viene mitigata da un file system radice con protezione dell'integrità.

Root-fs nell'immagine di Confidential Space è protetto dall'integrità di dm-verity. La configurazione (root-hash) viene trasmessa in un argomento del comando del kernel, quindi misurata e attestata da Google Cloud Attestation.

 All'interno dell'immagine Confidential Space

Attacchi al launcher dei container

Questa tabella descrive le potenziali minacce e le strategie di mitigazione relative al launcher.

Minaccia Attenuazione Implementazione della mitigazione
Un malintenzionato intercetta la connessione di rete del launcher o del repository di immagini.

La connessione al repository di immagini è protetta da una connessione TLS autenticata e criptata.

Un malintenzionato può modificare l'URL dell'immagine e controllare il file binario del workload. Tuttavia, queste azioni vengono registrate nel log di attestazione.

Il repository di immagini non è controllato tramite un elenco di accesso, pertanto si presume che l'immagine sia visibile a tutti. Devi assicurarti che l'immagine container del workload non contenga segreti.

 All'interno dell'immagine Confidential Space
Un malintenzionato modifica l'immagine del workload sul disco dopo che è stata scaricata e misurata.

Questa minaccia viene mitigata da una partizione scrivibile crittografata e la cui integrità è protetta.

L'immagine del workload e i relativi dati temporanei sono protetti da dm-crypt utilizzando chiavi effimere per avvio.

Il processo di crittografia del disco dm-crypt consente attacchi di rollback, in cui un malintenzionato sostituisce i contenuti del disco con testi e tag criptati visti in precedenza. Questi attacchi sono considerati altamente complessi nelle impostazioni di Confidential Space.

 All'interno dell'immagine Confidential Space
Un malintenzionato modifica la configurazione del launcher nel server di metadati e controlla l'URL del repository di immagini. La procedura di attestazione rileva configurazioni non sicure che caricano immagini non autentiche. In Google Cloud Attestation

Attacchi a Google Cloud Attestation

Questa tabella descrive le potenziali minacce e le strategie di mitigazione per Google Cloud Attestation.

Minaccia Attenuazione Implementazione della mitigazione
Un malintenzionato intercetta la connessione di rete per il launcher o Google Cloud Attestation e legge il token segreto dal cavo.

Questa minaccia viene mitigata da una connessione TLS autenticata e criptata. Questa connessione aiuta a proteggere il token da intercettazioni passive.

Un malintenzionato non può impersonare il servizio perché non dispone della chiave TLS. Anche se riuscito, l'autore dell'attacco non può creare token OIDC validi.

Un malintenzionato non può impersonare un client valido perché l'identità del client è garantita dal protocollo di attestazione.

 All'interno della rete tra il tuo workload e il servizio di attestazione.
Un malintenzionato sfrutta le discrepanze di analisi, il che porta a modifiche non rilevate nel processo di attestazione.

Questa minaccia può verificarsi perché il log eventi delle misurazioni viene serializzato e inviato a Google Cloud Attestation, dove viene analizzato ed elaborato.

Si verifica una discrepanza di analisi quando il servizio e il sistema operativo runtime non concordano sulla semantica del log.

Ad esempio, se il campo cmdline contiene un elenco di argomenti separati da una virgola, una stringa come a=1, b=2 c='3,d=e' (nota ,d nella sottostringa del valore) potrebbe essere analizzata in modo diverso dal kernel e dal servizio.

Questo rischio viene mitigato grazie a un motore di analisi che riflette correttamente il comportamento del sistema operativo. In particolare, cmdline viene elaborato come stringa intera e non viene suddiviso in coppie chiave-valore.

 All'interno dell'immagine Confidential Space
Un malintenzionato utilizza tutte le risorse del servizio, che viene interrotto in un attacco Denial of Service (DoS). Il servizio viene interrotto per gli altri utenti di Confidential Space.

Questo rischio di affidabilità viene mitigato grazie a un servizio distribuito ed elastico che può essere facilmente replicato e scalato in base alle esigenze.

Il codice impedisce l'esaurimento delle risorse da parte di client dannosi.

 All'interno del workload

Attacchi ai workload

Questa tabella descrive le potenziali minacce e le strategie di mitigazione relative ai carichi di lavoro.

Minaccia Attenuazione Implementazione della mitigazione
Un malintenzionato legge i secret di runtime dalla partizione scrivibile.

Questa minaccia viene mitigata con un file system criptato. Il file system scrivibile è montato utilizzando dm-crypt. Lo swap è disattivato e i contenuti della memoria non vengono paginati sul disco.

In quanto tecnica di difesa in profondità, i token OIDC sono limitati e di breve durata.

 All'interno dell'immagine Confidential Space
Un malintenzionato legge i secret di runtime dalla console seriale. Questa minaccia viene mitigata nell'immagine Confidential Space perché le credenziali e i token non vengono mai stampati nella console seriale. Inoltre, Cloud Logging è disabilitato. All'interno dell'immagine Confidential Space
Un malintenzionato aggiorna le chiavi SSH autorizzate utilizzando il pacchetto OSLogin e poi si connette all'istanza in esecuzione. Questa minaccia viene mitigata nell'immagine di Confidential Space perché i servizi systemd predefiniti sono mascherati, incluso sshd. All'interno dell'immagine Confidential Space
Un malintenzionato aggiorna gli script di avvio nel server dei metadati, che vengono caricati automaticamente dall'agente guest. Questa minaccia viene mitigata nell'immagine di Confidential Space perché il pacchetto dell'agente guest è disattivato. All'interno dell'immagine Confidential Space
Un malintenzionato esegue il push di pacchetti non validi nella VM utilizzando l'agente OS Config. Questa minaccia viene mitigata nell'immagine Confidential Space perché l'agente di configurazione del sistema operativo è disattivato. All'interno dell'immagine Confidential Space
Un malintenzionato passa un set di dati criptato e malformato al carico di lavoro. Questa minaccia viene mitigata grazie alla presenza di codice di analisi difensiva nel carico di lavoro. All'interno del workload
Un malintenzionato trasmette un set di dati distorto o compromesso al carico di lavoro e tenta di ottenere informazioni sui set di dati da altre parti. Questa minaccia viene mitigata implementando controlli di privacy differenziale nel workload. All'interno del workload

Test di sicurezza

Confidential Space è stato sottoposto a una procedura di revisione della sicurezza completa presso Google. Questa procedura di revisione della sicurezza ha incluso i seguenti test e audit:

  • Test di integrazione end-to-end del flusso negativo

    Questi test hanno verificato che l'attestazione non riesce in caso di misurazioni errate, ad esempio quando il codice viene eseguito in un ambiente TEE imprevisto o avvia un contenitore del carico di lavoro modificato.

  • Controllo manuale della procedura di avvio con misurazioni

    Questa revisione si è concentrata sull'identificazione di misurazioni mancanti e bug di doppia lettura. I test hanno verificato che il codice è stato scritto tenendo conto delle best practice per la sicurezza e, in caso di errore, il codice è stato chiuso.

  • Controllo manuale della processo di compilazione per l'immagine e la logica di avvio di Confidential Space:

    Questa revisione si è concentrata sulla rimozione dei pacchetti e sulla riduzione della superficie di attacco.

  • Audit manuale di Google Cloud Attestation

    Questa revisione si è concentrata sull'implementazione del protocollo di attestazione corretto e sull'evitare problemi di analisi.

  • Revisione della crittografia da parte di esperti di cybersicurezza

    Questa revisione si è concentrata su protocollo di attestazione, crittografia del file system e soluzioni di integrità.

  • Revisione della privacy da parte di esperti

    Questa revisione si è concentrata sui controlli di privacy differenziale nei carichi di lavoro creati da Google.

  • Test fuzzing continui

    Questi test hanno riguardato componenti critici per la sicurezza, come vTPM e Google Cloud Attestation.

NCC Group, un'organizzazione esterna di test di penetrazione, ha eseguito test di penetrazione sul sistema. NCC ha esaminato Confidential Space come piattaforma di calcolo sicura.

Passaggi successivi