Attestazione remota di macchine non aggregate

Questi contenuti sono stati aggiornati l'ultima volta a dicembre 2022 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono 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 relativi 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 di data center disaggregati. Invece di un'unica radice di attendibilità, molte macchine contengono radici di attendibilità separate, tra cui root di attendibilità per misurazione (RTM), archiviazione, aggiornamento e 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'altra 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.

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 è un'impresa non banale.

Il sistema descritto in questo documento è progettato per rendere più gestibile il problema dell'attestazione remota per macchine disaggregate. Questa infrastruttura di attestazione è estendibile, in modo da adattarsi per gestire macchine sempre più complesse come si presentano nei 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. Tramite la collaborazione con partner di settore e contributi a enti di standard come Distributed Management Task Force (DMTF), Trusted Computing Group (TCG) e Open Compute Project (OCP), intendiamo continuare a supportare l'innovazione della sicurezza in questo ambito.

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 relative al primo codice modificabile eseguito sul processore. Le misurazioni del codice modificabile successivo devono essere acquisite e riportate a una radice di attendibilità prima dell'esecuzione. Questa disposizione produce una catena di avvio misurata che consente una solida attestazione dello stato critico per la sicurezza del processore.

Attestazione dell'identità del firmware e dell'hardware 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 l'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 recuperare le vulnerabilità critiche del firmware RTM.

La specifica DICE (Device Identifier Compose Engine) è una formalizzazione del pattern che viene utilizzata nella nostra soluzione di attestazione. Il produttore 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 chiave alias contiene una misurazione del firmware RTM e il numero di serie dell'RTM. I verificatori possono essere certi che tutti i dati firmati da una determinata chiave alias siano stati emessi da un RTM descritto dalle misurazioni dell'identità dell'hardware crittografico e del firmware incorporate all'interno della catena di certificati della chiave alias.

Operazioni di attestazione da remoto

Lo schema di attestazione è progettato per garantire che i dati utente e i job vengano inviati solo alle 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 pianificazione 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 trova appena prima della pianificazione del lavoro su una macchina. La macchina ottiene l'accesso ai job e ai dati utente solo dopo il superamento della verifica di attestazione.

Il criterio di attestazione

Google utilizza un documento firmato leggibile dal computer, denominato criterio, 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. I seguenti dettagli per ogni RTM sono rappresentati nel criterio:

  • Il certificato radice di identità attendibile in grado di convalidare le attestazioni emessi 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 che l'RTM deve essere in esecuzione.
  • Le previsioni di misurazione per ogni fase di avvio segnalata 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 automatici di riparazione delle macchine.

Inoltre, il criterio contiene anche un numero di serie di revoca univoco a livello globale che aiuta a impedire il rollback dei criteri non autorizzati. Il seguente diagramma mostra un criterio.

Un criterio di attestazione di esempio.

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 impedire il rollback.
  • Le aspettative RTM enumerano i dettagli per ogni RTM nella macchina.

Le sezioni seguenti descrivono questi elementi in modo più dettagliato.

Assemblea dei criteri

Quando l'hardware di una macchina viene assemblato o riparato, viene creato un modello hardware che definisce tutti gli RTM previsti su quella macchina. Il nostro piano di controllo aiuta a garantire che queste informazioni rimangano aggiornate in tutti gli eventi come riparazioni che prevedono scambi di parti o upgrade dell'hardware.

Inoltre, il piano di controllo mantiene una serie di aspettative riguardo al software che deve essere installato su una macchina, oltre alle aspettative su quali RTM devono misurare quale software. Il piano di controllo utilizza queste aspettative, insieme al modello di 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 allo strumento di verifica remoto durante la attestazione di una macchina. Anziché eseguire una query sul criterio in un database, lo strumento di verifica può recuperare il criterio dalla macchina stessa. Questo approccio è un'importante funzionalità di progettazione, poiché gli scheduler dei job 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.

Flusso di assemblaggio dei criteri.

Il diagramma descrive i seguenti passaggi completati dal piano di controllo nel processo di assemblaggio dei criteri:

  • Ricava il criterio di attestazione dall'assegnazione del pacchetto 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 per 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 autenticare 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 di 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 di base del sistema operativo di ogni macchina. Il push dell'elenco revoche certificati viene eseguito 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 pressioni di emergenza rapide durante le condizioni di risposta agli incidenti.

Tramite l'utilizzo di chiavi pubbliche di verifica e di file CRL archiviati localmente sulla macchina del verificatore, i responsabili della verifica possono convalidare le dichiarazioni di attestazione da macchine remote senza che nessun servizio esterno sia presente nel percorso critico.

Recupero dei criteri di attestazione e convalida delle misurazioni

La procedura di attestazione da remoto di una macchina 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 in modo più approfondito queste fasi.

Fasi di attestazione da remoto.

Recupero e convalida del criterio di attestazione

Lo strumento di verifica remoto recupera il criterio di attestazione firmato per la macchina. Come menzionato in Assemblaggio di criteri, per motivi di disponibilità il criterio viene archiviato come documento firmato sulla macchina di destinazione.

Per verificare che il criterio restituito sia autentico, lo strumento di verifica remoto consulta la copia locale del verificatore dell'elenco revoche certificati pertinente. Questa azione contribuisce a garantire che il criterio recuperato sia stato firmato crittograficamente da un'entità attendibile e che il criterio non sia stato revocato.

Ottenere misurazioni attestate

Lo strumento di verifica remoto sfida la macchina, richiedendo le misurazioni a ogni RTM. Lo strumento di verifica garantisce l'aggiornamento includendo nonce crittografiche in queste richieste. Un'entità sulla macchina, ad esempio un controller di gestione del battiscopa (BMC), instrada ogni richiesta al rispettivo RTM, raccoglie le risposte firmate e le invia nuovamente allo strumento di verifica remoto. Questa entità sulla macchina non ha privilegi dal punto di vista dell'attestazione, in quanto funge solo da trasporto per le misurazioni firmate dell'RTM.

Google utilizza API interne per attestare le misurazioni. Contribuiamo anche ai miglioramenti a Redfish per consentire ai verificatori fuori dalla macchina di testare un BMC per le misurazioni di un RTM utilizzando SPDM. Il routing interno delle macchine viene eseguito tramite protocolli e canali specifici dell'implementazione, tra cui:

  • Scorza sulla subnet
  • Intelligent Platform Management Interface (IPMI)
  • MCTP (Gestione componenti Transport Protocol) su i2c/i3c
  • PCIe
  • Interfaccia periferica seriale (SPI)
  • USB

Valutazione delle misurazioni attestate

Lo strumento di verifica remota di Google convalida le firme emesse da ogni RTM, garantendo che siano basate sull'identità dell'RTM inclusa nel criterio di attestazione della macchina. Tutte 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 esegua il firmware corretto. Per garantire l'aggiornamento, viene controllato il nonce crittografico firmato. Infine, le misurazioni 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, i possibili risultati sono due: l'attestazione ha esito positivo e alla macchina vengono assegnate le credenziali dell'attività e i dati utente oppure l'attestazione non va a buon fine e vengono inviati avvisi all'infrastruttura di riparazione.

Risultati dell'attestazione remota.

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 ai 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 impedire a più macchine di non riuscire a completare l'attestazione. Quando si verifica questo evento, viene inviato un avviso agli SRE. Per le macchine che non vengono corrette tramite il reimaging automatico, viene eseguito il rollback o c'è un'implementazione del software corretto. Fino a quando una macchina non viene nuovamente sottoposta all'attestazione remota, non viene utilizzata per gestire i job dei clienti.

Attestazione riuscita

Se l'attestazione remota di una macchina ha esito positivo, Google la utilizza per fornire job di produzione come VM per i clienti di Google Cloud o elaborazione di immagini per Google Foto. Google richiede che tutte le azioni di job significative che riguardano i servizi di rete siano limitate a credenziali di breve durata per le attività LOAS. 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 la pagina Application Layer Transport Security.

L'attestazione del software è valida quanto l'infrastruttura che crea il software. Per garantire che gli artefatti generati rispecchino fedelmente le nostre intenzioni, abbiamo investito in modo significativo nell'integrità della nostra pipeline di build. 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 come BeyondProd aiuta le macchine dei data center di Google a stabilire connessioni sicure.