Panoramica sulla sicurezza di Confidential Space

Questo documento descrive i controlli di sicurezza di Confidential Space e come il sistema sia 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 carico di lavoro, mantenendo la riservatezza e la proprietà dei dati. Confidential Space crea l'isolamento in modo che i dati siano visibili solo al carico di lavoro e ai proprietari originali dei dati.

Puoi utilizzare Confidential Space in casi in cui non è possibile 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 le attività di riciclaggio di denaro. Confidential Space consente di analizzare i set di dati dei clienti, mantenendo al contempo private le identità dei clienti.

Componenti di un sistema Confidential Space

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

Un sistema Confidential Space ha tre componenti principali:

  • Un carico di lavoro: un'immagine containerizzata con un sistema operativo protetto 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). Puoi utilizzare questo servizio per verificare le virgolette di attestazione per il TEE e rilasciare 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 un criterio di autorizzazione che concede l'accesso a token di identità federati autorizzati. Un passaggio intermedio, utilizzando 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 ispezione e manomissioni, prima e dopo l'attestazione.

In un sistema Confidential Space, le parti coinvolte sono tre:

  • L'autore del carico di lavoro, 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 carico di lavoro, che esegue il carico di lavoro in un progetto Google Cloud. In genere l'operatore ha privilegi amministrativi completi per il progetto. L'operatore può gestire risorse Google Cloud come istanze, dischi e regole di networking di Compute Engine e può interagire con qualsiasi API di Google Cloud che agisca 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 della risorsa (o i collaboratori dei dati) proprietari della risorsa protetta. Un proprietario di una 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 né modificare il codice autonomamente.

Confidential Space supporta un modello di attendibilità in cui l'autore dei carichi di lavoro, l'operatore del carico di lavoro e i proprietari delle risorse sono parti separate e disattendibilità reciproca.

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 trattamento sicuro dei dati

Confidential Space ti consente di preservare la privacy dell'utente durante la condivisione dei dati. La tabella seguente 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 Roberto, 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 programma binario con Bob. Alice configura il 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 nel Cloud Storage di Roberto.
Calcolo multi-parti Nel calcolo multi-parti, Alice e Bob vogliono condividere tra loro i risultati, preservando al contempo 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 dei loro progetti. È coautore di un programma che determina i risultati e lo esegue in un Confidential Space. Alice e Bob configurano il 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 il concetto di quote delle chiavi. Una condivisione della chiave è una chiave privata suddivisa tra Alice, Bob e altri proprietari, in modo che la conoscenza delle singole condivisioni non consenta l'accesso al set di dati criptato. In questo schema, l'attendibilità è 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 assicura che nessuno possa eseguire operazioni non controllate su dati che non sono di sua proprietà. I proprietari dei dati controllano come vengono utilizzati i loro dati e quali carichi di lavoro sono autorizzati ad agire su di essi.

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

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

  • Un processo di attestazione rileva le modifiche all'immagine del carico di lavoro o al relativo TEE. Questo controllo aiuta a proteggere la pre-attestazione dell'integrità del carico di lavoro.
  • Un'immagine di base protetta contribuisce a ridurre la superficie di attacco e a impedire all'operatore del carico di lavoro di accedere all'istanza o di comprometterla in fase di runtime. Questo controllo aiuta a proteggere l'integrità e la riservatezza di un carico di lavoro dopo l'attestazione. Insieme, questi controlli di sicurezza aiutano a proteggere il carico di lavoro, i relativi secret e i dati elaborati.

Procedura di attestazione

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

Le misurazioni riguardano i componenti di fase iniziale di avvio, il kernel caricato e l'immagine del container. Inoltre, includono proprietà di ambiente, come un flag che indica che l'istanza è una Confidential VM. 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 la partecipazione di ogni componente al processo di attestazione.

Componenti e parti del sistema coinvolti 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 Confidential Space attestata: un'immagine protetta basata su Container-Optimized OS che viene letta dal disco di avvio collegato.
  • Componenti di avvio precoce: bootloader e kernel che interagiscono con il vTPM per misurare i componenti di avvio in un registro di configurazione della piattaforma (PCR).

  • Avvio app: un componente che scarica il programma binario del carico di lavoro dal repository di immagini e misura il container e la sua configurazione in una PCR. Avvio app legge la sua configurazione dal server di metadati dell'istanza.

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

  • Il servizio di attestazione: è un servizio che verifica il preventivo, riproduce il log eventi, emette il token OIDC e restituisce il token con gli attributi per il criterio di accesso ai carichi di lavoro.

Immagine protetta

L'immagine di Confidential Space è un sistema operativo minimo e monouso. L'immagine esegue l'Avvio app container, che a sua volta avvia un singolo container. L'immagine di 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 Confidential Space include le seguenti partizioni:
    • Una partizione root-fs e una partizione OEM che include il file binario di Avvio applicazioni. Queste partizioni sono immutabili e protette da dm-verity.
    • Una partizione temporanea scrivibile che archivia 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 è disabilitato, il che contribuisce a impedire a un sistema operativo configurato in modo errato di archiviare i dati su disco.
  • Connessioni di rete autenticate e criptate:l'Avvio app utilizza TLS per autenticare il servizio di attestazione e proteggere i suoi link di comunicazione.
  • Varie misure di avvio: queste misurazioni includono gli argomenti della riga di comando del kernel, la configurazione dm-verity per root-fs e il programma binario del carico di lavoro.

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

  • Transizioni di stato ridotte: ad esempio, l'Avvio app esegue un singolo container e poi si arresta.

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 UEFI (Unified Extensible Firmware Interface) guest, al bootloader e al kernel delle immagini Confidential Space, al runtime del container e a dipendenze di terze parti per il carico di lavoro. I collaboratori dei dati presumono che i proprietari delle risorse abbiano esaminato e controllato l'immagine container prima che i proprietari delle risorse condividano la loro risorsa con un criterio di autorizzazione.
  • Attacchi a Google Cloud, ad esempio escape delle VM.

Possibili attacchi

Confidential Space è progettato per difendersi da tre possibili attacchi:

  • Un operatore dannoso dei carichi di lavoro: un operatore dannoso dei carichi di lavoro può modificare i contenuti dei dischi, intercettare le connessioni di rete e tentare di compromettere il TEE in fase di runtime. Un operatore malintenzionato può espandere la superficie di attacco o limitare l'ambiente di runtime. Ad esempio, un operatore dannoso può aggiungere una console seriale per introdurre nuovi vettori d'attacco. Per fare un altro esempio, un operatore dannoso può limitare le risorse, ad esempio limitando le dimensioni della memoria di un guest, modificando lo spazio su disco o le regole firewall. Questi vincoli potrebbero attivare errori di I/O che potrebbero portare a casi di errore testati male.
  • Un client di attestazione dannoso:questo utente malintenzionato si connette al servizio di attestazione e invia messaggi del log eventi non corretti ancora firmati.
  • Un proprietario di risorse dannose:il proprietario di una risorsa malintenzionato ha il controllo completo sul set di dati criptato utilizzato dal carico di lavoro. Questo utente malintenzionato potrebbe presentare input non corretti o dati distorti e tentare di attivare l'analisi delle vulnerabilità nel carico di lavoro o tentare di eludere i relativi controlli per la privacy.

Superfici di attacco

La seguente tabella descrive le piattaforme di attacco a disposizione degli utenti malintenzionati.

Attaccante Destinazione Superficie d'attacco Rischi
Operatore del carico di lavoro TEE, carico di lavoro Letture disco

Qualsiasi lettura dal disco è sotto il controllo dell'utente malintenzionato.

Servizi come dischi permanenti multi-writer e collegamenti ai dischi dinamici consentono a un utente malintenzionato di modificare i contenuti dei dischi in modo dinamico e a piacimento.
Operatore del carico di lavoro TEE, carico di lavoro Scritture disco Qualsiasi elemento scritto su disco è visibile a un utente malintenzionato. Consulta la sezione relativa agli snapshot dei dischi e alle funzionalità di import.
Operatore del carico di lavoro TEE, carico di lavoro Server dei metadati Gli attributi delle istanze letti dal server di metadati sono sotto il controllo dell'utente malintenzionato, inclusi lo script di avvio e le variabili di ambiente.
Operatore del carico di lavoro TEE, carico di lavoro Rete Le connessioni di rete esterne al repository di immagini o al servizio di attestazione possono essere intercettate. Questo attacco viene eseguito utilizzando un VPC privato con un'istanza di router Cloud rivolta al pubblico.
Client di attestazione Servizio di attestazione Log eventi e messaggi di attestazione Il servizio di attestazione ha una logica complessa e ad alto utilizzo di criptovalute, che è difficile da scrivere in modo difensivo.
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 Confidential VM, 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 ogni 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 i tecnici è limitato, controllato e transparent per i clienti. Inoltre, la crittografia della memoria incorporata in Confidential VM aiuta 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 sulla sicurezza di Google.

Minacce e mitigazioni

Un file system criptato con protezione dell'integrità è progettato per mitigare i rischi derivanti dagli attacchi ai dischi. Inoltre, una volta letto il codice dal disco, il codice viene misurato e i dati non vengono mai riletti dal disco. I secret non vengono mai divulgati in formato testo non crittografato al disco o a dispositivi esterni come una console seriale.

I rischi derivanti dagli attacchi di rete sono mitigati grazie alla crittografia end-to-end autenticata. L'accesso alla rete esterna, ad esempio SSH, è disabilitato nell'immagine. Un protocollo di attestazione aiuta a proteggere la sequenza di avvio e qualsiasi configurazione letta dal server dei metadati. Infine, i carichi di lavoro Confidential Space dovrebbero utilizzare controlli per la privacy differenziali per mitigare i rischi derivanti da set di dati distorti.

Le seguenti tabelle descrivono le minacce e le mitigazioni:

Attacchi al processo di avvio misurato

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

Minaccia Attenuazione Implementazione della mitigazione

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

In caso di esito positivo, un utente malintenzionato può riprodurre misurazioni arbitrarie e annullare l'attestazione remota.

Questa minaccia è mitigata dal piano di controllo di Google Cloud.

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

 All'interno dell'infrastruttura Google Cloud

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

In caso di esito positivo, un utente malintenzionato può riprodurre misure arbitrarie e annullare l'attestazione remota.

 Questa minaccia è mitigata dall'hypervisor. Al riavvio dell'ospite, l'hypervisor carica una copia pulita del firmware UEFI nella memoria guest. Le modifiche precedenti alla memoria guest vengono ignorate. Inoltre, il riavvio come ospite è l'unico evento che reimposta il vTPM. All'interno di Google Cloud e abilitando il Confidential Computing
Un utente malintenzionato modifica file di configurazione non misurate, con un effetto negativo sull'esecuzione del programma.

Questa minaccia è mitigata dal processo di attestazione. Tutti i programmi binari eseguibili e i rispettivi file di configurazione vengono misurati completamente prima dell'esecuzione.

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

Dal controllo della sicurezza è emerso che non sono state mancate misurazioni durante il processo di attestazione.

 Immagine In the Confidential Space
Un utente malintenzionato attiva vulnerabilità di danneggiamento della memoria nei componenti di avvio anticipato e ottiene l'esecuzione del codice.

I componenti di avvio iniziali 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 è ridotto dal processo di attestazione: i componenti di fase iniziale di avvio devono misurare tutti i dati controllati dagli utenti prima di elaborarli. Un attacco BootHole utilizza un grub.cfg modificato per ottenere l'esecuzione del codice e annullare l'avvio protetto.

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

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

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

Immagine In the Confidential Space
Un utente malintenzionato modifica i programmi binari di fase iniziale di avvio su disco dopo che sono stati letti e misurati, prima che vengano letti ed eseguiti (disco TOCTOU).

I componenti di avvio iniziali erano per macchine bare metal e potrebbero non aspettarsi 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'ipotesi errata per gli ambienti cloud.

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

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

 Immagine In the Confidential Space
Un utente malintenzionato modifica i driver del dispositivo e i servizi in modalità utente su disco dopo il caricamento del kernel.

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

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

 Immagine In the Confidential Space

Attacchi ad Avvio app container

Questa tabella descrive le potenziali minacce e le strategie di mitigazione relative all'avvio app.

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 utente malintenzionato può modificare l'URL dell'immagine e controllare il programma binario del carico di lavoro. Tuttavia, queste azioni si riflettono nel log di attestazione.

Il repository di immagini non è controllato utilizzando un elenco per gli accessi, pertanto si presume che l'immagine sia visibile a tutti. Devi assicurarti che l'immagine container del carico di lavoro non contenga secret.

 Immagine In the Confidential Space
Un utente malintenzionato modifica l'immagine del carico di lavoro su disco dopo che è stata scaricata e misurata.

Questa minaccia è mitigata da una partizione scrivibile criptata e la sua integrità è protetta.

L'immagine del carico di lavoro e i relativi dati temporanei sono protetti da dm-crypt mediante chiavi temporanee di avvio.

Il processo di crittografia del disco dm-crypt consente attacchi di rollback in base ai quali un utente malintenzionato sostituisce i contenuti del disco con testi criptati e tag rilevati in precedenza. Questi attacchi sono considerati molto complessi nelle impostazioni di Confidential Space.

 Immagine In the Confidential Space
Un utente malintenzionato modifica la configurazione dell'Avvio app nel server di metadati e controlla l'URL del repository di immagini. Il processo 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 al servizio di attestazione.

Minaccia Attenuazione Implementazione della mitigazione
Un malintenzionato intercetta la connessione di rete per l'avvio app o il servizio di attestazione e legge il token segreto dal cavo.

Questa minaccia è mitigata grazie a una connessione TLS autenticata e criptata. Questa connessione aiuta a proteggere il token dalle intercettazioni passive.

Un utente malintenzionato non può impersonare il servizio perché manca la chiave TLS. Anche se l'operazione va a buon fine, l'utente malintenzionato non può creare token OIDC validi.

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

 All'interno della rete tra il carico di lavoro e il servizio di attestazione.
Un utente malintenzionato sfrutta le discrepanze di analisi, il che comporta 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 in esecuzione 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 il ,d nella sottostringa del valore) potrebbe essere analizzata in modo diverso dal kernel e dal servizio.

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

 Immagine In the Confidential Space
Un utente malintenzionato utilizza tutte le risorse di servizio, causando così un attacco denial of service (DoS). Il servizio è interrotto per gli altri utenti di Confidential Space.

Questo rischio di affidabilità è mitigato disponendo di un servizio distribuito ed elastico che può essere facilmente replicato e ridimensionato secondo necessità.

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

 All'interno del carico di lavoro

Attacchi ai carichi di lavoro

Questa tabella descrive le potenziali minacce e le 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 è mitigata con un file system criptato. Il file system scrivibile viene montato utilizzando dm-crypt. Lo scambio è disabilitato e i contenuti della memoria non vengono impaginati sul disco.

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

 Immagine In the Confidential Space
Un utente malintenzionato legge i secret di runtime dalla console seriale. Questa minaccia è mitigata nell'immagine di Confidential Space perché le credenziali e i token non vengono mai stampati sulla console seriale. Inoltre, il cloud logging è disabilitato. Immagine In the Confidential Space
Un utente malintenzionato aggiorna le chiavi SSH autorizzate utilizzando il pacchetto OSLogin e si connette all'istanza in esecuzione. Questa minaccia è mitigata nell'immagine Confidential Space perché i servizi systemd predefiniti sono mascherati, tra cui sshd. Immagine In the Confidential Space
Un utente malintenzionato aggiorna gli script di avvio nel server dei metadati, che vengono caricati automaticamente dall'agente guest. Questa minaccia è mitigata nell'immagine Confidential Space perché il pacchetto di agenti guest è disabilitato. Immagine In the Confidential Space
Un utente malintenzionato esegue il push di pacchetti dannosi sulla VM utilizzando l'agente OS config. Questa minaccia è attenuata nell'immagine Confidential Space perché l'agente di configurazione del sistema operativo è disabilitato. Immagine In the Confidential Space
Un utente malintenzionato trasmette al carico di lavoro un set di dati criptato e criptato. Questa minaccia viene mitigata inserendo un codice di analisi difensivo nel carico di lavoro. All'interno del carico di lavoro
Un utente malintenzionato trasmette al carico di lavoro un set di dati alterato o avvelenato e tenta di acquisire informazioni sui set di dati da altre parti. Questa minaccia viene mitigata implementando controlli di privacy differenziali nel carico di lavoro. All'interno del carico di lavoro

Test di sicurezza

Confidential Space è stato sottoposto a una procedura completa di revisione della sicurezza in Google. Questo processo di revisione della sicurezza includeva i seguenti test e controlli:

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

    Questi test hanno verificato che l'attestazione non va a buon fine in caso di misurazioni errate, ad esempio quando il codice viene eseguito in un ambiente TEE imprevisto o avvia un container di carichi di lavoro modificato.

  • Controllo manuale del processo di avvio misurato

    Questa recensione si concentrava sull'identificazione delle misurazioni mancanti e dei bug di doppia lettura. I test hanno verificato che il codice è stato scritto in base alle best practice di sicurezza e, quando si è verificato un errore, il codice è stato chiuso (arresto).

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

    Questa recensione si è concentrata sulla rimozione dei pacchi e sulla riduzione della superficie di attacco.

  • Controllo manuale del servizio di attestazione

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

  • Revisione della crittografia da parte di esperti di cybersicurezza

    Questa recensione è incentrata sul protocollo di attestazione, sulla crittografia del file system e sulle soluzioni per l'integrità.

  • Revisione della privacy da parte di esperti della privacy

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

  • Test continui del fuzz

    Questi test hanno riguardato componenti critici per la sicurezza, come vTPM e servizio di attestazione.

NCC Group, un'organizzazione esterna per i test, ha eseguito test di penetrazione nel sistema. NCC ha esaminato Confidential Space come piattaforma di computing sicura.

Passaggi successivi