So schützt Google seine Produktionsdienste

Der Inhalt dieses Dokuments wurde im Juni 2026 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.

Google betreibt eine globale, mandantenfähige und verteilte Computing-Infrastruktur, um Milliarden von Menschen auf der ganzen Welt Produkte und Dienste zur Verfügung zu stellen. Bei dieser Infrastruktur müssen die konkurrierenden Prioritäten von Sicherheit, Zuverlässigkeit, Stabilität, Effizienz, Entwicklungsgeschwindigkeit, Debugging-Fähigkeit und mehr berücksichtigt werden.

In diesem Dokument werden einige der Mechanismen beschrieben, die wir verwenden, um ein branchenführendes Sicherheitsniveau für Dienste aufrechtzuerhalten, die in der Produktionsumgebung von Google ausgeführt werden. Diese Dienste decken das gesamte Spektrum der Sicherheitsempfindlichkeit ab, von Entwicklungsexperimenten, die keinen Zugriff auf vertrauliche Daten haben, bis hin zu kritischer Identitätsinfrastruktur. Diese Dienste übernehmen Aufgaben wie die Verarbeitung von Nutzerdaten, die Verwaltung von Software-Rollouts sowie die Bereitstellung und Verwaltung des Lebenszyklus einzelner physischer Maschinen.

In diesem Dokument werden die Sicherheitskontrollen beschrieben, die zum Schutz der folgenden drei wichtigen Ebenen unserer Infrastruktur beitragen:

• Produktionsdienste, zu denen die sicherheitskritischsten Dienste gehören (auch als fundamentale Dienste bezeichnet)
• Produktionsmaschinen
• Produktionsarbeitslasten

Wir wenden diese Kontrollen an, damit Google-Mitarbeiter nur für legitime geschäftliche Zwecke (z. B. Wartungszugriff) auf Dienste, Maschinen und Arbeitslasten zugreifen können und um Insider-Risiken und Kompromittierungen von Mitarbeiterkonten zu verhindern. Diese Kontrollen bieten zusätzlichen Schutz, der die vorhandenen Sicherheitskontrollen für die Infrastruktur ergänzt und dazu beiträgt, dass Konten nicht gehackt werden.

Kontinuierliche Verbesserungen

Die in diesem Dokument beschriebenen Kontrollen werden in der gesamten Produktionsumgebung von Google verwendet. Viele Dienste, einschließlich grundlegender Dienste, nutzen die neuesten von uns angebotenen Kontrollfunktionen. Aufgrund des Umfangs und der Komplexität der Infrastruktur von Google haben einzelne Produktionsdienste jedoch oft spezielle Anforderungen und es kann zusätzliche Zeit erforderlich sein, um die neuesten Empfehlungen zu implementieren. Durch eine Kultur der kontinuierlichen Verbesserung passen die Site Reliability Engineering (SRE)- und Sicherheitsteams von Google die Sicherheitskontrollen ständig an die sich ändernde Bedrohungslandschaft an.

Produktionsdienste schützen

Google trägt zum Schutz der Integrität von Produktionsdiensten bei, sodass Google-Mitarbeiter nur für einen legitimen geschäftlichen Zweck, z. B. zur Wartung, auf die Dienste zugreifen können. Es gibt zwei primäre Möglichkeiten, Zugriff auf Dienste zu erhalten, die in der Produktionsumgebung ausgeführt werden: über den Administratorzugriff und über die Software-Lieferkette.

In der folgenden Liste werden die Kontrollen beschrieben, die zum Schutz der einzelnen Zugriffspfade beitragen.

• Administrative Zugriffssteuerung: Produktionsdienste müssen regelmäßig gewartet werden, z. B. durch Binär- oder Konfigurationsrollouts. Bei Google ist es unser Ziel, dass solche Vorgänge gemäß der Philosophie Zero Touch Prod durch Automatisierung, sichere Proxys oder geprüften Notfallzugriff erfolgen. Die Reihe von Kontrollen, die den menschlichen Zugriff auf Produktionsressourcen entfernen, wird als No Persons (NoPe) bezeichnet. NoPe gibt Google die Flexibilität, Zugriffssteuerungen bereitzustellen, die auf der Sensibilität eines Produktionsdienstes und seiner Bereitschaft basieren, durch kontinuierliche Verbesserung eine noch stärkere Sicherheitslage zu erreichen.

  Google erlaubt beispielsweise keinen einseitigen Zugriff auf grundlegende Dienste. Selbst für den Notfallzugriff ist die Genehmigung durch andere Google-Mitarbeiter erforderlich. Ein Zugriff ist einseitig, wenn er ohne Genehmigung einer anderen autorisierten Person erfolgen kann. Als weiteres Beispiel deaktivieren wir Core-Dumps, um den Verlust wichtiger Geheimnisse wie Root-Zugriffsschlüssel zu verhindern, auch wenn dies das Debugging erschwert.

• Kontrollen der Softwarelieferkette: Die meisten Produktionsarbeitslasten bei Google, einschließlich grundlegender Dienste, führen Binärdateien und Jobkonfigurationen aus, die nachweislich aus von Experten geprüften Code erstellt werden, der sich in einer vertrauenswürdigen Quelle befindet. Wir erzwingen diesen Prozess mit der Binärautorisierung für Borg (BAB).

Das folgende Diagramm zeigt die Kontrollen, die zum Schutz eines Produktionsdienstes beitragen.

Wenn wir die höchsten NoPe- und BAB-Stufen anwenden, tragen wir dazu bei, dass kein Personal – auch nicht in Notfällen – einseitigen Zugriff auf grundlegende Dienste hat und dass jeder gewährte privilegierte Zugriff einen klar definierten Umfang und eine klare Dauer hat. Der privilegierte Zugriff ist eine höhere Zugriffsebene, die Mitarbeitern gewährt wird, um kritische Produktionsdienste unter besonderen Umständen zu verwalten, die nicht durch die Automatisierung abgedeckt werden. Wir machen eine Ausnahme von dieser Regel, damit Google aus Sperrsituationen herauskommt.

Die meisten Produktionsdienste, einschließlich Produkte wie Filestore oder Cloud SQL und interne Infrastrukturprodukte wie Borg und Spanner, sind so konfiguriert, dass sie die höchsten NoPe- und BAB-Stufen verwenden. Wir arbeiten kontinuierlich daran, die Einführung von NoPe und BAB für Produktionsdienstinhaber im Laufe der Zeit zu vereinfachen. Im Risikoregister sind verwaltete Ausnahmen mit gültigen betrieblichen Begründungen vorhanden.

Administratorzugriffssteuerung

In Borg können Mitglieder einer Produktionsrolle die Daten, die der Produktionsrolle gehören, lesen, schreiben oder löschen und Code mit der Berechtigung der Rolle ausführen. Eine Produktionsrolle ist eine Identität, mit der Arbeitslasten in der Produktionsumgebung von Google ausgeführt werden können.

Die dauerhafte Mitgliedschaft in Produktionsrollen birgt das Risiko unbeabsichtigter Folgen für die Produktion und das Risiko, dass diese Berechtigungen missbraucht werden. Die Mission von SRE erfordert jedoch, dass Teams in die Lage versetzt werden, die Dienste zu verwalten, für die sie verantwortlich sind. Daher ist ein vollständiger Zugriffsentzug möglicherweise keine praktikable Strategie.

Die NoPe-Suite bietet eine Möglichkeit, den Zugriff so zu konfigurieren, dass die konkurrierenden Anforderungen, Teams zu unterstützen und Produktionssysteme zu schützen, in Einklang gebracht werden. Mit NoPe unterliegen Google-Mitarbeiter Einschränkungen hinsichtlich der Berechtigungen ihrer Konten, wenn sie versuchen, auf Produktionsdienste zuzugreifen. NoPe ermöglicht die folgenden Einschränkungen:

• Für Zugriffsanfragen sind ein Genehmiger und eine Begründung erforderlich: Eine Kontrolle, die als Autorisierung durch mehrere Parteien (Multi-Party Authorization, MPA) bezeichnet wird, trägt dazu bei, dass Google-Mitarbeiter nicht ohne geschäftliche Begründung und Genehmigung durch eine andere Person, die zur Überprüfung der Zugriffsanfrage berechtigt ist, auf Produktionsdienste zugreifen können.
• Kein direkter Zugriff auf Produktionsdienstrollen: Mitarbeiter können nur über sichere Proxys für NoPe auf Produktionsdienste zugreifen. Sichere Proxys sind so konzipiert, dass nur eine genau definierte Reihe von Befehlen ausgeführt werden kann. Für alle Befehle, die von Google Security und SRE als riskant eingestuft werden (z. B. das Herunterfahren eines Dienstes oder der Zugriff auf oder das Löschen von Daten), ist ebenfalls eine MPA erforderlich.
• Keine dauerhafte Produktionsrollenmitgliedschaft: Bei einer Steuerung namens Access on Demand (AoD) müssen Mitarbeiter eine vorübergehende Mitgliedschaft beantragen, anstatt dass Mitarbeiterkonten immer Zugriffsberechtigungen haben. Mit dieser Einstellung wird dafür gesorgt, dass erweiterte Berechtigungen nur vorübergehend und aus bestimmten Gründen gewährt werden.
• Monitoring von Personalanfragen für den Zugriff auf Produktionsdienste: Google verlangt eine regelmäßige Überprüfung der Zugriffsmuster für Produktionsrollen, die einen Produktionsdienst ausführen. Ziel der Prüfung ist es, solche Anfragen durch kontinuierliche Verbesserung der Verwaltungs-APIs in Zukunft zu vermeiden. Der Zugriff auf Produktionsdienste sollte nur für Notfallsituationen reserviert sein. Bei grundlegenden Diensten ist die Anzahl der Situationen, in denen Zugriff gewährt wird, so gering, dass ein Sicherheitsteam jeden gewährten Zugriff prüft, um seine Gültigkeit zu bestätigen.

In den folgenden Abschnitten werden die einzelnen Kontrollfunktionen im Detail beschrieben.

Autorisierung durch mehrere Parteien für NoPe

Für MPA ist die Genehmigung einer Zugriffsanfrage durch anderes autorisiertes Google-Personal erforderlich.

Für Anfragen zum Zugriff auf ausreichend sensible Dienste ist gemäß MPA außerdem erforderlich, dass das Personal mit jeder Anfrage eine geschäftliche Begründung angibt, die sich auf einen laufenden Produktionsnotfall bezieht.

Beide Bedingungen sollen den Missbrauch des Zugriffs verhindern.

Sichere Proxys für NoPe

Sichere Proxys sind Tools, die eine vordefinierte Reihe von Befehlen bereitstellen, die ders sichere Proxy im Namen eines Aufrufers ausführen kann. Sichere Proxies implementieren detaillierte, regelbasierte Autorisierungsrichtlinien, um den Zugriff auf Produktionsdienste einzuschränken. Diese Richtlinien können beispielsweise die Genehmigung durch eine andere autorisierte Person erfordern, um Befehle auszuführen, die sich negativ auf die Sicherheit oder Zuverlässigkeit auswirken könnten (z. B. Befehle zum Löschen von Dateien). Richtlinien können auch dafür sorgen, dass bestimmte sichere Befehle (z. B. Befehle, die die Ressourcennutzung auflisten) ohne Genehmigung ausgeführt werden. Diese Flexibilität ist entscheidend, um den operativen Aufwand zu minimieren.

Bei Missbrauch des Zugriffs sind Konten weiterhin auf die Vorgänge beschränkt, die der sichere Proxy zulässt. Über das Konto können nur sichere Befehle einseitig ausgeführt werden. Für privilegierte Vorgänge ist die Genehmigung durch eine andere autorisierte Person erforderlich. Alle Vorgänge hinterlassen einen klaren Audit-Trail.

Weitere Informationen zu sicheren Proxys finden Sie in der SREcon-Präsentation zu Zero Touch Prod und in der Fallstudie zu sicheren Proxys. „Zero Touch Prod“ ist eine Reihe von Prinzipien und Tools, die dafür sorgen, dass jede Änderung in der Produktion automatisiert erfolgt (keine Beteiligung von Personen), von Software vorab validiert wird oder über einen geprüften Notfallmechanismus erfolgt.

On-Demand-Zugriff

Mit dem On-Demand-Zugriff (AoD) kann Google die Berechtigungen von Mitarbeitern einschränken, indem eine dauerhafte Mitgliedschaft durch eine nutzungsabhängige Mitgliedschaft ersetzt wird.

Berechtigte Mitglieder einer Rolle haben keinen Zugriff auf die zugehörigen Berechtigungen. Wenn ein Mitglied einer berechtigten Rolle Zugriff benötigt, kann es stattdessen eine vorübergehende Mitgliedschaft beantragen, die als AoD-Zustimmung bezeichnet wird. Wenn ein AoD-Antrag von einer anderen autorisierten Person genehmigt wird, wird der Antragsteller für einen begrenzten Zeitraum, in der Regel weniger als einen Tag, Mitglied der Rolle.

Mit dem berechtigten Mitgliedschaftsmodell können Mitarbeiter nur die Teilmenge des Zugriffs anfordern, die sie für den benötigten Zeitraum benötigen. Konzeptionell können Sie sich AoD als zeitgebundene Produktions-sudo vorstellen, ähnlich dem Befehl sudo -u in Unix, mit dem Sie einige Befehle mit den erhöhten Berechtigungen ausführen können, die einem bestimmten Nutzer zugewiesen sind. Im Gegensatz zu Unix sudo ist für den Erhalt einer AoD-Zustimmung jedoch eine geschäftliche Begründung und eine MPA erforderlich. Außerdem wird ein Audit-Trail erstellt. Außerdem sind AoD-Zustimmungen zeitlich begrenzt.

Durch die Sicherung der vertraulichen Berechtigungen hinter geeigneten Mitgliedschaften können Konten auch bei unwahrscheinlichen Fällen von Missbrauch des Zugriffs nur dann auf diese Berechtigungen zugreifen, wenn eine aktive Zustimmung vorliegt. Durch die Verwendung von sicheren Proxys sind solche Zustimmungen weitgehend nicht mehr erforderlich.

Monitoring von Zugriffsanfragen

Obwohl in vielen Bereichen der Google-Produktion NoPe als Maßnahme zur Zugriffsreduktion verwendet wird, sind AoD-Zustimmungen für unsere sensibelsten Produktionsrollen äußerst selten und nur für den Notfall vorgesehen. Außerdem wird durch jedes Ereignis eine manuelle, nachträgliche Prüfung ausgelöst. Ziel der Prüfung ist es, die Häufigkeit von AoD-Zustimmungen in Zukunft zu senken. Dazu werden diese Ereignisse beispielsweise genutzt, um Verbesserungen an Verwaltungs-APIs anzuregen.

Google überwacht kontinuierlich die AoD-Zustimmungen und die Aktionen, die im Rahmen dieser Zustimmungen ausgeführt werden. Wir verwenden die Echtzeit-Überwachungsdaten, um potenzielle Sicherheitsrisiken zu erkennen und Bereiche zu identifizieren, in denen der Zugriff weiter eingeschränkt werden kann. Wenn ein Vorfall auftritt, ermöglicht der Prüfpfad eine schnelle Reaktion.

Binärautorisierung für Borg

So wie NoPe privilegierte Zugriffspfade schützt, schützt die Binärautorisierung für Borg (BAB) die Softwarelieferkette von Google. BAB trägt dazu bei, dass Produktionssoftware und Jobkonfigurationen vor der Bereitstellung überprüft und genehmigt werden, insbesondere wenn sie auf sensible Daten zugreifen können. Die wichtigsten Konzepte von BAB wurden ursprünglich für die Produktionsinfrastruktur von Google entwickelt und sind jetzt in einer offenen Spezifikation namens Supply Chain Levels for Software Artifacts (SLSA) enthalten.

BAB trägt dazu bei, dass Mitarbeiter Quellcode nicht ohne Peer-Review ändern, Binärdateien ausführen oder Jobs konfigurieren können und dass alle Binärartefakte oder Softwarekonfigurationen nachweislich aus eingechecktem, von Peers überprüften Quellcode erstellt werden.

Weitere Informationen finden Sie unter Binärautorisierung für Borg.

Produktionsmaschinen schützen

Neben der Absicherung privilegierter Zugriffspfade und der Aufrechterhaltung der Integrität der Softwarelieferkette schützt Google die Maschinen, auf denen Produktionsdienste ausgeführt werden. Insbesondere setzen wir Folgendes um:

• Shell-Zugriffskontrollen: Die meisten Google-Mitarbeiter haben keinen Shell-Zugriff (z. B. über SSH) auf Produktionsmaschinen oder auf Arbeitslasten, die auf Borg, dem Clustermanagementsystem von Google, ausgeführt werden. Stattdessen müssen Einzelpersonen sichere Proxys verwenden, bei denen eine andere autorisierte Person jeden Befehl prüfen und genehmigen muss, bevor er ausgeführt wird.

  Nur wenige Teams, die an der Infrastruktur auf niedriger Ebene arbeiten, behalten den nicht einseitigen Shell-Zugriff, damit sie die komplexesten Probleme beheben können, bei denen sichere Proxys nicht praktikabel sind. Ein Zugriff ist nicht einseitig, wenn er die Autorisierung durch eine oder mehrere zusätzliche autorisierte Personen erfordert. Google macht eine Ausnahme, bei der einseitiger Shell-Zugriff zulässig ist: um sicherzustellen, dass Google einen Weg hat, aus Sperrsituationen herauszukommen.

• Kontrollen für den physischen Zugriff: Maschinen müssen regelmäßig physisch gewartet werden, damit sie gut funktionieren. Damit Rechenzentrumstechniker nur aus einem gültigen geschäftlichen Grund auf physische Maschinen zugreifen, verwendet Google physisch-zu-logische Kontrollen.

• Kontrollen für Firmware und Systemsoftware: Google implementiert einen gemessenen Boot-Sicherheitsablauf, der auf einem Hardware-Root of Trust basiert. Der Hardware-Root of Trust trägt dazu bei, die Integrität der Boot-Firmware und Systemsoftware jeder Maschine zu gewährleisten.

Das folgende Diagramm zeigt die Kontrollen, die zum Schutz eines Computers in einem Rechenzentrum beitragen.

Shell-Zugriffssteuerung

SSH ist ein Open-Source-Verwaltungstool, das häufig verwendet wird, um umfassenden Zugriff auf Linux-basierte Server zu ermöglichen. Ohne Kontrollen für den SSH-Zugriff können Konten mit den richtigen Anmeldedaten eine Shell erhalten, mit der sie beliebigen Code auf schwer nachvollziehbare Weise ausführen können.

Mit Shell-Zugriff auf einen Produktionsdienst könnte das Konto beispielsweise das Verhalten einer laufenden Aufgabe ändern, Anmeldedaten exfiltrieren oder Anmeldedaten verwenden, um einen dauerhaften Fußabdruck in der Umgebung zu hinterlassen.

Um dieses Risiko zu minimieren, verwenden wir die folgenden Kontrollen, die den SSH-Zugriff auf Produktionsmaschinen durch sichere, alternative Methoden ersetzen:

• Eingeschränkte APIs: Für Teams mit genau definierten Workflows, für die bisher SSH erforderlich war, ersetzen wir SSH durch genau definierte, prüfbare APIs.
• Sichere Proxys für SSH: Für Teams, die einen flexibleren Zugriff benötigen, ermöglichen sichere Proxys die individuelle Autorisierung und Prüfung von Befehlen.
• MPA: Wenn SREs Notfall-SSH-Zugriff auf einen Computer benötigen, verlangt Google eine geschäftliche Begründung und eine autorisierte Person, die den Zugriff genehmigt. Vollständige Transkripte von Shell-Sitzungen werden protokolliert.
• Sperrszenarien: Die einzige Ausnahme, bei der einseitiger SSH-Zugriff zulässig ist. Vollständige Transkripte von Shell-Sitzungen werden protokolliert.

Diese Kontrollen gleichen den Bedarf an legitimem Shell-Zugriff mit dem Risiko aus, das mit einem zu weitreichenden Shell-Zugriff verbunden ist.

Hintergrund: SSH bei Google

Früher hat Google SSH zur Verwaltung seiner Computer verwendet. Durch die Entwicklung von Borg konnten die meisten Google-Mitarbeiter auf den direkten Zugriff auf die Linux-Maschinen verzichten, auf denen ihre Binärdateien ausgeführt werden. Der Shell-Zugriff blieb jedoch aus mehreren Gründen bestehen:

• Manchmal benötigen Mitarbeiter direkten Zugriff auf einen Computer, um Fehler zu beheben.
• Der SSH-Zugriff ist ein wertvolles Lehrmittel, um die verschiedenen Abstraktionsebenen zu verstehen.
• In unerwarteten Notfallwiederherstellungsszenarien sind Tools auf höherer Ebene möglicherweise nicht verfügbar.

Um diese Gründe und das damit verbundene Sicherheitsrisiko in Einklang zu bringen, hat Google eine Reihe von Meilensteinen festgelegt, um das SSH-Risiko und die Nutzung schrittweise zu eliminieren.

Zentralisiertes Monitoring und zentrale Zugriffssteuerung

Google hat in ein zentrales SSH-Überwachungs- und Autorisierungssystem investiert, das als host identity-based monitoring authorization (HIBA) bezeichnet wird. HIBA bietet Einblick in die SSH-Nutzung und ermöglicht die Durchsetzung strenger Autorisierungsrichtlinien. SSH-Versuche werden nicht nur vom Zielcomputer, sondern auch vom zentralen BeyondCorp-Proxy protokolliert. Von der Shell ausgeführte Befehle werden protokolliert und in Pipelines zur Erkennung von schädlichem Verhalten eingespeist. Die Erkennung ist jedoch von Natur aus reaktiv und anfällig für Umgehungen und Verschleierung.

Meilenstein für einseitigen Zugriff wird entfernt

Für die meisten Mitarbeiter hat Google den Shell-Zugriff (z. B. über SSH) auf Produktionsmaschinen oder auf Arbeitslasten, die auf Borg ausgeführt werden, entfernt. Sie bleibt jedoch für die Entwicklungsteams auf Testmaschinen zugänglich, z. B. auf Maschinen, die zum Qualifizieren neuer Hardware oder neuer Low-Level-Software verwendet werden, aber keine Produktionsdienste ausführen.

Enge APIs

Einige Google-Teams, die früher SSH verwendet haben, um eine begrenzte Anzahl genau definierter Befehle auszuführen (z. B. in einem Playbook) oder Daten zu erhalten, deren Struktur vorhersehbar ist, verwenden jetzt enge APIs, die dem jeweiligen Anwendungsfall dienen und strukturierte Daten bereitstellen.

Enge APIs haben nur wenige Methoden, die auf gängige Nutzerpfade abgestimmt sind, und abstrahieren Details zum Zugriff auf niedriger Ebene. Daher sind sie die bevorzugte Lösung von Google, weil sie die beste Sicherheit und Prüfbarkeit bieten. Da sie auf der Remote-Prozeduraufruf (RPC)-Infrastruktur von Google basieren, profitieren wir von jahrzehntelangen Investitionen in Sicherheit und Auditing.

Sichere Proxys für SSH

Einige Google-Teams können die benötigten Befehle nicht im Voraus ermitteln. In diesem Fall verwendet Google einen Daemon zum Ausführen von Befehlen, der nur Anfragen zur Ausführung beliebiger Befehle von einem vertrauenswürdigen Proxy akzeptiert, der von einem Sicherheitsteam ausgeführt wird. Diese Technologie ähnelt der Technologie, die in sicheren Proxys für NoPe verwendet wird.

Sichere Proxys für SSH sind für die detaillierte Autorisierung der Befehlsausführung und für die Prüfung verantwortlich. Die Autorisierung basiert auf dem Argument und der Umgebung des Befehls, den Ratenbegrenzungsparametern, den geschäftlichen Begründungen und dem MPA. Dieser Autorisierungsprozess ermöglicht beliebig genaue Einschränkungen für die Ausführung von Befehlen gemäß Team-Playbooks und Best Practices. Bei unerwarteten Fehlern, die nicht in vorhandenen Playbooks enthalten sind, können Mitarbeiter die erforderlichen Debugging-Befehle weiterhin ausführen, nachdem eine andere autorisierte Person sie genehmigt hat.

MPA für SSH

Die verbleibenden wenigen Teams, die an der Infrastruktur auf niedriger Ebene arbeiten, behalten eine nicht einseitige Form des Shell-Zugriffs bei, um die komplexesten Probleme zu beheben.

SSH in Sperrszenarien

Google macht eine Ausnahme, bei der einseitiger Shell-Zugriff zulässig ist: um sicherzustellen, dass Google Sperrsituationen beheben kann. Die dafür verwendeten SSH-Schlüssel werden mit einem separaten, prüfbaren Prozess generiert und offline auf manipulationssicherer Hardware gespeichert. Wenn diese Schlüssel verwendet werden, werden vollständige Shell-Sitzungsprotokolle aufgezeichnet.

Physische Zugriffssteuerung

Google-Rechenzentren sind eine komplexe Umgebung mit Servern, Netzwerkgeräten und Steuerungssystemen, die eine breite Palette von Rollen und Fähigkeiten für die Verwaltung, Wartung und den Betrieb erfordern.

Google implementiert sechs Ebenen physischer Steuerelemente und viele logische Steuerelemente auf den Maschinen selbst, um Arbeitslasten im Rechenzentrum zu schützen. Wir schützen auch den Bereich zwischen den Maschinen, den wir als physisch-zu-logischen Bereich bezeichnen.

Physische zu logischen Kontrollen bieten zusätzliche Sicherheitsebenen durch Kontrollen, die als Maschinenhärtung, aufgabenbasierte Zugriffssteuerung und System-Selbstschutz bezeichnet werden. Physisch-zu-logische Steuerelemente schützen vor einem Angreifer, der versucht, physischen Zugriff auf einen Computer zu nutzen und zu einem logischen Angriff auf die Arbeitslasten des Computers zu eskalieren.

Weitere Informationen finden Sie unter So schützt Google den physisch-zu-logischen Bereich in einem Rechenzentrum.

Firmware- und Systemsoftware-Steuerelemente

Der Sicherheitsstatus einer Rechenzentrumsmaschine wird beim Booten ermittelt. Der Bootvorgang der Maschine konfiguriert die Hardware der Maschine und initialisiert ihr Betriebssystem, während dafür gesorgt wird, dass die Maschine sicher in der Produktionsumgebung von Google ausgeführt werden kann.

Bei jedem Schritt des Bootvorgangs implementiert Google branchenführende Kontrollen, um dazu beizutragen, dass der von uns erwartete Bootstatus erzwungen wird und die Sicherheit von Kundendaten gewährleistet ist. Diese Kontrollen sorgen dafür, dass unsere Maschinen in der vorgesehenen Software gestartet werden. Dadurch können wir Sicherheitslücken entfernen, die den anfänglichen Sicherheitsstatus der Maschine beeinträchtigen könnten.

Weitere Informationen finden Sie unter So erzwingt Google die Bootintegrität auf Produktionsmaschinen.

Arbeitslasten schützen

Gemäß unserer Zero-Trust-Philosophie hat Google auch Kontrollen eingeführt, die vor Seitwärtsbewegungen zwischen Arbeitslasten mit unterschiedlichen Sicherheitsanforderungen schützen. Die Google-Infrastruktur verwendet eine Arbeitslasthierarchie, die als Workload Security Rings (WSR) bezeichnet wird. Mit WSR wird dafür gesorgt, dass kritische Arbeitslasten nicht auf denselben Maschinen wie weniger sichere Arbeitslasten geplant werden. Gleichzeitig wird eine negative Auswirkung auf die Ressourcennutzung vermieden. WSR gruppiert Arbeitslasten in vier Vertraulichkeitsklassen – grundlegend, vertraulich, gehärtet und ungehärtet – und versucht, sie in verschiedenen Maschinenpools zu planen.

Das folgende Diagramm zeigt, wie WSR Gruppen und Zeitpläne für Arbeitslasten auf Grundlage von Produktions- und Entwicklungsmaschinen erstellt.

WSR bietet eine zusätzliche Schutzebene gegen lokale Rechteausweitung durch Kernel-Sicherheitslücken oder CPU-Seitenkanalangriffe. WSR trägt dazu bei, dass nur Arbeitslasten mit ähnlichen Sicherheitsanforderungen auf denselben Maschinen geplant werden. So implementieren wir WSR:

• Arbeitslasten nach ihren Sicherheitsanforderungen klassifizieren. Jede Klasse wird als Arbeitslastring bezeichnet.
• Verteilen Sie physische Maschinen auf mehrere Maschinenpools, die voneinander isoliert sind. Mit anderen Worten: Wir entfernen Seitwärtsbewegungspfade zwischen Pools.
• Wenden Sie Planungsbeschränkungen an, um zu verhindern, dass Arbeitslasten mit unterschiedlichen Sicherheitsanforderungen auf derselben Maschine ausgeführt werden. Diese Planungsbeschränkungen verringern das Risiko einer Kompromittierung durch lokale Rechteausweitung.

Für WSR ist beispielsweise erforderlich, dass grundlegende Arbeitslasten auf dedizierten Maschinen ausgeführt werden und niemals zusammen mit nicht grundlegenden Arbeitslasten geplant werden. Diese Einschränkung bietet eine starke Isolation von weniger sicheren Arbeitslasten.

Methoden zum Isolieren von Arbeitslasten

Moderne Systemsoftware ist komplex und Sicherheitsexperten entdecken regelmäßig Sicherheitslücken zur lokalen Rechteausweitung, z. B. Kernel-Zero-Day-Exploits oder neue CPU-Side-Channel-Angriffe. Mit WSR, das erstmals in USENIX ;login: vorgestellt wurde, kann Google das Risiko, das mit der Co-Location von Arbeitslasten verbunden ist, reduzieren und gleichzeitig eine hohe Ressourcennutzung aufrechterhalten.

Standardmäßig verwendet Borg Prozessgrenzen auf Betriebssystemebene, um Container zu isolieren. Diese Prozesse bieten eine schwächere Isolierung als virtuelle Maschinen, die auf Hardware basierende Virtualisierung verwenden. Eine solche schwächere Isolation ist in der Regel ein guter Kompromiss zwischen Effizienz und Sicherheit für Multi-Tenant-Umgebungen, in denen vertrauenswürdige Arbeitslasten ausgeführt werden. Eine vertrauenswürdige Arbeitslast ist eine Arbeitslast, bei der das Binärprogramm und die Konfiguration nachweislich aus von Experten geprüften Code mit bestätigter Herkunft erstellt wurden. Vertrauenswürdige Arbeitslasten verarbeiten keine beliebigen nicht vertrauenswürdigen Daten. Beispiele für die Verarbeitung nicht vertrauenswürdiger Daten sind das Hosten von Drittanbietercode oder das Codieren von Videos.

Google schafft Vertrauen in unsere Binärdateien durch die Verwendung von BAB. BAB reicht jedoch nicht aus, um die Integrität von Arbeitslasten zu gewährleisten, die nicht vertrauenswürdige Daten verarbeiten. Zusätzlich zu BAB müssen solche Arbeitslasten auch in einer Sandbox ausgeführt werden. Eine Sandbox ist eine eingeschränkte Umgebung, z. B. gVisor, in der ein Binärprogramm sicher ausgeführt werden kann. Sowohl für BAB als auch für Sandboxes gelten Einschränkungen.

BAB ist eine gute Kontrollgruppe für ausgereifte Produkte, kann aber die Geschwindigkeit in der Anfangsphase der Entwicklung neuer Systeme und bei der Durchführung von Tests ohne vertrauliche Daten verringern (z. B. bei der Optimierung der Codierung von Daten, die bereits öffentlich sind). Diese Einschränkung bedeutet, dass einige Arbeitslasten immer ohne BAB ausgeführt werden müssen. Bei solchen Arbeitslasten besteht ein höheres Risiko einer lokalen Rechteausweitung, z. B. durch Ausnutzung einer Kernel-Sicherheitslücke, um lokalen Root-Zugriff auf einem Computer zu erhalten.

Durch das Sandboxing nicht vertrauenswürdiger Arbeitslasten wird das Sicherheitsrisiko ebenfalls verringert, allerdings auf Kosten einer erhöhten Rechen- und Speichernutzung. Die Effizienz kann je nach Arbeitslast und Art der Sandbox um einen zweistelligen Prozentsatz sinken. Ein Beispiel für die Auswirkungen auf die Leistung einer Sandbox-Arbeitslast finden Sie in den detaillierten Benchmarks im gVisor Performance Guide. Mit WSR können wir die Effizienzeinschränkungen beheben, die sich aus der Isolierung von Arbeitslasten ergeben.

Arbeitslastringe

Google definiert vier Klassen von Arbeitslasten entsprechend ihren Sicherheitsanforderungen: grundlegend, sensibel, gehärtet und ungehärtet. In der folgenden Tabelle werden sie genauer beschrieben.

Arbeitslastring	Beschreibung
Grundlegend	Eine kleine Gruppe von Arbeitslasten, die für die Sicherheit von Google von entscheidender Bedeutung sind, z. B. Dienste für die Identitäts- und Zugriffsverwaltung. Für grundlegende Arbeitslasten gelten die höchsten Sicherheitsanforderungen. Hier wird in der Regel Effizienz gegen erhöhte Sicherheit und Zuverlässigkeit eingetauscht.
Vertraulich	Arbeitslasten, die weitverbreitete Ausfälle verursachen können oder Zugriff auf vertrauliche produktspezifische Daten wie Nutzer- oder Kundendaten haben.
Gehärtet	Unterstützung von Arbeitslasten, die nicht sicherheitskritisch sind, aber BAB übernommen haben oder in einer Sandbox ausgeführt werden, sodass sie nur ein geringes Risiko für benachbarte Arbeitslasten darstellen.
Nicht gehärtet	Alle anderen Arbeitslasten, einschließlich derer, die nicht vertrauenswürdigen Code ausführen.

Bei Google klassifizieren wir kritische Arbeitslasten, die bestimmte Produkte unterstützen, als vertraulich. Fundamentale Arbeitslasten sind Arbeitslasten, die sich auf alle Produkte auswirken können.

Im Gegensatz zu grundlegenden und sensiblen Arbeitslasten können wir jede Arbeitslast ausschließlich auf Grundlage der angewendeten Kontrollen und der Art der Eingabe, die sie verarbeitet, als gehärtet klassifizieren. Bei gehärteten Arbeitslasten geht es uns in erster Linie um die Auswirkungen auf andere Arbeitslasten. Daher können Härtungslösungen Sandboxing umfassen.

Maschinenpools

Um zu vermeiden, dass vertrauliche Dienste zusammen mit Arbeitslasten geplant werden, die weniger vertrauenswürdig sind (z. B. solche, die nicht vertrauenswürdige Daten ohne Sandbox verarbeiten), müssen wir sie auf isolierten Maschinenpools ausführen. Durch die Maschinenisolation lassen sich die Sicherheitsinvarianten leichter nachvollziehen. Jeder zusätzliche Maschinenpool führt jedoch zu Kompromissen bei der Ressourcennutzung und Wartungsfreundlichkeit.

Die Maschinenisolation führt zu einer geringeren Nutzung physischer Ressourcen, da es schwieriger wird, die Maschinenpools vollständig zu nutzen, wenn wir weitere Pools hinzufügen. Die Effizienzkosten können erheblich sein, wenn es mehrere große, isolierte Maschinenpools gibt.

Da der Ressourcenbedarf von Arbeitslasten in den einzelnen Pools schwankt, führt eine strikte Isolation zu zusätzlichem Verwaltungsaufwand, da Maschinen regelmäßig zwischen den Pools neu verteilt und umfunktioniert werden müssen. Für ein solches Rebalancing müssen alle Arbeitslasten von einem Computer entfernt, der Computer neu gestartet und unser aufwendigster Prozess zur Bereinigung von Computern durchgeführt werden, um die Authentizität und Integrität der Firmware zu gewährleisten.

Diese Überlegungen bedeuten, dass die Implementierung der Maschinenisolation von Google Möglichkeiten zur Optimierung der Nutzung physischer Ressourcen bieten muss und gleichzeitig grundlegende und sensible Arbeitslasten vor Angreifern geschützt werden müssen.

In Kubernetes wird dieser Ansatz als Knotenisolation bezeichnet. Kubernetes-Knoten können physischen oder virtuellen Maschinen zugeordnet werden. In diesem Whitepaper konzentrieren wir uns auf physische Maschinen. Außerdem Google Cloud bieten Produkte wie Compute Engine einzelne Mandanten,um physische Maschinen zu isolieren.

Einschränkungen bei der Arbeitslastplanung

Google stellt Maschinen in drei Arten von isolierten Pools bereit: Fundamentale Maschinen, Produktionsmaschinen und Entwicklungsmaschinen. Google betreibt mehrere isolierte Pools, in denen grundlegende und vertrauliche Arbeitslasten gehostet werden. In diesem Dokument werden sie jedoch zur Vereinfachung als ein Pool dargestellt.

Um einen möglichst effektiven Schutz zu bieten, gelten für WSR die folgenden Planungsbeschränkungen:

• Basisarbeitslasten können nur auf Basismaschinen ausgeführt werden.
• Vertrauliche Arbeitslasten können nur auf Produktionsmaschinen ausgeführt werden.
• Nicht gehärtete Arbeitslasten können nur auf Entwicklungsmaschinen ausgeführt werden.
• Gehärtete Arbeitslasten können auf Produktions- oder Entwicklungsmaschinen ausgeführt werden, wobei Produktionsmaschinen bevorzugt werden.

Das folgende Diagramm zeigt die Planungsbeschränkungen.

In diesem Diagramm werden verschiedene Klassen von Arbeitslasten sowohl zwischen als auch innerhalb von Maschinenpools durch Isolierungsgrenzen getrennt. Basisarbeitslasten sind die einzigen Mandanten dedizierter Basismaschinen. Die Binärautorisierung oder das Sandboxing für Arbeitslasten, die auf Produktionsmaschinen ausgeführt werden, helfen, lokale Angriffe zur Rechteausweitung zu verhindern. Auf Entwicklermaschinen besteht ein Restrisiko, dass eine nicht gehärtete Arbeitslast eine andere Arbeitslast gefährden könnte. Die Gefährdung ist jedoch auf die Entwicklermaschinen beschränkt, da gehärtete Arbeitslasten keine neuen Jobs erstellen können.

Gehärtete Arbeitslasten werden je nach Verfügbarkeit auf Produktions- oder Entwicklungsmaschinen geplant. Die Planung in mehreren Pools zuzulassen, mag kontraintuitiv erscheinen, ist aber unerlässlich, um den durch die Planungsbeschränkungen verursachten Rückgang der Auslastung zu verringern. Robuste Arbeitslasten schließen Lücken, die durch die Isolation sensibler und nicht gehärteter Jobs entstehen. Je größer der Ressourcen-Footprint der gehärteten Ressourcen ist, desto mehr Schwankungen im Ressourcenverbrauch der beiden anderen Klassen können berücksichtigt werden, ohne dass teure Maschinenbewegungen zwischen Ringen erforderlich sind.

Das folgende Diagramm zeigt die Planungsbeschränkungen, die für verschiedene Klassen von Arbeitslasten gelten. Eine gehärtete Arbeitslast kann sich entweder auf einer Produktionsmaschine oder einer Entwicklungsmaschine befinden.

Durch die Isolierung grundlegender Arbeitslasten in mehreren grundlegenden Pools tauscht Google Ressourceneffizienz gegen höhere Sicherheit ein. Glücklicherweise haben grundlegende Arbeitslasten in der Regel einen relativ geringen Ressourcenbedarf und kleine isolierte Pools mit dedizierten Maschinen haben nur geringe Auswirkungen auf die Gesamtauslastung.

WSR bietet eine starke Garantie dafür, dass nicht grundlegende Arbeitslasten niemals auf grundlegenden Maschinen ausgeführt werden dürfen. Basismaschinen sind vor Seitwärtsbewegungen geschützt, da nur Basisarbeitslasten auf diesen Maschinen ausgeführt werden können.

Zusammenfassung der Kontrollen

Google verwendet in seiner gesamten Infrastruktur eine Reihe von Kontrollen, um Produktionsdienste, Produktionsmaschinen und Arbeitslasten zu schützen. Die Einstellungen umfassen Folgendes:

• Administrative Zugriffssteuerung und BAB für Produktionsdienste
• Shell-Zugriffssteuerung, physische Zugriffssteuerung sowie Firmware- und Systemsoftwaresteuerung für Produktionsmaschinen
• WSR für verschiedene Arbeitslastklassen

Zusammen erzwingen diese Kontrollen Einschränkungen, die zum Schutz der Nutzer und Kunden von Google sowie ihrer Daten beitragen. Das folgende Diagramm veranschaulicht, wie die Kontrollen zusammenarbeiten, um die Sicherheitslage von Google zu unterstützen.

Nächste Schritte

• Weitere Informationen zu Sicherheitskontrollen in der Google-Infrastruktur finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.
• Weitere Informationen zur Sicherheitskultur von Google finden Sie unter Sichere und zuverlässige Systeme erstellen (O'Reilly-Buch).
• Weitere Informationen zu Zero-Touch-Prod finden Sie in der SREcon-Präsentation.