Shared-Responsibility-Modell
Rahmenmodell zur klaren Aufteilung von Sicherheits-, Compliance- und Betriebsverantwortungen zwischen Cloud-Anbietern und Kunden.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypOrganisation
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Missverständnisse führen zu blinden Flecken bei Sicherheit.
- Unklare Verantwortung verzögert Incident Response.
- Verlass auf Provider-Kontrollen ohne Nachweis ist riskant.
- Standardvorlage für Verantwortungsmatrizen nutzen.
- Regelmäßige Audits und Evidence-Sammlungen durchführen.
- Provider-Dokumentation in Betriebsprozesse integrieren.
I/O & Ressourcen
- Service-Inventar mit Anbieterangaben
- Rechtliche und regulatorische Anforderungen
- Organisationsstruktur und Verantwortungsrollen
- Verantwortungsmatrix pro Service
- Änderungsanforderungen an Betriebshandbücher
- Vertrags- oder SLA-Ergänzungen
Beschreibung
Beschreibt die Aufteilung von Verantwortung zwischen Cloud-Anbieter und Kunde für Sicherheit, Compliance und Betrieb. Es legt fest, welche Kontrollen der Anbieter übernimmt (Infrastruktur, physische Sicherheit, Plattformdienste) und welche beim Kunden verbleiben (Daten, Zugriff, Konfigurationen). Gilt für Public Cloud, SaaS und verwaltete Dienste zur klaren Governance.
✔Vorteile
- Reduziert Unsicherheit über Zuständigkeiten.
- Verbessert Compliance- und Auditfähigkeit.
- Ermöglicht gezielte Sicherheitsinvestitionen.
✖Limitationen
- Grenzen sind nur so wirksam wie Dokumentation und Umsetzung.
- Unterschiedliche Anbieter-Modelle erschweren Standardisierung.
- Liegt falsche Annahme vor, entstehen Sicherheitslücken.
Trade-offs
Metriken
- Anzahl der klar dokumentierten Verantwortlichkeiten
Zählt Services mit schriftlich definiertem Verantwortlichkeitsmodell.
- Zeit bis zur Incident-Zuordnung
Zeit zwischen Incident-Erkennung und eindeutiger Zuständigkeitszuweisung.
- Anzahl auditfähiger Nachweise pro Kontrolle
Misst vorhandene Nachweise für Anbieter- und Kundenkontrollen.
Beispiele & Implementierungen
AWS Shared Responsibility Model (Beispiel)
AWS beschreibt klar die Trennung zwischen Infrastruktur- und Kundenverantwortung für Cloud-Services.
SaaS-Einsatz in Marketing
Marketing nutzt ein SaaS-Tool; Backup und Zugriffsmanagement bleiben kundenseitig geregelt.
Hybride Datenplattform
Ein Daten-Lake in der Cloud kombiniert Anbieter- und Kundenaufgaben für Verschlüsselung und Zugriffskontrolle.
Implementierungsschritte
Erfassen aller genutzten Cloud- und SaaS-Services und Zuordnen der Anbieter.
Erarbeiten einer Verantwortungsmatrix pro Service mit Provider- und Kundenpflichten.
Anpassen interner Runbooks, Betriebs- und Sicherheitsprozesse entsprechend der Matrix.
Vertragliche Klärung offener Punkte und regelmäßige Reviews einplanen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Alte Runbooks, die Provider-/Kunden-Grenzen nicht reflektieren.
- Manuelle Nachweise statt automatisierter Compliance-Reports.
- Fehlende zentrale Inventarisierung der verwendeten Services.
Bekannte Engpässe
Beispiele für Missbrauch
- Annahme, dass der Provider alle Backups übernimmt, ohne Vertrag.
- Kunden konfigurieren Kritische Dienste, obwohl Provider zuständig ist.
- Fehlende Dokumentation für hybride Zugriffspfade.
Typische Fallen
- Verwechslung von Infrastruktur- und Applikationsverantwortung.
- Annäherung an ein Modell ohne Prüfung provider-spezifischer Details.
- Unzureichende Kommunikation zwischen Security- und Betriebsteams.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Vertragliche Grenzen der Provider-Verantwortung
- • Technische Schnittstellen, die keine vollständige Kontrolle erlauben
- • Regulatorische Vorgaben, die Kundenpflichten festlegen