Panoramica della sicurezza di Confidential Space

Questo documento descrive i controlli di sicurezza di Confidential Space e come il sistema è progettato per mitigare una vasta 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 carico di lavoro, mantenendo al contempo 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.

Puoi utilizzare Confidential Space per gli scenari in cui non riesci a stabilire la fiducia con l'operatore del carico di lavoro o tra le parti originali che hanno creato i dati riservati. Ad esempio, gli istituti finanziari possono utilizzare Confidential Space per collaborare tra loro al fine di identificare attività fraudolente o analizzare attività di riciclaggio di denaro. Confidential Space consente di analizzare i set di dati dei clienti, mantenendo al contempo private le loro identità.

Componenti di un sistema Confidential Space

Confidential Space utilizza un ambiente di esecuzione attendibile (TEE) disponibile per rilasciare i secret solo ai carichi di lavoro autorizzati. Un processo di attestazione e un'immagine del sistema operativo rafforzata contribuiscono a proteggere il carico di lavoro e i dati elaborati dal carico di lavoro 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 rafforzato che viene eseguita in un TEE basato su cloud. Utilizzi Confidential Computing come TEE che offre funzionalità di isolamento hardware e attestazione remota.
  • Un servizio di attestazione: un provider di token OpenID Connect (OIDC). Utilizza questo servizio per verificare le citazioni di attestazione per il TEE e rilasciare token di autenticazione. I token contengono gli 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 un criterio di autorizzazione che concede l'accesso ai token di identità federata autorizzati. Un passaggio intermedio, che utilizza i pool di identità per i carichi di lavoro, trasforma i token OIDC in token di identità federati che possono essere utilizzati da IAM.

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 di Confidential Space sono presenti tre parti:

  • L'autore del workload, che crea un'immagine container che include un'applicazione con 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 carico di lavoro, che esegue il carico di lavoro in un progetto Google Cloud. L'operatore solitamente dispone di privilegi amministrativi completi per il progetto. L'operatore può gestire le risorse Google Cloud, come istanze, dischi e regole di rete di Compute Engine, nonché interagire con qualsiasi API Google Cloud che agisce su queste risorse. 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 per i dati), che sono i proprietari della risorsa protetta. Un proprietario della risorsa può accedere ai propri dati, impostare le autorizzazioni per i propri dati e accedere ai risultati. Non possono accedere ai dati di altri proprietari di risorse o modificare autonomamente il codice.

Confidential Space supporta un modello di attendibilità in cui l'autore del carico di lavoro, l'operatore del carico di lavoro e i proprietari delle risorse sono parti distinte e reciprocamente diffidenti.

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

Sistema e componenti di Confidential Space.

Esempi di elaborazione sicura dei dati

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

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 proprio 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 file binario con Bob. Alice configura KMS per concedere al programma l'accesso alla DEK. Il workload 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 multipartito Nel calcolo multi-parte, Alice e Bob vogliono condividere il risultato tra loro, preservando al contempo la riservatezza dei set di dati di input. Analogamente al modello di crittografia funzionale, Alice e Bob crittografiano 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 un Confidential Space. Alice e Bob configurano KMS per concedere al programma l'accesso ai DEK. Il programma legge ed elabora entrambi i set di dati e scrive il risultato in un bucket Cloud Storage condiviso.
Azioni principali Uno schema più complesso utilizza l'idea delle quote chiave. Una condivisione della chiave è una chiave privata suddivisa tra Alice, Bob e altri proprietari in modo che la conoscenza delle singole quote non consenta l'accesso al set di dati criptato. In questo schema, la fiducia è suddivisa tra più proprietari. La chiave privata viene assemblata solo in un TEE limitato da un carico di lavoro autorizzato.

In questi esempi, solo il carico di lavoro ha accesso al set di dati criptato e può elaborarlo. Confidential Space contribuisce ad assicurare che nessuno possa eseguire operazioni non sottoposte a controllo su dati che non possiede. I proprietari dei dati controllano come vengono utilizzati i loro dati e quali carichi di lavoro sono autorizzati a intervenire.

Protezione dell'integrità e della riservatezza di un carico di lavoro

Per contribuire a proteggere il carico di lavoro da un operatore non attendibile, Confidential Space implementa i seguenti controlli di sicurezza:

  • Una procedura di attestazione rileva le modifiche all'immagine del carico di lavoro o al suo TEE. Questo controllo contribuisce a proteggere l'integrità del carico di lavoro prima dell'attestazione.
  • Un'immagine di base rafforzata contribuisce a ridurre la superficie di attacco e a impedire all'operatore del carico di lavoro di accedere o compromettere l'istanza in fase di esecuzione. Questo controllo contribuisce a proteggere l'integrità e la riservatezza di un carico di lavoro post-attestazione. Insieme, questi controlli di sicurezza contribuiscono a proteggere il workload, i relativi secret e i dati che vengono elaborati.

Procedura di attestazione

La procedura di attestazione si basa su misurazioni dell'avvio misurato e del tempo di esecuzione esteso della VM protetta. Questa procedura acquisisce le misurazioni della sequenza di avvio in un registro protetto di sola estensione nel dispositivo Trusted Platform Module (vTPM) virtuale.

Le misurazioni coprono i componenti di fase iniziale di avvio, il kernel caricato e l'immagine del contenitore. Inoltre, includono proprietà dell'ambiente come un flag che indica che l'istanza è una VM riservata. Il vTPM firma (o cita) queste misurazioni utilizzando una chiave di attestazione certificata considerata attendibile dal servizio di attestazione.

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

I componenti e le parti del sistema nella procedura di attestazione.

La procedura di attestazione dipende dai seguenti componenti:

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

  • Avvio: un componente che scarica il file binario del carico di lavoro dal repository di immagini e misura il contenitore e la relativa configurazione in un PCR. Il programma di avvio legge la propria configurazione dal server di metadati dell'istanza.

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

  • Il servizio di attestazione: un servizio che verifica la richiesta, riproduce il log eventi, emette il token OIDC e restituisce il token con gli attributi per il criterio di accesso al workload.

Immagine protetta

L'immagine dello spazio riservato è un sistema operativo minimale a scopo unico. L'immagine esegue il programma di avvio del contenitore, che a sua volta avvia un singolo contenitore. L'immagine dello spazio riservato 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 file binario del programma di avvio. Queste partizioni sono immutabili e protette da dm-verity.
    • Una partizione scrivibile temporanea che memorizza il file binario del carico di lavoro scaricato. dm-crypt cripta questa partizione e ne protegge l'integrità.
    • Una partizione tmp-fs mappata alla RAM. In un TEE di 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 memorizzare dati sul disco.
  • Connessioni di rete autenticate e criptate:il programma di lancio utilizza TLS per autenticare il servizio di attestazione e proteggere i relativi 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 codice binario del carico di lavoro.

  • Accesso remoto disattivato e strumenti specifici per il cloud: tra questi strumenti figurano sshd e Accesso sistema operativo.

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

Modello di minaccia e mitigazioni

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

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

  • Attacchi alla catena di approvvigionamento 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 contenitore 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 contenitore prima di condividerla con un criterio di autorizzazione.
  • Attacchi a Google Cloud, come fughe da VM.

Possibili attacchi

Confidential Space è progettato per difendersi da tre possibili attacchi:

  • Un operatore di workload malintenzionato:un operatore di workload malintenzionato può modificare i contenuti del disco, intercettare le connessioni di rete e tentare di compromettere il TEE in fase di esecuzione. 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. Un altro esempio è un operatore malintenzionato che può limitare le risorse, ad esempio la dimensione della memoria di un ospite, lo spazio su disco o le regole del firewall. Questi vincoli potrebbero attivare errori di I/O che potrebbero portare a casi di errori poco testati.
  • Un client di attestazione dannoso: questo malintenzionato si connette al servizio di attestazione e invia messaggi di log degli eventi non formattati, ma firmati.
  • Un proprietario di risorse malintenzionato: un proprietario di risorse malintenzionato ha il controllo completo sul set di dati criptato utilizzato dal carico di lavoro. L'utente malintenzionato potrebbe presentare input non validi o dati distorti e tentare di attivare vulnerabilità di analisi nel carico di lavoro o di aggirare i relativi controlli della privacy.

Superfici di attacco

La tabella seguente descrive le superfici di attacco a disposizione degli autori di attacchi.

Attaccante Target Superficie di attacco Rischi
Operatore di carico di lavoro TEE, Workload Letture disco

Tutto ciò che viene letto dal disco è sotto il controllo dell'aggressore.

Servizi come i dischi permanenti multi-writer e i collegamenti dinamici dei dischi consentono a un malintenzionato di modificare i contenuti dei dischi in modo dinamico e a piacimento.
Operatore di carico di lavoro TEE, Workload Scritture su disco Tutto ciò che viene scritto su disco è visibile a un malintenzionato. Consulta le funzionalità di snapshot dei dischi e di import.
Operatore di carico di lavoro TEE, Workload Server dei metadati Gli attributi delle istanze letti dal server dei metadati sono sotto il controllo dell'aggressore, inclusi lo script di avvio e le variabili di ambiente.
Operatore di carico di lavoro TEE, Workload Rete Le connessioni di rete esterne al repository di immagini o al servizio di attestazione possono essere intercettate. Questo attacco viene eseguito utilizzando una VPC privata con un'istanza Cloud Router rivolta al pubblico.
Client di attestazione Servizio di attestazione Log degli eventi e messaggi di attestazione Il servizio di attestazione ha una logica complessa e basata sulla crittografia che è difficile da scrivere in modo sicuro.
Proprietario risorsa Carico di lavoro Set di dati criptato

Un utente malintenzionato può avvelenare i set di dati di input del carico di lavoro, il che significa che i dati criptati non sono necessariamente dati attendibili.

Infrastruttura Google Cloud

Google Cloud include l'hypervisor Compute Engine, il vTPM per la VM Confidential, il firmware UEFI guest e un servizio di attestazione ospitato. 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, sometido a controllo 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 degli arresti anomali del kernel). Per ulteriori informazioni su come proteggiamo la nostra piattaforma, consulta la panoramica della sicurezza di Google.

Minacce e mitigazioni

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

I rischi derivanti dagli attacchi alla 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, si prevede che i workload di Confidential Space utilizzino controlli della privacy differenziale per ridurre i rischi derivanti dai set di dati distorti.

Le tabelle seguenti descrivono le minacce e le mitigazioni:

Attacchi al processo di avvio con misurazioni

Questa tabella descrive potenziali minacce e strategie di mitigazione relative al procedura di avvio misurata.

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 aggirare l'attestazione remota.

Questa minaccia viene mitigata dal control plane di Google Cloud.

Confidential Space aggiunge un dispositivo vTPM e un firmware UEFI aggiornato. Inoltre, Confidential Space attiva l'avvio misurato e quest'ultimo non può essere disattivato.

 Nell'infrastruttura Google Cloud

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

In caso di esito positivo, un malintenzionato potrebbe riprodurre misurazioni arbitrarie e aggirare l'attestazione da remoto.

 Questa minaccia viene mitigata dall'hypervisor. Al riavvio del guest, l'hypervisor carica una copia pulita del firmware UEFI nella memoria del guest. Le modifiche precedenti nella memoria ospite vengono ignorate. Inoltre, il riavvio del guest è l'unico evento che reimposta il vTPM. In Google Cloud e attivando 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 gli eseguibili binari e i rispettivi file di configurazione vengono misurati completamente prima dell'esecuzione.

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

La revisione della sicurezza ha rilevato che non sono state perse misurazioni durante la procedura di attestazione.

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

I componenti di avvio iniziale 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, consulta BootHole.

Questo rischio viene mitigato dalla procedura di attestazione: i componenti di 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 di codice e aggirare l'avvio protetto.

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

Un rischio correlato è rappresentato 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 corruzione della memoria.

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

All'interno dell'immagine di Confidential Space
Un utente 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 sul disco).

I componenti di avvio iniziale sono stati creati per macchine bare metal e potrebbero non essere adatti all'ambiente dinamico del cloud. I componenti di avvio potrebbero presumere che i contenuti del disco non possano cambiare durante l'esecuzione, che è un'ipotesi errata per gli ambienti cloud.

Questo rischio viene ridotto utilizzando la programmazione difensiva: i contenuti del disco vengono letti solo una volta utilizzando il pattern di lettura, misurazione ed esecuzione.

La revisione della sicurezza dell'immagine di Confidential Space non ha rilevato problemi TOCTOU nei componenti di fase iniziale di avvio come UEFI, Shim o GNU GRUB.

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

Questa minaccia viene attenuata da un file system principale con protezione dell'integrità.

L'integrità di Root-fs nell'immagine di Confidential Space è protetta da dm-verity. La configurazione (root-hash) viene passata in un argomento del comando del kernel, quindi misurata e attestata dal servizio di attestazione.

 All'interno dell'immagine di Confidential Space

Attacchi all'avvio del contenitore

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

Minaccia Attenuazione Implementazione della mitigazione
Un malintenzionato intercetta la connessione di rete del programma di avvio 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 immagine e controllare il codice binario del carico di lavoro. Tuttavia, queste azioni sono riportate nel log dell'attestazione.

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

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

Questa minaccia viene attenuata da una partizione scrivibile criptata e la cui integrità è protetta.

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

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

 All'interno dell'immagine di Confidential Space
Un malintenzionato modifica la configurazione del programma di lancio 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. All'interno del servizio di attestazione

Attacchi al servizio di attestazione

Questa tabella descrive le potenziali minacce e le strategie di mitigazione per il servizio di attestazione.

Minaccia Attenuazione Implementazione della mitigazione
Un malintenzionato intercetta la connessione di rete per il programma di lancio o il servizio di attestazione e legge il token segreto dalla rete.

Questa minaccia viene attenuata da una connessione TLS autenticata e criptata. Questa connessione contribuisce a proteggere il token dalle intercettazioni passive.

Un malintenzionato non può rubare l'identità del servizio perché manca la chiave TLS. Anche se l'attacco riesce, l'autore non può creare token OIDC validi.

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

 All'interno della rete tra il tuo carico di lavoro e il servizio di attestazione.
Un utente malintenzionato sfrutta le discrepanze di analisi, che comportano modifiche non rilevate nel processo di attestazione.

Questa minaccia può verificarsi perché il log eventi delle misurazioni viene serializzato e inviato al servizio di attestazione, dove viene analizzato ed elaborato.

Una discrepanza di analisi si verifica quando il servizio e il sistema operativo di runtime non sono d'accordo 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 di Confidential Space
Un malintenzionato utilizza tutte le risorse del servizio, che viene quindi interrotto in un attacco di tipo 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 e elastico che può essere facilmente replicato e scalato in base alle esigenze.

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

 All'interno del workload

Attacchi ai carichi di lavoro

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

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

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

Come tecnica di difesa in profondità, i token OIDC sono basati su ambito e di breve durata.

 All'interno dell'immagine di Confidential Space
Un utente malintenzionato legge i secret di runtime dalla console seriale. Questa minaccia è attenuata nell'immagine Confidential Space perché le credenziali e i token non vengono mai stampati nella console seriale. Inoltre, il logging su cloud è disattivato. All'interno dell'immagine di Confidential Space
Un malintenzionato aggiorna le chiavi SSH autorizzate utilizzando il pacchetto OSLogin e si connette all'istanza in esecuzione. Questa minaccia è attenuata nell'immagine Confidential Space perché i servizi systemd predefiniti sono mascherati, incluso sshd. All'interno dell'immagine di Confidential Space
Un malintenzionato aggiorna gli script di avvio nel server dei metadati, che vengono caricati automaticamente dall'agente invitato. Questa minaccia è attenuata nell'immagine Confidential Space perché il pacchetto dell'agente ospite è disattivato. All'interno dell'immagine di Confidential Space
Un malintenzionato spinge pacchetti non validi alla VM utilizzando l'agente OS Config. Questa minaccia è attenuata nell'immagine Confidential Space perché l'agente di configurazione del sistema operativo è disattivato. All'interno dell'immagine di Confidential Space
Un utente malintenzionato passa un set di dati con formato non valido e criptato al caricamento di lavoro. Questa minaccia viene attenuata inserendo nel workload codice di analisi difensiva. All'interno del workload
Un utente malintenzionato passa 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 carico di lavoro. All'interno del workload

Test di sicurezza

Confidential Space è stato sottoposto a un processo di revisione della sicurezza approfondito da parte di Google. Questa procedura di revisione della sicurezza ha incluso i seguenti test e controlli:

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

    Questi test hanno verificato che la verifica non va a buon fine in caso di misurazioni errate, ad esempio quando il codice viene eseguito in un ambiente TEE imprevisto o viene lanciato un contenitore del carico di lavoro modificato.

  • Controllo manuale del processo di avvio misurato

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

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

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

  • Controllo manuale del servizio di attestazione

    Questa revisione si è concentrata sull'implementazione del protocollo di attestazione corretto ed evitato problemi di analisi sintattica.

  • Revisione della crittografia da parte di esperti di sicurezza informatica

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

  • Revisione della privacy da parte di esperti

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

  • Test di fuzzing continui

    Questi test hanno coperto componenti fondamentali per la sicurezza, come il vTPM e il servizio di attestazione.

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