DevSecOps integriert Sicherheitsentscheidungen und Nachweise in die Softwarebereitstellung, anstatt sie als abschließende Überprüfung zu behandeln. In einer Multi-Cloud-Pipeline für Continuous Integration und Continuous Delivery (CI/CD) ist nicht die Frage entscheidend, in welcher Cloud die Anwendung ausgeführt wird. Vielmehr kommt es darauf an, welche Komponente Quellcode ändern, Build-Code ausführen, ein Artefakt veröffentlichen oder eine Deployment-API des Anbieters aufrufen kann. Diese Fähigkeiten definieren die Sicherheitsgrenze.
In diesem Kurs bilden AWS, Microsoft Azure und Google Cloud den Anbieterkontext. Jeder Anbieter verfügt über eigene Ressourcen- und Identitätsgrenzen, während eine zentrale CI-Steuerungsebene (Control Plane) Pipeline-Definitionen, Job-Planung, Genehmigungen und Ergebnisprotokolle koordiniert. In dieser Lektion wird ein abgegrenzter Workload definiert, damit spätere Kontrollmechanismen anhand konkreter Identitäten, Artefakte und Bereitstellungsziele bewertet werden können.
Eine Sicherheitsüberprüfung einer Multi-Cloud-Pipeline kann erst beginnen, wenn feststeht, welche Komponenten zum Geltungsbereich gehören; andernfalls könnte ein Runner oder eine Registry außerhalb dieses Bereichs ein Release ändern, ohne dass dies überprüft wird. Die Pipeline-Grenze umfasst die Gesamtheit der Repositories, Dienste der Steuerungsebene, Runner, Identitäten, Artefakt-Speicher und Bereitstellungsschnittstellen, die an der Umwandlung einer Änderung in ein Release beteiligt sind. Sie beginnt an dem Punkt, an dem eine Änderung im Repository das Verhalten der Pipeline beeinflussen kann, und erstreckt sich bis zu den API-Aktionen des Anbieters, durch die der Workload erstellt oder modifiziert wird. Laufzeitanfragen an die bereitgestellte Anwendung liegen außerhalb dieser Grenze, auch wenn spätere Nachweise einen Zusammenhang zwischen einem Release und dem Laufzeitverhalten herstellen können.
Die zentrale Steuerungsebene mit dem Namen ci-control befindet sich nicht automatisch innerhalb von AWS, Azure oder Google Cloud. Ihre Runner führen die Build- und Deployment-Jobs aus und authentifizieren sich anschließend separat gegenüber dem AWS-Konto dev, dem Azure-Abonnement dev und dem Google-Cloud-Projekt orders-dev. Ein Runner wird erst dann Teil der Grenze eines Anbieters, wenn er dort selbst gehostet wird. Sein Standort verändert zwar die Netzwerksichtbarkeit und die verfügbaren Identitätsmechanismen, entbindet jedoch nicht von der Notwendigkeit einer präzise eingeschränkten Autorisierung beim Anbieter.
Nun lässt sich nachvollziehen, welche Komponenten die jeweilige Anbietergrenze überschreiten.
Eine zentrale Pipeline reduziert Redundanz nur dann, wenn ihre Kontrollmechanismen konsequent angewendet werden. Eine unkontrollierte Ausbreitung von Zugangsdaten (Credential Sprawl) entsteht, wenn zahlreiche Jobs, Repositories oder Provider-Umgebungen jeweils eigene, langlebige Zugangsdaten mit weitreichenden Berechtigungen vorhalten. Ein kompromittiertes Deployment-Credential kann über die Laufzeit des ursprünglichen Jobs hinaus bestehen bleiben; zudem verhindern gemeinsam genutzte Zugangsdaten, dass Audit-Protokolle zwischen verschiedenen Pipeline-Durchläufen unterscheiden können. Kurzlebige, auf einen einzelnen Durchlauf beschränkte Zugangsdaten begrenzen sowohl die Nutzungsdauer als auch den Wirkungsbereich des Deployments.
Auch bei Scan-Kontrollen kann es zu Abweichungen kommen. Ein Schwachstellen-Scan mit einem bestimmten Fehlerschwellenwert in einem AWS-Pfad und einem abweichenden Schwellenwert in einem Azure- oder Google-Cloud-Pfad stellt keine einheitliche Sicherheitsentscheidung dar – selbst wenn in allen Pfaden derselbe Scanner zum Einsatz kommt. Die Pipeline muss das geprüfte Artefakt, das Regelwerk, das Ergebnis sowie den Ausgang der Kontrollinstanz (Gate) protokollieren. Ein erfolgreiches Job-Protokoll belegt lediglich, dass der Job innerhalb des aufgezeichneten Zeitfensters Erfolg gemeldet hat; es ist für sich genommen kein Nachweis dafür, dass alle Ressourcen beim Provider nun dem Soll-Zustand entsprechen.
Das Kopieren von Images zwischen verschiedenen Clouds fügt eine weitere Grenze hinzu. Ein zwischen Registries kopiertes Image kann ausgetauscht, unvollständig übertragen oder unter einem bereits bekannten Tag bereitgestellt (promoted) werden. Während Tags eine veränderbare Referenz darstellen, identifiziert ein Digest den spezifischen Inhalt des Images. Als bewährte Regel gilt: Jede Aktion beim Provider muss unabhängig autorisiert werden, und der Nachweis über das exakte Artefakt muss bei jeder Übergabe mitgeführt werden.
Bei der laufenden Workload handelt es sich um orders-api, einen Dienst, der auf Port 8080 lauscht. Der Quellcode der Anwendung liegt im Repository orders-api-repo, während die Infrastrukturdefinitionen im Repository orders-infra-repo gespeichert sind. Ein Build-Vorgang erzeugt das fiktive Container-Image orders-api:1.0; Infrastrukturänderungen werden als Terraform-Stack orders-infra ausgewertet. Durch die Trennung von Quellcode- und Infrastruktur-Repositories können nachgelagerte Kontrollmechanismen den jeweiligen Änderungstypen unterschiedliche Berechtigungen für Überprüfung, Ausführung und Deployment zuweisen.
Das Image wird in die Ziel-Registries aws-ecr/orders-api, azure-acr/ordersapi und gcp-ar/orders-api übertragen (Promotion) und anschließend mittels provider-spezifischer API-Aktionen in den jeweiligen Entwicklungsumgebungen bereitgestellt. Promotion bedeutet hier das Kopieren desselben, verifizierten Image-Digests in jede Registry, nicht das erneute Erstellen des Images aus dem Quellcode für jede Cloud. Ein erneuter Build-Vorgang würde separate Artefakte erzeugen, deren Inhalte und Nachweise voneinander abweichen könnten – selbst wenn sie dasselbe Tag orders-api:1.0 verwenden.
Wir können die Artefakt- und Infrastrukturpfade untersuchen, die durch diese Workload explizit definiert werden.