Questi contenuti sono stati aggiornati l'ultima volta a settembre 2024 e rappresentano lo status quo al momento della loro 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 di Titan costituisce la base dei 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 della sicurezza dell'infrastruttura in continua evoluzione e completa di Google e contribuisce a proteggere l'integrità, la riservatezza e la disponibilità dei dati utente. L'hardware Titanium si basa su infrastrutture come le schede di offload hardware crittografico che forniscono crittografia in transito e microservizi interni che forniscono 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 di Google e a ridurre le minacce ai dati dei clienti. Questo documento descrive anche in che modo l'hardware Titanium abilita controlli di sicurezza specifici a livello di software, l'evoluzione dell'architettura oltre gli offload hardware crittografici iniziali e le minacce reali che l'architettura di sicurezza hardware di Titanium è progettata per mitigare tra i clienti e le basi di deployment di Google.
Architettura di sicurezza hardware Titanium
L'architettura di sicurezza hardware di Titan è progettata per difendersi da un ampio spettro di scenari e autori di minacce. Il seguente diagramma dell'architettura mostra i componenti indipendenti, ma interconnessi, di Titanium.
L'architettura di sicurezza hardware di Titanium include i seguenti componenti:
- Radice di attendibilità Caliptra per la misurazione (RTM): contribuisce a applicare un perimetro di sicurezza per ogni pacchetto di silicio. Caliptra RTM fornisce l'attestazione e un ID univoco ai servizi di crittografia di root.
- Chip Titan RoT: si interpone tra il flash di avvio di una piattaforma e i relativi dispositivi di avvio principali, come il controller di gestione della base di supporto (BMC), l'hub del controller della piattaforma (PCH) e la CPU. I chip Titan forniscono un RTO basato su hardware a prova di manomissione che consente di stabilire un'identità solida. I chip Titan sono utili anche per l'autorizzazione e la revoca del codice per macchine, schede o periferiche.
- Processore di offload Titanium (TOPs): fornisce controlli crittografici per contribuire a proteggere la riservatezza e l'integrità dei dati inattivi e in transito.
- Schede madri personalizzate: offrono resilienza su larga scala contro gli attacchi DoS di software difettosi o dannosi, nonché protezione contro gli attacchi fisici. Nel diagramma, ad esempio, il pacchetto di chip e il Titan RoT si trovano su una scheda madre personalizzata distinta dalle schede madri personalizzate per Titanium TOP o per le schede madri di altre infrastrutture.
- Enclave di Confidential Computing: contribuiscono a garantire l'isolamento dai privilegi amministrativi di Google, migliorano l'isolamento con altri tenant e aggiungono la verifica tramite l'attestazione. L'attestazione può garantire che l'ambiente non sia stato alterato.
- Servizi di backend regionali fault-tolerant: contribuiscono a impedire la riassegnazione dei privilegi tra servizi, zone o dall'accesso amministrativo.
Nel diagramma, Altra infrastruttura si riferisce ai network fabric e allo spazio di archiviazione di backend replicato.
Principi di progettazione dell'architettura di sicurezza hardware di Titan
I nostri componenti hardware Titanium e le relative interazioni vengono sviluppati utilizzando i 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 & Reliable Systems illustra l'importanza di evitare single point of failure. Questo principio viene applicato a 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 al sicuro e disponibili.
Ad esempio, la migrazione live con Confidential Computing contribuisce a preservare la memoria criptata sulle macchine host supportate. La migrazione live contribuisce ad assicurare che una VM a lunga durata non sia un singolo punto di errore a causa di eventi di manutenzione o per rispondere a vulnerabilità.
Il perimetro è il pacchetto di silicio: poiché un sistema di server contiene più sistemi on chip interconnessi e separati, la nostra architettura non si fida fondamentalmente di tutti i connettori, le strutture, i componenti assemblati della scheda di circuito stampato (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 obiettivi ben definiti da cui rubare i dati in testo non cifrato. I dati all'interno del pacchetto di silicio stesso vengono criptati e autenticati da asset criptati privati all'interno del pacchetto.
Spostare il perimetro nel 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 pubblicazione dei data center diventano sempre più diverse. Ad esempio, l'impostazione del perimetro nel pacchetto di silicio aiuta a gestire le minacce provenienti da operazioni hardware non autorizzate.
Zero trust e compartimentalizzazione del rischio: i controlli multipli sulle azioni amministrative contribuiscono a garantire che nessun account personale (o account personale compromesso) possa causare unilateralmente le minacce discusse in questo documento. L'architettura separa i servizi in livelli e zone per compartimentalizzare e contenere i rischi. Anche con gli enclavi, che in genere sono radicati nell'hardware, l'architettura tiene conto del rilevamento delle vulnerabilità hardware e della necessità di applicare la correzione mentre i componenti rimangono in funzione.
Ad esempio, se un malintenzionato compromette intenzionalmente il comportamento di un chip all'interno di un sistema attivo che esegue i 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 il computer non viene messo fuori servizio, l'attaccante deve aggirare ulteriori confini di attendibilità e compromettere più credenziali per spostarsi lateralmente e ottenere influenza su altri sistemi, utenti o regioni.
I domini di errore indipendenti e le tecnologie di isolamento contribuiscono a limitare l'area interessata da un compromesso. Questi domini e queste tecnologie aggiungono punti di controllo naturali per il rilevamento e limitano la complessità aggiuntiva che deve essere introdotta.
Per ulteriori informazioni sulla nostra implementazione Zero Trust, consulta BeyondProd.
Sicurezza trasparente: Google investe in diversi progetti 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, che afferma che 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 e software per la sicurezza. La tabella seguente descrive alcuni dei progetti open source a cui contribuiamo e che utilizziamo.
Progetto open source Descrizione Componente Titanium Utilizzato nelle librerie di crittografia FIPS 140-3 di 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 basato sulla copertura
Distro VM host ring0 e utente
Utilizzato nelle librerie di crittografia FIPS 140-3 di livello 1
Processore di offload Titanium
Difesa fisica e logica in profondità: Google si basa sulla sicurezza fisica dei data center per contribuire a proteggere i nostri investimenti di capitale e i nostri sistemi. Questi controlli di sicurezza rappresentano un primo livello di difesa, pertanto investiamo deliberatamente in controlli logici aggiuntivi per rafforzare i nostri sistemi contro le minacce fisiche. Titanium contribuisce alla nostra difesa in profondità aggiungendo la compartimentazione al nostro hardware, che offre difese aggiuntive contro minacce specifiche alle infrastrutture.
Ad esempio, i nostri data center sono dotati di rilevatori di metalli in grado di rilevare con precisione i tentativi di esfiltrazione dei supporti di archiviazione. Tuttavia, la nostra strategia di crittografia dei dati at-rest è progettata deliberatamente per non fare affidamento sulla custodia dei 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 degli addetti ai lavori e a proteggere la riservatezza dei dati dei nostri utenti.
Vantaggi per la sicurezza dei componenti dell'architettura di Titanium
La tabella seguente mette in evidenza alcuni importanti vantaggi per la sicurezza ottenuti con i componenti dell'architettura di sicurezza di Titan, sia a livello hardware che software. Questi vantaggi per la sicurezza sono descritti in maggiore dettaglio nelle sezioni seguenti.
| Vantaggi per la 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 nei vari boot |
Caliptra RTM, Titan RoT |
Protezione della riservatezza dei dati at-rest e in transito |
TOP per la crittografia |
Offloading della protezione a livello di processore (oltre una carta fisica) |
TOP per la crittografia |
Sicurezza per progettazione, resistenza agli attacchi fisici e funzionalità di resilienza che supportano il ripristino del firmware completo del sistema da un singolo Titan RoT |
Schede madri personalizzate |
Schede appositamente progettate con solo i connettori essenziali, che aiutano 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 da parte di persone |
Enclave di Confidential Computing |
Resistenza ai tentativi di manomissione tramite crittografia DRAM (per abilitare la crittografia dei dati in uso) |
Enclave di Confidential Computing |
Area interessata e paratie ridotte al minimo per un malintenzionato con accesso locale |
Servizi di backend regionali a tolleranza di errore |
Più livelli di compartimentalizzazione |
Servizi di backend regionali a tolleranza di errore |
Radice di attendibilità di Caliptra per la misurazione
Caliptra RTM contribuisce a creare fiducia e trasparenza per il firmware all'interno del nostro ecosistema che gira su SoC (system-on-chip) come CPU, GPU e TPU.
Caliptra RTM offre i seguenti vantaggi:
- Fornisce un servizio crittografico di root: Caliptra RTM consente di rilevare codice e configurazione critici danneggiati tramite una verifica dell'integrità crittografica end-to-end avanzata. Caliptra RTM può misurare in modo crittografico il codice e la configurazione, firmare queste misurazioni con una chiave di attestazione univoca e protetta dall'hardware e generare report sulle misurazioni che attestano l'autenticità e l'integrità del dispositivo. Caliptra RTM fornisce un'identità del dispositivo crittografica e un insieme di misurazioni dell'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, sia creati da Google sia da terze parti. Questa procedura di verifica consente a Caliptra RTM di mantenere l'autenticità e l'integrità degli aggiornamenti autorizzati e contribuisce a garantire che le configurazioni rimangano come previste e siano attestate.
- Protezione contro intrusioni fisiche che richiedono l'accesso diretto all'hardware in esecuzione: poiché Caliptra RTM è integrato nei livelli di silicio del chip, un intercalare PCBA o un chip malintenzionato che tenta di caricare il firmware errato su un circuito integrato specifico per l'applicazione (ASIC) non può attaccare correttamente il RoT. Ad esempio, gli aggressori possono aggirare le funzionalità di rilevamento di un RoT esterno manomettendo il bus SPI a velocità relativamente ridotta. Tuttavia, un RoT integrato in un SoC o un ASIC diventa più difficile da compromettere per un aggressore.
Radice di attendibilità del chip Titan
Titan è progettato per mantenere crittograficamente l'identità del dispositivo, difendersi da push di software dannosi e applicare l'autenticità del codice tramite la revoca.
Un'identità di dispositivo cryptographic contribuisce a garantire che il parco sia composto esclusivamente da macchine convalidate che eseguono i binari previsti e che possono identificare e autenticare l'accesso legittimo. L'accesso legittimo è basato a livello hardware.
Per impostazione predefinita, le macchine di produzione utilizzano l'avvio attendibile per garantire che possa essere eseguito solo il 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 va a buon fine.
Come ulteriore controllo preventivo, la revoca del codice macchina impedisce l'applicazione di modifiche al software che non sono più autorizzate. La funzionalità di revoca nei chip Titan contribuisce a mitigare non solo gli attacchi dannosi (ad esempio gli attacchi di rollback o di replay), ma anche i bug di stabilità o resilienza non dannosi (ad esempio impedendo la reinstallazione accidentale di firmware vecchi con bug).
Per ulteriori informazioni, consulta In che modo Google applica l'integrità del boot 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. Le TOP implementano la crittografia autenticata dei dati in transito e la crittografia autenticata dei dati at-rest a basso costo. La crittografia autenticata garantisce che i dati dei clienti siano protetti da crittografia per quanto riguarda riservatezza e integrità. Poiché gestiscono la crittografia, i TOP riducono i privilegi di molti componenti di sistema. I TOP consentono di migliorare le proprietà architettoniche, come la disponibilità, riducendo al minimo la potenziale perdita della segretezza dei dati.
Schede madri personalizzate
Le schede madri personalizzate nell'infrastruttura di Google sono progettate per fornire la provenienza dell'hardware. Le schede madri supportano l'attestazione a più livelli. I progetti delle schede madri proteggono i dati dei clienti, anche nell'improbabile caso in cui un malintenzionato colleghi fisicamente un dispositivo dannoso a un computer. I progetti delle schede madri Titanium consentono di implementare in modo affidabile meccanismi di rafforzamento aggiuntivi, come porte di debug svuotate, 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, i TOP fungono da proxy per qualsiasi traffico di gestione specifico 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 recupero integrati per garantire disponibilità e recuperabilità. Possono ripristinarsi dalla maggior parte degli arresti anomali o dalla corruzione del firmware. I nostri progetti più recenti consentono di ricostruire l'intera macchina da un singolo Titan RoT funzionante. Queste schede madre utilizzano componenti di alimentazione dedicati e segnalazioni di reimpostazione per contribuire a garantire l'indipendenza elettrica delle unità di rotazione Titan dal resto della piattaforma e a proteggere il loro controllo sui payload del firmware della piattaforma ai fini dell'autenticazione e del recupero.
Enclave di Confidential Computing
Confidential Computing crea un Trusted Execution Environment (TEE) o un'enclave per contribuire a isolare i carichi di lavoro sensibili dei clienti dall'accesso amministrativo di Google. Quando i dati vengono gestiti dalla CPU o dalla GPU, Confidential Computing fornisce un controllo tecnico preventivo tramite l'isolamento del calcolo e la crittografia in memoria. Confidential Computing contribuisce ad assicurare che anche un hypervisor dannoso non possa accedere a una VM. Per i carichi di lavoro dei clienti, Confidential Computing fornisce un livello di isolamento della segretezza dei dati dalla possibilità di accesso non intenzionale del personale di Google o di azioni automatizzate del software di sistema errate su larga scala.
Un esempio di sicurezza avanzata abilitata dall'architettura Titanium è la modalità riservata per Hyperdisk Balanced. La modalità riservata per Hyperdisk Balanced combina gli offload di archiviazione a blocchi basati su Titanium, il calcolo riservato e Cloud HSM per creare un TEE basato su hardware. In altre parole, la modalità riservata per Hyperdisk Balanced è un'offerta bilanciata Hyperdisk. La modalità riservata per Hyperdisk Balance isola l'infrastruttura in modo che le chiavi sensibili vengano elaborate esclusivamente in un TEE basato su hardware. Per informazioni sulla revisione da parte di terze parti delle operazioni di crittografia, consulta Public Report – Confidential Mode for Hyperdisk – DEK Protection Analysis.
Servizi di backend regionali a tolleranza di errore
I servizi di backend regionali fault-tolerant contribuiscono a ridurre al minimo l'area interessata da un malintenzionato con accesso locale. L'infrastruttura di Google è progettata per compartimentalizzare servizi, sistemi e zone dal movimento laterale di persone interne privilegiate o servizi compromessi.
Stiamo lavorando per includere le informazioni regionali in un insieme sempre più ampio dei nostri sistemi di gestione dell'identità e dell'accesso interni. Le informazioni regionali rafforzano l'isolamento crittografico in modo che un malintenzionato che ottiene l'accesso locale debba compromettere più credenziali di servizi di infrastruttura distinti per continuare a muoversi lateralmente.
Se un attacco attiva un controllo preventivo che rimuove una macchina di produzione dall'ambiente (ad esempio, causa lo spegnimento del sistema), la nostra infrastruttura di backend fault-tolerant contribuisce a garantire la disponibilità continua dei dati e dei servizi dei clienti sulle macchine vicine. Per ulteriori informazioni sui nostri controlli dell'infrastruttura, consulta BeyondProd e In che modo Google protegge i suoi servizi di produzione.
Vettori di attacco per l' Google Cloud infrastruttura
Questa sezione descrive minacce fisiche e logiche specifiche che costituiscono parte della superficie di attacco di Google Cloud. L'architettura di sicurezza hardware di Titanium è progettata specificamente per affrontare un insieme unico di minacce all'infrastruttura di Google e ai dati utente che archiviamo.
Minacce all'infrastruttura
L'architettura Titanium è progettata per difendersi dalle seguenti categorie di minacce:
- Insider malintenzionato con accesso fisico: il nostro personale deve accedere ai dispositivi fisici nei data center per eseguire il deployment, la manutenzione e la riparazione dell'hardware. Questo accesso rappresenta un potenziale vettore di attacco perché il personale o i fornitori non autorizzati hanno un motivo commerciale legittimo per riparare fisicamente alcune delle macchine nei nostri data center.
Insider malintenzionato con accesso logico: in modo simile all'accesso fisico al data center, il personale è tenuto a sviluppare, mantenere, testare, eseguire il debug, ottimizzare e supportare più livelli dello stack software di Google. Questo personale include sviluppatori, SRE e ingegneri cloud rivolti ai clienti.
Per ulteriori informazioni sulle nostre difese contro questa minaccia, consulta In che modo 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 Google Cloud ambiente e tentare di trasferirsi lateralmente ad altre macchine per ottenere l'accesso a dati sensibili. Una tattica comune utilizzata dagli aggressori esterni è iniziare compromettendo un account personale o di un appaltatore legittimo.
Il seguente diagramma mostra la parte dell'ambiente cloud più vulnerabile a queste minacce.
La superficie di attacco ai server del data center
La seguente tabella descrive le superfici di attacco che sono aspetti tipici dei server dei data center. L'architettura di sicurezza hardware di Titan è progettata per fornire difese efficaci contro queste minacce.
| Attaccante | Target | Superficie di attacco | Rischio |
|---|---|---|---|
Addetti ai lavori malintenzionati con accesso fisico |
Supporti di archiviazione (SSD, HDD o unità di avvio) |
Dischi fisici e connettori |
Questo attacco potrebbe rubare un'unità e tentare di accedervi con gli strumenti dell'aggressore. |
DIMM |
Connettori della memoria fisica |
Questo attacco potrebbe bloccare la DIMM, rimuoverla dal data center e tentare di accedere ai dati in essa contenuti utilizzando gli strumenti dell'utente malintenzionato. Questa minaccia a volte viene chiamata attacco di avvio a freddo. |
|
Server |
Connettori USB o PCIe |
Questo attacco potrebbe connettere hardware dannoso al server. Utilizzando l'hardware dannoso, l'aggressore potrebbe tentare di ottenere l'esecuzione di codice o di esfiltrare i dati residenti. |
|
Scheda madre |
Porta di debug estesa (XDP) del gruppo di accesso per i test congiunto (JTAG) |
Questo attacco potrebbe connettere uno strumento di debug hardware per ottenere l'esecuzione di codice o l'accesso ai dati elaborati sulla CPU. |
|
Rete |
Cavi Ethernet |
Questo attacco potrebbe intercettare un cavo Ethernet per ottenere l'accesso a tutti i dati trasferiti tra i dispositivi. In questo modo, qualsiasi traffico di testo non criptato 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 utente interno. Questa minaccia può portare a hardware pre-hacked con rootkit che forniscono accesso backdoor al server. |
|
Insider malintenzionato con accesso logico |
Carico di lavoro di calcolo (ad esempio VM) |
Punti di accesso |
Questo attacco potrebbe utilizzare le credenziali di un insider per accedere direttamente alle VM o agli host e ai dati in esse contenuti. |
Router di dominio |
Accesso fisico o amministrativo |
Questo attacco potrebbe ottenere il controllo root su un router del fabric per intercettare tutto il traffico ed esfiltrare o manomettere i dati in testo non cifrato in transito nel fabric. |
|
Scheda madre |
Firmware |
Questo attacco potrebbe inviare immagini del firmware difettose alle schede madri, rendendole definitivamente inutilizzabili e rendendo i dati non recuperabili. Un malintenzionato potrebbe spingere firmware con vulnerabilità note sulle macchine per riprendere il controllo utilizzando exploit che consentono l'esecuzione di codice remoto. |
|
Attaccante esterno con accesso logico |
Server |
VM |
Questo attacco potrebbe lanciare pattern di attacchi lato canale pubblici sulle VM. Questi attacchi potrebbero causare la fuga di dati dalle istanze in esecuzione sullo stesso hardware o dal software del sistema host. |
SSD |
VM |
Questo attacco potrebbe utilizzare l'accesso diretto alle unità SSD PCIe per tentare di dedurre i dati dei co-tenant. |
|
Memoria |
VM |
Questo vettore di attacco potrebbe utilizzare canali laterali per cercare nella memoria chiavi di crittografia importanti. |
|
Server |
VM bare metal |
Questo vettore di attacco potrebbe utilizzare istanze bare metal per eseguire la scansione di tutte le periferiche per trovare un componente vulnerabile che consenta di persistere nella macchina e attaccare gli utenti successivi. |
Mappatura dei componenti hardware di Titanium alle minacce
L'architettura di sicurezza hardware di Titanium utilizza un approccio multilivello per contribuire a gestire minacce all'infrastruttura specifiche e per evitare single point of failure. Queste minacce possono derivare da errori o da malintenzionati. Le minacce interessano le operazioni hardware e possono sfruttare vulnerabilità in server, reti e nel piano di controllo. Non esiste una singola soluzione che possa affrontare tutti questi vettori di attacco, ma le funzionalità combinate di Titanium ci aiutano 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 Root of Trust criptati, schede madri personalizzate e processori I/O. Questi componenti agiscono congiuntamente per fornire una difesa a più livelli resistente a una vasta gamma di attacchi.
La tabella seguente descrive alcune delle minacce hardware illecite e come l'architettura Titanium può mitigarle.
| Minaccia | Mitigazione di Titanium |
|---|---|
Un malintenzionato esfiltra singole unità di dati dai data center per accedere ai dati in esse contenuti. |
Le chiavi di crittografia dei dati inattivi per i prodotti e i servizi di archiviazione non vengono mai memorizzate in modo permanente sulle macchine a cui sono collegati i supporti di archiviazione. Anche le funzionalità di crittografia automatica integrate dei supporti di archiviazione sono attivate per la difesa in profondità e utilizzano chiavi che non vengono mai memorizzate in modo permanente sul supporto stesso. I moduli RTM Caliptra consentono a Google di includere l'identità hardware e l'integrità del firmware della radice di attendibilità tra le condizioni di autorizzazione necessarie per rilasciare le chiavi da un servizio di gestione delle chiavi alle istanze del servizio di archiviazione. Le macchine configurate in modo dannoso con firmware indesiderato non possono accedere alle chiavi necessarie per decriptare i dati archiviati. Le RoT integrate all'interno dei pacchetti in silicio ancorano le identità cryptographic pertinenti all'interno del pacchetto del chip. Gli interpositari a funzione singola costituisce la parte principale della nostra sicurezza del piano dati e criptano i dati in ogni passaggio di elaborazione. I TOP offrono i seguenti vantaggi:
Soluzioni software collaudate come dm-crypt vengono utilizzate per le unità con prestazioni inferiori dove la riduzione della superficie di attacco è fondamentale, ad esempio in alcuni casi di utilizzo della unità di avvio. |
Un malintenzionato intercetta un cavo di rete e legge i byte sul cavo o sulla fibra. |
I TOP criptano i dati in transito, rimuovendo l'opportunità per una minaccia di sniffare dati importanti sulla rete. Le nostre NIC utilizzano lo standard di offload hardware PSP. Questo standard fornisce una crittografia economica con una riduzione minima delle prestazioni. Queste implementazioni sono conformi allo standard FIPS. I dati dei clienti vengono criptati quando transitano su switch ToR (Top of Rack) o di rete. Alcune infrastrutture di machine learning utilizzano meccanismi di sicurezza di trasporto proprietari. |
Un utente malintenzionato sostituisce i chip flash che contengono codice mutabile nel data center o nella catena di approvvigionamento per eseguire codice dannoso sui server. |
I chip Titan sono progettati per respingere l'attacco e non forniscono accesso alle credenziali memorizzate al loro interno. Anche se un malintenzionato riscrivi i contenuti dei chip flash non volatili, la RoT di Titan segnala in modo sicuro una misurazione del codice al piano di controllo di Google, progettato per bloccare il dispositivo. Google revoca regolarmente il codice deprecato o con vulnerabilità note su scala mondiale nel nostro parco utilizzando i chip Titan. |
Un malintenzionato inserisce dispositivi ostili nelle interfacce fisiche di schede o server di data center per eseguire codice dannoso o esfiltrare dati. |
I progetti delle schede madri personalizzate 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 gli screamer PCIe in tutto il nostro firmware. Gli screamer PCIe sono progettati per leggere e scrivere pacchetti arbitrari sul fabric PCIe. Con la crescita del settore, stiamo completando questa protezione con il protocollo IDE PCI per contrastare ulteriormente gli interposer 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. Le RTM Caliptra bloccano qualsiasi firmware non approvato. Le nostre periferiche attendibili attestano la loro identità hardware e l'integrità del codice al nostro piano di controllo e nessun server viene ammesso alla produzione se il record di attestazione non corrisponde all'intenzione hardware e software. |
Un malintenzionato utilizza un attacco di cold boot nel data center per accedere ai dati memorizzati nella RAM. |
La crittografia in-memory di Confidential Computing protegge eventuali dati sensibili o 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 un livello di garanzia inferiore. |
Scenario: sfruttamento di server o reti da parte di utenti malintenzionati
Gli attaccanti 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 gli avversari esterni, da singoli individui a stati nazionali, potrebbero tentare di ottenere accesso privilegiato da remoto.
Per mitigare queste azioni, l'architettura di sicurezza hardware di Titanium utilizza 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. La tecnologia Confidential Computing contribuisce a proteggere dalla manipolazione della memoria di sistema, sia fisica che tramite attacchi all'hypervisor, e i chip Titan rifiutano o rilevano gli upgrade software non autorizzati.
La tabella seguente descrive alcune delle minacce di sfruttamento del server e della rete e come l'architettura di Titanium può mitigarle.
| Minaccia | Mitigazione di Titanium |
|---|---|
Un malintenzionato sfrutta una vulnerabilità per uscire dalla propria VM e ottenere l'accesso ai dati e ad altre VM in esecuzione sulla stessa macchina. |
Gli enclave di Confidential Computing riducono l'esfiltrazione dei dati del carico di lavoro, in fase di elaborazione o inattivi. Questa misura di mitigazione impedisce a un malintenzionato che è riuscito a uscire dalla VM di accedere ai dati in uso. I chip Titan e le RTM Caliptra impediscono all'attaccante di avere accesso permanente. È probabile che qualsiasi tentativo di accesso permanente venga rilevato perché la configurazione della macchina non corrisponderà alla configurazione e ai criteri di codice del server. Questa corrispondenza è necessaria prima che la macchina possa ospitare i carichi di lavoro di produzione dopo un riavvio. |
Un utente malintenzionato lancia pattern di attacco lato canale 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 hanno come target queste vulnerabilità note. Le misurazioni dell'integrità basate su Titan forniscono inoltre un'elevata certezza che le mitigazioni, che potrebbero dover essere implementate con urgenza, siano state implementate nelle macchine di destinazione. Rafforziamo questo approccio rimanendo all'avanguardia nell'indagine e nella mitigazione dei canali laterali, tramite tecniche come retpoline e la pianificazione dei core, nonché ricerche avanzate su Meltdown, Spectre, Zenbleed, Downfall e altri. |
Un malintenzionato utilizza l'accesso diretto alle unità SSD che forniscono spazio di archiviazione a più tenant per tentare di dedurre i dati dei co-tenant. |
La crittografia dei dati inattivi aiuta a proteggersi 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 l'opportunità di attacchi di accesso diretto all'SSD. |
Un malintenzionato esegue la scansione della memoria e utilizza i canali laterali per cercare le credenziali o le chiavi di crittografia dei dati. |
I chip Titan consentono il provisioning di credenziali sigillate per macchina. Anche se un malintenzionato ottiene l'accesso come utente root su una macchina, le sue credenziali sono legate esclusivamente all'identità privata del chip Titan locale. |
Un malintenzionato acquista istanze bare metal e esegue la scansione di tutte le periferiche per tentare di ottenere l'accesso permanente. |
I chip Titan rifiutano qualsiasi upgrade software non autorizzato, inclusi push dannosi per il controllo persistente. Il nostro flusso di lavoro delle macchine conferma positivamente le misurazioni dell'integrità previste in un ciclo di alimentazione verificato completo del sistema tra i clienti bare metal. |
Scenario: sfruttamento di server o reti a causa del comportamento del piano di controllo non autorizzato
Gli addetti ai lavori del piano di controllo non autorizzati possono tentare di sfruttare i sistemi di Google in diversi modi, ad esempio tentando di ottenere il controllo root su un router del fabric, inviando immagini del firmware difettose alle schede madri e intercettando il traffico di rete. L'architettura di sicurezza hardware di Titanium si difende da queste minacce utilizzando una serie di meccanismi, tra cui chip Titan, RTM Caliptra, schede madri personalizzate e servizi di backend isolati e a prova di errori.
La tabella seguente descrive alcune delle minacce al piano di controllo e come l'architettura di Titanium può mitigarle.
| Minaccia | Mitigazione di Titanium |
|---|---|
Un malintenzionato utilizza le credenziali di un insider per accedere alle VM Compute Engine che fungono da livello di base per gli ambienti dei clienti. |
I TOP contribuiscono ad assicurare 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 hardware e software privilegiato sottostante alle VM dei nostri clienti. L'accesso degli addetti ai lavori di Google ai dati dei clienti è bloccato perché i dati sono accessibili solo tramite API definite. |
Un malintenzionato carica su larga scala immagini del firmware con difetti sulle schede madri, bloccandole definitivamente. |
I Root of Trust dei chip Titan rifiutano qualsiasi aggiornamento software non autorizzato, inclusi i push dannosi per il controllo persistente. I design personalizzati delle schede madre utilizzano una rete alternativa di indicatori che interconnettono tutti i nostri RoT alla piattaforma RoT. Il RoT della piattaforma contiene il firmware di backup per i dispositivi critici. Anche se la rete e la scheda PCI sono state bloccate da un malintenzionato, la rete out-of-band (OOB) può ripristinare il sistema. |
Un malintenzionato spinge firmware di produzione deprecati e con vulnerabilità note sulle macchine per riprendere il controllo utilizzando vulnerabilità pubbliche. |
I chip Titan rifiutano i push non validi e contribuiscono a applicare la revoca del codice vulnerabile noto. Attestano la versione del firmware di cui è stato eseguito il deployment sulla macchina e rifiutano la macchina nel piano di controllo. Questa misura di mitigazione contribuisce a impedire l'esecuzione di job su una macchina non sana e attiva indagini o riparazioni, se necessario. |
Un malintenzionato abusa delle funzionalità di debug del silicio necessarie per la continuità aziendale, che forniscono il massimo livello possibile di accesso ai dati nei sistemi di server. |
Caliptra RTM contribuisce a garantire che tutti i parametri che attivano le interfacce di debug invasive, collegate logicamente o tramite inserimento fisico diretto, siano configurati in modo affidabile, misurati crittograficamente e registrati nel nostro piano di controllo utilizzando un protocollo di attestazione. Solo le macchine nello stato previsto ottengono l'accesso per eseguire 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 di backend regionalizzati e a prova di errore sono un'infrastruttura delle credenziali regionalizzata che non consente l'accesso unilaterale da parte di persone. Oltre a impedire l'accesso degli operatori ai nodi di calcolo, gli operatori non possono nemmeno accedere al control plane per recuperare il materiale della chiave. Le enclave di Confidential Computing nell'architettura Titanium isolano i nostri servizi di provisioning delle chiavi e di autorizzazione di backend dai privilegi di root della macchina. Le gerarchie di chiavi aiutano a proteggere le chiavi di firma e di autorizzazione della maggior parte dei servizi. Con le gerarchie delle chiavi, le chiavi radice si trovano in chiavi con isolamento aereo custodite in HSM e in casseforti oppure in chiavi custodite in produzione da un quorum Paxos di datastore in memoria. |
Passaggi successivi
- Leggi la Panoramica sulla progettazione della sicurezza dell'infrastruttura.
- Implementa Confidential Computing.