Questi contenuti sono stati aggiornati l'ultima volta a dicembre 2022 e rappresentano lo status quo del momento in cui sono stati scritti. 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), Protocollo di sicurezza e modello di dati (SPDM) e Scorfano. Per i nuovi standard o le implementazioni di riferimento proposte da Google e relativi all'attestazione delle macchine dei data center, consulta il nostro progetto Platform Integrity (PINT) in GitHub. Questo documento è destinato a responsabili della sicurezza, architetti della sicurezza e revisori dei conti.
Panoramica
Google progetta e implementa sempre più macchine di data center disaggregate. Invece di una singola radice di attendibilità, molte macchine contengono origini di attendibilità separate, tra cui le origini di attendibilità per la misurazione (RTM), l'archiviazione, l'aggiornamento e il recupero. Ogni RTM gestisce una sottosezione dell'intera macchina. Ad esempio, una macchina potrebbe avere un RTM che misura e attesta cosa è 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 del data center, oltre a molte complicazioni che possono verificarsi a causa di errori umani, hardware o software. Per riassumere, l'integrità del firmware del nostro parco risorse è un'operazione non banale.
Il sistema descritto in questo documento è progettato per rendere più gestibile il problema dell'attenuazione remota per le macchine disaggregate. Questa infrastruttura di attestazione è estensibile, adattandola per gestire macchine sempre più complesse così come vengono visualizzate nel data center.
Condividendo questo lavoro, vogliamo fornire il nostro punto di vista su come si può fare l'attestazione di macchina disaggregata su larga scala. Attraverso la collaborazione con partner di settore e contributi a organismi 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 spazio.
Proprietà RTM consigliate
Questa sezione introduce alcune proprietà che consigliamo ai RTM.
Integrazione hardware RTM
Quando un processore è associato a un RTM, quest'ultimo deve acquisire le misurazioni sul primo codice modificabile che viene eseguito su quel processore. Il codice modificabile successivo deve eseguire l'acquisizione e la segnalazione delle sue misurazioni a una radice di attendibilità prima dell'esecuzione del codice. Questa disposizione produce una catena di avvio misurata che consente un'alta affidabilità 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 di 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 di qualsiasi codice modificabile in esecuzione all'interno del 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 Composition Engine) è una formalizzazione del pattern utilizzato nella nostra soluzione di attestazione. Il produttore dell'RTM certifica una coppia di chiavi univoca del dispositivo, che certifica una coppia di chiavi dell'alias specifica per l'identità hardware e l'immagine firmware dell'RTM. La catena di certificati della chiave alias contiene una misurazione del firmware RTM e del numero di serie dell'RTM. I verificatori possono essere sicuri che tutti i dati firmati da una determinata chiave alias sono stati emessi da un RTM descritto dalle misurazioni dell'hardware crittografico e delle misurazioni dell'identità del firmware incorporate nella catena di certificati della chiave alias.
Operazioni di attestazione remota
Lo schema di attestazione è progettato per garantire che i dati e i job degli utenti vengano emessi solo su 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 di scheduler di job, ospitato nel nostro cloud interno, può testare la raccolta di RTM all'interno della macchina e confrontare le misurazioni attestate risultanti con un criterio univoco per la macchina. Lo scheduler fornisce job e dati utente alle macchine solo se le misurazioni attestate sono conformi ai criteri della macchina.
L'attestazione da remoto 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 vengono modificati.
Verifica dell'attestazione, che viene eseguita in momenti definiti nei nostri flussi di gestione delle macchine. Uno di questi punti è appena prima che il lavoro venga pianificato su una macchina. La macchina ottiene accesso a job e dati utente solo dopo il superamento della verifica di attestazione.
Il criterio di attestazione
Google utilizza un documento leggibile leggibile dal computer, denominato criterio, per descrivere l'hardware e il software che si prevede di eseguire 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 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 RTM.
- L'identità firmware che descrive la versione prevista che la RTM deve essere in esecuzione.
- Le aspettative di misurazione per ogni fase di avvio indicate dal RTM.
- Un identificatore per RTM, analogo a un nome di risorsa Redfish.
- Un identificatore che collega il RTM alla sua sede 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 un numero di serie di revoca univoco a livello globale che contribuisce a impedire il rollback di criteri non autorizzati. Il seguente diagramma mostra un criterio.
Il diagramma mostra i seguenti elementi nel criterio:
- La firma fornisce l'autenticazione dei criteri.
- Il numero di serie della revoca fornisce l'aggiornamento dei criteri per evitare il rollback.
- Le aspettative RTM elencano i dettagli di ogni RTM nella macchina.
Questi elementi descrivono in modo più dettagliato questi elementi.
Montaggio criteri
Quando viene assemblato o riparato l'hardware di una macchina, viene creato un modello di hardware che definisce tutti i RTM previsti su quella macchina. Il nostro piano di controllo assicura che queste informazioni rimangano aggiornate durante eventi come riparazioni che prevedono ricambi o upgrade dell'hardware.
Inoltre, il piano di controllo mantiene una serie di aspettative sul software previsto per l'installazione su una macchina, nonché le aspettative su quali RTM debbano misurare il 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 che descrive. Questo approccio aiuta a ridurre il numero di dipendenze di rete e di servizio necessarie allo strumento di verifica remoto durante l'attestazione di una macchina. Invece di eseguire una query su un database per il criterio, lo strumento di verifica può recuperare il criterio dalla macchina stessa. Questo approccio è una funzionalità di progettazione importante, in quanto gli scheduler di job hanno requisiti rigorosi relativi allo SLO e devono rimanere a disponibilità elevata. 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:
- Ricava il criterio di attestazione dall'assegnazione di pacchetti software e dal modello di hardware della macchina.
- Firma il criterio.
- Archivia il criterio sulla macchina del data center.
Revoca dei criteri
L'intento hardware e software di una determinata macchina cambiano 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 l'autenticazione di un criterio firmato e l'elenco appropriato di revoca del certificato per garantire che il criterio sia ancora valido.
L'esecuzione interattiva di una query su un server chiavi o su un database di revoca influisce sulla disponibilità degli scheduler di job. Google utilizza invece un modello asincrono. L'insieme di chiavi pubbliche utilizzate per autenticare i criteri di attestazione firmati viene eseguito come parte dell'immagine del sistema operativo di base di ogni macchina. Il CRL viene eseguito in modo asincrono utilizzando lo stesso sistema di deployment centralizzato di revoca utilizzato da Google per gli altri tipi di credenziali. Questo sistema è già progettato per un funzionamento affidabile in condizioni normali, con la possibilità di eseguire push rapidi di emergenza durante le condizioni di risposta agli incidenti.
Utilizzando le chiavi pubbliche di verifica e i file CRL che sono archiviati localmente sulla macchina del verificatore, i verificatori possono convalidare le dichiarazioni di attestazione dalle macchine remote senza avere servizi esterni nel percorso critico.
Recupero dei criteri di attestazione e convalida delle misurazioni
Il processo di attestazione da remoto di una macchina è costituito dalle seguenti fasi:
- Recupero e convalida del criterio di attestazione.
- Ottenere le misurazioni attestate dai RTM della macchina.
- Valutazione delle misurazioni attestate rispetto 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 firmato per la macchina. Come menzionato in Assemblaggio di 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 dello strumento di verifica pertinente. Questa azione contribuisce a garantire che il criterio recuperato sia stato firmato in modo crittografico da un'entità attendibile e che il criterio non sia stato revocato.
Ottenere misurazioni attestate
Il verificatore remoto verifica la macchina, richiedendo le misurazioni da ogni RTM. Lo strumento di verifica garantisce l'aggiornamento includendo nonce crittografiche in queste richieste. Un'entità on-machine, ad esempio un controller di gestione di battiscopa (BMC), instrada ogni richiesta al rispettivo RTM, raccoglie le risposte firmate e le invia al verificatore remoto. Questa entità on-machine non ha privilegi dal punto di vista dell'attestazione, poiché serve solo come trasporto per le misurazioni firmate RTM.
Google utilizza API interne per le attestazioni delle misurazioni. Contribuiamo anche a migliorare il pesce rosso per consentire ai verificatori fuori macchina di mettere alla prova un BMC per le misurazioni di RTM utilizzando SPDM. Il routing delle macchine interne viene eseguito su protocolli e canali specifici per l'implementazione, tra cui:
- Red sulla subnet
- Piattaforma di gestione intelligente della piattaforma (IPMI)
- Management Component Protocol (MCTP) di gestione su i2c/i3c
- PCI
- Interfaccia periferica seriale (SPI)
- USB
Valutazione delle misurazioni attestate
Lo strumento di verifica remoto di Google convalida le firme emesse da ogni RTM, assicurandosi di eseguire il reintegrazione all'identità del 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, assicurandoti 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 garantire che corrispondano alle aspettative dei criteri per il dispositivo in questione.
Reazione ai risultati di attestazione remota
Una volta completata l'attestazione, i risultati devono essere utilizzati per determinare il destino della macchina attestata. Come mostrato nel diagramma, ci sono due possibili risultati: l'attestazione è andata a buon fine e la macchina invia credenziali e attività utente oppure l'attestazione non riesce e vengono inviati avvisi all'infrastruttura di riparazione.
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 gestire i job dei clienti. Viene invece inviato un avviso all'infrastruttura di riparazione, che tenta di ricreare automaticamente la macchina. Anche se gli errori di attestazione potrebbero essere dovuti a un intent dannoso, la maggior parte degli errori di attestazione è dovuta a bug nelle implementazioni software. Di conseguenza, le implementazioni con errori di aumento dell'attestato vengono arrestati automaticamente per evitare che più macchine non superino l'attestazione. Quando si verifica questo evento, viene inviato un avviso a SRE. Per le macchine che non vengono risolte tramite il reimmaginamento automatico, viene eseguito il rollback dell'implementazione o con l'implementazione di un software fisso. Finché una macchina non esegue nuovamente l'attestazione da remoto, non viene utilizzata per gestire i job dei clienti.
Attestazione riuscita
Se l'attestazione da remoto di una macchina ha esito positivo, Google la utilizza per gestire job di produzione come VM per i clienti Google Cloud o elaborazione di immagini per Google Foto. Google richiede che tutte le azioni dei job significative che coinvolgono i servizi in rete siano protette da credenziali di attività LOAS di breve durata. Queste credenziali vengono concesse su una connessione sicura dopo una riuscita verifica dell'attestazione e forniscono i privilegi richiesti dal job. Per ulteriori informazioni su queste credenziali, consulta la sezione Application Layer Transport Security.
L'attestazione del software dipende dalla stessa infrastruttura che genera quel software. Per garantire che gli artefatti risultanti riflettano accuratamente la nostra intenzione, abbiamo investito in modo significativo nell'integrità della nostra pipeline di build. Per ulteriori informazioni su uno standard proposto da Google per verificare 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.