BeyondProd

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Der Inhalt dieses Dokuments wurde im November 2022 zum letzten Mal aktualisiert und stellt den Stand bei der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.

In diesem Dokument wird beschrieben, wie Google die Sicherheit in unserer Infrastruktur mithilfe einer cloudnativen Architektur namens BeyondProd implementiert. BeyondProd bezieht sich auf Dienste und Einstellungen in unserer Infrastruktur, die zum Schutz von Arbeitslasten zusammenarbeiten. Arbeitslasten sind eindeutige Aufgaben, die von einer Anwendung abgearbeitet werden. BeyondProd schützt die Mikrodienste, die wir in unserer Umgebung ausführen, einschließlich der Art und Weise, wie wir Code ändern und wie wir auf Nutzerdaten zugreifen.

Dieses Dokument ist Teil einer Reihe technischer Dokumentationen, in denen die Technologien beschrieben werden, z. B. BeyondCorp Enterprise, , die wir entwickelt haben, um Google-Plattformen vor ausgeklügelten Bedrohungen zu schützen. BeyondCorp Enterprise implementiert eine Zero-Trust-Architektur, die sicheren Zugriff auf Google-Plattformen und die darauf ausgeführten Dienste bietet. Wie bei BeyondCorp Enterprise verlässt sich BeyondProd nicht auf einen herkömmlichen Netzwerkperimeterschutz wie Firewalls. Stattdessen hilft BeyondProd dabei, Vertrauen zwischen Mikrodiensten zu schaffen. Dazu nutzt es Merkmale wie Codeherkunft, Dienstidentitäten und vertrauenswürdige Hardware. Dieses Vertrauen gilt für Software, die in Google Cloud ausgeführt wird, und Software, die von Google Cloud-Kunden bereitgestellt und aufgerufen wird.

In diesem Dokument werden die Vorteile von BeyondProd, dessen Diensten und Prozessen sowie die Migration auf diese Architektur beschrieben. Eine Übersicht über die Infrastruktursicherheit finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.

Einführung

Moderne Sicherheitsarchitekturen haben sich von einem herkömmlichen perimeterbasierten Sicherheitsmodell entwickelt, bei dem eine Firewall den Perimeter schützt und alle Nutzer oder Dienste innerhalb des Perimeters als vertrauenswürdig gelten.

Heute sind Nutzer mobil und arbeiten häufig außerhalb des traditionellen Sicherheitsperimeters einer Organisation, z. B. von zu Hause aus, im Café oder in einem Flugzeug. Mit BeyondCorp Enterprise gewähren wir den Zugriff auf Unternehmensressourcen anhand mehrerer Faktoren, darunter die Identität des Nutzers, die Identität des Geräts, das für den Zugriff auf die Ressource verwendet wird, der Zustand des Geräts, Vertrauenssignale wie das Nutzerverhalten und Zugriffskontrolllisten.

BeyondProd befasst sich mit denselben Problemen bei Produktionsdiensten wie BeyondCorp Enterprise für Nutzer. In einer cloudnativen Architektur können wir uns nicht einfach auf eine Firewall verlassen, um das Produktionsnetzwerk zu schützen. Mikrodienste werden in verschiedenen Umgebungen auf heterogenen Hosts verschoben und bereitgestellt und arbeiten auf verschiedenen Vertrauens- und Empfindlichkeitsstufen. Während BeyondCorp Enterprise feststellt, dass das Vertrauen der Nutzer von Merkmalen wie dem kontextbezogenen Zustand der Geräte und nicht von der Fähigkeit, sich mit dem Unternehmensnetz zu verbinden, abhängen sollte, stellt BeyondProd fest, dass das Vertrauen in den Dienst von Merkmalen wie der Herkunft des Codes, der vertrauenswürdigen Hardware und der Identität des Dienstes abhängen sollte, und nicht von der Position im Produktionsnetz, wie IP-Adresse oder Hostname.

Containerisiert Infrastruktur

Unsere Infrastruktur stellt Arbeitslasten als einzelne Mikrodienste in Containern bereit. Mikrodienste trennen die einzelnen Aufgaben, die eine Anwendung ausführen muss, in verschiedene Dienste. Jeder Dienst kann unabhängig für seine eigene API, Einführung, Skalierung und Kontingentverwaltung entwickelt und verwaltet werden. Mikrodienste sind unabhängig, modular, dynamisch und flüchtig. Sie können auf mehrere Hosts, Cluster oder sogar Clouds verteilt werden. In einer Mikrodienstarchitektur kann eine Arbeitslast aus einem oder mehreren Mikrodiensten bestehen.

Eine Containerinfrastruktur bedeutet, dass jeder Mikrodienst als eigener Satz beweglicher und planbarer Container bereitgestellt wird. Um diese Container intern verwalten zu können, haben wir ein Container-Orchestrierungssystem mit dem Namen Borg entwickelt, das mehrere Milliarden Container pro Woche bereitstellt. Borg ist das einheitliche Containerverwaltungssystem von Google und dient als Inspiration für Kubernetes.

Mit Containern lassen sich Arbeitslasten einfacher und effizienter auf mehreren Maschinen planen. Durch das Verpacken von Mikrodiensten in Container können Arbeitslasten in kleinere, besser verwaltbare Einheiten zur Wartung und Aufteilung aufgeteilt werden. Bei dieser Architektur werden Arbeitslasten nach Bedarf skaliert. Wenn für eine bestimmte Arbeitslast eine hohe Nachfrage besteht, können mehrere Maschinen Kopien desselben Containers ausführen, um die erforderliche Arbeitslast zu bewältigen.

Bei Google spielt die Sicherheit bei jeder Weiterentwicklung unserer Architektur eine entscheidende Rolle. Unser Ziel bei dieser Mikrodienstarchitektur und diesem Entwicklungsprozess ist es, Sicherheitsprobleme im Entwicklungs- und Bereitstellungszyklus so früh wie möglich zu berücksichtigen, wenn dies günstiger ist, und zwar auf standardisierte und einheitliche Weise. Das Endergebnis ist, dass Entwickler weniger Zeit für die Sicherheit aufwenden müssen und gleichzeitig sicherere Ergebnisse erzielen.

BeyondProd-Vorteile

BeyondProd bietet viele Automatisierungs- und Sicherheitsvorteile für die Google-Infrastruktur. Hier sind einige dieser Vorteile:

  • Edge-Netzwerkschutz: Arbeitslasten werden von Netzwerkangriffen und von nicht autorisiertem Traffic aus dem Internet isoliert. Ein Perimeteransatz ist zwar kein neues Konzept, bleibt aber eine bewährte Sicherheitsmethode für Cloudarchitekturen. Ein Perimeteransatz hilft, so viel Infrastruktur wie möglich gegen nicht autorisierten Traffic und potenzielle Angriffe aus dem Internet zu schützen, z. B. volumenbasierte DoS-Angriffe.
  • Kein inhärentes gegenseitiges Vertrauen zwischen Diensten: Nur authentifizierte, vertrauenswürdige und speziell autorisierte Anrufer oder Dienste können auf einen anderen Dienst zugreifen. Dadurch wird verhindert, dass Angreifer nicht vertrauenswürdigen Code für den Zugriff auf einen Dienst verwenden. Wird ein Dienst manipuliert, können Angreifer keine Aktionen ausführen, die es ihnen ermöglichen, ihren Einflussbereich zu erweitern. Das fehlende gegenseitige Vertrauen in Kombination mit einer detaillierten Zugriffssteuerung hilft, den Umfang einer Manipulation einzuschränken.
  • Vertrauenswürdige Maschinen, auf denen Code bekannter Herkunft ausgeführt wird: Dienstidentitäten sind darauf beschränkt, nur autorisierten Code und Konfigurationen zu verwenden und nur in autorisierten, verifizierten Umgebungen ausgeführt zu werden.
  • Konsistente Richtlinienerzwingung bei allen Diensten: Eine konsistente Richtlinienerzwingung sorgt dafür, dass Zugriffsentscheidungen dienstübergreifend funktionieren. Sie können beispielsweise eine Richtlinienerzwingung erstellen, die Anfragen für den Zugriff auf Nutzerdaten überprüft. Für den Zugriff auf den Dienst muss ein autorisierter Endnutzer eine validierte Anfrage enthalten und ein Administrator muss eine geschäftliche Begründung angeben.
  • Einfacher, automatisierter und standardisierter Rollout von Änderungen: Änderungen an der Infrastruktur können einfach auf ihre Auswirkungen auf die Sicherheit überprüft werden, und Sicherheits-Patches können mit geringen Auswirkungen auf die Produktion ausgerollt werden.
  • Isolation von Arbeitslasten, die dasselbe Betriebssystem verwenden: Wenn ein Dienst kompromittiert wird, kann dies nicht die Sicherheit einer anderen Arbeitslast beeinträchtigen, die auf demselben Host läuft. Dadurch wird der Umfang einer möglichen Manipulation eingeschränkt.
  • Vertrauenswürdige Hardware und Attestierung: Mit einem Hardware-Root of Trust wird sichergestellt, dass nur bekannter und autorisierter Code (von der Firmware bis zum Nutzermodus) auf dem Host ausgeführt wird, bevor Arbeitslasten darauf geplant werden.

Diese Vorteile bedeuten, dass Container und die in unserer Cloud-Architektur ausgeführten Mikrodienste bereitgestellt und nebeneinander ausgeführt werden sowie miteinander kommunizieren können, ohne die Sicherheit unserer Infrastruktur zu schwächen. Darüber hinaus sind einzelne Mikrodienstentwickler nicht mit den Sicherheits- und Implementierungsdetails der zugrunde liegenden Infrastruktur belastet.

BeyondProd-Sicherheitsdienste

Wir haben mehrere BeyondProd-Sicherheitsdienste entworfen und entwickelt, um die unter BeyondProd-Vorteile beschriebenen Vorteile zu schaffen. In den folgenden Abschnitten werden diese Sicherheitsdienste beschrieben.

Google Front End für Edge-Netzwerkschutz

Google Front End (GFE) bietet Schutz des Netzwerks am Rand. GFE beendet die Verbindung vom Endnutzer und bietet einen zentralen Punkt zur Umsetzung der Best Practices für TLS.

Obwohl unser Schwerpunkt nicht mehr auf perimeterbasierter Sicherheit liegt, ist das GFE nach wie vor ein wichtiger Bestandteil unserer Strategie zum Schutz interner Dienste vor DoS-Angriffen. GFE ist der erste Einstiegspunkt für einen Nutzer, der eine Verbindung zur Google-Infrastruktur herstellt. Nachdem ein Nutzer eine Verbindung zu unserer Infrastruktur hergestellt hat, ist GFE auch für das Load-Balancing und ggf. für die Umleitung des Traffics unter den Regionen verantwortlich. GFE ist der Edge-Proxy, der den Traffic zum richtigen Mikrodienst weiterleitet.

Kunden-VMs in Google Cloud registrieren sich nicht bei GFE. Stattdessen registrieren sie sich beim Cloud Front End, einer speziellen Konfiguration von GFE, die den Compute Engine-Netzwerkstack verwendet. Mit Cloud Front End können Kunden-VMs über ihre öffentliche oder private IP-Adresse direkt auf einen Google-Dienst zugreifen. (Private IP-Adressen sind nur verfügbar, wenn privater Google-Zugriff aktiviert ist.)

Application Layer Transport Security für Vertrauen unter den Diensten

Application Layer Transport Security (ALTS) trägt dazu bei, dass es kein inhärentes gegenseitiges Vertrauen zwischen den Diensten gibt. ALTS wird für die Authentifizierung eines Remote-Prozeduraufrufs (RPC), für die Verschlüsselung des Traffics und für Dienstidentitäten verwendet. ALTS ist ein gegenseitiges Authentifizierungs- und Transportverschlüsselungssystem für Dienste in der Infrastruktur von Google. Im Allgemeinen sind Identitäten an Dienste gebunden und nicht an einen bestimmten Servernamen oder Host. Diese Bindung sorgt für nahtlose Replikation, Load-Balancing und Neuplanung von Mikrodiensten auf allen Hosts.

Jede Maschine hat ALTS-Anmeldedaten, die mit dem Hostintegritätssystem bereitgestellt werden, und nur entschlüsselt werden können, wenn der Hostintegritätssystem bestätigt hat, dass Secure Boot erfolgreich war. Die meisten Google-Dienste werden als Mikrodienste zusätzlich zu Borg ausgeführt. Diese Mikrodienste haben jeweils ihre eigene ALTS-Identität. Borg Prime, , der zentrale Controller von Borg, vergibt diese Anmeldedaten für ALTS-Mikrodienste an Arbeitslasten auf der Grundlage der Identität des Mikrodienstes. Die ALTS-Anmeldedaten auf Maschinenebene bilden den sicheren Kanal zur Bereitstellung von Anmeldedaten für Mikrodienste. Somit können nur Maschinen, bei denen der Bootvorgang der Hostintegrität erfolgreich bestanden wurde, Mikrodienstarbeitslasten hosten. Weitere Informationen zu ALTS-Anmeldedaten finden Sie unter Arbeitslastzertifikate.

Binärautorisierung für Borg für die Codeherkunft

Binärautorisierung für Borg (BAB) bietet eine Überprüfung der Codeherkunft. BAB ist eine Erzwingungsprüfung zur Bereitstellungszeit, mit der sichergestellt wird, dass der Code den internen Sicherheitsanforderungen entspricht, bevor der Code bereitgestellt wird. So wird beispielsweise im Rahmen der BAB-Durchsetzungskontrolle sichergestellt, dass Änderungen von einem zweiten Entwickler überprüft werden, bevor der Code an unser Quellcode-Repository gesendet wird, und dass die Binärdateien nachweislich auf einer speziellen Infrastruktur erstellt werden. In unserer Infrastruktur beschränkt BAB die Bereitstellung von nicht autorisierten Mikrodiensten.

Hostintegrität für maschinelles Vertrauen

Hostintegrität überprüft die Integrität der Host-System-Software durch einen sicheren Boot-Prozess und wird durch einen Hardware-Root-of-Trust-Sicherheitschip (Titan genannt) unterstützt, wenn diese unterstützt wird. Zu den Hostintegritätsprüfungen gehören die Verifizierung digitaler Signaturen im BIOS, Baseboard-Management-Controller (BMC) , Bootloader- und Betriebssystem-Kernel. Falls unterstützt, können Hostintegritätsprüfungen Nutzermoduscode und Peripheriefirmware (z. B. NICs) umfassen. Zusätzlich zur digitalen Signaturprüfung sorgt die Integrität der Hosts dafür, dass jeder Host die beabsichtigte Version dieser Softwarekomponenten ausführt.

Tickets für die Dienstzugriffsverwaltung und Endnutzerkontexte für die Richtlinienerzwingung

Dienstzugriffsverwaltung und Tickets für den Endnutzerkontext sorgen für eine konsistente Durchsetzung der Richtlinien bei allen Diensten.

Die Dienstzugriffsrichtlinie schränkt den Zugriff auf Daten durch Dienste ein. Wenn ein RPC von einem Dienst an einen anderen gesendet wird, werden anhand der Dienstzugriffsverwaltung die Autorisierungs- und Prüfrichtlinien definiert, die Dienste für den Zugriff auf die Daten des empfangenden Dienstes benötigen. So wird der Zugriff auf Daten eingeschränkt, die erforderlichen minimalen Zugriffsberechtigungen werden erteilt und es wird angegeben, wie dieser Zugriff geprüft werden kann. In der Google-Infrastruktur beschränkt die Dienstzugriffsverwaltung den Zugriff eines Mikrodienstes auf die Daten eines anderen Mikrodienstes und ermöglicht globale Analysen der Zugriffssteuerung.

Tickets für den Endnutzerkontext werden von einem Endnutzer-Authentifizierungsdienst ausgestellt und stellen Dienste mit einer Nutzeridentität bereit, die von ihrer Dienstidentität getrennt ist. Diese Tickets sind integritätsgeschützte, zentral ausgestellte, weiterleitbare Anmeldedaten, die die Identität eines Endnutzers belegen, der eine Anfrage an den Dienst gestellt hat. Diese Tickets reduzieren die Notwendigkeit des Vertrauens zwischen Diensten, da Peer-Identitäten, die ALTS verwenden, nicht ausreichend sind, um Zugriff zu gewähren, wenn solche Zugriffsentscheidungen in der Regel auch auf der Identität des Endnutzers beruhen.

Borg-Tools für das automatische Rollout von Änderungen und Skalierbarkeit

Borg-Tools für Blau/Grün-Bereitstellungen bieten einen einfachen, automatisierten und standardisierten Roll-out von Änderungen. Eine Blau/Grün-Bereitstellung ist eine Möglichkeit, eine Änderung an einer Arbeitslast durchzuführen, ohne den eingehenden Traffic zu beeinträchtigen. Für die Endnutzer entsteht also beim Zugriff auf die Anwendung keine Ausfallzeit.

Ein Borg-Job ist eine einzelne Instanz eines Mikrodienstes, der einen Teil einer Anwendung ausführt. Jobs werden skaliert, um die Last zu bewältigen. Neue Jobs werden bereitgestellt, wenn die Last zunimmt, und vorhandene Jobs werden beendet, wenn die Last abnimmt.

Borg-Tools sind für die Migration ausgeführter Arbeitslasten verantwortlich, wenn Wartungsaufgaben ausgeführt werden. Wenn ein neuer Borg-Job bereitgestellt wird, verschiebt ein Load-Balancer den Traffic schrittweise von einem vorhandenen Job zum neuen. So kann ein Mikrodienst ohne Ausfallzeit aktualisiert werden und dem Nutzer fällt dies überhaupt nicht auf.

Wir verwenden dieses Tool auch, um Dienste zu aktualisieren, wenn neue Features hinzugefügt werden, und um wichtige Sicherheitsupdates ohne Ausfallzeiten anzuwenden (z. B. Heartbleed und Spectre/Meltdown). Bei Änderungen, die Auswirkungen auf unsere Infrastruktur haben, verwenden wir eine Live-Migration von Kunden-VMs, um sicherzustellen, dass die Arbeitslasten nicht betroffen sind.

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

gVisor-Kernel zur Isolation von Arbeitslasten

Der gVisor-Kernel ermöglicht die Isolierung zwischen Arbeitslasten, die sich ein Betriebssystem teilen. gVisor verwendet einen Nutzerbereichs-Kernel, um Syscalls abzufangen und zu verarbeiten, wodurch die Interaktion mit dem Host und die potenzielle Angriffsfläche reduziert werden. Dieser Kernel bietet die meisten Funktionen, die zum Ausführen einer Anwendung erforderlich sind, und schränkt die Oberfläche des Host-Kernels ein, auf die die Anwendung zugreifen kann. gVisor ist eines von mehreren Tools, mit denen wir interne Arbeitslasten und Arbeitslasten von Google Cloud-Kunden isolieren können, die auf demselben Host ausgeführt werden. Weitere Informationen zu anderen Sandbox-Tools finden Sie unter Code-Sandboxing.

Nutzerdaten mit BeyondProd schützen

In diesem Abschnitt wird beschrieben, wie BeyondProd-Dienste zusammenwirken, um Nutzerdaten in unserer Infrastruktur zu schützen. In den folgenden Abschnitten werden zwei Beispiele beschrieben:

  • Zugriff auf Nutzerdatenanfragen von der Erstellung bis zur Zustellung an ihrem Ziel.
  • Eine Codeänderung von der Entwicklung bis zur Produktion.

Nicht alle der aufgeführten Technologien werden in allen Teilen unserer Infrastruktur verwendet. Dies hängt von den Diensten und Arbeitslasten ab.

Zugriff auf Nutzerdaten

Das nachstehende Diagramm zeigt den Prozess, mit dem unsere Infrastruktur prüft, ob ein Nutzer auf Nutzerdaten zugreifen darf.

Die cloudnativen Sicherheitskontrollen von Google greifen auf Nutzerdaten zu.

Zum Zugriff auf Nutzerkonten gehen Sie so vor:

  1. Ein Nutzer sendet eine Anfrage an GFE.
  2. GFE beendet die TLS-Verbindung und leitet die Anfrage mithilfe von ALTS an das Front-End des entsprechenden Dienstes weiter.
  3. Das Front-End der Anwendung authentifiziert die Anfrage des Nutzers mithilfe eines zentralen Endnutzer-Authentifizierungsdienstes (EUA-Dienst) und erhält im Erfolgsfall ein kurzlebiges, kryptografisches Ticket für den Endnutzerkontext.
  4. Das Front-End der Anwendung führt über ALTS einen RPC zum Back-End eines Speicherdienstes aus und leitet das Ticket mit der Back-End-Anfrage weiter.
  5. Der Back-End-Dienst verwendet die Dienstzugriffsverwaltung, um sicherzustellen, dass die folgenden Kriterien erfüllt sind:
    • Das Front-End wird mit einem gültigen, nicht widerrufenen Zertifikat authentifiziert. Diese Prüfung bedeutet, dass sie auf einem vertrauenswürdigen Host ausgeführt wird und BAB-Prüfungen erfolgreich waren.
    • Die ALTS-Identität des Front-End-Dienstes ist autorisiert, Anfragen an den Back-End-Dienst zu senden und ein EUC-Ticket weiterzuleiten.
    • Das Ticket für den Endnutzerkontext ist gültig.
    • Der im EUC-Ticket aufgeführte Nutzer ist berechtigt, auf die angefragten Daten zuzugreifen.

Schlägt eine dieser Prüfungen fehl, wird die Anfrage abgelehnt.

Sind diese Prüfungen bestanden, werden die Daten an das autorisierte Front-End der Anwendung zurückgegeben und dem autorisierten Nutzer bereitgestellt.

In vielen Fällen gibt es eine Kette von Back-End-Aufrufen und jeder Vermittlungsdienst führt zu eingehenden RPCs eine Dienstzugriffsprüfung durch. Das EUC-Ticket wird zusammen mit ausgehenden RPCs weitergeleitet.

Weitere Informationen zur Weiterleitung von Traffic innerhalb unserer Infrastruktur finden Sie unter Weiterleitung von Traffic.

Änderungen am Code vornehmen

Das folgende Diagramm zeigt, wie eine Codeänderung bereitgestellt wird.

Wie Codeänderungen vorgenommen werden.

Führen Sie die folgenden Schritte aus, um eine Codeänderung vorzunehmen:

  1. Ein Entwickler nimmt eine Änderung an einem durch BAB geschützten Mikrodienst vor. Die Änderung wird an unser zentrales Code-Repository gesendet, das das Code Review erzwingt. Nach der Genehmigung wird die Änderung an das zentrale, vertrauenswürdige Build-System gesendet, das ein Paket mit einem signierten verifizierbaren Build-Manifest-Zertifikat erstellt.

  2. Zur Bereitstellungszeit überprüft die BAB, ob diesem Prozess eine Validierung des signierten Zertifikats aus der Build-Pipeline gefolgt ist.

  3. Borg verarbeitet alle Arbeitslastaktualisierungen mithilfe eines Zuverlässigkeitsmodells, das eine minimale Unterbrechung der Dienste sicherstellt, unabhängig davon, ob es sich um einen routinemäßigen Roll-Out oder einen Notfall-Sicherheitspatch handelt.

  4. GFE verschiebt Traffic mithilfe des Load-Balancings in die neue Bereitstellung und sorgt so für die Kontinuität von Vorgängen.

Weitere Informationen zu diesem Verfahren finden Sie unter Entwicklung und Produktion.

Alle Arbeitslasten müssen isoliert werden. Wenn die Arbeitslast weniger vertrauenswürdig ist, da der Quellcode nicht von Google stammt, kann er in einer von gVisor geschützten Umgebung bereitgestellt werden oder es können weitere Isolationsebenen zur Anwendung kommen. Diese Isolation unterstützt einen Angreifer, der die Anwendung manipuliert.

Auswirkungen der cloudnativen Sicherheit

In den folgenden Abschnitten werden Aspekte der herkömmlichen Infrastruktursicherheit und ihrer Gegenstücke in einer cloudnativen Architektur verglichen.

Anwendungsarchitektur

Ein eher traditionelles Sicherheitsmodell, das auf perimeterbasierte Sicherheit ausgerichtet ist, kann eine cloudnative Architektur nicht allein schützen. Bisher monolithische Anwendungen nutzten eine dreistufige Architektur und wurden in privaten Rechenzentren bereitgestellt, die über ausreichende Kapazitäten verfügten, um die Spitzenlast für kritische Ereignisse zu bewältigen. Anwendungen mit bestimmten Hardware- oder Netzwerkanforderungen wurden absichtlich auf bestimmten Maschinen bereitgestellt, die in der Regel feste IP-Adressen haben. Roll-outs erfolgten selten, in großem Umfang und waren schwer zu koordinieren, da die resultierenden Änderungen gleichzeitig viele Teile der Anwendung betrafen. Dies führte zu sehr langlebigen Anwendungen, die weniger häufig aktualisiert wurden und bei denen Sicherheitspatches normalerweise nicht so oft zur Anwendung kamen.

In einem cloudnativen Modell müssen Anwendungen jedoch zwischen verschiedenen Umgebungen portierbar sein, da sie in öffentlichen Clouds, privaten Rechenzentren oder in Diensten von Drittanbietern gehostet werden können. Daher wird eine monolithische Anwendung, die in Mikrodienste aufgeteilt ist, anstelle von monolithischen Anwendungen ideal für Cloud-Umgebungen. Container entkoppeln die Binärdateien, die Ihre Anwendung benötigt, vom zugrunde liegenden Hostbetriebssystem und machen Anwendungen leichter übertragbar. Unsere Container sind unveränderlich, d. h. sie werden nach der Bereitstellung nicht mehr geändert. Stattdessen werden sie häufig neu erstellt und neu bereitgestellt.

Da Container häufig neu gestartet, gestoppt oder neu geplant werden, werden Hardware und Netzwerke häufiger wiederverwendet und gemeinsam genutzt. Mit einem standardisierten Erstellungs- und Verteilungsprozess gestaltet sich der teamübergreifende Entwicklungsprozess einheitlicher, obwohl die Teams die Entwicklung ihrer Mikrodienste selbstständig verwalten. Somit können Sicherheitsfragen (z. B. Sicherheitsüberprüfungen, Codescans und Verwaltung von Sicherheitslücken) frühzeitig in Entwicklungszyklen berücksichtigt werden.

Service Mesh

Durch das Einrichten einer gemeinsam genutzten und sicheren Infrastruktur, die alle Entwickler verwenden, wird der Aufwand für Entwickler, die gemeinsamen Sicherheitsanforderungen zu kennen und zu implementieren, minimiert. Die Sicherheitsfunktion sollte nur eine minimale oder keine Integration in jede Anwendung erfordern. Stattdessen wird sie als Fabric bereitgestellt, das alle Mikrodienste umfasst und miteinander verbindet. Dies wird normalerweise als Service Mesh bezeichnet. Das bedeutet auch, dass die Sicherheit getrennt von den normalen Entwicklungs- oder Bereitstellungsaktivitäten verwaltet und umgesetzt werden kann.

Ein Service Mesh ist ein freigegebenes Fabric auf der Infrastrukturebene, das alle Mikrodienste umfasst und verbindet. Ein Service Mesh ermöglicht eine Dienst-zu-Dienst-Kommunikation, über die der Traffic gesteuert, Richtlinien angewendet und zentralisiertes Monitoring für Dienstaufrufe bereitgestellt werden kann.

Zero-Trust-Sicherheit

Bei einem herkömmlichen Sicherheitsmodell, das private Rechenzentren verwendet, sind die Anwendungen einer Organisation von einer Firewall abhängig, um Arbeitslasten vor externen netzwerkbasierten Bedrohungen zu schützen.

Mit einem Zero-Trust-Sicherheitsmodell gibt es keine Firewalls. Stattdessen sorgen andere Kontrollen wie die Identität, Authentifizierung und Autorisierung von Arbeitslasten für den Schutz von Mikrodiensten, da interne oder externe Verbindungen vor der Transaktion validiert werden. Wenn Sie die Abhängigkeit von Firewalls oder netzwerkbasierten Steuerelementen entfernen, können Sie eine Segmentierung auf Mikrodienstebene vornehmen, ohne dass zwischen den Diensten ein inhärentes Vertrauen besteht. Bei der Segmentierung auf Mikrodienstebene kann der Traffic für verschiedene Steuerelemente unterschiedliche Vertrauensstufen haben. So vergleichen Sie nicht mehr nur internen mit externem Traffic.

Gemeinsame Sicherheitsanforderungen, die in Dienststacks eingebunden sind

Bei einem herkömmlichen Sicherheitsmodell müssen Anwendungen unabhängig von anderen Diensten ihre eigenen Sicherheitsanforderungen erfüllen. Zu diesen Anforderungen gehören die Identitätsverwaltung, die TLS-Beendigung sowie die Datenzugriffsverwaltung. Dies kann zu inkonsistenten Implementierungen oder nicht berücksichtigten Sicherheitsproblemen führen, da diese Probleme an verschiedensten Stellen behoben werden müssen, was die Problembehebung schwieriger macht.

In einer cloudnativen Architektur werden Komponenten häufiger für verschiedene Dienste wiederverwendet. Nadelöhre ermöglichen die konsistente Durchsetzung von Richtlinien über Dienste hinweg. Unterschiedliche Richtlinien können mithilfe verschiedener Sicherheitsdienste erzwungen werden. Anstatt dass wichtige Sicherheitsdienste für jede Anwendung separat implementiert werden müssen, können Sie die verschiedenen Richtlinien in separate Mikrodienste aufteilen. Sie können beispielsweise eine Richtlinie erstellen, um den autorisierten Zugriff auf Nutzerdaten sicherzustellen, und eine weitere Richtlinie, um die Verwendung aktueller TLS-Chiffresammlungen zu gewährleisten.

Standardisierte Prozesse mit häufigeren Roll-outs

Bei einem herkömmlichen Sicherheitsmodell gibt es in begrenztem Umfang gemeinsam genutzte Dienste und der Code wird häufig dupliziert und mit der lokalen Entwicklung gekoppelt. Eine begrenzte Freigabe erschwert die Auswirkungen einer Änderung und darüber, wie sich die Änderung auf viele Teile einer Anwendung auswirken kann. Daher sind Roll-outs selten und schwer zu koordinieren. Um eine Änderung vorzunehmen, mussten Entwickler unter Umständen jede Komponente direkt aktualisieren und beispielsweise eine SSH-Verbindung zu jeder virtuellen Maschine herstellen, um eine Konfiguration zu aktualisieren. Insgesamt kann dies zu extrem langlebigen Anwendungen führen.

Aus der Sicherheitsperspektive ist es schwieriger, den Code zu überprüfen, da er oft doppelt vorhanden ist, und es ist noch schwieriger, sicherzustellen, dass eine Schwachstelle überall behoben wird, wenn sie behoben ist.

In einer cloudnativen Architektur sind Roll-outs häufig und standardisiert. Dieser Prozess ermöglicht ein Shift-Left-Modell im Lebenszyklus der Softwareentwicklung. Das Shift-Left-Modell bezieht sich auf die Verschiebung von Schritten zu einem früheren Zeitpunkt im Lebenszyklus der Softwareentwicklung, was Schritte wie Code, Build, Test, Validierung und Bereitstellung umfassen kann. Das Shift-Left-Modell ermöglicht eine einfachere und konsistentere Erzwingung der Sicherheit, einschließlich der regelmäßigen Durchführung von Sicherheitspatches.

Änderung an BeyondProd vornehmen

Die Umstellung bei Google auf BeyondProd erforderte Änderungen in zwei Hauptbereichen: an unserer Infrastruktur und an unserem Entwicklungsprozess. Wir haben diese Änderungen gleichzeitig vorgenommen, aber Sie können sie unabhängig voneinander beheben, wenn Sie in Ihrer Umgebung etwas ähnliches einrichten möchten.

Unsere Infrastruktur ändern

Das Ziel ist die Automatisierung der Sicherheit in unserer gesamten Infrastruktur, da wir der Meinung sind, dass Sicherheit auf die gleiche Weise skaliert werden sollte wie die Dienste skalieren. Dienste müssen standardmäßig sicher und in Ausnahmefällen unsicher sein. Direkte menschliche Eingriffe an unserer Infrastruktur sollten selten und nicht routinemäßig erfolgen und die Eingriffe sollten überprüfbar sein. Wir können einen Dienst dann basierend auf dem Code und der Konfiguration authentifizieren, die für den Dienst bereitgestellt wurden, und nicht auf Grundlage der Personen, die den Dienst bereitgestellt haben.

Wir haben zuerst eine solide Grundlage für die Dienstidentität, Authentifizierung und Autorisierung geschaffen. Ein Mikrodienst verwendet eine Dienstidentität , um sich bei anderen Diensten zu authentifizieren, die in der Infrastruktur ausgeführt werden. Dank der vertrauenswürdigen Dienstidentitäten konnten wir übergeordnete Sicherheitsfunktionen implementieren, die von der Validierung dieser Dienstidentitäten abhängig sind, z. B. Dienstzugriffsverwaltung und Tickets für Endnutzerkontexte. Zur Vereinfachung dieser Umstellung sowohl für neue als auch für bestehende Dienste wurde ALTS zuerst als Bibliothek mit einem einzelnen Daemon als Hilfe bereitgestellt. Dieser Daemon wurde auf dem Host ausgeführt, der von jedem Dienst aufgerufen wurde. Im Laufe der Zeit entwickelte sich daraus mithilfe von Dienstanmeldedaten eine Bibliothek. Die ALTS-Bibliothek wurde nahtlos in die zentrale RPC-Bibliothek eingebunden. Dank dieser Integration konnte eine breite Akzeptanz erreicht werden, ohne dass die einzelnen Entwicklerteams in erheblichem Maße belastet wurden. Der Roll-out von ALTS war eine Voraussetzung für den Roll-out der Dienstzugriffsverwaltung und der Tickets für den Endnutzerkontext.

Unsere Entwicklungsprozesse ändern

Für Google war es entscheidend, einen stabilen Prozess für die Entwicklung und Codeüberprüfung einzurichten, um die Integrität der ausgeführten Dienste sicherzustellen. Wir haben einen zentralen Build-Prozess erstellt, mit dem wir Anforderungen wie die Überprüfung von Code durch zwei Personen und automatisierte Tests bei der Entwicklung und Bereitstellung durchsetzen konnten. Weitere Informationen zum Bereitstellen finden Sie unter Binärautorisierung für Borg.

Nachdem wir die Grundlagen geschaffen hatten, beschäftigten wir uns mit der Problematik, dass externer, nicht vertrauenswürdiger Code in unserer Umgebung ausgeführt werden sollte. Um dieses Ziel zu erreichen, begannen wir mit dem Ausführen in einer Sandbox – zuerst mit ptrace und später mit gVisor. Ebenso haben sich durch Blau/Grün-Bereitstellungen erhebliche Vorteile in Bezug auf die Sicherheit (z. B. Patching) und Zuverlässigkeit ergeben.

Wir stellten schnell fest, dass es einfacher war, wenn ein Dienst mit dem Logging von Richtlinienverstößen begann, anstatt bei Verstößen zu blockieren. Dieser Ansatz brachte zwei Vorteile mit sich:

  • Die Dienstinhaber erhielten die Gelegenheit, die Änderung zu testen und die eventuell vorhandenen Auswirkungen zu beurteilen, die der Umstieg auf eine cloudnative Umgebung auf ihren Dienst hätte.
  • So konnten wir Fehler beheben und zusätzliche Funktionen ermitteln, die wir für die Teams der Dienste möglicherweise bereitstellen müssen.

Wenn für einen Dienst beispielsweise die BAB eingerichtet wird, aktivieren die Dienstinhaber den Modus „Nur Prüfen“. So können sie Code oder Workflows ermitteln, die nicht ihren Anforderungen entsprechen. Wenn die Dienstinhaber die im Modus „Nur Prüfen“ gekennzeichneten Probleme behoben haben, wechseln sie in den Erzwingungsmodus. In gVisor haben wir die Arbeitslasten hierfür zuerst in einer Sandbox ausgeführt, auch wenn bei den Sandbox-Funktionen Kompatibilitätslücken bestanden. Dann haben wir diese Lücken systematisch abgearbeitet, um die Sandbox zu verbessern.

Nächste Schritte