Share via

Sicherheitssteuerung: DevOps-Sicherheit

  • Artikel

Die DevOps-Sicherheit deckt die Kontrollen im Zusammenhang mit der Sicherheitsentwicklung und den Vorgängen in DevOps-Prozessen ab, einschließlich der 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: Führen Sie eine Bedrohungsmodellierung durch, um die potenziellen Bedrohungen zu identifizieren und die Kontrollmechanismen aufzulisten. 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 Bedrohungsmodellierungstools wie das Microsoft Threat Modeling-Tool mit der eingebetteten Azure-Bedrohungsmodellvorlage, um Ihren Prozess zur Bedrohungsmodellierung zu steuern. 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 die Verwendung eines Bedrohungsmodellierungstools 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 Bedrohungsmodellierungstools 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 die Verwendung eines Bedrohungsmodellierungstools 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 Bedrohungsmodellierungstools wie das Microsoft Threat Modeling-Tool mit der eingebetteten Azure-Bedrohungsmodellvorlage, um Ihren Prozess zur Bedrohungsmodellierung zu steuern. 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 die Verwendung eines Bedrohungsmodellierungstools 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 -Prozess Ihres Unternehmens eine Reihe von Sicherheitskontrollen enthält, um die internen und drittanbieterbasierten Softwarekomponenten (einschließlich proprietärer und Open-Source-Software) zu steuern, in denen Ihre Anwendungen abhängigkeiten sind. Definieren Sie Durchlasskriterien, um zu verhindern, dass anfällige oder schädliche Komponenten in die Umgebung integriert und dort bereitgestellt werden.

Die Sicherheitskontrollen der Softwarelieferkette sollten mindestens die folgenden Aspekte umfassen:

  • Ordnungsgemäß verwalten Sie eine Software Bill of Materials (SBOM), indem Sie die Upstream Abhängigkeiten identifizieren, die für die Entwicklungs-, Build-, Integrations- und Bereitstellungsphase von Dienst/Ressourcen 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 Softwarelieferkette mithilfe der folgenden Funktionen oder Tools aus GitHub Advanced Security oder dem nativen Feature von GitHub sicher:- Verwenden Sie Dependency Graph, um alle Abhängigkeiten Ihres Projekts zu überprüfen, zu inventarisieren und zu identifizieren, über Advisory Database.

  • 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 native Codeüberprüfungsfunktion von GitHub, um den Quellcode zu überprüfen, wenn Sie den Code extern beziehen.
  • Verwenden Sie Microsoft Defender für Cloud, um die Sicherheitsrisikobewertung für Ihr Containerimage in den 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 die Sicherheit der Softwarelieferkette sicher, indem Sie CodeGuru Reviewer verwenden, um den Quellcode (für Java und Python) über die CI/CD-Workflows zu überprüfen. Plattformen wie CodeCommit und CodePipeline unterstützen auch Erweiterungen von Drittanbietern, um ähnliche Steuerelemente für die Inventur, Analyse und Behebung der Softwarekomponenten von Drittanbietern und deren Sicherheitsrisiken zu implementieren.

Wenn Sie Ihren Quellcode über die GitHub-Plattform verwalten, stellen Sie die Sicherheit der Softwarelieferkette über die folgenden Funktionen oder Tools aus GitHub Advanced Security oder dem nativen Feature von GitHub sicher:

  • 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 native Codeüberprüfungsfunktion von GitHub, um den Quellcode zu überprüfen, wenn Sie den Code extern beziehen.
  • Verwenden Sie ggf. Microsoft Defender für Cloud, um die Sicherheitsrisikobewertung für Ihr Containerimage in den CI/CD-Workflow zu integrieren.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Verwenden Sie Software Delivery Shield, um eine End-to-End-Software-Lieferkettensicherheitsanalyse durchzuführen. Dies umfasst den Dienst Assured OSS (Open Source Software) für den Zugriff und die Integration der OSS-Pakete, die von Google überprüft und getestet wurden, sowie überprüfte Java- und Python-Pakete, die mit den sicheren Pipelines von Google erstellt werden. Diese Pakete werden regelmäßig überprüft, analysiert und auf Sicherheitsrisiken getestet. Solche Funktionen können in Google Cloud Build, Cloud Deploy, Artifact Registry und Artefaktanalyse als Teil der CI/CD-Workflows integriert werden.

Wenn Sie Ihren Quellcode über die GitHub-Plattform verwalten, stellen Sie die Sicherheit der Softwarelieferkette über die folgenden Funktionen oder Tools aus GitHub Advanced Security oder dem nativen Feature von GitHub sicher:

  • 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 native Codeüberprüfungsfunktion von GitHub, um den Quellcode zu überprüfen, wenn Sie den Code extern beziehen.
  • Verwenden Sie ggf. Microsoft Defender für Cloud, um die Sicherheitsrisikobewertung für Ihr Containerimage in den 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 Sicherheitsmethoden 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 Benchmark auf die 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, schädlichen Code einzufügen. Überprüfen Sie beispielsweise Ihre CI/CD-Pipeline, um Fehlkonfigurationen in Den Kernbereichen von Azure DevOps wie Organisation, Projekte, Benutzer, Pipelines (Build & Release), Connections und Build-Agent zu identifizieren, um Fehlkonfigurationen wie Open Access, schwache Authentifizierung, unsichere Verbindungseinrichtung usw. zu identifizieren. Verwenden Sie für GitHub ähnliche Steuerelemente, um die Organisationsberechtigungsstufen zu sichern.
  • Stellen Sie sicher, dass Ihre DevOps-Infrastruktur in allen Entwicklungsprojekten konsistent bereitgestellt wird. Verfolgen Sie die Compliance Ihrer DevOps-Infrastruktur im großen Stil, indem Sie Microsoft Defender für Cloud (z. B. Compliance Dashboard, Azure Policy, Cloud Posture Management) oder Ihre eigenen Tools zur Überwachung der Compliance 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 permanenten privilegierten Zugriff auf die menschlichen Konten wie Entwickler oder Tester, indem Sie Features wie verwaltete Azure-Identifizierungen und Just-in-Time-Zugriff verwenden.
  • Entfernen Sie Schlüssel, Anmeldeinformationen und Geheimnisse aus Code und Skripts, die in CI/CD-Workflowaufträgen verwendet werden, und behalten Sie sie in einem Schlüsselspeicher oder azure Key Vault.
  • Wenn Sie selbstgehostete Build-/Bereitstellungs-Agents ausführen, befolgen Sie die Microsoft Cloud Security Benchmark-Kontrollen, einschließlich Netzwerksicherheit, Verwaltung von Sicherheitsrisiken 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 aktivieren.

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 AWS Well-Architected Framework, um Ihre DevOps-Umgebungen in AWS zu schützen.
  • Schützen Sie Artefakte und die zugrunde liegende unterstützende Infrastruktur, um sicherzustellen, dass die CI/CD-Pipelines nicht zu Möglichkeiten werden, schädlichen Code einzufügen.
  • Stellen Sie sicher, dass Ihre DevOps-Infrastruktur in allen Entwicklungsprojekten konsistent bereitgestellt und dauerhaft bereitgestellt wird. Verfolgen Sie die Compliance Ihrer DevOps-Infrastruktur im großen Stil mithilfe von AWS Config oder Ihrer eigenen Lösung zur Überprüfung der Konformität.
  • Verwenden Sie CodeArtifact zum sicheren Speichern und Freigeben von Softwarepaketen, die für die Anwendungsentwicklung verwendet werden. 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, nativen Diensten und CI/CD-Tools in Ihrer Pipeline, um sicherzustellen, dass Änderungen an den Pipelines autorisiert werden.
  • Entfernen von Schlüsseln, Anmeldeinformationen und Geheimnissen aus Code und Skripts, die in CI/CD-Workflowaufträgen verwendet werden, und behalten Sie sie im Schlüsselspeicher oder IN AWS KMS.
  • Wenn Sie selbstgehostete Build-/Bereitstellungs-Agents ausführen, befolgen Sie die Microsoft Cloud Security Benchmark-Kontrollen, einschließlich Netzwerksicherheit, Verwaltung von Sicherheitsrisiken und Endpunktsicherheit, um Ihre Umgebung zu schützen. Verwenden Sie AWS Inspector für die Überprüfung von Sicherheitsrisiken auf Sicherheitsrisiken in EC2- oder Containerumgebung als Buildumgebung.

Hinweis: Informationen zur Verwendung von Diensten wie AWS CloudTrail, CloudWatch und Microsoft Sentinel finden Sie in den Abschnitten Protokollierung und Bedrohungserkennung, DS-7 und Haltungs- und Sicherheitsrisikoverwaltung, 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 Benchmarks auf Die 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, schädlichen Code einzufügen. Überprüfen Sie beispielsweise Ihre CI/CD-Pipeline, um Fehlkonfigurationen in Diensten wie Google Cloud Build, Cloud Deploy, Artefaktregistrierung, Connections und Build-Agent zu identifizieren, um Fehlkonfigurationen wie open access, schwache Authentifizierung, unsichere Verbindungseinrichtung usw. zu identifizieren. Verwenden Sie für GitHub ähnliche Steuerelemente, um die Organisationsberechtigungsstufen zu sichern.
  • Stellen Sie sicher, dass Ihre DevOps-Infrastruktur in allen Entwicklungsprojekten konsistent bereitgestellt wird. Verfolgen Sie die Compliance Ihrer DevOps-Infrastruktur im großen Stil, indem Sie das Google Cloud Security Command Center (z. B. Compliance-Dashboard, Organisationsrichtlinie, Aufzeichnung einzelner Bedrohungen und Identifizieren von Fehlkonfigurationen) oder Ihre eigenen Tools zur Überwachung der Compliance verwenden.
  • 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 werden.
  • Vermeiden Sie permanenten privilegierten Zugriff auf die menschlichen Konten wie Entwickler oder Tester, indem Sie Features wie von Google verwaltete Identifizierungen verwenden.
  • Entfernen Sie Schlüssel, Anmeldeinformationen und Geheimnisse 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 selbstgehostete Build-/Bereitstellungs-Agents ausführen, befolgen Sie die Microsoft Cloud Security Benchmark-Kontrollen, einschließlich Netzwerksicherheit, Verwaltung von Sicherheitsrisiken und Endpunktsicherheit, um Ihre Umgebung zu schützen.

Hinweis: In den Abschnitten Protokollierung und Bedrohungserkennung, DS-7 und Haltungs- und Sicherheitsrisikoverwaltung können Sie Dienste wie Azure Monitor und Microsoft Sentinel oder die Operations Suite von Google Cloud sowie Chronicle SIEM und SOAR 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: Stellen Sie sicher, dass statische Anwendungssicherheitstests (SAST) Fuzzytests, interaktive Tests und Tests mobiler Anwendungen Teil der Gating-Steuerelemente 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), sodass 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 gitHub Native Secret Scanning für die Überprüfung von 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 die Java-Quellcodeanalyse. AWS Codepipeline kann auch die Integration von drittanbietern 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
  • Native Geheimnisüberprüfung auf GitHub für die Überprüfung 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 Ihre 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 überprüfen können.

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 Anwendungssicherheitstests (DAST) Teil der Gating-Steuerelemente 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 getestet werden kann, der in Diensten wie Google Cloud Build, Cloud Deploy oder GitHub festgelegt ist. 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: Stellen Sie sicher, dass die Workload während des gesamten Lebenszyklus in der Entwicklungs-, Test- und Bereitstellungsphase gesichert ist. Verwenden Sie microsoft Cloud Security Benchmark, um die Steuerelemente (z. B. Netzwerksicherheit, Identitätsverwaltung, privilegierter Zugriff usw.) auszuwerten, die standardmäßig als Schutzplanken festgelegt oder vor der Bereitstellungsphase nach links verschoben werden können. Stellen Sie insbesondere sicher, dass in Ihrem DevOps-Prozess die folgenden Kontrollen vorhanden sind: Automatisieren der Bereitstellung mithilfe von Azure- oder Drittanbietertools im CI/CD-Workflow, Infrastrukturverwaltung (Infrastructure-as-Code) und Tests, um menschliche Fehler zu reduzieren und die Angriffsfläche zu verringern.

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

Leitfaden für Azure-Containerdienste:

  • Verwenden Sie Azure Container Registry (ACR), um Ihre private Containerregistrierung zu erstellen, bei der der differenzierte 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 Ihrem privaten Azure Container Registry. Darüber hinaus können Sie Microsoft Defender for Cloud verwenden, um die Containerimagescans als Teil Ihrer CI/CD-Workflows zu integrieren.

Verwenden Sie für serverlose Azure-Dienste ähnliche Kontrollen, um sicherzustellen, dass Sicherheitskontrollen 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 Images von verschiedenen Benutzern und Rollen innerhalb Ihrer organization 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 sicheren Konfigurationsbaselines für die EC2-AMI-Images, um unnötige Anmeldeinformationen, Berechtigungen und Pakete zu vermeiden. Bereitstellen und Erzwingen von Konfigurationsbaselines über benutzerdefinierte AMI-Images, CloudFormation-Vorlagen und/oder AWS-Konfigurationsregeln.

Verwenden Sie AWS Inspector für die Überprüfung von VMs und Containerumgebungen auf Sicherheitsrisiken, um sie vor böswilliger Manipulation zu schützen.

Verwenden Sie für serverlose AWS-Dienste AWS CodePipeline in Verbindung mit AWS AppConfig, um ähnliche Kontrollen einzuführen, um sicherzustellen, dass Sicherheitskontrollen vor der Bereitstellung nach links verschoben werden.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Google Cloud enthält Steuerelemente zum Schutz Ihrer Computeressourcen und GKE-Containerressourcen (Google Kubernetes Engine). Google schließt abgeschirmte VM ein, wodurch die VM-Instanzen gehärtet werden. Es bietet Startsicherheit, überwacht die Integrität und verwendet das Virtual Trusted Platform Module (vTPM).

Verwenden Sie die Google Cloud Artifact Analysis, um Sicherheitsrisiken in Container- oder Betriebssystemimages und andere Art von Artefakten bei Bedarf oder automatisch in Ihren Pipelines zu überprüfen. Verwenden Sie container threat detection, um die angegebenen Container-Optimized Betriebssystemknotenimages kontinuierlich zu überwachen. Der Dienst wertet alle Änderungen und Remotezugriffsversuche aus, um Laufzeitangriffe nahezu in Echtzeit zu erkennen.

Verwenden Sie die Artefaktregistrierung, um einen sicheren Privaten Buildartefaktspeicher einzurichten, um die Kontrolle darüber zu behalten, wer mit registrierungsnativen IAM-Rollen und Berechtigungen auf Artefakte zugreifen, diese anzeigen oder herunterladen kann, und um eine konsistente Betriebszeit für die sichere und zuverlässige Infrastruktur von Google zu erhalten.

Verwenden Sie für serverlose GCP-Dienste ähnliche Kontrollen, um sicherzustellen, dass Sicherheitskontrollen vor der Bereitstellung nach links verschoben werden.

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 Überwachungsbereich Nicht-Produktionsumgebungen und CI/CD-Workflowelemente umfasst, 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 Sie die Überwachungsprotokollierungsfunktionen in Nicht-Produktions- und CI/CD-Toolumgebungen (z. B. Azure DevOps und GitHub), die im gesamten DevOps-Prozess verwendet werden.

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

Erfassen Sie die oben genannten Protokolle und Ereignisse in Microsoft Sentinel oder anderen SIEM-Tools über einen Protokollierungsstream oder eine API, um sicherzustellen, dass die Sicherheitsvorfälle ordnungsgemäß überwacht und für die Behandlung analysiert werden.

Azure-Implementierung und zusätzlicher Kontext:

AWS-Leitfaden: Aktivieren und konfigurieren Sie 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.

Erfassen Sie die oben genannten Protokolle und Ereignisse in AWS CloudWatch, Microsoft Sentinel oder anderen SIEM-Tools über einen Protokollierungsstream oder eine API, um sicherzustellen, dass die Sicherheitsvorfälle ordnungsgemäß überwacht und für die Behandlung analysiert werden.

AWS-Implementierung und zusätzlicher Kontext:

GCP-Leitfaden: Aktivieren und konfigurieren Sie die Überwachungsprotokollierungsfunktionen in Nicht-Produktions- und CI/CD-Toolumgebungen 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.

Erfassen Sie die oben genannten Protokolle und Ereignisse in Microsoft Sentinel, Google Cloud Security Command Center, Chronicle oder anderen SIEM-Tools über einen Protokollierungsstream oder eine API, um sicherzustellen, dass die Sicherheitsvorfälle ordnungsgemäß überwacht und für die Behandlung analysiert werden.

GCP-Implementierung und zusätzlicher Kontext:

Kundensicherheitsbeteiligte (weitere Informationen):