Best Practices für die Verwendung von Dienstkonten in Pipelines

Mit Bereitstellungspipelines können Sie den Prozess der Aufnahme von Code oder vordefinierten Artefakten und deren Bereitstellung in eine Google Cloud-Umgebung automatisieren. Sie können außerdem eine Alternative zu interaktiven Tools wie der Google Cloud Console oder der Google Cloud-CLI sein.

Bereitstellungspipelines unterscheiden sich von interaktiven Tools wie der Google Cloud Console oder der gcloud-CLI darin, wie sie mit Identity and Access Management interagieren. Sie müssen diese Unterschiede beim Schützen Ihrer Google Cloud-Ressourcen berücksichtigen.

Bevor Sie über Google Cloud auf eine Ressource zugreifen können, wird eine Zugriffsprüfung durchgeführt. Für diese Prüfung berücksichtigt IAM in der Regel Folgendes:

  • Ihre Identität
  • Die Ressource, auf die Sie zugreifen möchten, und deren IAM-Richtlinien zum Zulassen und Verweigern
  • Den Kontext Ihrer Anfrage (möglicherweise einschließlich Zeit und Ort)

In einer Bereitstellungspipeline rufen Sie Google Cloud APIs nur selten direkt auf. Stattdessen verwenden Sie Tools, um auf Google Cloud-Ressourcen zuzugreifen. Für Tools wie die Google Cloud Console oder die gcloud CLI müssen Sie das Tool zuerst für den Zugriff auf Ressourcen autorisieren. Durch diese Autorisierung erteilen Sie dem Tool die Berechtigung, bei API-Aufrufen Ihre Identität zu verwenden.

Wie die Google Cloud Console oder die gcloud-CLI agiert eine Bereitstellungspipeline in Ihrem Namen: Sie nimmt Ihre als Quellcode ausgedrückten Änderungen und stellt sie in Google Cloud bereit. Im Gegensatz zur Google Cloud Console oder der gcloud-CLI verwendet eine Bereitstellungspipeline jedoch in der Regel Ihre Identität nicht, um die Bereitstellung durchzuführen:

  1. Als Nutzer interagieren Sie in der Regel nicht direkt mit einer Bereitstellungspipeline. Stattdessen interagieren Sie mit einem Versionsverwaltungssystem (SCM), indem Sie Codeänderungen in ein Quell-Repository übertragen oder Code Reviews genehmigen.

  2. Die Bereitstellungspipeline liest gesendete Codeänderungen aus dem SCM-System und stellt sie in Google Cloud bereit.

    Für die Bereitstellung kann die Bereitstellungspipeline in der Regel nicht Ihre Identität verwenden, da:

    1. Der Quellcode und seine Metadaten geben möglicherweise nicht an, dass Sie der Autor waren, oder die Autoreninformationen sind nicht manipulationssicher (wie bei unsignierten Git-Commits).
    2. Die Identität, die Sie zum Senden von Quellcode verwendet haben, unterscheidet sich möglicherweise von Ihrer Google-Identität und die beiden Identitäten können nicht einander zugeordnet werden

    Die meisten Bereitstellungspipelines führen daher Bereitstellungen unter ihrer eigenen Identität mithilfe eines Dienstkontos aus.

  3. Wenn die Bereitstellungspipeline auf Google Cloud zugreift, lässt IAM den Zugriff ausschließlich auf Grundlage der Identität des von der Pipeline verwendeten Dienstkontos zu oder verweigert ihn, nicht aufgrund der Identität Ihres Nutzerkontos.

Bereitstellungspipeline

Wenn Sie eine Bereitstellungs-pipeline ein Dienstkonto verwenden lassen, um auf Google Cloud zuzugreifen, hat das einige Vorteile:

  • Der Lebenszyklus eines Dienstkontos wird vom Lebenszyklus von Nutzerkonten getrennt. Durch die Konfiguration einer Pipeline für die Verwendung eines Dienstkontos wird sichergestellt, dass Code auch dann bereitgestellt werden kann, wenn der Autor des Codes nicht mehr in Ihrer Organisation vorhanden ist.
  • Wenn Sie Ressourcen mithilfe einer Bereitstellungspipeline verwalten, müssen Sie Nutzern keinen Zugriff auf die Ressourcen gewähren oder Sie können die Berechtigungen auf den Lesezugriff beschränken. Dieser Ansatz kann die Verwaltung von IAM-Richtlinien vereinfachen und Sie erzwingen, dass Nutzer die Bereitstellungspipeline verwenden, um alle Änderungen vorzunehmen.

Die Verwendung eines Dienstkontos führt jedoch auch neue Bedrohungen ein. Dazu gehören:

  • Spoofing: Ein böswilliger Nutzer könnte versuchen, die Identität der Deployment-Pipeline vorzutäuschen oder ihre Anmeldedaten zu stehlen, um Zugriff auf Ressourcen zu erhalten.
  • Rechteausweitung: Die Pipeline könnte dazu verleitet werden, Aktionen auszuführen, die nicht ausgeführt werden sollen, wodurch sie effektiv zu einem Confused Deputy wird.
  • Nachweisbarkeit: Nach dem Ausführen einer Operation kann möglicherweise nur schwer rekonstruiert werden, warum sie ausgeführt wurde und durch welchen Entwickler oder welche Codeänderung sie ausgelöst wurde.
  • Manipulation: Eine Pipeline kann missbraucht werden, um die Integrität oder Sicherheitskontrollen Ihrer Cloud-Umgebungen zu untergraben.
  • Offenlegung von Informationen: Böswillige Akteure versuchen möglicherweise, die Bereitstellungspipeline zur Exfiltration vertraulicher Daten zu verwenden.

Vor Spoofing-Bedrohungen schützen

So gewähren Sie einer Bereitstellungspipeline in der Regel Zugriff auf Google Cloud:

  1. Dienstkonto erstellen
  2. Gewähren Sie dem Dienstkonto Zugriff auf die erforderlichen Ressourcen.
  3. Bereitstellungspipeline für die Verwendung des Dienstkontos konfigurieren

Aus Sicht von IAM stellt das Dienstkonto die Bereitstellungspipeline dar, aber die Bereitstellungspipeline und das Dienstkonto sind zwei separate Entitäten. Bei nicht ordnungsgemäßer Sicherung kann ein böswilliger Akteur möglicherweise dasselbe Dienstkonto verwenden, was ihm ein Spoofing der Identität der Bereitstellungspipeline ermöglicht.

Im folgenden Abschnitt werden Best Practices beschrieben, mit denen Sie das Risiko solcher Bedrohungen minimieren können.

Best Practices:

Anhängen von Dienstkonten an VM-Instanzen vermeiden, die von CI/CD-Systemen verwendet werden
Dedizierte Dienstkonten pro Bereitstellungspipeline verwenden
Nach Möglichkeit die Workload Identity-Föderation verwenden
Mit VPC Service Controls die Auswirkungen von gehackten Anmeldedaten reduzieren

Anhängen von Dienstkonten an VM-Instanzen vermeiden, die von CI/CD-Systemen verwendet werden

Für Anwendungen, die auf Compute Engine bereitgestellt werden und Zugriff auf Google Cloud-Ressourcen benötigen, empfiehlt es sich, ein Dienstkonto an die zugrunde liegende VM-Instanz anzuhängen. Bei CI/CD-Systemen, die Compute Engine-VMs zum Ausführen verschiedener Bereitstellungspipelines verwenden, kann diese Vorgehensweise problematisch sein, wenn dieselbe VM-Instanz zum Ausführen verschiedener Bereitstellungspipelines verwendet werden kann, die jeweils Zugriff auf verschiedene Ressourcen benötigen.

Statt angehängte Dienstkonten zu verwenden, damit Bereitstellungspipelines auf Ressourcen zugreifen können, sollten Sie jede Bereitstellungspipeline ein separates Dienstkonto verwenden lassen. Hängen Sie kein Dienstkonto an VM-Instanzen an, die von CI/CD-Systemen verwendet werden, oder hängen Sie ein Dienstkonto an, dessen Zugriff auf wichtige Dienste wie Cloud Logging beschränkt ist.

Dedizierte Dienstkonten pro Bereitstellungspipeline verwenden

Wenn Sie mehrere Bereitstellungspipelines dasselbe Dienstkonto verwenden lassen, kann IAM nicht zwischen den Pipelines unterscheiden: Die Pipelines haben Zugriff auf dieselben Ressourcen und Audit-Logs enthalten möglicherweise nicht genügend Informationen, um zu bestimmen, welche Bereitstellungspipeline es ausgelöst hat, dass eine Ressource aufgerufen oder geändert wurde.

Sorgen Sie für eine 1:1-Beziehung zwischen Bereitstellungspipelines und Dienstkonten, um eine solche Mehrdeutigkeit zu vermeiden. Erstellen Sie für jede Bereitstellungspipeline ein dediziertes Dienstkonto und beachten Sie Folgendes:

  • Geben Sie den Namen oder die ID der Bereitstellungspipeline in der E-Mail-Adresse des Dienstkontos an. Wenn Sie ein konsistentes Benennungsschema verwenden, können Sie die Bereitstellungspipeline anhand des Namens des Dienstkontos ermitteln und umgekehrt.
  • Gewähren Sie dem Dienstkonto nur Zugriff auf die Ressourcen, die die jeweilige Bereitstellungspipeline benötigt.

Nach Möglichkeit die Workload Identity-Föderation verwenden

Einige CI/CD-Systeme wie GitHub Actions oder GitLab ermöglichen Bereitstellungspipelines, OpenID Connect-kompatible Tokens abzurufen, die die Identität der Bereitstellungspipeline bestätigen. Sie können zulassen, dass Bereitstellungspipelines diese Tokens verwenden, um die Identität eines Dienstkontos zu übernehmen. Verwenden Sie dazu die Workload Identity-Föderation.

Mit der Föderation von Workload Identity können Sie die Risiken der Verwendung von Dienstkontoschlüsseln vermeiden.

Mit VPC Service Controls die Auswirkungen gehackter Anmeldedaten reduzieren

Wenn ein böswilliger Akteur es schafft, ein Zugriffstoken oder einen Dienstkontoschlüssel aus einer Ihrer Bereitstellungspipelines zu stehlen, kann er versuchen, diese Anmeldedaten zu verwenden und über einen von ihm kontrollierten Computer auf Ihre Ressourcen zugreifen.

Standardmäßig berücksichtigt IAM bei Standortentscheidungen nicht den Standort, die Quell-IP-Adresse oder das Google Cloud-Ausgangsprojekt. Gestohlene Anmeldedaten können daher von überall aus verwendet werden.

Sie können Einschränkungen für die Quellen festlegen, bezüglich von wo aus auf Ihre Google Cloud-Ressourcen zugegriffen werden kann. Dazu legen Sie Ihre Projekte in einen VPC-Dienstperimeter und verwenden Regeln für eingehenden Traffic:

  • Wenn Ihre Bereitstellungspipeline in Google Cloud ausgeführt wird, können Sie eine Regel für eingehenden Traffic konfigurieren, die nur den Zugriff über das Projekt zulässt, das Ihr CI/CD-System enthält.
  • Wenn Ihre Bereitstellungspipeline außerhalb von Google Cloud ausgeführt wird, können Sie eine Zugriffsebene erstellen, die nur den Zugriff von bestimmten geografischen Standorten oder IP-Bereichen zulässt. Erstellen Sie dann eine Regel für eingehenden Traffic, die den Zugriff für Clients zulässt, die diese Zugriffsebene erfüllen.

Schutz vor Manipulations-Bedrohungen

Für einige Daten, die Sie in Google Cloud speichern, ist es möglicherweise besonders wichtig, nicht autorisierte Änderungen oder Löschungen zu verhindern. Wenn eine nicht autorisierte Änderung oder Löschung besonders wichtig ist, können Sie die Daten als Daten mit hoher Integrität charakterisieren.

Um die Integrität Ihrer Daten aufrechtzuerhalten, müssen Sie dafür sorgen, dass die Google Cloud-Ressourcen, die Sie zum Speichern und Verwalten dieser Daten verwenden, sicher konfiguriert sind und ihre Integrität aufrechterhalten.

Bereitstellungspipelines können Sie bei der Aufrechterhaltung der Integrität Ihrer Daten und Ressourcen unterstützen, können jedoch auch ein Risiko darstellen: Wenn die Pipeline oder einer ihrer Komponenten nicht den Integritätsanforderungen der von ihr verwalteten Ressourcen entspricht, wird Die Bereitstellungspipeline zu einer schwachen Stelle, die böswilligen Nutzern die Manipulation Ihrer Daten oder Ressourcen ermöglichen kann.

Im folgenden Abschnitt werden Best Practices beschrieben, mit denen Sie das Risiko von Manipulierungs-Bedrohungen minimieren können.

Best Practices:

Lassen Sie nicht zu, dass Bereitstellungspipelines die Sicherheitskontrollen verwalten.

Zugriff auf Sicherheitskontrollen beschränken

Um die Sicherheit und Integrität Ihrer Daten und Ressourcen in Google Cloud zu gewährleisten, verwenden Sie Sicherheitskontrollen wie:

  • Zulassungssrichtlinien und Ablehnungsrichtlinien
  • Einschränkungen für Organisationsrichtlinien
  • Perimeter, Zugriffsebenen und Richtlinien für eingehenden Traffic von VPC Service Controls

Diese Sicherheitskontrollen sind selbst Ressourcen. Manipulation von Sicherheitskontrollen beeinträchtigt die Integrität der Ressourcen, für die die Sicherheitskontrollen gelten. Daher muss die Integrität der Sicherheitskontrollen mindestens als so wichtig betrachtet werden wie die Integrität der Ressourcen, für die sie gelten.

Wenn Sie eine Bereitstellungspipeline für die Verwaltung von Sicherheitskontrollen sorgen lassen, muss die Integrität der Sicherheitskontrollen durch die Bereitstellungspipeline aufrechterhalten werden. Daher muss die Integrität der Bereitstellungspipeline selbst mindestens so wichtig sein wie die Integrität der von ihnen verwalteten Sicherheitskontrollen und der Ressourcen, für die diese Kontrollen gelten.

Sie können die Auswirkungen einer Bereitstellungspipeline auf die Integrität Ihrer Ressourcen so begrenzen:

  • Gewähren Sie keinen Bereitstellungspipelines Zugriff auf Zulassungsrichtlinien, auf Ablehnungsrichtlinien, und auf andere Sicherheitskontrollen und beschränken Sie deren Zugriff auf andere Ressourcen.
  • Zugriff nur auf ausgewählte Sicherheitskontrollen gewähren, z. B. die Richtlinien zum Zulassen und Ablehnen für eine bestimmte Ressource oder ein bestimmtes Projekt, aber keinen Zugriff auf umfassendere Kontrollen gewähren, die mehrere Ressourcen oder Projekte betreffen

Wenn Ihre Bereitstellungspipeline, deren Komponenten und die zugrunde liegende Infrastruktur den Integritätsanforderungen bestimmter Sicherheitskontrollen nicht gerecht werden, sollten Sie es vermeiden, dass Bereitstellungspipelines diese Sicherheitskontrollen verwalten.

Schutz vor Nichterkennungs-Bedrohungen

Sie bemerken irgendwann möglicherweise verdächtige Aktivitäten, die sich auf eine Ihrer Ressourcen in Google Cloud auswirken. In diesem Fall müssen Sie in der Lage sein, mehr über die Aktivität zu erfahren, und idealerweise in der Lage sein, die Kette der Ereignisse zu rekonstruieren, die zu dieser Aktivität geführt haben.

Mit Cloud-Audit-Logs können Sie herausfinden, wann auf Ressourcen zugegriffen wurde oder wann sie geändert wurden und welche Nutzer beteiligt waren. Obwohl Cloud-Audit-Logs ein Ausgangspunkt für die Analyse verdächtiger Aktivitäten sind, reichen die von diesen Logs bereitgestellten Informationen möglicherweise nicht aus: Wenn Sie Bereitstellungspipelines verwenden, müssen Sie auch in der Lage sein, Cloud-Audit-Logs mit Logs zu korrelieren, die von Ihrer Bereitstellungspipeline erzeugt werden.

Dieser Abschnitt enthält Best Practices, mit denen Sie einen Audit-Trail in Google Cloud und Ihren Bereitstellungspipelines verwalten können.

Best Practices:

Sicherstellen, dass Sie Deployment-Pipeline-Logs mit Cloud-Audit-Logs korrelieren können
Aufbewahrungsdauer von Deployment-Pipeline-Logs und Cloud-Audit-Logs aufeinander abstimmen.

Sicherstellen, dass Sie Deployment-Pipeline-Logs mit Cloud-Audit-Logs korrelieren können

Cloud-Audit-Logs enthalten Zeitstempel und Informationen zu dem Nutzer, der eine Aktivität initiiert hat. Wenn Sie ein dediziertes Dienstkonto für jede Bereitstellungspipeline verwenden, können Sie mit diesen Informationen die Bereitstellungspipeline ermitteln, die die Aktivität initiiert hat. Außerdem können Sie mithilfe dieser Informationen eingrenzen, welche Codeänderungen und Pipelineausführen verantwortlich sein können. Es kann jedoch schwierig sein, die genaue Pipelineausführung und Codeänderung zu identifizieren, die zu der Aktivität geführt haben, ohne mehr Informationen zu haben, über die Sie Audit-Logs mit den Logs Ihrer Bereitstellungspipeline korrelieren können.

Sie können Cloud-Audit-Logs auf verschiedene Arten anreichern sodass sie mehr Infos enthalten, einschließlich:

  • Wenn Sie Terraform verwenden, geben Sie einen Anfragegrund an, der die Ausführung der CI/CD-Pipeline angibt.
  • Fügen Sie den API-Anfragen einen HTTP-Header X-Goog-Request-Reason hinzu und übergeben Sie die ID der Ausführung der Bereitstellungs-Pipeline.
  • Verwenden Sie eine benutzerdefinierte User-Agent, die die ID der Bereitstellungs-Pipeline-Ausführung einbettet.

Sie können auch die von Ihrer Bereitstellungspipeline ausgegebenen Logs anreichern:

  • Aufzeichnen der API-Anfragen, die bei jeder CI-/CD-Pipelineausführung ausgeführt werden.
  • Jedes Mal, wenn die API eine Vorgangs-ID zurückgibt, die ID in den Logs des CI/CD-Systems vermerken.

Aufbewahrungsdauer von Deployment-Pipeline-Logs und Cloud-Audit-Logs aufeinander abstimmen.

Zum Analysieren verdächtiger Aktivitäten im Zusammenhang mit einer Bereitstellungspipeline benötigen Sie in der Regel mehrere Arten von Logs, einschließlich Audit-Logs zur Administratoraktivität, Audit-Logs zum Datenzugriff und die Logs der Bereitstellungspipeline.

Cloud Logging speichert Logs nur für einen bestimmten Zeitraum. Standardmäßig ist diese Aufbewahrungsdauer für Audit-Logs zum Datenzugriff kürzer als für Audit-Logs zur Administratoraktivität. Das System, in dem Ihre Bereitstellungspipeline ausgeführt wird, kann seine Logs auch nach einem bestimmten Zeitraum verwerfen. Je nach Art der Bereitstellungspipeline und der Bedeutung der von der Bereitstellungspipeline verwalteten Ressourcen sind diese Standardaufbewahrungsdauern möglicherweise nicht ausreichend oder falsch ausgerichtet.

Achten Sie darauf, dass die von den verschiedenen Systemen verwendeten Werte für die Log-Aufbewahrungsdauer angepasst und ausreichend lang sind, damit Logs bei Bedarf verfügbar sind.

Passen Sie bei Bedarf die Aufbewahrungsdauer für Audit-Logs zum Datenzugriff an oder richten Sie eine benutzerdefinierte Senke ein, um Logs an einen benutzerdefinierten Speicherort weiterzuleiten.

Best Practices:

Das Gewähren von Direkten Zugriff auf vertrauliche Daten vermeiden
Mit VPC Service Controls Daten-Exfiltration verhindern.

Vor Bedrohungen in puncto Offenlegung von Informationen schützen

Wenn das Dienstkonto einer Bereitstellungspipeline Zugriff auf vertrauliche Daten hat, könnte ein böswilliger Akteur versuchen, diese Daten mit der Bereitstellungspipeline zu exfiltrieren. Der Zugriff der Bereitstellungspipeline auf Daten kann direkt oder indirekt erfolgen:

  • Direkt: Das Dienstkonto der Bereitstellungspipeline ist unter Umständen berechtigt, vertrauliche Daten aus Cloud Storage, BigQuery oder anderen Standorten zu lesen. Dieser Zugriff wurde möglicherweise absichtlich gewährt. Es kann jedoch auch versehentlich ein zu weitreichender Zugriff sein.

    Wenn ein böswilliger Akteur Zugriff auf eine Bereitstellungspipeline mit direktem Zugriff auf vertrauliche Daten erlangt, kann er versuchen, das Zugriffstoken des Dienstkontos zu verwenden, um auf die Daten zuzugreifen und diese zu exfiltrieren.

  • Indirekt: Zum Bereitstellen von Konfiguration oder neuen Softwareversionen hat das Dienstkonto einer Bereitstellungspipeline möglicherweise die Berechtigung zum Erstellen oder erneuten Bereitstellen von VM-Instanzen, Cloud Run-Anwendungen oder anderen Computing-Ressourcen. Einige dieser Rechenressourcen haben möglicherweise ein angehängtes Dienstkonto, das Zugriff auf vertrauliche Daten gewährt.

    In diesem Fall könnte ein böswilliger Akteur versuchen, die Bereitstellungspipeline zu manipulieren, damit sie schädlichen Code in einer der Rechenressourcen bereitstellt und diesen Code zur Exfiltration vertraulicher Daten verwenden.

Dieser Abschnitt enthält Best Practices, mit denen Sie das Risiko der Offenlegung vertraulicher Daten begrenzen können.

Das Gewähren von Direkten Zugriff auf vertrauliche Daten vermeiden

Zum Bereitstellen von Infrastruktur, Konfiguration oder neuen Softwareversionen benötigt eine Bereitstellungspipeline häufig keinen Zugriff auf vorhandene Daten. Stattdessen reicht es oft aus, den Zugriff auf Ressourcen zu beschränken, die keine Daten oder zumindest keine vertraulichen Daten enthalten.

Möglichkeiten zum Minimieren des Zugriffs auf vorhandene, potenziell vertrauliche Daten:

  • Anstatt dem Dienstkonto einer Bereitstellungspipeline Zugriff auf ein gesamtes Projekt zu gewähren, gewähren Sie nur Zugriff auf bestimmte Ressourcen.
  • Gewähren Sie Zugriff zum Erstellen, ohne Lesezugriff zu gewähren. Mit der Rolle Storage-Objekt-Ersteller (roles/storage.objectCreator) können Sie beispielsweise einem Dienstkonto erlauben, neue Objekte in einen Cloud Storage-Bucket hochzuladen, ohne dass es die Berechtigung hat, vorhandene Daten zu lesen.
  • Beschränken Sie "Infrastruktur als Code" auf weniger vertrauliche Ressourcen. Verwenden Sie es beispielsweise zur Verwaltung von VM-Instanzen oder Netzwerken, nicht jedoch zur Verwaltung vertraulicher BigQuery-Datasets.

Mit VPC Service Controls Daten-Exfiltration verhindern

Durch das Bereitstellen Ihrer Google Cloud-Ressourcen in einem VPC Service Controls-Perimeter können Sie das Risiko einer indirekten Daten-Exfiltration verringern.

Wenn Ihre Bereitstellungspipeline außerhalb von Google Cloud ausgeführt wird oder Teil eines anderen Perimeters ist, können Sie dem Dienstkonto der Pipeline Zugriff auf den Perimeter gewähren. Dazu konfigurieren Sie eine Regel für eingehenden Traffic. Konfigurieren Sie nach Möglichkeit die Regel für eingehenden Traffic so, dass sie nur den Zugriff über die von der Bereitstellungspipeline verwendeten IP-Adressen zulässt und nur den Zugriff auf die Dienste erlaubt, die die Bereitstellungspipeline wirklich benötigt.

Schutz vor Bedrohungen durch Rechteausweitung

Wenn eine Bereitstellungspipeline ein Dienstkonto für den Zugriff auf Google Cloud-Ressourcen verwendet, geschieht dies unabhängig vom Entwickler oder Nutzer, der eine Code- oder Konfigurationsänderung erstellt hat. Die Trennung zwischen dem Dienstkonto der Pipeline und der Identität des Entwicklers macht Bereitstellungs-Pipelines anfällig für Confused-Deputy-Angriffe, bei denen ein böswilliger Akteur die Pipeline zur Ausführung einer Aktion veranlasst, die der böswillige Akteur nicht selbst ausführen darf und die die Pipeline möglicherweise nicht ausführen sollte.

Dieser Abschnitt enthält Best Practices, mit denen Sie das Risiko des Missbrauchs der Bereitstellungspipeline für die Rechteausweitung reduzieren können.

Best Practices:

Zugriff auf die Bereitstellungspipeline und alle Eingaben beschränken
Vermeiden, es einer Bereitstellungspipeline zu erlauben, Richtlinien zu ändern
Anmeldedaten für Dienstkonten nicht in Logs anzeigen.

Zugriff auf die Bereitstellungspipeline und alle Eingaben beschränken

Die meisten Bereitstellungspipelines verwenden ein Quellcode-Repository als Haupteingabequelle. Sie können automatisch ausgelöst werden, wenn sie in bestimmten Zweigen (z. B. dem Zweig main) eine Codeänderung erkennen. Bereitstellungspipelines können normalerweise nicht prüfen, ob der Code und die Konfiguration im Quellcode-Repository echt und vertrauenswürdig sind. Die Sicherheit dieser Architektur hängt daher von folgenden Maßnahmen ab:

  • Steuern, wer Code und Konfiguration an das Repository und die Zweige senden kann, die von der Bereitstellungspipeline verwendet werden
  • Kriterien erzwingen, die erfüllt sein müssen, bevor Änderungen per Commit übernommen werden können, z. B. erfolgreiche Codeüberprüfungen, statische Analysen oder automatisierte Tests

Damit diese Kontrollen effektiv sind, müssen Sie auch sicherstellen, dass böswillige Nutzer sie nicht umgehen können, indem diese Folgendes tun:

  • Konfiguration des Quellcode-Repositorys oder der Bereitstellungspipeline ändern
  • Manipulation der Infrastruktur (z. B. VMs und Speicher), die der Bereitstellungspipeline zugrunde liegt
  • Eingaben wie Pakete, Container-Images oder Bibliotheken außerhalb des Quellcode-Repositorys ändern oder ersetzen

Bei der Verwaltung durch eine Bereitstellungspipeline können Ihre Ressourcen in Google Cloud nur so sicher sein wie Ihre Bereitstellungspipeline, deren Konfiguration, Infrastruktur und Eingaben. Daher müssen Sie diese Komponenten so gut schützen, wie Ihre Google Cloud-Ressourcen geschützt werden sollen.

Vermeiden, es einer Bereitstellungspipeline zu erlauben, Richtlinien zu ändern

Für die meisten Ressourcentypen wird in IAM die Berechtigung RESOURCE_TYPE.setIamPolicy definiert. Diese Berechtigung ermöglicht es einem Nutzer, die IAM-Richtlinie zum Zulassen von Ressourcen zu ändern, entweder um anderen Nutzern Zugriff zu gewähren oder seinen eigenen Zugriff zu ändern und zu erweitern. Sofern Sie nicht durch eine Ablehnungsrichtlinie eingeschränkt sind, hat die Zuweisung einer *.setIamPolicy-Berechtigung für einen Nutzer oder ein Dienstkonto den Effekt, dass ihm vollständiger Zugriff auf die Ressource gewährt wird.

Eine Bereitstellungspipeline sollte nach Möglichkeit den Zugriff auf Ressourcen nicht ändern. Wenn Sie dem Dienstkonto der Pipeline Zugriff auf Google Cloud-Ressourcen gewähren, verwenden Sie Rollen ohne *.setIamPolicy-Berechtigung und vermeiden Sie die einfachen Rollen Bearbeiter und Inhaber.

Bei einigen Bereitstellungspipelines kann das Gewähren der Berechtigung zum Ändern von Zulassungsrichtlinien oder Ablehnungs-Richtlinien unvermeidbar sein: Der Zweck einer Bereitstellungspipeline kann beispielsweise das Erstellen neuer Ressourcen oder das Verwalten des Zugriffs auf vorhandene Ressourcen sein. In diesen Szenarien können Sie dennoch einschränken, wie sehr die Bereitstellung den Zugriff ändern kann und zwar durch:

  • Erteilen Sie die Berechtigung *.setIamPolicy nur für bestimmte Ressourcen und nicht für das gesamte Projekt.
  • Mit IAM-Ablehnungsrichtlinien können Sie die Reihe von Berechtigungen beschränken, die gewährt werden können, oder beschränken, welchen Hauptkonten sie zugewiesen werden können.
  • Verwenden Sie IAM-Bedingungen, um einzuschränken, welche Rollen, die Pipeline erteilen darf, und um nur Rollen ohne *.setIamPolicy-Berechtigungen zulassen.

Anmeldedaten für Dienstkonten nicht in Logs anzeigen

Die von einer Bereitstellungspipeline generierten Logs sind oft für eine größere Gruppe von Nutzern zugänglich, einschließlich Nutzern, die nicht berechtigt sind, die Konfiguration der Pipeline zu ändern. Es ist möglich, dass diese Logs versehentlich Anmeldedaten durch Rückgabe von Folgendem offenlegen:

  • Inhalt von Umgebungsvariablen
  • Befehlszeilenargumente
  • Diagnoseausgabe

Wenn Logs versehentlich Anmeldedaten wie Zugriffstokens offenlegen, können diese Anmeldedaten von böswilligen Nutzern missbraucht werden, um ihre Berechtigungen zu erhöhen. So können Sie verhindern, dass Anmeldedaten an Logs angehängt werden:

  • Zugriffstoken oder andere Anmeldedaten nicht als Befehlszeilenargumente übergeben
  • Anmeldedaten nicht in Umgebungsvariablen speichern
  • CI-/CD-System so konfigurieren, dass Tokens und andere Anmeldedaten automatisch erkannt und maskiert werden wenn möglich

Nächste Schritte