Panoramica della sicurezza di Confidential Space

Questo documento descrive i controlli di sicurezza di Confidential Space e il modo in cui 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 gli 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 riservati. 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 private le identità dei clienti.

Componenti di un sistema Confidential Space

Confidential Space è 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 carico di lavoro:un'immagine containerizzata con un sistema operativo protetto che viene eseguita in un'istanza di Confidential VM 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 dall'istanza Confidential VM e rilasciare token di autenticazione. I token contengono attributi di identificazione per il workload.
  • 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à del 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 carico di lavoro 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 Google Cloud risorse come istanze, dischi e regole di rete Compute Engine e può interagire con qualsiasi Google Cloud API che agisce su di esse. 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. Un proprietario della risorsa può accedere ai propri dati, impostare le autorizzazioni sui propri dati 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 workload, l'operatore del workload 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 multipartitico, 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. Sono coautori di 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 un bucket Cloud Storage condiviso.
Condivisioni chiave Uno schema più complesso utilizza l'idea di condivisioni di chiavi. 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'istanza VM riservata con accesso limitato da un workload 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 che non possiede. 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 alla relativa istanza VM confidenziale. Questo controllo contribuisce a proteggere l'integrità del workload prima dell'attestazione.
  • Un'immagine di base protetta aiuta a ridurre la superficie di attacco e impedisce all'operatore del carico di lavoro 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 della fase iniziale di avvio, il kernel caricato e l'immagine container. Inoltre, includono proprietà dell'ambiente come un flag che indica che l'istanza è una VM confidenziale. 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 nella procedura 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 con protezione avanzata basata su Container-Optimized OS che viene letta dal disco di avvio collegato.
  • Componenti della fase iniziale di avvio: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 il criterio di accesso al workload.

Immagine protetta

L'immagine Confidential Space è un sistema operativo minimale 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 temporanea scrivibile che archivia il binario del workload scaricato. dm-crypt crittografa questa partizione e ne protegge l'integrità.
    • Una partizione tmp-fs mappata alla RAM. In un'istanza 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 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 disabilitati: 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 workload. I collaboratori dei dati presuppongono che i proprietari delle risorse abbiano esaminato e controllato l'immagine 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 dimensione della 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 scenari 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 dannoso:un proprietario di risorse dannoso 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 del disco in modo dinamico e a 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 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 router Cloud 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 che è 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 istanze Confidential VM contribuisce a proteggere la riservatezza della memoria dell'istanza. La crittografia della memoria inline rende inefficace l'ispezione diretta o la registrazione 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 la lettura del codice dal disco, questo viene misurato e i dati non vengono più riletti dal disco. I secret non vengono mai divulgati in formato di testo non crittografato sul disco o su 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 dei metadati. Infine, i workload di Confidential Space devono 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 misurato

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

Minaccia Mitigazione Implementazione della mitigazione

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

Se l'attacco va a buon fine, l'aggressore può 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 dell'ospite. Le modifiche precedenti nella memoria guest vengono eliminate. Inoltre, il riavvio guest è l'unico evento che reimposta il vTPM. Entro Google Cloud e dopo 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 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 non sono state omesse misurazioni nel processo di attestazione.

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

I componenti della fase iniziale di avvio 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 della fase iniziale di avvio 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 sconfiggere 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 attaccante modifica i file binari della fase iniziale di avvio sul disco dopo che sono stati letti e misurati, prima che vengano letti ed eseguiti (TOCTOU del disco).

I componenti della fase iniziale di avvio sono stati creati per macchine bare metal e potrebbero non essere adatti all'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 di lettura, misurazione ed esecuzione.

La revisione della sicurezza per l'immagine di Confidential Space non ha identificato problemi TOCTOU nei componenti della fase iniziale di avvio 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 su 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 Mitigazione 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 criptata e autenticata.

Un malintenzionato può modificare l'URL dell'immagine e controllare il 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 criptata e la cui integrità è protetta.

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

La procedura di crittografia del disco dm-crypt consente attacchi di rollback, in cui un malintenzionato sostituisce i contenuti del disco con tag e testi crittografati visualizzati 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 Mitigazione 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 tramite una connessione TLS crittografata e autenticata. Questa connessione contribuisce a proteggere il token dall'intercettazione passiva.

Un malintenzionato non può impersonare il servizio perché non dispone della chiave TLS. Anche se riuscito, l'attaccante 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 e 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 una 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 dalla presenza di un servizio distribuito ed elastico che può essere facilmente replicato e scalato in orizzontale 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 Mitigazione 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 di 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 ospite è disabilitato. 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 di Confidential Space perché l'agente di configurazione del sistema operativo è disabilitato. All'interno dell'immagine Confidential Space
Un malintenzionato passa un set di dati criptato e malformato al carico di lavoro. Questa minaccia viene mitigata dalla 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 di istanza Confidential VM imprevisto o avvia un contenitore del workload modificato.

  • Controllo manuale della procedura di avvio misurato

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

  • Controllo manuale del 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 workload 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