Google Zero Trust Architektur Praktiken

Hintergrund

Der Autor dieses Artikels ist Jack Chen, der das Glück hatte, von 2015 bis 2020 an der Produktionsumgebung von Google beteiligt zu sein.Null Vertrauen（Das in diesem Zusammenhang entwickelte Binary Authorisation for Borg (BAB)-System hat eine umfassende Abdeckung der Produktionsumgebung von Google erreicht: Bevor jemand ein beliebiges Paket als beliebigen Dienst in der Produktionsumgebung ausführen kann, muss das Zielpaket für den Nutzer verfügbar gemacht werden. Das in diesem Zusammenhang entwickelte System Binary Authorization for Borg (BAB) hat eine vollständige Abdeckung der Produktionsumgebungen von Google erreicht: Bevor jemand ein beliebiges Paket als beliebigen Dienst in einer Produktionsumgebung ausführen kann, muss für den Zieldienst eine ausreichend starke BAB-Sicherheitsrichtlinie festgelegt werden. Programme, die die BAB-Sicherheitsrichtlinien nicht einhalten, dürfen nicht als der entsprechende Dienst ausgeführt werden.

Bei der Umsetzung und Förderung dieses Null-Vertrauens für Produktionsumgebungen ist das BAB-Team viele Umwege gegangen, hat aber auch viele Erfahrungen gesammelt. Ab 2017 begann das BAB-Team, diese praktischen Erfahrungen zur Theorie zu erheben und veröffentlichte nach und nach eine Reihe von Whitepapers ( BeyondProd(math.) Gattung Binäre Autorisierung für Borg, SLSA: Lieferkettenebenen für Software-Artefakte), Bücher ( Aufbau sicherer und zuverlässiger Systeme) und den Bericht ( Umstellung auf ein Zero-Trust-Sicherheitsmodell mit Anthos-Sicherheit, Zero Touch Prod). Sie hat auch damit begonnen, diese Null-Vertrauens-Philosophie auf weitere Anwendungsszenarien auszuweiten, einschließlich Null-Vertrauen in die öffentliche Cloud, Null-Vertrauen in die eigene Infrastruktur der öffentlichen Cloud und Null-Vertrauen in die Entwicklung von Android und Chrome selbst und deren Anwendungen.

Der Inhalt dieses Artikels basiert auf den oben genannten Informationen, die von Google veröffentlicht wurden, und legt keine Unternehmensgeheimnisse von Google offen und verstößt nicht gegen Geheimhaltungsvereinbarungen. Die Schlussfolgerungen in diesem Artikel geben nur die persönlichen Ansichten des Autors wieder und sind nicht unbedingt die offiziellen Ansichten von Google.

Was ist Zero Trust?

Was bedeutet Nullvertrauen? Verschiedene Leute werden wahrscheinlich unterschiedliche Antworten geben. Einige sagen, dass Zero Trust die Mikrosegmentierung von Workloads ist; einige sagen, dass Zero Trust die kontinuierliche Überwachung von Bedrohungen ist; einige sagen, dass Zero Trust das Vertrauen in Endpunkte und nicht in das Netzwerk ist; und einige sagen, dass Zero Trust die Zwei-Wege-TLS-Authentifizierung (mTLS) ist. Einige sagen, dass Zero Trust eine kontinuierliche Überwachung von Bedrohungen ist; einige sagen, dass man den Endpunkten und nicht dem Netzwerk vertraut; andere sagen, dass Zero Trust bedeutet, den Endpunkten und nicht dem Netzwerk zu vertrauen; wieder andere sagen, dass Zero Trust eine Zwei-Wege-TLS-Authentifizierung (mTLS) ist. All diese Ansätze haben ihre Berechtigung, aber sie sind auch eindeutig unvollständig.

An dieser Stelle möchte der Autor eine spielerische Formulierung über maschinelles Lernen aufgreifen: "Maschinelles Lernen ist verherrlichte Statistik". In ähnlicher Weise ist "Zero Trust" ein verherrlichtes "Least Privilege". Auch dies ist eindeutig unzutreffend, da sowohl maschinelles Lernen als auch Zero Trust mehr Gewicht auf spezifische Probleme und Anwendungsszenarien legen als Statistik und Least Privilege. Sowohl maschinelles Lernen als auch Zero-Trust sind keine Einzeldisziplinen und Einzeltheorien, sondern innovative Praktiken in mehreren Bereichen (z. B. Mathematik, Computerarchitektur, verteilte Systeme, Speicherung, Vernetzung usw.), die zur Lösung realer Probleme entwickelt wurden.

Es zeigt sich, dass wir bei der Definition und Theorie von Zero Trust nicht zu starr sein müssen, sondern sie mit der Praxis verbinden sollten, ausgehend von den spezifischen zu lösenden Problemen und Anwendungsszenarien. Daher kombinieren wir die Probleme und Anwendungsszenarien in diesem Papier vorübergehend, um Zero Trust wie folgt zu definieren: Reduzierung und Wiederherstellung des Vertrauens in der Produktion in Bezug auf geschützte Daten und Privilegien. und Privilegien).

Eine wichtigere Frage als die Definition von Null-Vertrauen ist: Warum Null-Vertrauen?

Warum Zero Trust

Warum Zero Trust? Im Wesentlichen liegt es daran, dass wir einige wichtige Daten oder Berechtigungen haben, die geschützt werden müssen, und das bestehende Sicherheitssystem kann im Zeitalter der Cloud-Native keinen ausreichenden Schutz mehr bieten. Private Benutzerdaten, Gehaltsabrechnungsdaten von Mitarbeitern, Berechtigungen zum Ändern von Passwörtern, Berechtigungen zum Herunterfahren kritischer Systeme usw. sind alle geschützt. Diese Daten und Berechtigungen wurden ursprünglich durch Perimeter Security-basierte Netzwerkzugriffskontrollen geschützt, wie z. B. Firmenintranets und VPNs, und wenn sich ein Gerät mit dem Firmenintranet verband, erbte es das Recht, auf diese Daten und Berechtigungen zuzugreifen. Später wurden IP-basierte oder Benutzername-und-Passwort-Zugangskontrollen eingeführt, ebenso wie granularere identitäts- und rollenbasierte Zugangskontrollen. Diese erfüllen jedoch nicht mehr die Anforderungen an den Schutz von Daten und Berechtigungen in Cloud-nativen Umgebungen, insbesondere bei komplexen Unternehmens-IT-Systemen wie Google.

Cloud-native bringt folgende Herausforderungen mit sich: Erstens haben sich die IT-Systeme der Unternehmen von einem Ein-Raum-Modell zu einem Multi- und Hybrid-Cloud-Modell entwickelt, was dazu führt, dass die Grenzen verschwimmen und die auf dem Grenzschutz basierende Sicherheit unwirksam wird; zweitens führt das Container-basierte Computing zu einer Host-Unsicherheit, und derselbe Dienst kann jederzeit von einem physischen Host zu einem anderen migriert werden, ohne dass die Verbindung unterbrochen wird; drittens können Microservices und feinkörnige APIs keinen tieferen Schutz mehr erreichen, der auf der Dienstlogik basiert; und viertens können Microservices und feinkörnige APIs keinen tieferen Schutz mehr erreichen, der auf der Dienstlogik basiert. Drittens vergrößern Microservices und feinkörnige APIs die Angriffsfläche, und die Identitäten und Rollen sind nicht mehr nur die der Endbenutzer, sondern auch feinkörnigere Identitäten und Zugangskontrollen bei der Interaktion zwischen Microservices. Zugriffskontrolle.

Ausgehend von der Situation, in der sich Google damals befand, hatten wir 2015 oder so ein relativ ausgereiftes, auf Schlüsseln und Authentifizierung basierendes Privilegienverwaltungssystem intern implementiert, aber zwei Sicherheitsbedrohungen erregten unsere Aufmerksamkeit: Erstens, wie stellt man in der Post-Snowden-Ära gegenseitiges Vertrauen bei der Kommunikation zwischen Maschinen in einem Rechenzentrum her, und wie stellt man sicher, dass ein kompromittierter Host oder ein kompromittierter Dienst keine Auswirkungen auf den Rest der Produktionsumgebung in den anderen Teilen der Produktionsumgebung auswirkt? Zweitens: Wenn wir ein gutes Autorisierungs- und Auditsystem für den einmaligen Daten- und Berechtigungszugriff haben, wie gehen wir dann mit dem potenziellen Risiko eines groß angelegten Datenlecks durch Batch-Daten- und Berechtigungszugriff wie maschinelles Lernen um? Es ist dringend erforderlich, ein Insider-Risiko-System auf der Grundlage von Nullvertrauen aufzubauen.

Natürlich basiert dies alles auf soliden traditionellen Sicherheitsgrundlagen: Netz- und Hostschutzsysteme, vertrauenswürdige Initiierung, Schlüsselverwaltungssysteme, Authentifizierungs- und Verwaltungssysteme usw. Zero Trust ist ein Überbau, der auf diesen Sicherheitsgrundlagen basiert.

Drei Elemente von Zero Trust: Vertrauenskette, Identität 2.0 und kontinuierliche Zugangskontrolle

Chain of Trust, Identity 2.0 und Continuous Access Control sind die drei Hauptelemente von Zero Trust.

Vertrauenskette

Null-Vertrauen ist nicht das völlige Fehlen von Vertrauen, sondern vielmehr der explizite Prozess der Rekonstruktion der Vertrauenskette, ausgehend von einigen grundlegenden, minimierten Vertrauenswurzeln. Einige typische Beispiele: Die Multi-Faktor-Authentifizierung (MFA, Multi-Factor Authentication) ist die Vertrauensbasis für die menschliche Identität; das vertrauenswürdige Plattformmodul (TPM, Trusted Platform Module) und der vertrauenswürdige Startvorgang (Trusted Boot) sind die Vertrauensbasis für die Maschinenidentität; und der Quellcode und die vertrauenswürdige Erstellung sind die Vertrauensbasis für Software. Trusted Build ist die Wurzel des Vertrauens für Software. Das Vertrauen in ein großes IT-System beginnt bei diesen grundlegenden Vertrauenswurzeln und führt über eine Reihe von standardisierten Prozessen (Standardprozess) zu einer vollständigen Vertrauenskette (auch bekannt als Vertrauensbaum oder Vertrauensnetz).

Identität 2.0

Identity 2.0 ist eine Standardisierung der oben genannten Vertrauenskette, um die Verwendung der während des Vertrauensbildungsprozesses gesammelten Informationen in Sicherheitszugangsrichtlinien zu erleichtern. In Identity 2.0 haben alle Ontologien (Entity) eine Identität, Benutzer haben eine Benutzeridentität, Mitarbeiter haben eine Mitarbeiteridentität, Maschinen haben eine Maschinenidentität, Software hat auch eine Softwareidentität; in Identity 2.0 wird jeder Zugriff (Access) mit mehreren Identitäten (auch als Access Context Access Context bekannt), wie z.B. für die Datenbank der Zugriff auf eine Datenzeile mit etwas wie Zum Beispiel wird der Zugriff auf eine Datenzeile in einer Datenbank einen Zugriffskontext haben wie "Um einem Benutzer bei der Lösung eines technischen Problems zu helfen, beantragt Mitarbeiter A Zugriff auf Maschine D durch Software C unter der Autorisierung von Benutzer B".

Kontinuierliche Zugangskontrolle

Mit den umfangreichen Identitäts- und Zugriffskontextinformationen, die Identity 2.0 bereitstellt, können wir ein darauf aufbauendes System zur kontinuierlichen Zugriffskontrolle (CAAC) aufbauen. Bei der kontinuierlichen Zugangskontrolle wird die Zugangskontrolle kontinuierlich in allen Aspekten der Softwareentwicklung und des Betriebs angewendet. Typische Beispiele sind: die Forderung nach einer Multi-Faktor-Authentifizierung, wenn sich ein Mitarbeiter anmeldet; die Forderung, dass Software aus vertrauenswürdigen Quellcode-Repositories in einer sicheren Umgebung erstellt und einer Codeprüfung unterzogen werden muss, wenn Software bereitgestellt wird; die Forderung nach einem Nachweis der Host-Integrität, wenn eine Verbindung zwischen Hosts hergestellt wird; und die Forderung nach Autorisierungs-Tokens, wenn ein Microservice Daten über einen bestimmten Benutzer erhält (Authorization Token). Autorisierungs-Token).

Beispiel für eine Zero-Trust-Bereitstellung

In diesem Abschnitt stellen wir zwei konkrete Beispiele für Zero-Trust-Implementierungen vor: Das erste zeigt, wie ein Nutzer auf seine eigenen Daten zugreifen kann, und das zweite, wie ein Entwickler das Datenzugriffsverhalten in einer Produktionsumgebung durch Änderung des Quellcodes ändern kann. Die Datenzugriffskontrolle von Google folgt in beiden Fällen dem Zero-Trust-Prinzip.

Nutzer, die auf ihre eigenen Daten zugreifen

Wenn ein Nutzer über die Google-Dienste auf seine Daten zugreift, gelangt die Anfrage zunächst über eine verschlüsselte Verbindung (TLS) zwischen dem Nutzer und dem Google Front End (GFE) zum GFE, das wiederum effizientere und sicherere Protokolle und Datenstrukturen verwendet, um die Nutzeranfrage an verschiedene Back-End-Dienste zu verteilen, damit diese gemeinsam die Nutzeranfrage erfüllen. TLS wird zum Beispiel ersetzt durchAnwendungsschicht TLS (ATLS). Benutzerseitige Passwörter werden in das sicherere End User Context Ticket (EUC) umgewandelt. Diese Ersetzungen sollen die Privilegien interner Verbindungen und Token auf der Grundlage der tatsächlichen Anfrage reduzieren, so dass bestimmte ATLS und EUC nur auf Daten und Privilegien zugreifen können, die auf diese Anfrage beschränkt sind.

folgen SieBeyondProdIm Originalbild sollte der Entwickler auf dem Bild eigentlich der Benutzer sein:

Entwickler ändern das Datenzugriffsverhalten von Software

Wenn ein Entwickler das Daten- und Privilegienzugriffsverhalten eines Dienstes ändern möchte, indem er den Code des Dienstes ändert (der Entwickler hat keinen Zugriff auf die Befehlsausführungsprivilegien des Produktionshosts, z. B. SSH), durchläuft die Codeänderung eine Reihe von Prozessen, um das Vertrauen in den Entwickler und sein/ihr Team in Vertrauen in den neuen Dienst umzuwandeln: Alle an dem Prozess beteiligten Personen haben ihre Identitäten durch Multifaktor-Authentifizierung festgestellt, und die Codeänderung wird von Codeänderungen werden von einer oder mehreren Personen mit Genehmigungsrechten bewertet, und nur Code mit ausreichenden Berechtigungen wird in die zentrale Codebasis aufgenommen, wo er zentral erstellt, getestet und von einem vertrauenswürdigen Erstellungsdienst signiert wird, der ebenfalls durch BAB geschützt ist, und die erstellte Software wird bei der Bereitstellung durch die BAB-Richtlinie des Zieldienstes zertifiziert (z. B. kann der GMail-Dienst nur Code ausführen, der an einer bestimmten Stelle in der Codebasis bewertet und getestet wurde). Die erstellte Software wird während des Deployments durch die BAB-Richtlinie des Zieldienstes zertifiziert (z. B. kann der GMail-Dienst nur Code ausführen, der an einem bestimmten Ort in der Codebasis vollständig evaluiert und getestet wurde), und die Software wird in Laufzeitisolierung gemäß der entsprechenden BAB-Sicherheitsrichtlinie ausgeführt: Dienste, die unterschiedlichen BAB-Dienstrichtlinien unterliegen, werden in unterschiedlichen Isolierungsbereichen ausgeführt.

folgen SieBeyondProdOriginalbild, weitere Einzelheiten finden Sie im Originalartikel unter.

Praktische Erfahrungen und gelernte Lektionen

Den Menschen in den Mittelpunkt stellen und Vertrauen durch Prozesse aufbauen

Bei der Verwirklichung von Zero Trust in der Corp-Umgebung mit BeyondCorp haben wir den Menschen in den Mittelpunkt unseres Ansatzes gestellt, mit Identitätsmanagement und Multi-Faktor-Authentifizierung für Mitarbeiter. Gleichzeitig haben wir einen Prozess für die Verwaltung von Corp-Geräten eingeführt, wobei jedes Corp-Gerät mit einem TPM-Modul und einer Integritätsprüfung des Betriebssystems ausgestattet ist. Diese beiden Maßnahmen stellen sicher, dass die richtigen Personen die richtigen Geräte verwenden, um vertrauenswürdige Authentifizierungsdaten bereitzustellen. Schließlich verwenden wir diese Authentifizierungsinformationen, um eine kontinuierliche Zugangskontrolle für den Zugriff der Mitarbeiter auf die Entwicklungsumgebung zu gewährleisten.

Das Problem, dem sich BeyondProd gegenübersieht, ist, dass die Produktionsumgebung nicht direkt mit Menschen interagiert. Deshalb haben wir ein System entwickelt, das die Software in der Produktionsumgebung bis zu den Entwicklern zurückverfolgt (Software Provenance). Software Provenance), beginnend mit der Zertifizierung der Entwickler und der Härtung des Entwicklungsprozesses, um sicherzustellen, dass keine einzelne Person das Verhalten der Software in der Produktionsumgebung ändern kann (No Unilateral Change).

Stufe der Sicherheitsregel

Rom wurde nicht an einem Tag erbaut, und die Förderung von Nullvertrauen ist ein schrittweiser Prozess. Um Sicherheitsverbesserungen zu quantifizieren und Anreize zu schaffen, verwenden wir Sicherheitsregelstufen, um zu messen, ob eine Sicherheitsregel "sicherer" ist als eine andere. Im System Binary Authorization for Borg haben wir zum Beispiel die folgenden Sicherheitsstufen eingeführt:

Sicherheitsstufe 〇: Kein Schutz. Dies ist die niedrigste Sicherheitsstufe und bedeutet, dass der Dienst überhaupt nicht durch BAB geschützt ist. Dies kann der Fall sein, weil das System keine sensiblen Berechtigungen hat oder weil es einen anderen BAB-äquivalenten Schutz verwendet.

Sicherheitsstufe I: Überprüfbarer Code. Sicherheitsregeln dieser Stufe gewährleisten, dass die von dem entsprechenden Dienst verwendete Software aus bekanntem Quellcode in einer sicheren und überprüfbaren Umgebung erstellt wird.

Sicherheitsstufe 2: Vertrauenswürdiger Code. Die Sicherheitsregeln für diese Stufe gewährleisten zusätzlich zur Sicherheitsstufe Eins, dass die vom entsprechenden Dienst verwendete Software aus Code besteht, der in einer bestimmten Codebasis (z. B. der Codebasis von Google Mail) bewertet (Code Review) und getestet wurde. Ab Februar 2020 ist diese Stufe die Standardschutzstufe für alle Google-Dienste.

Sicherheitsstufe 3: Vertrauenswürdiger Code und Konfiguration. Die Sicherheitsregeln für diese Stufe stellen sicher, dass zusätzlich zur Sicherheitsstufe zwei die vom entsprechenden Dienst verwendeten Konfigurationsdateien denselben Sicherheitsprozess durchlaufen haben wie Code (Configuration as Code). Ab Februar 2020 ist diese Stufe die Standardstufe für alle Google Priority Protection-Dienste.

Alarm- und Berechtigungssysteme

Um eine reibungslose Migration für alle Beteiligten zu ermöglichen, verbieten wir im Zuge der Förderung von Zero Trust nicht direkt jeden nicht konformen Zugriff auf die Sicherheitsregeln, sondern bieten in den Sicherheitsregeln selbst zwei Modi an, das Alarmsystem und das Autorisierungssystem. Im Alarmsystem werden Zugriffe, die gegen die Sicherheitsregeln verstoßen, nicht blockiert, sondern protokolliert und die zuständigen Mitarbeiter benachrichtigt, während im Autorisierungssystem Zugriffe, die gegen die Sicherheitsregeln verstoßen, sofort blockiert werden. Das Vorhandensein dieses dualen Systems bietet die Möglichkeit, nicht konforme Verhaltensweisen auf der Grundlage von Alarmen zu wiederholen und zu verbessern, während es gleichzeitig einen wirksamen Mechanismus zur Verschärfung der Sicherheitsregeln und zur Verhinderung von Rückschritten bietet, sobald nicht konforme Verhaltensweisen beseitigt wurden.

Sicherheit und Stabilität.

Die Komplexität von Zero Trust bringt auch neue Herausforderungen bei der Aufrechterhaltung der Systemstabilität (Zuverlässigkeit) mit sich. In der Praxis von Zero Trust sehen wir für die meisten Szenarien einen Break-Glass-Mechanismus vor. Dadurch wird sichergestellt, dass der Betreiber in einem Notfall die Grenzen des Zero-Trust-Systems durchbrechen kann, um einige komplexe Notfallmaßnahmen durchzuführen. Um die Sicherheit zu gewährleisten, wird das Sicherheitsteam alarmiert, sobald der Break-glass-Mechanismus ausgelöst wird, und alle Vorgänge im Rahmen des Break-glass-Mechanismus werden in Sicherheitsprotokollen aufgezeichnet. Diese Sicherheitsprotokolle werden geprüft, um die Notwendigkeit des Aufbrechens von Wänden zu verifizieren. Diese Sicherheitsprotokolle helfen auch bei der Entwicklung neuer vertrauenswürdiger Funktionen, um zu vermeiden, dass in ähnlichen Situationen erneut der "Break-glass"-Mechanismus zum Einsatz kommt.

Schwerpunkt auf endogenen Risiken

Aus der Sicht der Verteidigung ist das endogene Risiko eine Obermenge des exogenen Risikos: Wenn ein Angreifer das Gerät eines Insiders (eines rechtmäßigen Benutzers oder Mitarbeiters) kompromittiert, wird der Angreifer zu einem Insider, so dass sowohl der externe Angreifer als auch der interne Verletzer als endogenes Risiko eingestuft werden. Null-Vertrauen aus dieser Perspektive geht davon aus, dass jeder Host kompromittiert werden kann.

Sicherheitsinfrastruktur

Die Umsetzung von Zero Trust stützt sich auf eine solide Sicherheitsarchitektur, ohne die es keinen Überbau geben kann. Google Zero Trust stützt sich auf die grundlegende Sicherheit, die durch die folgende Infrastruktur gewährleistet wird:

1. Datenverschlüsselung und Schlüsselverwaltung (Verschlüsselung und Schlüsselverwaltung)
2. Identitäts- und Zugriffsmanagement (IAM)
3. Digitale Humanressourcen (DHR)
4. Digitale Geräteverwaltung (DDM)
5. Sicherheit im Rechenzentrum
6. Netzwerksicherheit(Netzwerksicherheit)
7. Host-Sicherheit
8. Container-Isolierung (gVisor)
9. Vertrauenswürdiges Boot
10. Überprüfbarer Aufbau
11. Überprüfung der Software-Integrität (SIV)
12. Zwei-Wege-TLS (mTLS)
13. Dienstzugangspolitik (dienstbasierte Zugangspolitik)
14. Endbenutzer-Kontext-Token (EUT)
15. Konfiguration als Code (Konfiguration als Code)
16. Standardisierte Entwicklung und Bereitstellung (SDD)

der Rest

Zusätzlich zu den oben genannten Lektionen sind klein anfangen, dann iterieren, Defense in depth, Quantify return over investment, Senkung der Kosten durch Homogenität, Shifting left usw. ebenfalls Leitlinien, die wir in der Praxis gesammelt haben. Kostenreduzierung durch Homogenität), Linksverschiebung usw. sind ebenfalls Leitlinien, die wir in der Praxis gesammelt haben und hier nicht wiederholen werden.

zu einem Urteil gelangen

Um eine gute Arbeit von Null Vertrauen zu tun, 20% stützt sich auf die Theorie, 80% stützt sich auf die Praxis. Die praktische Lösung von Null-Vertrauen ist nicht einzigartig, der Autor hofft, dass durch die gemeinsame Nutzung der oben genannten ein Beispiel für Null-Vertrauen der Praxis, um den Zweck des Werfens Ziegel zu gewinnen Jade zu erreichen. Kritik ist willkommen!