Was ist das Shared Responsibility Model in Cloud Computing?
Das Shared Responsibility Model (deutsch: Modell der geteilten Verantwortung) ist ein Sicherheitskonzept, das bei Cloud-Diensten klar regelt, welche Sicherheitsaufgaben der Anbieter übernimmt und welche beim Kunden liegen. Der Cloud-Anbieter ist für die Sicherheit der Cloud verantwortlich – also für die Infrastruktur, Hardware und Rechenzentren. Ihr als Nutzer seid hingegen für die Sicherheit in der Cloud zuständig – etwa für eure Daten, Zugriffsrechte und Anwendungen.
Diese Aufteilung ist entscheidend, denn viele Sicherheitsprobleme entstehen durch Missverständnisse darüber, wer was absichern muss. Während Amazon Web Services (AWS), Microsoft Azure oder Google Cloud die technische Basis schützen, müsst ihr eure Passwörter, Verschlüsselung und Berechtigungen selbst verwalten.
Das Modell lässt sich vereinfacht so zusammenfassen: Der Anbieter kümmert sich um das Fundament und die Mauern des Hauses, ihr seid dafür verantwortlich, die Türen abzuschließen und zu entscheiden, wer Zutritt erhält.
Wie funktioniert die Verantwortungsteilung bei IaaS, PaaS und SaaS?
Das Shared Responsibility Model entstand mit dem Aufkommen von Cloud-Computing. Als Unternehmen begannen, ihre IT-Infrastruktur in die Cloud zu verlagern, wurde schnell klar, dass klassische Sicherheitsmodelle nicht mehr ausreichten. Bei eigenen Servern im Keller war klar: Die IT-Abteilung ist für alles zuständig.
In der Cloud ist das anders. Die Verantwortung teilt sich in mehrere Ebenen auf, die je nach Service-Modell variieren. Bei Infrastructure as a Service (IaaS) wie virtuellen Servern habt ihr die meiste Kontrolle und Verantwortung.
Ihr müsst das Betriebssystem aktualisieren, Sicherheitspatches einspielen und Firewalls konfigurieren. Der Cloud-Anbieter kümmert sich um die physischen Server, Netzwerke, Rechenzentren sowie die Virtualisierungsschicht und den Hypervisor. Ihr seid hingegen für die virtuellen Maschinen, Gastbetriebssysteme, Anwendungen, Daten und die dafür konfigurierten Netzwerk- und Sicherheitskontrollen verantwortlich.
Bei Platform as a Service (PaaS) übernimmt der Anbieter mehr: Betriebssystem, Middleware und Runtime-Umgebungen werden gewartet. Ihr konzentriert euch auf eure Anwendungen und Daten. Ein Beispiel ist eine Datenbank-Plattform, bei der ihr nur noch die Datenbankinhalte und Zugriffe verwaltet.
Bei Software as a Service (SaaS) wie Microsoft 365, Salesforce oder Dropbox übernimmt der Anbieter große Teile des Anwendungsstacks und der Infrastruktur. Der Kunde bleibt jedoch unter anderem für Daten, Identitäten, Zugriffsrechte und die Konfiguration des Dienstes verantwortlich. Je nach Dienst können außerdem Anwendungs- und Sicherheitskonfigurationen sowie Backup- und Governance-Entscheidungen beim Kunden liegen.
Wichtig zu verstehen: Unabhängig vom Service-Modell bleibt die Verantwortung für eure Daten immer bei euch. Das umfasst die Klassifizierung sensibler Informationen, Governance und die Kontrolle darüber, wer Zugriff hat. Verschlüsselung und Backups sind häufig geteilt: Der Anbieter stellt entsprechende Funktionen bereit und kann bestimmte Schutzmaßnahmen automatisch betreiben, während ihr diese Funktionen passend konfigurieren, aktivieren und überprüfen müsst. Auch für starke Passwörter, Zwei-Faktor-Authentifizierung und die Schulung eurer Mitarbeiter seid ihr zuständig.
Die großen Cloud-Anbieter visualisieren dieses Modell oft als Schichtenmodell. Ganz unten liegt die physische Sicherheit – Zutrittskontrollen zu Rechenzentren, Stromversorgung, Klimatisierung. Darüber kommt die Netzwerksicherheit, dann die Virtualisierungsebene. Je weiter man nach oben kommt, desto mehr Verantwortung liegt beim Kunden.
Was bedeutet das Shared Responsibility Model für eure IT-Sicherheit?
Im Alltag begegnet euch das Shared Responsibility Model ständig, auch wenn ihr es vielleicht nicht bemerkt. Nutzt ihr Google Drive oder iCloud für eure Fotos? Dann verlasst ihr euch darauf, dass Apple oder Google die Server sicher betreiben. Gleichzeitig müsst ihr aber selbst ein sicheres Passwort wählen und die Zwei-Faktor-Authentifizierung aktivieren.
Ein konkretes Beispiel: Wenn ein Hacker euer Google-Konto übernimmt, weil ihr das Passwort „123456“ verwendet habt, ist das eure Verantwortung. Google hat die Server abgesichert, aber die Wahl eines schwachen Passworts liegt in eurem Verantwortungsbereich. Fällt hingegen die zugrunde liegende Google-Infrastruktur aus oder wird kompromittiert, liegt das grundsätzlich in Googles Verantwortungsbereich – ihr bleibt jedoch für die Konfiguration eurer Dienste, eure Daten, Zugriffsrechte sowie gegebenenfalls Ausfallsicherheit, Backups und Wiederherstellungsplanung verantwortlich.
Für Unternehmen ist das Modell noch kritischer. Viele Datenpannen entstehen nicht durch Fehler der Cloud-Anbieter, sondern durch Fehlkonfigurationen der Kunden. Ein klassischer Fall: Ein Unternehmen speichert Kundendaten in einem Cloud-Speicher, lässt diesen aber versehentlich öffentlich zugänglich. Der Cloud-Anbieter hat die Werkzeuge für Zugriffsbeschränkungen bereitgestellt – die falsche Konfiguration liegt beim Kunden.
Die praktische Bedeutung liegt also darin, dass ihr nicht blind darauf vertrauen könnt, dass „alles sicher ist, weil es in der Cloud läuft“. Ihr müsst aktiv werden: Starke, einzigartige Passwörter verwenden, Mehrfaktor-Authentifizierung aktivieren, Berechtigungen regelmäßig überprüfen, Updates und Sicherheits-Patches zeitnah installieren und verstehen, welche Sicherheitseinstellungen verfügbar sind. Das Modell macht deutlich: Cloud-Sicherheit ist Teamarbeit.
Typische Fehler beim Shared Responsibility Model vermeiden
Ein weit verbreitetes Missverständnis ist, dass Cloud-Anbieter für alle Sicherheitsaspekte verantwortlich sind. Viele Nutzer denken: „Ich zahle doch für den Service, also muss sich der Anbieter um alles kümmern.“ Das stimmt nicht. Der Anbieter kann nicht wissen, welche eurer Daten sensibel sind oder wer in eurem Unternehmen Zugriff haben sollte.
Ein weiterer Irrtum: „Wenn ich SaaS nutze, muss ich mich um nichts kümmern.“ Auch bei Software-as-a-Service bleibt die Verantwortung für Benutzerverwaltung, Zugriffskontrollen und Datenklassifizierung bei euch. Nur weil Microsoft sich um die Office-365-Server kümmert, heißt das nicht, dass ihr jedem Mitarbeiter Vollzugriff auf alle Dateien geben solltet.
Verwechselt das Shared Responsibility Model auch nicht mit Compliance. Cloud-Anbieter bieten zwar oft Compliance-Zertifizierungen an (wie ISO 27001 oder DSGVO-Konformität), aber die rechtliche Verantwortung für die Einhaltung von Datenschutzgesetzen liegt letztlich bei euch als Datenverantwortlichen. Der Anbieter stellt die Werkzeuge bereit, ihr müsst sie richtig einsetzen.
Schließlich bedeutet „shared“ nicht „fifty-fifty“. Die Aufteilung ist nicht gleichmäßig, sondern hängt vom genutzten Service ab. Bei IaaS tragt ihr deutlich mehr Verantwortung als bei SaaS. Es ist keine mathematische Teilung, sondern eine logische Trennung nach Kontrollbereichen.
Best Practices für Cloud Computing und Datenschutz
Das Shared Responsibility Model entwickelt sich weiter, besonders mit neuen Cloud-Diensten wie Serverless Computing oder Container-Plattformen. Hier verschieben sich die Grenzen erneut: Bei Serverless übernimmt der Anbieter noch mehr Infrastruktur-Verantwortung, während ihr euch auf den Code konzentriert.
Verwandte Konzepte sind Zero Trust Security, das davon ausgeht, dass man niemandem automatisch vertrauen sollte, und Defense in Depth, das mehrere Sicherheitsebenen kombiniert. Beide ergänzen das Shared Responsibility Model gut. Auch Cloud Security Posture Management (CSPM)-Tools helfen dabei, eure Verantwortungsbereiche besser zu überwachen.
Alle großen Cloud-Anbieter bieten detaillierte Dokumentationen zu ihrem spezifischen Shared Responsibility Model. AWS, Microsoft Azure und Google Cloud haben eigene Visualisierungen und Best-Practice-Guides. Es lohnt sich, diese zu studieren, wenn ihr Cloud-Dienste beruflich nutzt. Die Zukunft liegt in noch klareren Definitionen und automatisierten Tools, die helfen, die eigenen Verantwortungsbereiche besser abzusichern.
