Freigeben über

Sicherheitssteuerung: DevOps-Sicherheit

Die DevOps-Sicherheit umfasst Kontrollmechanismen im Zusammenhang mit der Sicherheitsentwicklung und den Sicherheitsvorgängen in DevOps-Prozessen ab. Dazu gehört die Bereitstellung kritischer Sicherheitsüberprüfungen (z. B. statische Anwendungssicherheitstests, Sicherheitsrisikomanagement) vor der Bereitstellungsphase, um die Sicherheit während des gesamten DevOps-Prozesses zu gewährleisten. Zudem fallen darunter auch allgemeine Themen wie Gefahrenmodellierung und Softwarebereitstellungssicherheit.

DS-1: Durchführen der Gefahrenmodellierung

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.10, 16.14 SA-15 6.5, 12.2

Sicherheitsprinzip: Durchführen der Bedrohungsmodellierung zur Identifizierung potenzieller Bedrohungen und Aufzählen der mildernden Steuerelemente. Stellen Sie sicher, dass Ihre Gefahrenmodellierung die folgenden Zwecke erfüllt:

  • Schützen Ihrer Anwendungen und Dienste in der Laufzeitphase der Produktion.
  • Schützen der Artefakte, der zugrunde liegenden CI/CD-Pipeline und anderer Toolumgebungen, die zum Erstellen, Testen und Bereitstellen verwendet werden. Die Gefahrenmodellierung sollte mindestens die folgenden Aspekte umfassen:
  • Definieren der Sicherheitsanforderungen der Anwendung. Stellen Sie sicher, dass diese Anforderungen bei der Gefahrenmodellierung angemessen berücksichtigt werden.
  • Analysieren von Anwendungskomponenten und Datenverbindungen sowie von deren Beziehungen. Stellen Sie sicher, dass diese Analyse auch die Upstream- und Downstreamverbindungen außerhalb Ihres Anwendungsbereichs umfasst.
  • Auflisten der potenziellen Bedrohungen und Angriffsvektoren, denen Ihre Anwendungskomponenten, Datenverbindungen und Upstream- und Downstreamdienste möglicherweise ausgesetzt sind.
  • Identifizieren der anwendbaren Sicherheitskontrollen, mit deren Hilfe die aufgelisteten Bedrohungen entschärft werden können, und Identifizieren von Kontrolllücken (z. B. Sicherheitsrisiken), die möglicherweise zusätzliche Behandlungspläne erfordern.
  • Aufzählen und Entwerfen der Kontrollen, mit denen die identifizierten Sicherheitsrisiken entschärft werden können.

Azure-Leitfaden: Verwenden Sie Tools zur Bedrohungsmodellierung, z. B. das Microsoft-Tool zur Bedrohungsmodellmodellerstellung mit eingebetteter Azure-Bedrohungsmodellvorlage, um Ihren Bedrohungsmodellprozess voranzutreiben. Verwenden Sie das STRIDE-Modell, um sowohl interne als auch externe Bedrohungen aufzulisten und die anwendbaren Kontrollen zu identifizieren. Stellen Sie sicher, dass beim Gefahrenmodellierungsprozess die Bedrohungsszenarien im DevOps-Prozess berücksichtigt werden, z. B. die Einschleusung von schädlichem Code über ein unsicheres Artefaktrepository mit falsch konfigurierter Zugriffssteuerungsrichtlinie.

Wenn ein Bedrohungsmodellierungstool nicht anwendbar ist, sollten Sie mindestens einen fragebogenbasierten Bedrohungsmodellierungsprozess verwenden, um die Bedrohungen zu identifizieren.

Stellen Sie sicher, dass die Ergebnisse der Gefahrenmodellierung oder -analyse aufgezeichnet und aktualisiert werden, wenn eine sicherheitsrelevante Änderung an Ihrer Anwendung vorgenommen wird oder sich die Bedrohungslandschaft maßgeblich ändert.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Verwenden Sie Tools zur Bedrohungsmodellierung wie das Microsoft Threat Modeling Tool mit der eingebetteten Azure-Bedrohungsmodellvorlage, um Ihren Bedrohungsmodellprozess voranzutreiben. Verwenden Sie das STRIDE-Modell, um sowohl interne als auch externe Bedrohungen aufzulisten und die anwendbaren Kontrollen zu identifizieren. Stellen Sie sicher, dass beim Gefahrenmodellierungsprozess die Bedrohungsszenarien im DevOps-Prozess berücksichtigt werden, z. B. die Einschleusung von schädlichem Code über ein unsicheres Artefaktrepository mit falsch konfigurierter Zugriffssteuerungsrichtlinie.

Wenn ein Bedrohungsmodellierungstool nicht anwendbar ist, sollten Sie mindestens einen fragebogenbasierten Bedrohungsmodellierungsprozess verwenden, um die Bedrohungen zu identifizieren.

Stellen Sie sicher, dass die Ergebnisse der Gefahrenmodellierung oder -analyse aufgezeichnet und aktualisiert werden, wenn eine sicherheitsrelevante Änderung an Ihrer Anwendung vorgenommen wird oder sich die Bedrohungslandschaft maßgeblich ändert.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Verwenden Sie Tools zur Bedrohungsmodellierung wie das Microsoft Threat Modeling Tool mit der eingebetteten Azure-Bedrohungsmodellvorlage, um Ihren Bedrohungsmodellprozess voranzutreiben. Verwenden Sie das STRIDE-Modell, um sowohl interne als auch externe Bedrohungen aufzulisten und die anwendbaren Kontrollen zu identifizieren. Stellen Sie sicher, dass beim Gefahrenmodellierungsprozess die Bedrohungsszenarien im DevOps-Prozess berücksichtigt werden, z. B. die Einschleusung von schädlichem Code über ein unsicheres Artefaktrepository mit falsch konfigurierter Zugriffssteuerungsrichtlinie.

Wenn ein Bedrohungsmodellierungstool nicht anwendbar ist, sollten Sie mindestens einen fragebogenbasierten Bedrohungsmodellierungsprozess verwenden, um die Bedrohungen zu identifizieren.

Stellen Sie sicher, dass die Ergebnisse der Gefahrenmodellierung oder -analyse aufgezeichnet und aktualisiert werden, wenn eine sicherheitsrelevante Änderung an Ihrer Anwendung vorgenommen wird oder sich die Bedrohungslandschaft maßgeblich ändert.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):

DS-2: Sicherstellen der Sicherheit der Softwarelieferkette

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.4, 16.6, 16.11 SA-12, SA-15 6.3, 6.5

Sicherheitsprinzip: Stellen Sie sicher, dass der SDLC (Software Development Lifecycle) oder der Prozess Ihres Unternehmens eine Reihe von Sicherheitskontrollen umfasst, um die internen und Drittanbieter-Softwarekomponenten (einschließlich proprietärer und Open-Source-Software) zu steuern, bei denen Ihre Anwendungen Abhängigkeiten haben. Definieren Sie Durchlasskriterien, um zu verhindern, dass anfällige oder schädliche Komponenten in die Umgebung integriert und dort bereitgestellt werden.

Die Sicherheitskontrollen der Softwareversorgungskette sollten mindestens die folgenden Aspekte umfassen:

  • Verwalten Sie ein Software Bill of Materials (SBOM) ordentlich, indem Sie die Upstream-Abhängigkeiten identifizieren, die für die Entwicklung von Diensten/Ressourcen, die Build-, Integrations- und Bereitstellungsphase erforderlich sind.
  • Inventarisieren und Verfolgen interner Softwarekomponenten und der Softwarekomponenten von Drittanbietern im Hinblick auf bekannte Sicherheitsrisiken, wenn im Upstream eine Korrektur verfügbar ist.
  • Bewerten von Sicherheitsrisiken und Schadsoftware in den Softwarekomponenten anhand von statischen und dynamischen Anwendungstests im Hinblick auf unbekannte Sicherheitsrisiken.
  • Sicherstellen einer Entschärfung der Sicherheitsrisiken und der Schadsoftware mithilfe des entsprechenden Ansatzes. Dabei kann es sich um einen lokalen oder einen Upstreamfix des Quellcodes, den Ausschluss von Features und/oder die Anwendung ausgleichender Kontrollen handeln, wenn die direkte Entschärfung nicht verfügbar ist.

Wenn in Ihrer Produktionsumgebung Drittanbieterkomponenten aus geschlossenen Quellen verwendet werden, haben Sie möglicherweise nur eingeschränkten Einblick in deren Sicherheitsstatus. Sie sollten zusätzliche Kontrollen wie Zugriffssteuerung, Netzwerkisolation und Endpunktsicherheit in Betracht ziehen, um die Auswirkungen von schädlichen Aktivitäten oder Sicherheitsrisiken im Zusammenhang mit der Komponente zu minimieren.

Azure-Leitfaden: Stellen Sie für die GitHub-Plattform die Sicherheit der Software supply chain über die folgenden Funktionen oder Tools aus gitHub Advanced Security oder gitHub nativen Feature sicher:- Verwenden Sie Dependency Graph, um alle Abhängigkeiten und damit verbundenen Sicherheitsrisiken Ihres Projekts über die Advisory Database zu scannen, zu inventarisieren und zu identifizieren.

  • Verwenden Sie Dependabot, um sicherzustellen, dass die anfällige Abhängigkeit nachverfolgt und behoben wird, und stellen Sie sicher, dass Ihr Repository automatisch mit den neuesten Releases der Pakete und Anwendungen aktualisiert wird, von denen es abhängig ist.
  • Verwenden Sie die systemeigene Codescanfunktion von GitHub, um den Quellcode zu scannen, wenn der Code extern abgerufen wird.
  • Verwenden Sie Microsoft Defender für Cloud, um die Sicherheitsrisikobewertung für Ihr Containerimage im CI/CD-Workflow zu integrieren. Für Azure DevOps können Sie Erweiterungen von Drittanbietern verwenden, um ähnliche Kontrollen zum Inventarisieren, Analysieren und Korrigieren der Softwarekomponenten von Drittanbietern und der zugehörigen Sicherheitsrisiken zu implementieren.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Wenn Sie AWS CI/CD-Plattformen wie CodeCommit oder CodePipeline verwenden, stellen Sie sicher, dass die Sicherheit der Software supply chain mithilfe von CodeGuru Reviewer den Quellcode (für Java und Python) über die CI/CD-Workflows scannen kann. Plattformen wie CodeCommit und CodePipeline unterstützen auch Erweiterungen von Drittanbietern, um ähnliche Steuerelemente zum Inventar zu implementieren, die Softwarekomponenten von Drittanbietern und deren Sicherheitsrisiken zu analysieren und zu beheben.

Wenn Sie Ihren Quellcode über die GitHub-Plattform verwalten, stellen Sie sicher, dass die Sicherheit der Software-Lieferkette über die folgenden Funktionen oder Tools von GitHub Advanced Security oder gitHub native Feature gewährleistet ist:

  • Verwenden Sie Dependency Graph, um alle Abhängigkeiten und zugehörigen Sicherheitsrisiken Ihres Projekts über Advisory Database zu überprüfen, zu inventarisieren und zu identifizieren.
  • Verwenden Sie Dependabot, um sicherzustellen, dass die anfällige Abhängigkeit nachverfolgt und behoben wird, und stellen Sie sicher, dass Ihr Repository automatisch mit den neuesten Releases der Pakete und Anwendungen aktualisiert wird, von denen es abhängig ist.
  • Verwenden Sie die systemeigene Codescanfunktion von GitHub, um den Quellcode zu scannen, wenn der Code extern abgerufen wird.
  • Verwenden Sie ggf. Microsoft Defender für Cloud, um die Sicherheitsrisikobewertung für Ihr Containerimage im CI/CD-Workflow zu integrieren.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Verwenden des Software Delivery Shield zur Durchführung von End-to-End-Software-Lieferketten-Sicherheitsanalysen. Dazu gehört der Assured OSS -Dienst (Open Source Software) für den Zugriff und die Integration der OSS-Pakete, die von Google überprüft und getestet wurden, sowie validierte Java- und Python-Pakete, die mithilfe der sicheren Pipelines von Google erstellt wurden. Diese Pakete werden regelmäßig überprüft, analysiert und auf Sicherheitsrisiken getestet. Solche Funktionen können in Google Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis als Teil der CI/CD-Workflows integriert werden.

Wenn Sie Ihren Quellcode über die GitHub-Plattform verwalten, stellen Sie sicher, dass die Sicherheit der Software-Lieferkette über die folgenden Funktionen oder Tools von GitHub Advanced Security oder gitHub native Feature gewährleistet ist:

  • Verwenden Sie Dependency Graph, um alle Abhängigkeiten und zugehörigen Sicherheitsrisiken Ihres Projekts über Advisory Database zu überprüfen, zu inventarisieren und zu identifizieren.
  • Verwenden Sie Dependabot, um sicherzustellen, dass die anfällige Abhängigkeit nachverfolgt und behoben wird, und stellen Sie sicher, dass Ihr Repository automatisch mit den neuesten Releases der Pakete und Anwendungen aktualisiert wird, von denen es abhängig ist.
  • Verwenden Sie die systemeigene Codescanfunktion von GitHub, um den Quellcode zu scannen, wenn der Code extern abgerufen wird.
  • Verwenden Sie ggf. Microsoft Defender für Cloud, um die Sicherheitsrisikobewertung für Ihr Containerimage im CI/CD-Workflow zu integrieren.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):

DS-3: Sichere DevOps-Infrastruktur

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.7 CM-2, CM-6, AC-2, AC-3, AC-6 2.2, 6.3, 7.1

Sicherheitsprinzip: Stellen Sie sicher, dass die DevOps-Infrastruktur und -Pipeline bewährte Methoden für die Sicherheit in allen Umgebungen befolgen, einschließlich Ihrer Build-, Test- und Produktionsphasen. Dazu gehören in der Regel die Sicherheitskontrollen für den folgenden Bereich:

  • Artefaktrepositorys zum Speichern von Quellcode, erstellten Paketen und Images, Projektartefakten und Geschäftsdaten
  • Server, Dienste und Tools, die CI/CD-Pipelines hosten.
  • Konfiguration der CI/CD-Pipeline

Azure-Leitfaden: Priorisieren Sie im Rahmen der Anwendung des Microsoft Cloud Security Benchmarks auf Ihre Sicherheitskontrollen der DevOps-Infrastruktur die folgenden Steuerelemente:

  • Schützen Sie Artefakte und die zugrunde liegende Umgebung, um sicherzustellen, dass die CI/CD-Pipelines nicht zu Möglichkeiten werden, bösartigen Code einzufügen. Überprüfen Sie beispielsweise Ihre CI/CD-Pipeline, um alle Fehlkonfigurationen in den Kernbereichen von Azure DevOps zu identifizieren, z. B. Organisation, Projekte, Benutzer, Pipelines (Build & Release), Verbindungen und Build-Agent, um Fehlkonfigurationen wie open access, schwache Authentifizierung, unsichere Verbindungseinrichtung usw. zu identifizieren. Verwenden Sie für GitHub ähnliche Steuerelemente, um die Berechtigungsstufen der Organisation zu sichern.
  • Stellen Sie sicher, dass Ihre DevOps-Infrastruktur konsistent in Entwicklungsprojekten bereitgestellt wird. Verfolgen Sie die Compliance Ihrer DevOps-Infrastruktur im großen Maßstab, indem Sie Microsoft Defender für Cloud (z. B. Compliance-Dashboard, Azure-Richtlinie, Cloud-Haltungsverwaltung) oder Ihre eigenen Complianceüberwachungstools verwenden.
  • Konfigurieren Sie Identitäts-/Rollenberechtigungen und Berechtigungsrichtlinien in Azure AD, nativen Diensten und CI/CD-Tools in Ihrer Pipeline, um sicherzustellen, dass Änderungen an den Pipelines autorisiert sind.
  • Vermeiden Sie die Bereitstellung dauerhafter "ständiger" privilegierter Zugriff auf die menschlichen Konten wie Entwickler oder Tester, indem Sie Features wie von Azure verwaltete Identifizierungen und Just-in-Time-Zugriff verwenden.
  • Entfernen Sie Schlüssel, Anmeldeinformationen und geheime Schlüssel aus Code und Skripts, die in CI/CD-Workflowaufträgen verwendet werden, und bewahren Sie sie in einem Schlüsselspeicher oder Azure Key Vault auf.
  • Wenn Sie selbst gehostete Build-/Bereitstellungs-Agents ausführen, folgen Sie den Microsoft Cloud Security Benchmark-Kontrollmaßnahmen, einschließlich Netzwerksicherheit, Sicherheitsstatusmanagement und Endpunktsicherheit, um Ihre Umgebung zu schützen.

Hinweis: Lesen Sie die Abschnitte Protokollierung und Bedrohungserkennung, DS-7 und die Abschnitte "Haltungs- und Sicherheitsrisikoverwaltung", um Dienste wie Azure Monitor und Microsoft Sentinel zu verwenden, um Governance, Compliance, Betriebsüberwachung und Risikoüberwachung für Ihre DevOps-Infrastruktur zu ermöglichen.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Im Rahmen der Anwendung des Microsoft Cloud Security Benchmark auf die Sicherheitskontrollen Ihrer DevOps-Infrastruktur, z. B. GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild und CodeDeploy, priorisieren Sie die folgenden Steuerelemente:

  • Lesen Sie diese Anleitung und die Sicherheitssäule von AWS Well-architected Framework, um Ihre DevOps-Umgebungen in AWS zu sichern.
  • Schützen Sie Artefakte und die zugrunde liegende unterstützende Infrastruktur, um sicherzustellen, dass die CI/CD-Pipelines nicht zu Möglichkeiten werden, bösartigen Code einzufügen.
  • Stellen Sie sicher, dass Ihre DevOps-Infrastruktur in entwicklungsübergreifenden Projekten einheitlich bereitgestellt und nachhaltig bereitgestellt wird. Verfolgen Sie die Compliance Ihrer DevOps-Infrastruktur im großen Maßstab, indem Sie AWS Config oder Ihre eigene Compliance-Check-Lösung verwenden.
  • Verwenden Sie CodeArtifact, um Softwarepakete, die für die Anwendungsentwicklung verwendet werden, sicher zu speichern und zu teilen. Sie können CodeArtifact mit beliebten Buildtools und Paket-Managern wie Maven, Gradle, npm, Yarn, Pip und Twine verwenden.
  • Konfigurieren Sie Identitäts-/Rollenberechtigungen und Berechtigungsrichtlinien in AWS IAM- und CI/CD-Tools in Ihrer Pipeline, um sicherzustellen, dass Änderungen an den Pipelines autorisiert sind.
  • Entfernen Sie Schlüssel, Anmeldeinformationen und geheime Daten aus Code und Skripten, die in CI/CD-Workflows verwendet werden, und speichern Sie sie sicher im Schlüsselspeicher oder AWS KMS
  • Wenn Sie selbst gehostete Build-/Bereitstellungs-Agents ausführen, folgen Sie den Microsoft Cloud Security Benchmark-Kontrollmaßnahmen, einschließlich Netzwerksicherheit, Sicherheitsstatusmanagement und Endpunktsicherheit, um Ihre Umgebung zu schützen. Verwenden Sie AWS Inspector für die Sicherheitsrisikoüberprüfung für Sicherheitsrisiken in EC2 oder containerisierter Umgebung als Buildumgebung.

Hinweis: In den Abschnitten Protokollierung und Bedrohungserkennung, DS-7 und den Abschnitten "Haltungs- und Sicherheitsrisikoverwaltung" können Sie Dienste wie AWS CloudTrail, CloudWatch und Microsoft Sentinel verwenden, um Governance, Compliance, Betriebsüberwachung und Risikoüberwachung für Ihre DevOps-Infrastruktur zu ermöglichen.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Priorisieren Sie im Rahmen der Anwendung des Microsoft Cloud Security Benchmark auf Sicherheitskontrollen ihrer DevOps-Infrastruktur die folgenden Steuerelemente:

  • Schützen Sie Artefakte und die zugrunde liegende Umgebung, um sicherzustellen, dass die CI/CD-Pipelines nicht zu Möglichkeiten werden, bösartigen Code einzufügen. Überprüfen Sie beispielsweise Ihre CI/CD-Pipeline, um alle Fehlkonfigurationen in Diensten wie Google Cloud Build, Cloud Deploy, Artifact Registry, Connections und Build Agent zu identifizieren, um alle Fehlkonfigurationen wie open access, schwache Authentifizierung, unsichere Verbindungseinrichtung usw. zu identifizieren. Verwenden Sie für GitHub ähnliche Steuerelemente, um die Berechtigungsstufen der Organisation zu sichern.
  • Stellen Sie sicher, dass Ihre DevOps-Infrastruktur konsistent in Entwicklungsprojekten bereitgestellt wird. Verfolgen Sie die Compliance Ihrer DevOps-Infrastruktur im großen Maßstab mithilfe des Google Cloud Security Command Centers (z. B. Compliance-Dashboard, Organisationsrichtlinie, Aufzeichnung einzelner Bedrohungen und Identifizieren von Fehlkonfigurationen) oder Ihren eigenen Complianceüberwachungstools.
  • Konfigurieren Sie Identitäts-/Rollenberechtigungen und Berechtigungsrichtlinien in nativen Cloud Identity/AD-Diensten und CI/CD-Tools in Ihrer Pipeline, um sicherzustellen, dass Änderungen an den Pipelines autorisiert sind.
  • Vermeiden Sie permanenten"ständigen" privilegierten Zugriff auf die menschlichen Konten, z. B. Entwickler oder Tester, indem Sie Features wie google managed identifies verwenden.
  • Entfernen Sie Schlüssel, Anmeldeinformationen und geheime Schlüssel aus Code und Skripts, die in CI/CD-Workflowaufträgen verwendet werden, und bewahren Sie sie in einem Schlüsselspeicher oder Google Secret Manager auf.
  • Wenn Sie selbst gehostete Build-/Bereitstellungs-Agents ausführen, folgen Sie den Microsoft Cloud Security Benchmark-Kontrollmaßnahmen, einschließlich Netzwerksicherheit, Sicherheitsstatusmanagement und Endpunktsicherheit, um Ihre Umgebung zu schützen.

Hinweis: Lesen Sie die Abschnitte über Protokollierung und Bedrohungserkennung, DS-7 und "Haltungs- und Sicherheitsrisikomanagement", um Dienste wie Azure Monitor und Microsoft Sentinel oder die Operations Suite von Google Cloud sowie Chronicle SIEM und SOAR zu verwenden, um Governance, Compliance, Betriebsüberwachung und Risikoüberwachung für Ihre DevOps-Infrastruktur zu ermöglichen.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):

DS-4: Integrieren statischer Anwendungssicherheitstests in DevOps-Pipeline

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Sicherheitsprinzip: Sicherstellen, dass SAST-Tests (Static Application Security Testing), Fuzz-Tests, interaktive Tests und mobile Anwendungstests Teil der Prüfkontrollen im CI/CD-Workflow sind. Die Zulassung kann basierend auf den Testergebnissen festgelegt werden, um zu verhindern, dass anfällige Pakete im Repository committet, in die Pakete integriert oder in der Produktion bereitgestellt werden.

Azure-Leitfaden: Integrieren Sie SAST in Ihre Pipeline (z. B. in Ihrer Infrastruktur als Codevorlage), damit der Quellcode automatisch in Ihrem CI/CD-Workflow gescannt werden kann. Azure DevOps Pipeline oder GitHub können die folgenden Tools und SAST-Tools von Drittanbietern in den Workflow integrieren.

  • GitHub CodeQL für die Quellcodeanalyse
  • Microsoft BinSkim Binary Analyzer für Windows und *nix-Binäranalyse
  • Azure DevOps Credential Scanner (Microsoft Security DevOps-Erweiterung) und GitHubs native Erkennung von Geheimnissen für Anmeldeinformationen im Quellcode.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Integrieren Sie SAST in Ihre Pipeline, damit der Quellcode automatisch in Ihrem CI/CD-Workflow gescannt werden kann.

Wenn Sie AWS CodeCommit verwenden, verwenden Sie AWS CodeGuru Reviewer für Python und Java-Quellcodeanalyse. AWS Codepipeline kann auch die Integration von Drittanbieter-SAST-Tools in die Codebereitstellungspipeline unterstützen.

Wenn Sie GitHub verwenden, können die folgenden Tools und SAST-Tools von Drittanbietern in den Workflow integriert werden.

  • GitHub CodeQL für die Quellcodeanalyse
  • Microsoft BinSkim Binary Analyzer für Windows und *nix-Binäranalyse
  • GitHub integrierte Geheimnisüberprüfung für das Scannen von Anmeldeinformationen im Quellcode.
  • AWS CodeGuru Reviewer für Python- und Java-Quellcodeanalyse.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Integrieren Sie SAST (z. B. Software Delivery Shield, Artefaktanalyse) in Ihre Pipeline (z. B. in Ihrer Infrastruktur als Codevorlage), damit der Quellcode automatisch in Ihrem CI/CD-Workflow gescannt werden kann.

Dienste wie Cloud Build, Cloud Deploy, Artifact Registry unterstützen die Integration mit Software Delivery Shield und Artifact Analysis, die Quellcode und andere Artefakte im CI/CD-Workflow scannen kann.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):

DS-5: Integrieren dynamischer Anwendungssicherheitstests in DevOps-Pipeline

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Sicherheitsprinzip: Stellen Sie sicher, dass dynamische Tests der Anwendungssicherheit (DAST) Teil der Genehmigungskontrollen im CI/CD-Workflow sind. Die Zulassung kann basierend auf den Testergebnissen festgelegt werden, um zu verhindern, dass Sicherheitsrisiken in die Pakete integriert oder in der Produktion bereitgestellt werden.

Azure-Leitfaden: Integrieren Sie DAST in Ihre Pipeline, damit die Laufzeitanwendung automatisch in Ihrem CI/CD-Workflowsatz in Azure DevOps oder GitHub getestet werden kann. Die automatisierten Penetrationtests (mit manuell unterstützter Validierung) sollten ebenfalls Teil von DAST sein.

Azure DevOps Pipeline oder GitHub unterstützt die Integration von DAST-Tools von Drittanbietern in den CI/CD-Workflow.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Integrieren Sie DAST in Ihre Pipeline, damit die Laufzeitanwendung automatisch in Ihrem CI/CD-Workflowsatz in AWS CodePipeline oder GitHub getestet werden kann. Die automatisierten Penetrationtests (mit manuell unterstützter Validierung) sollten ebenfalls Teil von DAST sein.

AWS CodePipeline oder GitHub unterstützt die Integration von DAST-Tools von Drittanbietern in den CI/CD-Workflow.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Integrieren Sie DAST (z. B. Cloud Web Security Scanner) in Ihre Pipeline, damit die Laufzeitanwendung automatisch in Ihrem CI/CD-Workflow in den Diensten wie Google Cloud Build, Cloud Deploy oder GitHub getestet werden kann. Cloud Web Security Scanner kann verwendet werden, um Sicherheitsrisiken in Ihren Workload-Webanwendungen zu identifizieren, die in App Engine, Google Kubernetes Engine (GKE) und Compute Engine gehostet werden. Die automatisierten Penetrationtests (mit manuell unterstützter Validierung) sollten ebenfalls Teil von DAST sein.

Google Cloud Build, Google Cloud Deploy, Artifact Registry und GitHub unterstützen auch die Integration von DAST-Tools von Drittanbietern in den CI/CD-Workflow.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):

DS-6: Erzwingen der Sicherheit von Workloads während des DevOps-Lebenszyklus

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
7.5, 7.6, 7.7, 16.1, 16.7 CM-2, CM-6, AC-2, AC-3, AC-6 6.1, 6.2, 6.3

Sicherheitsprinzip: Sicherstellen, dass die Workload während des gesamten Lebenszyklus in der Entwicklungs-, Test- und Bereitstellungsphase gesichert ist. Verwenden Sie den Microsoft Cloud Security Benchmark, um die Steuerelemente (z. B. Netzwerksicherheit, Identitätsverwaltung, privilegierten Zugriff usw.) auszuwerten, die standardmäßig als Leitplanken festgelegt oder bereits vor der Bereitstellungsphase frühzeitiger implementiert werden können. Stellen Sie insbesondere sicher, dass die folgenden Steuerelemente in Ihrem DevOps-Prozess vorhanden sind:- Automatisieren Sie die Bereitstellung mithilfe von Azure- oder Drittanbietertools im CI/CD-Workflow, der Infrastrukturverwaltung (Infrastruktur als Code) und tests, um menschliche Fehler und Angriffsfläche zu reduzieren.

  • Stellen Sie sicher, dass VMs, Containerimages und andere Artefakte vor böswilliger Manipulation geschützt sind.
  • Überprüfen Sie die Workloadartefakte (d. h. Containerimages, Abhängigkeiten, SAST- und DAST-Scans) vor der Bereitstellung im CI/CD-Workflow.
  • Stellen Sie eine Funktion zur Sicherheitsrisikobewertung und Bedrohungserkennung in der Produktionsumgebung bereit, und setzen Sie diese Funktionen zur Laufzeit kontinuierlich ein.

Azure-Leitfaden: Leitfaden für Azure-VMs:

  • Über Azure Shared Image Gallery können Sie Ihre Images für unterschiedliche Benutzer, Dienstprinzipale oder AD-Gruppen in Ihrer Organisation freigeben und den Zugriff steuern. Verwenden Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC), um sicherzustellen, dass nur autorisierte Benutzer auf Ihre benutzerdefinierten Images zugreifen können.
  • Definieren Sie Baselines für eine sichere Konfiguration für die VMs, um unnötige Anmeldeinformationen, Berechtigungen und Pakete zu vermeiden. Bereitstellen und Erzwingen von Konfigurationsbaselines über benutzerdefinierte Images, Azure Resource Manager-Vorlagen und/oder Azure Policy-Gastkonfigurationen.

Leitfaden für Azure-Containerdienste:

  • Verwenden Sie Azure Container Registry (ACR), um Ihre private Containerregistrierung zu erstellen, in der präziser Zugriff über Azure RBAC eingeschränkt werden kann, sodass nur autorisierte Dienste und Konten auf die Container in der privaten Registrierung zugreifen können.
  • Verwenden Sie Defender für Container für die Sicherheitsrisikobewertung der Images in Ihrer privaten Azure-Containerregistrierung. Darüber hinaus können Sie Microsoft Defender für Cloud verwenden, um die Container-Image-Scans als Teil Ihrer CI/CD-Workflows zu integrieren.

Wenden Sie für Azure Serverless-Dienste ähnliche Steuerelemente an, um sicherzustellen, dass Sicherheitskontrollen in der Phase vor der Bereitstellung „nach links“ verschoben werden.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Verwenden Sie Amazon Elastic Container Registry, um den Zugriff auf Ihre Bilder von verschiedenen Benutzern und Rollen innerhalb Ihrer Organisation zu teilen und zu steuern. Und verwenden Sie AWS IAM, um sicherzustellen, dass nur autorisierte Benutzer auf Ihre benutzerdefinierten Images zugreifen können.

Definieren Sie die Basispläne für sichere Konfigurationen für die EC2 AMI-Images, um unnötige Anmeldeinformationen, Berechtigungen und Pakete zu beseitigen. Bereitstellen und Erzwingen von Konfigurationsbasislinien über benutzerdefinierte AMI-Images, CloudFormation-Vorlagen und/oder AWS-Konfigurationsregeln.

Verwenden Sie AWS Inspector für die Überprüfung der Sicherheitsrisiken der vm- und containerisierten Umgebungen, um sie vor böswilliger Manipulation zu schützen.

Verwenden Sie für AWS Serverless Services AWS CodePipeline in Verbindung mit AWS AppConfig, um ähnliche Steuerelemente zu übernehmen, um sicherzustellen, dass Sicherheitskontrollen vor der Bereitstellung in die Phase "verschoben" werden.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Google Cloud umfasst Steuerelemente zum Schutz Ihrer Computeressourcen und Der GKE-Containerressourcen (Google Kubernetes Engine). Google bietet Shielded VM, die die VM-Instanzen absichern. Sie bietet Startsicherheit, überwacht integrität und verwendet das Virtual Trusted Platform Module (vTPM).

Verwenden Sie Google Cloud Artifact Analysis, um Sicherheitsrisiken in Container- oder Betriebssystemimages sowie andere Art von Artefakten bei Bedarf oder automatisch in Ihren Pipelines zu scannen. Verwenden Sie die Container-Bedrohungserkennung, um die angeführten Container-Optimized Betriebssystem-Knoten-Images kontinuierlich zu überwachen. Der Dienst wertet alle Änderungen und Remotezugriffsversuche aus, um Laufzeitangriffe in nahezu Echtzeit zu erkennen.

Nutzen Sie Artifact Registry, um einen sicheren privaten Speicher für Build-Artefakte einzurichten, um die Kontrolle darüber zu behalten, wer mit registrierungseigenen IAM-Rollen und Berechtigungen auf die Artefakte zugreifen, ansehen oder herunterladen kann, und um konsistente Betriebszeiten auf der sicheren und zuverlässigen Infrastruktur von Google sicherzustellen.

Übernehmen Sie für serverlose GCP-Dienste ähnliche Kontrollen, um sicherzustellen, dass Sicherheitskontrollen in eine frühere Phase vor der Bereitstellung verlagert werden ('Shift-Left').

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):

DS-7: Aktivieren der Protokollierung und Überwachung in DevOps

CIS Controls v8-ID(s) ID(s) von NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.9, 8.11 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3, 10.6

Sicherheitsprinzip: Stellen Sie sicher, dass Ihr Protokollierungs- und Überwachungsumfang Nichtproduktionsumgebungen und CI/CD-Workflowelemente enthält, die in DevOps (und anderen Entwicklungsprozessen) verwendet werden. Die Sicherheitsrisiken und Bedrohungen, die auf diese Umgebungen abzielen, können erhebliche Risiken für Ihre Produktionsumgebung darstellen, wenn sie nicht ordnungsgemäß überwacht werden. Die Ereignisse aus dem CI/CD-Build-, Test- und Bereitstellungsworkflow sollten ebenfalls überwacht werden, um Abweichungen in den CI/CD-Workflowaufträgen zu identifizieren.

Azure-Leitfaden: Aktivieren und Konfigurieren der Überwachungsprotokollierungsfunktionen in Nichtproduktions- und CI/CD-Toolumgebungen (z. B. Azure DevOps und GitHub), die während des gesamten DevOps-Prozesses verwendet werden.

Die ereignisse, die aus Azure DevOps und dem GitHub CI/CD-Workflow generiert wurden, einschließlich der Build-, Test- und Bereitstellungsaufträge, sollten ebenfalls überwacht werden, um anomale Ergebnisse zu identifizieren.

Nehmen Sie die oben genannten Protokolle und Ereignisse über einen Protokollierungsstream oder eine API in Microsoft Sentinel oder andere SIEM-Tools ein, um sicherzustellen, dass die Sicherheitsvorfälle ordnungsgemäß überwacht und für die Behandlung triaged sind.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Aktivieren und Konfigurieren von AWS CloudTrail für Überwachungsprotokollierungsfunktionen in Nichtproduktions- und CI/CD-Toolumgebungen (z. B. AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar), die während des gesamten DevOps-Prozesses verwendet werden.

Die Ereignisse, die aus den AWS CI/CD-Umgebungen (z. B. AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) und dem GitHub CI/CD-Workflow generiert werden, einschließlich der Build-, Test- und Bereitstellungsaufträge, sollten ebenfalls überwacht werden, um anomale Ergebnisse zu identifizieren.

Nehmen Sie die oben genannten Protokolle und Ereignisse über einen Protokollierungsstream oder eine API in AWS CloudWatch, Microsoft Sentinel oder andere SIEM-Tools ein, um sicherzustellen, dass die Sicherheitsvorfälle ordnungsgemäß überwacht und für die Verarbeitung triaged sind.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Aktivieren und Konfigurieren der Überwachungsprotokollierungsfunktionen in Nichtproduktions- und CI/CD-Tools für Produkte wie Cloud Build, Google Cloud Deploy, Artifact Registry und GitHub, die während des gesamten DevOps-Prozesses verwendet werden können.

Die Ereignisse, die aus den GCP CI/CD-Umgebungen (z. B. Cloud Build, Google Cloud Deploy, Artifact Registry) und dem GitHub CI/CD-Workflow generiert werden, einschließlich der Build-, Test- und Bereitstellungsaufträge, sollten ebenfalls überwacht werden, um anomale Ergebnisse zu identifizieren.

Nehmen Sie die oben genannten Protokolle und Ereignisse in Microsoft Sentinel, Google Cloud Security Command Center, Chronik oder andere SIEM-Tools über einen Protokollierungsstream oder eine API ein, um sicherzustellen, dass die Sicherheitsvorfälle ordnungsgemäß überwacht und zur Behandlung analysiert werden.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (Weitere Informationen):