Eine Bereitstellungspipeline ist ein automatisierter Prozess, bei dem Code oder vordefinierte Artefakte in einer Test- oder Produktionsumgebung bereitgestellt werden. Bereitstellungspipelines werden häufig verwendet, um Anwendungen, Konfiguration oder Cloud-Infrastruktur (Infrastruktur als Code) bereitzustellen. Sie können eine wichtige Rolle für die allgemeine Sicherheit einer Cloud-Bereitstellung spielen.
Dieser Leitfaden richtet sich an DevOps- und Sicherheitsentwickler und beschreibt Best Practices für das Entwerfen sicherer Bereitstellungspipelines anhand Ihrer Vertraulichkeits-, Integritäts- und Verfügbarkeitsanforderungen.
Architektur
Das folgende Diagramm zeigt den Datenfluss in einer Bereitstellungspipeline. Es wird gezeigt, wie Sie Ihre Artefakte in Ressourcen umwandeln.
Bereitstellungspipelines sind häufig Teil eines größeren Workflows für Continuous Integration/Continuous Deployment (CI/CD) und werden in der Regel mit einem der folgenden Modelle implementiert:
Push-Modell: In diesem Modell implementieren Sie die Bereitstellungspipeline mithilfe eines zentralen CI/CD-Systems wie Jenkins oder GitLab. Dieses CI/CD-System kann in Google Cloud, lokal oder in einer anderen Cloud-Umgebung ausgeführt werden. Häufig wird dasselbe CI/CD-System zum Verwalten mehrerer Bereitstellungspipelines verwendet.
Das Push-Modell führt zu einer zentralisierten Architektur mit einigen CI/CD-Systemen, die zur Verwaltung einer potenziell großen Anzahl von Ressourcen oder Anwendungen verwendet werden. Sie können beispielsweise eine einzelne Jenkins- oder GitLab-Instanz zur Verwaltung Ihrer gesamten Produktionsumgebung verwenden, einschließlich aller Projekte und Anwendungen.
Pull-Modell: In diesem Modell wird der Bereitstellungsprozess von einem Agent implementiert, der zusammen mit der Ressource bereitgestellt wird, z. B. im selben Kubernetes-Cluster. Der Agent ruft Artefakte oder Quellcode aus einem zentralen Speicherort ab und stellt sie lokal bereit. Jeder Agent verwaltet eine oder zwei Ressourcen.
Das Pull-Modell führt zu einer dezentralisierten Architektur mit einer potenziell großen Anzahl von zweckgebundenen Agents.
Im Vergleich zu manuellen Bereitstellungen kann die konsistente Verwendung von Bereitstellungspipelines die folgenden Vorteile bieten:
- Höhere Effizienz, da keine manuelle Arbeit erforderlich ist.
- Höhere Zuverlässigkeit, da der Prozess vollständig automatisiert und wiederholbar ist
- Erhöhte Rückverfolgbarkeit, da Sie alle Bereitstellungen bis zu Änderungen im Code oder zu Eingabeartefakten zurückverfolgen können.
Für die Ausführung benötigt eine Bereitstellungspipeline Zugriff auf die von ihr verwalteten Ressourcen:
- Eine Pipeline, die Infrastruktur mithilfe von Tools wie Terraform bereitstellt, muss möglicherweise Ressourcen wie VM-Instanzen, Subnetze oder Cloud Storage-Buckets erstellen, ändern oder löschen.
- Eine Pipeline, die Anwendungen bereitstellt, muss möglicherweise neue Container-Images in Artifact Registry hochladen und neue Anwendungsversionen in App Engine, Cloud Run oder Google Kubernetes Engine (GKE) bereitstellen.
- Für eine Pipeline, die Einstellungen verwaltet oder Konfigurationsdateien bereitstellt, müssen möglicherweise VM-Instanzmetadaten, Kubernetes-Konfigurationen oder Daten in Cloud Storage geändert werden.
Wenn Ihre Bereitstellungspipelines nicht ordnungsgemäß geschützt sind, kann ihr Zugriff auf Google Cloud-Ressourcen zu einer Schwachstelle im Sicherheitsstatus werden. Schwachstellen in der Sicherheit können zu verschiedenen Arten von Angriffen führen, darunter auch zu den folgenden:
Pipeline-Poisoning-Angriffe: Anstatt eine Ressource direkt anzugreifen, könnte ein böswilliger Akteur versuchen, die Bereitstellungspipeline, ihre Konfiguration oder die zugrunde liegende Infrastruktur zu manipulieren. Unter Ausnutzung des Zugriffs der Pipeline auf Google Cloud könnte der böswillige Akteur die Pipeline dazu bringen, böswillige Aktionen auf Cloud-Ressourcen auszuführen, wie im folgenden Diagramm dargestellt:
Lieferkettenangriffe: Anstatt die Bereitstellungspipeline anzugreifen, kann ein böswilliger Akteur versuchen, Pipelineeingaben zu manipulieren oder zu ersetzen, einschließlich Quellcode, Bibliotheken oder Container-Images, wie im folgenden Diagramm gezeigt:
Um festzustellen, ob Ihre Bereitstellungspipelines angemessen abgesichert sind, reicht es nicht aus, nur die Zulassungs- und Ablehnungsrichtlinien von Google Cloud-Ressourcen isoliert zu betrachten. Stattdessen müssen Sie die gesamte Grafik der Systeme berücksichtigen, die direkt oder indirekt Zugriff auf eine Ressource gewähren. Diese Grafik enthält folgende Informationen:
- Die Bereitstellungspipeline, das zugrunde liegende CI/CD-System und die zugrunde liegende Infrastruktur
- Das Quellcode-Repository, die zugrunde liegenden Server und die zugrunde liegende Infrastruktur
- Eingabeartefakte, ihre Speicherorte und die zugrunde liegende Infrastruktur
- Systeme, die die Eingabeartefakte erzeugen, und ihre zugrunde liegende Infrastruktur
Komplexe Eingabediagramme erschweren den Nutzerzugriff auf Ressourcen und Schwachstellen im System.
In den folgenden Abschnitten werden Best Practices für das Entwerfen von Bereitstellungspipelines beschrieben, mit denen Sie die Größe des Diagramms verwalten und das Risiko von seitlichen Bewegungen und Lieferkettenangriffen reduzieren können.
Sicherheitsziele bewerten
Ihre Ressourcen in Google Cloud variieren wahrscheinlich in Bezug auf ihre Vertraulichkeit. Einige Ressourcen sind möglicherweise vertraulich, da sie geschäftskritisch oder vertraulich sind. Andere Ressourcen sind möglicherweise weniger vertraulich, da sie sitzungsspezifisch oder nur für Testzwecke vorgesehen sind.
Um eine sichere Bereitstellungspipeline zu entwerfen, müssen Sie zuerst die Ressourcen verstehen, auf die die Pipeline zugreifen muss, und wie vertraulich diese Ressourcen sind. Je vertraulicher Ihre Ressourcen sind, desto mehr sollten Sie sich auf die Sicherung der Pipeline konzentrieren.
Die Ressourcen, auf die Bereitstellungspipelines zugreifen, können Folgendes umfassen:
- Anwendungen wie Cloud Run oder App Engine
- Cloud-Ressourcen wie VM-Instanzen oder Cloud Storage-Buckets
- Daten wie Cloud Storage-Objekte, BigQuery-Datensätze oder -Dateien
Einige dieser Ressourcen haben möglicherweise Abhängigkeiten von anderen Ressourcen, z. B.:
- Anwendungen greifen möglicherweise auf Daten, Cloud-Ressourcen und andere Anwendungen zu.
Cloud-Ressourcen wie VM-Instanzen oder Cloud Storage-Buckets können Anwendungen oder Daten enthalten.
Wie im vorherigen Diagramm dargestellt, hängen Abhängigkeiten davon ab, wie vertraulich eine Ressource ist. Wenn Sie beispielsweise eine Anwendung verwenden, die auf hochsensible Daten zugreift, sollten Sie diese Anwendung in der Regel als sehr vertraulich behandeln. Wenn eine Cloud-Ressource wie ein Cloud Storage-Bucket sensible Daten enthält, sollten Sie den Bucket in der Regel als vertraulich behandeln.
Aufgrund dieser Abhängigkeiten sollten Sie zuerst die Vertraulichkeit Ihrer Daten bewerten. Nachdem Sie Ihre Daten bewertet haben, können Sie die Abhängigkeitskette prüfen und die Vertraulichkeit Ihrer Cloud-Ressourcen und -Anwendungen bewerten.
Vertraulichkeit Ihrer Daten kategorisieren
Beachten Sie die folgenden drei Ziele, um die Vertraulichkeit der Daten in Ihrer Bereitstellungspipeline zu verstehen:
- Vertraulichkeit: Sie müssen die Daten vor unbefugtem Zugriff schützen.
- Integrität: Sie müssen die Daten vor unbefugtem Ändern oder Löschen schützen.
- Verfügbarkeit: Sie müssen dafür sorgen, dass autorisierte Personen und Systeme auf die Daten in Ihrer Bereitstellungspipeline zugreifen können.
Fragen Sie sich bei jedem dieser Ziele, was passieren würde, wenn Ihre Pipeline verletzt wird:
- Vertraulichkeit: Wie groß wäre der Schaden, wenn Daten einem böswilligen Akteur offengelegt oder der Öffentlichkeit zugänglich gemacht werden?
- Integrität: Wie groß wäre der Schaden, wenn Daten von einem böswilligen Akteur verändert oder gelöscht würden?
- Verfügbarkeit: Wie groß wäre der Schaden, wenn ein böswilliger Akteur Ihren Datenzugriff unterbrechen würde?
Damit die Ergebnisse ressourcenübergreifend vergleichbar sind, ist es hilfreich, Sicherheitskategorien einzuführen. Die Standards für die Sicherheitskategorisierung (FIPS-199) schlägt die folgenden vier Kategorien vor:
- Hoch: Der Schaden wäre schwerwiegend oder katastrophal
- Mittel: Der Schaden wäre ernst
- Niedrig: Der Schaden würde sich in Grenzen halten
- Nicht zutreffend: Der Standard gilt nicht
Je nach Umgebung und Kontext können andere Kategorien besser geeignet sein.
Die Vertraulichkeit und Integrität der Pipelinedaten sind auf der Grundlage der gerade erläuterten Sicherheitskategorien unterschiedlich. Die folgenden Unterabschnitte enthalten Beispiele für Ressourcen mit unterschiedlichen Vertraulichkeits- und Integritätsmessungen.
Ressourcen mit niedriger Vertraulichkeit, aber niedriger, mittlerer und hoher Integrität
Die folgenden Ressourcenbeispiele haben alle eine niedrige Vertraulichkeit:
- Niedrige Integrität: Testdaten
- Mittlere Integrität: Inhalt öffentlicher Webserver, Richtlinieneinschränkungen für Ihre Organisation
- Hohe Integrität: Container-Images, Laufwerk-Images, Anwendungskonfigurationen, Zugriffsrichtlinien (Zulassungs- und Ablehnungslisten), Sperren, Daten auf Zugriffsebene
Ressourcen mit mittlerer Vertraulichkeit, aber niedriger, mittlerer und hoher Integrität
Die folgenden Ressourcenbeispiele haben alle eine mittlere Vertraulichkeit:
- Niedrige Integrität: Interner Webserverinhalt
- Mittlere Integrität: Audit-Logs
- Hohe Integrität: Konfigurationsdateien der Anwendung
Ressourcen mit hoher Vertraulichkeit, aber niedriger, mittlerer und hoher Integrität
Die folgenden Ressourcenbeispiele haben alle eine hohe Vertraulichkeit:
- Niedrige Integrität: Nutzungsdaten und personenidentifizierbare Informationen
- Mittlere Integrität: Secrets
- Hohe Integrität: Finanzdaten, KMS-Schlüssel
Anwendungen basierend auf den Daten kategorisieren, auf die sie zugreifen
Wenn eine Anwendung auf sensible Daten zugreift, können die Anwendung und die Bereitstellungspipeline, die die Anwendung verwaltet, ebenfalls vertraulich werden. Sehen Sie sich die Daten an, auf die die Anwendung und die Pipeline zugreifen muss, um diese Vertraulichkeit zu qualifizieren.
Nachdem Sie alle Daten, auf die eine Anwendung zugreift, identifiziert und kategorisiert haben, können Sie die folgenden Kategorien verwenden, um die Anwendung erst einmal zu kategorisieren, bevor Sie eine sichere Bereitstellungspipeline entwerfen:
- Vertraulichkeit: Die höchste Kategorie aller Daten, auf die zugegriffen wird
- Integrität: Die höchste Kategorie aller Daten, auf die zugegriffen wird
- Verfügbarkeit: Die höchste Kategorie aller Daten, auf die zugegriffen wird
Die erste Bewertung bietet eine Orientierungshilfe. Es müssen jedoch möglicherweise weitere Faktoren berücksichtigt werden. Beispiel:
- Zwei Datensätze können für sich genommen eine geringe Vertraulichkeit haben. In Kombination ergeben diese jedoch neue Erkenntnisse. Wenn eine Anwendung Zugriff auf beide Datensätze hat, müssen Sie sie möglicherweise als mittel- oder hochvertraulich einstufen.
- Wenn eine Anwendung Zugriff auf Daten mit hoher Integrität hat, sollten Sie die Anwendung normalerweise mit hoher Integrität kategorisieren. Handelt es sich jedoch um einen reinen Lesezugriff, könnte eine Kategorisierung mit hoher Integrität zu streng sein.
Einzelheiten zu einem formalen Ansatz zur Kategorisierung von Anwendungen finden Sie im Leitfaden zum Zuordnen von Informations- und Informationssystemen zu Sicherheitskategorien (NIST SP 800-60 Vol. 2 Rev1).
Cloudressourcen basierend auf den Daten und Anwendungen kategorisieren, die sie hosten
Alle Daten oder Anwendungen, die Sie in Google Cloud bereitstellen, werden von einer Google Cloud-Ressource gehostet:
- Eine Anwendung kann von einem App Engine-Dienst, einer VM-Instanz oder einem GKE-Cluster gehostet werden.
- Ihre Daten können von einem nichtflüchtigen Speicher, einem Cloud Storage-Bucket oder einem BigQuery-Dataset gehostet werden.
Wenn eine Cloud-Ressource sensible Daten oder Anwendungen hostet, können die Ressource und die Bereitstellungspipeline, die die Ressource verwaltet, ebenfalls vertraulich werden. Beispielsweise sollten Sie einen Cloud Run-Dienst und seine Bereitstellungspipeline so vertraulich betrachten wie die Hosting-Anwendung.
Nachdem Sie Ihre Daten und Ihre Anwendungen kategorisiert haben, erstellen Sie eine erste Sicherheitskategorie für die Anwendung. Ermitteln Sie dazu eine Ebene aus den folgenden Kategorien:
- Vertraulichkeit: Die höchste Kategorie aller gehosteten Daten oder Anwendungen
- Integrität: Die höchste Kategorie aller gehosteten Daten oder Anwendungen
- Verfügbarkeit: Die höchste Kategorie aller gehosteten Daten oder Anwendungen
Seien Sie bei Ihrer ersten Beurteilung nicht zu streng. Beispiel:
- Wenn Sie hoch vertrauliche Daten verschlüsseln, sollten Sie auch den Verschlüsselungscode als hoch vertraulich behandeln. Sie können jedoch eine niedrigere Sicherheitskategorie für die Ressource verwenden, die die Daten enthält.
- Wenn Sie redundante Datenkopien speichern oder redundante Instanzen derselben Anwendungen auf mehreren Ressourcen ausführen, können Sie die Kategorie der Ressource niedriger ansetzen als die Kategorie der Daten oder Anwendungen, die sie hostet.
Verwendung von Bereitstellungspipelines einschränken
Wenn Ihre Bereitstellungspipeline auf vertrauliche Google Cloud-Ressourcen zugreifen muss, müssen Sie deren Sicherheitsstatus berücksichtigen. Je vertraulicher die Ressourcen sind, desto besser müssen Sie die Pipeline sichern. Es können jedoch folgende praktische Einschränkungen auftreten:
- Bei Verwendung einer vorhandenen Infrastruktur oder eines vorhandenen CI/CD-Systems kann diese Infrastruktur das Sicherheitsniveau einschränken, das Sie realistisch erreichen können. Beispielsweise unterstützt Ihr CI/CD-System möglicherweise nur eine begrenzte Anzahl von Sicherheitskontrollen oder es wird auf einer Infrastruktur ausgeführt, die Sie als weniger sicher betrachten als einige Ihrer Produktionsumgebungen.
- Wenn Sie eine neue Infrastruktur und neue Systeme für Ihre Bereitstellungspipeline einrichten, ist es möglicherweise nicht kosteneffektiv, alle Komponenten so zu sichern, dass sie Ihren strengsten Sicherheitsanforderungen entsprechen.
Um mit diesen Einschränkungen umzugehen, kann es sinnvoll sein, festzulegen, für welche Szenarien Bereitstellungspipelines und ein bestimmtes CI/CD-System verwendet werden sollen und für welche nicht. Beispielsweise werden die sensibelsten Bereitstellungen oft außerhalb einer Bereitstellungspipeline verarbeitet. Diese Bereitstellungen können manuell, mit einem privilegierten Sitzungsverwaltungssystem oder mit einem System für die privilegierte Zugriffssteuerung oder mit anderen Funktionen wie Tool-Proxys erfolgen.
Legen Sie basierend auf Ihren Ressourcenkategorien fest, welche Zugriffssteuerungen erzwungen werden sollen, um die Einschränkungen festzulegen. Sehen Sie sich die Anleitung in der folgenden Tabelle an:
| Kategorie der Ressource | Zugriffssteuerung |
|---|---|
| Niedrig | Keine Genehmigung erforderlich |
| Mittel | Teamleiter müssen genehmigen |
| Hoch | Mehrere Leads müssen genehmigt werden und Aktionen müssen aufgezeichnet werden |
Vergleichen Sie diese Anforderungen mit den Fähigkeiten Ihrer Quellcodeverwaltungsysteme (SCM-Systeme) und CI/CD-Systeme, indem Sie u. a. die folgenden Fragen stellen:
- Unterstützen Ihre SCM- oder CI/CD-Systeme die erforderlichen Zugriffssteuerungen und Genehmigungsmechanismen?
- Sind die Kontrollen davor geschützt, unterwandert zu werden, wenn bösartige Akteure die zugrunde liegende Infrastruktur angreifen?
- Ist die Konfiguration, die die Steuerelemente definiert, entsprechend gesichert?
Abhängig von den Funktionen und Einschränkungen Ihrer SCM- oder CI/CD-Systeme können Sie Ihre Daten- und Anwendungseinschränkungen für Ihre Bereitstellungspipelines definieren. Sehen Sie sich die Anleitung in der folgenden Tabelle an:
| Kategorie der Ressource | Einschränkungen |
|---|---|
| Niedrig | Bereitstellungspipelines können verwendet werden und Entwickler können Bereitstellungen selbst genehmigen. |
| Mittel | Bereitstellungspipelines können verwendet werden, aber ein Teamleiter muss jeden Commit und jede Bereitstellung genehmigen. |
| Hoch | Es werden keine Bereitstellungspipelines verwendet. Stattdessen müssen Administratoren ein privilegiertes Zugriffsverwaltungssystem und eine Sitzungsaufzeichnung verwenden. |
Ressourcenverfügbarkeit aufrechterhalten
Die Verwendung einer Bereitstellungspipeline zum Verwalten von Ressourcen kann sich auf die Verfügbarkeit dieser Ressourcen auswirken und neue Risiken mit sich bringen:
- Ausfälle verursachen: Eine Bereitstellungspipeline kann fehlerhafte Code- oder Konfigurationsdateien übertragen, was dazu führt, dass ein zuvor funktionierendes System nicht mehr funktioniert oder Daten unbrauchbar werden.
- Lang andauernde Ausfälle: Um einen Ausfall zu beheben, müssen Sie möglicherweise eine Bereitstellungspipeline noch einmal ausführen. Wenn die Bereitstellungspipeline aus anderen Gründen fehlerhaft ist oder nicht verfügbar ist, kann dies den Ausfall verlängern.
Eine Pipeline, die Ausfälle verursachen oder verlängern kann, stellt ein Denial of Service-Risiko dar. Ein böswilliger Akteur kann die Bereitstellungspipeline verwenden, um absichtlich einen Ausfall zu verursachen.
Notfallzugriffsverfahren erstellen
Wenn eine Bereitstellungspipeline die einzige Möglichkeit ist, eine Anwendung oder Ressource bereitzustellen oder zu konfigurieren, kann die Pipelineverfügbarkeit entscheidend sein. In extremen Fällen, in denen eine Bereitstellungspipeline die einzige Möglichkeit ist, eine geschäftskritische Anwendung zu verwalten, müssen Sie möglicherweise auch die Bereitstellungspipeline als geschäftskritisch betrachten.
Da Bereitstellungspipelines häufig aus mehreren Systemen und Tools stammen, kann die Aufrechterhaltung einer hohen Verfügbarkeit schwierig oder wirtschaftlich sein.
Sie können den Einfluss von Bereitstellungspipelines auf die Verfügbarkeit reduzieren, indem Sie Notfallzugriffsverfahren erstellen. Erstellen Sie beispielsweise einen alternativen Zugriffspfad, der verwendet wird, wenn die Bereitstellungspipeline nicht betriebsbereit ist.
Zum Erstellen eines Notfallzugriffsverfahrens sind in der Regel die meisten der folgenden Prozesse erforderlich:
- Sie haben eines oder mehrere Nutzerkonten mit privilegiertem Zugriff auf relevante Google Cloud-Ressourcen.
- Speichern Sie die Anmeldedaten der Nutzerkonten für den Notfallzugriff an einem sicheren Ort oder verwenden Sie ein privilegiertes Zugriffsverwaltungssystem, um den Zugriff zu erleichtern.
- Legen Sie ein Verfahren fest, an dem autorisierte Mitarbeiter auf die Anmeldedaten zugreifen können.
- Prüfen Sie, wie Nutzerkonten mit Notfallzugriff verwendet werden.
Eingabeartefakte müssen den Verfügbarkeitsanforderungen entsprechen
Bereitstellungspipelines müssen in der Regel Quellcode aus einem zentralen Quellcode-Repository herunterladen, bevor sie eine Bereitstellung ausführen können. Wenn das Quellcode-Repository nicht verfügbar ist, schlägt das Ausführen der Bereitstellungspipeline wahrscheinlich fehl.
Viele Bereitstellungspipelines hängen auch von Artefakten von Drittanbietern ab. Solche Artefakte können Bibliotheken aus Quellen wie npm, Maven Central oder NuN Gallery, sowie Container-Basis-Images sowie .deb- und .rpm-Pakete umfassen. Wenn eine der Drittanbieterquellen nicht verfügbar ist, kann die Ausführungspipeline fehlschlagen.
Sie müssen darauf achten, dass die Eingabeartefakte Ihrer Bereitstellungspipeline dieselben oder höhere Verfügbarkeitsanforderungen erfüllen, um ein bestimmtes Maß an Verfügbarkeit beizubehalten. Mit der folgenden Liste können Sie die Verfügbarkeit von Eingabeartefakten gewährleisten:
- Anzahl von Quellen für Eingabeartefakte beschränken, insbesondere Drittanbieterquellen
- Cache der Eingabeartefakte verwalten, die Bereitstellungspipelines verwenden können, wenn Quellsysteme nicht verfügbar sind
Bereitstellungspipelines und ihre Infrastruktur wie Produktionssysteme behandeln
Bereitstellungspipelines dienen häufig als Bindeglied zwischen Entwicklungs-, Staging- und Produktionsumgebungen. Je nach Umgebung können sie mehrere Phasen implementieren:
- In der ersten Phase aktualisiert die Bereitstellungspipeline eine Entwicklungsumgebung.
- In der nächsten Phase aktualisiert die Bereitstellungspipeline eine Staging-Umgebung.
- In der letzten Phase aktualisiert die Bereitstellungspipeline die Produktionsumgebung.
Wenn Sie eine Bereitstellungspipeline in mehreren Umgebungen verwenden, achten Sie darauf, dass die Pipeline die Verfügbarkeitsanforderungen der einzelnen Umgebungen erfüllt. Da Produktionsumgebungen in der Regel die höchsten Verfügbarkeitsanforderungen haben, sollten Sie die Bereitstellungspipeline und die zugrunde liegende Infrastruktur wie ein Produktionssystem behandeln. Mit anderen Worten: Wenden Sie auf die Infrastruktur, in der Ihre Bereitstellungspipelines ausgeführt werden, dieselben Zugriffs-, Sicherheits- und Qualitätsstandards an wie bei Ihren Produktionssystemen.
Umfang von Bereitstellungspipelines beschränken
Je mehr Ressourcen eine Bereitstellungspipeline nutzen kann, desto mehr Schäden können sie bei Manipulationen verursachen. Eine manipulierte Bereitstellungspipeline, die Zugriff auf mehrere Projekte oder sogar auf Ihre gesamte Organisation hat, kann im schlimmsten Fall zu einer dauerhaften Beschädigung Ihrer Daten und Anwendungen in Google Cloud führen.
Um diesen schlimmsten Fall zu vermeiden, begrenzen Sie den Umfang Ihrer Bereitstellungspipelines. Definieren Sie den Bereich jeder Bereitstellungspipeline, sodass sie nur Zugriff auf eine relativ kleine Anzahl von Ressourcen in Google Cloud benötigt:
- Anstatt Zugriff auf Projektebene zu gewähren, gewähren Sie nur Bereitstellungspipelines Zugriff auf einzelne Ressourcen.
- Gewähren Sie keinen Zugriff auf Ressourcen in mehreren Google Cloud-Projekten.
- Teilen Sie Bereitstellungspipelines in mehrere Phasen auf, wenn sie Zugriff auf mehrere Projekte oder Umgebungen benötigen. Sichern Sie dann die Phasen einzeln.
Vertraulichkeit gewährleisten
Eine Bereitstellungspipeline muss die Vertraulichkeit der verwalteten Daten aufrechterhalten. Eines der wichtigsten Risiken in Bezug auf die Vertraulichkeit ist die Daten-Exfiltration.
Es gibt mehrere Möglichkeiten, wie ein böswilliger Akteur versuchen kann, eine Bereitstellungspipeline zur Exfiltration von Daten aus Ihren Google Cloud-Ressourcen zu verwenden. Dazu gehören:
- Direkt: Ein böswilliger Akteur kann die Bereitstellungspipeline oder ihre Konfiguration ändern, sodass Daten aus Ihren Google Cloud-Ressourcen extrahiert und dann an eine andere Stelle kopiert werden.
- Indirekt: Ein böswilliger Akteur kann die Bereitstellungspipeline verwenden, um manipulierten Code bereitzustellen, der dann Daten aus Ihrer Google Cloud-Umgebung stiehlt.
Sie können Vertraulichkeitsrisiken reduzieren, indem Sie den Zugriff auf vertrauliche Ressourcen minimieren. Es ist jedoch unpraktikabel, den gesamten Zugriff auf vertrauliche Ressourcen zu entfernen. Daher müssen Sie Ihre Bereitstellungspipeline so gestalten, dass sie die Vertraulichkeitsanforderungen der von ihr verwalteten Ressourcen erfüllt. Mit dem folgenden Ansatz können Sie diese Anforderungen ermitteln:
- Bestimmen Sie die Daten, Anwendungen und Ressourcen, auf die die Bereitstellungspipeline zugreifen muss, und kategorisieren Sie sie.
- Suchen Sie die Ressource mit der höchsten Vertraulichkeitskategorie und verwenden Sie sie als anfängliche Kategorie für die Bereitstellungspipeline.
Ähnlich wie beim Kategorisierungsprozess für Anwendungen und Cloud-Ressourcen ist diese erste Bewertung nicht immer geeignet. Sie können beispielsweise eine Bereitstellungspipeline verwenden, um Ressourcen zu erstellen, die letztendlich vertrauliche Informationen enthalten. Wenn Sie die Bereitstellungspipeline so einschränken, dass sie diese Ressourcen erstellen, aber nicht lesen kann, reicht eine niedrigere Vertraulichkeitskategorie möglicherweise aus.
Zur Wahrung der Vertraulichkeit schlägt das Bell–LaPadula-Modell vor, dass eine Bereitstellungspipeline Folgendes nicht tun darf:
- Eingabeartefakte mit höherer Vertraulichkeit nutzen
- Daten in eine Ressource mit geringerer Vertraulichkeit schreiben
Gemäß dem Bell–LaPadula-Modell zeigt das obige Diagramm, wie Daten in der Pipeline fließen sollten, um die Vertraulichkeit von Daten zu gewährleisten.
Bereitstellungspipelines keine Daten lesen lassen, die sie nicht benötigen
Verteilungspipelines benötigen oft keinen Zugang zu Daten, können ihn aber dennoch haben. Eine solche Vergabe von Zugriff kann zu Folgendem führen:
- Falsche Zugriffsberechtigungen gewähren. Einer Bereitstellungspipeline kann beispielsweise auf Projektebene Zugriff auf Cloud Storage gewährt werden. Daher kann die Bereitstellungspipeline auf alle Cloud Storage-Buckets im Projekt zugreifen, obwohl der Zugriff auf einen einzelnen Bucket möglicherweise ausreichend ist.
- Eine zu moderate Rolle verwenden. Einer Bereitstellungspipeline kann beispielsweise eine Rolle zugewiesen werden, die vollständigen Zugriff auf Cloud Storage ermöglicht. Die Berechtigung zum Erstellen neuer Buckets würde jedoch ausreichen.
Je mehr Daten auf eine Pipeline zugreifen können, desto höher ist das Risiko, dass jemand oder etwas Ihre Daten stehlen kann. Vermeiden Sie es, Bereitstellungspipelines Zugriff auf alle Daten zu gewähren, die sie nicht benötigen, um dieses Risiko zu minimieren. Viele Bereitstellungspipelines benötigen überhaupt keinen Datenzugriff, da sie ausschließlich dazu dienen, Konfigurations- oder Softwarebereitstellungen zu verwalten.
Bereitstellungspipelines keinen Schreibzugriff für Stellen gewähren, die sie nicht benötigen
Damit ein böswilliger Akteur Daten entfernen kann, benötigt er Zugriff und eine Möglichkeit, die Daten aus Ihrer Umgebung weiterzuleiten. Je mehr Speicher- und Netzwerkstandorte eine Bereitstellungspipeline ansteuern kann, desto wahrscheinlicher ist es, dass ein böswilliger Akteur einen dieser Standorte für die Exfiltration nutzen kann.
Sie können das Risiko reduzieren, indem Sie die Anzahl der Netzwerk- und Speicherorte begrenzen, an denen eine Pipeline Daten senden kann:
- Entziehen Sie Schreibzugriff auf Ressourcen, die die Pipeline nicht benötigt, auch wenn die Ressourcen keine vertraulichen Daten enthalten.
- Blockieren Sie den Internetzugang oder beschränken Sie Verbindungen auf eine Reihe von Netzwerkstandorten, die auf einer Zulassungsliste für zulässige Verbindungen stehen.
Die Beschränkung des ausgehenden Zugriffs ist besonders wichtig für Pipelines, die Sie als vertraulich oder streng vertraulich kategorisiert haben, da sie Zugriff auf vertrauliche Daten oder kryptografisches Schlüsselmaterial haben.
Mit VPC Service Controls verhindern, dass manipulierte Bereitstellungen Daten stehlen
Anstatt die Datenexfiltration durch die Bereitstellungspipeline durchführen zu lassen, könnte ein böswilliger Akteur versuchen, die Bereitstellungspipeline zu nutzen, um kompromittierten Code bereitzustellen. Dieser manipulierte Code kann dann Daten aus Ihrer Google Cloud-Umgebung stehlen.
Sie können das Risiko eines solchen Datendiebstahls verringern, indem Sie VPC Service Controls verwenden. Mit VPC Service Controls können Sie die Gruppe von Ressourcen und APIs einschränken, auf die in bestimmten Google Cloud-Projekten zugegriffen werden kann.
Integrität aufrechterhalten
Um Ihre Google Cloud-Umgebung zu schützen, müssen Sie deren Integrität schützen. Dazu zählen:
- Unbefugtes Ändern oder Löschen von Daten oder Konfigurationen verhindern
- Bereitstellung von nicht vertrauenswürdigem Code oder Konfigurationen verhindern
- Alle Änderungen müssen einen klaren Audit-Trail hinterlassen
Bereitstellungspipelines können Ihnen helfen, die Integrität Ihrer Umgebung aufrechtzuerhalten, indem sie Ihnen Folgendes ermöglichen:
- Genehmigungsprozesse implementieren, z. B. in Form von Codeüberprüfungen
- Einheitlichen Prozess für alle Konfigurations- oder Codeänderungen erzwingen
- Vor jeder Bereitstellung automatisierte Tests oder Schnellprüfungen ausführen
Für eine effektive Effektivität müssen Sie dafür sorgen, dass böswillige Akteure diese Maßnahmen nicht untergraben oder umgehen können. Um solche Aktivitäten zu verhindern, müssen Sie die Integrität von Folgendem schützen:
- Die Bereitstellungspipeline und ihre Konfiguration
- Die zugrunde liegende Infrastruktur
- Alle von der Bereitstellungspipeline genutzten Eingaben
Wenn Sie verhindern möchten, dass die Bereitstellungspipeline anfällig ist, sollten Sie prüfen, ob die Integritätsstandards der Bereitstellungspipeline den Integritätsanforderungen der von ihr verwalteten Ressourcen entsprechen oder diese übertreffen. Mit dem folgenden Ansatz können Sie diese Anforderungen ermitteln:
- Bestimmen Sie die Daten, Anwendungen und Ressourcen, auf die die Bereitstellungspipeline zugreifen muss, und kategorisieren Sie sie.
- Suchen Sie die Ressource mit der höchsten Integritätskategorie und verwenden Sie sie als Kategorie für die Bereitstellungspipeline.
Das Biba-Modell empfiehlt Folgendes, um die Integrität der Bereitstellungspipeline aufrechtzuerhalten:
- Die Bereitstellungspipeline darf keine Eingabeartefakte mit niedrigerer Integrität verbrauchen.
- Die Bereitstellungspipeline darf keine Daten in eine Ressource mit höherer Integrität schreiben.
Gemäß dem Biba-Modell zeigt das obige Diagramm, wie die Daten in der Pipeline fließen sollten, um die Datenintegrität zu gewährleisten.
Authentizität von Eingabeartefakten prüfen
Viele Bereitstellungspipelines verwenden Artefakte von Drittanbieterquellen. Solche Artefakte können sein:
- Docker-Basis-Images
.rpm- oder.deb-Pakete- Maven-,
.npm- oder NuGet-Bibliotheken
Ein böswilliger Akteur kann versuchen, Ihre Bereitstellungspipeline so zu ändern, dass manipulierte Versionen von Drittanbieterartefakten verwendet werden. Dafür muss Folgendes beachtet werden:
- Manipulation des Repositorys, das die Artefakte speichert
- Konfiguration der Bereitstellungspipeline so ändern, dass ein anderes Quell-Repository verwendet wird
- Schädliche Pakete mit ähnlichen Namen oder Namen mit Tippfehlern hochladen
Viele Paketmanager ermöglichen die Überprüfung der Authentizität eines Pakets durch die Unterstützung von Codesignaturen. Sie können beispielsweise PGP verwenden, um RPM- und Maven-Pakete zu signieren. Sie können Authenticode zum Signieren von NuGet-Paketen verwenden.
Sie können Codesignierung verwenden, um das Risiko zu verringern, Opfer von kompromittierten Paketen von Drittanbietern zu werden, indem Sie folgendes beachten:
- Alle Artefakt von Drittanbietern müssen signiert sein
- Führen Sie eine Liste ausgewählter vertrauenswürdiger Publisher-Zertifikate oder öffentlicher Schlüssel
- Lassen Sie die Bereitstellungspipeline die Signatur von Drittanbieterartefakten anhand der Liste der vertrauenswürdigen Publisher überprüfen
Alternativ können Sie die Hashes der Artefakte prüfen. Sie können diesen Ansatz für Artefakte verwenden, die die Codesignierung nicht unterstützen und sich nur selten ändern.
Die zugrunde liegende Infrastruktur muss Ihren Integritätsanforderungen entsprechen
Anstatt die Bereitstellungspipeline selbst zu kompromittieren, könnten böswillige Akteure versuchen, deren Infrastruktur zu kompromittieren, einschließlich:
- Die CI/CD-Software, die die Bereitstellungspipeline ausführt
- Die von der Pipeline verwendeten Tools, z. B. Terraform, kubectl oder Docker
- Das Betriebssystem und alle seine Komponenten
Da die Infrastruktur, die den Bereitstellungspipelines zugrunde liegt, oft komplex ist und Komponenten von verschiedenen Anbietern oder Quellen enthalten kann, ist diese Art von Sicherheitsverstößen schwer zu erkennen.
So können Sie das Risiko einer manipulierten Infrastruktur verringern:
- Die Infrastruktur und alle ihre Komponenten unterliegen denselben Integritätsstandards wie die Bereitstellungspipeline und die von ihr verwalteten Google Cloud-Ressourcen
- Tools müssen aus einer vertrauenswürdigen Quelle stammen und ihre Authentizität muss überprüft werden
- Die Infrastruktur regelmäßig von Grund auf neu erstellen
- Die Bereitstellungspipeline auf Shielded VMs ausführen
Integritätskontrollen in der Pipeline anwenden
Böswillige Akteure sind zwar eine Bedrohung, aber sie sind nicht die einzige mögliche Quelle für Software- oder Konfigurationsänderungen, die die Integrität Ihrer Google Cloud-Umgebung beeinträchtigen können. Solche Änderungen können auch von Entwicklern stammen und einfach versehentlich, aus Unkenntnis oder aufgrund von Tippfehlern und anderen Fehlern entstehen.
Durch das Konfigurieren von Bereitstellungspipelines können Sie das Risiko einer versehentlichen Anwendung riskanter Änderungen verringern und zusätzliche Integritätskontrollen anwenden. Folgende Kontrollen sind möglich:
- Statische Analyse von Code und Konfiguration durchführen
- Erfordernis, dass alle Änderungen eine Reihe von Regeln erfüllen (Richtlinie als Code)
- Anzahl der Änderungen begrenzen, die gleichzeitig vorgenommen werden können
Nächste Schritte
- Best Practices für die Verwendung von Dienstkonten in Bereitstellungspipelines
- Best Practices zum Schutz von Dienstkonten
- Bedrohungen untersuchen und darauf reagieren
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.