Questi contenuti sono stati aggiornati l'ultima volta a maggio 2024 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.
Questo documento descrive l'approccio di Google all'attestazione delle macchine dei data center. L'architettura descritta in questo documento è progettata per essere integrata con standard aperti come Trusted Platform Module (TPM), Security Protocol and Data Model (SPDM) e Redfish. Per nuovi standard o implementazioni di riferimento proposte da Google e relative all'attestazione delle macchine dei data center, consulta il nostro progetto Integrità della piattaforma (PINT) in GitHub. Questo documento è destinato a dirigenti, architetti e revisori della sicurezza.
Panoramica
Google progetta e implementa sempre di più macchine dei data center non aggregate, Invece di un'unica radice di attendibilità, molte macchine contengono radici di attendibilità separate, tra cui le root di attendibilità per la misurazione (RTM), l'archiviazione, l'aggiornamento e il ripristino. Ogni RTM fornisce una sottosezione dell'intera macchina. Ad esempio, una macchina potrebbe avere un RTM che misura e attesta ciò che è stato avviato sulla CPU principale e un altro RTM che misura e attesta ciò che è stato avviato su uno SmartNIC collegato a uno slot PCIe. Il seguente diagramma mostra una macchina di esempio.
La complessità di più RTM in una macchina si aggiunge all'enorme scalabilità e alle aspettative delle macchine dei data center, nonché alle molte complicazioni che possono verificarsi a causa di guasti umani, hardware o software. Per riassumere, garantire l'integrità del firmware del nostro parco risorse è uno sforzo non banale.
Il sistema descritto in questo documento è progettato per rendere più gestibile il problema dell'attestazione remota di macchine disaggregate. Questa infrastruttura di attestazione è estensibile, consentendole di adattarsi per gestire macchine sempre più complesse come appaiono nel data center.
Condividendo questo lavoro, intendiamo fornire il nostro punto di vista su come l'attestazione delle macchine disaggregate può essere eseguita su larga scala. Attraverso la collaborazione con partner di settore e i contributi a organismi di standard come Distributed Management Tasks Force (DMTF), Trusted Computing Group (TCG) e Open Compute Project (OCP), intendiamo continuare a supportare l'innovazione della sicurezza in questo settore.
Proprietà RTM consigliate
Questa sezione illustra alcune proprietà consigliate per gli RTM.
Integrazione hardware RTM
Quando un processore è accoppiato a un RTM, l'RTM dovrebbe acquisire le misurazioni sul primo codice modificabile eseguito su quel processore. Le misurazioni del codice modificabile successivo devono essere acquisite e riportate a una radice di attendibilità prima dell'esecuzione del codice. Questa disposizione produce una catena di avvio misurata che consente un'attestazione solida dello stato critico per la sicurezza del processore.
Attestazione dell'identità hardware e firmware RTM
Ogni RTM deve avere una coppia di chiavi di firma utilizzata per emettere attestazioni per la convalida esterna. La catena di certificati per questa coppia di chiavi deve includere prove crittografiche dell'identità hardware univoca dell'RTM e dell'identità del firmware per qualsiasi codice modificabile eseguito all'interno dell'RTM. La catena di certificati deve essere rooted nel produttore RTM. Questo approccio consente alle macchine di ripristinare le vulnerabilità critiche del firmware RTM.
La specifica DICE (Device Identifier Resolution Engine) è una formalizzazione del pattern utilizzato nella nostra soluzione di attestazione. Il produttore di RTM certifica una coppia unica di chiavi del dispositivo che certifica una coppia di chiavi alias specifica per l'identità hardware e l'immagine del firmware RTM. La catena di certificati delle chiavi alias contiene una misurazione del firmware RTM e del numero di serie dell'RTM. I verificatori possono avere la certezza che tutti i dati firmati da una determinata chiave alias siano stati emessi da un RTM descritto dalle misurazioni dell'identità del firmware e dell'hardware crittografico incorporati nella catena di certificati della chiave alias.
Operazioni di attestazione remota
Lo schema di attestazione è progettato per garantire che i dati utente e i job vengano emessi solo su macchine che eseguono lo stack di avvio previsto, consentendo al contempo l'automazione della manutenzione del parco risorse su larga scala per risolvere i problemi. Il servizio di scheduler dei job, ospitato nel nostro cloud interno, può verificare la raccolta di RTM all'interno della macchina e confrontare le misurazioni attestate risultanti con un criterio univoco per quella macchina. Lo scheduler invia job e dati utente alle macchine solo se le misurazioni attestate sono conformi ai criteri della macchina.
L'attestazione remota include le due operazioni seguenti:
Generazione dei criteri di attestazione, che si verifica ogni volta che l'hardware o il software previsto di una macchina viene modificato.
Verifica dell'attestazione, che avviene in punti definiti nei nostri flussi di gestione delle macchine. Uno di questi punti si verifica poco prima che il lavoro sia programmato su una macchina. La macchina ottiene l'accesso ai job e ai dati utente solo dopo il superamento della verifica dell'attestazione.
Il criterio di attestazione
Google utilizza un documento firmato leggibile dalle macchine, chiamato criteri, per descrivere l'hardware e il software che si prevede saranno in esecuzione all'interno di una macchina. Questo criterio può essere attestato dalla raccolta di RTM della macchina. Nel criterio sono riportati i seguenti dettagli per ogni RTM:
- Il certificato radice di identità attendibile in grado di convalidare le attestazioni emesse dall'RTM.
- L'identità hardware univoca a livello globale che identifica in modo univoco l'RTM.
- L'identità del firmware che descrive la versione prevista su cui deve essere in esecuzione l'RTM.
- Le previste di misurazione per ogni fase di avvio riportate dall'RTM.
- Un identificatore per l'RTM, analogo a un nome della risorsa Redfish.
- Un identificatore che collega l'RTM alla sua posizione fisica all'interno di una macchina. Questo identificatore è analogo al nome di una risorsa Redfish e viene utilizzato dai sistemi di riparazione automatica delle macchine.
Inoltre, il criterio contiene anche un numero di serie di revoca univoco a livello globale che contribuisce a impedire il rollback non autorizzato del criterio. Il seguente diagramma mostra un criterio.
Il diagramma mostra i seguenti elementi delle norme:
- La firma fornisce l'autenticazione basata sui criteri.
- Il numero di serie della revoca fornisce l'aggiornamento dei criteri per evitare il rollback.
- Le aspettative RTM enumerano i dettagli per ogni RTM nella macchina.
Le sezioni seguenti descrivono questi elementi in modo più dettagliato.
Assemblaggio di criteri
Quando l'hardware di una macchina viene assemblato o riparato, viene creato un modello hardware che definisce gli RTM previsti su quella macchina. Il nostro piano di controllo aiuta a garantire che queste informazioni rimangano aggiornate in caso di eventi come riparazioni che prevedono la sostituzione di componenti o upgrade dell'hardware.
Inoltre, il piano di controllo mantiene una serie di aspettative riguardo al software da installare su una macchina, oltre alle aspettative su quali RTM devono misurare quale software. Il piano di controllo utilizza queste aspettative, insieme al modello hardware, per generare un criterio di attestazione firmato e revocabile che descriva lo stato previsto della macchina.
Il criterio firmato viene quindi scritto nell'archiviazione permanente sulla macchina che descrive. Questo approccio consente di ridurre il numero di dipendenze di rete e servizi necessarie al verificatore remoto durante la verifica di una macchina. Anziché eseguire una query su un database per il criterio, lo strumento di verifica può recuperare il criterio dalla macchina stessa. Questo approccio è un'importante caratteristica di progettazione, poiché i job scheduler hanno requisiti SLO rigorosi e devono rimanere ad alta disponibilità. La riduzione delle dipendenze di rete di queste macchine da altri servizi contribuisce a ridurre il rischio di interruzioni. Il seguente diagramma mostra questo flusso di eventi.
Il diagramma descrive i seguenti passaggi che il piano di controllo completa nel processo di assemblaggio dei criteri:
- Ricava il criterio di attestazione dall'assegnazione dei pacchetti software e dal modello di hardware della macchina.
- Firma le norme.
- Archivia il criterio sul computer del data center.
Revoca dei criteri
L'intent hardware e software di una determinata macchina cambia nel tempo. Quando l'intent cambia, i criteri precedenti devono essere revocati. Ogni criterio di attestazione firmato include un numero di serie univoco di revoca. I verificatori ricevono la chiave pubblica appropriata per l'autenticazione di un criterio firmato e l'elenco di revoca dei certificati appropriato per garantire che il criterio sia ancora valido.
L'esecuzione di query interattive su un server delle chiavi o un database di revoche influisce sulla disponibilità dei programmi di pianificazione dei job. Google utilizza invece un modello asincrono. Il set di chiavi pubbliche utilizzate per autenticare i criteri di attestazione firmata viene inviato tramite push come parte dell'immagine del sistema operativo di base di ogni macchina. Il CRL viene inviato in modo asincrono utilizzando lo stesso sistema centralizzato di deployment delle revoche che Google utilizza per altri tipi di credenziali. Questo sistema è già progettato per un funzionamento affidabile in condizioni normali, con la capacità di eseguire rapidi push di emergenza durante le condizioni di risposta agli incidenti.
Utilizzando le chiavi pubbliche di verifica e i file CRL archiviati in locale sulla macchina del verificatore, i verificatori possono convalidare le dichiarazioni di attestazione da macchine remote senza dover disporre di servizi esterni nel percorso critico.
Recupero dei criteri di attestazione e convalida delle misurazioni
La procedura di attestazione di una macchina da remoto prevede le seguenti fasi:
- Recupero e convalida del criterio di attestazione.
- Ottenere misurazioni attestate dagli RTM della macchina.
- Valutazione delle misurazioni attestate in base al criterio.
Il diagramma e le sezioni seguenti descrivono ulteriormente queste fasi.
Recupero e convalida del criterio di attestazione
Lo strumento di verifica remoto recupera il criterio di attestazione firmata per la macchina. Come menzionato nell'assemblaggio dei criteri, per motivi di disponibilità il criterio viene archiviato come documento firmato sulla macchina di destinazione.
Per verificare che le norme restituite siano autentica, lo strumento di verifica remoto consulta la copia locale del verificatore pertinente nell'elenco revoche certificati. Questa azione contribuisce a garantire che il criterio recuperato sia stato firmato crittograficamente da un'entità attendibile e che non sia stato revocato.
Ottenere misurazioni attestate
Il verificatore remoto sfida la macchina, richiedendo le misurazioni a ogni RTM. Lo strumento di verifica garantisce l'aggiornamento includendo nonce crittografici in queste richieste. Un'entità sulla macchina, ad esempio un controller di gestione a battiscopa (BMC), instrada ogni richiesta al rispettivo RTM, raccoglie le risposte firmate e le invia di nuovo allo strumento di verifica remoto. Questa entità sulla macchina è senza privilegi dal punto di vista dell'attestazione, in quanto funge solo da trasporto per le misurazioni firmate di RTM.
Google utilizza API interne per attestare le misurazioni. Inoltre, contribuiamo a miglioramenti in Redfish per consentire ai verificatori esterni al computer di testare un BMC per le misurazioni di una RTM utilizzando SPDM. Il routing interno delle macchine viene eseguito su protocolli e canali specifici dell'implementazione, tra cui:
- Redfish oltre una subnet
- Interfaccia di gestione della piattaforma intelligente (IPMI)
- MCTP (Gestione dei componenti Transport Protocol) su i2c/i3c
- PCIe
- Interfaccia periferica seriale (SPI)
- USB
Valutazione delle misurazioni attestate
Il verificatore remoto di Google convalida le firme emesse da ogni RTM, garantendo che restino all'identità dell'RTM inclusa nel criterio di attestazione della macchina. Le identità hardware e firmware presenti nella catena di certificati RTM vengono convalidate in base al criterio, assicurando che ogni RTM sia l'istanza corretta e che esegua il firmware corretto. Per garantire l'aggiornamento, viene controllato il nonce crittografico firmato. Infine, le misurazioni attestate vengono valutate per verificare che corrispondano alle aspettative del criterio per il dispositivo in questione.
Reazione ai risultati dell'attestazione remota
Una volta completata l'attestazione, i risultati devono essere utilizzati per determinare il destino della macchina che viene attestata. Come mostrato nel diagramma, i risultati possibili sono due: l'attestazione ha esito positivo e alla macchina vengono emessi le credenziali dell'attività e i dati utente oppure l'attestazione non va a buon fine e gli avvisi vengono inviati all'infrastruttura di riparazione.
Le sezioni seguenti forniscono ulteriori informazioni su questi processi.
Attestazione non riuscita
Se l'attestazione di una macchina non va a buon fine, Google non la utilizza per fornire i job dei clienti. Viene invece inviato un avviso all'infrastruttura di riparazione, che tenta di ricreare automaticamente l'immagine della macchina. Sebbene gli errori di attestazione possano essere dovuti a intenti dannosi, la maggior parte degli errori di attestazione è dovuta a bug nelle implementazioni del software. Di conseguenza, le implementazioni con errori di attestazione in aumento vengono interrotte automaticamente per evitare che l'attestazione venga completata da più macchine. Quando si verifica questo evento, viene inviato un avviso agli SRE. Per le macchine non corrette tramite il reimaging automatico, viene eseguito il rollback dell'implementazione o del software corretto. Fino a quando una macchina non viene nuovamente sottoposta ad attestazione remota, non viene utilizzata per gestire i job del cliente.
Attestazione riuscita
Se l'attestazione remota di una macchina ha esito positivo, Google la utilizza per fornire job di produzione come le VM per i clienti di Google Cloud o l'elaborazione di immagini per Google Foto. Google richiede azioni job significative che riguardano i servizi di rete, basate su credenziali per le attività LOAS a breve durata. Queste credenziali vengono concesse tramite una connessione sicura dopo una verifica di attestazione riuscita e forniscono i privilegi richiesti dal job. Per ulteriori informazioni su queste credenziali, consulta Application Layer Transport Security.
L'attestazione software è valida quanto l'infrastruttura che lo crea. Per fare in modo che gli artefatti risultanti rispecchino fedelmente la nostra intenzione, abbiamo investito in modo significativo nell'integrità della nostra pipeline di creazione. Per ulteriori informazioni su uno standard proposto da Google per affrontare l'integrità e l'autenticità della catena di fornitura del software, consulta la pagina Integrità della catena di fornitura del software.
Passaggi successivi
Scopri in che modo BeyondProd consente alle macchine dei data center di Google di stabilire connessioni sicure.