Der Inhalt dieses Dokuments wurde im September 2024 zum letzten Mal aktualisiert und stellt den Stand zum Zeitpunkt 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.
Die Titan-Hardwaresicherheitsarchitektur bildet die Grundlage für die Google-Dienste und unterstützt viele der Sicherheitsmaßnahmen in der Google-Infrastruktur. Titan-Hardware umfasst Sicherheitsmikrocontroller, Hardwareadapter und Auslagerungs-Prozessoren, die speziell für bestimmte Angriffsvektoren für die Google-Infrastruktur entwickelt wurden.
Titan-Hardware ist die neueste Innovation in der sich ständig weiterentwickelnden und umfassenden Infrastruktursicherheit von Google. Sie trägt zum Schutz der Integrität, Vertraulichkeit und Verfügbarkeit von Nutzerdaten bei. Die Titan-Hardware basiert auf Infrastrukturen wie kryptografischen Hardware-Offload-Karten, die die Verschlüsselung von Daten bei der Übertragung und interne Microservices für die Verschlüsselung ruhender Daten bereitstellen.
In diesem Dokument wird beschrieben, wie Titan-Hardwarekomponenten zusammenwirken, um eine Sicherheitsarchitektur zu schaffen, die dazu beiträgt, die physische Angriffsfläche von Google-Systemen zu schützen und Bedrohungen für Kundendaten zu minimieren. In diesem Dokument wird auch beschrieben, wie die Titan-Hardware bestimmte Sicherheitskontrollen auf Softwareebene ermöglicht, wie sich die Architektur über die anfängliche kryptografische Hardwareauslagerung hinaus entwickelt hat und welche realen Bedrohungen die Titan-Hardware-Sicherheitsarchitektur für die Kunden und die Bereitstellung von Google abmildern soll.
Titan-Hardwaresicherheitsarchitektur
Die Titan-Hardwaresicherheitsarchitektur von Titan wurde entwickelt, um vor einer Vielzahl von Szenarien und Bedrohungsakteuren zu schützen. Das folgende Architekturdiagramm zeigt die unabhängigen, aber ineinandergreifenden Komponenten von Titan.
Die Titan-Hardwaresicherheitsarchitektur umfasst die folgenden Komponenten:
- Caliptra Root of Trust for Measurement (RTM): Hilft, einen Sicherheitsperimeter für jedes Siliziumpaket durchzusetzen. Caliptra RTM bietet Attestierung und eine eindeutige ID für kryptografische Root-Dienste.
- Titan-Chip-RoT: Wird zwischen dem Boot-Flash einer Plattform und ihren wichtigsten Boot-Geräten wie dem Baseboard Management Controller (BMC), dem Platform Controller Hub (PCH) und der CPU platziert. Titan-Chips bieten einen physisch manipulationssicheren, hardwarebasierten RoT, der eine starke Identität schafft. Titan-Chips unterstützen auch die Autorisierung und den Widerruf von Codes für Maschinen, Karten oder Peripheriegeräte.
- Titanium-Offload-Prozessor (TOPS): Bietet kryptografische Steuerelemente zum Schutz der Vertraulichkeit und Integrität von ruhenden und übertragenen Daten.
- Benutzerdefinierte Motherboards: Bieten eine hohe Widerstandsfähigkeit gegen DoS-Angriffe durch fehlerhafte oder schädliche Software sowie Schutz vor physischen Angriffen. Im Diagramm befinden sich beispielsweise das Chippaket und die Titan RoT auf einem benutzerdefinierten Motherboard, das sich von den benutzerdefinierten Motherboards für Titan TOP oder den Motherboards für andere Infrastruktur unterscheidet.
- Enklaven für vertrauliches Computing: Hilft, die Isolation vor den administrativen Berechtigungen von Google zu erzwingen, die Isolation gegenüber anderen Mietern zu verbessern und die Überprüfbarkeit durch Attestierung zu erhöhen. Eine Attestierung kann dafür sorgen, dass die Umgebung nicht verändert wurde.
- Fehlertolerante regionale Backend-Dienste: Hilft, die Eskalierung von Berechtigungen über Dienste, Zonen oder den Administratorzugriff zu verhindern.
Im Diagramm bezieht sich Sonstige Infrastruktur auf Netzwerk-Fabrics und replizierten Backend-Speicher.
Designprinzipien der Titan-Hardwaresicherheitsarchitektur
Unsere Titan-Hardwarekomponenten und ihre Interaktionen werden nach den folgenden grundlegenden Prinzipien entwickelt:
Kein Single Point of Failure: Die Google-Architektur wurde entwickelt, um Single Point of Failures zu vermeiden, z. B. einzelne tragende Komponenten mit mehreren Aufgaben. Im Artikel Building Secure and Reliable Systems wird erläutert, wie wichtig es ist, Single Points of Failure zu vermeiden. Dieses Prinzip wird in unserer gesamten physischen Infrastruktur, in allen Regionen und sogar bis hin zum Silizium in Chips angewendet. Diese Ausfallsicherheit in unserer globalen Infrastruktur trägt dazu bei, dass Kundendaten sicher und verfügbar bleiben.
So kann beispielsweise mithilfe der Live-Migration mit Confidential Computing der verschlüsselte Arbeitsspeicher auf unterstützten Hostmaschinen erhalten bleiben. Mit der Live-Migration wird dafür gesorgt, dass eine langjährig laufende VM aufgrund von Wartungsereignissen oder als Reaktion auf Sicherheitslücken nicht zu einem Single Point of Failure wird.
Der Perimeter ist das Siliziumpaket: Da ein Serversystem mehrere miteinander verbundene und separate System-on-Chips enthält, misstrauen wir in unserer Architektur grundsätzlich allen Anschlüssen, Fabrics, Leiterplatten-Baugruppen (Printed Circuit Board Assemblies, PCBAs), Leiterplatten-Verläufen und Kabeln. Die Komponententrennung ist zwar für die Modularität nützlich, kann aber auch zu einer Schwachstelle werden, wenn Angreifern gut definierte Ziele geboten werden, von denen aus sie Klartextdaten abfangen können. Die Daten im Siliziumpaket selbst werden durch private kryptografische Assets im Paket verschlüsselt und authentifiziert.
Wenn der Perimeter in das Silizium selbst verlagert wird, lässt sich das implizite Vertrauen minimieren. Dieses Prinzip befasst sich mit Bedrohungen der Datenvertraulichkeit, die sich aus der zunehmenden Vielfalt der Rechenzentrumsbedingungen ergeben. Wenn Sie den Perimeter beispielsweise im Siliziumpaket festlegen, können Sie Bedrohungen durch schädliche Hardwarefunktionen besser abwehren.
Zero-Trust-Prinzip und Risikobegrenzung: Mehrere Parteien steuern administrative Aktionen, um dafür zu sorgen, dass kein Mitarbeiterkonto (oder manipuliertes Mitarbeiterkonto) einseitig die in diesem Artikel beschriebenen Bedrohungen auslösen kann. Die Architektur unterteilt Dienste in Schichten und Zonen, um Risiken zu begrenzen. Selbst bei Enklaven, die in der Regel hardwarebasiert sind, berücksichtigt die Architektur die Entdeckung von Hardwarelücken und die Notwendigkeit, diese zu beheben, während die Komponenten in Betrieb bleiben.
Wenn ein Angreifer beispielsweise böswillig das Verhalten eines Chips in einem aktiven System manipuliert, in dem Kundenarbeitslasten in unseren Rechenzentren ausgeführt werden, ist die Architektur so konzipiert, dass dieser manipulierte Chip identifiziert und isoliert wird. Dieser Computer kann dann außer Betrieb genommen werden. Selbst wenn der Computer nicht außer Betrieb gesetzt wird, muss der Angreifer zusätzliche Vertrauensgrenzen überwinden und mehrere Anmeldedaten manipulieren, um sich lateral zu bewegen und Einfluss auf weitere Systeme, Nutzer oder Regionen zu gewinnen.
Unabhängige Ausfalldomänen und Isolationstechnologien tragen dazu bei, den betroffenen Bereich einer Manipulation einzuschränken. Diese Domains und Technologien bieten natürliche Kontrollpunkte für die Erkennung und begrenzen die zusätzliche Komplexität, die eingeführt werden muss.
Weitere Informationen zu unserer Zero-Trust-Implementierung finden Sie unter BeyondProd.
Transparente Sicherheit: Google investiert in verschiedene Transparenzmaßnahmen, darunter Open Source, die verantwortungsvolle Offenlegung von Forschungsergebnissen und die Zusammenarbeit mit dem Hardwarehersteller-Ökosystem. Bei der globalen Infrastruktur von Google gilt das Kerckhoffs Prinzip, das besagt, dass ein Kryptosystem sicher sein sollte, auch wenn alle Informationen über das System mit Ausnahme des Schlüssels öffentlich bekannt sind.
So tragen wir beispielsweise zu Open-Source-Projekten bei und verwenden diese Projekte in unseren Sicherheitshardware-Designs und unserer Sicherheitssoftware. In der folgenden Tabelle werden einige der Open-Source-Projekte beschrieben, an denen wir mitwirken und die wir verwenden.
Open-Source-Projekt Beschreibung Titan-Komponente Wird in Verschlüsselungsbibliotheken der FIPS 140-3 Level 1 verwendet
BoringSSL
Wird in Root of Trust (RoT) auf Siliziumebene verwendet
Caliptra RTM
Wird in der RoT für einen Chip in einer Systemarchitektur verwendet
Titan-Chips
Wird für laufzeitgestütztes Kernel-Fuzzing verwendet
Host-Ring0- und Nutzer-VM-Distributionen
Wird in Verschlüsselungsbibliotheken der FIPS 140-3 Level 1 verwendet
Titanium Offload Processor (TOP)
Physische und logische Defense in Depth: Google setzt auf physische Rechenzentrumssicherheit, um unsere Kapitalinvestitionen und unsere Systeme zu schützen. Diese Sicherheitsmaßnahmen sind eine erste Verteidigungsebene. Deshalb investieren wir bewusst in zusätzliche logische Kontrollen, um unsere Systeme gegen physische Bedrohungen zu härten. Titan trägt zu unserer mehrschichtigen Verteidigung bei, indem wir unsere Hardware in mehrere Bereiche unterteilen, die zusätzlichen Schutz vor spezifischen Infrastrukturbedrohungen bieten.
So sind unsere Rechenzentren beispielsweise mit Metalldetektoren ausgestattet, die Versuche zur Ausschleusung von Speichermedien zuverlässig erkennen können. Unsere Strategie zur Verschlüsselung inaktiver Daten ist jedoch bewusst so konzipiert, dass sie nicht auf die Verwahrung physischer Medien angewiesen ist. Diese logischen und physischen Kontrollen sind unabhängige und sich ergänzende Schichten.
Durch unsere physischen und logischen Sicherheitskontrollen sind wir in der Lage, Insiderrisiken zu erkennen und die Vertraulichkeit der Daten unserer Nutzer zu schützen.
Sicherheitsvorteile von Titan-Architekturkomponenten
In der folgenden Tabelle sind einige wichtige Sicherheitsvorteile aufgeführt, die mit den Komponenten der Titan-Sicherheitsarchitektur sowohl auf Hardware- als auch auf Softwareebene erreicht werden. Diese Sicherheitsvorteile werden in den folgenden Abschnitten ausführlicher beschrieben.
| Sicherheitsvorteile | Architekturkomponente |
|---|---|
Vertrauensperimeter auf Siliziumebene auf System-on-Chips (SoCs) wie CPUs oder GPUs |
Caliptra RTM |
Verifizierbarkeit auf Chipebene |
Caliptra RTM |
Kryptografische Identität auf Hardwareebene |
Caliptra RTM, Titan RoT |
Prüfen, ob die erwarteten Binärdateien ausgeführt werden |
Caliptra RTM, Titan RoT |
Minimierung von anhaltenden Bedrohungen bei jedem Start |
Caliptra RTM, Titan RoT |
Schutz der Vertraulichkeit von ruhenden Daten und Daten in der Übertragung |
TOPs für Kryptografie |
Schutz auf Prozessorebene auslagern (über eine physische Karte hinaus) |
TOPs für Kryptografie |
Von Grund auf sicher, Widerstandsfähigkeit gegen physische Angriffe und Resilienzfunktionen, die die vollständige Firmwarewiederherstellung des Systems über einen einzelnen Titan-RoT unterstützen |
Benutzerdefinierte Motherboards |
Speziell entwickelte Boards mit nur den erforderlichen Anschlüssen, um Manipulationsversuche zu erschweren |
Benutzerdefinierte Motherboards |
Kryptografische Arbeitslastisolierung von maschinenweiter Systemsoftware und Administratorzugriff |
Confidential Computing-Enklaven |
Manipulationssicherheit durch DRAM-Verschlüsselung (um die Verschlüsselung von Daten in Verwendung zu ermöglichen) |
Confidential Computing-Enklaven |
Minimiertes betroffenes Gebiet und Schutzschild für einen Angreifer mit lokalem Zugriff |
Fehlertolerante regionale Backend-Dienste |
Mehrere Ebenen der Abschottung |
Fehlertolerante regionale Backend-Dienste |
Caliptra-Root of Trust für die Messung
Caliptra RTM trägt dazu bei, Vertrauen und Transparenz für die Firmware in unserem Ökosystem aufzubauen, die auf System-on-Chips (SoCs) wie CPUs, GPUs und TPUs ausgeführt wird.
Caliptra RTM bietet folgende Vorteile:
- Bietet einen kryptografischen Root-Dienst: Caliptra RTM hilft, beschädigten kritischen Code und eine fehlerhafte Konfiguration durch eine starke End-to-End-kryptografische Integritätsprüfung zu erkennen. Caliptra RTM kann seinen Code und seine Konfiguration kryptografisch messen, diese Messungen mit einem eindeutigen und hardwaregeschützten Attestierungsschlüssel signieren und Messungen melden, die die Authentizität und Integrität des Geräts bestätigen. Caliptra RTM bietet eine kryptografische Geräteidentität und eine Reihe von Firmware- und Konfigurationsintegritätsprüfungen für das Motherboard.
- Reduziert die physische Sicherheit der Lieferkette: Mit Caliptra RTM lässt sich dafür sorgen, dass die Hardware echt ist und die vorgesehene Firmware und Software ausführt. In Kombination mit der Sicherheit der Softwarelieferkette kann das System mit Caliptra RTM die Authentizität und Integrität von Firmware und Software prüfen, unabhängig davon, ob sie von Google oder einem Drittanbieter erstellt wurde. Durch diesen Überprüfungsprozess kann Caliptra RTM Authentizität und Integrität bei autorisierten Updates aufrechterhalten und dafür sorgen, dass Konfigurationen wie vorgesehen bleiben und attestiert werden.
- Schutz vor physischen Eingriffen, die direkten Zugriff auf laufende Hardware erfordern: Da Caliptra RTM in die Siliziumschichten des Chips integriert ist, kann ein PCBA-Interposer oder ein Rogue-Chip, der versucht, die falsche Firmware an einen anwendungsspezifischen integrierten Schaltkreis (ASIC) zu senden, den RoT nicht erfolgreich angreifen. Angreifer können beispielsweise die Erkennungsfunktionen eines externen RoT umgehen, indem sie den relativ langsamen SPI-Bus manipulieren. Ein RoT, das in einem SoC oder ASIC eingebettet ist, kann jedoch von Angreifern nur schwer manipuliert werden.
Root of Trust des Titan-Chips
Titan wurde entwickelt, um die Geräteidentität kryptografisch zu verwalten, vor schädlichen Software-Pushes zu schützen und die Codeauthentizität durch Widerruf zu erzwingen.
Eine starke kryptografische Geräteidentität trägt dazu bei, dass die Flotte ausschließlich aus validierten Maschinen besteht, auf denen die erwarteten Binärdateien ausgeführt werden und die legitimen Zugriff identifizieren und authentifizieren können. Der rechtmäßige Zugriff wird auf Hardwareebene festgelegt.
Standardmäßig wird auf Produktionsmaschinen der vertrauenswürdige Start verwendet, um dafür zu sorgen, dass nur authentifizierte Software ausgeführt werden kann. Beim vertrauenswürdigen Start wird die digitale Signatur aller Boot-Komponenten überprüft und ein Computer darf nicht an der Produktionsumgebung teilnehmen, wenn die Authentifizierung fehlschlägt.
Als zusätzliche vorbeugende Maßnahme verhindert der Widerruf von Maschinencode, dass nicht mehr autorisierte Softwareänderungen angewendet werden. Die Widerrufsfunktion in Titan-Chips hilft nicht nur, schädliche Angriffe (z. B. Rollback- oder Replay-Angriffe) abzuschwächen, sondern auch nicht schädliche Stabilitäts- oder Ausfallsicherheitsfehler (z. B. durch Verhindern der versehentlichen Neuinstallation fehlerhafter alter Firmware).
Weitere Informationen finden Sie unter So erzwingt Google die Bootintegrität auf Produktionsmaschinen.
Titanium-Offload-Prozessoren für die Kryptografie
Titanium-Offload-Prozessoren (TOPs) für die Kryptografie sorgen für Sicherheit beim Auslagern von E/A. Diese TOPs sind mit Titan oder Caliptra RTM geschützt. TOPs setzen eine weit verbreitete authentifizierte Verschlüsselung von Daten bei der Übertragung und eine authentifizierte Verschlüsselung von ruhenden Daten zu geringen Kosten ein. Bei der authentifizierten Verschlüsselung werden Kundendaten kryptografisch auf Vertraulichkeit und Integrität geprüft. Da TOPs die Kryptografie verwalten, entziehen sie vielen Systemkomponenten Berechtigungen. TOPs ermöglichen erweiterte architektonische Eigenschaften wie Verfügbarkeit und minimieren gleichzeitig das Risiko von Datenlecks.
Benutzerdefinierte Motherboards
Die benutzerdefinierten Motherboards in der Google-Infrastruktur sollen die Herkunft der Hardware nachweisen. Die Motherboards unterstützen die Attestierung auf mehreren Ebenen. Motherboard-Designs schützen Kundendaten auch im äußerst unwahrscheinlichen Fall, dass ein Angreifer ein schädliches Gerät physisch an einen Computer anschließt. Titan-Motherboard-Designs ermöglichen die zuverlässige Bereitstellung zusätzlicher Härtungsmechanismen wie nicht belegte Debug-Ports, schreibgeschützte serielle Konsolen, Bus-Anschluss-Intrusion und Extrusionssignale.
TLS und ALTS sind die einzigen akzeptierten Protokolle, die von unserem BMC-Netzwerkstack freigegeben werden, wenn ein Computer eingeschaltet ist. Bei Maschinen, die ein COTS-Design eines Drittanbieters verwenden, z. B. unsere X4-Instanzen, leiten TOPs jeglichen Verwaltungsverkehr weiter, der nur für dieses Drittanbieter-Design gilt. Durch das Proxying von Verwaltungs-Traffic ist unsere Infrastruktur nicht von Drittanbieterlösungen für Authentifizierung, Autorisierung, Transportsicherheit oder Netzwerksicherheit abhängig.
Benutzerdefinierte Titan-Motherboards sind mit integrierten Wiederherstellungs- und Sicherungsmechanismen ausgestattet, um Verfügbarkeit und Wiederherstellbarkeit zu gewährleisten. Sie können sich nach den meisten Abstürzen oder bei Beschädigung der Firmware selbst wiederherstellen. Mit unseren neuesten Designs können wir den gesamten Computer aus einem einzigen funktionierenden Titan-RoT wiederherstellen. Diese Motherboards verwenden spezielle Stromversorgungskomponenten und Reset-Signale, um die elektrische Unabhängigkeit von Titan RoTs vom Rest der Plattform zu gewährleisten und die Kontrolle über die Firmware-Nutzlast der Plattform zu schützen, um die Authentifizierung und Wiederherstellung zu ermöglichen.
Confidential Computing-Enklaven
Confidential Computing erstellt eine Trusted Execution Environment (TEE) oder Enclave, um kundensensible Arbeitslasten vom Administratorzugriff von Google zu isolieren. Wenn die Daten von der CPU oder GPU verarbeitet werden, bietet Confidential Computing eine technische vorbeugende Kontrolle durch Compute-Isolation und In-Memory-Verschlüsselung. Mit Confidential Computing wird sichergestellt, dass selbst ein böswilliger Hypervisor nicht auf eine VM zugreifen kann. Für Kundenarbeitslasten bietet Confidential Computing eine zusätzliche Schutzschicht für die Datenvertraulichkeit, die vor unbeabsichtigtem Zugriff von Google-Mitarbeitern oder fehlerhaften automatisierten System-Softwareaktionen in großem Umfang schützt.
Ein Beispiel für erweiterte Sicherheit, die durch die Titan-Architektur ermöglicht wird, ist der Vertrauliche Modus für Hyperdisk Balanced. Der vertrauliche Modus für Hyperdisk Balanced kombiniert Titan-basierte Blockspeicher-Offloads, vertrauliches Computing und Cloud-HSM, um ein hardwarebasiertes TEE zu erstellen. Mit anderen Worten: Der vertrauliche Modus für Hyperdisk Balanced ist ein Hyperdisk-ausgewogenes Angebot. Im vertraulichen Modus für Hyperdisk Balanced wird die Infrastruktur so isoliert, dass sensible Schlüssel ausschließlich in einer hardwarebasierten TEE verarbeitet werden. Informationen zur Überprüfung der kryptografischen Vorgänge durch Dritte finden Sie im öffentlichen Bericht „Confidential Mode for Hyperdisk – DEK Protection Analysis“.
Fehlertolerante regionale Backend-Dienste
Fehlertolerante regionale Backend-Dienste tragen dazu bei, das betroffene Gebiet durch einen Angreifer mit lokalem Zugriff zu minimieren. Die Google-Infrastruktur ist so konzipiert, dass Dienste, Systeme und Zonen vor lateralen Bewegungen von privilegierten Insidern oder manipulierten Diensten geschützt sind.
Wir arbeiten daran, regionale Informationen in immer mehr unserer internen Identitäts- und Zugriffsverwaltungssysteme aufzunehmen. Regionale Informationen stärken die kryptografische Isolation, sodass ein Angreifer, der lokalen Zugriff erhält, mehrere Anmeldedaten von verschiedenen Infrastrukturdiensten kompromittieren muss, um sich weiter lateral zu bewegen.
Wenn ein Angriff eine vorbeugende Kontrolle auslöst, die einen Produktionscomputer aus der Umgebung entfernt (z. B. das System ausschaltet), sorgt unsere fehlertolerante Backend-Infrastruktur dafür, dass Kundendaten und ‑dienste auf nahe gelegenen Maschinen weiterhin verfügbar sind. Weitere Informationen zu unseren Infrastrukturkontrollen finden Sie unter BeyondProd und So schützt Google seine Produktionsdienste.
Angriffsvektoren für die Google Cloud-Infrastruktur
In diesem Abschnitt werden bestimmte physische und logische Bedrohungen beschrieben, die einen Teil der Angriffsfläche von Google Cloud ausmachen. Die Hardware-Sicherheitsarchitektur von Titan wurde speziell für eine Reihe von Bedrohungen für die Google-Infrastruktur und die von uns gespeicherten Nutzerdaten entwickelt.
Bedrohungen der Infrastruktur
Die Titan-Architektur wurde entwickelt, um vor den folgenden Kategorien von Bedrohungen zu schützen:
- Betrügerischer Insider mit physischem Zugriff: Unsere Mitarbeiter benötigen Zugriff auf physische Geräte in Rechenzentren, um Hardware bereitzustellen, zu warten und zu reparieren. Dieser Zugriff stellt einen potenziellen Angriffsvektor dar, da böswillige Mitarbeiter oder Auftragnehmer einen legitimen geschäftlichen Grund haben, einige der Maschinen in unseren Rechenzentren physisch zu reparieren.
Betrügerischer Insider mit logischem Zugriff: Ähnlich wie beim physischen Zugriff auf das Rechenzentrum müssen Mitarbeiter mehrere Ebenen des Google-Softwarestacks entwickeln, verwalten, testen, debuggen, optimieren und unterstützen. Dazu gehören Entwickler, SREs und Cloud-Entwickler im Kundensupport.
Weitere Informationen zu unseren Schutzmaßnahmen gegen diese Bedrohung finden Sie unter So schützt Google seine Produktionsdienste.
Externe Angreifer mit logischem Zugriff: Externe Angreifer können in einer Google Cloud-Umgebung Fuß fassen und versuchen, sich lateral auf andere Maschinen zu übertragen, um Zugriff auf vertrauliche Daten zu erhalten. Eine gängige Taktik externer Angreifer besteht darin, zuerst ein legitimes Mitarbeiter- oder Auftragnehmerkonto zu manipulieren.
Das folgende Diagramm zeigt, welcher Teil der Cloud-Umgebung am stärksten für diese Bedrohungen anfällig ist.
Angriffsfläche für Rechenzentrumsserver
In der folgenden Tabelle werden Angriffsflächen beschrieben, die für Rechenzentrumsserver typisch sind. Die Hardware-Sicherheitsarchitektur von Titan wurde entwickelt, um einen starken Schutz vor solchen Bedrohungen zu bieten.
| Angreifer | Ziel | Angriffsfläche | Risiko |
|---|---|---|---|
Unbefugter Insider mit physischem Zugriff |
Speichermedien (SSDs, HDDs oder Bootlaufwerke) |
Physische Laufwerke und Anschlüsse |
Bei diesem Angriff kann ein Laufwerk gestohlen und mit den Tools des Angreifers versucht werden, darauf zuzugreifen. |
DIMM |
Anschlüsse für physischen Arbeitsspeicher |
Bei diesem Angriff kann der DIMM eingefroren, aus dem Rechenzentrum entfernt und mit den eigenen Tools des Angreifers auf die darauf befindlichen Daten zugegriffen werden. Diese Bedrohung wird manchmal als Cold-Boot-Angriff bezeichnet. |
|
Server |
USB- oder PCIe-Anschlüsse |
Bei diesem Angriff kann schädliche Hardware mit dem Server verbunden werden. Mit der schädlichen Hardware kann der Angreifer versuchen, Code auszuführen oder gespeicherte Daten zu exfiltrieren. |
|
Motherboard |
Joint Test Access Group (JTAG) eXtended Debug Port (XDP) |
Bei diesem Angriff kann ein Hardware-Debugging-Tool verbunden werden, um Code auszuführen oder auf Daten zuzugreifen, die auf der CPU verarbeitet werden. |
|
Netzwerk |
Ethernetkabel |
Bei diesem Angriff wird ein Ethernetkabel angezapft, um Zugriff auf alle Daten zu erhalten, die zwischen den Geräten übertragen werden. Klartext-Traffic kann dann beobachtet werden. |
|
Motherboard |
Firmware |
Dieser Angriff kann zur Installation schädlicher Firmware führen, die nicht gelöscht werden kann. Diese Firmware kann von einem manipulierten Hersteller vorinstalliert, während des Transports abgefangen oder von einem Insider aktualisiert werden. Diese Bedrohung kann zu vorinstallierter gehackter Hardware mit Rootkits führen, die einen Backdoor-Zugriff auf den Server ermöglichen. |
|
Unbefugter Insider mit logischem Zugriff |
Rechenlast (z. B. VMs) |
Anmeldepunkte |
Bei diesem Angriff können Insider-Anmeldedaten verwendet werden, um direkt auf VMs oder Hosts und die darauf befindlichen Daten zuzugreifen. |
Fabric-Router |
Physischer oder Administratorzugriff |
Bei diesem Angriff kann die Root-Kontrolle über einen Fabric-Router erlangt werden, um den gesamten Traffic abzuhören und Klartextdaten, die sich in der Fabric befinden, zu exfiltrieren oder zu manipulieren. |
|
Motherboard |
Firmware |
Bei diesem Angriff können fehlerhafte Firmware-Images auf Motherboards übertragen werden, wodurch sie dauerhaft unbrauchbar werden und die Daten nicht wiederhergestellt werden können. Ein Angreifer könnte eine Firmware mit bekannten Sicherheitslücken auf Computer übertragen, um mithilfe von Exploits, die die Remote-Codeausführung ermöglichen, die Kontrolle zurückzuerlangen. |
|
Externer Angreifer mit logischem Zugriff |
Server |
VMs |
Dieser Angriff könnte öffentliche Nebenkanalangriffsmuster auf VMs ausführen. Bei diesen Angriffen können Daten aus Instanzen, die auf derselben Hardware ausgeführt werden, oder aus der Hostsystemsoftware gehackt werden. |
SSDs |
VMs |
Bei diesem Angriff kann der direkte Zugriff auf PCIe-SSDs verwendet werden, um Daten von Mitbenutzern abzuleiten. |
|
Arbeitsspeicher |
VMs |
Bei diesem Angriffsvektor könnten Sidechannels verwendet werden, um den Arbeitsspeicher nach wertvollen Verschlüsselungsschlüsseln zu durchsuchen. |
|
Server |
Bare-Metal-VMs |
Bei diesem Angriffsvektor könnten Bare-Metal-Instanzen verwendet werden, um alle Peripheriegeräte zu scannen und eine anfällige Komponente zu finden, mit der sich der Angreifer auf dem Computer verfestigen und nachfolgende Tenants angreifen kann. |
Titan-Hardwarekomponenten Bedrohungen zuordnen
Die Hardwaresicherheitsarchitektur von Titan verwendet einen mehrschichtigen Ansatz, um bestimmte Infrastrukturbedrohungen zu beheben und Single Point of Failures zu vermeiden. Diese Bedrohungen können auf Fehler oder auf böswillige Akteure zurückzuführen sein. Die Bedrohungen umfassen Hardwarefunktionen und können Sicherheitslücken in Servern, Netzwerken und der Steuerungsebene ausnutzen. Es gibt keine einzelne Lösung, die alle diese Angriffsvektoren abdecken kann. Die kombinierten Funktionen von Titan tragen jedoch zum Schutz der Daten unserer Nutzer und unserer Cloud-Computing-Instanzen bei.
Szenario: Unbefugte Hardwarenutzung
Unbefugte Hardware-Vorgänge stellen eine Bedrohung für die Datensicherheit dar, da sie zur Exfiltration von Daten aus Rechenzentren und zur Änderung von Hardware und Firmware führen können. Die Titan-Hardware-Sicherheitsarchitektur von Google schützt vor diesen Bedrohungen mithilfe verschiedener Sicherheitsmaßnahmen, darunter kryptografische RoTs, benutzerdefinierte Motherboards und E/A-Prozessoren. Diese Komponenten sorgen gemeinsam für eine mehrschichtige Verteidigung, die gegen eine Vielzahl von Angriffen resistent ist.
In der folgenden Tabelle werden einige der Bedrohungen durch Rogue Hardware beschrieben und wie sie mit der Titan-Architektur abgeschwächt werden können.
| Bedrohung | Titan-Risikominderung |
|---|---|
Ein Angreifer schleust einzelne Datenlaufwerke aus den Rechenzentren heraus, um auf die darauf gespeicherten Daten zuzugreifen. |
Verschlüsselungsschlüssel für inaktive Daten für Speicherprodukte und ‑dienste werden niemals dauerhaft auf den Maschinen gespeichert, an die Speichermedien angeschlossen sind. Die integrierten Funktionen zur Selbstverschlüsselung von Speichermedien sind ebenfalls für die Absicherung in mehreren Schichten aktiviert und verwenden Schlüssel, die nie dauerhaft auf den Medien selbst gespeichert werden. Mit Caliptra-RTMs kann Google die Hardware-Identität des Root-of-Trust und die Firmwareintegrität in die Autorisierungsbedingungen aufnehmen, die erforderlich sind, um Schlüssel von einem Schlüsselverwaltungsdienst an Speicherdienstinstanzen freizugeben. Computer, die auf schädliche Weise mit nicht vorgesehener Firmware konfiguriert wurden, können nicht auf die Schlüssel zugreifen, die zum Entschlüsseln gespeicherter Daten erforderlich sind. Die RoTs, die in den Siliziumpaketen eingebettet sind, verankern die relevanten kryptografischen Identitäten im Chippaket. Einfunktions-Interposer sind der Hauptbestandteil unserer Datenebenensicherheit und verschlüsseln Daten in jedem Verarbeitungsschritt. TOPs bieten folgende Vorteile:
Bewährte Softwarelösungen wie dm-crypt werden für Laufwerke mit geringerer Leistung verwendet, bei denen die Verringerung der Angriffsfläche von entscheidender Bedeutung ist, z. B. bei einigen Bootlaufwerken. |
Ein Angreifer schneidet ein Netzwerkkabel an und liest die Bytes auf dem Draht oder der Glasfaser. |
TOPs verschlüsseln Daten während der Übertragung, wodurch die Möglichkeit für eine Bedrohung, wertvolle Daten im Netzwerk zu erfassen, ausgeschlossen wird. Unsere NICs verwenden den PSP-Hardware-Offload-Standard. Dieser Standard bietet eine kostengünstige Verschlüsselung mit minimalen Leistungseinbußen. Diese Implementierungen sind FIPS-konform. Kundendaten werden verschlüsselt, wenn sie über Top-of-Rack- (ToR-) oder Fabric-Switches übertragen werden. Einige Infrastrukturen für maschinelles Lernen verwenden proprietäre Transportsicherheitsmechanismen. |
Ein Angreifer ersetzt Flash-Chips mit veränderlichem Code im Rechenzentrum oder in der Lieferkette, um schädlichen Code auf den Servern auszuführen. |
Titan-Chips sind so konzipiert, dass sie den Angriff abwehren und keinen Zugriff auf die darin gespeicherten Anmeldedaten gewähren. Selbst wenn ein Angreifer den Inhalt nichtflüchtiger Flash-Chips überschreibt, meldet der Titan-RoT die Messung des Codes sicher an die Steuerungsebene von Google, die das Gerät blockieren soll. Google setzt Titan-Chips ein, um in unserer Flotte regelmäßig nicht mehr unterstützten oder bekanntermaßen anfälligen Code auf globaler Ebene zu widerrufen. |
Ein Angreifer fügt feindliche Geräte in physische Schnittstellen von Rechenzentrumsservern oder -karten ein, um schädlichen Code auszuführen oder Daten zu exfiltrieren. |
Bei benutzerdefinierten Motherboard-Designs werden die Schnittstellen entfernt, über die schädliche Geräte eingeführt werden. IOMMU-Konfigurationen (Input-Output Memory Management Unit) sind in unserer Firmware vorhanden, um PCIe-Screamer zu verhindern. (PCIe-Screamer sind für das Lesen und Schreiben beliebiger Pakete im PCIe-Fabric konzipiert.) Mit der Weiterentwicklung der Branche ergänzen wir diesen Schutz durch PCI IDE, um auch ausgefeiltere PCI-Interposer abzuwehren. ALTS und TLS sind die einzigen zulässigen Authentifizierungs- und Autorisierungsnetzwerkverbindungen für Steuer- und Verwaltungsfunktionen auf TOPs und BMCs. Caliptra-RTMs blockieren jede nicht genehmigte Firmware. Unsere vertrauenswürdigen Peripheriegeräte attestieren ihre Hardwareidentität und Codeintegrität an unsere Kontrollebene. Kein Server wird in die Produktion aufgenommen, wenn der Attestierungseintrag nicht mit der Hardware- und Softwareabsicht übereinstimmt. |
Ein Angreifer nutzt einen Cold-Boot-Angriff im Rechenzentrum, um auf Daten im RAM zuzugreifen. |
Die In-Memory-Verschlüsselung von Confidential Computing schützt alle vertraulichen Daten oder Verschlüsselungsschlüssel im RAM. Die DRAM-Verschlüsselung ist auch auf Maschinen aktiviert, die ohne Confidential Computing in Edge-Rechenzentren mit niedrigerer Sicherheit bereitgestellt werden. |
Szenario: Ausnutzung von Servern oder Netzwerken durch böswillige Nutzer
Angreifer könnten die öffentliche Cloud nutzen, um ihre schädlichen Arbeitslasten in unserer gemeinsamen Infrastruktur zu hosten und Daten in unseren öffentlichen Diensten abzulegen. Externe Angreifer, von Einzelpersonen bis hin zu Nationen, können ebenfalls versuchen, sich per Fernzugriff privilegierten Zugriff zu verschaffen.
Um diese Aktionen zu verhindern, verwendet die Titan-Hardwaresicherheitsarchitektur Titan-Chips und Caliptra RTM, um Laufzeitanmeldedaten sicher bereitzustellen und Berechtigungen für Hardware und Betriebssysteme einzuschränken. Confidential Computing schützt vor der Manipulation des Systemspeichers – physisch oder durch Hypervisor-Angriffe – und Titan-Chips lehnen nicht autorisierte Softwareupdates ab oder erkennen sie.
In der folgenden Tabelle werden einige der Bedrohungen durch Server- und Netzwerkausnutzung beschrieben und wie sie mit der Titan-Architektur abgeschwächt werden können.
| Bedrohung | Titan-Risikominderung |
|---|---|
Ein Angreifer nutzt eine Sicherheitslücke aus, um seine VM zu verlassen und Zugriff auf Daten und andere VMs zu erhalten, die auf demselben Computer ausgeführt werden. |
Confidential Computing-Enklaven verhindern die Exfiltration von Arbeitslastdaten, sowohl während der Verarbeitung als auch im inaktiven Zustand. Diese Maßnahme verhindert, dass ein Angreifer, der aus einer VM entkommen ist, auf verwendete Daten zugreift. Titan-Chips und Caliptra-RTMs verhindern, dass der Angreifer dauerhaften Zugriff erhält. Alle Versuche, dauerhaften Zugriff zu erhalten, werden wahrscheinlich erkannt, da die Computerkonfiguration nicht mit der Konfigurations- und Coderichtlinie für diesen Server übereinstimmt. Diese Übereinstimmung ist erforderlich, damit der Computer nach einem Neustart Produktionsarbeitslasten hosten kann. |
Ein Angreifer startet öffentliche Seitenkanal-Angriffsmuster auf VMs. |
Unser Flottenverwaltungssystem mit Titan-Chips kann Software mit bekannten Sicherheitslücken widerrufen. Durch den Widerruf können alle nachfolgenden Angriffe blockiert werden, die auf diese bekannten Sicherheitslücken abzielen. Titanbasierte Integritätsprüfungen bieten außerdem ein hohes Maß an Sicherheit, dass Maßnahmen, die möglicherweise dringend bereitgestellt werden müssen, auf den Zielmaschinen implementiert wurden. Wir unterstützen diesen Ansatz, indem wir mithilfe von Techniken wie Retpoline und Core Scheduling sowie fortschrittlicher Forschung zu Meltdown, Spectre, Zenbleed, Downfall und anderen Themen an der Spitze der Untersuchung und Abschwächung von Seitenkanälen bleiben. |
Ein Angreifer nutzt den direkten Zugriff auf SSDs, die mehreren Mietern Speicherplatz zur Verfügung stellen, um Daten anderer Mieter abzuleiten. |
Die Verschlüsselung inaktiver Daten trägt mit einer Vielzahl von Zwischenspeichern zum Schutz vor logischen und physischen Angriffen bei. Bei Ressourcen, die nicht freigegeben sind, werden die Daten der einzelnen Mieter mit unterschiedlichen Schlüsseln verschlüsselt. Dadurch wird das Risiko von Direktzugriffsangriffen auf das SSD verringert. |
Ein Angreifer scannt den Arbeitsspeicher und verwendet Sidechannels, um nach Datenverschlüsselungsschlüsseln oder Anmeldedaten zu suchen. |
Titan-Chips ermöglichen die Bereitstellung von per-Machine-versiegelten Anmeldedaten. Selbst wenn ein Angreifer Root-Zugriff auf einen Computer erhält, sind seine Anmeldedaten nur an die private Identität des lokalen Titan-Chips gebunden. |
Ein Angreifer kauft Bare-Metal-Instanzen und scannt alle Peripheriegeräte, um dauerhaften Zugriff zu erhalten. |
Titan-Chips lehnen alle nicht autorisierten Softwareupdates ab, einschließlich schädlicher Push-Nachrichten für eine dauerhafte Kontrolle. Unser Maschinen-Workflow bestätigt die erwarteten Integritätsprüfungen über einen vollständigen, von Bare-Metal-Kunden bestätigten System-Ein-/Aus-Zyklus. |
Szenario: Ausnutzung von Servern oder Netzwerken durch schädliches Verhalten der Steuerungsebene
Böswillige Insider der Kontrollebene können versuchen, die Systeme von Google auf verschiedene Arten zu missbrauchen, z. B. durch den Versuch, Root-Kontrolle über einen Fabric-Router zu erlangen, fehlerhafte Firmware-Images auf Motherboards zu übertragen und den Netzwerkverkehr abzufangen. Die Titan-Hardwaresicherheitsarchitektur schützt vor diesen Bedrohungen mithilfe verschiedener Mechanismen, darunter Titan-Chips, Caliptra-RTMs, benutzerdefinierte Motherboards und fehlertolerante, isolierte Back-End-Dienste.
In der folgenden Tabelle werden einige der Bedrohungen der Kontrollebene und die Möglichkeiten beschrieben, wie sie mit der Titan-Architektur abgeschwächt werden können.
| Bedrohung | Titan-Risikominderung |
|---|---|
Ein Angreifer verwendet Insider-Anmeldedaten, um auf Compute Engine-VMs zuzugreifen, die als Basisschicht für Kundenumgebungen dienen. |
TOPs sorgen dafür, dass Administratoren keinen Zugriff auf Kundenumgebungen haben. Ohne Zugriff können Google-Mitarbeiter ihre Anmeldedaten nicht verwenden, um auf die privilegierte Hardware- und Softwareebene zuzugreifen, die sich unter den VMs unserer Kunden befindet. Der Zugriff von Google-Insidern auf Kundendaten ist blockiert, da nur über definierte APIs auf Daten zugegriffen werden kann. |
Ein Angreifer sendet fehlerhafte Firmware-Images in großem Umfang an Motherboards, wodurch diese dauerhaft unbrauchbar werden. |
Die Root-of-Trust-Richtlinien von Titan-Chips lehnen alle nicht autorisierten Softwareupdates ab, einschließlich schädlicher Push-Nachrichten für eine dauerhafte Kontrolle. Benutzerdefinierte Motherboard-Designs verwenden ein alternatives Signalnetzwerk, das alle unsere RoTs mit dem RoT der Plattform verbindet. Der Plattform-RoT enthält Sicherungsfirmware für kritische Geräte. Selbst wenn das Netzwerk und die PCI-Karte von einem Angreifer beschädigt wurden, kann das Out-of-Band-Netzwerk (OOB) das System wiederherstellen. |
Ein Angreifer lädt veraltete Produktionsfirmware mit bekannten Sicherheitslücken auf Maschinen hoch, um mithilfe öffentlicher Sicherheitslücken die Kontrolle zurückzuerlangen. |
Titan-Chips lehnen fehlerhafte Pushes ab und tragen dazu bei, den Widerruf von Code mit bekannten Sicherheitslücken zu erzwingen. Sie attestieren die Firmwareversion, die auf dem Computer bereitgestellt wird, und lehnen den Computer auf der Steuerungsebene ab. Diese Maßnahme trägt dazu bei, dass keine Jobs auf einem nicht fehlerfreien Computer ausgeführt werden, und löst bei Bedarf eine Untersuchung oder Reparatur aus. |
Ein Angreifer missbraucht Funktionen zur Fehlerbehebung in Silizium, die für die Geschäftskontinuität erforderlich sind und den bestmöglichen Datenzugriff in Serversystemen bieten. |
Caliptra RTM trägt dazu bei, dass alle Parameter, die invasive Debug-Schnittstellen ermöglichen, ob logisch verbunden oder durch direkte physische Einfügung, vertrauenswürdig konfiguriert, kryptografisch gemessen und über ein Attestierungsprotokoll an unsere Steuerebene gemeldet werden. Nur Maschinen im gewünschten Status erhalten Zugriff, um Produktionsarbeitslasten zu bedienen. |
Ein Angreifer übernimmt die Kontrolle über einen Backend-Dienst, um auf Kundenumgebungen zuzugreifen. |
Fehlertolerante regionalisierte Backend-Dienste sind regionalisierte Anmeldedateninfrastrukturen, die keinen einseitigen Zugriff durch Menschen zulassen. Neben der Verhinderung der Anmeldung von Betreibern auf Compute-Knoten können sich Betreiber auch nicht mehr in der Steuerebene anmelden, um Schlüsselmaterial abzurufen. Confidential Computing-Enklaven in der Titan-Architektur isolieren unsere Backend-Autorisierungs- und Schlüsselbereitstellungsdienste von den Root-Berechtigungen des Computers. Schlüsselhierarchien tragen zum Schutz der Signatur- und Autorisierungsschlüssel der meisten Dienste bei. Bei Schlüsselhierarchien befinden sich die Stammschlüssel in Air-Gap-Schlüsseln, die in HSMs und Tresoren aufbewahrt werden, oder in Schlüsseln, die in der Produktion durch ein Paxos-Quorum von In-Memory-Datenspeichern aufbewahrt werden. |
Nächste Schritte
- Weitere Informationen finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur.
- Implementieren Sie Confidential Computing.
Autoren: Andrés Lagar-Cavilla, Erlander Lo, Jon McCune, Chris Perry