Questi contenuti sono stati aggiornati a maggio 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.
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 proposti da Google e correlati all'attestazione delle macchine dei data center, consulta il nostro progetto Platform Integrity (PINT) su GitHub. Questo documento è rivolto a responsabili della sicurezza, architetti della sicurezza e revisori.
Panoramica
Sempre più spesso, Google progetta e implementa macchine di data center disaggregate. Anziché una singola radice di attendibilità, molte macchine contengono radici di attendibilità separate, tra cui le radici di attendibilità per la misurazione (RTM), lo spazio di archiviazione, l'aggiornamento e il recupero. Ogni RTM serve 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 una SmartNIC collegata a uno slot PCIe. Il seguente diagramma mostra un esempio di macchina.
La complessità di più RTM in una macchina aumenta l'enorme scala e le aspettative delle macchine del data center, nonché le molte complicazioni che possono verificarsi a causa di errori umani, hardware o software. In sintesi, garantire l'integrità del firmware della nostra flotta non è un'impresa banale.
Il sistema descritto in questo documento è progettato per rendere più gestibile il problema dell'attestazione da remoto per le macchine disaggregate. Questa infrastruttura di attestazione è estensibile, il che le consente di adattarsi al servizio di macchine sempre più complesse man mano che appaiono nel data center.
Con la condivisione di questo lavoro, il nostro obiettivo è fornire la nostra prospettiva su come l'attestazione delle macchine disaggregate può essere eseguita su larga scala. Attraverso la collaborazione con i partner del settore e i contributi a enti di standardizzazione come Distributed Management Task Force (DMTF), Trusted Computing Group (TCG) e Open Compute Project (OCP), intendiamo continuare a supportare l'innovazione in materia di sicurezza in questo ambito.
Proprietà RTM consigliate
Questa sezione illustra alcune proprietà consigliate per gli annunci adattabili della rete di ricerca.
Integrazione hardware RTM
Quando un processore è accoppiato a un RTM, quest'ultimo deve acquisire le misurazioni sul primo codice mutabile eseguito sul processore. Le misurazioni del codice mutabile successivo devono essere acquisite e registrate in una radice di attendibilità prima dell'esecuzione del codice. Questa disposizione produce una catena di avvio misurata che consente un'attestazione solida dello stato del processore critico per la sicurezza.
Attestazione dell'identità dell'hardware e del 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 cryptographiche dell'identità hardware univoca dell'RTM e dell'identità del firmware per qualsiasi codice mutabile eseguito all'interno dell'RTM. La catena di certificati deve essere basata sul produttore RTM. Questo approccio consente alle macchine di recuperare dalle vulnerabilità critiche del firmware RTM.
La specifica Device Identifier Composition Engine (DICE) è una formalizzazione del pattern utilizzato nella nostra soluzione di attestazione. Il produttore dell'RTM certifica una coppia di chiavi del dispositivo univoca, che certifica una coppia di chiavi dell'alias specifica per l'identità hardware e l'immagine del firmware dell'RTM. La catena di certificati della chiave dell'alias contiene una misurazione del firmware dell'RTM e del numero di serie dell'RTM. I verificatori possono essere certi che qualsiasi dato firmato da una determinata chiave alias sia stato emesso da un RTM descritto dalle misurazioni dell'identità dell'hardware e del firmware crittografici incorporate nella catena di certificati della chiave alias.
Operazioni di attestazione da remoto
Lo schema di attestazione è progettato per garantire che i dati e i job degli utenti vengano emessi solo alle macchine che eseguono lo stack di avvio previsto, consentendo al contempo l'automazione della manutenzione del parco macchine su larga scala per risolvere i problemi. Il servizio di pianificazione dei job, ospitato nel nostro cloud interno, può mettere in discussione la raccolta di RTM all'interno della macchina e confrontare le misurazioni attestate risultanti con un criterio specifico per la macchina. Il programmatore invia job e dati utente alle macchine solo se le misurazioni attestate sono conformi alle norme della macchina.
L'attestazione remota include le seguenti due operazioni:
Generazione dei criteri di attestazione, che si verifica ogni volta che l'hardware o il software previsti di una macchina vengono modificati.
Verifica dell'attestazione, che avviene in punti definiti dei nostri flussi di gestione delle macchine. Uno di questi punti si trova appena prima della pianificazione del lavoro su una macchina. La macchina ottiene l'accesso ai job e ai dati utente solo dopo che la verifica dell'attestazione è andata a buon fine.
Il criterio di attestazione
Google utilizza un documento firmato leggibile dalla macchina, chiamato criterio, per descrivere l'hardware e il software che dovrebbero essere in esecuzione all'interno di un computer. Questo criterio può essere verificato dalla raccolta di RTM della macchina. I seguenti dettagli per ogni RTM sono rappresentati nel criterio:
- Il certificato radice di identità attendibile che può convalidare le attestazioni emesse dall'RTM.
- L'identità hardware univoca che identifica l'RTM.
- L'identità del firmware che descrive la versione prevista che deve essere in esecuzione sul RTM.
- Le aspettative di misurazione per ogni fase di avvio registrate 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 un computer. 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 mondiale che aiuta a impedire il rollback non autorizzato dei criteri. Il seguente diagramma mostra un criterio.
Il diagramma mostra i seguenti elementi delle norme:
- La firma fornisce l'autenticazione dei criteri.
- Il numero di serie della revoca garantisce l'aggiornamento delle norme per contribuire a evitare il rollback.
- Le aspettative RTM elencano i dettagli per ogni RTM nella macchina.
Le sezioni seguenti descrivono questi elementi in modo più dettagliato.
Assemblaggio delle norme
Quando l'hardware di una macchina viene assemblato o riparato, viene creato un modello hardware che definisce i RTM previsti sulla macchina. Il nostro piano di controllo contribuisce a garantire che queste informazioni rimangano aggiornate in caso di eventi come riparazioni che prevedono la sostituzione di componenti o l'upgrade dell'hardware.
Inoltre, il piano di controllo gestisce un insieme di aspettative sul software che deve essere installato su una macchina, nonché sulle RTM che 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 descrive lo stato previsto della macchina.
Il criterio firmato viene poi scritto nello spazio di archiviazione persistente della macchina che descrive. Questo approccio consente di ridurre il numero di dipendenze di rete e servizi necessarie al verificatore remoto durante l'attestazione di una macchina. Anziché eseguire una query su un database per trovare il criterio, il verificatore può recuperarlo dalla macchina stessa. Questo approccio è una funzionalità di progettazione importante, poiché gli schedulatori dei job hanno requisiti SLO rigorosi e devono rimanere altamente disponibili. Ridurre le 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 completati dal piano di controllo nel processo di assemblaggio delle norme:
- Deduce il criterio di attestazione dall'assegnazione del pacchetto software e dal modello hardware della macchina.
- Firma le norme.
- Memorizza il criterio sulla macchina del data center.
Revoca delle norme
L'intent hardware e software di una determinata macchina cambia nel tempo. Quando l'intent cambia, le vecchie norme devono essere revocate. Ogni criterio di attestazione firmato include un numero di serie di revoca univoco. I verificatori ottengono la chiave pubblica appropriata per autenticare un criterio firmato e l'elenco di revoca dei certificati appropriato per verificare che il criterio sia ancora valido.
La query interattiva su un server di chiavi o un database di revoca influisce sulla disponibilità degli schedulatori dei job. Google utilizza invece un modello asincrono. L'insieme di chiavi pubbliche utilizzate per autenticare i criteri di attestazione firmati viene inviato come parte dell'immagine del sistema operativo di base di ogni macchina. Il CRL viene inviato in modo asincrono utilizzando lo stesso sistema di implementazione della revoca centralizzata utilizzato da Google per altri tipi di credenziali. Questo sistema è già progettato per un funzionamento affidabile in condizioni normali, con la possibilità di eseguire push di emergenza rapidi in caso di risposta agli incidenti.
Utilizzando le chiavi pubbliche di verifica e i file CRL archiviati localmente sulla macchina del verificatore, i verificatori possono convalidare le attestazioni da macchine remote senza avere servizi esterni nel percorso critico.
Recupero dei criteri di attestazione e convalida delle misurazioni
La procedura di attestazione da remoto di una macchina è composta dalle seguenti fasi:
- Recupero e convalida del criterio di attestazione.
- Ottenimento di misurazioni attestate dagli RTM della macchina.
- Valutazione delle misurazioni attestate in base alle norme.
Il diagramma e le sezioni seguenti descrivono ulteriormente queste fasi.
Recupero e convalida del criterio di attestazione
Il verificatore remoto recupera il criterio di attestazione firmato per la macchina. Come discusso in Assembly dei criteri, per motivi di disponibilità, il criterio viene archiviato come documento firmato sulla macchina di destinazione.
Per verificare che il criterio restituito sia autentico, il verificatore remoto consulta la copia locale dell'elenco revoche certificati pertinente. Questa azione contribuisce ad assicurare che il criterio recuperato sia stato firmato criptograficamente da un'entità attendibile e che non sia stato revocato.
Ottenere misurazioni attestate
Il verificatore remoto mette alla prova la macchina, richiedendo misurazioni da ogni RTM. Il verificatore garantisce l'aggiornamento includendo nonce crittografici in queste richieste. Un'entità on-machine, come un controller di gestione della base di supporto (BMC), indirizza ogni richiesta al rispettivo RTM, raccoglie le risposte firmate e le invia nuovamente al verificatore remoto. Questa entità on-machine non ha privilegi dal punto di vista dell'attestazione, in quanto serve solo come mezzo di trasporto per le misurazioni firmate dell'RTM.
Google utilizza API interne per attestare le misurazioni. Inoltre, contribuiamo con miglioramenti a Redfish per consentire ai verificatori off-machine di contestare un BMC per le misurazioni di un RTM utilizzando SPDM. Il routing interno delle macchine viene eseguito su protocolli e canali specifici dell'implementazione, tra cui:
- Redfish tramite subnet
- Intelligent Platform Management Interface (IPMI)
- Management Component Transport Protocol (MCTP) 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, assicurandosi che risalgano all'identità dell'RTM inclusa nel criterio di attestazione della macchina. Le identità hardware e firmware presenti nella catena di certificati dell'RTM vengono convalidate in base alle norme, per garantire che ogni RTM sia l'istanza corretta ed 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 delle norme per il dispositivo in questione.
Reagire ai risultati dell'attestazione da remoto
Al termine dell'attestazione, i risultati devono essere utilizzati per determinare il destino della macchina in fase di attestazione. Come mostrato nel diagramma, sono possibili due risultati: l'attestazione è riuscita e alla macchina vengono emesse credenziali delle attività e dati utente oppure l'attestazione non va a buon fine e vengono inviati avvisi all'infrastruttura delle riparazioni.
Le sezioni seguenti forniscono ulteriori informazioni su queste procedure.
Attestazione non riuscita
Se l'attestazione di una macchina non va a buon fine, Google non la utilizza per eseguire i job dei clienti. Viene invece inviato un avviso all'infrastruttura delle riparazioni, che tenta di ripristinare automaticamente l'immagine della macchina. Sebbene gli errori di attestazione possano essere dovuti a intenti malevoli, la maggior parte è dovuta a bug nell'implementazione del software. Pertanto, le implementazioni con un numero crescente di errori di attestazione vengono interrotte automaticamente per contribuire a evitare che un numero maggiore di macchine non superi l'attestazione. Quando si verifica questo evento, viene inviato un avviso agli SRE. Per le macchine che non vengono riparate con la reimaging automatica, viene eseguito il rollback dell'implementazione o viene eseguita l'implementazione del software corretto. Finché una macchina non supera nuovamente un'attestazione remota, non viene utilizzata per eseguire i job dei clienti.
Attestazione riuscita
Se l'attestazione remota di una macchina va a buon fine, Google la utilizza per eseguire job di produzione come VM per i clienti Google Cloud o l'elaborazione di immagini per Google Foto. Google richiede che le azioni di job significative che coinvolgeno servizi di rete siano protette da credenziali di task LOAS di breve durata. Queste credenziali vengono concesse tramite una connessione sicura dopo una verifica di attestazione andata a buon fine e forniscono i privilegi richiesti dal lavoro. Per ulteriori informazioni su queste credenziali, consulta Application Layer Transport Security.
L'attestazione del software è valida solo se l'infrastruttura che lo genera è sicura. Per garantire che gli elementi risultanti riflettano con precisione la nostra intenzione, abbiamo investito in modo significativo nell'integrità della nostra pipeline di compilazione. Per saperne di più su uno standard proposto da Google per gestire l'integrità e l'autenticità della catena di fornitura del software, consulta Integrità della catena di fornitura del software.
Passaggi successivi
Scopri in che modo BeyondProd aiuta le macchine dei data center di Google a stabilire connessioni sicure.