Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo al momento della loro redazione. 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 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 ai responsabili della sicurezza, architetti e revisori.
Panoramica
Sempre più spesso, Google progetta e implementa macchine di data center disaggregate. 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 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 un slot PCIe. Il seguente diagramma mostra una macchina di esempio.
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 del nostro parco dispositivi è uno sforzo non banale.
Il sistema descritto in questo documento è progettato per semplificare il problema dell'attestazione da remoto per le macchine disaggregate. Questa attestazione è estensibile, in modo che si adatti al servizio 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. 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 introduce alcune proprietà che consigliamo per i sistemi RTM.
Integrazione hardware RTM
Quando un processore è accoppiato a un RTM, quest'ultimo deve acquisire le misurazioni sul primo codice mutabile eseguito sul processore. Codice modificabile successivo deve acquisire le sue misurazioni e riportarle a una radice di attendibilità prima che il codice viene eseguito. Questa disposizione produce una catena di avvio misurata che consente un'attestazione solida 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 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 Motore di composizione dell'identificatore dispositivo (DICE) è una formalizzazione del pattern utilizzato nella nostra attestazione soluzione. 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 avere la certezza che qualsiasi i dati firmati da una determinata chiave alias sono stati emessi da un RTM descritto le misurazioni dell'identità del firmware e dell'hardware crittografico incorporati 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 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. 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 job e 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 avviene in punti definiti dei nostri flussi di gestione delle macchine. 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 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 attestato dalla raccolta di RTM della macchina. La i seguenti dettagli per ogni RTM sono rappresentati nelle norme:
- Il certificato radice di identità attendibile che può convalidare le attestazioni emesse dall'RTM.
- L'identità hardware univoca a livello globale che identifica in modo univoco il sistema RTM.
- L'identità firmware che descrive la versione prevista RTM deve essere in esecuzione.
- Le aspettative di misurazione per ogni fase di avvio registrate dall'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 al nome di una risorsa Redfish e viene utilizzato dai sistemi di riparazione automatica delle macchine.
Inoltre, i criteri contengono anche un numero seriale di revoca univoco a livello globale che contribuisce a 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 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 di criteri
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 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 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 quindi scritto nello spazio di archiviazione permanente sulla macchina in cui che descrive il problema. 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 è 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 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 modifiche di intent, 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 verificare 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 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à 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
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à 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. 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 della macchina interna avviene tramite protocolli e canali specifici dell'implementazione, tra cui:
- Redfish sulla subnet
- Intelligent Platform Management Interface (IPMI)
- Management Component Transport Protocol (MCTP) 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 ciascun RTM, assicurandosi di far risalire all'identità di RTM inclusa nei il 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. 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
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 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 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 implementato il 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 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 che verifica dell'attestazione riuscita e fornisci 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 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.