Der Inhalt dieses Dokuments wurde im Dezember 2022 zum letzten Mal aktualisiert und stellt den Stand bei der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.
In diesem Dokument wird der Google-Ansatz für die Attestierung von Rechenzentrumsmaschinen beschrieben. Die in diesem Dokument beschriebene Architektur wurde für die Einbindung in offene Standards wieTrusted Platform Module (TPM) ,Security Protocol and Data Model (SPDM) sowie Redfish entworfen. Neue Standards oder Referenzimplementierungen, die von Google vorgeschlagen und im Zusammenhang mit der Attestierung der Rechenzentrumsmaschinen erstellt wurden, finden Sie in unserem Projekt zur Plattformintegrität (PINT) in GitHub. Dieses Dokument richtet sich an Sicherheitsführungskräfte, Sicherheitsarchitekten und Prüfer.
Übersicht
Google entwirft zunehmend verteilte Rechenzentrumsmaschinen und stellt sie bereit. Anstelle eines einzigen Root of Trust enthalten viele Maschinen separate Roots of Trust, einschließlich Roots of Trust für Messungen (RTM), Speicherung, Aktualisierung und Wiederherstellung. Jeder RTM ist für einen Unterbereich der gesamten Maschine zuständig. Eine Maschine kann beispielsweise einen RTM haben, der misst und attestiert, was auf der Haupt-CPU gebootet wird, und einen weiteren RTM, der misst und attestiert, was auf einer SmartNIC gestartet wurde, die an einen PCIe-Slot angeschlossen ist. Das folgende Diagramm zeigt eine Beispielmaschine.
Die Komplexität mehrerer RTMs in einer Maschine kommt zum enormen Umfang, zu den Erwartungen an Rechenzentrumsmaschinen und zu den viele Komplikationen hinzu, die aufgrund von menschlichen, Hardware- oder Softwarefehlern auftreten können. Fazit: Die Sicherstellung der Integrität der Firmware unserer Flotte ist nicht einfach.
Das in diesem Dokument beschriebene System wurde entwickelt, um das Problem der Remote-Attestierung für verteilte Maschinen zu vereinfachen. Diese Attestierungsinfrastruktur ist erweiterbar, sodass sie an die immer komplexer werdenden Maschinen im Rechenzentrum angepasst werden kann.
Unser Ziel ist hier, unsere Perspektive bei der Durchführung der verteilten Maschinenattestierung im großen Maßstab zu vermitteln. Durch Zusammenarbeit mit Branchenpartnern und Beiträge in Gremien für Standards wie der Distributed Management Task Force (DMTF), der Trusted Computing Group (TCG) und dem Open Compute Project (OCP) möchten wir weiterhin Sicherheitsinnovationen in diesem Bereich unterstützen.
Empfohlene RTM-Eigenschaften
In diesem Abschnitt werden einige Eigenschaften vorgestellt, die wir für RTMs empfehlen.
RTM-Hardwareintegration
Wenn ein Prozessor mit einem RTM gekoppelt ist, sollte der RTM Messungen über den ersten änderbaren Code erfassen, der auf diesem Prozessor ausgeführt wird. Für den nachfolgenden änderbaren Code sollten die Messungen erfasst und an einen Root of Trust übergeben werden, bevor der Code ausgeführt wird. Dieser Ansatz erzeugt eine Measured-Boot-Kette, die eine robuste Attestierung des sicherheitsrelevanten Zustands des Prozessors ermöglicht.
Attestierung von RTM-Hardware- und -Firmware-Identität
Jeder RTM sollte ein Signaturschlüsselpaar haben, das zum Ausgeben von Attestierungen für die externe Validierung verwendet wird. Die Zertifikatskette für dieses Schlüsselpaar sollte kryptografische Beweise für die eindeutige Hardware-Identität des RTM und die Firmware-Identität für jeden änderbaren Code enthalten, der im RTM ausgeführt wird. Die Zertifikatskette sollte im RTM-Hersteller gerootet sein. Bei diesem Ansatz können Maschinen nach kritischen Sicherheitslücken in RTM-Firmware wiederhergestellt werden.
Die Spezifikation DICE (Device Identifier Composition Engine) ist eine Formalisierung des Musters, das in unserer Attestierungslösung verwendet wird. Der RTM-Hersteller zertifiziert ein eindeutiges Geräteschlüsselpaar, das ein Alias-Schlüsselpaar zertifiziert, das für die Hardware-Identität und das Firmware-Image des RTM spezifisch ist. Die Alias-Schlüsselzertifikatkette enthält eine Messung der RTM-Firmware und der Seriennummer des RTM. Verifizierer können sich sicher sein, dass alle von einem bestimmten Aliasschlüssel signierten Daten von einem RTM ausgegeben wurden, der durch die kryptografischen Hardware- und Firmware-Identitätsmessungen beschrieben wird, die in die Zertifikatskette dieses Aliasschlüssels eingebettet sind.
Remote-Attestierungsvorgänge
Das Attestierungsschema ist so konzipiert, dass Nutzerdaten und Jobs nur auf Maschinen ausgegeben werden, auf denen der vorgesehene Boot-Stack ausgeführt wird. Gleichzeitig kann die Flottenwartungsautomatisierung in großem Maßstab durchgeführt werden, um Probleme zu beheben. Der in unserer internen Cloud gehostete Jobplaner-Dienst kann die Erfassung von RTMs innerhalb der Maschine abfragen und die resultierenden attestierten Messungen mit einer Richtlinie vergleichen, die für diese Maschine eindeutig ist. Der Planer gibt Jobs und Nutzerdaten nur dann an Maschinen aus, wenn die attestierten Messungen der Richtlinie der Maschine entsprechen.
Die Remote-Attestierung umfasst die folgenden beiden Vorgänge:
Generierung der Attestierungsrichtlinie, was bei jeder Änderung der gewünschten Hardware oder Software einer Maschine erfolgt.
Attestierungsüberprüfung, was an definierten Punkten in unseren Maschinenverwaltungsabläufen erfolgt. Einer dieser Punkte wird unmittelbar vor der Planung von Arbeit auf einer Maschine durchgeführt. Die Maschine erhält erst dann Zugriff auf Jobs und Nutzerdaten, wenn die Attestierungsüberprüfung erfolgreich war.
Attestierungsrichtlinie
Google verwendet ein signiertes maschinenlesbares Dokument, das als Richtlinie bezeichnet wird, um die Hardware und Software zu beschreiben, die voraussichtlich auf einer Maschine ausgeführt wird. Diese Richtlinie kann durch die RTM-Erfassung der Maschine attestiert werden. Die folgenden Details zu jedem RTM werden in der Richtlinie dargestellt:
- Das vertrauenswürdige Identitätsstammzertifikat, das Attestierungen validieren kann, die vom RTM ausgegeben werden.
- Die global eindeutige Hardware-Identität, die den RTM eindeutig identifiziert.
- Die Firmware-Identität, die die erwartete Version beschreibt, die der RTM ausführen soll.
- Die Messungserwartungen für jede Bootphase, die vom RTM gemeldet wird.
- Eine Kennung für den RTM, analog zu einem Redfish-Ressourcennamen.
- Eine Kennung, die den RTM mit seinem physischen Standort innerhalb einer Maschine verknüpft. Diese Kennung entspricht einem Redfish-Ressourcennamen und wird von automatisierten Maschinenreparatursystemen verwendet.
Darüber hinaus enthält die Richtlinie eine global eindeutige Widerrufsseriennummer, mit der ein nicht autorisiertes Rollback der Richtlinie verhindert wird. Das folgende Diagramm zeigt eine Richtlinie.
Das Diagramm zeigt die folgenden Elemente in der Richtlinie:
- Die Signatur ermöglich die Richtlinienauthentifizierung.
- Die Widerrufsseriennummer gewährleistet die Richtlinienaktualität, um ein Rollback zu verhindern.
- Die RTM-Erwartungen enthalten Details zu jedem RTM in der Maschine.
Diese Elemente werden in den folgenden Abschnitten näher erläutert.
Richtlinienzusammenstellung
Wenn die Hardware einer Maschine zusammengestellt oder repariert wird, wird ein Hardwaremodell erstellt, das alle erwarteten RTMs auf dieser Maschine definiert. Unsere Steuerungsebene trägt dazu bei, dass diese Informationen bei allen Ereignissen, z. B. bei Reparaturen, die Teilaustausche oder Hardware-Upgrades beinhalten, auf dem neuesten Stand bleiben.
Darüber hinaus enthält die Steuerungsebene eine Reihe von Erwartungen an die Software, die auf einer Maschine installiert werden soll, sowie bestimmte Erwartungen dazu, welche RTMs welche Software messen sollen. Die Steuerungsebene verwendet diese Erwartungen zusammen mit dem Hardwaremodell, um eine signierte und widerrufbare Attestierungsrichtlinie zu generieren, die den erwarteten Zustand der Maschine beschreibt.
Die signierte Richtlinie wird dann in den nichtflüchtigen Speicher auf der beschriebenen Maschine geschrieben. Dieser Ansatz reduziert die Anzahl der Netzwerk- und Dienstabhängigkeiten, die der Remote-Verifizierer beim Attestieren einer Maschine benötigt. Anstatt eine Datenbank nach der Richtlinie abzufragen, kann der Verifizierer die Richtlinie von der Maschine selbst abrufen. Dieser Ansatz ist ein wichtiges Designfeature, da die Jobplaner strenge SLO-Anforderungen haben und hochverfügbar sein müssen. Durch die Reduzierung der Netzwerkabhängigkeiten dieser Maschinen bei anderen Diensten wird das Risiko von Ausfällen verringert. Das folgende Diagramm zeigt diesen Ereignisablauf.
Das Diagramm beschreibt die folgenden Schritte, die die Steuerungsebene bei der Richtlinienzusammenstellung ausführt:
- Leitet die Attestierungsrichtlinie aus der Zuweisung des Softwarepakets und vom Hardwaremodell der Maschine ab.
- Signiert die Richtlinie.
- Speichert die Richtlinie auf der Rechenzentrumsmaschine.
Richtlinienwiderruf
Der Hardware- und Software-Intent für eine bestimmte Maschine ändert sich mit der Zeit. Wenn sich der Intent ändert, müssen alte Richtlinien widerrufen werden. Jede signierte Attestierungsrichtlinie enthält eine eindeutige Widerrufsseriennummer. Verifizierer erhalten den entsprechenden öffentlichen Schlüssel zum Authentifizieren einer signierten Richtlinie sowie die entsprechende Zertifikatssperrliste (Certificate Revocation List, CRL), um sicherzustellen, dass die Richtlinie noch gültig ist.
Das interaktive Abfragen eines Schlüsselservers oder einer Widerrufsdatenbank wirkt sich auf die Verfügbarkeit des Jobplaners aus. Stattdessen verwendet Google ein asynchrones Modell. Die öffentlichen Schlüssel, die zur Authentifizierung von signierten Attestierungsrichtlinien verwendet werden, werden als Teil des Basisbetriebssystem-Images jeder Maschine übertragen. Die CRL wird asynchron mit demselben zentralisierten Widerrufsbereitstellungssystem übertragen, das Google auch für andere Anmeldedatentypen verwendet. Dieses System ist bereits auf den zuverlässigen Betrieb unter normalen Bedingungen ausgelegt und bietet die Möglichkeit, bei einem Vorfall schnell Notfallübertragungen durchzuführen.
Mithilfe von öffentlichen Überprüfungsschlüsseln und CRL-Dateien, die lokal auf der Maschine des Verifizierers gespeichert sind, können Verifizierer Attestierungserklärungen von Remotemaschinen validieren, ohne dass externe Dienste im kritischen Pfad vorhanden sind.
Attestierungsrichtlinien abrufen und Messungen validieren
Die Remote-Attestierung einer Maschine besteht aus den folgenden Phasen:
- Attestierungsrichtlinie abrufen und validieren
- Attestierte Messungen von den RTMs der Maschine abrufen
- Attestierten Messungen anhand der Richtlinie auswerten
Im folgenden Diagramm und in den folgenden Abschnitten werden diese Phasen weiter beschrieben.
Attestierungsrichtlinie abrufen und validieren
Der Remote-Verifizierer ruft die signierte Attestierungsrichtlinie für die Maschine ab. Wie unter Richtlinienzusammenstellung erwähnt, wird die Richtlinie aus Verfügbarkeitsgründen als signiertes Dokument auf der Zielmaschine gespeichert.
Um zu überprüfen, ob die zurückgegebene Richtlinie echt ist, prüft der Remote-Verifizierer die lokale Kopie der entsprechenden CRL. Dadurch wird sichergestellt, dass die abgerufene Richtlinie von einer vertrauenswürdigen Entität kryptografisch signiert und nicht widerrufen wurde.
Attestierte Messwerte abrufen
Der Remote-Verifizierer fragt die Maschine ab und fordert Messungen von jedem RTM an. Der Verifizierer gewährleistet Aktualität, indem er kryptografische Nonces in diese Anfragen aufnimmt. Eine Entität auf der Maschine, z. B. ein Baseboard-Verwaltungscontroller (BMC), leitet jede Anfrage an den entsprechenden RTM weiter, sammelt die signierten Antworten und sendet sie an den Remote-Verifizierer zurück. Diese maschineninterne Entität ist aus Sicht der Attestierung nicht privilegiert, da sie nur für den Transport der signierten Messungen des RTM dient.
Google verwendet interne APIs für die Attestierung von Messungen. Außerdem bieten wir Verbesserungen für Redfish an, damit Verifizierer außerhalb von Maschinen mithilfe von SPDM einen BMC nach den Messungen eines RTM abfragen können. Das interne Maschinenrouting erfolgt über implementierungsspezifische Protokolle und Kanäle, einschließlich:
- Redfish über Subnetz
- Intelligent Platform Management Interface (IPMI)
- Management Component Transport Protocol (MCTP) über i2c/i3c
- PCIe
- Serial Peripheral Interface (SPI)
- USB
Attestierte Messungen auswerten
Der Remote-Verifizierer von Google validiert die Signaturen, die von jedem RTM ausgegeben werden. So wird sichergestellt, dass sie auf die Identität des RTMs zurückgeführt werden, die in der Attestierungsrichtlinie der Maschine enthalten ist. Alle Hardware- und Firmware-Identitäten, die in der Zertifikatskette des RTM vorhanden sind, werden anhand der Richtlinie validiert, um sicherzustellen, dass jeder RTM die richtige Instanz ist und die richtige Firmware ausführt. Um die Aktualität zu gewährleisten, wird die signierte kryptografische Nonce geprüft. Abschließend werden die attestierten Messungen ausgewertet, um sicherzustellen, dass sie den Erwartungen der Richtlinie für dieses Gerät entsprechen.
Auf Remote-Attestierungsergebnisse reagieren
Nach Abschluss der Attestierung müssen die Ergebnisse verwendet werden, um das Schicksal der attestierten Maschine zu ermitteln. Wie im Diagramm dargestellt, gibt es zwei mögliche Ergebnisse: Die Attestierung ist erfolgreich und die Maschine erhält Aufgabenanmeldedaten und Nutzerdaten oder die Attestierung schlägt fehl und Benachrichtigungen werden an die Reparaturinfrastruktur gesendet.
In den folgenden Abschnitten finden Sie weitere Informationen zu diesen Prozessen.
Fehlgeschlagene Attestierung
Wenn die Attestierung einer Maschine nicht erfolgreich ist, verwendet Google die Maschine nicht zum Bereitstellen von Kundenjobs. Stattdessen wird eine Benachrichtigung an die Reparaturinfrastruktur gesendet, die dann versucht, das Image automatisch neu aufzuspielen. Obwohl Attestierungsfehler auf böswillige Absichten zurückzuführen sein können, sind die meisten Attestierungsfehler auf Programmfehler in Software-Roll-outs zurückzuführen. Daher werden Roll-outs mit zunehmenden Attestierungsfehlern automatisch gestoppt, um zu verhindern, dass weitere Maschinen die Attestierung nicht bestehen. In diesem Fall wird eine Benachrichtigung an SREs gesendet. Bei Maschinen, die nicht durch automatisches Neuaufspielen des Images korrigiert wurden, wird ein Rollback des Roll-outs durchgeführt oder es wird eine korrigierte Software installiert. Eine Maschine wird erst dann für Kundenjobs verwendet, wenn sie die Remote-Attestierung bestanden hat.
Erfolgreiche Attestierung
Wenn die Remote-Attestierung einer Maschine erfolgreich ist, verwendet Google die Maschine, um Produktionsjobs wie VMs für Google Cloud-Kunden oder die Bildverarbeitung für Google Fotos bereitzustellen. Google verlangt, dass alle wichtigen Jobaktionen, die vernetzte Dienste umfassen, durch kurzlebige LOAS-Aufgabenanmeldedaten geschützt sind. Diese Anmeldedaten werden nach einer erfolgreichen Attestierungsabfrage über eine sichere Verbindung gewährt und bieten die für den Job erforderlichen Berechtigungen. Weitere Informationen zu diesen Anmeldedaten finden Sie unter Application Layer Transport Security.
Die Software-Attestierung ist nur so gut wie die Infrastruktur, die diese Software erstellt. Um sicherzustellen, dass die resultierenden Artefakte unsere Absichten genau widerspiegeln, haben wir erheblich in die Integrität unserer Build-Pipeline investiert. Weitere Informationen zu einem Standard, den Google vorgeschlagen hat, um die Integrität und Authentizität von Softwarelieferketten zu gewährleisten, finden Sie unter Integrität der Softwarelieferkette.
Nächste Schritte
Erfahren Sie, wie BeyondProd die Rechenzentren von Google dabei unterstützt, sichere Verbindungen herzustellen.