Das Shared-Responsibility-Modell definiert die Aufteilung der Sicherheitsverantwortung zwischen Cloud-Anbieter und Kunde. Viele Cloud-Sicherheitsvorfälle entstehen durch Missverständnisse dieses Modells.
Was ist das Shared-Responsibility-Modell
Cloud-Sicherheit ist eine geteilte Verantwortung. Der Anbieter schützt die Infrastruktur der Cloud. Der Kunde schützt alles was er in der Cloud betreibt. Wo genau die Grenze liegt, hängt vom Service-Modell ab (IaaS, PaaS, SaaS). Missverständnisse an dieser Grenze sind die häufigste Ursache von Cloud-Sicherheitsvorfällen.
Wie unterscheidet sich Verantwortung bei IaaS, PaaS und SaaS
IaaS (z.B. AWS EC2): Anbieter = physisch, Netzwerk, Hypervisor. Kunde = OS-Patching, Netzwerkkonfiguration, Anwendungen, Daten, IAM. PaaS (z.B. Azure App Service): Anbieter = OS, Runtime. Kunde = Anwendungscode, Daten, Zugriffskonfiguration. SaaS (z.B. Microsoft 365): Anbieter = Anwendung, Plattform. Kunde = Datenzugriff, Konfiguration, Compliance.
Welche Verantwortung bleibt immer beim Kunden
Unveräußerliche Kundenverantwortung: Datenschutz (DSGVO), Zugriffsverwaltung (wer darf was?), Konfiguration der Cloud-Dienste, Compliance-Nachweise, Risikobewertung der Cloud-Nutzung, Datensicherung nach eigenen RPO/RTO, Schulung der Mitarbeiter, Incident-Response für eigene Daten.
Welche typischen Fehler entstehen durch das Shared-Responsibility-Missverständnis
Häufige Fehler: S3-Buckets oder Azure Blob Storage public zugänglich gelassen, keine MFA obwohl MS es anbietet, Cloud-Backups nicht konfiguriert (obwohl Service existiert), Admin-Rechte zu großzügig vergeben, keine Audit-Logs aktiviert, DSGVO-konforme Datenspeicherung nicht konfiguriert.
Wie dokumentiert man Shared Responsibility für Compliance
Für ISO 27001 und NIS2: Supplier-Security-Policy erstellen, Cloud-Anbieter in Asset-Inventar aufnehmen, Shared-Responsibility-Matrix dokumentieren (Anbieter/Kunde je Bereich), SLAs auf Sicherheitsanforderungen prüfen, regelmäßige Lieferantenbewertung durchführen, Audit-Rechte vertraglich sichern.
✓ Checkliste: Was bedeutet Shared Responsibility in der Cloud?
- Verantwortlichkeiten klar definiert
- Dokumentation vollständig und aktuell
- Risikoanalyse durchgeführt
- Maßnahmen priorisiert und umgesetzt
- Mitarbeiter geschult
- Regelmäßige Überprüfung geplant
- Management informiert und eingebunden
- Compliance-Anforderungen erfüllt
- Technische Maßnahmen implementiert
- Auditierbarkeit sichergestellt
Fazit
Das Thema Was bedeutet Shared Responsibility in der Cloud? ist für moderne Unternehmen unverzichtbar. Es schützt vor Risiken, erfüllt regulatorische Anforderungen und schafft Vertrauen bei Kunden und Partnern. APASEC unterstützt Sie dabei — von der ersten Analyse bis zur nachhaltigen Umsetzung.
APASEC unterstützt Sie bei der professionellen Umsetzung — praxisnah und auf Ihr Unternehmen zugeschnitten. Jetzt unverbindlich anfragen →
Häufige Fragen (FAQ)
Cloud-Sicherheit ist eine geteilte Verantwortung. Der Anbieter schützt die Infrastruktur der Cloud. Der Kunde schützt alles was er in der Cloud betreibt. Wo genau die Grenze liegt, hängt vom Service-Modell ab (IaaS, PaaS, SaaS). Missverständnisse an dieser Grenze sind die häufigste Ursache von Cloud-Sicherheitsvorfällen.
IaaS (z.B. AWS EC2): Anbieter = physisch, Netzwerk, Hypervisor. Kunde = OS-Patching, Netzwerkkonfiguration, Anwendungen, Daten, IAM. PaaS (z.B. Azure App Service): Anbieter = OS, Runtime. Kunde = Anwendungscode, Daten, Zugriffskonfiguration. SaaS (z.B. Microsoft 365): Anbieter = Anwendung, Plattform. Kunde = Datenzugriff, Konfiguration, Compliance.
Unveräußerliche Kundenverantwortung: Datenschutz (DSGVO), Zugriffsverwaltung (wer darf was?), Konfiguration der Cloud-Dienste, Compliance-Nachweise, Risikobewertung der Cloud-Nutzung, Datensicherung nach eigenen RPO/RTO, Schulung der Mitarbeiter, Incident-Response für eigene Daten.
Häufige Fehler: S3-Buckets oder Azure Blob Storage public zugänglich gelassen, keine MFA obwohl MS es anbietet, Cloud-Backups nicht konfiguriert (obwohl Service existiert), Admin-Rechte zu großzügig vergeben, keine Audit-Logs aktiviert, DSGVO-konforme Datenspeicherung nicht konfiguriert.
Für ISO 27001 und NIS2: Supplier-Security-Policy erstellen, Cloud-Anbieter in Asset-Inventar aufnehmen, Shared-Responsibility-Matrix dokumentieren (Anbieter/Kunde je Bereich), SLAs auf Sicherheitsanforderungen prüfen, regelmäßige Lieferantenbewertung durchführen, Audit-Rechte vertraglich sichern.