Questi contenuti sono stati aggiornati per l'ultima volta a settembre 2024 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.
L'architettura di sicurezza hardware Titanium funge da base per i servizi di Google e supporta molte delle contromisure di sicurezza nell'infrastruttura di Google. L'hardware Titanium include microcontroller di sicurezza, adattatori hardware e processori di offload sviluppati appositamente per affrontare vettori di attacco specifici per l'infrastruttura di Google.
L'hardware Titanium è l'ultimo avanzamento dell'infrastruttura di sicurezza completa e in continua evoluzione di Google e contribuisce a proteggere l'integrità, la riservatezza e la disponibilità dei dati utente. L'hardware Titanium si basa su un'infrastruttura come le schede di offload hardware crittografico che forniscono la crittografia in transito e i microservizi interni che forniscono la crittografia dei dati at-rest.
Questo documento descrive in che modo i componenti hardware di Titanium collaborano per creare un'architettura di sicurezza che contribuisce a proteggere la superficie di attacco fisica dei sistemi Google e a mitigare le minacce ai dati dei clienti. Questo documento descrive anche come l'hardware Titanium abilita controlli di sicurezza specifici a livello software, l'evoluzione dell'architettura oltre agli scarichi hardware crittografici iniziali e le minacce reali che l'architettura di sicurezza hardware Titanium è progettata per mitigare nella base di clienti e deployment di Google.
Architettura di sicurezza hardware Titanium
L'architettura di sicurezza hardware Titanium è progettata per difendersi da una gamma di scenari e autori di minacce. Il seguente diagramma dell'architettura mostra i componenti indipendenti, ma interconnessi, di Titanium.
L'architettura di sicurezza hardware Titanium include i seguenti componenti:
- Radice di attendibilità per la misurazione (RTM) Caliptra: contribuisce a imporre un perimetro di sicurezza per ogni pacchetto di silicio. Caliptra RTM fornisce l'attestazione e un ID univoco ai servizi di crittografia root.
- Chip Titan RoT: si interpone tra la memoria flash di avvio di una piattaforma e i suoi dispositivi di avvio principali, come il controller di gestione della scheda madre (BMC), l'hub del controller della piattaforma (PCH) e la CPU. I chip Titan forniscono una radice di attendibilità (RoT) basata su hardware fisicamente resistente alla manomissione che contribuisce a stabilire un'identità solida. I chip Titan aiutano anche con l'autorizzazione e la revoca del codice per macchine, schede o periferiche.
- Processore di offload Titanium (TOPS): fornisce controlli crittografici per proteggere la riservatezza e l'integrità dei dati a riposo e dati in transito.
- Schede madri personalizzate: offrono resilienza su larga scala contro gli attacchi DoS da software difettoso o dannoso, nonché protezione contro gli attacchi fisici. Nel diagramma, ad esempio, il pacchetto del chip e Titan RoT si trovano su una scheda madre personalizzata separata dalle schede madri personalizzate per Titanium TOP o dalle schede madri per altre infrastrutture.
- Enclave di Confidential Computing: contribuiscono a imporre l'isolamento dai privilegi amministrativi di Google, migliorano l'isolamento con altri tenant e aggiungono la verificabilità tramite l'attestazione. L'attestazione può garantire che l'ambiente non sia stato alterato.
- Servizi regionalizzati di backend a tolleranza di errore: contribuiscono a prevenire l'escalation dei privilegi tra servizi, zone o dall'accesso amministrativo.
Nel diagramma, Altra infrastruttura si riferisce a fabric di rete e spazio di archiviazione di backend replicato.
Principi di progettazione dell'architettura di sicurezza hardware Titanium
I nostri componenti hardware Titanium e le loro interazioni sono sviluppati in base ai seguenti principi fondamentali:
Nessun single point of failure: l'architettura di Google è progettata per evitare single point of failure, ad esempio singoli componenti portanti con più responsabilità. Building Secure and Reliable Systems illustra l'importanza di evitare single point of failure. Questo principio viene applicato in tutta la nostra infrastruttura fisica, in tutte le regioni e persino al silicio dei chip. Questa resilienza in tutta la nostra infrastruttura globale contribuisce a mantenere i dati dei clienti sicuri e disponibili.
Ad esempio, la migrazione live con Confidential Computing consente di preservare la memoria criptata sulle macchine host supportate. La migrazione live contribuisce a garantire che una VM a lunga esecuzione non sia un unico punto di errore a causa di eventi di manutenzione o risposta a vulnerabilità.
Il perimetro è il pacchetto di silicio: poiché un sistema server contiene più system-on-chip interconnessi e separati, la nostra architettura non si fida fondamentalmente di tutti i connettori, i tessuti, gli assiemi di schede di circuiti stampati (PCBA), le tracce PCBA e i cavi. Sebbene la separazione dei componenti sia utile per la modularità, può anche diventare un punto debole quando offre agli avversari target ben definiti da cui spiare i dati in testo non crittografato. I dati all'interno del pacchetto di silicio stesso vengono criptati e autenticati da asset crittografici privati all'interno del pacchetto.
Spostare il perimetro all'interno del silicio stesso contribuisce a ridurre al minimo la fiducia implicita. Questo principio affronta le minacce alla riservatezza dei dati che si verificano man mano che le condizioni di servizio dei data center diventano sempre più diverse. Ad esempio, l'impostazione del perimetro nel pacchetto di silicio aiuta a contrastare le minacce derivanti da operazioni hardware non autorizzate.
Zero Trust e compartimentazione del rischio: i controlli multi-party sulle azioni amministrative contribuiscono a garantire che nessun account del personale (o account del personale compromesso) possa causare unilateralmente le minacce discusse in questo documento. L'architettura separa i servizi in livelli e zone per compartimentare e contenere il rischio. Anche con le enclave, che in genere sono basate sull'hardware, l'architettura tiene conto del rilevamento delle vulnerabilità hardware e della necessità di eseguire la correzione mentre i componenti rimangono in funzione.
Ad esempio, se un malintenzionato compromette il comportamento di un chip all'interno di un sistema attivo che esegue carichi di lavoro dei clienti nei nostri data center, l'architettura è progettata per identificare e isolare il chip compromesso. La macchina può quindi essere ritirata dal servizio. Anche se la macchina non viene ritirata dal servizio, l'autore dell'attacco deve superare ulteriori limiti di attendibilità e compromettere più credenziali per spostarsi lateralmente e ottenere influenza su ulteriori sistemi, utenti o regioni.
Domini di errore indipendenti e tecnologie di isolamento contribuiscono a limitare l'area interessata da un attacco. Questi domini e tecnologie aggiungono punti di controllo naturali per il rilevamento e limitano la quantità di complessità aggiuntiva che deve essere introdotta.
Per ulteriori informazioni sulla nostra implementazione di Zero Trust, consulta BeyondProd.
Sicurezza trasparente: Google investe in diverse iniziative di trasparenza, tra cui l'open source, la divulgazione responsabile di ricerche e risultati e la collaborazione con l'ecosistema dei produttori di hardware. L'infrastruttura globale di Google applica il principio di Kerckhoffs, secondo cui un sistema crittografico deve essere sicuro, anche se tutto ciò che riguarda il sistema, tranne la chiave, è di dominio pubblico.
Ad esempio, contribuiamo a progetti open source e li utilizziamo nei nostri progetti hardware di sicurezza e nel nostro software di sicurezza. La tabella seguente descrive alcuni dei progetti open source a cui contribuiamo e che utilizziamo.
Progetto open source Descrizione Componente in titanio Utilizzato nelle librerie di crittografia FIPS 140-3 livello 1
BoringSSL
Utilizzato nelle radici di attendibilità (RoT) a livello di silicio
Caliptra RTM
Utilizzato in RoT per un chip in un'architettura di sistema
Chip Titan
Utilizzato per il fuzzing del kernel guidato dalla copertura
Distribuzioni VM host ring0 e utente
Utilizzato nelle librerie di crittografia FIPS 140-3 livello 1
Processore di offload Titanium
Difesa fisica e logica in profondità: Google si affida alla sicurezza fisica dei data center per proteggere i propri investimenti di capitale e i propri sistemi. Questi controlli di sicurezza sono un livello di difesa iniziale, quindi investiamo deliberatamente in controlli logici aggiuntivi per rafforzare i nostri sistemi contro le minacce fisiche. Titanium si aggiunge alla nostra difesa in profondità aggiungendo la compartimentazione nel nostro hardware che fornisce difese aggiuntive contro minacce specifiche all'infrastruttura.
Ad esempio, i nostri data center sono dotati di metal detector in grado di rilevare con precisione i tentativi di esfiltrazione di supporti di archiviazione. Tuttavia, la nostra strategia di crittografia dei dati inattivi è progettata appositamente per non fare affidamento sulla custodia di supporti fisici. Questi controlli logici e fisici sono livelli indipendenti e complementari.
I nostri controlli di sicurezza fisici e logici combinati ci aiutano a rimanere vigili contro le minacce interne e a proteggere la riservatezza dei dati dei nostri utenti.
Vantaggi per la sicurezza dei componenti architetturali di Titanium
La tabella seguente evidenzia alcuni importanti vantaggi per la sicurezza ottenuti con i componenti dell'architettura di sicurezza Titanium, sia a livello hardware che software. Questi vantaggi in termini di sicurezza sono descritti in modo più dettagliato nelle sezioni seguenti.
| Vantaggi di sicurezza | Componente dell'architettura |
|---|---|
Perimetro di attendibilità a livello di silicio su system on chip (SoC) come CPU o GPU |
Caliptra RTM |
Verificabilità a livello di silicio |
Caliptra RTM |
Identità crittografica a livello hardware |
Caliptra RTM, Titan RoT |
Verifica che i binari previsti siano in esecuzione |
Caliptra RTM, Titan RoT |
Mitigazione delle minacce persistenti durante gli avvii |
Caliptra RTM, Titan RoT |
Protezione della riservatezza dei dati at-rest e in transito |
TOP per la crittografia |
Scaricamento della protezione a livello di processore (oltre a una carta fisica) |
TOP per la crittografia |
Funzionalità di sicurezza by design, resistenza agli attacchi fisici e resilienza che supportano il ripristino completo del firmware di sistema da una singola radice di attendibilità (RoT) Titan |
Schede madri personalizzate |
Schede appositamente progettate con solo i connettori essenziali, che contribuiscono a mitigare i tentativi di manomissione fisica |
Schede madri personalizzate |
Isolamento del carico di lavoro crittografico dal software di sistema a livello di macchina e accesso amministrativo umano |
Enclave di Confidential Computing |
Resistenza alla manomissione tramite la crittografia DRAM (per abilitare la crittografia dei dati in uso) |
Enclave di Confidential Computing |
Area interessata e paratia ridotte al minimo per un malintenzionato con accesso locale |
Servizi regionalizzati di backend a tolleranza di errore |
Più livelli di compartimentazione |
Servizi regionalizzati di backend a tolleranza di errore |
Radice di attendibilità per la misurazione Caliptra
Caliptra RTM contribuisce a creare fiducia e trasparenza per il firmware all'interno del nostro ecosistema che viene eseguito su system-on-chip (SoC) come CPU, GPU e TPU.
Caliptra RTM offre i seguenti vantaggi:
- Fornisce un servizio di crittografia root: Caliptra RTM aiuta a rilevare codice e configurazione critici danneggiati tramite una verifica dell'integrità crittografica end-to-end avanzata. Caliptra RTM può misurare crittograficamente il proprio codice e la propria configurazione, firmare queste misurazioni con una chiave di attestazione univoca e protetta dall'hardware e segnalare le misurazioni che attestano l'autenticità e l'integrità del dispositivo. Caliptra RTM fornisce un'identità del dispositivo crittografica e un insieme di misure di integrità del firmware e della configurazione per la scheda madre.
- Mitiga la sicurezza della catena di fornitura fisica: Caliptra RTM contribuisce a garantire che l'hardware sia autentico e che esegua il firmware e il software previsti. In combinazione con la sicurezza della catena di fornitura del software, Caliptra RTM consente al sistema di verificare l'autenticità e l'integrità del firmware e del software, indipendentemente dal fatto che siano stati creati da Google o da terze parti. Questa procedura di verifica consente a Caliptra RTM di mantenere l'autenticità e l'integrità negli aggiornamenti autorizzati e contribuisce a garantire che le configurazioni rimangano come previsto e siano attestate.
- Protegge dalle intrusioni fisiche che richiedono l'accesso diretto all'hardware in esecuzione: poiché Caliptra RTM è integrato nei livelli di silicio del chip, un interposer PCBA o un chip non autorizzato che tenta di fornire il firmware errato a un circuito integrato specifico per l'applicazione (ASIC) non può attaccare correttamente la RoT. Ad esempio, gli autori degli attacchi possono bypassare le funzionalità di rilevamento di una RoT esterna manomettendo il bus SPI a velocità relativamente bassa. Tuttavia, una RoT incorporata in un SoC o ASIC diventa più difficile da compromettere per un malintenzionato.
Radice di attendibilità del chip Titan
Titan è progettato per mantenere crittograficamente l'identità del dispositivo, difendersi dall'installazione di software dannoso e garantire l'autenticità del codice tramite la revoca.
Un'identità di dispositivo crittografica sicura contribuisce a garantire che il parco risorse sia composto esclusivamente da macchine convalidate che eseguono i file binari previsti e che possono identificare e autenticare l'accesso legittimo. L'accesso legittimo è radicato a livello hardware.
Per impostazione predefinita, le macchine di produzione utilizzano l'avvio attendibile per garantire che possa essere eseguito solo software autenticato. L'avvio attendibile verifica la firma digitale di tutti i componenti di avvio e non consente a una macchina di partecipare all'ambiente di produzione se l'autenticazione non riesce.
Come controllo preventivo aggiuntivo, la revoca del codice macchina impedisce l'applicazione di modifiche software non più autorizzate. La funzionalità di revoca nei chip Titan contribuisce a mitigare non solo gli attacchi dannosi (ad esempio, gli attacchi di rollback o replay), ma anche i bug di stabilità o resilienza non dannosi (ad esempio, impedendo la reinstallazione accidentale di firmware precedenti con bug).
Per ulteriori informazioni, consulta la sezione Come Google impone l'integrità dell'avvio sulle macchine di produzione.
Processori di offload Titanium per la crittografia
I processori di offload Titanium (TOP) per la crittografia contribuiscono a garantire la sicurezza durante l'offload di I/O. Questi TOP sono protetti con Titan o Caliptra RTM. I TOP implementano una crittografia autenticata diffusa dei dati in transito e una crittografia autenticata dei dati a riposo a basso costo. La crittografia autenticata indica che i dati dei clienti hanno la garanzia crittografica di riservatezza e integrità. Poiché i TOP gestiscono la crittografia, privano molti componenti di sistema dei privilegi. I TOP consentono di migliorare le proprietà architetturali, come la disponibilità, riducendo al minimo il potenziale di perdita di segretezza dei dati.
Schede madri personalizzate
Le schede madri personalizzate nell'infrastruttura di Google sono progettate per fornire provenienza hardware. Le schede madri supportano l'attestazione a più livelli. I design delle schede madri proteggono i dati dei clienti, anche nell'eventualità altamente improbabile che un malintenzionato colleghi fisicamente un dispositivo dannoso a una macchina. I design della scheda madre Titanium contribuiscono a consentire l'implementazione affidabile di meccanismi di hardening aggiuntivi, come porte di debug spopolate, console seriali di sola lettura, intrusione del connettore del bus e segnalazione di estrusione.
TLS e ALTS sono gli unici protocolli accettati esposti dal nostro stack di rete BMC quando una macchina è accesa. Per le macchine che utilizzano un design COTS di terze parti, come le nostre istanze X4, TOP esegue il proxy di qualsiasi traffico di gestione univoco per quel design di terze parti. Il proxy del traffico di gestione significa che la nostra infrastruttura non dipende da progetti di terze parti per l'autenticazione, l'autorizzazione, la sicurezza del trasporto o la sicurezza di rete.
Le schede madri personalizzate Titanium sono progettate per avere meccanismi di backup e ripristino integrati per garantire disponibilità e recuperabilità. Possono ripristinarsi dalla maggior parte degli arresti anomali o dal danneggiamento del firmware. I nostri ultimi progetti consentono di ricostruire l'intera macchina da un singolo Titan RoT funzionante. Queste schede madri utilizzano componenti di alimentazione e segnalazione di ripristino dedicati alle funzionalità per contribuire a garantire l'indipendenza elettrica delle radici di attendibilità Titan dal resto della piattaforma e a proteggere il loro controllo sui payload del firmware della piattaforma per scopi di autenticazione e ripristino.
Enclave di Confidential Computing
Confidential Computing crea un Trusted Execution Environment (TEE) o un enclave per isolare i workload sensibili dei clienti dall'accesso amministrativo di Google. Quando i dati vengono gestiti dalla CPU o dalla GPU, Confidential Computing fornisce un controllo preventivo tecnico tramite l'isolamento del calcolo e la crittografia in memoria. Confidential Computing contribuisce a garantire che anche un hypervisor dannoso non possa accedere a una VM. Per i workload dei clienti, Confidential Computing fornisce un livello di isolamento della segretezza dei dati dalla possibilità di accesso involontario del personale di Google o di azioni errate del software di sistema automatizzato su larga scala.
Un esempio di sicurezza avanzata abilitata dall'architettura Titanium è la modalità Confidential per Hyperdisk Balanced. La modalità Confidential per Hyperdisk Balanced combina l'offload dell'archiviazione a blocchi basata su Titanium, Confidential Computing e Cloud HSM per creare un TEE basato su hardware. In altre parole, la modalità Confidential per Hyperdisk Balanced è un'offerta hyperdisk-balanced. La modalità Confidential per Hyperdisk Balanced isola l'infrastruttura in modo che le chiavi sensibili vengano elaborate esclusivamente in un TEE basato su hardware. Per informazioni sulla revisione di terze parti delle operazioni crittografiche, consulta Report pubblico - Modalità confidenziale per Hyperdisk - Analisi della protezione DEK.
Servizi regionalizzati di backend a tolleranza di errore
I servizi regionalizzati di backend a tolleranza di errore contribuiscono a ridurre al minimo l'area interessata da un attaccante con accesso locale. L'infrastruttura Google è progettata per compartimentare servizi, sistemi e zone dal movimento laterale di insider privilegiati o servizi compromessi.
Stiamo lavorando per includere le informazioni regionali in un insieme sempre più ampio dei nostri sistemi interni di gestione dell'identità e dell'accesso. Le informazioni regionali rafforzano l'isolamento crittografico, in modo che un malintenzionato che ottiene l'accesso locale debba compromettere più credenziali di servizi infrastrutturali distinti per continuare a spostarsi lateralmente.
Se un attacco attiva un controllo preventivo che rimuoverebbe una macchina di produzione dall'ambiente (ad esempio, causerebbe lo spegnimento del sistema), la nostra infrastruttura di backend tollerante agli errori contribuisce a garantire la continua disponibilità di dati e servizi dei clienti su macchine vicine. Per saperne di più sui nostri controlli dell'infrastruttura, consulta BeyondProd e Come Google protegge i suoi servizi di produzione.
Vettori d'attacco per l'infrastruttura Google Cloud
Questa sezione descrive minacce fisiche e logiche specifiche che costituiscono parte della superficie di attacco di Google Cloud. L'architettura di sicurezza hardware Titanium è progettata specificamente per affrontare una serie unica di minacce all'infrastruttura di Google e ai dati utente che memorizziamo.
Minacce all'infrastruttura
L'architettura Titanium è progettata per difendersi da più categorie di minacce:
- Addetto interno non autorizzato con accesso fisico: il nostro personale ha bisogno di accedere ai dispositivi fisici nei data center per implementare, gestire e riparare l'hardware. Questo accesso rappresenta un potenziale vettore d'attacco perché personale o appaltatori malintenzionati hanno un motivo aziendale legittimo per riparare fisicamente alcune macchine nei nostri data center.
Addetto interno non autorizzato con accesso logico: analogamente all'accesso fisico al data center, il personale è tenuto a sviluppare, gestire, testare, eseguire il debug, ottimizzare e supportare più livelli dello stack software di Google. Queste figure includono sviluppatori, SRE e ingegneri cloud a contatto con i clienti.
Per ulteriori informazioni sulle nostre difese contro questa minaccia, consulta la pagina Come Google protegge i suoi servizi di produzione.
Attaccante esterno con accesso logico: gli attaccanti esterni possono ottenere un punto d'appoggio all'interno di un ambiente Google Cloud e tentare di trasferirsi lateralmente ad altre macchine per ottenere l'accesso a dati sensibili. Una tattica comune utilizzata dagli aggressori esterni è quella di iniziare compromettendo un account di personale o collaboratore legittimo.
Il seguente diagramma mostra la parte dell'ambiente cloud più vulnerabile a queste minacce.
Superficie di attacco ai server del data center
La seguente tabella descrive le superfici di attacco tipiche dei server dei data center. L'architettura di sicurezza hardware Titanium è progettata per fornire difese efficaci contro queste minacce.
| Attaccante | Target | Superficie di attacco | Rischio |
|---|---|---|---|
Addetto ai lavori malintenzionato con accesso fisico |
Supporti di archiviazione (SSD, HDD o unità di avvio) |
Unità fisiche e connettori |
Questo attacco potrebbe rubare un'unità e tentare di accedervi con gli strumenti dell'aggressore. |
DIMM |
Connettori di memoria fisica |
Questo attacco potrebbe bloccare il DIMM, estrarlo dal data center e tentare di accedere ai dati contenuti utilizzando gli strumenti dell'attaccante. Questa minaccia a volte è chiamata attacco di riavvio a freddo. |
|
Server |
Connettori USB o PCIe |
Questo attacco potrebbe connettere hardware dannoso al server. Utilizzando l'hardware dannoso, l'attaccante potrebbe tentare di ottenere l'esecuzione di codice o esfiltrare i dati residenti. |
|
Scheda madre |
Joint Test Action Group (JTAG) eXtended Debug Port (XDP) |
Questo attacco potrebbe connettere uno strumento di debug hardware per ottenere l'esecuzione del codice o l'accesso ai dati elaborati sulla CPU. |
|
Rete |
Cavi Ethernet |
Questo attacco potrebbe intercettare un cavo Ethernet per accedere a tutti i dati trasferiti tra i dispositivi. Qualsiasi traffico con testo in chiaro potrebbe essere osservato. |
|
Scheda madre |
Firmware |
Questo attacco potrebbe introdurre firmware dannoso persistente. Questo firmware potrebbe essere preinstallato da un produttore compromesso, intercettato durante il transito o aggiornato da un insider. Questa minaccia può portare a hardware pre-compromesso con rootkit che forniscono l'accesso backdoor al server. |
|
Addetto ai lavori malintenzionato con accesso logico |
Carico di lavoro di calcolo (ad esempio, VM) |
Punti di accesso |
Questo attacco potrebbe utilizzare le credenziali interne per accedere direttamente alle VM o agli host e ai dati contenuti. |
Router di tessuto |
Accesso fisico o amministrativo |
Questo attacco potrebbe ottenere il controllo root di un router fabric per intercettare tutto il traffico ed estrarre o manomettere qualsiasi dato in chiaro in transito sul fabric. |
|
Scheda madre |
Firmware |
Questo attacco potrebbe inviare immagini firmware difettose alle schede madri, rendendole inutilizzabili in modo permanente e i dati irrecuperabili. Un malintenzionato potrebbe inviare firmware con vulnerabilità note alle macchine per riacquisire il controllo utilizzando exploit che consentono l'esecuzione di codice remoto. |
|
Attaccante esterno con accesso logico |
Server |
VM |
Questo attacco potrebbe lanciare pattern di attacco side-channel pubblici sulle VM. Questi attacchi potrebbero causare la perdita di dati dalle istanze in esecuzione sullo stesso hardware o dal software del sistema host. |
SSD |
VM |
Questo attacco potrebbe utilizzare l'accesso diretto agli SSD PCIe per tentare di dedurre i dati del co-inquilino. |
|
Memoria |
VM |
Questo vettore d'attacco potrebbe utilizzare canali laterali per cercare nella memoria chiavi di crittografia preziose. |
|
Server |
VM bare metal |
Questo vettore d'attacco potrebbe utilizzare istanze bare metal per scansionare tutte le periferiche per trovare un componente vulnerabile che consenta di persistere nella macchina e attaccare i tenant successivi. |
Mappatura dei componenti hardware di Titanium alle minacce
L'architettura di sicurezza hardware Titanium utilizza un approccio multilivello per contribuire a contrastare minacce specifiche all'infrastruttura e per prevenire singoli punti di errore. Queste minacce possono derivare da errori o da utenti malintenzionati. Le minacce riguardano le operazioni hardware e possono sfruttare le vulnerabilità di server, reti e control plane. Non esiste una singola soluzione che possa affrontare tutti questi vettori di attacco, ma le funzionalità combinate di Titanium contribuiscono a proteggere i dati dei nostri utenti e le nostre istanze di cloud computing.
Scenario: operazioni hardware non autorizzate
Le operazioni hardware non autorizzate rappresentano una minaccia per la sicurezza dei dati, in quanto possono portare all'esfiltrazione di dati dai data center e alla modifica di hardware e firmware. L'architettura di sicurezza hardware Titanium di Google aiuta a difendersi da queste minacce utilizzando una serie di misure di sicurezza, tra cui RoT crittografiche, schede madri personalizzate e processori I/O. Questi componenti lavorano insieme per fornire una difesa a più livelli resistente a un'ampia gamma di attacchi.
La tabella seguente descrive alcune delle minacce hardware rogue e come l'architettura Titanium può mitigarle.
| Minaccia | Mitigazione di Titanium |
|---|---|
Un malintenzionato estrae singole unità di dati dai data center per accedere ai dati contenuti. |
Le chiavi di crittografia dei dati inattivi per i prodotti e i servizi di archiviazione non vengono mai archiviate in modo permanente sulle macchine a cui sono collegati i supporti di archiviazione. Le funzionalità di autocrittografia integrate dei supporti di archiviazione sono attivate anche per la difesa in profondità e utilizzano chiavi che non vengono mai archiviate in modo permanente sul supporto stesso. Le RTM Caliptra consentono a Google di includere l'identità hardware root-of-trust e l'integrità del firmware tra le condizioni di autorizzazione necessarie per rilasciare le chiavi da un Key Management Service alle istanze del servizio di archiviazione. Le macchine configurate in modo dannoso con firmware non intenzionale non possono accedere alle chiavi necessarie per decriptare i dati archiviati. Le RoT incorporate nei pacchetti di silicio ancorano le identità crittografiche pertinenti all'interno del pacchetto del chip. Gli interposer a singola funzione sono la parte principale della nostra sicurezza del data plane e criptano i dati a ogni fase di elaborazione. I TOP offrono i seguenti vantaggi:
Per le unità con prestazioni inferiori vengono utilizzate soluzioni software collaudate come dm-crypt, in cui la riduzione della superficie di attacco è fondamentale, ad esempio in alcuni casi di utilizzo dell'unità di avvio. |
Un malintenzionato tocca un cavo di rete e legge i byte sul cavo o sulla fibra. |
TOPs cripta i dati in transito, il che elimina la possibilità che una minaccia possa intercettare dati preziosi sulla rete. Le nostre NIC utilizzano lo standard di offload hardware PSP. Questo standard fornisce una crittografia conveniente con una riduzione minima delle prestazioni. Queste implementazioni sono conformi allo standard FIPS. I dati dei clienti vengono criptati quando transitano da switch Top of Rack (ToR) o fabric. Alcune infrastrutture di machine learning utilizzano meccanismi di sicurezza del trasporto proprietari. |
Un attaccante sostituisce i chip flash che contengono codice modificabile nel data center o nella catena di fornitura per eseguire codice dannoso sui server. |
I chip Titan sono progettati per respingere l'attacco e non forniscono l'accesso alle credenziali memorizzate al loro interno. Anche se un malintenzionato riscrive il contenuto dei chip flash non volatili, la radice di attendibilità Titan segnala in modo sicuro una misurazione del codice al control plane di Google, progettato per bloccare il dispositivo. Google revoca regolarmente il codice deprecato o con vulnerabilità note su scala globale nella nostra flotta utilizzando i chip Titan. |
Un malintenzionato inserisce dispositivi avversari nelle interfacce fisiche dei server o delle schede del data center per eseguire codice dannoso o esfiltrare dati. |
I design personalizzati della scheda madre rimuovono le interfacce utilizzate per inserire dispositivi avversari. Le configurazioni dell'unità di gestione della memoria di input/output (IOMMU) sono in atto per impedire i problemi di PCIe in tutti i nostri firmware. (I PCIe screamer sono progettati per leggere e scrivere pacchetti arbitrari sul fabric PCIe.) Man mano che il settore matura, stiamo integrando questa protezione con PCI IDE per mitigare ulteriormente gli interpositori PCI più sofisticati. ALTS e TLS sono le uniche connessioni di rete di autenticazione e autorizzazione accettate per le funzioni di controllo e gestione su TOP e BMC. I Caliptra RTM bloccano qualsiasi firmware non approvato. Le nostre periferiche attendibili attestano l'identità hardware e l'integrità del codice al nostro control plane e nessun server viene ammesso alla produzione se il record di attestazione non corrisponde all'intento di hardware e software. |
Un attaccante utilizza un attacco di avvio a freddo nel data center per accedere ai dati nella RAM. |
La crittografia in memoria di Confidential Computing protegge tutti i dati sensibili o le chiavi di crittografia nella RAM. La crittografia DRAM è abilitata anche nelle macchine di cui è stato eseguito il deployment senza Confidential Computing in data center edge con livelli di garanzia inferiori. |
Scenario: sfruttamento di server o reti da parte di utenti malintenzionati
Gli autori degli attacchi potrebbero utilizzare il cloud pubblico per ospitare i loro carichi di lavoro dannosi sulla nostra infrastruttura condivisa e per depositare dati nei nostri servizi pubblici. Anche avversari esterni, da singoli individui a stati nazionali, potrebbero tentare di ottenere l'accesso privilegiato remoto.
Per mitigare queste azioni, l'architettura di sicurezza hardware Titanium utilizza i chip Titan e Caliptra RTM per eseguire il provisioning delle credenziali di runtime in modo sicuro e limitare i privilegi su hardware e sistemi operativi. Il Confidential Computing aiuta a proteggere dalla manipolazione della memoria di sistema – fisicamente o tramite attacchi dell'hypervisor – e i chip Titan rifiutano o rilevano gli aggiornamenti software non autorizzati.
La tabella seguente descrive alcune delle minacce di sfruttamento di server e reti e il modo in cui l'architettura Titanium può mitigarle.
| Minaccia | Mitigazione di Titanium |
|---|---|
Un malintenzionato sfrutta una vulnerabilità per uscire dalla VM e accedere ai dati e ad altre VM in esecuzione sulla stessa macchina. |
Le enclave Confidential Computing riducono l'esfiltrazione dei dati del workload, sia in fase di elaborazione sia a riposo. Questa mitigazione impedisce a un malintenzionato che ha eseguito l'escape dalla VM di accedere ai dati in uso. I chip Titan e i moduli RTM Caliptra impediscono all'aggressore di avere accesso persistente. Qualsiasi tentativo di accesso persistente verrà probabilmente rilevato perché la configurazione della macchina non corrisponderà alla configurazione e alle norme relative al codice per quel server. Questa corrispondenza è necessaria prima che la macchina possa ospitare carichi di lavoro di produzione dopo un riavvio. |
Un attaccante lancia pattern di attacco side-channel pubblici sulle VM. |
Il nostro sistema di gestione del parco risorse, che utilizza i chip Titan, può revocare il software con vulnerabilità note. La revoca può bloccare eventuali attacchi successivi che prendono di mira queste vulnerabilità note. Le misurazioni dell'integrità basate su Titan forniscono anche un'elevata sicurezza che le mitigazioni, che potrebbero dover essere implementate con urgenza, siano state implementate sulle macchine di destinazione. Rafforziamo questo approccio rimanendo all'avanguardia nell'indagine e nella mitigazione dei canali collaterali, attraverso tecniche come retpoline e core scheduling, e nella ricerca avanzata su Meltdown, Spectre, Zenbleed, Downfall e altri. |
Un aggressore utilizza l'accesso diretto agli SSD che forniscono spazio di archiviazione a più tenant per tentare di dedurre i dati dei co-inquilini. |
La crittografia dei dati inattivi aiuta a proteggere da attacchi logici e fisici con una serie di interpositori. Per le risorse non condivise, i dati di ogni tenant vengono criptati utilizzando chiavi diverse, il che riduce la possibilità di attacchi di accesso diretto all'SSD. |
Un malintenzionato esegue la scansione della memoria e utilizza i canali laterali per cercare chiavi di crittografia dei dati o credenziali. |
I chip Titan consentono il provisioning di credenziali sigillate per macchina. Anche se un malintenzionato ottiene l'accesso root su una macchina, le sue credenziali sono associate esclusivamente all'identità privata del chip Titan locale. |
Un malintenzionato acquista istanze bare metal e scansiona tutte le periferiche per tentare di ottenere l'accesso persistente. |
I chip Titan rifiutano qualsiasi aggiornamento software non autorizzato, inclusi i push dannosi per il controllo persistente. Il nostro flusso di lavoro della macchina conferma positivamente le misurazioni di integrità previste in un ciclo di accensione attestato del sistema completo tra i clienti bare metal. |
Scenario: sfruttamento di server o reti da parte di un comportamento non autorizzato del control plane
Gli addetti ai lavori del piano di controllo malintenzionati possono tentare di sfruttare i sistemi di Google in vari modi, ad esempio tentando di ottenere il controllo root di un router fabric, inviando immagini firmware difettose alle schede madri e intercettando il traffico di rete. L'architettura di sicurezza hardware Titanium si difende da queste minacce utilizzando una serie di meccanismi, tra cui chip Titan, RTM Caliptra, schede madri personalizzate e servizi isolati a tolleranza di errore di backend.
La tabella seguente descrive alcune delle minacce al control plane e il modo in cui l'architettura Titanium può mitigarle.
| Minaccia | Mitigazione di Titanium |
|---|---|
Un malintenzionato utilizza le credenziali interne per accedere alle VM di Compute Engine che fungono da livello di base per gli ambienti dei clienti. |
I TOP contribuiscono a garantire che gli amministratori non abbiano accesso agli ambienti dei clienti. Senza accesso, il personale di Google non può utilizzare le proprie credenziali per accedere al livello privilegiato di hardware e software che si trova sotto le VM dei nostri clienti. L'accesso di Google ai dati dei clienti è bloccato perché i dati sono accessibili solo tramite API definite. |
Un malintenzionato invia immagini firmware difettose su larga scala alle schede madri, rendendole inutilizzabili in modo permanente. |
Le radici di attendibilità (RoT) dei chip Titan rifiutano qualsiasi aggiornamento software non autorizzato, inclusi i push dannosi per il controllo persistente. I design personalizzati della scheda madre utilizzano una rete alternativa di segnali che interconnettono tutte le nostre RoT alla RoT della piattaforma. La RoT della piattaforma contiene il firmware di backup per i dispositivi critici. Anche se la rete e PCI sono state compromesse da un malintenzionato, la rete (OOB) out-of-band può ripristinare il sistema. |
Un malintenzionato esegue il push del firmware di produzione obsoleto e con vulnerabilità note sulle macchine per riacquisire il controllo utilizzando vulnerabilità pubbliche. |
I chip Titan rifiutano i push dannosi e contribuiscono a imporre la revoca del codice con vulnerabilità note. Attestano la versione del firmware di cui è stato eseguito il deployment sulla macchina e rifiutano la macchina nel control plane. Questa mitigazione impedisce l'esecuzione di job su una macchina non integra e attiva l'indagine o la riparazione, se necessario. |
Un malintenzionato abusa delle funzionalità di debug del silicio necessarie per la continuità operativa, che forniscono il livello più elevato di accesso ai dati nei sistemi server. |
Caliptra RTM contribuisce a garantire che tutti i parametri che attivano interfacce di debug invasive, siano connesse logicamente o tramite inserimento fisico diretto, siano configurati in modo affidabile, misurati crittograficamente e segnalati al nostro control plane utilizzando un protocollo di attestazione. Solo le macchine nello stato previsto ottengono l'accesso per gestire i carichi di lavoro di produzione. |
Un malintenzionato ottiene il controllo di un servizio di backend per poter accedere agli ambienti dei clienti. |
I servizi regionalizzati di backend tolleranti ai guasti sono un'infrastruttura di credenziali regionalizzata che non consente l'accesso umano unilaterale. Oltre a impedire l'accesso dell'operatore ai nodi di calcolo, gli operatori non possono accedere al control plane per recuperare il materiale della chiave. Le enclave Confidential Computing nell'architettura Titanium isolano i nostri servizi di autorizzazione e provisioning delle chiavi di backend dai privilegi di root della macchina. Le gerarchie di chiavi contribuiscono a proteggere le chiavi di firma e autorizzazione della maggior parte dei servizi. Con le gerarchie di chiavi, le chiavi radice si trovano in chiavi air-gap conservate in HSM e casseforti oppure in chiavi conservate in produzione da un quorum Paxos di datastore in memoria. |
Passaggi successivi
- Leggi la panoramica sulla progettazione della sicurezza dell'infrastruttura.
- Implementa Confidential Computing.