Wer in die Cloud deployt, verlagert Betrieb, aber nicht automatisch Verantwortung. AWS, Microsoft Azure und Google Cloud beschreiben in ihrer öffentlichen Dokumentation dasselbe Grundprinzip, das Shared Responsibility Model: Sicherheitsaufgaben sind zwischen Anbieter und Nutzer aufgeteilt. Wo genau die Grenze verläuft, hängt vom genutzten Dienst ab. Für alle, die eine Deployment-Pipeline betreiben, ist das keine Formalie, denn eine Pipeline besteht zu großen Teilen aus Identitäten, Zugriffsrechten und Konfiguration.
Zwei frühere Beiträge behandeln Cloud-Kosten und die Sicherheitsfolgen des Sparens: Cloud-Kosten senken und Cloud-Kosten und Sicherheit. Hier geht es nicht um Geld, sondern um die Zuständigkeitsfrage: Wer ist für welche Kontrolle verantwortlich?
Shared Responsibility Model: Sicherheit „of“ und „in“ der Cloud
AWS formuliert die Trennung als „Security of the Cloud“ versus „Security in the Cloud“. Für den ersten Teil ist AWS zuständig: Der Anbieter schützt die Infrastruktur, auf der alle Dienste laufen, also Hardware, Software, Netzwerk und Rechenzentren. Für den zweiten Teil gilt laut AWS: Die Verantwortung des Nutzers richtet sich nach den ausgewählten Cloud-Diensten.
Das ist der eigentliche Kern: Es gibt keine feste Linie, sondern eine, die mit jeder Dienstentscheidung wandert.
Die Grenze verschiebt sich mit dem Servicetyp
Microsoft unterscheidet in der Dokumentation zwischen On-Premises, IaaS, PaaS und SaaS. Die Verantwortungsmatrix zeigt den Effekt an einzelnen Zeilen: Das Betriebssystem liegt bei IaaS beim Nutzer, bei PaaS und SaaS bei Microsoft. Physische Hosts, physisches Netzwerk und Rechenzentrum liegen ab IaaS bei Microsoft. Netzwerkkontrollen und Anwendungen sind bei PaaS zwischen beiden geteilt.
Google beschreibt es im selben Muster: Bei IaaS liegt der Großteil der Sicherheitsverantwortung beim Nutzer, bei PaaS teilen sich beide Seiten die Verantwortung für Kontrollen auf Anwendungsebene und für das IAM-Management, bei SaaS liegt der Großteil beim Anbieter.
Ein konkretes Beispiel liefert AWS: Bei EC2 verwaltet der Nutzer das Gastbetriebssystem einschließlich Updates und Sicherheitspatches, installierte Anwendungssoftware und die Konfiguration der bereitgestellten Firewall. Bei abstrahierten Diensten wie S3 und DynamoDB verwaltet er Daten, Klassifizierung und die Berechtigungen über IAM.
Was auf jeder Stufe beim Nutzer bleibt
Aus der Verschiebung folgt nicht, dass am Ende nichts mehr zu tun bleibt. Die drei Anbieter nennen jeweils Bereiche, die sich nicht abgeben lassen:
- Microsoft: Für alle Bereitstellungsarten gehören Daten und Identitäten dem Nutzer. Dauerhaft beim Nutzer bleiben laut Dokumentation Daten, Endgeräte, Konten und Zugriffsverwaltung. In der Matrix stehen außerdem Konfigurationen und Einstellungen bei allen vier Modellen auf der Nutzerseite.
- Google: Der Anbieter bleibt für das zugrunde liegende Netzwerk und die Infrastruktur verantwortlich, Kunden bleiben immer für ihre Zugriffsrichtlinien und ihre Daten verantwortlich.
- AWS: Als „Customer Specific“ gelten Kontrollen, die allein in der Verantwortung des Nutzers liegen, abhängig von der Anwendung, die er in AWS-Diensten betreibt.
Google ergänzt mit „Shared Fate“ ein Modell, das auf dem Shared Responsibility Model aufbaut: Die Beziehung zwischen Anbieter und Kunde soll als fortlaufende Partnerschaft zur Verbesserung der Sicherheit verstanden werden.
Was das für die Pipeline bedeutet
Die folgende Einordnung ist keine Aussage der Anbieter, sondern eine Schlussfolgerung aus ihren Kategorien. Eine Deployment-Pipeline hält Zugangsdaten zur Cloud, ändert Konfigurationen und entscheidet, welcher Stand in Produktion läuft. Das sind Identitäten, Zugriffsrichtlinien und Konfiguration. Zugriffsrichtlinien und Daten nennen alle drei Anbieter als Nutzerpflicht, Konfigurationen und Einstellungen führt Microsoft ausdrücklich in allen vier Modellen beim Nutzer, und bei Google ist das IAM-Management in PaaS zwischen beiden Seiten geteilt.
Die Konsequenz: Dass die Plattform darunter vom Anbieter abgesichert wird, sagt nichts darüber, wer den Deployment-Zugang, die Rechte des Build-Kontos und die Freigabe einer Änderung absichert. Wie sich Zugangsdaten in Workflows eingrenzen lassen, zeigt Secrets-Scoping in GitHub Actions.
Fünf Fragen, um die eigene Grenze zu ziehen
- Welche Diensttypen laufen produktiv, und welche Zeile der Anbieter-Matrix gilt jeweils?
- Welche Identitäten deployen in die Cloud, und wer hat ihre Rechte zuletzt geprüft (auch beim Ausscheiden von Personen, siehe Offboarding in GitHub)?
- Wer pflegt Betriebssystem, Basis-Images und Anwendungspakete dort, wo der Dienst das dem Nutzer überlässt?
- Welche Konfigurationsänderungen laufen durch die Pipeline, und wer gibt sie frei?
- Wo ist schriftlich festgehalten, welche Kontrolle bei welchem Team liegt (siehe CODEOWNERS in der Praxis)?
Wer diese fünf Fragen beantworten kann, hat die Verantwortungsgrenze für die eigene Umgebung gezogen, statt sie aus einem Schaubild zu übernehmen. Die Anbieter-Dokumentation ist dafür der Ausgangspunkt, sie ersetzt die Prüfung der eigenen Konfiguration nicht.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über zwei Felder: Delivery- und Nachweiskontrollen in die Pipeline einziehen (Implementation) und Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen (AI Governance). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Hinterlasse einen Kommentar