Questi contenuti sono stati aggiornati l'ultima volta a settembre 2024 e rappresentano lo status quo. al momento in cui è stata scritta. Le norme e i sistemi di sicurezza di Google potrebbero cambiare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.
L'architettura di sicurezza hardware in titanio costituisce la base del e supporta molte delle contromisure per la sicurezza offerte da Google dell'infrastruttura. L'hardware in titanio include microcontroller di sicurezza, hardware e scaricano processori sviluppati appositamente per affrontare vettori di attacco specifici per l'infrastruttura di Google.
L'hardware Titanium è l'ultimo ritrovato per la sicurezza dell'infrastruttura sempre in 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 per la crittografia che forniscono la crittografia in transito e 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 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 la base 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 allo stesso tempo interconnessi, di Titanium.
L'architettura di sicurezza hardware 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 crittografici radice.
- Chip Titan Rotazione: si interpone tra il flash di avvio di una piattaforma e i suoi dispositivi di avvio principali come il controller di gestione a battiscopa (BMC), l'hub controller della piattaforma (PCH), e la CPU. I chip Titan forniscono un supporto fisico a prova di manomissione, basato su hardware che aiuta a stabilire una forte identità. I chip Titan sono utili anche per l'autorizzazione e la revoca del codice per macchine, schede o periferiche.
- Processore con offload in Titanio (TOPS): fornisce di crittografia che aiutano a proteggere la riservatezza e l'integrità dati at-rest 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.
- Confidential Computing enclave: consente di applicare l'isolamento contro i sistemi amministrativi privilegiati, migliorare l'isolamento con altri tenant e aggiungere la verificabilità mediante l'attestazione. La attestazione può garantire che l'ambiente non sia stato alterato.
- Servizi regionali a tolleranza di errore di backend: aiutano a prevenire la riassegnazione tra servizi, zone o accesso amministrativo.
Nel diagramma, Altra infrastruttura si riferisce agli asset di rete e agli asset archiviazione backend.
Principi di progettazione dell'architettura di sicurezza dell'hardware Titanium
I nostri componenti hardware Titanium e le relative interazioni vengono 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 & Reliable Systems illustra l'importanza di evitare single point of failure. Questo principio viene applicato in tutta la nostra organizzazione dell'infrastruttura, in tutte le regioni e persino fino al silicio nei chip. Questa resilienza in tutta la nostra infrastruttura globale aiuta 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ù system-on-chip interconnessi e separati, la nostra architettura non si fida fondamentalmente di tutti i connettori, i fabric, i componenti assemblati su schede di circuito stampato (PCBA), le tracce PCBA e i cavi. Sebbene la separazione dei componenti sia utile per la modularità, la separazione può diventare un punto debole quando offre obiettivi ben definiti da cui esaminare i dati del testo in chiaro. 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 le condizioni di servizio dei data center diventano sempre più diversificate. Ad esempio, l'impostazione del perimetro nel pacchetto di silicio aiuta a gestire le minacce provenienti da operazioni hardware non autorizzate.
Zero Trust e rischio di compartimentazione: controlli da più parti attivi le azioni amministrative contribuiscono ad assicurare che nessun account del personale (o venga compromesso account personale) possono causare unilateralmente le minacce discusse nel questo documento. L'architettura separa i servizi in livelli e zone per compartimentalizzare e contenere i rischi. Anche con le enclavi, che in genere sono basato sull'hardware, l'architettura spiega il rilevamento dell'hardware le vulnerabilità e la necessità di rimediare mentre i componenti operativa.
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. globale di Google dell'infrastruttura applica Kerckhoffs' principio, che afferma che un crittosistema dovrebbe essere sicuro, anche se tutto ciò che riguarda il sistema, eccetto la chiave, è di dominio pubblico.
Ad esempio, contribuiamo ai progetti open source e li utilizziamo nelle i nostri progetti hardware di sicurezza e il nostro software di sicurezza. La tabella seguente descrive alcuni dei progetti open source a cui contribuiamo e utilizziamo.
Progetto open source Descrizione Componente Titanium Utilizzato nelle librerie di crittografia FIPS 140-3 di livello 1
BoringSSL
Utilizzato nelle radici di fiducia (RoT) a livello di silicio
Caliptra RTM
Utilizzato in RoT per un chip in un'architettura di sistema
Chip Titan
Utilizzato per il fuzzing dei kernel guidato dalla 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 dispongono di metal detector in grado di rilevare con precisione tentativi di esfiltrazione di supporti di archiviazione. Tuttavia, la nostra crittografia dei dati at-rest è deliberatamente progettato per non affidarsi alla custodia fisica dei media. Questi controlli logici e fisici sono livelli indipendenti e complementari.
I nostri controlli combinati sulla sicurezza fisica e logica ci aiutano a rimanere vigili dalle minacce interne e contribuire a proteggere la riservatezza dei dati e i dati di Google Cloud.
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 Architettura |
|---|---|
Perimetro di attendibilità a livello di silicio su SoC (system-on-chip) come CPU GPU |
Caliptra RTM |
Verificabilità a livello di silicio |
Caliptra RTM |
Identità crittografica a livello di hardware |
Caliptra RTM, Titan RoT |
Verifica dell'esecuzione dei programmi binari previsti |
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 a una scheda fisica) |
Migliori 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 madre personalizzate |
Schede appositamente progettate con solo i connettori essenziali, che aiutano a mitigare i tentativi di manomissione fisica |
Schede madre personalizzate |
Isolamento del carico di lavoro crittografico dal software di sistema a livello di macchina e accesso amministrativo da parte di persone |
Enclavi di Confidential Computing |
Resistenza alle manomissioni tramite crittografia DRAM (per abilitare la crittografia dei dati in uso) |
Enclave di Confidential Computing |
Area e paratia colpite al minimo per un aggressore con servizi locali accesso |
Servizi regionalizzati a tolleranza di errore di backend |
Multilivello di compartimentazione |
Servizi regionalizzati a tolleranza di errore di backend |
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 efficace. Caliptra RTM può misurare in modo criptato 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 offre l'identità del dispositivo crittografico e un set di firmware e configurazione delle misurazioni dell'integrità della 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 catena di fornitura del software sicurezza, Caliptra RTM consente al sistema di verificare l'autenticità e l'integrità di firmware e software, creati da Google o 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.
- Protegge dalle intrusioni fisiche che richiedono l’accesso diretto ai sistemi di hardware: poiché Caliptra RTM è integrato negli strati di silicio del chip, Interposer PCBA o chip rogue che tenta di consegnare il firmware sbagliato a un il circuito integrato specifico per l'applicazione (ASIC) non è in grado di attaccare RoT. Ad esempio, gli aggressori possono aggirare il rilevamento di un RoT esterno manomissioni del bus SPI a velocità relativamente bassa. Tuttavia, un RoT integrato in un SoC o un ASIC diventa più difficile da compromettere per un aggressore.
Radice di attendibilità 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 è in grado di eseguire il software autenticato. Avvio affidabile verifica la firma digitale tutti i componenti di avvio e non consente a una macchina di partecipare ambiente di produzione in caso di errore dell'autenticazione.
Come ulteriore controllo preventivo, la revoca del codice macchina impedisce al software modifiche la cui applicazione non è più autorizzata. 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, vedi In che modo Google applica l'integrità in fase di avvio in produzione machine learning.
Il titanio prevede l'offload dei processori per la crittografia
I processori con offload (TOP) in titanio per la crittografia contribuiscono a fornire sicurezza durante lo spostamento dell'I/O. Questi TOP sono protetti con Titan o Caliptra RTM I TOP implementano la crittografia autenticata diffusa dei dati in transito e la crittografia autenticata dei dati at-rest a basso costo. Autenticato significa che i dati del cliente hanno una garanzia crittografica 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 Google sono progettate per fornire hardware provenienza. Le schede madri supportano l'attestazione a più livelli. Progettazioni di schede madre salvaguardare i dati dei clienti, anche nell'improbabile eventualità che un utente malintenzionato collega fisicamente un dispositivo dannoso a un computer. I progetti delle schede madri Titanium contribuiscono a consentire il deployment affidabile di ulteriori meccanismi di hardening, 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 eseguono un proxy con tutto il traffico di gestione il design di terze parti. Eseguire il proxy del traffico di gestione significa che dell'infrastruttura non dipende da progetti di terze parti per l'autenticazione, autorizzazione, sicurezza del trasporto o sicurezza di rete.
Le schede madri personalizzate Titanium sono progettate per avere ripristino e backup integrati per garantire disponibilità e recuperabilità. Può ripristinare a causa della maggior parte degli arresti anomali o del danneggiamento 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 ai carichi di lavoro sensibili ai clienti dall'accesso amministrativo di Google. Quando i dati vengono gestite dalla CPU o dalla GPU, Confidential Computing offre una e un controllo preventivo mediante 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 offre una di protezione dei dati e impedire che Google accesso del personale o azioni automatiche errate del software di sistema su larga scala.
Un esempio di sicurezza avanzata offerta dall'architettura Titanium è Modalità riservata per Hyperdisk Balanced. La modalità riservata di Hyperdisk Balanced combina l'archiviazione a blocchi basata su Titanium gli offload, Confidential Computing e Cloud HSM per creare un TEE basato sull'hardware. In altre parole, la modalità riservata per Hyperdisk bilanciato è un'offerta bilanciata per Hyperdisk. Modalità riservata per Il bilanciamento Hyperdisk isola l'infrastruttura in modo che le chiavi sensibili vengano elaborati in un TEE con hardware rooted. Per informazioni sulla recensione di terze parti delle operazioni crittografiche, vedi Report pubblico - Modalità riservata per Hyperdisk - Protezione DEK Analisi.
Servizi di backend regionali a tolleranza di errore
I servizi regionalizzati a tolleranza di errore di backend aiutano a ridurre al minimo l'area interessata un utente malintenzionato con accesso locale. L'infrastruttura di Google è progettata categorizzare i servizi, i sistemi e le zone dal movimento laterale privilegiati di addetti ai lavori 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, così che un utente malintenzionato ottene l'accesso locale deve compromettere più credenziali provenienti dei servizi di infrastruttura per continuare a spostarsi 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 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. La sicurezza hardware Titanium è progettata specificatamente per affrontare un insieme unico di minacce all'infrastruttura di Google e ai dati utente che memorizziamo.
Minacce alle infrastrutture
L'architettura in titanio è progettata per difendersi dalle seguenti categorie di minacce:
- Utente interno non autorizzato con accesso fisico: il nostro personale ha bisogno di accedere a apparecchiature fisiche nei data center per eseguire il deployment, la manutenzione e la riparazione dell'hardware. Questo accesso rappresenta un potenziale vettore di attacco perché personale o appaltatori disonesti avere un motivo commerciale legittimo per riparare fisicamente alcune macchine nei nostri data center.
Utente interno non autorizzato con accesso logico: in modo simile all'accesso fisico ai dati center, il personale deve sviluppare, mantenere, testare, eseguire il debug, supportano più livelli dello stack software di Google. Questi membri del personale includono sviluppatori, tecnici SRE e cloud engineer a contatto con il pubblico.
Per ulteriori informazioni sulle nostre difese contro questa minaccia, consulta l'articolo In che modo Google ne protegge la produzione Google Cloud.
Utente malintenzionato esterno con accesso logico: gli utenti malintenzionati esterni possono ottenere un punto d'appoggio all'interno di un ambiente Google Cloud e tentare di trasferire in modo laterale 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 quale parte dell'ambiente cloud è più vulnerabili 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 dati ai server centrali dei server. L'architettura di sicurezza hardware Titanium è progettata per offrono solide difese contro tali minacce.
| Aggressore | 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 il i nostri strumenti. |
DIMM |
Connettori della memoria fisica |
Questo attacco potrebbe bloccare il DIMM, portarlo fuori dal data center tentare di accedere ai dati utilizzando gli strumenti dell’aggressore. Questa minaccia a volte chiamato attacco cold boot. |
|
Server |
Connettori USB o PCIe |
Questo attacco potrebbe collegare 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 attingere a un cavo Ethernet per accedere a tutti i dati trasferite da un dispositivo all'altro. A questo punto, il traffico di testo in chiaro osservati. |
|
Scheda madre |
Firmware |
Questo attacco potrebbe introdurre un 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 pre-compromissione dell'hardware con che forniscono l'accesso backdoor al server. |
|
Utente malintenzionato con accesso logico |
Carico di lavoro Compute (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 in tessuto |
Accesso fisico o amministrativo |
Questo attacco potrebbe ottenere il controllo root di un router fabric per intercettare tutto il traffico ed esfiltrare o manomettere i dati in chiaro in transito. sul tessuto. |
|
Scheda madre |
Firmware |
Questo attacco potrebbe inviare immagini del firmware difettose alle schede madri, rendendole definitivamente inutilizzabili e rendendo i dati non recuperabili. Un aggressore potrebbe inviare un firmware vulnerabile noto alle macchine per riprendere il controllo utilizzando exploit che abilitano l'esecuzione remota di codice. |
|
Utente malintenzionato esterno con accesso logico |
Server |
VM |
Questo attacco potrebbe lanciare pattern di attacco nel canale laterale pubblico 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 dei dati del 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 scansionare tutte le periferiche per trovare un componente vulnerabile che possa rimanere nella macchina e attaccare i tenant successivi. |
Mappatura dei componenti hardware Titanium alle minacce
L'architettura di sicurezza hardware di Titanium utilizza un approccio multilivello per contribuire a gestire minacce all'infrastruttura specifiche e a prevenire i 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 l'esfiltrazione dei dati dai data center e la modifica di hardware e completamente gestito di Google Cloud. 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 operano in sinergia offrono una difesa multilivello resistente a un’ampia gamma di attacchi.
La tabella seguente descrive alcune delle minacce hardware non autorizzate e indica come l'architettura in titanio può ridurle.
| Minaccia | Mitigazione del titanio |
|---|---|
Un aggressore esfiltra singole unità di dati dai data center per accedere ai relativi dati. |
Chiavi di crittografia dei dati at-rest per prodotti e servizi di archiviazione non vengono mai archiviati in modo permanente sulle macchine in allegato. Le funzionalità di autocrittografia integrate per i supporti di archiviazione abilitato per la difesa in profondità, e utilizzare chiavi che non vengono mai archiviate in modo permanente i contenuti multimediali stessi. 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. RoT integrate all’interno dei pacchetti di silicio ancorano la crittografia pertinente le identità all'interno del pacchetto del chip. Interposer a funzione singola sono la parte principale della sicurezza del nostro piano dati e criptano i dati a ogni fase di elaborazione. I TOP offrono i seguenti vantaggi:
Per unità a prestazioni inferiori vengono utilizzate soluzioni software comprovate come dm-crypt per cui ridurre la superficie di attacco è fondamentale, ad esempio utilizzando le unità di avvio d'uso diversi. |
Un malintenzionato intercetta un cavo di rete e legge i byte sul cavo o sulla fibra. |
I TOP criptano i dati in transito, eliminando così l'opportunità di un di sniffare 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 su switch ToR (Top of Rack) o di rete. Alcune infrastrutture di machine learning utilizzano meccanismi di proprietà di sicurezza per il trasporto. |
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 aggressore scrive contenuto dei chip flash non volatili, Titan RoT segnala in modo sicuro del codice al piano di controllo di Google, progettato per bloccare del dispositivo. Google revoca regolarmente il codice deprecato o con vulnerabilità note su scala mondiale nel nostro parco utilizzando i chip Titan. |
Un aggressore inserisce dispositivi avversari nelle interfacce fisiche dei dati a server o schede centrali per eseguire codice dannoso o esfiltrare dati. |
I design di schede madre personalizzate rimuovono le interfacce utilizzate per inserire dispositivi avversari. Unità di gestione della memoria di input-output (IOMMU), in modo da evitare attacchi PCIe in tutte le nostre completamente gestito di Google Cloud. (Gli urlatori PCIe sono progettati per leggere e scrivere pacchetti arbitrari sul tessuto 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 per l'autenticazione e l'autorizzazione accettate per le funzioni di controllo e gestione su TOP e BMC. I RTM di Caliptra bloccano qualsiasi firmware non approvato. Le nostre le periferiche attendibili attestano l'integrità dell'identità hardware e del codice secondo i nostri di controllo e nessun server viene ammesso in produzione se il record di attestazione non corrisponde all'intento 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 di macchine il cui deployment viene eseguito senza Confidential Computing in dei data center periferici di garanzia. |
Scenario: sfruttamento di server o reti da parte di utenti malintenzionati
Gli aggressori potrebbero utilizzare il cloud pubblico per ospitare i propri carichi di lavoro dannosi sui nostri un'infrastruttura condivisa e a 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 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. Confidential Computing protegge dalla manipolazione della memoria di sistema che si tratti di attacchi fisici o di attacchi hypervisor, e i chip Titan rifiutano rilevare upgrade di software non autorizzati.
La tabella seguente descrive alcuni dei tipi di sfruttamento del server e della rete e come l'architettura Titanium possa ridurle.
| 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 a riposo. Questa mitigazione blocca Un malintenzionato non è riuscito ad accedere ai dati in uso. Chip Titan e Gli RTM di Caliptra impediscono all'utente malintenzionato 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 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 qualsiasi attacco successivo mirato a queste vulnerabilità note. Le misurazioni dell'integrità basate su Titan offrono anche con sicurezza che le mitigazioni, che potrebbero richiedere un'implementazione urgente, abbiano il deployment sulle macchine di destinazione. Rafforzaamo questo approccio rimanendo in prima linea nelle indagini e nella mitigazione dei canali laterali, attraverso tecniche di recupero crediti e pianificazione principale, nonché ricerche avanzate su Meltdown, Spectre, Zenbleed, downfall e altre ancora. |
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 at-rest contribuisce a proteggere da attacchi logici e attacchi fisici con una varietà 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 utente malintenzionato ottiene l'accesso root a una macchina, le credenziali sono legate esclusivamente all'identità privata del server 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 possono tentare di sfruttare i sistemi di Google in in vari modi, tra cui il tentativo di ottenere il controllo root di un router fabric, il push immagini del firmware difettose sulle schede madri e intercettazioni del traffico di rete. L'architettura di sicurezza hardware Titanium protegge da queste minacce utilizzando una varietà di meccanismi, tra cui chip Titan, Caliptra RTM, e servizi isolati a tolleranza di errore di backend.
La tabella seguente descrive alcune delle minacce al piano di controllo e come l'architettura di Titanium può mitigarle.
| Minaccia | Mitigazione del titanio |
|---|---|
Un utente malintenzionato usa credenziali interne per accedere alle VM di Compute Engine che rappresentano il livello 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 ai dati dei clienti da parte di addetti ai lavori di Google è 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 upgrade software non autorizzato, inclusi i push dannosi per il controllo persistente. Scheda madre personalizzata dei progetti 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 il networking e il PCI fossero bloccati da un aggressore, (OOB) può ripristinare il sistema. |
Un aggressore invia un firmware di produzione deprecato e vulnerabili agli attacchi per riprendere il controllo usando le vulnerabilità pubbliche. |
I chip Titan rifiutano le notifiche push errate e aiutano ad applicare la revoca delle il codice vulnerabile noto. Attestano la versione firmware di cui è stato eseguito il deployment sulla macchina e rifiutarla sul piano di controllo. Questa mitigazione aiuta a impedire l'esecuzione di job su una macchina in stato non integro e attiva ed effettuare accertamenti o riparazioni, se necessario. |
Un aggressore abusa delle capacità di debug del silicio necessarie per continuità aziendale, che forniscono il massimo livello immaginabile di accesso ai dati nei sistemi server. |
Caliptra RTM aiuta a garantire che tutti i parametri che consentono interfacce di debug invasive, collegate logicamente o tramite l'inserimento fisico, sono configurati in modo affidabile, misurati crittograficamente e segnalato al 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 utente malintenzionato ottiene il controllo di un servizio di backend per poter accedere degli ambienti del cliente. |
I servizi regionalizzati a tolleranza di errore di backend sono regionalizzati delle credenziali che non consentono l'accesso unilaterale da parte di persone fisiche. 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. Gli 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 di chiavi, la radice le chiavi si trovano in chiavi con air gap all'interno di HSM e casseforti, oppure chiavi che in produzione da un quorum di Paxos di datastore in memoria. |
Passaggi successivi
- Leggi la Panoramica sulla progettazione della sicurezza dell'infrastruttura.
- Implementa Confidential Computing.
Autori: Andrés Lagar-Cavilla, Erlander Lo, Jon McCune, Chris Perry