BeyondProd: Ein neuer Ansatz für cloudnative Sicherheit

Von Google wurden mehrere Whitepapers veröffentlicht, in denen intern entwickelte Projekte erläutert werden, die zur Verbesserung der Sicherheit beitragen. BeyondProd erinnert bewusst an die Konzepte von BeyondCorp. So wie ein Perimetersicherheitsmodell nicht mehr für Endnutzer funktioniert, funktioniert es auch nicht mehr für Mikrodienste. Das ursprüngliche Whitepaper zu BeyondCorp wurde also angepasst, da grundlegende Annahmen dieses Modells nicht mehr gelten: Der Perimeter ist nicht mehr nur der physische Standort des Unternehmens (Rechenzentrum) und was innerhalb des Perimeters liegt, ist kein geschützter und sicherer Ort für Computer und Unternehmensanwendungen (Mikrodienste) mehr.

In diesem Whitepaper finden Sie ausführliche Informationen dazu, wie mehrere Teile der Infrastruktur von Google in Verbindung miteinander für den Schutz von Arbeitslasten sorgen – in einer Architektur, die jetzt als „cloudnativ“ bezeichnet wird. Eine Übersicht über die Sicherheit von Google finden Sie im Whitepaper zur Entwicklung der Sicherheitsinfrastruktur.

Die Inhalte entsprechen den zum Dezember 2019 vorliegenden Informationen. Dieses Whitepaper gibt damit den Stand zu dem Zeitpunkt wieder, als es verfasst wurde. Die Sicherheitsrichtlinien und -systeme von Google können sich in Zukunft ändern, da wir den Schutz für unsere Nutzer kontinuierlich verbessern.

Glossar

In diesem Dokument werden folgende Definitionen verwendet:

  • Ein Mikrodienst dient zur Trennung einzelner Aufgaben, die eine Anwendung ausführen muss, in separate Dienste, die jeweils unabhängig voneinander entwickelt und verwaltet werden können – mit eigener API, Skalierung, Kontingentverwaltung und eigenem Rollout. In einer moderneren Architektur kann eine Anwendung, z. B. eine Website, als eine Sammlung von Mikrodiensten anstatt als ein einzelner monolithischer Dienst ausgeführt werden. Mikrodienste sind unabhängig, modular, dynamisch und flüchtig. Sie können auf mehrere Hosts, Cluster oder sogar Clouds verteilt werden.

  • Eine Arbeitslast ist eine eindeutige Aufgabe, die von einer Anwendung abgearbeitet wird. In einer Mikrodienstarchitektur kann eine Arbeitslast aus einem oder mehreren Mikrodiensten bestehen.

  • Ein Job ist eine einzelne Instanz eines Mikrodienstes, der einen Teil einer Anwendung ausführt.

  • Ein Mikrodienst verwendet eine Dienstidentität, um sich bei anderen Diensten zu authentifizieren, die in der Infrastruktur ausgeführt werden.

  • Ein Service Mesh ist eine Infrastrukturebene für die Dienst-zu-Dienst-Kommunikation. Damit können der Traffic gesteuert, Richtlinien angewendet und zentralisiertes Monitoring für Dienstaufrufe bereitgestellt werden. Kommt eine Mikrodienstarchitektur zum Einsatz, werden die einzelnen Dienste bei der Umsetzung dieser Steuerung entlastet und eine Vielzahl von Mikrodiensten kann einfacher und zentralisiert verwaltet werden.

Zusammenfassung für CIOs

  • Über die Infrastruktur von Google werden Arbeitslasten als einzelne Mikrodienste in Containern bereitgestellt und diese Arbeitslasten mithilfe des Container-Orchestrierungssystems Borg verwaltet. Dies dient als Inspiration und Vorlage für das, was heute als „cloudnative“ Architektur bekannt ist.

  • Bei der Entwicklung der Infrastruktur von Google wurde bewusst auf Sicherheit Wert gelegt; sie wurde nicht einfach nachträglich hinzugefügt. Unsere Infrastruktur setzt nicht voraus, dass sich die Dienste vertrauen.

  • Google schützt seine Mikrodienste mit einer Initiative namens BeyondProd. Bei diesem Schutz wird auch berücksichtigt, wie Code geändert und auf Nutzerdaten in Mikrodiensten zugegriffen wird. BeyondProd greift auf Konzepte wie wechselseitig authentifizierte Dienstendpunkte, Transportsicherheit, Edge-Beendigung mit globalem Load-Balancing und DoS-Schutz (Denial of Service), End-to-End-Codeherkunft und das Ausführen von Laufzeiten in einer Sandbox zurück.

  • Der Umstieg von einem herkömmlichen Sicherheitsmodell auf ein cloudnatives Sicherheitsmodell erforderte Änderungen in zwei zentralen Bereichen, nämlich an unserer Infrastruktur und unserem Entwicklungsprozess. Die Einbindung gemeinsam genutzter Komponenten in einem gemeinsam genutzten Fabric, das alle Mikrodienste umfasst und miteinander verbindet, erleichtert den Rollout von Änderungen und sorgt für allgemeine Sicherheit bei allen Diensten. Dieses Fabric wird auch Service Mesh genannt.

Motivation

Google hat auf Container und Containerorchestrierung umgestellt, um die Ressourcennutzung zu verbessern, hochverfügbare Anwendungen zu erstellen und die Arbeit für Google-Entwickler zu vereinfachen. Wir hatten einen weiteren Grund für den Wechsel zu einer Containerinfrastruktur: Wir wollten unsere Sicherheitskontrollen an unsere Architektur anpassen. Es wurde offensichtlich, dass ein perimeterbasiertes Sicherheitsmodell nicht sicher genug war. Würde ein Angreifer den Perimeter überwinden, könnte er sich innerhalb des Netzwerks frei bewegen. Wir haben zwar erkannt, dass wir in unserer gesamten Infrastruktur strengere Sicherheitskontrollen benötigen, wollten es Google-Entwicklern aber auch erleichtern, sichere Anwendungen zu schreiben und bereitzustellen, ohne selbst Sicherheitsfunktionen implementieren zu müssen.

Die Umstellung von monolithischen Anwendungen auf dezentrale Mikrodienste, die über Container mithilfe eines Orchestrierungssystems bereitgestellt wurden, brachte greifbare operative Vorteile mit sich: eine einfachere Verwaltung und Skalierbarkeit. Diese cloudnative Architektur erforderte ein anderes Sicherheitsmodell mit verschiedenen Tools, um Bereitstellungen zu schützen, die den Vorteilen bei der Verwaltung und Skalierbarkeit von Mikrodiensten gerecht wurden.

In diesem Dokument wird beschrieben, wie cloudnative Sicherheit bei Google umgesetzt wird. Wir verwenden hierfür den Begriff BeyondProd, der Folgendes beinhaltet: Was die Umstellung auf ein cloudnatives System für die Sicherheit bedeutet, Sicherheitsgrundsätze für cloudnative Sicherheit, auf die Erfüllung dieser Anforderungen ausgelegte Systeme und einige Tipps, wie Sie selbst eine ähnliche Änderung vornehmen können.

Cloudnative Sicherheit bei Google

Containerisierte Mikrodienste

Von Beginn an entschied sich Google bewusst dafür, zum Aufbau der Kapazität seines Rechenzentrums auf kostengünstige Standardserver zu setzen, statt in teurere hochverfügbare Hardware zu investieren. Die grundlegende Philosophie für unsere Zuverlässigkeit war und ist, dass jeder einzelne Teil eines Systems ausfallen kann, ohne die Verfügbarkeit der für den Nutzer sichtbaren Dienste zu beeinträchtigen. Zum Erreichen dieser Verfügbarkeit mussten redundante Instanzen von Diensten ausgeführt werden, damit einzelne Fehler nicht zu Ausfällen führten. Eine Folge dieser Philosophie war die Entwicklung von Containern, Mikrodiensten und einer Containerorchestrierung, damit die Bereitstellung dieser hochredundanten und verteilten Systeme auf skalierbare Weise erfolgen kann.

Eine Containerinfrastruktur bedeutet, dass jede Arbeitslast als eigene Gruppe nicht veränderbarer, beweglicher und planbarer Container bereitgestellt wird. Um diese Container intern verwalten zu können, haben wir ein Container-Orchestrierungssystem mit dem Namen Borg1 entwickelt, das wir auch heute noch zum Bereitstellen mehrerer Milliarden Container pro Woche verwenden.

Mit Containern war es einfacher, Arbeitslasten als Behälter auf mehrere Maschinen zu verteilen und neu zu planen. Mikrodienste erleichterten die Entwicklung und das Debugging verschiedener Teile einer Anwendung. Werden sie in Kombination verwendet, ermöglichen Mikrodienste und Container die Aufteilung von Arbeitslasten in kleinere, besser verwaltbare Einheiten zur Wartung und Auffindbarkeit. Der Umstieg auf eine Containerinfrastruktur mit einer Mikrodienstarchitektur wird als „cloudnativer“ Ansatz bezeichnet. Dienste werden in durch Borg bereitgestellten Containern ausgeführt. Bei dieser Architektur werden Arbeitslasten nach Bedarf skaliert. Wenn für eine bestimmte Arbeitslast eine hohe Nachfrage besteht, können mehrere Maschinen Kopien desselben Dienstes ausführen, um die erforderliche Arbeitslast zu bewältigen.

Google zeichnet sich dadurch aus, dass wir das Thema Sicherheit bei der Weiterentwicklung unserer Architektur immer berücksichtigen. Das neuere Konzept der cloudnativen Sicherheit ist vergleichbar mit dem Ansatz, den Google seit vielen Jahren zur Sicherung der Infrastruktur verwendet. 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.

In eine cloudnativen Architektur migrieren

Moderne Sicherheitsarchitekturen haben sich über ein herkömmliches perimeterbasiertes Sicherheitsmodell hinaus entwickelt, bei dem eine Firewall den Perimeter schützt und allen Nutzern oder Diensten darin vollständig vertraut wird. BeyondCorp war eine Reaktion auf eine Veränderung bei der Arbeitsweise des modernen Nutzers in einem Unternehmen. Heute sind Nutzer mobil und arbeiten häufig außerhalb des traditionellen Sicherheitsperimeters einer Organisation, z. B. in einem Café, einem Flugzeug oder an einem anderen Ort unterwegs. Bei BeyondCorp haben wir auf das Konzept eines privilegierten Unternehmensnetzwerks und eines autorisierten Zugriffs verzichtet, der ausschließlich auf den Anmeldedaten und Attributen von Geräten und Nutzern basiert und unabhängig vom Standort des Netzwerks eines Nutzers ist.

Bei cloudnativer Sicherheit stehen für Dienste und Nutzer dieselben Punkte im Vordergrund: In einer cloudbasierten Welt können wir uns nicht einfach auf eine Firewall zum Schutz des Produktionsnetzwerks verlassen, ebenso wie wir uns nicht auf eine Firewall zum Schutz des Unternehmensnetzwerks verlassen können. So wie sich Nutzer nicht alle am gleichen physischen Standort befinden oder dasselbe Gerät verwenden, stellen Entwickler Code nicht in derselben Umgebung bereit. Mit BeyondProd können Mikrodienste nicht nur in einem Rechenzentrum ausgeführt werden, das durch eine Firewall geschützt ist, sondern auch in öffentlichen Clouds, privaten Clouds oder gehosteten Diensten von Drittanbietern. Und sie müssen überall sicher sein.

So wie Nutzer sich bewegen, unterschiedliche Geräte verwenden und Verbindungen von verschiedenen Standorten herstellen, werden auch Mikrodienste bewegt und in verschiedenen Umgebungen auf heterogenen Hosts bereitgestellt. Laut BeyondCorp sollte das Vertrauen der Nutzer von Merkmalen wie dem kontextsensitiven Status der Geräte und nicht der Möglichkeit abhängig sein, eine Verbindung zum Unternehmensnetzwerk herzustellen. Weiterhin sollte das Vertrauen der Dienste von Merkmalen wie Codeherkunft und Dienstidentität abhängig sein und nicht vom Ort im Produktionsnetzwerk, z. B. der IP-Adresse oder der Identität des Hostnamens.

Cloud-Nativität und die Entwicklung von Anwendungen

Ein eher traditionelles Sicherheitsmodell, das auf perimeterbasierte Sicherheit ausgerichtet ist, kann eine cloudnative Architektur nicht alleine schützen. In diesem Beispiel wird eine monolithische Anwendung mit einer dreistufigen Architektur in einem privaten Rechenzentrum bereitgestellt, das über ausreichende Kapazitäten verfügt, um die Spitzenlast für kritische Ereignisse zu bewältigen. Anwendungen mit bestimmten Hardware- oder Netzwerkanforderungen werden absichtlich auf bestimmten Maschinen bereitgestellt, die in der Regel feste IP-Adressen haben. Rollouts erfolgen selten, in großem Umfang und sind schwer zu koordinieren, da die resultierenden Änderungen gleichzeitig viele Teile der Anwendung betreffen. Dies führt zu sehr langlebigen Anwendungen, die weniger häufig aktualisiert werden und bei denen Sicherheitspatches normalerweise nicht so oft zur Anwendung kommen.

In einem cloudnativen Modell entkoppeln Container jedoch die für die Anwendung erforderlichen Binärprogramme vom zugrunde liegenden Hostbetriebssystem und machen Anwendungen leichter übertragbar. Container sollen unverändert verwendet werden, d. h. sie bleiben nach der Bereitstellung gleich. Sie werden also häufig neu erstellt und immer wieder aufs Neue bereitgestellt. 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. Da Container häufig neu gestartet, beendet 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) bereits im frühen Entwicklungsstadium berücksichtigt werden.

Auswirkungen auf die Sicherheit

Wie sich das Modell einer nicht vertrauenswürdigen Innengestaltung mit Nutzern in BeyondCorp auch auf Mikrodienste in BeyondProd anwenden lässt, wurde bereits ausführlich erläutert. Aber wie sieht diese Änderung aus? Tabelle 1 bietet einen Vergleich zwischen Aspekten der herkömmlichen Infrastruktursicherheit und ihren Gegenstücken in einer cloudnativen Architektur. In der Tabelle werden auch die Anforderungen aufgeführt, die für den Umstieg von einem System auf das andere erforderlich sind. Der Rest dieses Abschnitts enthält weitere Details zu jeder Zeile der Tabelle.

Herkömmliche Infrastruktursicherheit Cloudnative Sicherheit Implizierte Anforderungen für die cloudnative Sicherheit
Perimeterbasierte Sicherheit (d. h. Firewall), wobei die interne Kommunikation als vertrauenswürdig eingestuft wird Zero-Trust-Sicherheit mit verifizierter Dienst-zu-Dienst-Kommunikation und ohne implizites Vertrauen für Dienste in der Umgebung Schutz des Netzwerks am Rand (weiterhin gültig) und kein inhärentes gegenseitiges Vertrauen zwischen den Diensten
Feste IP-Adressen und Hardware für bestimmte Anwendungen Umfassendere Auslastung, Wiederverwendung und gemeinsame Nutzung von Ressourcen, einschließlich IP-Adressen und Hardware Vertrauenswürdige Maschinen, auf denen Code mit bekannter Herkunft ausgeführt wird
IP-Adressen-basierte Identität Dienstbasierte Identität
An einem bekannten, erwarteten Ort ausgeführte Dienste Dienste können überall in der Umgebung ausgeführt werden, auch in hybriden Bereitstellungen in der öffentlichen Cloud und privaten Rechenzentren
Sicherheitsspezifische Anforderungen, die in jede Anwendung integriert sind und separat erzwungen werdenGemeinsame Sicherheitsanforderungen, die in Dienststacks gemäß einer zentralisierten Erzwingungsrichtlinie eingebunden sind Nadelöhre für die konsistente Richtlinienerzwingung bei allen Diensten
Begrenzte Einschränkungen für das Erstellen und Überprüfen von Diensten Für alle Dienste gleichermaßen geltende Sicherheitsanforderungen
Eingeschränkte Überwachung von Sicherheitskomponenten Zentralisierte Ansicht der Sicherheitsrichtlinien und Einhaltung der Richtlinien
Spezialisierte und seltene Rollouts Standardisierter Erstellungs- und Rollout-Prozess mit häufigeren Änderungen an einzelnen Mikrodiensten Einfacher, automatisierter und standardisierter Rollout von Änderungen
Arbeitslasten werden in der Regel als VMs oder auf physischen Hosts bereitgestellt und verwenden für die Isolation physische Maschinen oder Hypervisoren. Arbeitslasten aus Behältern und ihre Prozesse werden in einem gemeinsam genutzten Betriebssystem ausgeführt, das einen Mechanismus zum Isolieren der Arbeitslasten erfordert Isolation zwischen Arbeitslasten, die gemeinsam ein Betriebssystem verwenden

Tabelle 1: Implizite Anforderungen an die Sicherheit beim Umstieg auf eine cloudnative Architektur

Von der perimeterbasierten Sicherheit zur Zero-Trust-Sicherheit

Bei einem herkömmlichen Sicherheitsmodell können die Anwendungen einer Organisation zum Schutz vor eingehendem Traffic auf eine externe Firewall um das private Rechenzentrum angewiesen sein. Obwohl der Netzwerkperimeter in einer cloudnativen Umgebung wie beim BeyondCorp-Modell noch geschützt werden muss, reicht ein perimeterbasiertes Sicherheitsmodell nicht mehr aus. Dies stellt kein neues Sicherheitsproblem dar, sondern trägt der Tatsache Rechnung, dass eine Firewall das Produktionsnetzwerk nicht vollständig schützen kann, wenn sie keinen vollständigen Schutz für das Unternehmensnetzwerk bietet. Mit einem Zero-Trust-Sicherheitsmodell können Sie internem Traffic nicht mehr implizit vertrauen. Dies erfordert andere Sicherheitskontrollen wie Authentifizierung und Verschlüsselung. Gleichzeitig bietet der Umstieg auf Mikrodienste die Chance, das herkömmliche Sicherheitsmodell zu überdenken. Wenn Sie die Abhängigkeit von einem einzelnen Netzwerkperimeter entfernen, z. B. eine Firewall, können Sie das Netzwerk weiter nach Diensten segmentieren. Um dieses Konzept noch einen Schritt weiter zu verfolgen, könnten Sie eine Segmentierung auf Mikrodienstebene vornehmen, ohne dass zwischen den Diensten ein inhärentes Vertrauen besteht. Bei Mikrodiensten kann der Traffic für verschiedene Steuerelemente unterschiedliche Vertrauensstufen haben. So vergleichen Sie nicht mehr nur internen mit externem Traffic.

Von festen IP-Adressen und Hardware bis zu umfangreicheren gemeinsam genutzten Ressourcen

Bei einem herkömmlichen Sicherheitsmodell wurden die Anwendungen einer Organisation auf bestimmten Maschinen bereitgestellt und die IP-Adressen dieser Maschinen änderten sich nur selten. Dies bedeutete, dass sich Sicherheitstools auf eine relativ statische Architekturkarte verlassen konnten, bei der Anwendungen auf vorhersehbare Weise miteinander verknüpft waren. Sicherheitsrichtlinien in Tools wie Firewalls konnten IP-Adressen als Kennung verwenden.

In der cloudnativen Welt mit gemeinsam genutzten Hosts und häufig wechselnden Jobs funktioniert die Verwendung einer Firewall zur Steuerung des Zugriffs unter den Mikrodiensten jedoch nicht. Sie können sich nicht darauf verlassen, dass eine bestimmte IP-Adresse an einen bestimmten Dienst gebunden ist. Die Identität basiert daher nicht auf einer IP-Adresse oder einem Hostnamen, sondern auf einem Dienst.

Von anwendungsspezifischen Sicherheitsimplementierungen bis zu gemeinsam genutzten Sicherheitsanforderungen, die in Dienststacks eingebunden sind

Bei einem herkömmlichen Sicherheitsmodell mussten einzelne Anwendungen unabhängig von anderen Diensten ihre eigenen Sicherheitsanforderungen erfüllen. Zu diesen Anforderungen gehörten die Identitätsverwaltung, die SSL- und TLS-Beendigung sowie die Datenzugriffsverwaltung. Dies führte häufig zu inkonsistenten Implementierungen oder nicht berücksichtigten Sicherheitsproblemen, da diese Probleme an verschiedensten Stellen behoben werden mussten, was die Problembehebung schwieriger machte.

In der cloudnativen Welt werden Komponenten häufiger für verschiedene Dienste wiederverwendet und es gibt Engpässe, an denen Richtlinien konsistent für alle Dienste erzwungen werden können. 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 (z. B. eine Richtlinie für den autorisierten Zugriff auf Nutzerdaten und eine andere Richtlinie zur Verwendung der aktuellen Suites für die TLS-Verschlüsselung).

Von spezialisierten und seltenen Rolloutprozessen bis zu standardisierten Prozessen mit häufigeren Rollouts

Bei einem herkömmlichen Sicherheitsmodell gab es in begrenztem Umfang gemeinsam genutzte Dienste. Aufgrund des stärker verteilten Codes in Verbindung mit der lokal erfolgenden Entwicklung war es schwierig, die Auswirkungen einer Änderung zu ermitteln, die viele Teile einer Anwendung betraf. Also erfolgten Rollouts selten und waren schwer zu koordinieren. Um eine Änderung vorzunehmen, mussten Entwickler unter Umständen jede Komponente direkt aktualisieren und beispielsweise eine SSH-Verbindung zu einer virtuellen Maschine herstellen, um eine Konfiguration zu aktualisieren. Insgesamt führte dies zu extrem langlebigen Anwendungen. Aufgrund des stärker verteilten Codes war es aus Perspektive der Sicherheit schwieriger zu überprüfen, ob eine Sicherheitslücke, die geschlossen wurde, überall geschlossen wurde, und sogar noch problematischer, dies wirklich sicherzustellen. Der Umstieg auf cloudnative Systeme mit häufigen und standardisierten Rollouts ermöglicht eine Linksverschiebung 2 der Sicherheit im Softwareentwicklungszyklus. Somit ist eine einfachere und konsistentere Erzwingung der Sicherheitshygiene möglich, einschließlich der regelmäßigen Durchführung von Sicherheitspatches.

Von Arbeitslasten, die mit physischen Maschinen oder Hypervisoren isoliert wurden, bis zu Arbeitslasten in Behältern, die auf derselben Maschine ausgeführt werden und eine stärkere Isolation erfordern

In einem herkömmlichen Sicherheitsmodell wurden Arbeitslasten auf ihren eigenen Instanzen ohne gemeinsam genutzte Ressourcen geplant. Die Trennung von Anwendungen erfolgte effektiv durch ihre Maschinen- und Netzwerkgrenzen und die Isolation der Arbeitslasten wurde ausschließlich durch physische Hosttrennung, Hypervisoren und herkömmliche Firewalls erzwungen.

In einer cloudnativen Welt werden Arbeitslasten containerisiert und in Behältern auf gemeinsam genutzte Hosts und Ressourcen verteilt. Daher ist eine stärkere Isolation zwischen Ihren Arbeitslasten erforderlich. Arbeitslasten können in Mikrodienste aufgeteilt werden, die teilweise mithilfe von Netzwerkeinstellungen und Sandbox-Technologien voneinander isoliert sind.

Sicherheitsgrundsätze

Bei der Entwicklung einer cloudnativen Architektur wollten wir gleichzeitig die Sicherheit verbessern. Deshalb haben wir die folgenden Sicherheitsgrundsätze aufgestellt und optimiert:

  • Schutz des Netzwerks am Rand, damit Arbeitslasten von Netzwerkangriffen und von nicht autorisiertem Traffic aus dem Internet isoliert sind. Obwohl der Ansatz auf Grundlage einer Firewall für das cloudnative Konzept nicht neu ist, bleibt er für die Sicherheit ein Best Practice. In einer cloudnativen Welt wird ein Perimeteransatz verwendet, um so viel Infrastruktur wie möglich gegen nicht autorisierten Traffic und potenzielle Angriffe aus dem Internet zu schützen, z. B. volumenbasierte DoS-Angriffe (Denial of Service).

  • Kein inhärentes gegenseitiges Vertrauen zwischen Diensten, damit nur bekannte, vertrauenswürdige und speziell autorisierte Aufrufer einen Dienst nutzen können. 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 trägt dazu bei, den Umfang einer Manipulation einzuschränken.

  • Vertrauenswürdige Maschinen, auf denen Code bekannter Herkunft ausgeführt wird, damit Dienstidentitäten darauf beschränkt sind, nur autorisierten Code und Konfigurationen zu verwenden, und nur in autorisierten, verifizierten Umgebungen ausgeführt werden.

  • Nadelöhre für die konsistente Richtlinienerzwingung bei allen Diensten, zum Beispiel ein Nadelöhr zur Überprüfung von Anfragen für den Zugriff auf Nutzerdaten, damit der Zugriff eines Dienstes von einer validierten Anfrage eines autorisierten Endnutzers abgeleitet wird und der Zugriff eines Administrators eine geschäftliche Rechtfertigung erfordert.

  • Einfacher, automatisierter und standardisierter Rollout von Änderungen, damit Infrastrukturänderungen leicht auf ihre Auswirkungen auf die Sicherheit überprüft werden können und der Rollout von Sicherheitspatches geringe Auswirkungen auf die Produktion hat.

  • Isolation von Arbeitslasten, die ein Betriebssystem gemeinsam nutzen, damit bei der Manipulation eines Dienstes die Sicherheit einer anderen Arbeitslast, die auf demselben Host ausgeführt wird, nicht beeinträchtigt wird. Dadurch wird der Umfang einer möglichen Manipulation eingeschränkt.

Wir verfolgen für unsere gesamte Infrastruktur das Ziel, für automatisierte Sicherheit zu sorgen, die nicht von Einzelpersonen abhängig ist. Die Skalierung der Sicherheit sollte auf die gleiche Weise erfolgen wie bei Diensten. Dienste sollten standardmäßig sicher und in Ausnahmefällen unsicher sein. Menschliche Aktionen sollten die Ausnahme, nicht die Regel, sowie überprüfbar sein, wenn sie vorkommen. 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.

Zusammengenommen bedeutet die Umsetzung dieser Sicherheitsgrundsätze, dass Container und die darin ausgeführten Mikrodienste bereitgestellt und nebeneinander ausgeführt werden sowie miteinander kommunizieren können, ohne die Eigenschaften einer cloudnativen Architektur zu schwächen (d. h. einfache Arbeitslastverwaltung, managementfreie Skalierung und wirksame Nutzung von Behältern). All dies kann erreicht werden, ohne die einzelnen Entwickler von Mikrodiensten mit den Details zur Sicherheit und Implementierung der zugrunde liegenden Infrastruktur zu belasten.

Interne Sicherheitsdienste von Google

Zum Schutz der cloudnativen Infrastruktur von Google haben wir mehrere interne Tools und Dienste entwickelt. Im Zusammenspiel dienen die unten aufgeführten Sicherheitsdienste dazu, die im Abschnitt Sicherheitsgrundsätze definierten Sicherheitsgrundsätze zu erfüllen:

  • Google Front End (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 eine Nutzerverbindung zu Google. Innerhalb unserer Infrastruktur ist das GFE dann auch für das Load-Balancing und ggf. für die Umleitung des Traffics unter den Regionen verantwortlich. In unserer Infrastruktur ist das GFE der Edge-Proxy, der den Traffic zum richtigen Mikrodienst weiterleitet.

  • Application Layer Transport Security (ALTS): Wird für die RPC-Authentifizierung, -Integrität und -Verschlüsselung verwendet. ALTS ist ein gegenseitiges Authentifizierungs- und Transportverschlüsselungssystem für Dienste in der Infrastruktur von Google. Identitäten sind im Allgemeinen an Dienste gebunden und nicht an einen bestimmten Servernamen oder Host. Somit können die Replikation, das Load-Balancing und die Neuplanung von Mikrodiensten auf allen Hosts nahtlos erfolgen.

  • Die Binärautorisierung für Borg und die Hostintegrität werden zur Überprüfung der Mikrodienst- und Maschinenintegrität verwendet:

    • Binärautorisierung für Borg (BAB): Eine Erzwingungsprüfung zur Bereitstellungszeit, mit der sichergestellt wird, dass der Code den internen Sicherheitsanforderungen entspricht, bevor er bereitgestellt wird. Dabei werden unter anderem Änderungen von einem zweiten Entwickler geprüft, Code wird an unser Quellcode-Repository gesendet und Binärprogramme werden nachweislich auf einer dedizierten Infrastruktur erstellt. In unserer Infrastruktur beschränkt BAB die Bereitstellung von nicht autorisierten Mikrodiensten.
    • Hostintegrität (HINT): Verifiziert die Integrität der Software des Hostsystems durch einen sicheren Startvorgang und hat als Sicherung eine sichere Mikrocontroller-Hardware, wenn diese unterstützt wird. Zu den HINT-Prüfungen zählt die Verifizierung digitaler Signaturen im BIOS, BMC, Bootloader sowie im Kernel des Betriebssystems.
  • Dienstzugriffsrichtlinien und Tickets für den Endnutzerkontext werden verwendet, um den Zugriff auf Daten einzuschränken:

    • Dienstzugriffsrichtlinie: Schränkt den Zugriff auf Daten durch Dienste ein. Wenn ein RPC von einem Dienst an einen anderen gesendet wird, werden anhand der Dienstzugriffsrichtlinie die Authentifizierungs-, Autorisierungs- und Prüfrichtlinien definiert, die für den Zugriff auf die Daten des empfangenden Dienstes erforderlich sind. 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 Infrastruktur von Google beschränkt die Dienstzugriffsrichtlinie den Zugriff eines Mikrodienstes auf die Daten eines anderen Mikrodienstes und ermöglicht globale Analysen der Zugriffssteuerung.
    • Tickets für den Endnutzerkontext: Diese Tickets werden von einem Endnutzer-Authentifizierungsdienst ausgestellt und stellen Dienste mit einer Nutzeridentität bereit, die von ihrer Dienstidentität getrennt ist. Hierbei handelt es sich um integritätsgeschützte, zentral ausgestellte, weiterleitbare Anmeldedaten, die die Identität eines Endnutzers belegen, der eine Anfrage an den Dienst gestellt hat. So verringert sich die Notwendigkeit für Vertrauen unter den Diensten, da die Peer-Identität über ALTS häufig für die Zugriffserteilung nicht ausreicht, wobei diese Autorisierungsentscheidungen in der Regel auch auf der Identität des Endnutzers beruhen.
  • Borg-Tool für Blau/Grün-Bereitstellungen3: Dieses Tool ist für die Migration ausgeführter Arbeitslasten bei der Durchführung von Wartungsaufgaben zuständig. Neben dem bestehenden Borg-Job wird ein neuer Borg-Job bereitgestellt und ein Load-Balancer verschiebt den Traffic nach und nach von einem zum anderen Job. So kann ein Mikrodienst ohne Ausfallzeit aktualisiert werden und dem Nutzer fällt dies überhaupt nicht auf. Dieses Tool wird verwendet, 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 die Google Cloud-Infrastruktur haben, verwenden wir eine Live-Migration, damit VM-Arbeitslasten nicht beeinträchtigt werden.

  • gVisor zur Isolation von Arbeitslasten: gVisor verwendet einen Nutzerbereichs-Kernel, um Systemaufrufe abzufangen und zu verarbeiten, wodurch die Interaktion mit dem Host und der potenziellen Angriffsfläche reduziert wird. 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. In der Infrastruktur von Google ist gVisor eines von mehreren wichtigen Tools, mit denen sowohl interne als auch Arbeitslasten von Google Cloud-Kunden voneinander isoliert werden können, die auf demselben Host ausgeführt werden.

In Tabelle 2 wird jeder Grundsatz, der im Abschnitt „Sicherheitsgrundsätze“ beschrieben wurde, einem entsprechenden Tool zugeordnet, mit dem Google diesen Grundsatz umsetzt.

Sicherheitsgrundsatz Internes Sicherheitstool bzw. interner Sicherheitsdienst von Google
Schutz des Netzwerks am Rand Google Front End (GFE) zur Verwaltung der TLS-Beendigung und der Richtlinien für eingehenden Traffic
Kein inhärentes gegenseitiges Vertrauen unter den Diensten Application Layer Transport Security (ALTS) für die RPC-Authentifizierung, -Integrität und -Verschlüsselung sowie Dienstidentitäten
Vertrauenswürdige Maschinen, auf denen Code bekannter Herkunft ausgeführt wird Binärautorisierung für Borg (BAB) zur Überprüfung der Codeherkunft

Hostintegrität (HINT) zur Überprüfung der Maschinenintegrität

Nadelöhre für eine konsistente Richtlinienerzwingung bei allen Diensten Dienstzugriffsrichtlinie zum Einschränken, wie Dienste untereinander auf Daten zugreifen

Tickets für den Endnutzerkontext (EUC), um die Identität des ursprünglichen Anfragestellers zu bestätigen

Einfacher, automatisierter und standardisierter Rollout von Änderungen Borg-Tools für Blau/Grün-Bereitstellungen
Isolation von Arbeitslasten, die gemeinsam dasselbe Betriebssystem verwenden gVisor zur Isolation von Arbeitslasten

Tabelle 2: Grundsätze und Sicherheitstools zur Umsetzung der cloudnativen Sicherheit bei Google

Zusammenfassung

In diesem Abschnitt wird beschrieben, wie die bisher besprochenen Komponenten zusammenpassen, damit Nutzeranfragen in einer cloudnativen Welt bedient werden können. Wir verwenden zwei Beispiele: Zuerst verfolgen wir eine typische Anfrage für Nutzerdaten von der Erstellung bis zur Zustellung an ihrem Ziel und dann eine Codeänderung von der Entwicklung bis zur Produktion. Nicht alle der hier aufgeführten Technologien kommen in allen Bereichen der Infrastruktur von Google zum Einsatz. Dies ist von den Diensten und Arbeitslasten abhängig.

Zugriff auf Nutzerdaten

Wie in Abbildung 1 gezeigt, empfängt das GFE die Anfrage eines Nutzers (Schritt 1), beendet dann die TLS-Verbindung und leitet die Anfrage über ALTS4 an das entsprechende Front-End des Dienstes weiter (Schritt 2). Das Front-End der Anwendung authentifiziert die Anfrage des Nutzers mithilfe eines zentralen Endnutzer-Authentifizierungsdienstes (EUA) und erhält im Erfolgsfall ein kurzlebiges kryptografisches Ticket für den Endnutzerkontext (EUC) (Schritt 3).

Diagramm

Abbildung 1: Sicherheitskontrollen der cloudnativen Architektur von Google – Zugriff auf Nutzerdaten

Das Front-End der Anwendung führt dann über ALTS einen RPC zum Back-End eines Speicherdienstes aus und leitet das EUC-Ticket mit der Back-End-Anfrage weiter (Schritt 4). Der Back-End-Dienst verwendet Dienstzugriffsrichtlinien, um Folgendes sicherzustellen:

  1. Die ALTS-Identität des Front-End-Dienstes ist autorisiert, Anfragen an den Back-End-Dienst zu senden und ein EUC-Ticket weiterzuleiten.
  2. Die Identität des Front-Ends wird durch unsere Binärautorisierung für Borg (BAB) geschützt.
  3. Das EUC-Ticket ist gültig.

Der Back-End-Dienst überprüft dann, ob der im EUC-Ticket aufgeführte Nutzer berechtigt ist, auf die angefragten Daten zuzugreifen. Schlägt eine dieser Prüfungen fehl, wird die Anfrage abgelehnt. In vielen Fällen gibt es eine Kette von Back-End-Aufrufen und jeder Vermittlungsdienst führt zu eingehenden RPCs eine Prüfung der Dienstzugriffsrichtlinie durch. Das EUC-Ticket wird zusammen mit ausgehenden RPCs weitergeleitet. Sind diese Prüfungen bestanden, werden die Daten an das autorisierte Front-End der Anwendung zurückgegeben und dem autorisierten Nutzer bereitgestellt.

Jede Maschine hat ALTS-Anmeldedaten, die über das HINT-System bereitgestellt werden, und nur entschlüsselt werden können, wenn vom HINT bestätigt wurde, dass der Bootvorgang der Maschine erfolgreich war. Die meisten Google-Dienste werden als Mikrodienste zusätzlich zu Borg ausgeführt. Diese Mikrodienste haben jeweils ihre eigene ALTS-Identität. Borgmaster5 weist diesen ALTS-Mikrodiensten wie in Abbildung 1 beschrieben Anmeldedaten für Arbeitslasten basierend auf der Identität des Mikrodienstes zu. Die ALTS-Anmeldedaten auf Maschinenebene bilden den sicheren Kanal zur Bereitstellung von Anmeldedaten für Mikrodienste. Somit können nur Maschinen, bei denen der HINT-Bootvorgang erfolgreich bestätigt wurde, Arbeitslasten von Mikrodiensten hosten.

Änderungen am Code vornehmen

Wenn ein Google-Mitarbeiter eine Änderung an einem Mikrodienst vornimmt, der durch eine ausreichend starke BAB geschützt ist, muss die Änderung wie in Abbildung 2 ersichtlich an unser zentrales Code-Repository gesendet werden, das eine Codeüberprüfung 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 (Schritt 1). Zur Bereitstellungszeit überprüft die BAB, ob diesem Prozess eine Validierung des signierten Zertifikats aus der Build-Pipeline gefolgt ist (Schritt 2).

Diagramm

Abbildung 2: Sicherheitskontrollen der cloudnativen Architektur von Google – Codeänderung

Sämtliche Aktualisierungen der Arbeitslasten werden über Blau/Grün-Bereitstellungen abgewickelt, unabhängig davon, ob es sich um einen routinemäßigen Rollout oder einen Notfall-Sicherheitspatch handelt (Schritt 3). Das GFE verteilt den Traffic auf die neue Bereitstellung und führt ein Load-Balancing durch, um die Kontinuität der Vorgänge sicherzustellen.

Alle Arbeitslasten müssen isoliert werden. Wenn eine Arbeitslast weniger vertrauenswürdig ist, z. B. weil die Arbeitslast mehrmandantenfähig ist oder der Quellcode nicht von Google stammt, kann sie in einer von gVisor geschützten Umgebung bereitgestellt werden oder es können weitere Isolationsebenen zur Anwendung kommen. Durch diese Isolation wird sichergestellt, dass keine der anderen Instanzen betroffen ist, wenn eine Instanz der Anwendung manipuliert wird.

BeyondProd anwenden

Alles auf eine Karte setzen

Durch den Umstieg auf ein cloudnatives System und das angemessene Schützen dieser Infrastruktur kann Google für seine internen und externen Arbeitslasten (Google Cloud) sehr starke Sicherheitseigenschaften bieten.

Durch das Einrichten gemeinsam genutzter Komponenten ist der Druck auf den einzelnen Entwicklern, die gemeinsamen Sicherheitsanforderungen zu erfüllen, minimal. Idealerweise sollte die Sicherheitsfunktion nur eine minimale oder keine Integration in jede einzelne 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.

Auf ein cloudnatives System umstellen

Die Umstellung bei Google auf cloudnative Systeme erforderte Änderungen in zwei Hauptbereichen: an unserer Infrastruktur und an unserem Entwicklungsprozess. Wir haben diese Änderungen gleichzeitig vorgenommen, die aber entkoppelt und unabhängig voneinander umgesetzt werden konnten.

Unsere Infrastruktur ändern

Wir haben zuerst eine solide Grundlage für die Dienstidentität, Authentifizierung und Autorisierung geschaffen. Dank der vertrauenswürdigen Dienstidentitäten konnten wir übergeordnete Sicherheitsfunktionen implementieren, die von der Validierung dieser Dienstidentitäten abhängig sind, z. B. Dienstzugriffsrichtlinien und EUC-Tickets. 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. Dies erleichterte eine breite Akzeptanz, ohne dass die einzelnen Entwicklerteams in erheblichem Maße belastet wurden. Der Rollout von ALTS war eine Voraussetzung für den Rollout der Dienstzugriffsrichtlinien und EUC-Tickets.

Unsere Entwicklungsprozesse ändern

Für Google war es entscheidend, einen stabilen Prozess für die Entwicklung und Codeüberprüfung einzurichten. So konnten wir die Integrität der ausgeführten Dienste sicherstellen und dafür sorgen, dass die von ALTS verwendeten Identitäten aussagekräftig sind. Wir haben einen zentralen Build-Prozess entwickelt, mit dem wir Anforderungen wie die Überprüfung von Code durch zwei Personen und automatisierte Tests zum Zeitpunkt der Entwicklung und Bereitstellung durchsetzen konnten. Weitere Informationen zum Bereitstellen finden Sie im Whitepaper 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. Zuerst erhielten die Dienstinhaber 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. Außerdem 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.

Vorteile eines Umstiegs

Ebenso wie BeyondCorp uns bei der Weiterentwicklung über ein perimeterbasiertes Sicherheitsmodell hinaus geholfen hat, stellt BeyondProd für unseren Ansatz der Produktionssicherheit einen ähnlichen Schritt nach vorne dar. Der BeyondProd-Ansatz beschreibt eine cloudnative Sicherheitsarchitektur, die kein Vertrauen unter den Diensten voraussetzt, eine Isolation der einzelnen Arbeitslasten bietet, dafür sorgt, dass nur zentral entwickelte Anwendungen bereitgestellt werden, eine automatisierte Verwaltung von Sicherheitslücken bietet und eine strenge Zugriffssteuerung für wichtige Daten erzwingt. Die BeyondProd-Architektur hat Google dazu veranlasst, mehrere neue Systeme zu entwickeln, um diese Anforderungen zu erfüllen.

Zu häufig wird die Sicherheit erst als Letztes berücksichtigt, wenn die Entscheidung für die Migration zu einer neuen Architektur bereits gefallen ist. Wenn Sie Ihr Sicherheitsteam frühzeitig einbeziehen und sich auf die Vorteile des neuen Sicherheitsmodells wie die einfachere Patch-Verwaltung und die strengere Zugriffssteuerung konzentrieren, kann eine cloudnative Architektur sowohl für die Anwendungsentwicklung als auch die Sicherheitsteams erhebliche Vorteile bieten. Wenn Sie die in diesem Dokument beschriebenen Sicherheitsgrundsätze auf Ihre cloudnative Infrastruktur anwenden, können Sie die Bereitstellung Ihrer Arbeitslasten, die sichere Kommunikation Ihrer Arbeitslasten und die Auswirkungen auf andere Arbeitslasten verbessern.

Hinweise

1 Borg ist das Clusterverwaltungssystem von Google zum Planen und Ausführen von hohen Arbeitslasten. Borg war das erste einheitliche Containerverwaltungssystem von Google und diente als Inspiration für Kubernetes.

2 „Linksverschiebung“ bezieht sich auf frühe Schritte im Softwareentwicklungszyklus. Dazu gehören unter anderem Schritte wie das Schreiben von Code, Entwickeln, Testen, Validieren und Bereitstellen. Lebenszyklusdiagramme werden häufig von links nach rechts erstellt, also bedeutet links einen früheren Schritt.

3 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.

4 Informationen dazu, wie Traffic innerhalb der Google-Infrastruktur vom GFE an einen Dienst weitergeleitet wird, finden Sie im Abschnitt Weiterleitung des Traffics unseres Whitepapers zur Verschlüsselung bei der Übertragung in Google Cloud.

5 Borgmaster ist der zentrale Controller von Borg. Er ist für die Planung von Jobs zuständig und kommuniziert mit ausgeführten Jobs über deren Status.