Das Modell der geteilten Verantwortung in der Cloud

Das Modell der geteilten Verantwortung in der Cloud ist eines der wichtigsten Konzepte im Bereich der Cloud-Sicherheit – und zugleich eines der am häufigsten missverstandenen. Das Missverständnis folgt einem bestimmten Muster: Unternehmen gehen davon aus, dass durch den Umstieg auf die Cloud mehr Sicherheitsverantwortung auf den Anbieter übergeht, als dies tatsächlich der Fall ist. Diese Annahme führt zu Sicherheitslücken, die Angreifer aktiv ausnutzen.

Gartner schätzt, dass bis 2026 99 % der Sicherheitsvorfälle in der Cloud auf das Verschulden der Kunden zurückzuführen sein werden, vor allem aufgrund von Fehlkonfigurationen. Diese Zahl ist kein Vorwurf an die Cloud-Sicherheit. Sie ist vielmehr eine Feststellung darüber, wo die Grenze der Verantwortlichkeit liegt. Die Infrastruktur des Cloud-Anbieters ist in der Regel gut gesichert. Die Fehlkonfigurationen, die ungeschützten Speicher-Buckets, die IAM-Rollen mit zu weitreichenden Berechtigungen und die nicht gepatchten VMs liegen fast ausschließlich auf der Kundenseite.

Dieser Leitfaden erläutert genau, wofür Cloud-Anbieter verantwortlich sind, wofür Kunden und deren MSPs verantwortlich sind und wie sich die Zuständigkeiten bei den verschiedenen Cloud-Dienstmodellen unterscheiden. Die Plattform von Kaseya deckt die Kundenseite des Modells der geteilten Verantwortung für mehr als 50.000 MSPs und IT-Teams weltweit ab.

Das Grundprinzip

Alle großen Cloud-Anbieter – AWS, Microsoft Azure und Google Cloud – veröffentlichen ein Modell der geteilten Verantwortung, das die Arbeitsteilung im Bereich der Sicherheit festlegt. Das Prinzip ist bei allen Anbietern einheitlich: Der Anbieter sorgt für die Sicherheit der Cloud; der Kunde sorgt für die Sicherheit der in der Cloud befindlichen Daten.

Die Verantwortlichkeiten des Anbieters umfassen die physische Infrastruktur (Rechenzentren, Server, Netzwerkhardware), die Hypervisor-Ebene, die Netzwerkstruktur sowie die Verfügbarkeit und Zuverlässigkeit der von ihm angebotenen „ managed services “. Alles, was ein Kunde innerhalb der Cloud-Umgebung bereitstellt – Betriebssysteme, Anwendungen, Daten, Identitätskonfiguration und Netzwerkzugangskontrollen –, liegt in der Verantwortung des Kunden oder seines MSP.

Die praktische Konsequenz: Eine Cloud-Umgebung ist nicht von Haus aus sicher. Sie ist nur in dem Maße sicher, wie der Kunde sie korrekt konfiguriert. Eine EC2-Instanz mit einem nicht gepatchten Betriebssystem ist das Problem des Kunden. Ein S3-Bucket mit aktiviertem öffentlichem Zugriff ist das Problem des Kunden. Eine IAM-Rolle mit Administratorrechten, die einem Dienst zugewiesen ist, der lediglich Lesezugriff benötigt, ist das Problem des Kunden. Der Cloud-Anbieter wird keines dieser Probleme erkennen oder beheben.

Wie sich die Verantwortlichkeiten je nach Dienstleistungsmodell ändern

Die genaue Abgrenzung hängt vom jeweiligen Cloud-Service-Modell ab. Je höher im Stack der Dienst angesiedelt ist, desto mehr Aufgaben übernimmt der Anbieter, und desto weniger muss der Kunde auf Infrastrukturebene selbst verwalten. Daten, Identitäten und Zugriffskontrolle bleiben jedoch in jedem Modell in der Verantwortung des Kunden.

Infrastruktur als Dienstleistung (IaaS)

Der Anbieter verwaltet die physische Infrastruktur und die Virtualisierungsebene. Der Kunde verwaltet alles darüber liegende: Betriebssystem, Middleware, Laufzeitumgebung, Anwendungen, Daten und Netzwerkkonfiguration. Dies ist das Modell für in der Cloud gehostete virtuelle Maschinen, AWS EC2, Azure-VMs und Google Compute Engine.

IaaS bringt von allen Servicemodellen die größte Verantwortung für den Kunden mit sich. Ein MSP, der die IaaS-Umgebung eines Kunden verwaltet, ist für den gesamten Sicherheitsstack oberhalb des Hypervisors verantwortlich. Dazu gehören Betriebssystem-Patches, Anwendungs-Patches, die Konfiguration von Firewall-Regeln und Sicherheitsgruppen, die Verschlüsselung von gespeicherten und übertragenen Daten, die IAM-Konfiguration sowie die Protokollierung. Nichts davon wird vom Anbieter übernommen.

Platform as a Service (PaaS)

Der Anbieter verwaltet zudem das Betriebssystem, die Middleware und die Laufzeitumgebung. Der Kunde ist für Anwendungen und Daten verantwortlich. Verwaltete Datenbankdienste wie Azure SQL Database, AWS RDS und Anwendungshosting-Plattformen basieren auf diesem Modell.

PaaS reduziert den Verwaltungsaufwand erheblich. Die Kunden müssen weder Patches für das zugrunde liegende Betriebssystem installieren noch die Datenbank-Engine verwalten. Sie sind jedoch weiterhin selbst für die Datensicherheit, die Zugriffskontrolle, die Konfiguration auf Anwendungsebene und die Sicherheit des Anwendungscodes verantwortlich.

Software as a Service (SaaS)

Der Anbieter verwaltet den gesamten Stack, von der Infrastruktur bis hin zur Anwendung. Der Kunde ist für die Daten, die Zugriffsverwaltung und die Konfiguration der Sicherheitsmaßnahmen der Anwendung verantwortlich.

Microsoft 365, Google Workspace und Salesforce sind allesamt SaaS-Lösungen. Das am weitesten verbreitete Missverständnis hierbei: Da der Anbieter die Anwendung verwaltet, gehen die Kunden davon aus, dass er auch die Daten schützt. Das ist jedoch nicht der Fall. Microsoft ist für die Verfügbarkeit und Zuverlässigkeit der Microsoft 365-Plattform verantwortlich. Die Daten innerhalb der einzelnen Mandanten sowie deren Wiederherstellbarkeit liegen in der Verantwortung des Kunden.

Ein Unternehmen, das Microsoft 365-Daten durch versehentliches Massenlöschen, einen böswilligen Administrator oder durch Ransomware, die synchronisierte OneDrive-Dateien verschlüsselt, verliert, kann sich bei der Wiederherstellung nicht auf die Aufbewahrungstools von Microsoft verlassen. Diese Tools sind auf die Einhaltung von Vorschriften ausgerichtet, haben kurze Aufbewahrungsfristen und sind nicht für die operative Wiederherstellung zu einem bestimmten Zeitpunkt ausgelegt.

Die häufigsten Lücken bei der geteilten Verantwortung

Das Prinzip zu verstehen ist eine Sache. Die Schwachstellen, die in realen Umgebungen auftreten, sind spezifisch und vorhersehbar. Diese fünf treten in fast jeder Cloud-Umgebung auf, die nicht offiziell geprüft wurde.

SaaS-Backup. Das am weitesten verbreitete Missverständnis bei allen Servicemodellen. Microsoft und Google sichern Microsoft 365- oder Google Workspace-Daten nicht so, dass eine Wiederherstellung des Betriebs nach versehentlichem Löschen, Ransomware-Angriffen oder einer Kompromittierung des Kontos möglich ist. Datto SaaS Protection geht dieses Problem direkt an und sichert Microsoft 365- und Google Workspace-Daten dreimal täglich in einem unabhängigen, unveränderlichen Datto-Cloud-Repository mit unbegrenzter Aufbewahrungsdauer und granularer Wiederherstellung.

IAM-Konfiguration. Das Identitäts- und Zugriffsmanagement – also die Frage, wer in welchen Cloud-Umgebungen über welche Berechtigungen verfügt – liegt unabhängig vom Servicemodell stets in der Verantwortung des Kunden. Fehlkonfigurationen im IAM sind die Hauptursache für Datenschutzverletzungen in der Cloud. Ein kleiner MSP, der die AWS-Umgebung eines neuen Kunden übernimmt, wird in der Regel feststellen, dass IAM-Rollen über weitaus umfassendere Berechtigungen verfügen, als es für die von ihnen abgedeckten Dienste erforderlich wäre. Die Behebung dieses Problems ist eine wenig glamouröse, zeitaufwändige Arbeit, die in fast jeder Umgebung erforderlich ist.

Patches für Betriebssysteme und Anwendungen bei IaaS-Workloads. Cloud-VMs aktualisieren sich nicht von selbst. Eine AWS-EC2-Instanz oder eine Azure-VM, auf der ein nicht gepatchtes Betriebssystem läuft, ist genauso anfällig wie ein Server vor Ort in demselben Zustand. VSA und Datto RMM erweitern das automatisierte Patch-Management auf in der Cloud gehostete Endpunkte und nutzen dabei dieselbe agentenbasierte Bereitstellung und richtliniengesteuerte Automatisierung wie bei Servern vor Ort.

Konfiguration der Netzwerksicherheit. Sicherheitsgruppen, Netzwerkzugriffskontrolllisten sowie die VPC-/VNet-Konfiguration liegen in IaaS-Umgebungen in der Verantwortung des Kunden. Bei der Überprüfung von Cloud-Umgebungen werden immer wieder Sicherheitsgruppen festgestellt, die uneingeschränkten eingehenden Zugriff auf den Ports 22 oder 3389 zulassen. Diese sind stets vorhanden, da sie zur Fehlerbehebung offen gelassen und nie geschlossen wurden. Die Behebung dieser Probleme ist unkompliziert und hat hohe Priorität.

Protokollierung und Überwachung. Cloud-Anbieter stellen Audit-Protokolle zur Verfügung – AWS CloudTrail, Azure Monitor Activity Logs, Google Cloud Audit Logs –, doch die Aktivierung der Protokollierung, deren ordnungsgemäße Speicherung und die Überwachung auf Sicherheitsereignisse liegen in der Verantwortung des Kunden. Eine Cloud-Umgebung ohne aktivierte Protokollierung ist bei der Untersuchung von Vorfällen eine Sackgasse. Kaseya SIEM erfasst neben Endpunkt- und E-Mail-Telemetriedaten auch die Protokolle der Cloud-Plattform und normalisiert Sicherheitsereignisse aller Anbieter in einer einzigen Erkennungsebene.

Was dies für die Gestaltung von MSP-Dienstleistungen bedeutet

Das Modell der geteilten Verantwortung ist nicht nur ein Sicherheitskonzept. Es ist ein Rahmenwerk für die Gestaltung von Dienstleistungen. MSPs, die ihre Dienstleistungsangebote explizit auf die von ihnen abgedeckten Verantwortungskategorien ausrichten, können ihren Kunden den Mehrwert präzise vermitteln. MSPs, die das Modell nicht verstehen, haben wahrscheinlich undokumentierte Lücken in ihrem Leistungsumfang und müssen schwierige Gespräche führen, wenn ein Vorfall diese Lücken offenbart.

Eine praktische Checkliste für die Einbindung neuer Kunden-Cloud-Umgebungen, die sich am Modell der geteilten Verantwortung orientiert:

Für IaaS-Workloads:

VSA oder den Datto RMM-Agenten auf allen Cloud-VMs bereitstellen und in bestehende Richtlinien zur Patch-Verwaltung einbinden
IAM-Rollen und Dienstkonten prüfen; übermäßige Berechtigungen dokumentieren und beheben
Überprüfen Sie die Konfigurationen der Sicherheitsgruppen und Netzwerk-ACLs; sperren Sie jeglichen uneingeschränkten Zugriff auf Verwaltungsports.
Stellen Sie sicher, dass die Audit-Protokollierung in allen Regionen aktiviert ist und die Protokolle an einen unabhängigen, überwachten Zielort weitergeleitet werden.
Überprüfen Sie, ob die Sicherung unabhängig vom Cloud-Konto konfiguriert ist, und testen Sie eine Wiederherstellung.

Für SaaS-Umgebungen:

Datto- SaaS Protection s für Microsoft 365 und Google Workspace bereitstellen
Überprüfen Sie die Berechtigungen des Administratorkontos und setzen Sie die Zwei-Faktor-Authentifizierung (MFA) für alle privilegierten Konten über „ Kaseya 365 User“ durch.
Dokumentieren Sie, welche Daten sich auf welcher SaaS-Plattform befinden und wie der Wiederherstellungspfad für jede einzelne aussieht.

Für alle Cloud-Umgebungen:

Legen Sie fest und dokumentieren Sie, welche Aufgaben der MSP im Rahmen des Dienstleistungsvertrags übernimmt.
Ermitteln Sie die für in der Cloud gehostete Daten geltenden Compliance-Anforderungen (HIPAA, PCI DSS, CMMC, CCPA) und ordnen Sie diese den bestehenden Kontrollmaßnahmen zu
Fügen Sie für den Kunden die Architektur der Cloud-Umgebung und die IAM-Struktur zu „ IT Glue “ hinzu

Der Schritt der Dokumentation ist über den rein betrieblichen Nutzen hinaus von Bedeutung. Wenn ein Kunde mit einem Cyber-Versicherungsfall oder einem Compliance-Audit konfrontiert ist, entscheidet oft die Fähigkeit des MSP, Nachweise darüber vorzulegen, welche Sicherheitsmaßnahmen zu welchem Zeitpunkt bestanden, über den Ausgang des Verfahrens.

Wie „ Kaseya 365 “ die Kundenseite abdeckt

Die Plattform „ Kaseya 365 “ bietet Tools, die alle Ebenen der Kundenverantwortung in den Bereichen IaaS, PaaS und SaaS abdecken.

VSA und Datto RMM automatisieren die Verwaltung von Betriebssystem- und Anwendungs-Patches für in der Cloud gehostete VMs sowie für lokale Endgeräte und decken so die Verantwortung für das IaaS-Patching über eine einzige Konsole ab.

Datto „ SaaS Protection “ übernimmt die Verantwortung für die SaaS-Datensicherung bei Microsoft 365 und Google Workspace und bietet dreimal täglich Backups, unbegrenzte Aufbewahrungsdauer sowie unabhängigen, unveränderlichen Speicher.

Kaseya 365 Der Benutzer ist für das Identitäts- und Zugriffsmanagement in Microsoft 365 und den damit verbundenen Cloud-Umgebungen verantwortlich, einschließlich der Durchsetzung der MFA und der Überwachung der Anmeldedaten von „ Dark Web ID “.

Kaseya SIEM übernimmt die Protokollierung und Überwachung und bündelt Audit-Protokolle der Cloud-Plattform sowie Telemetriedaten von Endgeräten und E-Mails in einer einheitlichen Sicherheitserkennungsschicht.

IT Glue umfasst die Dokumentationspflicht sowie die Speicherung der Architektur der Cloud-Umgebung, der IAM-Struktur und der Wiederherstellungs-Runbooks mit kundenweiser Isolierung und kontrolliertem Zugriff.

Kaseya Intelligence nutzt automatisierte Mustererkennung und Reaktion in verwalteten Cloud-Umgebungen, erkennt Konfigurationsabweichungen auf der Kundenseite der Grenze der geteilten Verantwortung und führt Korrekturmaßnahmen durch, ohne auf eine manuelle Überprüfung zu warten.

Entdecken Sie „ Kaseya 365 “ für Cloud- und Hybridumgebungen