Shared Responsibility Model

Eine der häufigsten und teuersten Verwechslungen in der Cloud-Praxis lautet: „Wir nutzen AWS, also kümmert sich AWS um die Sicherheit." Falsch. Cloud-Anbieter sichern ihre Infrastruktur ab – aber für das, was du dort betreibst, bist du verantwortlich. Diese Aufteilung heißt Shared Responsibility Model und ist die wichtigste konzeptionelle Grundlage für Cloud-Sicherheit, Compliance und Betrieb. Wer sie nicht versteht, baut Sicherheitslücken in jedes Cloud-Projekt ein – und wundert sich am Ende, warum die Datenpanne trotz „großem Anbieter" passieren konnte.

Die Analogie passt zu einer Mietwohnung. Der Vermieter sorgt für ein dichtes Dach, funktionierende Heizung und sichere Eingangstüre. Du als Mieter sorgst dafür, dass deine Wohnungstür abgeschlossen wird, deine Wertsachen sicher liegen, deine Gäste sich benehmen. Wenn ein Einbrecher durch deine offene Wohnungstür kommt, weil du den Schlüssel unter der Fußmatte versteckt hast – ist das nicht das Verschulden des Vermieters. So funktioniert auch Cloud: Der Anbieter sichert die Infrastruktur („Security of the Cloud"), du sicherst, was du in der Cloud betreibst („Security in the Cloud"). Wo genau die Trennlinie verläuft, hängt vom Service-Modell ab – und genau das schauen wir uns jetzt im Detail an.

1) „Security of" vs. „Security in" der Cloud

AWS hat den Spruch geprägt: „We are responsible for security of the cloud, customers are responsible for security in the cloud." Diese eine Präposition macht den Unterschied. Was zu welcher Seite gehört, hängt vom gewählten Service-Modell ab:

Verantwortungsmatrix nach Service-Modell

Wichtig: Daten und Zugriffsrechte liegen IMMER beim Kunden – auch bei SaaS. Wenn jemand bei deinem Microsoft-365-Konto das Passwort errät und Mails löscht, ist das nicht Microsofts Problem. Genau deshalb sind die Multi-Faktor-Authentifizierung und Berechtigungskonzepte in der Cloud noch wichtiger als on-prem.

2) Was der Anbieter immer macht

Unabhängig vom Modell übernimmt der Cloud-Anbieter eine Reihe von Aufgaben, die du in der Cloud weder kannst noch musst. Wenn ein Server-Lüfter ausfällt, ein RAID-Verbund defekt geht oder das Rechenzentrum brennt – nicht dein Problem. Konkret sorgt der Anbieter für:

Physische Sicherheit: Rechenzentren mit Zutrittskontrolle, Videoüberwachung, mehrfache Sicherheitsstufen. Selbst AWS-Mitarbeiter haben in der Regel keinen Zugang zu den Server-Räumen.
Stromversorgung & Kühlung: Redundante Netzteile, USV-Anlagen, Diesel-Generatoren für längere Ausfälle, Klimatisierung.
Netzwerk-Backbone: Hunderte Gbit/s Anbindung an mehrere ISPs, DDoS-Schutz auf Infrastruktur-Ebene, BGP-Routing.
Hardware-Wartung: Defekte Festplatten, ausgefallene Server – wird automatisch ausgetauscht. Bei IaaS bemerkst du es nur als kurzes Failover.
Hypervisor-Sicherheit: Die Virtualisierungs-Schicht wird gepatcht und gegen VM-Escape-Angriffe gehärtet.
Compliance-Zertifikate: ISO 27001, SOC 2, BSI C5, FedRAMP – der Anbieter weist die Einhaltung durch externe Auditoren nach. Du musst diese Zertifikate dann nur „nutzen", aber nicht selbst beschaffen.

Diese Übernahme der Infrastruktur-Sicherheit ist tatsächlich einer der stärksten Cloud-Vorteile – ein durchschnittlicher Mittelständler kann mit eigenem Rechenzentrum kaum das Sicherheitsniveau erreichen, das ein Hyperscaler standardmäßig liefert.

3) Was IMMER beim Kunden bleibt

Drei Bereiche fallen auch bei SaaS – also wenn der Anbieter scheinbar „alles" macht – immer dir zu. Genau hier passieren in der Praxis die meisten Sicherheitsvorfälle:

Daten: Was hochgeladen wird, wie es klassifiziert und verschlüsselt wird – deine Verantwortung. Microsoft löscht keine Mails für dich, weil sie versehentlich vertrauliche Informationen enthalten.
Identitäten und Zugriffsrechte: Wer hat einen Account? Welche Rolle? MFA aktiviert? Das musst du konfigurieren. Eine Phishing-Mail, die einen Mitarbeiterzugang kompromittiert, ist dein Problem – nicht das des Anbieters.
Endgeräte: Der Laptop des Anwenders ist nie Sache der Cloud. Wenn das Notebook kompromittiert ist, sind die Cloud-Daten kompromittiert.

Praktisches Beispiel: 2019 wurden Daten von 100 Millionen Capital-One-Kunden gestohlen – nicht durch eine AWS-Lücke, sondern durch eine fehlkonfigurierte Web-Application-Firewall im Capital-One-Setup. AWS-Infrastruktur war einwandfrei, der Kunde hatte einen Konfigurationsfehler gemacht. So sieht ein Shared-Responsibility-Vorfall in der Praxis aus.

4) Schuld-Matcher – wer ist verantwortlich?

In der IHK-Prüfung wird gern abgefragt: Bei einem bestimmten Vorfall – wer hat versagt, Anbieter oder Kunde? Probier es selbst:

Schuld-Matcher – wer ist verantwortlich?

Frage 1 / 6

Wichtig: „Verantwortung" heißt nicht nur „Schuld zuweisen", sondern auch wer muss handeln, wenn etwas passiert. Ein Vorfall im Anbieterbereich → der Anbieter muss reagieren (per SLA). Ein Vorfall im Kundenbereich → du musst reagieren, der Anbieter hilft höchstens mit Logs. Mehr dazu in SLA in der Cloud.

5) Was der Anbieter NICHT für dich tut (auch wenn man's erwartet)

Wer in die Cloud wechselt, geht oft mit falschen Annahmen rein. Die folgenden Dinge übernimmt der Anbieter nicht, auch wenn man's erwarten könnte:

Falsche Annahme	Realität
„Meine Daten sind automatisch gebackupt"	Nein. Backups musst du in der Regel selbst konfigurieren (Snapshots, separate Backups in andere Region). Eine versehentlich gelöschte VM ist meist endgültig weg.
„Die Cloud ist gegen Ausfall geschützt"	Nein. Single-Region-Setups fallen mit der Region aus. Für echte Hochverfügbarkeit brauchst du Multi-AZ- oder Multi-Region-Architektur.
„Microsoft 365 schützt mich vor Ransomware"	Nur eingeschränkt. Versionierung hilft, aber gegen kompromittierte Accounts und Mass-Encryption brauchen die meisten Unternehmen ein zusätzliches drittes Backup (3-2-1-Regel).
„DSGVO-Compliance ist durch den Anbieter erledigt"	Nein. Der Anbieter stellt die Werkzeuge bereit (Verschlüsselung, EU-Regionen, AVV). Aber die Datenverarbeitung wird vom Kunden gesteuert, und der Kunde bleibt nach DSGVO der „Verantwortliche". Mehr in DSGVO und Cloud.
„Mein Konto kann nicht gestohlen werden"	Doch. Phishing, Password-Reuse, schwache MFA – alles weiterhin möglich. Cloud-Admin-Accounts sind besonders begehrt.

6) Konsequenzen für die Praxis

Aus dem Shared Responsibility Model folgen einige praktische Konsequenzen, die in jedem Cloud-Projekt umgesetzt werden sollten:

Eigene Sicherheitsverantwortung dokumentieren: Welcher Mitarbeiter ist für welches Konto zuständig? Wer macht Patch-Management auf den VMs? Wer überwacht die Logs? Ohne klare Zuweisung wird's niemand tun.
Identity-Management nicht vergessen: MFA für alle Admin-Accounts, Rollenkonzept nach RBAC, Least-Privilege-Prinzip.
Eigene Backups konfigurieren: Auch in der Cloud gilt die 3-2-1-Regel. Optimalerweise ist eine Kopie außerhalb des Cloud-Anbieters.
Monitoring und Logging aktivieren: CloudTrail (AWS), Activity Log (Azure), Audit Logs (GCP) – muss bewusst eingeschaltet werden. Siehe Monitoring-Konzept.
Security-Compliance-Tools nutzen: AWS Security Hub, Azure Defender, GCP Security Command Center finden Fehlkonfigurationen automatisch. Pflichtprogramm.
Mitarbeiter schulen: Phishing bleibt der häufigste Einstiegspunkt. Security Awareness gehört auch in der Cloud zur Pflicht.

7) Die rechtliche Dimension

Das Shared Responsibility Model ist nicht nur eine technische Aufteilung, sondern auch eine vertragliche. Im Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO wird festgelegt, was der Cloud-Anbieter mit personenbezogenen Daten tun darf und welche Pflichten er übernimmt. Wer den AVV nicht abschließt oder nicht prüft, was darin steht, baut auf Sand. Auch das Cloud-Computing-Compliance-Criteria-Catalogue (BSI C5) definiert für deutsche Behörden und sicherheitskritische Kunden, welche Verantwortlichkeiten klar geregelt sein müssen.

In SLAs sind die anbieterseitigen Pflichten quantifiziert – Verfügbarkeit, Reaktionszeit auf Tickets, Datenschutz-Garantien. Aber kein SLA der Welt deckt deine eigenen Fehlkonfigurationen ab. „Wir haben ja AWS gebucht" ist keine Verteidigung vor der Aufsichtsbehörde, wenn dein S3-Bucket öffentlich erreichbar war.

Zusammenfassung

Das Shared Responsibility Model regelt, wer für welche Schicht des Cloud-Stacks verantwortlich ist. Anbieter: „Security of the cloud" – Rechenzentrum, Hardware, Hypervisor, Netzwerk-Backbone, physische Sicherheit. Kunde: „Security in the cloud" – Daten, Anwendungen, Identitäten, Konfiguration. Die Trennlinie verschiebt sich nach Service-Modell: IaaS liegt viel beim Kunden (OS, Patches, Netzwerk-Config), PaaS verschiebt sich Richtung Anbieter (OS und Plattform), SaaS übergibt fast alles an den Anbieter – aber Daten und Identitäten bleiben IMMER beim Kunden. Häufigste Vorfälle entstehen aus Fehlkonfigurationen auf Kundenseite (offene S3-Buckets, fehlende MFA, ungepatchte VMs). Rechtlich wird die Aufteilung im AVV nach DSGVO und in SLAs festgehalten. Konsequenz: eigene Sicherheitsverantwortung dokumentieren, MFA überall, eigene Backups, Monitoring aktivieren, Mitarbeiter schulen.