Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo. al momento in cui è stata scritta. Le norme e i sistemi di sicurezza di Google potrebbero cambiare 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 come gli standard aperti, Trusted Platform Module (TPM), Protocollo di sicurezza e modello dei dati (SPDM), e Scorfano. Per i nuovi standard o le implementazioni di riferimento proposti da Google e relative all'attestazione delle macchine dei data center, consulta le Integrità della piattaforma (PINT) progetto in GitHub. Questo documento è rivolto ai responsabili della sicurezza, architetti 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, le radici di attendibilità per la misurazione (RTM), l'archiviazione, l'aggiornamento e il ripristino. Ogni RTM e offre una sottosezione dell'intera macchina. Ad esempio, una macchina potrebbe avere uno RTM, che misura e attesta ciò che è stato avviato sulla CPU principale RTM che misura e attesta ciò che è stato avviato su uno SmartNIC collegato a un Slot PCIe. Il seguente diagramma mostra una macchina di esempio.
La complessità di più RTM in una macchina si aggiunge all'enorme scala e le aspettative delle macchine dei data center e molte complicazioni che a causa di guasti umani, hardware o software. In sintesi, garantire l'integrità del firmware del nostro parco dispositivi è uno sforzo non banale.
Il sistema descritto in questo documento è stato progettato per risolvere il problema del più gestibile dell'attestazione per macchine disaggregate. Questa attestazione infrastruttura è estensibile, consentendole di adattarsi così come appaiono nel data center.
Condividendo questo lavoro, intendiamo fornire il nostro punto di vista su come l'attestazione può essere eseguita su larga scala. Tramite la collaborazione con il settore partner e contributi agli organismi di standardizzazione, come la gestione distribuita Task Force (DMTF), Trusted Computing Group (TCG) e Open Compute Project (OCP), intendiamo continuare a supportare l'innovazione della sicurezza in quest'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 sul primo codice modificabile in esecuzione su quel processore. Codice modificabile successivo devono acquisire le misurazioni e riportarle a una radice di attendibilità prima che il codice viene eseguito. Questa disposizione produce una catena di avvio misurata che consente una robusta 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 una convalida esterna. La catena di certificati per questa coppia di chiavi deve includere prova crittografica dell'identità hardware univoca del RTM e del firmware Identity per qualsiasi codice modificabile all'interno dell'RTM. La catena di certificati deve essere radicato nel produttore RTM. Questo approccio consente alle macchine dalle vulnerabilità critiche del firmware RTM.
La Motore di composizione dell'identificatore dispositivo (DICE) è una formalizzazione del pattern utilizzato nella nostra attestazione soluzione. Il produttore RTM certifica una coppia di chiavi univoca del dispositivo, che certifica una coppia di chiavi alias specifica per l'identità hardware di RTM e l'immagine del firmware. La catena di certificati delle chiavi alias contiene una misurazione del Firmware RTM e numero di serie dell'RTM. I verificatori possono avere la certezza che qualsiasi i dati firmati da una determinata chiave alias sono stati emessi da un RTM descritto da le misure dell'hardware crittografico e dell'identità del firmware che sono 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 e i job dell'utente vengano inviati alle macchine che eseguono lo stack di avvio previsto, ma consentendo l'automazione della manutenzione del parco risorse su larga scala per risolvere i problemi. La del job scheduler, ospitato nel nostro cloud interno, può di RTM all'interno della macchina e confrontare il risultato attestato di misurazione in base a un criterio univoco per quella macchina. Solo scheduler emette i job e i dati utente alle macchine se le misure attestate sono conformi il criterio 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 viene modificato.
Verifica dell'attestazione, che viene eseguita in punti definiti nel nostro computer e la gestione dei flussi di lavoro. Uno di questi punti è appena prima della programmazione del lavoro su un in una macchina virtuale. La macchina ottiene l'accesso ai job e ai dati utente solo dopo della verifica dell'attestazione ha avuto esito positivo.
Il criterio di attestazione
Google utilizza un documento firmato leggibile da computer, denominato policy, per descrivere l'hardware e il software che dovrebbe essere in esecuzione all'interno di un in una macchina virtuale. Questo criterio può essere attestato dalla raccolta di RTM della macchina. La i seguenti dettagli per ogni RTM sono rappresentati nelle norme:
- Il certificato radice dell'identità attendibile che può essere convalidato emesse dall'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 RTM deve essere in esecuzione.
- Le previsioni relative alla misurazione per ogni fase di avvio riportata da l'RTM.
- Un identificatore per l'RTM, analogo a un Nome risorsa scorfano.
- Un identificatore che collega il sistema RTM alla sua posizione fisica all'interno di un in una macchina virtuale. Questo identificatore è analogo a un Risorsa scorfano e viene utilizzato dai sistemi automatizzati di riparazione dei macchinari.
Inoltre, i criteri contengono anche un numero seriale di revoca univoco a livello globale che consente di impedire il rollback dei criteri non autorizzato. 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 delle norme per aiutare a evitare e 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 gli RTM previsti su quella macchina. Il nostro piano di controllo aiuta a garantire che queste informazioni rimangano aggiornate durante eventi come le riparazioni che comportano scambio di componenti o upgrade dell'hardware.
Inoltre, il piano di controllo mantiene una serie di aspettative software pensato per essere installato su una macchina, oltre alle su quali RTM dovrebbero misurare quale software. Il piano di controllo utilizza questi le aspettative, insieme al modello hardware, di generare un modello di attribuzione criterio di attestazione che descrive lo stato previsto della macchina.
Il criterio firmato viene quindi scritto nello spazio di archiviazione permanente sulla macchina in cui che descrive il problema. Questo approccio consente di ridurre il numero necessarie allo strumento di verifica remoto per 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 è una caratteristica importante della progettazione, gli scheduler dei job hanno requisiti rigorosi per gli SLO e devono rimanere ad alta disponibilità. Ridurre le dipendenze di rete di queste macchine su altri servizi aiuta e ridurre il rischio di interruzioni del servizio. Il seguente diagramma mostra questo flusso di eventi.
Il diagramma descrive i seguenti passaggi in cui il piano di controllo esegue il processo di assemblaggio dei criteri:
- Deriva il criterio di attestazione dall'assegnazione del pacchetto software e modello di 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 modifiche di intent, i vecchi criteri devono essere revocati. Ogni criterio di attestazione firmato includa un numero di serie univoco di revoca. I verificatori ottengono i dati appropriati chiave pubblica per l'autenticazione di un criterio firmato e il certificato appropriato dell'elenco revoche per garantire che il criterio sia ancora valido.
L'esecuzione interattiva di query su un server delle chiavi o un database di revoca influisce sul job scheduler la disponibilità del servizio. Google utilizza invece un modello asincrono. L'insieme Viene eseguito il push di chiavi pubbliche utilizzate per autenticare i criteri di attestazione firmata come parte dell'immagine del sistema operativo di base di ogni macchina. Il CRL è stato inviato utilizzando lo stesso sistema centralizzato di deployment delle revoche Google utilizza per altri tipi di credenziali. Questo sistema è già stato progettato un funzionamento affidabile in condizioni normali, con la capacità di eseguire rapide spinte di emergenza durante le condizioni di risposta agli incidenti.
Utilizzando le chiavi pubbliche di verifica e i file CRL memorizzati localmente sul macchina della verifica, questi ultimi possono convalidare le dichiarazioni di attestazione senza la presenza di 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 in Assemblaggio di criteri, per motivi di disponibilità, il criterio viene archiviato come documento firmato nella macchina di destinazione.
Per verificare l'autenticità delle norme restituite, il verificatore remoto consulta la copia locale del responsabile della verifica dell'elenco revoche certificati pertinente. Questa azione aiuta a garantire che il criterio recuperato è stato firmato tramite crittografia da un'entità attendibile e che il non è 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 i nonce crittografici in questi richieste. Un'entità sulla macchina, ad esempio un controller di gestione battiscopa (BMC), instrada ciascuna richiesta al rispettivo RTM, raccoglie le risposte firmate e le rimanda allo strumento di verifica remoto. Questa entità sul computer è senza privilegi dal punto di vista dell'attestazione, in quanto funge solo da trasporto per il controllo misure firmate.
Google utilizza API interne per attestare le misurazioni. Contribuiamo anche miglioramenti a Redfish per consentire agli strumenti di verifica fuori macchina di sfidare un BMC per le misurazioni di un RTM utilizzando SPDM. Il routing della macchina interna 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 di far risalire all'identità di RTM inclusa nei criterio di attestazione della macchina. Le identità hardware e firmware presenti nella catena di certificati di RTM vengono convalidate in base alle norme, verificando che ogni RTM sia l'istanza corretta e che esegua il firmware corretto. A assicura l'aggiornamento, viene controllato il nonce crittografico firmato. Infine, lo strumento Le misurazioni vengono valutate per garantire che corrispondano le aspettative per quel dispositivo.
Reazione ai risultati dell'attestazione remota
Una volta completata l'attestazione, i risultati devono essere usati per determinare il destino della macchina che viene attestata. Come illustrato nel diagramma, sono possibili due risultati: l'attestazione ha esito positivo e la macchina viene inviata le credenziali e i dati utente oppure l'attestazione ha esito negativo e vengono inviati avvisi in modo da riparare l'infrastruttura.
Le sezioni seguenti forniscono ulteriori informazioni su questi processi.
Attestazione non riuscita
Se l'attestazione di una macchina non ha esito positivo, Google non la utilizza per per le posizioni dei clienti. ma viene inviato un avviso all'infrastruttura di riparazione, che tenta di ricreare automaticamente l'immagine della macchina. Sebbene errori di attestazione potrebbero essere dovuti a un intento dannoso, la maggior parte degli errori di attestazione è dovuta a di bug nelle implementazioni del software. Di conseguenza, le implementazioni con gli errori di attestazione vengono arrestati automaticamente per prevenire di macchine in caso di errori di 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. Finché una macchina non subisce di nuovo l'attestazione remota, non viene utilizzata per gestire i job del cliente.
Attestazione riuscita
Se l'attestazione remota di una macchina ha esito positivo, Google utilizza la macchina per gestire job di produzione come VM per i clienti Google Cloud o elaborazione di immagini per Google Foto. Google richiede azioni significative che prevede l'accesso a servizi in rete sostenuti da servizi di breve durata LOAS e credenziali dell'attività. Queste credenziali vengono concesse tramite una connessione sicura dopo che verifica dell'attestazione riuscita e fornisci i privilegi richiesti dal job. Per ulteriori informazioni su queste credenziali, vedi Application Layer Transport Security.
L'attestazione del software è valida solo quanto l'infrastruttura che lo crea software. Per garantire che gli artefatti risultanti corrispondano in modo accurato nostro intento, abbiamo investito in modo significativo nell'integrità della nostra build una pipeline o un blocco note personalizzato. Per ulteriori informazioni su uno standard proposto da Google per l'integrità e l'autenticità della catena di fornitura del software, vedi Integrità della catena di fornitura del software.
Passaggi successivi
Scopri come fare BeyondProd aiuta i computer dei data center di Google a stabilire connessioni sicure.