Binärautorisierung für Borg

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

In diesem Dokument wird beschrieben, wie wir Codeüberprüfungen, Sicherheitsinfrastruktur und eine Erzwingungsprüfung namens Binärautorisierung für Borg (BAB) verwenden, um die Softwarelieferkette von Google vor Insiderrisiken zu schützen. BAB reduziert das Insiderrisiko, da es sicherstellt, dass Produktionssoftware vor der Bereitstellung überprüft und genehmigt wird, insbesondere wenn unser Code auf sensible Daten zugreifen kann. BAB gilt für alle Dienste, die auf Borg ausgeführt werden. Seit der ursprünglichen Veröffentlichung dieses Dokuments haben wir wichtige Konzepte von BAB in eine offene Spezifikation namens Supply Chain Levels for Software Artifacts (SLSA) aufgenommen.

Dieses Dokument ist Teil einer Reihe technischer Dokumentationen, die einige Projekte beschreiben, die das Google-Sicherheitsteam zur Verbesserung der Sicherheit entwickelt hat, darunter BeyondCorp und BeyondProd. Eine Übersicht über die Sicherheit unserer Infrastruktur finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.

Einleitung

Insiderrisiken stellen eine Bedrohung für die Sicherheit von Nutzerdaten dar, einschließlich Beschäftigungsdaten, Finanzdaten und andere proprietäre oder Geschäftsdaten. Ein Insiderrisiko ist das Risiko, dass ein Mitarbeiter firmeninternes Wissen oder Zugriffsberechtigungen für schädliche Handlungen nutzt, oder dass ein externer Angreifer die manipulierten Anmeldedaten eines Mitarbeiters für diese Zwecke nutzt.

Verwenden Sie BAB, um Insiderrisiken innerhalb unserer Softwarelieferkette zu minimieren. BAB ist eine interne Erzwingungsprüfung, die bei der Bereitstellung von Software durchgeführt wird. BAB sorgt dafür, dass Code- und Konfigurationsbereitstellungen bestimmte Mindeststandards erfüllen und die Einheitlichkeit in unseren Produktionssystemen unterstützen.

Zum Schutz der Nutzerdaten in unseren Produktionssystemen verhindern wir den einseitigen Zugriff durch unsere Mitarbeiter. BAB sorgt dafür, dass Mitarbeiter ohne direkte Autorisierung und Begründung weder direkt noch indirekt auf Nutzerdaten zugreifen oder diese anderweitig beeinflussen können. BAB und die zugehörigen Kontrollen unterstützen uns bei der Durchsetzung der geringsten Berechtigung, wodurch unser Sicherheitsstatus unabhängig von einem bestimmten Bedrohungsnutzer verbessert wird. Mit anderen Worten: BAB beschränkt den einseitigen Zugriff, unabhängig davon, ob der Akteur böswillige Absichten hat, sein Konto manipuliert wurde oder ob ihm unbeabsichtigt Zugriff gewährt wurde.

Vorteile von BAB

Die Verwendung von BAB und eines containerisierten Bereitstellungsmodells bietet viele Sicherheitsvorteile für die Google-Infrastruktur. Hier sind einige dieser Vorteile:

  • BAB hilft bei der Reduzierung von Insiderrisiken: BAB erfordert Code, um bestimmte Standards und Änderungsmanagementpraktiken zu erfüllen, bevor der Code auf Nutzerdaten zugreifen kann. Diese Anforderung verringert das Risiko, dass ein Mitarbeiter allein (oder ein manipuliertes Mitarbeiterkonto) programmatisch auf Nutzerdaten zugreift.
  • BAB unterstützt die Einheitlichkeit von Produktionssystemen: Durch die Verwendung von containerisierten Systemen und die Überprüfung ihrer BAB-Anforderungen vor der Bereitstellung sind unsere Systeme einfacher zu debuggen, sie sind zuverlässiger und haben klar definierte Änderungsmanagementprozesse. Die BAB-Anforderungen stellen eine gemeinsame Sprache für die Anforderungen des Produktionssystems dar.
  • BAB schreibt eine gemeinsame Sprache für den Datenschutz vor: BAB verfolgt die Konformität in Systemen von Google. Daten zu dieser Konformität werden intern veröffentlicht und stehen anderen Teams zur Verfügung. Wenn Sie BAB-Daten veröffentlichen, können Teams häufig verwendete Begriffe verwenden, wenn sie miteinander über ihren Datenzugriffsschutz kommunizieren. Durch diese gemeinsame Sprache wird der Aufwand, der für die teamübergreifende Arbeit mit Daten erforderlich ist, vereinfacht.
  • BAB ermöglicht das programmatische Tracking von Compliance-Anforderungen: BAB vereinfacht die bisher manuellen Compliance-Aufgaben. Bestimmte Prozesse bei Google erfordern strengere Kontrollen im Umgang mit Daten. Unsere Finanzberichtssysteme müssen beispielsweise dem Sarbanes-Oxley Act (SOX) entsprechen. Vor BAB hatten wir ein System, das uns bei der manuellen Durchführung von Überprüfungen half, um unsere Compliance sicherzustellen. Mit der Einführung von BAB wurden viele dieser Prüfungen auf Grundlage der BAB-Richtlinien für die Dienste automatisiert. Durch die Automatisierung dieser Prüfungen konnte das Compliance-Team sowohl den Umfang der Dienste als auch den Einsatz geeigneter Kontrollmaßnahmen für diese Dienste erhöhen.

BAB ist Teil des größeren BeyondProd-Frameworks, mit dem wir Insiderrisiken minimieren.

Unser Entwicklungs- und Produktionsprozess

Der Entwicklungs- und Produktionsprozess von Google umfasst standardmäßig vier obligatorische Schritte: Codeüberprüfung, überprüfbare Builds, containerisierte Bereitstellung und dienstbasierte Identität. Diese Schritte werden in den folgenden Abschnitten näher erläutert.

Schritt 1: Überprüfung des Codes

Der Großteil unseres Quellcodes wird in einemzentralen monolithischen Repository, gespeichert und muss von mindestens einem anderen Entwickler als dem Autor geprüft und genehmigt werden . Eine monolithische Codebasis ermöglicht die Erzwingung eines einzigen „Nadelöhrs“ für Codeüberprüfungen.

Bei unserem Codeüberprüfungsprozess müssen die Inhaber eines Systems mindestens Codeänderungen an diesem System genehmigen.

Beim Importieren von Änderungen vaus Drittanbieter- oder Open-Source-Code prüfen wir, ob die Änderung angemessen ist (z. B. die aktuelle Version). Häufig haben wir jedoch nicht dieselben Überprüfungseinstellungen für jede Änderung, die externe Entwickler an dem von uns verwendeten Drittanbieter- oder Open-Source-Code vornehmen.

Schritt 2: Überprüfbare Builds

Unser Build-System ähnelt Bazel, das Quellcodes erstellt und kompiliert, um eine Binärdatei zur Bereitstellung zu erstellen. Unser Build-System wird in einer isolierten und gesperrten Umgebung ausgeführt , die von den Mitarbeitern getrennt ist, die die Builds ausführen. Für jeden Build erzeugt das System die Herkunft, die von überprüfbaren Builds generiert wird . Diese Herkunft ist ein signiertes Zertifikat, das die Quellen und Abhängigkeiten beschreibt, die in den Build eingegangen sind, die kryptografischen Hashes aller Binärdateien oder anderen Build-Artefakte sowie die vollständigen Build-Parameter. Diese Herkunft ermöglicht Folgendes:

  • Die Möglichkeit, ein Binärprogramm zum Quellcode zu verfolgen, der beim Erstellen verwendet wurde. Durch die Erweiterung kann die Herkunft auch den Prozess zum Erstellen und Senden des beschriebenen Quellcodes verfolgen.
  • Die Möglichkeit, zu prüfen, ob die Binärdatei nicht geändert wurde, da Änderungen an der Datei automatisch zur Ungültigkeit der Signatur führen würden.

Da Build-Aktionen beliebiger Code sein können, wurde unser Build-System für Mehrmandantenfähigkeit optimiert. Mit anderen Worten soll unser Build-System verhindern, dass ein Build andere Builds beeinflusst. Das System verhindert, dass Builds Änderungen vornehmen, die die Integrität der Build-Herkunft oder des Systems selbst beeinträchtigen könnten. Sobald der Build abgeschlossen ist, wird die Änderung mithilfe von Borg bereitgestellt.

Schritt 3: Containerisierte Bereitstellung

Nachdem das Build-System die Binärdatei erstellt hat, wird sie in ein Container-Image verpackt und als Borg-Job in unserem Cluster-Orchestrierungssystem Borg bereitgestellt. Wir führen Hunderttausende von Jobs aus vielen verschiedenen Anwendungen in mehreren Clustern mit jeweils bis zu Zehntausenden von Computern aus. Trotz dieser Größenordnung ist unsere Produktionsumgebung ziemlich homogen. Dadurch können die Touchpoints für den Zugriff auf Nutzerdaten leichter kontrolliert und geprüft werden.

Container bieten erhebliche Sicherheitsvorteile. Container sind immer unveränderlich, sodass es häufig zu Neubereitstellungen aus einer vollständigen Image-Neuerstellung kommt. Dadurch können wir eine Codeänderung im Kontext überprüfen, und Änderungen, die in unserer Infrastruktur bereitgestellt werden, müssen durch ein „Nadelöhr“.

Die Konfiguration eines Borg-Jobs gibt die Anforderungen für den bereitzustellenden Job an: Container-Images, Laufzeitparameter, Argumente und Flags. Borg plant den Job unter Berücksichtigung der Beschränkungen, der Priorität, des Kontingents und aller anderen in der Konfiguration aufgeführten Anforderungen. Nach der Bereitstellung kann der Borg-Job mit anderen Jobs in der Produktion interagieren.

Schritt 4: Dienstbasierte Identität

Ein Borg-Job wird als Dienstidentität ausgeführt. Diese Identität wird für den Zugriff auf Datenspeicher oder Remoteprozeduraufruf-Methoden (RPC) anderer Dienste verwendet. Mehrere Aufträge können als identische Identität ausgeführt werden. Nur diejenigen Mitarbeiter, die für die Ausführung des Dienstes verantwortlich sind (in der Regel Site Reliability Entwickler (SREs)) können Jobs mit einer bestimmten Identität bereitstellen oder ändern.

Wenn Borg einen Job startet, wird der Job mit kryptografischen Anmeldedaten bereitgestellt. Der Job verwendet diese Anmeldedaten, um seine Identität zu bestätigen, wenn er Anfragen an andere Dienste stellt (mithilfe von Application Layer Transport Security (ALTS)). Damit ein Dienst auf bestimmte Daten oder einen anderen Dienst zugreifen kann, muss seine Identität die erforderlichen Berechtigungen haben.

Unsere Richtlinien erfordern den BAB-Schutz für Dienstidentitäten, die Zugriff auf Nutzerdaten und andere vertrauliche Informationen haben. Jobs zur Qualitätssicherung und Entwicklung, die keinen Zugriff auf sensible Daten haben, dürfen mit weniger Kontrollmaßnahmen ausgeführt werden.

Funktionsweise von BAB

BAB kann in Borg eingebunden werden, um sicherzustellen, dass nur autorisierte Jobs mit der Identität jedes Dienstes ausgeführt werden dürfen. BAB erstellt auch einen Audit-Trail des Codes und der Konfiguration, die in BAB-fähigen Jobs verwendet werden, um Monitoring und Reaktion auf Vorfälle zu ermöglichen.

BAB soll dafür sorgen, dass die gesamte Produktionssoftware und -konfiguration ordnungsgemäß überprüft, eingecheckt, autorisiert und zuverlässig erstellt wird, insbesondere wenn dieser Code auf Nutzerdaten zugreifen kann.

Dienstspezifische Richtlinie

Wenn Dienstinhaber ihren Dienst für BAB einrichten, erstellen sie eine BAB-Richtlinie, die die Sicherheitsanforderungen für ihren Dienst festlegt. Diese Richtlinie wird als dienstspezifische Richtlinie bezeichnet. Das Festlegen oder Ändern einer Richtlinie ist ebenfalls eine Codeänderung, die überprüft werden muss.

Die dienstspezifische Richtlinie definiert, welcher Code und welche Konfiguration als Identität des Dienstes ausgeführt werden dürfen, und bestimmt die erforderlichen Attribute dieses Codes und der Konfiguration. Alle als Dienstidentität ausgeführten Jobs müssen die dienstspezifische Richtlinie erfüllen.

Alle Borg-Dienste bei Google müssen eine dienstspezifische Richtlinie konfigurieren.

Diese Vorgehensweise erzwingt standardmäßig die folgenden Anforderungen:

  • Code muss prüfbar sein: Wir können das Container-Image zu seinem für Menschen lesbare Quellen über die Herkunft zurückverfolgen, die durch überprüfbare Builds generiert wird. Eine Aufbewahrungsrichtlinie speichert die für Menschen lesbaren Quellen des Codes mindestens 18 Monate lang, selbst wenn der Code nicht gesendet wurde.
  • Der Code muss gesendet werden: Der Code wird aus einem angegebenen, definierten Speicherort in unserem Quell-Repository erstellt. Das Senden des Codes bedeutet normalerweise, dass der Code einer Codeüberprüfung unterzogen wurde.
  • Konfigurationen müssen gesendet werden: Alle Konfigurationen, die während der Bereitstellung angegeben werden, durchlaufen denselben Überprüfungs- und Sendungsprozess wie regulärer Code. Daher können Befehlszeilen-Flag-Werte, Argumente und Parameter nicht ohne Überprüfung geändert werden.

Dienste, die keinen Zugriff auf sensible Daten haben – oder in seltenen Fällen auch Dienste mit einer gültigen und genehmigten Ausnahme – haben möglicherweise eine tolerantere Richtlinie, z. B. eine, die nur die Nachvollziehbarkeit von Code erfordert, oder sogar eine, die BAB vollständig deaktiviert.

Die Systeme und Komponenten, die BAB erzwingen, werden mithilfe strenger automatisierter Anforderungen und zusätzlicher manueller Kontrollen streng kontrolliert.

Erzwingungsmodi

BAB sorgt anhand von zwei Erzwingungsmodi dafür, dass alle Jobs der dienstspezifischen Richtlinie entsprechen:

  • Erzwingung bei der Bereitstellung: Die Bereitstellung nicht konformer Jobs wird blockiert.
  • Kontinuierliche Validierung: Nicht konforme Jobs, die bereitgestellt wurden, werden überwacht und entsprechende Benachrichtigungen werden gesendet.

Darüber hinaus können im Notfall die Erzwingungszeiten bei der Bereitstellung umgangen werden.

Modus „Erzwingung bei der Bereitstellung“

Borg Prime ist der zentrale Controller von Borg, der als Zertifizierungsstelle für ALTS fungiert. Wenn ein neuer Job gesendet wird, überprüft Borg Prime mithilfe von BAB, ob der Job den dienstspezifischen Richtlinienanforderungen entspricht, bevor Borg Prime dem Job das ALTS-Zertifikat zuweist. Diese Prüfung fungiert als Zugriffskontrolle: Borg startet den Job nur, wenn die dienstspezifische Richtlinie erfüllt wird. Diese Prüfung erfolgt auch dann, wenn der Mitarbeiter oder Dienst, der die Bereitstellungsanfrage stellt, anderweitig autorisiert wird.

In seltenen Fällen können Dienste die Erzwingung bei der Bereitstellung mit einer angemessenen Begründung deaktivieren.

Modus „Kontinuierliche Überprüfung“

Nach der Bereitstellung wird ein Job während seiner Lebensdauer kontinuierlich überprüft, unabhängig vom Erzwingungsmodus bei der Bereitstellung. Ein BAB-Prozess wird mindestens einmal am Tag ausgeführt, um zu prüfen, ob alle gestarteten und möglicherweise noch immer ausgeführten Jobs den Aktualisierungen ihrer Richtlinien entsprechen. Im Modus „Kontinuierliche Überprüfung“ wird beispielsweise kontinuierlich nach Jobs gesucht, die mit veralteten Richtlinien ausgeführt werden oder mithilfe von Notfallmaßnahmen bereitgestellt wurden. Wenn ein Job gefunden wird, der nicht der neuesten Richtlinie entspricht, benachrichtigt BAB die Dienstinhaber, damit sie das Risiko minimieren können.

Notfallmaßnahmen

Wenn ein Vorfall oder ein Ausfall auftritt, ist unsere oberste Priorität, den betroffenen Dienst so schnell wie möglich wiederherzustellen. In einem Notfall kann es erforderlich sein, Code auszuführen, der noch nicht überprüft oder überprüfbar erstellt wurde. Daher kann der Erzwingungsmodus mit dem Flag für Notfallmaßnahmen überschrieben werden. Notfallmaßnahmen dienen auch als Back-up für den Fall, dass ein BAB-Fehler auftritt, der eine Bereitstellung andernfalls blockieren würde. Wenn ein Entwickler einen Job mithilfe der Notfallmaßnahmen bereitstellt, muss er im Rahmen seiner Anfrage eine Begründung senden.

Während einer Notfallmaßnahme protokolliert BAB Details zum zugehörigen Borg-Job und sendet eine Benachrichtigung sowohl an das zentrale Sicherheitsteam von Google als auch an das Team, dem die Dienstidentität gehört. Der Logeintrag enthält einen Verweis auf einen Snapshot des bereitgestellten Codes und die vom Nutzer angegebene Begründung. Notfallmaßnahmen sind jedoch nur als letztes Mittel gedacht.

BAB auf andere Umgebungen erweitern

Anfangs unterstützte BAB nur den Schutz von Borg-Jobs und erforderte, dass die Software mit der herkömmlichen Versions-, Build- und Paketpipeline von Google entwickelt wurde. BAB bietet jetzt Unterstützung für den Schutz anderer Umgebungen für Softwarebereitstellung und -Deployment sowie für alternative Versionsverwaltung, Build- und Verpackungssysteme. Die Implementierungsdetails für diese verschiedenen Umgebungen unterscheiden sich, aber die Vorteile von BAB bleiben bestehen.

Es gibt einige Fälle, die sich vor der Bereitstellung nicht gut für manuelle Codeüberprüfungen eignen, insbesondere die iterative Entwicklung von Code für maschinelles Lernen und häufige Datenanalysen. In diesen Fällen haben wir alternative Kontrollmöglichkeiten, die eine manuelle Überprüfung kompensieren.

Ähnliche Kontrollmaßnahmen in Ihrer Organisation verwenden

In diesem Abschnitt werden die Best Practices beschrieben, die wir bei der Implementierung von BAB erlernt haben, damit Sie ähnliche Kontrollen in Ihrer Organisation anwenden können.

Homogene, containerisierte CI/CD-Pipeline erstellen

Die Einführung von BAB wurde vereinfacht, da die meisten Teams ein einziges Versionsverwaltungssystem, Code-Review-Prozess, Build-System- und Bereitstellungssystem verwendet haben. Codeüberprüfungen waren bereits Teil unserer Kultur, sodass wir Änderungen vornehmen konnten, ohne dass diese für den Nutzer zu sichtbar wären. Bei der Einführung von BAB haben wir uns auf Codeüberprüfungen, überprüfbare Builds, containerisierte Bereitstellungen und dienstbasierte Identitäten für die Zugriffskontrolle konzentriert. Dieser Ansatz vereinfachte die Einführung von BAB und sorgte für eine Stärkung der Garantien, die eine Lösung wie BAB bietet.

Unsere weit verbreitete Verwendung von Mikrodiensten und dienstbasierten Identitäten (z. B. Dienstkonten) anstelle von hostbasierten Identitäten (z. B. IP-Adressen) ermöglicht uns eine detailgenaue Kontrolle über die Software, die die einzelnen Dienste ausführen darf.

Wenn Ihre Organisation eine Dienstidentität nicht direkt übernehmen kann, können Sie als Zwischenschritt versuchen, Identitätstokens mit anderen Maßnahmen zu schützen.

Ihre Ziele bestimmen und Richtlinien entsprechend Ihren Anforderungen definieren

Erstellen Sie Ihren richtlinienbasierten Freigabeprozess Stück für Stück. Möglicherweise müssen Sie bestimmte Änderungen früher als andere in Ihrer CI/CD-Pipeline implementieren. Sie sollten beispielsweise mit der Durchführung formaler Codeüberprüfungen beginnen, bevor Sie sie zur Bereitstellungszeit erzwingen können.

Eine wichtige Motivation für einen richtlinienbasierten Freigabeprozess ist die Compliance. Wenn Sie zumindest einige Ihrer Compliance-Anforderungen in einer Richtlinie codieren können, können Sie Ihre Tests automatisieren und dafür sorgen, dass die Anforderungen zuverlässig gelten. Beginnen Sie mit einer Reihe grundlegender Anforderungen und legen Sie anschließend erweiterte Anforderungen fest.

Richtlinien bereits in der Entwicklungsphase erzwingen

Es ist schwierig, umfassende Richtlinien für eine bestimmte Software zu definieren, ohne vorher zu wissen, wo sie ausgeführt wird und auf welche Daten sie zugreift. Daher wird die dienstspezifische Richtlinienerzwingung durchgeführt, wenn Code bereitgestellt wird und wenn er auf Daten zugreift, und nicht, wenn er erstellt wird. Eine Richtlinie wird in Bezug auf eine Laufzeitidentität definiert. Daher kann derselbe Code in verschiedenen Umgebungen ausgeführt werden und unterschiedlichen Richtlinien unterliegen.

Wir verwenden BAB zusätzlich zu anderen Zugriffsmechanismen, um den Zugriff auf Nutzerdaten zu beschränken. Dienstinhaber können außerdem dafür sorgen, dass nur Jobs, die bestimmten BAB-Anforderungen entsprechen, auf Daten zugreifen können.

Teamübergreifende Change Agents rekrutieren

Als wir ein Google-weites Mandat für die BAB-Bereitstellung erstellten, hingen unsere Erfolgsaussichten vor allem davon ab, Inhaber zu finden, die die Änderung in jeder Produktgruppe vorantreiben. Wir haben eine Reihe von Dienstinhabern ermittelt, die sofort von der Erzwingung profitieren konnten und bereit waren, Feedback zu geben. Wir haben diese Inhaber gebeten, sich freiwillig anzumelden, bevor diese Änderungen erforderlich wurden. Nachdem wir ihre Hilfe erhalten hatten, richteten wir ein formelles Team für das Änderungsmanagement ein, um die laufenden Änderungen nachzuverfolgen. Anschließend haben wir in jedem Produktteam für die Implementierung der Änderungen verantwortliche Inhaber ausgewählt.

Verwaltung von Drittanbietercode festlegen

Wenn Sie Drittanbietercode verwalten müssen, sollten Sie prüfen, wie Sie Ihre Richtlinienanforderungen in die Codebasis des Drittanbieters einführen. Sie können beispielsweise anfangs ein Repository mit dem gesamten verwendeten Drittanbietercode führen. Wir empfehlen Ihnen, diesen Code regelmäßig auf Ihre Sicherheitsanforderungen zu prüfen.

Weitere Informationen zum Verwalten von Drittanbietercode finden Sie unter Gemeinsamer Erfolg beim Erstellen einer sicheren Open-Source-Community.

Nächste Schritte