Cloud-Computing-Aktivitäten
In diesem Abschnitt geht es weiter mit der Cloud-Referenzarchitektur nach ISO/IEC 17789. Sie gliedert sich in drei logisch aufeinander aufbauende Bereiche:
Rollen
Diese Rollen beschreiben die beteiligten Parteien und ihre grundsätzlichen Verantwortlichkeiten. Sie wurden bereits unter dem Punkt „Die Hauptakteure“ erläutert.
- Cloud Service Provider (CSP)
- Cloud Service Consumer (CSC)
- Cloud Service Broker
- Cloud Service Auditor
- Cloud Service Carrier
Sub-Rollen
Innerhalb einzelner Hauptrollen, hauptsächlich beim Cloud-Service-Provider, werden zusätzliche Sub-Rollen unterschieden. Diese konkretisieren die interne organisatorische Struktur und Verantwortungsverteilung des Anbieters, ersetzen die Hauptrollen aber nicht.
- Cloud Operations Manager ist für den stabilen und sicheren Betrieb der Cloud-Services verantwortlich. Dazu zählt Monitoring, Incident Management und Verfügbarkeitssteuerung
- Cloud Service Deployment Manager steuert die Prozesse zur Bereitstellung und Einführung von Cloud-Diensten und überwacht deren technische Umsetzung anhand definierter Metriken.
- Cloud Service Manager ist für die übergeordnete Steuerung der Services verantwortlich. Er stellt sicher, dass die vereinbarten Service-Levels eingehalten werden.
- Cloud Service Business Manager verantwortet die geschäftliche Planung, Wirtschaftlichkeit und Kundenbeziehungen.
- Cloud Service Developer entwickelt, testet, wartet und verbessert Cloud-Dienste oder deren Komponenten während des gesamten Service-Lebenszyklus.
Aktivitäten und Service Capabilities
Dieser Bereich bildet die Grundlage für die bekannten Service-Modelle (SaaS, PaaS, IaaS). Bei den Service Capabilities geht es darum, welche Kontrolle und Verantwortung zwischen Provider und Kunde aufgeteilt wird. Service Capabilities definieren die Leistungsarten, die ein Provider bereitstellt.
- Application Capabilities
- Platform Capabilities
- Infrastructure Capabilities
Cloud-Computing-Aktivitäten beschreiben die konkreten Handlungen der verschiedenen Rollen, etwa die Nutzung, Überwachung, Integration oder Auditierung von Cloud-Diensten.
Das Shared Responsibility Model
Eine der grundlegendsten Veränderungen beim Übergang in die Cloud betrifft die Sicherheitsverantwortung. Das „Shared Responsibility Model“ definiert, welche Sicherheitsaspekte der Cloud-Anbieter und welche der Kunde übernimmt.
Das Grundprinzip ist eigentlich einfach: Der Anbieter sichert die Cloud-Infrastruktur (Security OF the Cloud), der Kunde seine Daten und Anwendungen in der Cloud (Security IN the Cloud). Doch die genaue Trennlinie verschiebt sich je nach Service-Modell.
Für die Cloud-Sicherheit ist ein tiefes Verständnis der Verantwortungsteilung erforderlich. Organisationen müssen genau wissen, für welche Sicherheitsaspekte sie verantwortlich sind, und entsprechende Maßnahmen ergreifen. Der Irrglaube, „Sicherheit ist Sache des Cloud-Providers”, hat bereits zu zahllosen Datenpannen geführt.
Grundsätzlich gilt: „Wer einen Service konfigurieren kann, ist für dessen Sicherheit verantwortlich.“
Infrastructure as a Service (IaaS)
Beim IaaS stellt der Cloud-Anbieter virtuelle Infrastrukturressourcen bereit: Rechenleistung in Form von virtuellen CPUs und Arbeitsspeicher, Speicher in Form von persistenten Volumes oder Objektspeicher sowie virtuelle Netzwerkkomponenten. Der Kunde erhält somit im Wesentlichen einen leeren virtuellen Rechner, über dessen Betriebssystem und Software er vollständige Kontrolle hat.
Der Provider ist für die physische Infrastruktur, die Virtualisierung und die Netzwerk-Hardware verantwortlich. Der Kunde ist für alles darüber hinaus verantwortlich: Betriebssystem, Middleware, Anwendungen, Daten, Zugriffskontrolle und Netzwerkkonfiguration. Wenn eine virtuelle Maschine in AWS oder Azure aufgrund ungepatchter Schwachstellen im Betriebssystem kompromittiert wird, liegt die Verantwortung beim Kunden.
Ebenso liegt die Netzwerkkonfiguration in der Verantwortung des Kunden. Security Groups, Firewallregeln und Netzwerksegmentierung müssen vom Kunden korrekt konfiguriert werden.
IaaS bietet maximale Flexibilität. Organisationen können nahezu jede Software betreiben, eigene Betriebssysteme wählen und spezifische Sicherheitstools installieren. Diese Kontrolle ermöglicht maßgeschneiderte Lösungen für komplexe Anforderungen.
Gleichzeitig bedeutet sie aber auch maximalen Aufwand. Der Kunde muss sich um das Patch-Management kümmern, das Security-Hardening des Betriebssystems durchführen, Monitoring implementieren und Incident-Response-Prozesse etablieren.
Überblick – Verteilung der Sicherheitsverantwortung:
- Physische Infrastruktur: CSP
- Virtualisierungsschicht: CSP
- Netzwerkebene: geteilte Verantwortung
- Betriebssystem, Anwendungen, Daten: vollständig Kunde
Zu den Aufgaben der Kundenverantwortung zählen beispielsweise:
- Betriebssystem-Patches und -Hardening
- Anwendungs-Security
- Netzwerkkonfiguration (Security Groups, Firewalls)
- Daten-Verschlüsselung
- IAM und Access Control
Platform as a Service (PaaS)
Beim PaaS-Modell übernimmt der Provider neben der Infrastruktur auch das Betriebssystem und die Laufzeitumgebung. Somit kann sich der Kunde auf seine Anwendung und deren Daten konzentrieren. Die Verantwortung für Sicherheits-Updates des Betriebssystems liegt beim Provider.
Typische PaaS-Angebote sind AWS Lambda, Azure App Service oder Google App Engine. Ein Entwickler lädt seinen eigenen Code hoch und die Plattform kümmert sich um Ausführung, Skalierung und Hochverfügbarkeit, ohne dass der Entwickler je einen Server sieht oder konfiguriert.
Der Kunde bleibt jedoch für die Sicherheit seines Anwendungscodes und seiner Daten verantwortlich. Eine SQL-Injection-Schwachstelle in der Anwendung fällt auch bei PaaS in den Verantwortungsbereich des Kunden. Ebenso liegt die Konfiguration von Zugriffsrechten, die Verwaltung von Secrets und API-Keys sowie die Implementierung sicherer Coding-Praktiken beim Kunden.
Ein wichtiger Unterschied zu IaaS ist, dass der Kunde bei PaaS oft keine eigenen Sicherheitstools auf Betriebssystemebene installieren kann.
PaaS ermöglicht eine enorme Entwicklungsgeschwindigkeit. Teams können sich auf die Geschäftslogik konzentrieren, anstatt die Infrastruktur zu verwalten. Automatische Skalierung, integrierte Monitoring-Tools und verwaltete Datenbankdienste reduzieren dabei wesentlich den operativen Aufwand.
Aus Sicherheitsperspektive ist PaaS ein zweischneidiges Schwert: Einerseits übernimmt der Provider das Patch-Management für Betriebssystem und Runtime und reduziert damit eine häufige Schwachstellenquelle. Andererseits führen die geringeren Kontrollmöglichkeiten zu weniger Transparenz, da Kunden weder die Geschwindigkeit von Security-Updates noch die konkreten Sicherheitskonfigurationen vollständig überprüfen können.
Überblick – Verteilung der Sicherheitsverantwortung:
- Physische Infrastruktur, Netzwerk, Hosts: CSP
- Middleware, Runtime, Betrieb, Patching, Verfügbarkeit: CSP
- Anwendungen, Daten und Benutzerzugriff: Kunde
Der Kunde wird dadurch von deren Betrieb und Patch-Management entlastet, bleibt jedoch für die sichere Konfiguration, die Anwendung selbst sowie die verwalteten Daten verantwortlich. Dadurch kann er sich primär auf:
- Anwendungscode und dessen Sicherheit
- Konfiguration der Plattform
- Datenklassifizierung und -verschlüsselung
- IAM-Richtlinien für Funktionszugriffe
Software as a Service (SaaS)
Der Provider SaaS verwaltet nahezu alles: Infrastruktur, Plattform und Anwendung. Dem Kunden verbleiben vor allem Verantwortlichkeiten im Bereich Zugriffskontrolle, Benutzerverwaltung und Daten-Governance. Wenn ein Mitarbeiter sein Anwendung-Passwort mit einem Phishing-Angreifer teilt, liegt die Verantwortung eindeutig beim Kunden, nicht bei SaaS-Anbieter.
Zu den Hauptaufgaben der Kunden gehört es, die Multi-Faktor-Authentifizierung zu aktivieren, sichere Passwort-Richtlinien durchzusetzen und Zugriffsrechte nach dem Least-Privilege-Prinzip zu vergeben.
Für Organisationen mit strengen Compliance-Anforderungen, wie sie beispielsweise im Gesundheitswesen, Finanzsektor oder öffentlichen Dienst bestehen, ist die Verwendung von SaaS rechtlich besonders problematisch. Datenschutzgesetze wie die DSGVO schreiben häufig vor, dass personenbezogene Daten die EU nicht verlassen dürfen. Ein SaaS-Provider, dessen Rechenzentren sich in den USA befinden, kann diese Anforderung eher nicht erfüllen.
Bei SaaS ist nahezu die gesamte Infrastruktur, Plattform und Anwendung vom Anbieter verwaltet. Dem Kunden verbleiben:
- User Access Management
- Datenklassifizierung
- Konfiguration der Anwendung (wer darf was sehen/teilen).
- Compliance mit Datenschutzgesetzen.
Missverständnisse bezüglich dieser Verantwortungsteilung sind eine häufige Ursache von Sicherheitsvorfällen. Die Kunden gehen davon aus, dass der Provider ihre Daten vollständig schützt, übersehen dabei aber, dass die Zugriffskontrolle und Konfiguration in ihrer Verantwortung liegen.
Cloud-Deployment-Modelle
Deployment-Modelle beschreiben die organisatorische und infrastrukturelle Ausgestaltung einer Cloud-Umgebung.
Public Cloud
In der Public Cloud werden Infrastruktur und Services vom Provider öffentlich angeboten und von zahlreichen Kunden gemeinsam genutzt. Amazon Web Services, Microsoft Azure und Google Cloud Platform sind die führende Public-Cloud-Anbieter. Ein Kunde mietet sich virtuelle Ressourcen, teilt sich die physische Infrastruktur aber mit tausenden anderen Organisationen.
Das Kernprinzip der Public Cloud ist Multi-Tenancy. Verschiedene Kunden nutzen dieselben physischen Server, wobei Virtualisierung und Isolierungsmechanismen für Trennung sorgen. Diese gemeinsame Nutzung ermöglicht die Wirtschaftlichkeit der Public Cloud – Provider können durch Skaleneffekte niedrige Preise anbieten (so ist die Theorie).
Die Mehrmandantenfähigkeit ist gleichzeitig die größte Stärke und die größte Herausforderung der Public Cloud. Einerseits können Provider aufgrund der Größe ihrer Operationen in Sicherheitsmaßnahmen auf höchstem Niveau investieren, was einzelnen Organisationen nicht möglich wäre.
Andererseits entsteht ein fundamentales Vertrauensproblem. Der Kunde muss sich darauf verlassen können, dass die Isolierung zwischen den einzelnen Mandanten absolut zuverlässig funktioniert. Ein „Tenant Escape“, ist also ein Angriff, bei dem ein Mandant die Isolierung durchbricht und auf Ressourcen anderer Mandanten zugreift. In der Praxis sind solche Angriffe eher theoretischer Natur.
Ein weiteres Sicherheitsthema in der Public Cloud ist die Datenlokation. Die führenden Cloud-Provider betreiben Rechenzentren weltweit und speichern und/oder replizieren Daten prinzipiell in verschiedenen Regionen. Für Organisationen mit strengen Compliance-Anforderungen, wie beispielsweise DSGVO-Vorgaben, muss die Datenlokation kontrollierbar sein, damit die Daten die EU nicht verlassen.
Moderne Public Clouds bieten diese Kontrollmöglichkeit. Der Kunde muss diese Konfiguration jedoch korrekt vornehmen und überwachen, denn die Verantwortung dafür liegt bei ihm.
Private Cloud
Bei der Private Cloud sind Infrastruktur und Ressourcen ausschließlich für eine einzelne Organisation reserviert. Die Cloud kann im eigenen Rechenzentrum betrieben werden (On-Premises) oder bei einem Provider gehostet werden. Entscheidend ist nur, dass die Ressourcen dediziert und nicht geteilt sind.
Aus Sicherheitsperspektive ist die physische Isolation der Hauptvorteil der Private Cloud. Es gibt keine Mehrmandantenfähigkeit und keine gemeinsam genutzten physischen Ressourcen. Dadurch entfallen die Risiken von Tenant-Escape-Angriffen oder Seitenkanalangriffen über geteilte Hardware.
Dies kann für Organisationen mit höchsten Sicherheitsanforderungen, wie Regierungsbehörden, kritische Infrastrukturen oder Finanzinstitute mit sensiblen Daten ausschlaggebend sein. Auch das Thema Compliance lässt sich mit einer Private Cloud oft besser erfüllen.
Die Vorteile, die durch die Private Cloud entstehen, werden jedoch oft durch die deutlich höheren Kosten im Vergleich zur Public Cloud nivelliert. Private-Cloud-Betreiber tragen die vollen Kosten für Hardware, Stromversorgung, Kühlung und Netzwerkanbindung. Die Skaleneffekte der Public Cloud entfallen ebenfalls.
Ebenso trägt die Organisation die volle operative Verantwortung. Patch-Management, Security-Monitoring, Incident-Response – all dies muss intern aufgebaut und betrieben werden.
Hybrid Cloud
Bei der Hybrid Cloud werden Public und Private Cloud zu einer integrierten Umgebung kombiniert, um das Beste aus beiden Welten zu vereinen. Typischerweise werden sensible oder regulierte Workloads in der Private Cloud betrieben, während weniger kritische Anwendungen die Skalierbarkeit und Kosteneffizienz der Public Cloud nutzen.
Ein typisches Szenario ist, dass kritische Kernsysteme in einer Private Cloud betrieben werden, während Customer-Facing-Webanwendungen in der Public Cloud laufen. Noch verbreiteter ist die Platzierung von Backend-Lösungen in der Public Cloud.
Die Flexibilität, Workloads je nach Anforderungen zu platzieren, ist Stärke der Hybrid Cloud und ihre größte Herausforderung zugleich. Die Integration zwischen Public und Private Cloud erfordert stabile und sichere Netzwerkverbindungen, konsistentes Identity Management, einheitliche Security-Policies über beide Umgebungen hinweg. Das Thema Security-Monitoring (SIEM) wird komplexer, da die Sicherheitsereignisse über beide Umgebungen hinweg korreliert werden müssen.
Community Cloud
Bei einer Community Cloud nutzen mehrere Organisationen mit ähnlichen Compliance-Anforderungen und Sicherheitsbedürfnissen eine gemeinsame Cloud-Umgebung. Typische Beispiele sind Clouds für Behörden (Government Community Clouds), Gesundheitseinrichtungen oder Bildungseinrichtungen. Die Infrastruktur wird speziell für diese Anforderungen ausgelegt. Dabei profitieren sie von Skaleneffekten wie in der Public Cloud, haben aber mehr Kontrolle und spezifische Sicherheitsfeatures.
Multi-Cloud
Der Begriff Multi-Cloud beschreibt die parallele Nutzung mehrerer Cloud-Provider. Der Haupttreiber für Multi-Cloud ist oft die Vermeidung von Vendor Lock-in – die Abhängigkeit von einem einzigen Anbieter. Betreibt eine Organisation ihre gesamte Infrastruktur nur bei einem Provider, kann sie in eine Art Geiselhaft geraten, wenn der Provider beispielsweise die Preise erhöht, die Servicebedingungen ändert oder ausfällt.
Multi-Cloud erhöht die Sicherheitskomplexität wesentlich. Jeder Cloud-Provider hat eigene Sicherheitstools, eigene APIs und eigene Konfigurationsmechanismen. Es ist anspruchsvoll, konsistente Sicherheitsmechanismen über alle Provider hinweg zu etablieren und aufrechtzuerhalten.
Identity Management wird zur Herausforderung. Benutzer sollten idealerweise mit denselben Credentials auf Ressourcen z. B. bei AWS, Azure und Google Cloud zugreifen können. Dies erfordert Federation und Single Sign-On über Providergrenzen hinweg. Nicht weniger kompliziert wird auch die Netzwerksicherheit sein.