Binärautorisierung für Borg: So überprüft Google die Herkunft von Codes und implementiert die Codeidentität

Google hat mehrere Whitepapers zu Projekten verfasst, die unser Sicherheitsteam intern zur Verbesserung der Sicherheit entwickelt hat, darunter BeyondCorp und BeyondProd. Eine Übersicht über die Sicherheit bei Google finden Sie im Whitepaper zum Sicherheitsdesign der Infrastruktur.

In diesem Whitepaper beschreiben wir den Überprüfungsprozess von Google-Code, die Herkunft des Codes1 und die Notwendigkeit von Erzwingungsmechanismen. Wir konzentrieren uns auf die Entwicklung einer spezifischen Erzwingungsprüfung: die Binärautorisierung für Borg (BAB). Das Ziel von BAB ist es, Insiderrisiken zu reduzieren. Dazu wird sichergestellt, dass bei Google bereitgestellte Produktionssoftware ordnungsgemäß überprüft und autorisiert wird, insbesondere wenn solche Codes auf Nutzerdaten zugreifen können. Bei allen Google-Produkten legen wir Wert auf den Schutz von Nutzerdaten und möchten die von uns ergriffenen Sicherheitsmaßnahmen so transparent wie möglich gestalten.

Der Inhalt dieses Whitepapers basiert auf den im Dezember 2019 vorliegenden Informationen. Dieses Dokument gibt damit den Stand zu dem Zeitpunkt wieder, als es verfasst wurde. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kunden kontinuierlich verbessern.

Zusammenfassung für CIOs

  • Insiderrisiken stellen eine Gefahr für die Sicherheit von Nutzerdaten dar. Wir bei Google möchten mit allen möglichen Vorkehrungen dafür sorgen, dass Google-Mitarbeiter ihre Kenntnisse zur Organisation oder ihren Zugriff auf Nutzerdaten nicht unbefugt nutzen können. Dazu gehört auch das Ausführen eines nicht autorisierten Jobs.
  • Binärautorisierung für Borg, kurz BAB, ist eine interne Erzwingungsprüfung bei der Bereitstellung, die Insiderrisiken minimiert. Zu diesem Zweck wird sichergestellt, dass die bei Google bereitgestellte Produktionssoftware und -konfiguration ordnungsgemäß überprüft und autorisiert wird, insbesondere wenn solche Codes auf Nutzerdaten zugreifen können.
  • BAB sorgt dafür, dass Code- und Konfigurationsbereitstellungen bestimmte Mindeststandards erfüllen.
  • Neben der Erzwingung kann BAB auch in einem nicht erzwingenden Prüfmodus verwendet werden, um Warnungen auszugeben, wenn bestimmte Anforderungen nicht erfüllt sind.
  • Durch die Implementierung von BAB kann Google Insiderrisiken reduzieren, mögliche Angriffe verhindern und die Einheitlichkeit der Produktionssysteme von Google unterstützen.

Minimierung des Insiderrisikos bei Google

Als ein Unternehmen, bei dem Sicherheit oberste Priorität hat, haben wir Maßnahmen ergriffen, um das Insiderrisiko zu begrenzen. Dieses Risiko bezeichnet das Potenzial von Google-Mitarbeitern (oder einer anderen Person in der Organisation), ihr Wissen über die Organisation oder ihre Zugriffsrechte für böswillige Handlungen zu nutzen. Das Insiderrisiko umfasst auch Szenarien, bei denen Angreifer die Anmeldedaten einer Person bei Google manipulieren, um einen Angriff zu ermöglichen. Wir haben umfangreiche Ressourcen für Innovationen im Bereich des Insiderrisikoschutzes bereitgestellt. Bei Google ist die Sicherung von Nutzerdaten von größter Bedeutung und wir bemühen uns, diese Daten umfassend zu schützen. Wir möchten verhindern, dass Google-Mitarbeiter unbefugt auf Nutzerdaten zugreifen.

Autorisierung für den Zugriff auf Nutzerdaten

Bei Google müssen Dienste und Mitarbeiter manchmal auf Nutzerdaten zugreifen. Wir interagieren auf folgende Weise mit Nutzerdaten:

  1. Als Endnutzer: Ein Mitarbeiter, der einen Dienst verwendet, authentifiziert sich direkt beim Dienst und der Dienst gibt dessen Daten zurück. Ein Mitarbeiter, der sich beispielsweise in seinem Gmail-Konto anmeldet, sieht seine eigenen E-Mails.
  2. Als Teil ihrer Arbeit: Google-Mitarbeiter können den Großteil ihrer Arbeit mithilfe von anonymisierten Nutzerdaten erfolgreich ausführen. Doch in seltenen Fällen benötigen unsere Mitarbeiter Zugriff auf Nutzerdaten im Rahmen ihres Jobs, z. B. für den Support oder zur Fehlerbehebung. Unser Ziel ist es, Nutzerdatenzugriffe so transparent wie möglich zu gestalten. Dies erreichen wir unter anderem mit Access Transparency, einem Feature, mit dem Google Cloud-Kunden über Echtzeitprotokolle berechtigte Zugriffe auf ihre Daten sehen können.
  3. Als Teil eines Dienstes, programmatisch: Ein Dienst muss möglicherweise in großem Umfang programmatisch auf Nutzerdaten zugreifen, um eine Aufgabe abzuschließen. Beispiel: Eine Datenpipeline fragt Tausende von Nutzerdaten gleichzeitig ab, um aggregierte Nutzungsstatistiken zu erzeugen. Wenn es einen solchen Bedarf gibt, wird der Zugriff auf ein Dataset statt auf die Daten eines einzelnen Nutzers gewährt. Der Zugriff auf die Daten jedes einzelnen Nutzers wird nicht protokolliert.

In diesem Whitepaper geht es um das Bedrohungsmodell im dritten Szenario. Wir möchten sicher sein, dass die Administratoren, die die Systeme mit Zugriff auf Nutzerdaten ausführen, ihre Befugnisse nicht missbrauchen können.

Bedrohungsmodell

Die in diesem Artikel erläuterten Kontrollen wurden entwickelt, um Nutzerdaten zu schützen und einseitige Zugriffe zu verhindern. Wir möchten verhindern, dass Google-Mitarbeiter eigenmächtig direkt oder indirekt ohne ordnungsgemäße Autorisierung und Begründung auf Nutzerdaten zugreifen oder diese anderweitig beeinflussen. Unsere Kontrollen verhindern diese Handlungen unabhängig davon, ob der Akteur böswillige Absichten hat, sein Konto manipuliert wurde oder ob ihm unbeabsichtigt eine Autorisierung erteilt wurde.

Die containerisierte Infrastruktur von Google

Unsere Infrastruktur wird mithilfe eines Clusterverwaltungssystems namens Borg containerisiert. 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.

Außerdem haben wir durch die Verwendung von Containern erhebliche Sicherheitsvorteile erzielt. Container sollen unverändert verwendet werden, 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 alle Änderungen, die in unserer Infrastruktur bereitgestellt werden, müssen durch ein "Nadelöhr".

Bevor wir auf das Entwickeln einer Lösung eingehen, die den programmatischen Zugriff auf Nutzerdaten durch einen Dienst einschränkt, soll zuerst erläutert werden, wie ein Dienst bei Google in Produktion geht.

Schritt 1: Überprüfung des Codes

Unser Quellcode wird in einem monolithischen zentralen Repository gespeichert, über das Tausende von Mitarbeitern Codes an einem einzigen Ort einchecken können. Da wir eine einzige Codebasis verwenden, können wir Quellcodes leichter verwalten, insbesondere wenn es um unsere Abhängigkeiten von Drittanbietercode geht. Eine monolithische Codebasis ermöglicht außerdem die Erzwingung eines einzigen "Nadelöhrs" für Codeüberprüfungen. Bei Google umfassen Codeüberprüfungen die Untersuchung und Genehmigung durch mindestens einen anderen Entwickler als dem Autor. Unser Codeüberprüfungsprozess erzwingt eine Regel, nach der Codeänderungen an einem System mindestens von den Inhabern des Systems genehmigt werden müssen. Sobald der Code eingecheckt ist, wird er erstellt.

Beim Importieren von Änderungen aus Drittanbieter- oder Open-Source-Code überprü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

Wir verwenden ein Build-System, das Bazel sehr ähnlich ist. Es erstellt und kompiliert Quellcode und erstellt eine Binärdatei zur Bereitstellung. 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 ein überprüfbares Build-Manifest, also ein signiertes Zertifikat, das die in den Build eingehenden Quellen, die kryptografischen Hashes aller Binärdateien oder anderer Build-Artefakte sowie die kompletten Build-Parameter vollständig beschreibt. Mit diesem Manifest können wir eine Binärdatei auf den Quellcode zurückführen, der bei ihrer Erstellung verwendet wurde, und im weiteren Verlauf auf die Erstellung und Übermittlung des beschriebenen Quellcodes. Außerdem können wir anhand des Manifests gewährleisten, dass die Binärdatei nicht geändert wurde, da jede Änderung an der Datei automatisch zur Ungültigkeit der Signatur führen würde.

Weil Build-Aktionen theoretisch ein 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 überprüfbaren Build-Manifeste oder des Systems selbst beeinträchtigen könnten. Sobald der Build abgeschlossen ist, wird die Änderung mithilfe von Borg bereitgestellt.

Schritt 3: Bereitstellungsjobs

Nach der Erstellung kann eine Binärdatei in unserer containerisierten Infrastruktur als Borg-Job bereitgestellt werden. Diese Jobs verwenden Pakete, die möglicherweise Binärdateien oder Daten enthalten, deren Installation von Borg verwaltet wird. Eine Borg-Konfiguration legt die Anforderungen für den bereitzustellenden Job fest: die Pakete, die Laufzeitparameter, die Argumente und die 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: Jobidentität

Ein Borg-Job wird als Identität ausgeführt. Diese Identität wird verwendet, um auf Datenspeicher oder RPC-Methoden (Remote Procedure Calls) anderer Dienste zuzugreifen. Eine Identität kann entweder ein Rollenkonto (z. B. ein Dienst) oder ein Nutzerkonto sein (z. B. das individuelle Konto eines Mitarbeiters). Mehrere Aufträge können als identische Identität ausgeführt werden. Wir schränken die Möglichkeit, Jobs mit einer bestimmten Identität bereitzustellen oder zu ändern, für diejenigen Mitarbeiter ein, die für die Ausführung des Dienstes verantwortlich sind – in der Regel unsere Site Reliability Engineers (SREs).

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). Damit ein Dienst auf bestimmte Daten oder einen anderen Dienst zugreifen kann, muss seine Identität die erforderlichen Berechtigungen haben. Werfen wir einen Blick auf das Beispiel eines Dienstes wie der Cloud Data Loss Prevention (Cloud DLP) API von Google Cloud. Damit die DLP API auf Daten zum Scannen zugreifen kann, sind zwei Dinge erforderlich. Zuerst muss die DLP API so konfiguriert werden, dass sie mit einer eindeutigen Identität, in diesem Fall einem Rollenkonto, ausgeführt wird. Zweitens müssen die Berechtigungen für die von der DLP API gescannten Daten dieses Rollenkonto enthalten. Ohne gültige Identität und die richtigen Berechtigungen kann der Dienst den Scan nicht durchführen.

Gemäß unseren Richtlinien muss jedes Rollenkonto mit Zugriff auf Nutzerdaten (oder andere vertrauliche Informationen) streng von BAB und anderen Sicherheitssystemen kontrolliert werden. Jobs zur Qualitätssicherung und Entwicklung, die keinen Zugriff auf sensible Daten oder Ressourcen haben, dürfen mit weniger Kontrollmaßnahmen ausgeführt werden.

Alles kombiniert: Die Struktur eines Jobs

Zusammengefasst lauten die Schritte zum Ausführen eines Jobs in unserer Infrastruktur so:

  1. Ein Google-Entwickler verfasst eine Änderung am Code. Anschließend wird sie zur Überprüfung an einen oder mehrere andere Google-Entwickler gesendet. Die Überprüfung umfasst Prüfungen auf die entsprechende Autorisierung und das richtige Logging. Nach der Genehmigung wird der Code eingecheckt.
  2. Sobald der Entwickler es auslöst, erstellt das Build-System die Binärdateien überprüfbar in einer Sandbox-Umgebung und verpackt sie. Dieser Build-Vorgang erzeugt ein Paket, das das Build-System dann zu Überprüfungszwecken signiert.
  3. Der Job wird auf Borg von einem Entwickler bereitgestellt, der speziell zur Verwaltung von Jobs autorisiert ist, die unter der entsprechenden sicheren Identität ausgeführt werden.
  4. Wenn ein Borg-Job versucht, auf privilegierte Ressourcen wie Nutzerdaten zuzugreifen, wird die Identität des Jobs zur Autorisierung überprüft.

Nachdem Sie nun wissen, wie Jobs in unserer Produktionsumgebung ausgeführt werden, untersuchen wir das von BAB behandelte Bedrohungsmodell, mit dem verhindert wird, dass möglicherweise böswillige Insider einen nicht autorisierten Job ausführen. Um dies zu erreichen, überprüft BAB, ob alle erforderlichen Sicherheitsprüfungen durchgeführt wurden, bevor eine Binärdatei bereitgestellt wird.

Dieser Abschnitt enthält eine Übersicht über unsere containerisierte Infrastruktur. Ein grundlegendes Verständnis unserer Produktionsumgebung ist eine notwendige Voraussetzung dafür, dass Sie die Kontrollmaßnahmen verstehen, die wir für den programmatischen Nutzerzugriff auf Daten haben. Diese Kontrollmaßnahmen werden im nächsten Abschnitt ausführlicher beschrieben.

Binärautorisierung für Borg (BAB)

Seit einigen Jahren bemühen wir uns, Nutzerdaten vor manuellem Zugriff zu schützen. Dazu gehört auch, den Zugriff auf Daten und die Jobverwaltung auf die Google-Mitarbeiter zu beschränken, die diesen Zugriff für ihre Arbeit benötigen.

BAB soll dafür sorgen, dass die gesamte bei Google bereitgestellte Produktionssoftware und -konfiguration ordnungsgemäß überprüft und autorisiert wird, insbesondere wenn solche Codes auf Nutzerdaten zugreifen können. Zur Erfüllung dieses Ziels bietet BAB einen Dienst für die Erzwingung zur Bereitstellungszeit, um den Start nicht autorisierter Jobs zu verhindern, sowie einen Audit-Trail des Codes und der Konfiguration von BAB-aktivierten Jobs.

Überprüfung

BAB überprüft, ob Binärdateien bei der Bereitstellung bestimmte Anforderungen erfüllen. Ein Dienstinhaber könnte beispielsweise anfordern, dass die Binärdatei für seinen Dienst aus Code erstellt wird, der geprüft, eingecheckt, getestet und autorisiert wurde. Diese Arten von Prüfungen werden als Prüfungen bei der Bereitstellung bezeichnet. BAB kann auch Prüfungen durchführen, nachdem eine Binärdatei bereitgestellt wurde. Wir bezeichnen diese als Prüfungen nach der Bereitstellung. Weitere Informationen zu diesen Prüfungen nach der Bereitstellung finden Sie im Abschnitt Erzwingungsmodi.

Durch eine Codeänderung wird eine neue Binärdatei erstellt. Damit die Änderungen in der neuen Binärdatei wirksam werden, muss sie bereitgestellt werden. BAB ermöglicht viele Arten von Prüfungen bei der Bereitstellung. Hier finden Sie einige Beispiele für diese Überprüfungen:

  • Wurde die Binärdatei aus eingechecktem Code erstellt?

    Wurde der Code an das Quellcode-Repository von Google gesendet und dort geprüft? Damit der Code gesendet werden kann, muss er in der Regel von einem zweiten Google-Entwickler geprüft werden.

  • Wurde die Binärdatei überprüfbar erstellt?

    Kann diese Binärdatei auf überprüfbare Quellen zurückgeführt werden und wurde sie von einem genehmigten Build-System erstellt?

  • Wurde die Binärdatei aus getestetem Code erstellt?

    Entspricht die Binärdatei den Testanforderungen?

  • Wurde die Binärdatei aus Code erstellt, der in der Bereitstellung verwendet werden soll?

    Wurde der Code an den entsprechenden Bereich unseres Quellcode-Repositorys gesendet, der dem jeweiligen Projekt oder Team für diesen bestimmten Borg-Job entspricht?

Obwohl diese Anforderungen speziell für unsere Produktionsumgebung gelten, können ähnliche Anforderungen in Ihren CI-/CD-Umgebungen (Continuous Integration/Continuous Deployment) auf Basis Ihrer eigenen Sicherheits-, Compliance- oder Zuverlässigkeitsanforderungen erzwungen werden.

Dienstspezifische Richtlinie

Für Jobs, die auf vertrauliche Daten zugreifen, ist in der Regel die Übermittlung von Code erforderlich. Ausnahmen gelten für triftige geschäftliche Gründe. Zu den sensiblen Daten gehören Nutzerdaten, Beschäftigungs- und Finanzdaten sowie sonstige zum Unternehmen gehörende oder geschäftliche Daten, auf die nur Personen mit berechtigtem Interesse Zugriff erhalten. Für alle Jobs bei Google muss eine Richtlinie gelten. Auch für einen Borg-Job, der keinen Zugriff auf Nutzerdaten benötigt, ist eine Richtlinie definiert. Es werden jedoch keine spezifischen Anforderungen aufgeführt.

Wenn Dienstinhaber BAB einrichten, definieren sie eine Richtlinie mit den Sicherheitsanforderungen für ihren Dienst. Alle Rollenkonten, die zur Implementierung des Dienstes verwendet werden, müssen eine BAB-Richtlinie angeben. Für jedes Rollenkonto definiert die BAB-Richtlinie die zu startenden Jobs sowie die Code- und Konfigurationsanforderungen des Jobs. Das Definieren oder Ändern einer Richtlinie ist ebenfalls eine Codeänderung, die überprüft werden muss.

Folgende Anforderungen können in einer BAB-Richtlinie erzwungen werden:

  • Code wurde überprüfbar erstellt: Ein überprüfbar erstellter Code kann geprüft werden. Dies bedeutet jedoch nicht unbedingt, dass der Code einer Codeüberprüfung unterzogen wurde. Es gibt sogar Fälle, bei denen Code nicht gesendet wurde. Der in überprüfbaren Builds verwendete Code ist mindestens 18 Monate lang überprüfbar, auch wenn er nicht gesendet wurde.

  • Code wurde gesendet: Der Code wird aus einem angegebenen, vorgesehenen Ort in unserem Quell-Repository erstellt. Dies bedeutet normalerweise, dass der Code einer Codeüberprüfung unterzogen wurde.

  • Konfigurationen werden gesendet: 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.

Die Systeme und Komponenten, die BAB erzwingen, müssen streng kontrolliert werden. Dies wird durch die Implementierung strengster Anforderungen und zusätzlicher manueller Kontrollmaßnahmen erreicht.

Erzwingungsmodi

BAB führt je nach der vom Borg-Job festgelegten Richtlinie verschiedene Aktionen aus. Wir bezeichnen diese Aktionen als Erzwingungsmodi, von denen es drei gibt: Erzwingung bei der Bereitstellung, Prüfung bei der Bereitstellung und kontinuierliche Überprüfung. Beim Definieren einer Richtlinie muss der Dienstinhaber entweder die Erzwingung bei der Bereitstellung oder die Prüfung bei der Bereitstellung auswählen. Der Modus "Kontinuierliche Überprüfung" ist standardmäßig aktiviert. In den nächsten Abschnitten erhalten Sie weitere Informationen zu den einzelnen Modi.

Modus "Erzwingung bei der Bereitstellung"

Wenn ein neuer Job gesendet wird, überprüft Borgmaster2 mithilfe von BAB, ob der Job den Anforderungen der BAB-Richtlinien entspricht. Diese Prüfung fungiert als Zugriffskontrolle. Wenn die Anforderungen erfüllt sind, startet Borgmaster den Job. Andernfalls lehnt Borgmaster die Anfrage ab, auch wenn der Nutzer, der die Anfrage stellt, ansonsten autorisiert ist.

Im Erzwingungsmodus blockiert BAB die Bereitstellung eines Borg-Jobs, wenn dieser nicht den Anforderungen der BAB-Richtlinie für den Borg-Job entspricht. Dienste, die für BAB neu sind, beginnen in der Regel im Prüfmodus (wird im nächsten Abschnitt beschrieben) und gehen dann in den Erzwingungsmodus über.

Notfallmaßnahmen

Bei einem Zwischenfall oder Ausfall 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 eingecheckt 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 eine Bereitstellung andernfalls durch einen BAB-Fehler blockiert wird. Ein Entwickler, der einen Job mithilfe der Notfallmaßnahmen bereitstellt, muss im Rahmen seiner Anfrage eine Begründung senden.

Innerhalb von Sekunden nach der Nutzung der Notfallmaßnahme protokolliert BAB Details zu dem zugehörigen Borg-Job. Das Log enthält den verwendeten Code und die vom Nutzer angegebene Begründung. Wenige Sekunden später wird ein Audit-Trail an unser zentralisiertes Sicherheitsteam gesendet. Innerhalb weniger Stunden wird der Audit-Trail an das Team gesendet, dem das Rollenkonto gehört. Notfallmaßnahmen sind jedoch nur als letztes Mittel gedacht.

Modus "Prüfung bei der Bereitstellung"

Im Prüfmodus protokolliert BAB, wenn ein Borg-Job die Richtlinienanforderungen nicht erfüllt, blockiert seine Bereitstellung aber nicht. Diese Verletzung der Richtlinien erzeugt eine Benachrichtigung an das Team, dem das Rollenkonto gehört.

Bei Google müssen bestimmte Dienste, z. B. solche, die auf Nutzerdaten zugreifen, den Erzwingungsmodus verwenden. Wir empfehlen allen Dienstinhabern dringend, den Erzwingungsmodus zu verwenden und den Prüfmodus nur bei der Einrichtung eines neuen Dienstes zu nutzen. Damit der Prüfmodus verwendet werden kann, müssen Dienstinhaber eine Begründung angeben, um eine Ausnahme zu erhalten. Beispiel: Ein Dienst, dessen Zuverlässigkeits-SLO (Service Level Objective) wesentlich höher ist als das von BAB bereitgestellte, würde den Prüfmodus verwenden.

Obwohl der Prüfmodus bei der Feinabstimmung einer anfänglichen Richtlinie nützlich ist, ist er für die meisten Dienste kein praktischer stabiler Zustand. Beim Prüfmodus wird der Dienstinhaber erst einige Stunden nach dem Verstoß gegen Richtlinien informiert. Dies kann zu einem ungenauen Benachrichtigungsstrom führen, aufgrund dessen echte Sicherheitsprobleme durch Fehler oder falsche Richtlinienkonfigurationen ausgeblendet werden, die vom Dienstinhaber verursacht wurden. Im Erzwingungsmodus erhält der Diensteigentümer sofort Feedback, wenn er versucht, einen Job zu starten, der nicht der Richtlinie entspricht. Daher ist der Benachrichtigungsstrom viel übersichtlicher. Außerdem werden durch den Erzwingungsmodus in BAB unbeabsichtigte Fehler erfasst, z. B. wenn ein Job versehentlich in einer andere Rolle als derjenigen gestartet wird, für die er ausgeführt werden soll.

Kontinuierliche Überprüfung

Sobald ein Job bereitgestellt worden ist, wird er unabhängig von seiner Erzwingung bei der Bereitstellung kontinuierlich auf seine Gültigkeit überprüft. 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 oder mit einer Identität ausgeführt werden, die mithilfe von Notfallmaßnahmen bereitgestellt wurde. Wenn ein Job gefunden wird, der nicht der aktualisierten Richtlinie entspricht, benachrichtigt BAB die Dienstinhaber, sodass sie das Risiko minimieren können.

Global zulässige Pakete

Bei Google gibt es einige Pakete, die von vielen unserer Dienste häufig genutzt werden. Anstatt bei jedem Dienst die Verwaltung einer eigenen Version zu erzwingen, werden diese Pakete zentral zugelassen. Wir nennen sie global verwaltete Pakete. Beim Schreiben seiner BAB-Richtlinie kann ein Dienstinhaber ein global zulässiges Paket für einen bestimmten Job angeben. Es gibt auch einen globalen Standardmechanismus für häufig verwendete Pakete, sodass sie nicht einzeln als Teil der Richtlinien des jeweiligen Dienstes aufgeführt werden müssen. Dadurch behält Google die ausdrückliche Kontrolle über allgemeine Systemkomponenten, die in der gesamten Organisation verwendet werden, und stellt sicher, dass diese ordnungsgemäß überprüft und aktualisiert werden, ohne einzelne Teams einzubeziehen. Obwohl ein einzelner Dienstinhaber diese Pakete explizit als Teil der BAB-Richtlinie seines Dienstes zulassen kann, erleichtert dies die Verwendung des empfohlenen und unterstützten Pfades für die Inhaber.

Sonderfälle

Google implementiert robuste Sicherheitskontrollen für Code, der in der Produktion bereitgestellt wird, darunter Codeüberprüfungen und überprüfbare Builds. BAB dient als zusätzliche Kontroll- und Erzwingungsmöglichkeit, um sicherzustellen, dass diese Sicherheitskontrollen tatsächlich ordnungsgemäß implementiert werden.

BAB kann jedoch nicht in allen Fällen effektiv eingesetzt werden. BAB unterstützt die folgenden Sonderfälle nicht: Code, der mit nicht standardmäßigen Build-Systemen erstellt wurde, Code, der in Umgebungen außerhalb von Borg bereitgestellt wird, und Code für Datenanalysen und maschinelles Lernen, der sich nicht gut für menschliche Codeüberprüfungen eignet, bevor die endgültigen Produktionsparameter ausgewählt werden. In diesen Fällen gibt es eine Reihe anderer Sicherheitsmaßnahmen, einschließlich anderer Systeme zur Ermittlung der Codeherkunft. Diese Codes unterliegen jedoch weiterhin den allgemeinen Sicherheitskontrollen von Google.

Binärautorisierung für Borg implementieren

Zur Implementierung von BAB entwickelte das BAB-Team verschiedene neue Features, einschließlich der Notfallmaßnahmen und des Prüfmodus. Mit diesen Tools war es für Dienstinhaber möglichst einfach, BAB selbst auszuprobieren. Wenn Sie die Bereitstellung von BAB in Ihrer Organisation in Betracht ziehen, ist möglicherweise zusätzlicher Aufwand erforderlich, um diese Umstellung zu erleichtern. In diesem Abschnitt werden die Maßnahmen in Bezug auf die Organisation und das Änderungsmanagement beschrieben, die wir im Rahmen unseres Implementierungsplans durchgeführt haben.

Vorteile

BAB hat drei Vorteile, die bei der Entwicklung und Einführung bei Google eine wichtige Rolle gespielt haben: reduziertes Insiderrisiko, robuste Codeidentität und vereinfachte Compliance.

Reduziertes Insiderrisiko

BAB wurde in erster Linie entwickelt, um zu verhindern, dass einzelne Personen nicht autorisierten programmatischen Zugriff auf Nutzerdaten erhalten. Mit BAB wird es schwieriger für einen einzelnen Entwickler oder Angreifer, der an die Anmeldedaten eines Entwicklers gelangt, unangemessen und unerkannt auf vertrauliche Daten zuzugreifen.

Robuste Codeidentität

Wie im Abschnitt Containerisierte Infrastruktur beschrieben, werden Borg-Jobs als Identität ausgeführt, in der Regel als Rollenkonto. Diese Identität wird von anderen Diensten verwendet, um vor dem Gewähren des Zugriffs auf Daten zu überprüfen, ob eine ordnungsgemäße Autorisierung vorhanden ist. Andere Dienste können jedoch die Verwendung dieser Daten nicht erzwingen und müssen daher darauf vertrauen, dass die Jobidentität die empfangenen Daten nicht missbraucht. BAB verknüpft die Identität eines Jobs mit einem bestimmten Code. Dadurch wird sichergestellt, dass die Berechtigungen der Jobidentität nur mit dem angegebenen Code ausgeübt werden können. Dies ermöglicht den Übergang von einer Jobidentität, bei der einer Identität und einem ihrer privilegierten menschlichen Nutzer vorübergehend vertraut wird, zu einer Codeidentität, bei der einem bestimmten überprüften Code vertraut wird, der eine bestimmte Semantik aufweist und ohne Genehmigungsprozesse nicht geändert werden kann.

Vereinfachte Compliance

BAB vereinfachte die bisher manuell durchgeführten 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. Nach BAB wurden viele dieser Prüfungen auf Grundlage der BAB-Richtlinien der 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.

Einrichtung eines Dienstes

Das BAB-Team musste dafür sorgen, dass der Einrichtungsprozess einfach und unkompliziert war. Anfangs hatten Dienstinhaber bei Google zwei Hauptbedenken in Bezug auf die Übernahme von BAB:

  • Wenn BAB nicht zuverlässig genug sei, könnte die Implementierung Änderungen in kritischen Situationen blockieren.
  • BAB könnte durch häufiges Einchecken für Codes und iterative Prozesse die Entwicklung eines Dienstes verlangsamen.

Um diese anfänglichen Bedenken auszuräumen, entwickelte das BAB-Team den Prüfmodus. In diesem Modus konnte das BAB-Team wichtigen ersten Nutzern beweisen, dass BAB funktioniert. Um die Zuverlässigkeit weiter zu erhöhen, entwickelte das BAB-Team ein Verfügbarkeits-SLO und führte Notfallmaßnahmen für den Erzwingungsmodus ein.

Wenn ein vorhandener Dienst für BAB eingerichtet wird, aktiviert der Dienstinhaber normalerweise zuerst nur den Prüfmodus. Dadurch kann er Probleme erkennen und beheben, bevor er den Erzwingungsmodus aktiviert. Die Standardrichtlinie für jeden Job, der BAB in der Produktion verwendet, ist der Erzwingungsmodus. Zur Bereitstellung des Jobs muss der Dienstinhaber eine Richtlinie einreichen, bei der zumindest erforderlich ist, dass Code gesendet und überprüfbar erstellt wird. Ein Dienstinhaber kann einen Job bereitstellen, ohne diesen Mindeststandard zu erfüllen. Allerdings muss ihm eine Ausnahme gewährt werden. Wenn der Dienst Zugriff auf sensiblere Daten und/oder Dienste benötigt, kann der Inhaber strengere Anforderungen stellen. Die Festlegung einer anfänglichen Richtlinie kann schwierig sein. Deshalb hat das BAB-Team automatisierte Tools entwickelt, um Dienstinhabern beim Verfassen ihrer Richtlinien zu helfen. Die Tools überprüfen, welche Teile des Quell-Repositorys für einen vorhandenen Job verwendet werden, und schlagen eine entsprechende Richtlinie vor.

Wenn ein neuer Dienst für BAB eingerichtet wird, aktiviert der Dienstinhaber den Erzwingungsmodus von Anfang an. Der Dienstinhaber erstellt eine anfängliche Richtlinie und führt sie schnell aus, um zusätzliche Anforderungen hinzuzufügen. Die Richtlinien selbst werden als Codeänderungen verwaltet und erfordern daher einen zweiten Google-Entwickler zum Überprüfen aller Aktualisierungen.

Auswirkungen

Die Verwendung von BAB und eines containerisierten Bereitstellungsmodells bietet Google viele Vorteile im Hinblick auf Sicherheit und Support:

  • BAB hilft bei der Reduzierung des Insiderrisikos: Durch die Anforderung, dass Codes bestimmte Standards und Änderungsmanagementpraktiken vor dem Zugriff auf Nutzerdaten einhalten, reduziert BAB das Risiko, dass ein Google-Mitarbeiter eigenmächtig (oder aufgrund der Manipulation seines Kontos) programmatisch auf Nutzerdaten zugreifen kann.
  • 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 ein klareres Änderungsmanagement. 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 unseren Systemen. Daten zu dieser Konformität werden intern veröffentlicht und können von anderen Teams abgefragt werden. Wenn BAB-Daten auf diese Weise veröffentlicht werden, können Teams häufig verwendete Begriffe verwenden, wenn sie miteinander über Datenschutz sprechen. 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: Bestimmte Prozesse, z. B. für die Finanzberichterstellung, müssen bestimmte Compliance-Anforderungen für das Änderungsmanagement erfüllen. Mit BAB können diese Prüfungen automatisiert werden, wodurch Zeit gespart und der Deckungsumfang erweitert wird.

BAB ist eine von mehreren Technologien, die bei Google eingesetzt werden, um Insiderrisiken zu minimieren.

Ähnliche Kontrollmaßnahmen in Ihrer Organisation verwenden

Bei der Implementierung von BAB bei Google haben wir viele wichtige Erkenntnisse gewonnen. Eine solche große Veränderung kann eine gewaltige Aufgabe sein. In diesem Abschnitt beschreiben wir die Erkenntnisse, die wir im Laufe der Zeit gewonnen haben, in der Hoffnung, dass Sie die Prinzipien von BAB auf Ihre Organisation anwenden können.

Arbeiten Sie an einer homogeneren containerisierten CI-/CD-Pipeline.

Die Einführung von BAB bei Google wurde durch die Konsistenz und Integration der Tools ermöglicht, die wir bei der Codeentwicklung verwenden. Diese Arbeit umfasste Codeüberprüfungen, überprüfbare Builds, containerisierte Bereitstellungen und dienstbasierte Identitäten für die Zugriffskontrolle. Durch überprüfbare Builds können Sie prüfen, wie Ihre Binärdateien erstellt werden. Container ermöglichen Ihnen wiederum, Binärdateien von Daten zu trennen, und stellen Ihnen ein "Nadelöhr" zur Erzwingung bereit, mit dem Sie gewährleisten können, dass die Dateien die Nutzungsanforderungen erfüllen. Dieser Ansatz vereinfachte die Einführung von BAB und sorgte für eine Stärkung der Garantien, die eine Lösung wie BAB bietet.

Dank Mikrodiensten konnte eine dienstbasierte Identität (z. B. ein Dienstkonto) anstelle einer hostbasierten Identität (z. B. eine IP-Adresse) eingeführt werden. Mit der Umstellung auf eine dienstbasierte Identität können Sie die Verwaltung von Authentifizierungs- und Autorisierungsvorgängen zwischen Diensten ändern. Wenn Sie zum Beispiel ein Identitätstoken verwenden, das zur Identitätsbestätigung in einem Container-Image verankert ist, haben die durch die Codeherkunft bereitgestellten Garantien nicht dieselbe Stärke. Wenn Sie eine Dienstidentität nicht direkt übernehmen können, sollten Sie als Zwischenschritt versuchen, Identitätstokens stärker zu schützen.

Bestimmen Sie Ihre Ziele und definieren Sie Ihre Richtlinien basierend auf Ihren Anforderungen.

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 immer gelten. Beginnen Sie mit einer Reihe grundlegender Anforderungen und legen Sie anschließend erweiterte Anforderungen fest.

Erzwingen Sie Richtlinien bereits in der Entwicklungsphase.

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. Aus diesem Grund wird die BAB-Richtlinienerzwingung durchgeführt, wenn Code bereitgestellt wird und wenn er auf Daten zugreift, und nicht, wenn er erstellt wird. Eine BAB-Richtlinie wird in Bezug auf die 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. Mit BAB können Dienstinhaber zusätzlich dafür sorgen, dass nur Jobs, die bestimmten BAB-Anforderungen entsprechen, auf Daten zugreifen können, wobei der Code als Identität behandelt wird.

Legen Sie fest, wie Sie bestehende Dienstinhaber überzeugen.

Suchen Sie nach einigen Dienstinhabern, die sofort von der Erzwingung profitieren werden und bereit sind, Feedback zu geben. Eine Möglichkeit hierfür besteht darin, nach freiwilligen Inhabern zu suchen, bevor Änderungen zur Pflicht werden.

Verwenden Sie nach Möglichkeit den Erzwingungsmodus statt des Prüfmodus oder grenzen Sie den Kulanzzeitraum für den Prüfmodus ein. Mit dem Prüfmodus können Inhaber schnell einsteigen und Insiderrisiken besser einschätzen. Der Nachteil des Prüfmodus besteht darin, dass es einige Zeit dauern kann, bis Inhaber eine Reduzierung des Insiderrisikos verzeichnen können. Aufgrund dieser Verzögerung ist der Nutzen möglicherweise schlechter zu erkennen und es wird schwieriger, andere von der Einführung der Erzwingung zu überzeugen. Als das BAB-Team Notfallmaßnahmen für die Erzwingung bereitstellte, waren die Dienstinhaber eher bereit, die Erzwingung einzuführen, da sie dadurch bei Bedarf eine Ausstiegsmöglichkeit hatten.

Rekrutieren Sie teamübergreifende Change Agents.

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

Legen Sie fest, wie Sie Drittanbietercodes verwalten.

Viele der CI-/CD-Kontrollmaßnahmen, die wir in diesem Dokument beschreiben, werden dort durchgeführt, wo Ihr Code von einer einzelnen Organisation entwickelt, überprüft und gewartet wird. Wenn dies bei Ihnen der Fall ist, sollten Sie prüfen, wie Sie im Rahmen Ihrer Richtlinienanforderungen Drittanbietercode einbinden. Sie könnten den Code beispielsweise erst einmal ausschließen, während Sie die Pflege eines Repositorys mit allen verwendeten Drittanbietercodes optimieren und diesen Code regelmäßig auf Ihre Sicherheitsanforderungen überprüfen.

Fazit

Durch das Implementieren einer bei der Bereitstellung durchgeführten Erzwingungsprüfung als Teil der containerbasierten Infrastruktur und des CI-/CD-Prozesses von Google konnten wir überprüfen, ob der bereitgestellte Code und die entsprechende Konfiguration bestimmte Mindestanforderungen an die Sicherheit erfüllen. Dies ist eine wichtige Kontrollmaßnahme, durch die ein potenziell böswilliger Insider dabei eingeschränkt wird, einen nicht autorisierten Job auszuführen, der eventuell auf Nutzerdaten zugreift. Durch die Einführung von BAB konnte Google Insiderrisiken reduzieren, mögliche Angriffe verhindern und die Einheitlichkeit von Produktionssystemen unterstützen.

Weitere Referenzen

Weitere Informationen zur Sicherheit und Containerinfrastruktur von Google finden Sie in den folgenden Ressourcen:

Hinweise

1Die Herkunft beschreibt die Komponenten, Änderungen an den Komponenten und deren Entstehung. Weitere Informationen finden Sie unter https://csrc.nist.gov/glossary/term/Provenance.

2Borgmaster ist der zentrale Controller von Borg. Er verwaltet die Planung von Jobs und kommuniziert mit laufenden Jobs über deren Status.