20.2 Shared Responsibility Model verständlich erklärt

Das Shared Responsibility Model gehört zu den wichtigsten Grundlagen der Cloud-Sicherheit, weil es klar definiert, welche Sicherheitsaufgaben beim Cloud-Anbieter liegen und welche weiterhin vom Kunden übernommen werden müssen. Gerade für Einsteiger ist dieses Modell entscheidend, denn viele Missverständnisse in der Cloud-Sicherheit entstehen genau an dieser Stelle: Unternehmen gehen davon aus, dass der Provider „die Sicherheit macht“, während der Anbieter nur die Sicherheit bestimmter Schichten garantiert. Die Folge sind falsch konfigurierte Dienste, ungeschützte Daten, zu breite Berechtigungen oder unzureichend gesicherte Workloads. Für CCNA, Netzwerkpraxis und Cybersecurity ist das Thema besonders relevant, weil es klassische Sicherheitsfragen wie Zugriffskontrolle, Netzsegmentierung, Patch-Management, Logging und Verschlüsselung in die Cloud-Welt übersetzt. Wer das Shared Responsibility Model versteht, erkennt schnell, dass Cloud-Sicherheit weder vollständig beim Anbieter noch vollständig beim Kunden liegt, sondern eine klar aufgeteilte gemeinsame Verantwortung ist.

Was das Shared Responsibility Model überhaupt ist

Ein Modell zur Aufteilung von Sicherheitsverantwortung

Das Shared Responsibility Model beschreibt, wie Sicherheitsaufgaben zwischen dem Cloud-Anbieter und dem Cloud-Kunden verteilt sind. Es beantwortet die zentrale Frage: Wer schützt eigentlich was? Dabei übernimmt der Anbieter bestimmte Basisaufgaben für die Cloud-Plattform, während der Kunde für die sichere Nutzung dieser Plattform verantwortlich bleibt.

• Der Anbieter schützt die zugrunde liegende Cloud-Infrastruktur.
• Der Kunde schützt seine Daten, Identitäten, Konfigurationen und Workloads.
• Je nach Cloud-Modell verschiebt sich die Grenze der Verantwortung.

Das Modell ist deshalb so wichtig, weil es falsche Erwartungen korrigiert und Verantwortlichkeiten transparent macht.

„Shared“ bedeutet nicht „unklar“

Ein häufiger Denkfehler ist, dass geteilte Verantwortung automatisch unscharf oder diffus sei. In Wirklichkeit soll das Shared Responsibility Model genau das Gegenteil leisten: Es schafft Klarheit. Der Provider ist nicht für alles zuständig, der Kunde aber auch nicht. Beide Seiten haben definierte Rollen im Sicherheitsbetrieb.

Warum das Shared Responsibility Model so wichtig ist

Viele Cloud-Sicherheitsprobleme entstehen durch falsche Annahmen

In der Praxis entstehen viele Schwachstellen in Cloud-Umgebungen nicht, weil der Anbieter unsichere Rechenzentren betreibt, sondern weil Kunden ihre eigenen Aufgaben falsch einschätzen oder vernachlässigen. Typische Beispiele sind:

• öffentliche Speicherbereiche mit sensiblen Daten
• Admin-Konten ohne MFA
• zu breite IAM-Rollen
• ungepatchte virtuelle Maschinen
• offene Managementschnittstellen

Diese Probleme zeigen, dass die Cloud nicht automatisch unsicher ist, sondern oft falsch genutzt wird. Genau hier schafft das Shared Responsibility Model Orientierung.

Das Modell ist die Grundlage jeder Cloud-Sicherheitsstrategie

Ohne klares Verständnis der Zuständigkeiten lässt sich keine saubere Sicherheitsarchitektur in der Cloud aufbauen. Wer nicht weiß, welche Schicht der Anbieter schützt und welche Aufgaben intern organisiert werden müssen, kann keine belastbaren Sicherheitsprozesse definieren.

Der Grundsatz: Security of the Cloud und Security in the Cloud

Der Anbieter schützt die Cloud selbst

Ein häufig genutztes Erklärungsprinzip lautet: Der Cloud-Anbieter ist für die Security of the Cloud verantwortlich. Gemeint ist damit der Schutz der Cloud-Infrastruktur selbst, also der physischen und grundlegenden technischen Plattform, auf der Kundenressourcen betrieben werden.

• Rechenzentren und physische Sicherheit
• Hardware, Stromversorgung und Standortschutz
• Kernnetz der Plattform
• Hypervisor- und Infrastruktur-Grundlagen

Diese Ebenen sind für Kunden normalerweise nicht direkt sichtbar oder administrierbar. Deshalb liegen sie beim Anbieter.

Der Kunde schützt seine Nutzung der Cloud

Der Kunde ist für die Security in the Cloud verantwortlich. Das betrifft alles, was innerhalb der genutzten Cloud-Ressourcen konfiguriert, gespeichert, freigegeben oder betrieben wird.

• Benutzerkonten und Rollen
• Daten und deren Zugriffssteuerung
• Betriebssysteme und Anwendungen bei IaaS
• Netzwerkregeln, Security Groups und Firewalls
• Verschlüsselung, Logging und Monitoring

Diese Aufteilung ist einer der wichtigsten Merksätze für Cloud-Sicherheit.

Warum sich die Verantwortung je nach Cloud-Modell verändert

IaaS, PaaS und SaaS unterscheiden sich deutlich

Das Shared Responsibility Model ist nicht starr. Es verschiebt sich abhängig davon, welches Cloud-Servicemodell genutzt wird. Je mehr der Anbieter technisch betreibt, desto weniger Infrastrukturverantwortung bleibt beim Kunden. Gleichzeitig bleibt der Kunde fast immer für Daten, Identitäten und Berechtigungen zuständig.

• IaaS: mehr Verantwortung beim Kunden
• PaaS: geteilte Verantwortung mit stärkerem Anbieteranteil
• SaaS: noch mehr Betriebsverantwortung beim Anbieter

Gerade Einsteiger übersehen oft, dass sich die Sicherheitsaufgaben je nach Servicemodell stark verschieben.

Je höher der Dienst abstrahiert ist, desto stärker verschiebt sich die technische Verantwortung

Bei einem virtuellen Server in der Cloud muss der Kunde meist Betriebssystem, Patches und Dienste selbst absichern. Bei einer vollständig gemanagten SaaS-Anwendung fallen diese Aufgaben weitgehend beim Anbieter an. Trotzdem bleiben Identitäten, Datenfreigaben und sichere Nutzung fast immer Kundenthema.

Shared Responsibility bei Infrastructure as a Service

Der Kunde trägt hier besonders viel Verantwortung

Bei IaaS stellt der Anbieter grundlegende Infrastruktur wie Compute, Storage und Netzfunktionen bereit. Der Kunde erhält viel Flexibilität, übernimmt dafür aber auch einen großen Teil der Sicherheitsarbeit selbst.

• Betriebssysteme patchen und härten
• Benutzer und lokale Konten absichern
• Firewalls, Security Groups und ACLs konfigurieren
• Anwendungen und Middleware pflegen
• Logging und Monitoring aktivieren

Viele klassische On-Premises-Sicherheitsaufgaben bleiben hier also bestehen, nur auf virtualisierter Infrastruktur.

Typisches Missverständnis bei IaaS

Ein Unternehmen betreibt eine virtuelle Maschine in der Cloud und geht davon aus, dass der Anbieter Betriebssystem-Updates oder Härtung automatisch übernimmt. Genau das ist in vielen IaaS-Szenarien falsch. Der Anbieter schützt den Host und die Plattform, aber nicht automatisch das Gastbetriebssystem und dessen Konfiguration.

Shared Responsibility bei Platform as a Service

Der Anbieter übernimmt mehr Plattformbetrieb

Bei PaaS stellt der Cloud-Anbieter nicht nur Infrastruktur, sondern auch Teile der Plattform bereit, etwa Datenbankdienste, Laufzeitumgebungen oder Application Services. Dadurch muss der Kunde weniger Betriebssystem- und Plattformarbeit leisten.

• der Anbieter verwaltet mehr technische Basisschichten
• der Kunde verwaltet weiter Daten, Rollen und Zugriff
• Konfiguration und sichere Nutzung bleiben Kundenthema

PaaS reduziert operativen Aufwand, aber nicht die Verantwortung für sichere Architektur und Zugriffssteuerung.

Weniger Betriebsaufwand bedeutet nicht weniger Sicherheitsdenken

Auch wenn der Anbieter Teile von Patchen, Skalierung oder Plattformpflege übernimmt, muss der Kunde weiterhin entscheiden, wer auf welche Daten zugreifen darf, welche Netzgrenzen gelten und wie Logs, Verschlüsselung und API-Sicherheit umgesetzt werden.

Shared Responsibility bei Software as a Service

Der Anbieter betreibt die Anwendung, der Kunde steuert Nutzung und Zugriff

Bei SaaS betreibt der Anbieter die Anwendung vollständig. Kunden nutzen sie meist über Browser oder APIs. Dadurch übernimmt der Anbieter sehr viel von der technischen Betriebsverantwortung. Trotzdem bleibt der Kunde für wesentliche Sicherheitsaspekte zuständig.

• Benutzerkonten und Rollen verwalten
• MFA aktivieren und durchsetzen
• Freigaben und Berechtigungen sauber setzen
• Datenklassifikation und sichere Nutzung definieren
• Audit-Logs prüfen und integrieren

Auch in SaaS-Umgebungen entstehen viele Vorfälle durch falsche Freigaben, schwache Admin-Konten oder unkontrollierte Datennutzung.

SaaS ist kein Sicherheits-Freifahrtschein

Ein häufiges Missverständnis lautet: „Der Anbieter betreibt alles, also ist Sicherheit erledigt.“ Tatsächlich liegt gerade bei SaaS ein großer Teil der Sicherheitsqualität in der richtigen Nutzung durch den Kunden. Ein falsch konfiguriertes Berechtigungsmodell in einer SaaS-Plattform bleibt ein Kundenproblem, auch wenn die Anwendung technisch stabil betrieben wird.

Welche Aufgaben fast immer beim Kunden bleiben

Identitäts- und Zugriffsmanagement

Unabhängig vom Servicemodell bleibt IAM nahezu immer eine Kernverantwortung des Kunden. Wer Zugriffsrechte vergibt, Admin-Konten absichert oder MFA verpflichtend macht, ist typischerweise nicht der Anbieter, sondern das nutzende Unternehmen selbst.

• Rollen und Gruppen definieren
• Least Privilege durchsetzen
• Admin-Zugänge besonders schützen
• MFA aktivieren
• Offboarding sauber umsetzen

Datenklassifikation und Datenschutz

Der Kunde entscheidet, welche Daten in der Cloud gespeichert werden, wie sensibel sie sind und welche Schutzstufe sie brauchen. Der Anbieter speichert und verarbeitet zwar technisch, aber die Verantwortung für korrekte Einordnung, Freigabe und Governance bleibt meist beim Kunden.

Konfiguration und sichere Nutzung

Security Groups, öffentliche Endpunkte, Storage-Freigaben, Netzsegmente, Protokolle, API-Zugriffe und Logging-Optionen werden oft vom Kunden konfiguriert. Genau hier entstehen viele reale Sicherheitsprobleme.

Welche Aufgaben typischerweise beim Anbieter liegen

Physische Sicherheit und Infrastrukturgrundlagen

Der Cloud-Anbieter schützt Rechenzentren, Stromversorgung, Kühlsysteme, physische Hardware und die darunterliegende Kerninfrastruktur. Kunden können diese Schichten in der Regel weder administrieren noch direkt absichern.

• Zutrittskontrolle im Rechenzentrum
• physischer Schutz von Serverhardware
• Basis-Netzwerk der Plattform
• Hypervisor- oder Plattform-Grundschicht

Verfügbarkeit der Kernplattform

Auch grundlegende Verfügbarkeit und Stabilität des Plattformbetriebs liegen typischerweise beim Anbieter. Das entbindet Kunden aber nicht davon, eigene Hochverfügbarkeit, Redundanz und Backup-Konzepte für ihre genutzten Dienste zu planen.

Typische Missverständnisse rund um das Shared Responsibility Model

„Der Anbieter patcht alles“

Das ist nur teilweise richtig. Bei IaaS bleibt Patch-Management für Gastbetriebssysteme und Anwendungen oft beim Kunden. Bei PaaS und SaaS übernimmt der Anbieter mehr, aber nicht zwangsläufig alles, was für sichere Nutzung relevant ist.

„Wenn Daten in der Cloud liegen, sind sie automatisch geschützt“

Auch das ist falsch. Der Anbieter stellt oft Mechanismen wie Verschlüsselung, Logging oder Identity-Integration bereit. Ob diese Funktionen sinnvoll aktiviert, konfiguriert und genutzt werden, bleibt häufig Kundenthema.

„Wenn es einen Sicherheitsvorfall gibt, ist der Anbieter schuld“

Viele Vorfälle entstehen durch falsch konfigurierte Rollen, öffentliche Speicherfreigaben oder schwach geschützte Admin-Konten. In solchen Fällen liegt die Ursache typischerweise in der Kundenkonfiguration und nicht in der Plattform selbst.

Shared Responsibility und Identitätssicherheit

IAM ist oft der wichtigste Kundenanteil im Modell

Da Cloud-Ressourcen stark über Weboberflächen, APIs, Rollen und Automatisierung verwaltet werden, ist IAM eine der sensibelsten Kundenzuständigkeiten. Ein kompromittiertes Cloud-Admin-Konto kann enorme Reichweite erzeugen.

• Admin-Konten separat führen
• MFA für privilegierte Zugänge erzwingen
• API-Schlüssel und Tokens kontrollieren
• Rollen mit minimal nötigen Rechten definieren

Fehler in IAM untergraben die ganze Cloud-Sicherheit

Selbst wenn der Anbieter seine Plattform perfekt schützt, bleibt eine Umgebung hochgefährdet, wenn Kunden zu breite Rollen vergeben, MFA weglassen oder alte Admin-Konten nicht deaktivieren. Das Shared Responsibility Model macht genau diese Verantwortung sichtbar.

Shared Responsibility und Netzwerksicherheit

Virtuelle Netzgrenzen bleiben Kundenthema

In der Cloud übernimmt der Anbieter zwar den Betrieb der Netzwerkplattform, aber die Definition der eigenen virtuellen Netzarchitektur liegt oft beim Kunden. Dazu gehören:

• Subnets und Segmentierung
• Security Groups und Network ACLs
• öffentliche und private Endpunkte
• Regeln für Managementzugriffe

Falsch konfigurierte Netzregeln gehören deshalb zu den klassischen Beispielen für Kundenseitige Sicherheitsverantwortung.

Auch in der Cloud gilt: nur notwendige Erreichbarkeit

Ein öffentlich erreichbarer Dienst ist nicht automatisch falsch, aber er muss bewusst und minimal konfiguriert werden. Wer Security Groups zu breit öffnet oder Managementports mit Public IP versieht, verletzt das Sicherheitsprinzip der minimalen Erreichbarkeit – und das ist eindeutig Kundenthema.

Shared Responsibility und Daten

Der Anbieter speichert technisch, der Kunde steuert Schutz und Freigabe

Ein Cloud-Anbieter kann hochverfügbare Speicherplattformen betreiben, doch die Verantwortung dafür, welche Daten dort abgelegt werden und wer sie lesen darf, bleibt typischerweise beim Kunden.

• Freigaben korrekt setzen
• Verschlüsselungsoptionen sinnvoll nutzen
• Backups definieren
• Datenklassifikation berücksichtigen

Öffentliche Speicherfreigaben sind ein klassisches Beispiel

Wenn ein Unternehmen versehentlich sensible Daten in einem öffentlich erreichbaren Cloud-Speicher freigibt, liegt das Problem normalerweise nicht in der Plattformtechnik, sondern in der Kundenseitigen Konfiguration. Genau solche Fälle zeigen die praktische Bedeutung des Shared Responsibility Model besonders deutlich.

Wie Unternehmen das Modell praktisch umsetzen sollten

Verantwortlichkeiten intern klar zuordnen

Es reicht nicht, das Modell theoretisch zu kennen. Unternehmen sollten intern genau festlegen, wer welche Cloud-Sicherheitsaufgaben übernimmt. Dazu gehören meist Cloud-Administratoren, IAM-Verantwortliche, Security-Teams, Plattform-Teams und Fachbereiche.

• wer verwaltet Rollen und Berechtigungen?
• wer prüft Storage-Freigaben?
• wer überwacht Cloud-Logs?
• wer verantwortet Backup und Recovery?

Provider-Dokumentation und Sicherheitsoptionen aktiv nutzen

Cloud-Anbieter stellen meist umfangreiche Sicherheitsfunktionen bereit. Unternehmen müssen diese aber kennen, bewusst aktivieren und passend konfigurieren. Das betrifft Logging, Verschlüsselung, Security Policies, MFA, Alarmierung und Compliance-Funktionen.

Ein einfaches Praxisbeispiel

Virtuelle Maschine in der Public Cloud

Ein Unternehmen betreibt in einer Public Cloud eine virtuelle Linux-Maschine für eine interne Anwendung. Der Anbieter stellt Rechenzentrum, Host-Hardware, Virtualisierung und Grundplattform bereit. Der Kunde bleibt aber verantwortlich für:

• Patchen des Linux-Systems
• SSH-Zugriff absichern
• Security Group-Regeln korrekt setzen
• Application Logs überwachen
• Nutzer und Schlüssel verwalten

Wenn die VM veraltet ist und SSH aus dem Internet mit zu breiten Regeln erreichbar bleibt, ist das kein Fehler des Cloud-Anbieters, sondern eine Lücke in der Kundenseitigen Verantwortung.

SaaS-Beispiel mit Benutzerrechten

Ein Unternehmen nutzt eine SaaS-Kollaborationsplattform. Der Anbieter betreibt Anwendung, Backend und Infrastruktur. Der Kunde ist aber zuständig für Benutzerkonten, Admin-Rollen, MFA und Freigaben. Wird ein sensibles Dokument versehentlich für externe Personen freigegeben, liegt das Sicherheitsproblem trotz stabiler SaaS-Plattform auf Kundenseite.

Praktische CLI-Beispiele im Cloud-Kontext

Kundenseitige Sicht auf Ressourcen und Berechtigungen

Cloud-Sicherheit wird häufig über CLI-Tools und APIs verwaltet. Die genaue Syntax variiert je nach Plattform, aber typische Aufgaben zeigen gut, wie stark die Kundenseitige Verantwortung auf Konfiguration und Identität liegt.

aws iam list-users
aws ec2 describe-security-groups
aws s3 ls

az role assignment list
az vm list
az network nsg list

Diese Beispiele stehen sinnbildlich für Kundenseitige Aufgaben: Benutzer prüfen, Rollen verstehen, Netzwerkregeln kontrollieren und Ressourcen sichtbar machen. Genau das ist gelebte Verantwortung im Shared Responsibility Model.

Warum dieses Thema für Cybersecurity unverzichtbar ist

Das Modell verhindert gefährliche Fehlannahmen

Viele Cloud-Sicherheitsprobleme entstehen, weil Unternehmen nicht klar wissen, was der Anbieter schützt und was sie selbst absichern müssen. Das Shared Responsibility Model schafft hier die notwendige Realitätssicht.

• es klärt Zuständigkeiten
• es stärkt die eigene Sicherheitsverantwortung
• es macht Identitäts- und Konfigurationssicherheit sichtbar
• es hilft, Cloud-Risiken realistischer zu bewerten

Wer das Shared Responsibility Model versteht, versteht Cloud-Sicherheit deutlich besser

Am Ende ist die wichtigste Erkenntnis sehr klar: Das Shared Responsibility Model ist keine theoretische Anbieterformel, sondern das grundlegende Sicherheitsprinzip jeder Cloud-Nutzung. Wer es wirklich versteht, kann Cloud-Dienste sicherer betreiben, Fehlannahmen vermeiden und die eigene Verantwortung dort wahrnehmen, wo in der Praxis die meisten Cloud-Sicherheitsprobleme tatsächlich entstehen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.