So schützt Google seine Produktionsdienste

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

Google betreibt eine globale, mehrmandantenfähige und verteilte Computing-Infrastruktur, um Milliarden von Menschen auf der ganzen Welt Produkte und Dienste zur Verfügung zu stellen. Diese Infrastruktur muss die konkurrierenden Prioritäten wie Sicherheit, Zuverlässigkeit, Ausfallsicherheit, Effizienz, Entwicklungsgeschwindigkeit und Fehlerbehebung in Einklang bringen.

In diesem Dokument werden einige der Mechanismen beschrieben, mit denen wir für eine branchenführende Sicherheitsposition für Dienste sorgen, die in der Produktionsumgebung von Google ausgeführt werden. Diese Dienste umfassen das gesamte Spektrum der Sicherheitsempfindlichkeit, von Entwicklungstests ohne Zugriff auf sensible Daten bis hin zur kritischen Identitätsinfrastruktur. Diese Dienste übernehmen Aufgaben wie die Verarbeitung von Nutzerdaten, die Verwaltung von Software-Roll-outs sowie die Bereitstellung und Lebenszyklusverwaltung für einzelne physische Maschinen.

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

• Produktionsdienste, einschließlich der sicherheitskritischsten Dienste (auch als Grundlagendienste bezeichnet)
• Produktionsmaschinen
• Produktionsarbeitslasten

Wir wenden diese Kontrollen an, damit Google-Mitarbeiter nur zu legitimen geschäftlichen Zwecken (z. B. Wartungszugriff) auf Dienste, Maschinen und Arbeitslasten zugreifen können, und um sich vor Insiderrisiken und Manipulationen von Mitarbeiterkonten zu schützen. Diese Kontrollen bieten einen zusätzlichen Schutz durch mehrstufige Absicherung, der die vorhandenen Infrastruktursicherheitskontrollen ergänzt, die dazu beitragen, Kontomanipulationen zu verhindern.

Kontinuierliche Verbesserungen

Die in diesem Artikel beschriebenen Steuerelemente werden in der gesamten Produktionsumgebung von Google verwendet. Viele Dienste, einschließlich grundlegender Dienste, nutzen die neuesten Steuerelemente, die wir anbieten. Aufgrund des Umfangs und der Komplexität der Google-Infrastruktur haben einzelne Produktionsdienste jedoch oft individuelle Anforderungen und es kann zusätzliche Zeit in Anspruch nehmen, die neuesten Empfehlungen umzusetzen. Dank einer Kultur der kontinuierlichen Verbesserung passen die Site Reliability Engineers (SREs) 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 der Produktionsdienste bei, damit Google-Mitarbeiter nur zu legitimen geschäftlichen Zwecken wie Wartung auf die Dienste zugreifen können. Es gibt zwei Möglichkeiten, um Zugriff auf Dienste zu erhalten, die in der Produktionsumgebung ausgeführt werden: über den Administratorzugriff und über die Softwareversorgungskette.

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

• Verwaltungszugriffssteuerungen: Produktionsdienste erfordern regelmäßige Wartung (z. B. Binär- oder Konfigurations-Rollouts). 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 Einstellungen, die den Zugriff von Personen auf Produktions-Assets entfernen, werden als No Persons (NoPe) bezeichnet. NoPe bietet Google die Flexibilität, Zugriffssteuerungen bereitzustellen, die auf der Sensibilität eines Produktionsdienstes und seiner Bereitschaft basieren, durch kontinuierliche Verbesserung eine noch stärkere Position zu erreichen.

  Google erlaubt beispielsweise keinen einseitigen Zugriff auf grundlegende Dienste. Selbst der Notfallzugriff erfordert die Genehmigung anderer Google-Mitarbeiter. Ein Zugriff ist einseitig, wenn eine Person den Zugriff ohne Genehmigung einer anderen autorisierten Person ausführen kann.

• Kontrollen der Softwarelieferkette: Bei der Mehrheit der Produktionsarbeitslasten bei Google, einschließlich grundlegender Dienste, werden Binärprogramme und Jobkonfigurationen ausgeführt, die nachweislich aus von Experten geprüftem Code erstellt wurden, 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 Steuerelemente, mit denen ein Produktionsdienst geschützt werden kann.

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. Ein privilegierter Zugriff ist ein erhöhtes Zugriffsrecht, das Mitarbeitern gewährt wird, um kritische Produktionsdienste bei besonderen Umständen zu verwalten, die nicht durch Automatisierung abgedeckt werden. Wir machen eine Ausnahme von dieser Regel, damit Google in Fällen von Sperrungen reagieren kann.

Viele andere Produktionsdienste, darunter Produkte wie Filestore oder Cloud SQL sowie interne Infrastrukturprodukte wie Borg und Spanner, sind für die Verwendung der höchsten NoPe- und BAB-Ebenen konfiguriert. Wir arbeiten kontinuierlich daran, die Einführung von NoPe und BAB für die Eigentümer von Produktionsdiensten im Laufe der Zeit zu erleichtern.

Administratorzugriffssteuerungen

In Borg können Mitglieder einer Produktionsrolle die Daten, deren Eigentümer die Produktionsrolle ist, 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.

Eine dauerhafte Mitgliedschaft in Produktionsrollen birgt das Risiko unbeabsichtigter Folgen für die Produktion und das Risiko, dass diese Berechtigungen missbraucht werden. Die Aufgabe von SRE erfordert jedoch, dass Teams die Dienste, für die sie verantwortlich sind, verwalten können. Daher ist das vollständige Entfernen des Zugriffs möglicherweise keine praktikable Strategie.

Die NoPe-Suite bietet eine Möglichkeit, den Zugriff so zu konfigurieren, dass die gegensätzlichen Anforderungen an die Befähigung von Teams und die Sicherheit von Produktionssystemen in Einklang gebracht werden. Bei NoPe sehen Google-Mitarbeiter Einschränkungen bei den Berechtigungen ihrer Konten, wenn sie versuchen, auf Produktionsdienste zuzugreifen. NoPe ermöglicht die folgenden Einschränkungen:

• Zugriffsanfragen erfordern eine Genehmigung und eine Begründung: Mithilfe einer Genehmigung durch mehrere Parteien (Multi-Party Authorization, MPA) wird sichergestellt, dass Google-Mitarbeiter nicht ohne geschäftliche Begründung und Genehmigung einer anderen Person, die zur Überprüfung der Zugriffsanfrage berechtigt ist, auf Produktionsdienste zugreifen können.
• Kein direkter Zugriff auf Rollen für Produktionsdienste: Mitarbeiter können nur über sichere Proxys für NoPe auf Produktionsdienste zugreifen. Sichere Proxys sind so konzipiert, dass nur eine genau definierte Gruppe von Befehlen ausgeführt werden kann. Für alle Befehle, die von den Google Security- und SRE-Organisationen als riskant eingestuft werden (z. B. das Deaktivieren eines Dienstes oder der Zugriff auf oder das Löschen von Daten), ist ebenfalls eine MPA erforderlich.
• Keine dauerhafte Mitgliedschaft in einer Produktionsrolle: Bei einer Funktion namens On-Demand-Zugriff (AoD) müssen Mitarbeiter eine vorübergehende Mitgliedschaft beantragen, anstatt dass Mitarbeiterkonten immer Zugriffsberechtigungen haben. So wird sichergestellt, dass erhöhte Berechtigungen nur vorübergehend und aus bestimmten Gründen gewährt werden.
• Überwachung von Zugriffsanfragen von Mitarbeitern auf Produktionsdienste: Google verlangt eine regelmäßige Prüfung der Zugriffsmuster für Produktionsrollen, die einen Produktionsdienst ausführen. Ziel der Prüfung ist es, solche Anfragen in Zukunft durch kontinuierliche Verbesserung der Verwaltungs-APIs zu vermeiden. Der Zugriff auf Produktionsdienste sollte nur für Notfallsituationen reserviert werden. 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 Steuerelemente ausführlich beschrieben.

Genehmigung durch mehrere Parteien für NoPe

Bei der MPA muss ein anderer autorisierter Google-Mitarbeiter einen Zugriffsantrag genehmigen.

Bei Anfragen zum Zugriff auf ausreichend sensible Dienste muss das Personal gemäß MPA außerdem bei jeder Anfrage eine geschäftliche Begründung angeben, die sich auf einen laufenden Produktionsnotfall bezieht.

Beide Bedingungen sind ein Schutz vor Missbrauch des Zugriffs.

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 einer anderen autorisierten Person für die Ausführung von Befehlen erfordern, die sich negativ auf die Sicherheit oder Zuverlässigkeit auswirken können (z. B. Befehle zum Löschen von Dateien). Mithilfe von Richtlinien können bestimmte sichere Befehle (z. B. Befehle, die die Ressourcennutzung auflisten) auch 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 vom sicheren Proxy zugelassenen Vorgänge beschränkt. Das Konto kann nur sichere Befehle einseitig ausführen, während für privilegierte Vorgänge die Genehmigung einer anderen autorisierten Person erforderlich ist. Alle Vorgänge hinterlassen einen klaren Audit-Trail.

Weitere Informationen zu sicheren Proxys finden Sie in der SREcon-Präsentation zu Zero-Touch-Produktivität. Zero-Touch-Produktivität ist eine Reihe von Prinzipien und Tools, die dafür sorgen, dass jede Änderung in der Produktion durch Automatisierung (ohne menschliches Eingreifen) durchgeführt, von Software vorab validiert oder mit einem geprüften Mechanismus für Notfälle vorgenommen wird.

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 eine andere autorisierte Person die Genehmigung erteilt, wird der Antragsteller für eine begrenzte Zeit, in der Regel weniger als einen Tag, Mitglied der Rolle.

Mit dem Modell für berechtigte Mitgliedschaften können Mitarbeiter nur den Zugriff anfordern, den sie für die erforderliche Dauer benötigen. Konzeptionell können Sie sich AoD als zeitlich begrenzte Produktions-sudo vorstellen, ähnlich wie den Befehl sudo -u unter Unix, mit dem Sie einige Befehle mit den erhöhten Berechtigungen ausführen können, die mit einem bestimmten Nutzer verknüpft 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 löst jedes Ereignis eine manuelle Prüfung nach dem Ereignis aus. 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. Anhand der Echtzeit-Monitoring-Daten erkennen wir potenzielle Sicherheitslücken und Bereiche, in denen der Zugriff weiter eingeschränkt werden kann. Bei einem Vorfall ermöglicht der Audit-Trail eine schnelle Reaktion.

Binärautorisierung für Borg

Genau wie NoPe zum Schutz von Pfaden mit erhöhten Zugriffsrechten beiträgt, trägt die Binärautorisierung für Borg (BAB) zum Schutz der Softwarelieferkette von Google bei. 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 ursprünglich für die Produktionsinfrastruktur von Google entwickelten Schlüsselkonzepte von BAB sind jetzt in einer offenen Spezifikation namens Supply Chain Levels for Software Artifacts (SLSA) enthalten.

Mit der Bewertung vor dem Build wird dafür gesorgt, dass Mitarbeiter den Quellcode nicht ohne Peer-Review ändern, Binärprogramme ausführen oder Jobs konfigurieren können und dass jedes Binärartefakt oder jede Softwarekonfiguration nachweislich aus eingechecktem, von anderen geprüftem Quellcode erstellt wird.

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

Produktionsmaschinen schützen

Google schützt nicht nur die privilegierten Zugriffspfade und die Integrität der Softwarelieferkette, sondern auch die Maschinen, auf denen Produktionsdienste ausgeführt werden. Insbesondere implementieren wir Folgendes:

• Shell-Zugriffssteuerung: Die meisten Google-Mitarbeiter haben keinen Shell-Zugriff (z. B. über SSH) auf Produktionsmaschinen oder Arbeitslasten, die auf Borg, dem Clusterverwaltungssystem von Google, ausgeführt werden. Stattdessen müssen Einzelpersonen sichere Proxys verwenden, bei denen jeder Befehl von einer anderen autorisierten Person überprüft und genehmigt werden muss, bevor er ausgeführt wird.

  Nur wenige Teams, die an der Infrastruktur auf niedriger Ebene arbeiten, behalten einen 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 einer oder mehrerer weiterer autorisierter Personen erfordert. Google macht eine Ausnahme, bei der ein einseitiger Shell-Zugriff zulässig ist: Damit Google in Sperrsituationen eine Möglichkeit hat, diese zu beenden.

• Physische Zugriffssteuerung: Maschinen müssen regelmäßig gewartet werden, damit sie ordnungsgemäß funktionieren. Damit Rechenzentrumstechniker nur aus geschäftlichen Gründen auf physische Maschinen zugreifen können, verwendet Google physisch-zu-logische Kontrollen.

• Firmware- und Systemsoftwaresteuerung: Google implementiert einen sicherheitsrelevanten Ablauf für den gemanagten Start, der auf einem Hardware-Root of Trust basiert. Der Hardware-Root-of-Trust trägt dazu bei, die Integrität der Boot-Firmware und der Systemsoftware jedes Geräts zu gewährleisten.

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

Shell-Zugriffssteuerungen

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

Mit Shell-Zugriff auf einen Produktionsdienst kann das Konto beispielsweise das Verhalten eines laufenden Tasks ändern, Anmeldedaten abfangen oder Anmeldedaten verwenden, um einen dauerhaften Fuß in der Umgebung zu fassen.

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

• Enge APIs: Bei Teams mit klar definierten Workflows, für die zuvor SSH erforderlich war, ersetzen wir SSH durch eng definierte, auditierbare APIs.
• Sichere Proxys für SSH: Für Teams, die einen flexibleren Zugriff benötigen, können sichere Proxys verwendet werden, um Befehle einzeln zu autorisieren und zu prüfen.
• MPA: Wenn SREs im Notfall SSH-Zugriff auf einen Computer benötigen, muss Google eine geschäftliche Begründung und eine autorisierte Person haben, die den Zugriff genehmigt. Die vollständigen Transkripte der Shell-Sitzungen werden protokolliert.
• Sperrungsszenarien: Die einzige Ausnahme, bei der ein einseitiger SSH-Zugriff zulässig ist. Die vollständigen Transkripte der Shell-Sitzungen werden protokolliert.

Mit diesen Steuerelementen wird der Bedarf an legitimem Shell-Zugriff mit dem Risiko abgewogen, das mit einem zu weit gefassten Shell-Zugriff verbunden ist.

Hintergrund: SSH bei Google

In der Vergangenheit hat Google SSH zur Verwaltung seiner Maschinen verwendet. Durch die Entwicklung von Borg benötigten die meisten Google-Mitarbeiter keinen direkten Zugriff mehr auf die Linux-Maschinen, auf denen ihre Binärdateien ausgeführt wurden. Der Shell-Zugriff blieb jedoch aus mehreren Gründen bestehen:

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

Um einen Ausgleich zwischen diesen Gründen und dem damit verbundenen Sicherheitsrisiko zu schaffen, hat Google eine Reihe von Meilensteinen festgelegt, um das SSH-Risiko und dann die Nutzung schrittweise zu beseitigen.

Meilenstein: Zentrale Überwachung und Zugriffssteuerung

Google hat in ein zentrales SSH-Monitoring- und Autorisierungssystem investiert, das als Host Identity-Based Monitoring Authorization (HIBA) bezeichnet wird. HIBA bietet Transparenz bei der 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 böswilligen Verhaltens eingespeist. Die Erkennung ist jedoch von Natur aus reaktiv und anfällig für Umgehung und Verschleierung.

Meilenstein zur Abschaffung des einseitigen Zugriffs

Google hat für die meisten Mitarbeiter den Shell-Zugriff (z. B. über SSH) auf Produktionsmaschinen oder auf Arbeitslasten, die auf Borg ausgeführt werden, entfernt. Für die Entwicklungsteams bleibt sie jedoch auf Testmaschinen zugänglich, z. B. auf Maschinen, die zur Qualifizierung 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, da sie die höchste Sicherheit und Prüfbarkeit bieten. Da sie auf der RPC-Infrastruktur (Remote Procedure Call) von Google basieren, profitieren wir von jahrzehntelangen Investitionen in Sicherheit und Prüfung.

Sichere Proxys für SSH

Einige Google-Teams können die Befehle, die sie möglicherweise benötigen, nicht im Voraus bestimmen. In diesem Fall verwendet Google einen Befehlsausführungs-Daemon, 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 Parametern zur Ratebegrenzung, geschäftlichen Begründungen und dem MPA. Dieser Autorisierungsprozess ermöglicht beliebig genaue Einschränkungen, welche Befehle gemäß den Playbooks und Best Practices des Teams ausgeführt werden können. Bei unerwarteten Fehlern, die nicht in vorhandenen Playbooks erfasst sind, können Mitarbeiter die erforderlichen Debugging-Befehle ausführen, nachdem eine andere autorisierte Person sie genehmigt hat.

MPA für SSH

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

SSH bei Sperrungsszenarien

Google macht eine Ausnahme, wenn ein einseitiger Shell-Zugriff zulässig ist: Damit Google Sperrsituationen beheben kann. Die zu diesem Zweck verwendeten SSH-Schlüssel werden mit einem bestimmten überprüfbaren Prozess generiert und offline auf manipulationssicherer Hardware gespeichert. Wenn diese Schlüssel verwendet werden, werden vollständige Shell-Sitzungstranskripte protokolliert.

Physische Zugriffssteuerungen

Die Google-Rechenzentren sind eine komplexe Umgebung mit Servern, Netzwerkgeräten und Steuersystemen, 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. Außerdem schützen wir den Bereich zwischen den Maschinen, den wir physisch-zu-logischer Bereich nennen.

Physische bis logische Steuerelemente bieten zusätzliche Verteidigungsebenen durch Steuerelemente, die als Hardware-Härtung, aufgabenbasierte Zugriffssteuerung und Systemeigenschutz bezeichnet werden. Physisch-zu-logische Steuerelemente schützen vor Angreifern, die den physischen Zugriff auf einen Computer ausnutzen und zu einem logischen Angriff auf die Arbeitslasten des Computers eskalieren möchten.

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

Firmware- und Systemsoftware-Steuerungen

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 Workload Security Rings (WSR) genannt wird. WSR trägt dazu bei, dass kritische Arbeitslasten nicht auf denselben Maschinen wie weniger sichere Arbeitslasten geplant werden, und verhindert negative Auswirkungen auf die Ressourcennutzung. WSR gruppiert Arbeitslasten in vier Sensibilitätsklassen – grundlegend, sensibel, gehärtet und ungehärtet – und versucht, sie in verschiedenen Maschinenpools zu planen.

Das folgende Diagramm zeigt, wie WSR Arbeitslasten auf Basis-, Produktions- und Entwicklungsmaschinen gruppiert und plant.

WSR bieten eine zusätzliche Verteidigungsschicht gegen lokale Berechtigungsausweitungen 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:

• Klassifizieren Sie Arbeitslasten nach ihren Sicherheitsanforderungen. Jede Klasse wird als Arbeitslastring bezeichnet.
• Physische Maschinen auf mehrere voneinander getrennte Maschinenpools verteilen. Mit anderen Worten: Wir entfernen Seitwärtsbewegungspfade zwischen Pools.
• Sie können Planungseinschränkungen anwenden, um zu verhindern, dass Arbeitslasten mit unterschiedlichen Sicherheitsanforderungen auf demselben Computer ausgeführt werden. Diese Planungseinschränkungen verringern das Risiko von Manipulationen durch lokale Rechteausweitung.

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

Methoden zur Isolierung von Arbeitslasten

Moderne Systemsoftware ist komplex und Sicherheitsforscher entdecken regelmäßig Sicherheitslücken bei der lokalen Rechteausweitung, z. B. Kernel-Zero-Day-Exploits oder neue CPU-Seitenkanalangriffe. 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 geringere Isolationsgrenze als virtuelle Maschinen, die hardwarebasierte Virtualisierung verwenden. Diese geringere 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üftem Code mit nachgewiesener Herkunft erstellt wurden. Bei vertrauenswürdigen Arbeitslasten werden keine beliebigen nicht vertrauenswürdigen Daten verarbeitet. Beispiele für die Verarbeitung nicht vertrauenswürdiger Daten sind das Hosten von Drittanbietercode oder das Codieren von Videos.

Google setzt BAB ein, um die Vertrauenswürdigkeit seiner Binärdateien zu gewährleisten. BAB reicht jedoch nicht aus, um die Integrität von Arbeitslasten zu gewährleisten, bei denen nicht vertrauenswürdige Daten verarbeitet werden. Zusätzlich zu BAB müssen solche Arbeitslasten auch in einer Sandbox ausgeführt werden. Eine Sandbox ist eine eingeschränkte Umgebung, wie gVisor, in der ein Binärprogramm sicher ausgeführt werden kann. Sowohl die Bewertungs- und Analysetools als auch Sandboxes haben Einschränkungen.

BAB ist eine gute Kontrolle für ausgereifte Produkte, kann aber die Geschwindigkeit in den frühen Phasen der Entwicklung neuer Systeme und bei der Durchführung von Tests ohne sensible Daten verringern (z. B. bei der Optimierung der Codierung von Daten, die bereits öffentlich sind). Aufgrund dieser Einschränkung müssen einige Arbeitslasten immer ohne BAB ausgeführt werden. Bei solchen Arbeitslasten besteht von Natur aus ein höheres Risiko für die lokale Eskalierung von Berechtigungen, z. B. durch Ausnutzung einer Kernel-Sicherheitslücke, um auf einem Computer lokalen Root-Zugriff zu erhalten.

Das Sandboxing nicht vertrauenswürdiger Arbeitslasten reduziert auch das Sicherheitsrisiko, geht aber mit einer erhöhten Rechen- und Arbeitsspeichernutzung einher. Je nach Arbeitslast und Sandboxtyp kann die Effizienz um einen zweistelligen Prozentsatz sinken. Ein Beispiel für die Leistungsauswirkungen auf eine Arbeitslast in einer Sandbox finden Sie in den detaillierten Benchmarks im gVisor-Leistungsleitfaden. Mit WSR können wir die Effizienzeinschränkungen beheben, die durch die Isolierung von Arbeitslasten entstehen.

Arbeitslastringe

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

Arbeitslastring	Beschreibung
Grundlegend	Arbeitslasten, die für die Sicherheit von Google entscheidend sind, z. B. Identitäts- und Zugriffsverwaltungsdienste. Für grundlegende Arbeitslasten gelten die höchsten Sicherheitsanforderungen. Hier wird regelmäßig Effizienz gegen mehr Sicherheit und Zuverlässigkeit eingetauscht.
Vertraulich	Arbeitslasten, die zu weitreichenden Ausfällen führen können oder Zugriff auf vertrauliche produktspezifische Daten wie Nutzer- oder Kundendaten haben.
Gehärtet	Unterstützung von Arbeitslasten, die nicht sicherheitskritisch sind, aber die BAB eingeführt haben oder in einer Sandbox ausgeführt werden, sodass sie ein geringes Risiko für benachbarte Arbeitslasten darstellen.
Nicht gehärtet	Alle anderen Arbeitslasten, einschließlich solcher, auf denen nicht vertrauenswürdiger Code ausgeführt wird.

Bei Google werden kritische Arbeitslasten, die bestimmte Produkte unterstützen, als sensibel eingestuft. Grundlegende 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 anhand der verwendeten Steuerelemente und der Art der verarbeiteten Eingabe als gehärtet klassifizieren. Bei gehärteten Arbeitslasten geht es vor allem um ihre Auswirkungen auf andere Arbeitslasten. Daher können Härtungslösungen Sandboxing umfassen.

Maschinenpools

Um zu vermeiden, dass sensible Dienste gemeinsam mit Arbeitslasten geplant werden, die weniger vertrauenswürdig sind (z. B. solche, die nicht vertrauenswürdige Daten ohne Sandbox verarbeiten), müssen sie in isolierten Maschinenpools ausgeführt werden. Die Maschinenisolierung erleichtert das Verständnis der Sicherheitsinvarianten. Jeder zusätzliche Maschinenpool führt jedoch zu Kompromissen bei der Ressourcennutzung und Wartbarkeit.

Die Maschinenisolierung führt zu einer geringeren physischen Ressourcennutzung, da es immer schwieriger wird, dafür zu sorgen, dass Maschinenpools vollständig ausgelastet sind, wenn wir mehr Pools hinzufügen. Die Effizienzkosten können erheblich werden, wenn es mehrere große, isolierte Maschinenpools gibt.

Da die Ressourcenauslastung von Arbeitslasten in jedem Pool schwankt, erhöht eine strenge Isolation den Verwaltungsaufwand, um Maschinen regelmäßig neu auszubalancieren und zwischen Pools wiederzuverwenden. Für eine solche Neuausrichtung müssen alle Arbeitslasten von einem Computer entfernt, der Computer neu gestartet und unser umfangreichster Prozess zur Computerbereinigung durchgeführt werden, der für Authentizität und Integrität der Firmware sorgt.

Aus diesen Überlegungen ergibt sich, dass die Implementierung der Maschinenisolierung von Google Möglichkeiten zur Optimierung der Nutzung physischer Ressourcen bieten und gleichzeitig grundlegende und sensible Arbeitslasten vor Angreifern schützen muss.

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

Einschränkungen bei der Arbeitslastplanung

Google stellt Maschinen in drei Arten von isolierten Pools bereit: Basismaschinen, Produktionsmaschinen und Entwicklungsmaschinen. Google betreibt mehrere isolierte Pools, in denen grundlegende und sensible Arbeitslasten gehostet werden. In diesem Dokument werden sie jedoch aus Gründen der Übersichtlichkeit als einzelner Pool dargestellt.

Um den bestmöglichen Schutz zu bieten, gelten für WSR die folgenden Planungseinschränkungen:

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

Das folgende Diagramm zeigt die Planungseinschränkungen.

In diesem Diagramm werden verschiedene Arbeitslastklassen sowohl zwischen als auch innerhalb von Maschinenpools durch Isolationsgrenzen voneinander getrennt. Grundlegende Arbeitslasten sind die einzigen Nutzer spezieller grundlegender Maschinen. Die Binärautorisierung oder Sandboxing für Arbeitslasten, die auf Produktionsmaschinen ausgeführt werden, hilft, Angriffe auf die lokale Rechteausweitung zu verhindern. Auf Entwicklungscomputern besteht ein Restrisiko, dass eine nicht gehärtete Arbeitslast eine andere Arbeitslast schädigen kann. Die Manipulation ist jedoch auf die Entwicklungscomputer beschränkt, da mit gehärteten Arbeitslasten keine neuen Jobs erstellt werden können.

Gehärtete Arbeitslasten werden je nach Verfügbarkeit auf Produktions- oder Entwicklungsmaschinen geplant. Die Planung in mehreren Pools zuzulassen, mag zwar kontraintuitiv erscheinen, ist aber unerlässlich, um den durch die Planungseinschränkungen verursachten Rückgang der Auslastung zu verringern. Durch die Härtung von Arbeitslasten werden Lücken geschlossen, die durch die Isolierung sensibler und nicht gehärteter Jobs entstehen. Außerdem können je größer der Ressourcenbedarf der abgehärteten Ressourcen ist, desto mehr Schwankungen bei der Ressourcennutzung der anderen beiden Klassen aufgenommen werden, ohne dass teure Maschinenbewegungen zwischen den Ringen erforderlich sind.

Das folgende Diagramm zeigt die Planungseinschränkungen, die für verschiedene Arbeitslastklassen gelten. Eine gehärtete Arbeitslast kann sich entweder auf einem Produktions- oder einem Entwicklungscomputer befinden.

Durch die Isolierung grundlegender Arbeitslasten in mehreren grundlegenden Pools tauscht Google Ressourceneffizienz gegen mehr Sicherheit ein. Glücklicherweise haben grundlegende Arbeitslasten in der Regel einen relativ geringen Ressourcenverbrauch und kleine, isolierte Pools von dedizierten Maschinen haben nur einen vernachlässigbaren Einfluss auf die Gesamtauslastung. Selbst bei umfangreicher Automatisierung ist die Verwaltung mehrerer Maschinenpools mit Kosten verbunden. Deshalb entwickeln wir unsere Maschinendesigns ständig weiter, um die Isolation zu verbessern.

WSR bietet eine hohe Garantie dafür, dass nicht grundlegende Arbeitslasten niemals auf Basismaschinen 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 Steuerelemente

Google verwendet in seiner gesamten Infrastruktur eine Reihe von Kontrollen, um Produktionsdienste, Produktionsmaschinen und Arbeitslasten zu schützen. Zu den Steuerelementen gehören:

• Verwaltungszugriffssteuerung und BAB für Produktionsdienste
• Shell-Zugriffssteuerungen, physische Zugriffssteuerungen sowie Firmware- und Systemsoftwaresteuerungen für Produktionsmaschinen
• WSR für verschiedene Arbeitslastklassen

Zusammengenommen tragen diese Kontrollen dazu bei, die Nutzer und Kunden von Google und ihre Daten zu schützen. Das folgende Diagramm zeigt, wie die Kontrollen zusammenwirken, um die Sicherheitsstrategie von Google zu unterstützen.

Nächste Schritte

• Weitere Informationen zu Sicherheitsmaßnahmen 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-Produktion finden Sie in der SREcon-Präsentation.

Autoren: Michael Czapiński und Kevin Plybon