Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo al momento della loro stesura. Le norme e i 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 automatica 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 i nuovi standard o le nuove implementazioni di riferimento proposte da Google e correlate all'attestazione delle macchine dei data center, consulta il nostro progetto Integrity della piattaforma (PINT) in GitHub. Questo documento è rivolto a dirigenti, architetti della sicurezza e revisori.
Panoramica
Google progetta e implementa sempre più macchine di data center disaggregati. Invece di un'unica radice di attendibilità, molte macchine contengono radici di attendibilità separate, tra cui le radice di attendibilità per la misurazione (RTM), archiviazione, aggiornamento e ripristino. 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 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 scala e alle aspettative delle macchine dei data center e a molte complicazioni che possono verificarsi a causa di guasti umani, hardware o software. In sintesi, garantire l'integrità del firmware del nostro parco risorse è un'impresa non banale.
Il sistema descritto in questo documento è stato progettato per rendere più gestibile il problema dell'attestazione remota per le macchine disaggregate. Questa infrastruttura di attestazione è estensibile, consentendole di adattarsi per gestire macchine sempre più complesse così come vengono visualizzate nel data center.
Condividendo questo lavoro, miriamo a fornire il nostro punto di vista su come l'attestazione delle macchine disaggregate può essere eseguita su larga scala. Attraverso la collaborazione con partner del settore e contributi ad enti 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 ambito.
Proprietà RTM consigliate
Questa sezione introduce alcune proprietà che consigliamo per i sistemi RTM.
Integrazione hardware RTM
Quando un processore è abbinato a un RTM, l'RTM dovrebbe acquisire le misurazioni relative al primo codice mutabile in esecuzione su quel processore. Le misurazioni del codice modificabile successivamente 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 una solida attestazione 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 la prova crittografica dell'identità hardware univoca del RTM e dell'identità del firmware per qualsiasi codice modificabile all'interno del RTM. La catena di certificati deve essere radicata nel produttore RTM. Questo approccio consente alle macchine di ripristinare le vulnerabilità critiche del firmware RTM.
La specifica DICE (Device Identifier Compose Engine) è una formalizzazione del pattern utilizzato nella nostra soluzione di attestazione. Il produttore RTM certifica una coppia di chiavi univoca del dispositivo, che certifica una coppia di chiavi alias specifica per l'identità hardware e l'immagine del firmware di RTM. La catena di certificati 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 sono stati emessi da un RTM descritto dalle misurazioni dell'identità hardware e firmware di crittografia incorporate nella catena di certificati di quella chiave alias.
Operazioni di attestazione da remoto
Lo schema di attestazione è progettato per garantire che i dati e i job utente vengano inviati solo alle macchine che eseguono lo stack di avvio previsto, consentendo comunque l'automazione della manutenzione del parco risorse su larga scala per risolvere i problemi. Il servizio scheduler di 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 viene eseguita in punti definiti nei flussi di gestione delle macchine. Uno di questi punti è poco prima che il lavoro venga programmato su una macchina. La macchina può accedere ai job e ai dati utente solo dopo il superamento della verifica dell'attestazione.
Il criterio di attestazione
Google utilizza un documento firmato leggibile da una macchina, denominato criteri, per descrivere l'hardware e il software in esecuzione all'interno di una macchina. Questo criterio può essere attestato dalla raccolta di RTM della macchina. I seguenti dettagli per ogni RTM sono rappresentati nelle norme:
- Il certificato radice dell'identità attendibile in grado di convalidare le attestazioni emesse dal RTM.
- L'identità hardware univoca a livello globale che identifica in modo univoco il sistema RTM.
- L'identità del firmware che descrive la versione prevista che deve essere in esecuzione l'RTM.
- Le previsioni relative alla misurazione per ogni fase di avvio riportata da 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 automatizzati di riparazione macchine.
Il criterio contiene anche un numero di serie di revoca univoco a livello globale che consente di impedire il rollback non autorizzato dei criteri. Il seguente diagramma mostra un criterio.
Il diagramma mostra i seguenti elementi della norma:
- La firma fornisce l'autenticazione dei criteri.
- Il numero di serie di revoca fornisce l'aggiornamento dei criteri per prevenire il rollback.
- Le aspettative RTM elencano 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 di hardware che definisce i RTM previsti su quella macchina. Il nostro piano di controllo contribuisce a garantire che queste informazioni rimangano aggiornate in tutti gli eventi, come le riparazioni che prevedono lo scambio di parti o gli upgrade dell'hardware.
Inoltre, il piano di controllo mantiene un insieme di aspettative circa il software che deve essere installato su una macchina, insieme 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 nello spazio di archiviazione permanente sulla macchina descritta. 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 il criterio, lo strumento di verifica può recuperare il criterio dalla macchina stessa. Questo approccio è un'importante funzionalità di progettazione, poiché i job scheduler hanno requisiti rigidi per gli SLO e devono rimanere ad alta disponibilità. La riduzione delle dipendenze di rete di queste macchine su altri servizi aiuta 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 dei criteri:
- Deriva il criterio di attestazione dall'assegnazione del pacchetto software e dal modello hardware della macchina.
- Firma il criterio.
- Archivia il criterio nel computer del data center.
Revoca delle norme
L'intent hardware e software di una determinata macchina cambia nel tempo. Quando l'intent cambia, i vecchi criteri devono essere revocati. 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 garantire che il criterio sia ancora valido.
L'esecuzione interattiva di query su un server delle chiavi o su un database di revoca influisce sulla disponibilità dei pianificatori dei job. Google utilizza invece un modello asincrono. Il set di chiavi pubbliche utilizzate per autenticare i criteri di attestazione con firma viene inviato all'immagine del sistema operativo di base di ogni macchina. L'elenco revoche certificati viene inviato in modo asincrono utilizzando lo stesso sistema centralizzato di deployment delle revoche che utilizza Google per altri tipi di credenziali. Questo sistema è già stato progettato per un funzionamento affidabile in condizioni normali, con la possibilità di eseguire spinte di emergenza rapide durante le condizioni di risposta agli incidenti.
Utilizzando le chiavi pubbliche di verifica e i file CRL archiviati localmente sul computer del verificatore, i verificatori possono convalidare istruzioni di attestazione da macchine remote senza avere servizi esterni nel percorso critico.
Recupero dei criteri di attestazione e convalida delle misurazioni
Il processo di attestazione remota di una macchina prevede le seguenti fasi:
- Recupero e convalida del criterio di attestazione.
- Ottenere misurazioni attestate dai RTM della macchina.
- Valutazione delle misurazioni attestate in base al criterio.
Il diagramma e le sezioni seguenti descrivono nel dettaglio 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 sul computer di destinazione.
Per verificare che il criterio restituito sia autentico, lo strumento di verifica remoto consulta la copia locale del responsabile della verifica pertinente. Questa azione consente di garantire che il criterio recuperato sia stato firmato tramite crittografia da un'entità attendibile e che il criterio non sia stato revocato.
Ottenere misurazioni attestate
Lo strumento di verifica remoto interroga la macchina, richiedendo le misurazioni da 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 al verificatore remoto. Questa entità sulla macchina non è privilegiata dal punto di vista dell'attestazione, poiché funge solo da trasporto per le misurazioni firmate di RTM.
Google utilizza API interne per attestare le misurazioni. Contribuiamo inoltre a Redfish per consentire ai verificatori fuori macchina di sfidare un BMC per le misurazioni di RTM utilizzando SPDM. Il routing delle macchine interne avviene tramite protocolli e canali specifici dell'implementazione, tra cui:
- Redfish sulla subnet
- Intelligent Platform Management Interface (IPMI)
- Protocollo di trasporto dei componenti di gestione (MCTP) su i2c/i3c
- PCIe
- Interfaccia periferica seriale (SPI)
- USB
Valutazione di misurazioni attestate
Lo strumento di verifica remota di Google convalida le firme emesse da ciascun RTM, assicurandosi che risalgano all'identità RTM inclusa nei criteri di attestazione della macchina. Le identità hardware e firmware presenti nella catena di certificati RTM vengono convalidate in base al criterio, garantendo 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 misure attestate vengono valutate per garantire 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 attestata. Come mostrato nel diagramma, sono possibili due risultati: l'attestazione ha esito positivo e alla macchina vengono emessi le credenziali dell'attività e i dati utente oppure l'attestazione ha esito negativo e vengono inviati avvisi all'infrastruttura di riparazione.
Le sezioni seguenti forniscono ulteriori informazioni su questi processi.
Attestazione non riuscita
Se l'attestazione di una macchina non ha esito positivo, Google non utilizza la macchina per gestire i job del cliente. 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 un intento dannoso, 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 più macchine non superino l'attestazione. Quando si verifica questo evento, viene inviato un avviso agli SRE. Per le macchine per cui non sono stati risolti i problemi con la nuova immagine automatica, viene eseguito il rollback dell'implementazione oppure viene eseguita l'implementazione di un software corretto. Una macchina non viene utilizzata per gestire i job del cliente finché non viene ripetuta l'attestazione remota.
Attestazione riuscita
Se l'attestazione remota di una macchina ha esito positivo, Google utilizza la macchina per pubblicare job di produzione come VM per i clienti di Google Cloud o elaborazione di immagini per Google Foto. Google richiede che le azioni di job significative che implicano servizi di rete siano controllate da credenziali attività LOAS di 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 del software è valida solo quanto l'infrastruttura che lo crea. Per garantire che gli artefatti risultanti rispecchino accuratamente il nostro intento, abbiamo investito in modo significativo nell'integrità della nostra pipeline di compilazione. Per maggiori informazioni 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 come BeyondProd aiuta le macchine dei data center di Google a stabilire connessioni sicure.