Geteilte Verantwortung für IT-Sicherheit in Cloud-Umgebungen Shared responsibility Modelle für Cloud-Dienste

Von Dr. Götz Güttich

Anbieter zum Thema

Bucht man einen Cloud-basierten Dienst, so kümmert sich der jeweilige Provider keineswegs um alle mit dem Dienst zusammenhängenden Aspekte der IT-Sicherheit. Abhängig vom verwendeten Service muss auch der Kunde aktiv werden, um zumindest gewisse Teile seiner Daten selbst zu schützen, was vielen nicht wirklich bekannt ist.

Datensicherheit in Cloud-Diensten ist keine Sache, die nur beim Dienstleister, oder nur beim Kunden liegt. Ein Modell der geteilten Verantwortung ist der einzig praktikable Weg.
Datensicherheit in Cloud-Diensten ist keine Sache, die nur beim Dienstleister, oder nur beim Kunden liegt. Ein Modell der geteilten Verantwortung ist der einzig praktikable Weg.
(Bild: Elnur - stock.adobe.com )

Dieser Beitrag nimmt das in Cloud-Umgebungen geltende Modell der “Shared Responsibility” unter die Lupe und erklärt, worauf IT-Administratoren in Unternehmen, die mit Cloud-Diensten zu tun haben, achten müssen. Wir haben darüber mit AWS, Microsoft und Barracuda Networks gesprochen.

Die Sichtweise von AWS

Constantin Gonzalez ist Principal Solutions Architect bei AWS.
Constantin Gonzalez ist Principal Solutions Architect bei AWS.
(Bild: AWS )

Um die Situation bei Amazon Web Services (AWS) unter die Lupe zu nehmen, sprachen wir mit Constantin Gonzalez, Principal Solutions Architect bei AWS. Er sagte uns zum Thema Shared Responsibility, dass das Shared-Responsibility-Modell von Anfang an so ausgestaltet worden ist, dass alle Dienste und Komponenten, die sich unter dem Einfluss des Providers befinden, auch vom Provider, in diesem Fall AWS, abgesichert werden. Die Bestandteile, die unter Kundeneinfluss stehen sind im Gegensatz dazu vom Kunden zu schützen. So liegt es beispielsweise im Verantwortungsbereich von AWS, sich um die Sicherheit der physikalischen Infrastruktur zu kümmern, also die Rechenzentren und die darin befindliche Hardware. Bucht ein Kunde nun eine Virtuelle Maschine (VM) in der AWS-Cloud, so hat AWS selbst auf diese Maschine ja keinen direkten Zugriff und der Kunde muss sich darum kümmern, das Betriebssystem zu patchen, die in der VM laufenden Applikationen abzusichern und so weiter. Die Übergabe der Sicherheitsverantwortung läuft also auf Hypervisor-Ebene ab.

Angebote für die Kunden

Inzwischen haben sich viele Kunden bei AWS gemeldet, die es vorziehen, wenn gewisse Teile der mit der IT-Security in ihren Umgebungen zusammenhängenden Tätigkeiten zusätzlich durch den Provider erledigt werden. Deswegen bietet AWS jetzt Dienste an, die automatisiert unter Kontrolle der Kunden arbeiten, wie zum Beispiel den “AWS Systems Manager”, der zum Patchen und für Wartungsarbeiten zum Einsatz kommen kann.

Technisch geschieht das dadurch, dass Kunden einen Agenten auf Betriebssystem-Ebene installieren und konfigurieren (oder ein Amazon Machine Image (AMI) verwenden, das den Agenten vorinstalliert enthält), der sich mit dem AWS Systems Manager Service Manager Service verbindet, um das Patch-Management durchzuführen. Dieses Dienstangebot steht im Einklang mit dem Shared Responsibility Model, das dadurch nicht verändert wird.

„Die Kunden sind im Betrieb dazu in der Lage, dem Patch Manager – der übrigens kostenlos zur Verfügung steht – über ihr Identity und Access Management zu erlauben, Ihre Umgebungen zu verwalten und automatisiert Patches einzuspielen“, meinte Herr Gonzalez dazu. „Das funktioniert über die Rollenverwaltung und es gibt in der Konsole des Kunden eine Rückmeldung zum Status. Das bedeutet, der Kunde gibt AWS in diesem Fall die Erlaubnis, mit seiner Umgebung zu arbeiten.“

Bei Datenbanken in der Cloud sieht das ähnlich aus: Die Kunden verwenden zwar ihre Datenbanken, haben aber keinen Zugriff auf den Datenbank-Server. Das bedeutet, dass AWS allein für die Absicherung des Servers verantwortlich ist. Die Maintenance-Windows, während denen die Sicherungsarbeiten ablaufen, legt allerdings der Kunde fest.

Die von AWS angebotenen Dienste sind für alle Kunden gleich, haben aber gerade für Großunternehmen einen besonderen Mehrwert, da diese sich dann beispielsweise nicht mehr darum kümmern müssen, tausende von VMs zu patchen. Herr Gonzalez fuhr fort: „Mit AWS Shield steht zudem ein kostenloser DDoS-Schutz zur Verfügung und AWS bietet es zudem an, Web Application Firewalls vor die Web-Präsenzen der Kunden zu schalten. Mit all den verfügbaren Sicherheitsfunktionen erreicht man ein Security-Niveau, das on-premises überhaupt nicht umsetzbar wäre.“

Weitere Informationen zu AWS: Modell der geteilten Verantwortung – Amazon Web Services (AWS) und AWS Shield – Amazon Web Services (AWS).

Die Sichtweise von Microsoft

Helge Schroda ist Business Lead für Cybersecurity bei Microsoft Deutschland.
Helge Schroda ist Business Lead für Cybersecurity bei Microsoft Deutschland.
(Bild: Microsoft Deutschland )

Um die Shared-Responsibility-Thematik aus Microsoft-Seite zu beleuchten, sprachen wir mit Helge Schroda, Business Lead für Cybersecurity bei Microsoft Deutschland. Er sagte, dass die Shared Responsibility je nach Art der Cloud-Infrastruktur beziehungsweise -Nutzung unterschiedlich aussieht.

Betreibt ein Kunde innerhalb der Azure Cloud eine VM mit einer Anwendung darauf (IaaS), so übernimmt Microsoft nur für die physische Sicherheit Verantwortung, also dafür, dass das Rechenzentrum beispielsweise vor dem Eindringen unbefugter Personen geschützt ist, dass die Netzwerksicherheit durch eine Firewall realisiert wird und dass der Host, auf dem die VM läuft, nicht kompromittiert werden kann und Ähnliches.

Im SaaS-Bereich, also bei der Nutzung von Diensten wie Microsoft Dynamics oder Office 365 kauft der Kunde nur eine Lizenz für den Dienst, die gesamte Funktionalität liegt anschließend in der Verantwortung von Microsoft. Nur die Verantwortung für die Datenhaltung liegt beim Kunden. Er muss das Compliance-and-Risk-Management für die Daten durchführen und so dafür sorgen, dass die kritischen Daten nicht einfach aus dem Dienst herauskopiert werden können und alles abgesichert ist. Microsoft erstellt aber die Backups. Weitere Informationen zu den dabei eingesetzten Hochverfügbarkeits­maßnahmen finden sich unter „Informationen zur Verhinderung von Datenverlust - Microsoft 365 Compliance | Microsoft Docs“.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

“Eine PaaS-Umgebung kann beliebig kompliziert sein. Nehmen wir als Beispiel eine SQL-on-Azure-Datenbank”, erklärte Herr Schroda während unseres Gesprächs. “Die Datenbank selbst stellt einen Dienst aus der Cloud dar. Sie wird aber in der Regel zusammen mit anderen Applikationen benutzt, die die Kunden oft selbst erstellt haben. Die Abfragen werden üblicherweise durch die Entwickler der Kunden programmiert. Microsoft erstellt in diesem Szenario als Service Backups der Datenbank selbst, das Sichern der abgefragten Daten und der Reports ist aber Sache des Kunden.”

Angebote für die Kunden

Das Modell der Shared Responsibility aus Sicht von Microsoft.
Das Modell der Shared Responsibility aus Sicht von Microsoft.
(Bild: Microsoft )

Was das Patchen der Umgebungen angeht, so stellt Microsoft den Kunden vorbereitete Patches für bekannte Vulnerabilities zur Verfügung. Das gilt für alle Betriebssysteme und auch Applikationen, die in Azure lauffähig sind, wie beispielsweise Linux. Diese Patches sollen es den Kunden erleichtern, ihre Installationen sicher zu machen. Testen und einspielen müssen sie diese Patches im IaaS- oder PaaS-Szenario letztlich selbst.

Das “Azure Security Center” gibt von zentraler Stelle aus über einen Security-Score Aufschluss über den Status der einzelnen Systeme des Kunden. Man kann es zur Überwachung von Systemen in Azure nutzen, aber auch für On-Premises-Installationen und für weitere Cloud-Umgebungen in AWS oder Google (Multi-Cloud). Mit ihm können sich die Kunden darüber informieren, auf welchen Systemen sie aktiv werden müssen. Wenn die Administratoren der Kunden es zulassen, ist es dabei auch möglich, automatische Schritte zur Absicherung der Installationen zu unternehmen.

Um die Sicherheit der Plattform zu gewährleisten, arbeiten die Produkte von Microsoft mit einem Threat-Intelligence-System. Wird ein Angriff auf ein System – zum Beispiel eines Nutzers auf eine Office-Installation – durchgeführt, so würden diverse Sensoren das erkennen und beispielsweise den Defender for Endpoint starten, um den Angriff abzuwehren. Das funktioniert mit vielen Systemen und Applikationen im IT- und OT-Bereich. So gibt es unter anderem Defender für SQL-Server, Kubernetes oder Defender for IOT.

Es gibt also ein Schutzschild um die Anwendungen und Geräte, die alle zusammenarbeiten. Als SIEM-System kommt Microsoft Sentinel zum Einsatz, was es ermöglicht, viele der Abläufe, die zum Herstellen eines hohen Sicherheitsniveaus erforderlich sind, zu automatisierten. So gibt es beispielsweise die Option, beim Erkennen bestimmter Aktivitäten auf einem Endpoint eine Applikation zu sperren. Microsoft arbeitet hierbei über die “Intelligent Security Alliance” mit mehr als 400 Partnern zusammen, mit denen auch Daten ausgetauscht werden, um die Systeme abzusichern und ganzheitliche Sicherheitsansätze zu implementieren. Weitere Informationen zu Microsofts Sicht bietet das Dokument „Shared responsibility in the cloud“.

“Alles das funktioniert nur, wenn die Systeme alle verbunden sind, miteinander sprechen und die Kraft der Cloud nutzen”, fügte Herr Schroda hinzu. “Man benötigt den Speicher und die Rechenkraft der Cloud, um solche Szenarien realisieren zu können. Für die Cyber-Sicherheit ist die Cloud heutzutage ein Muss.”

Welche Tools können die Kunden selbst administrieren?

Stefan Schachinger ist Product Manager Network Security - IoT/OT/ICS bei Barracuda Networks.
Stefan Schachinger ist Product Manager Network Security - IoT/OT/ICS bei Barracuda Networks.
(Bild: Barracuda Networks )

Zum Abschluss des Beitrags wandten wir uns der Kundenseite zu und sprachen mit Barracuda Networks, einem Anbieter von Security-Produkten für Cloud Umgebungen. Stefan Schachinger, Product Manager Network Security - IoT/OT/ICS stand uns für dieses Interview zur Verfügung. Zunächst fragten wir, welche Szenarien Kunden von Cloud-Providern typischerweise absichern müssen. Hier unterscheidet Barracuda nach den jeweiligen Diensten. Bei Infrastructure as a Service (IaaS) kümmert sich der Anbieter – wie bereits erwähnt – lediglich um die physische Sicherheit und die darunterliegende Infrastruktur, auf die Kunden ohnehin keinen Zugriff haben. Alles weitere, wie etwa Betriebssystem und Netzwerk sowie alles darüber liegt in der Verantwortung des Kunden. Das ist das traditionelle Szenario, das Herr Gonzalez und Herr Schroda bereits ausgeführt hatten. IaaS erfordert umfangreiche Sicherheitsmaßnahmen für Applikationen, Betriebssysteme, die Netzwerkinfrastruktur, umfangreiche Updates sowie Logging und Analyse – also im Wesentlichen kaum weniger, als dies im Data Center der Fall ist.

Bei Software as a Service (SaaS) nutzt der Kunde eine Applikation, um die sich auch der Betreiber kümmert. „Die Einstiegshürde liegt dementsprechend niedrig, weshalb Kunden häufig vergessen, um welche Sicherheitsmaßnahmen sie sich selbst kümmern müssen“, sagte Herr Schachinger. „Die Details findet man oft im Kleingedruckten des Vertrags mit dem Serviceanbieter. Ein gängiger Fehler liegt darin, dass Unternehmen fälschlich davon ausgehen, ihre Daten wären entsprechend redundant gespeichert beziehungsweise es wäre ein Backup vorhanden, was jedoch oft nicht der Fall ist. Deshalb sollten Verantwortliche stets genau prüfen, ob Informationen und Daten ausreichend gesichert sind und sich gegebenenfalls um eine angemessene Lösung kümmern. Diese muss nicht nur den Aspekt der hohen Verfügbarkeit, sondern auch das klassische Backup miteinschließen. Auch bei der Anbindung der Applikation an das Unternehmensnetzwerk beziehungsweise bei der Benutzer-Authentifizierung gibt es Sicherheitsfallstricke: Grundsätzlich gilt hierbei, dass Zugänge möglichst nicht öffentlich zur Verfügung stehen und immer mit Multifaktor-Authentifizierung gearbeitet werden muss.“

Möglichkeiten des Kunden, das Sicherheitsniveau zu erhöhen

Bis zu einem gewissen Grad kann man natürlich mit den Bordmitteln der Anbieter arbeiten, jedoch decken diese meist nur das eigene Angebot des Anbieters ab. Viele Unternehmen betreiben aber hybride Infrastrukturen, verwenden also sowohl IaaS als auch SaaS, zum Teil bei unterschiedlichen Anbietern, und verfügen zusätzlich auch über eine lokale Infrastruktur im Rechenzentrum. Gerade aufgrund der dynamischen Veränderungen der letzten Jahre, wie dem anhaltenden Trend zur Cloud und dem „Work from Anywhere“-Modell, muss Security ganzheitlich gedacht werden. Insellösungen sind dabei weder praktikabel noch hilfreich.

“Moderne Zero-Trust-Access-Konzepte sollen die Sicherheit möglichst nahe an den Benutzer beziehungsweise dessen Gerät bringen”, erklärte Herr Schachinger dazu. “Sie ermöglichen es damit, ein gleichartiges Sicherheitsniveau für alle Applikationen zu implementieren, egal ob diese lokal oder in der Cloud gehostet sind. Diese Zero-Trust-Access-Lösungen ermöglichen einen rollen-basierten sowie bedingungs- und kontextabhängigen Zugriff auf Unternehmensressourcen, Applikationen und Workloads von überall aus. Es findet eine kontinuierliche Überprüfung der Identität und des Vertrauensstatus von Benutzern und Geräten statt. So können überprivilegierte Zugriffe und die damit verbundenen Sicherheitsrisiken deutlich reduziert werden.”

Gefahren für die Cloud-Konfiguration

Die größte Gefahr liegt darin, dass Cloud Services oft sehr schnell und leichtfertig konfiguriert und eingerichtet werden können, und dass die Verantwortlichen dabei deshalb Fehler machen oder Sicherheitslücken übersehen. Gerade im Bereich IaaS empfiehlt sich daher, automatisiert die Konfiguration zu überwachen und Änderungen aufzuzeigen. Man muss dieses Thema für jede Cloud separat analysieren und entsprechende Maßnahmen treffen.

(ID:48402858)