In diesem Abschnitt geht es darum, wie Sicherheitskontrollen in Cloud-Umgebungen geplant, implementiert und überwacht werden.
Physischer und Umweltbezogener Schutz
Die physischen Schutzmaßnahmen wurden bereits in Abschnitt 3.2 behandelt. Für On-Premises-Umgebungen gelten dieselben Prinzipien, wobei die Organisation (Betreiber) selbst die volle Verantwortung trägt.
Aus Kundensicht kommt ein weiterer Punkt hinzu: der Vendor-Risk-Review, also die strukturierte Bewertung eines CSP vor Vertragsabschluss anhand von Zertifizierungen (ISO 27001, SOC 2, CSA STAR – mehr dazu im Abschnitt 6.4.), Redundanznachweisen und Business-Continuity-Fähigkeiten (Abschnitt 3.5).
System-, Speicher- und Kommunikationsschutz
Viele Themen dieses Abschnitts sind im NIST-Dokument SP 800-53, Section 3.18 „System and Communications Protection“ detailliert beschrieben. NIST SP 800-53 ist ein strukturiertes Rahmenwerk zur Bewertung, Implementierung und Überwachung von Sicherheitskontrollen. Im aktuellen Kontext sind die folgenden Themen besonders relevant:
Boundary Protection. Die Systeme müssen so konzipiert sein, dass Datenflüsse zwischen Sicherheitsdomänen kontrolliert und überwacht werden. Dazu gehören Firewalls, API-Gateways, Netzsegmentierung und auch IDS/IPS-Systeme (Intrusion Detection / Prevention), die verdächtigen Datenverkehr in Echtzeit erkennen und blockieren. In Cloud-Umgebungen werden sie oft als virtuelle Appliances oder native CSP-Dienste bereitgestellt
Cryptographic Key Establishment and Management. Die Verschlüsselung allein ist ohne intelligentes Schlüsselmanagement wertlos. Eine sicherheitskonforme Verwaltung kryptografischer Schlüssel muss den gesamten Lebenszyklus abdecken: von der sicheren Erzeugung über die geschützte Speicherung und Verteilung bis zur endgültigen Vernichtung. Ebenso behandelt das Dokument die Verschlüsselung in allen drei Datenzuständen: at rest, in transit und in use.
DoS/DDoS-Schutz – CSPs bieten integrierte Schutzmechanismen (z. B. AWS Shield, Azure DDoS Protection). Ergänzend können Kunden Lastverteilung, Traffic-Filtering und Rate-Limiting implementieren.
Separation of Functions bedeutet eine klare Trennung von Systemen, Rollen und Sicherheitsfunktionen, um den Blast Radius bei einem erfolgreichen Angriff zu reduzieren. Konkret bedeutet das: Prod / Dev / Test-Umgebungen müssen strikt getrennt werden und administrative sowie sicherheitsrelevante Aufgaben dürfen nicht in einer Person gebündelt werden. Sicherheitsdienste wie Logging oder Key Management sind von regulären Betriebsdiensten zu isolieren.
Identifizierung, Authentifizierung und Autorisierung in Cloud-Umgebungen
IAAA “Identification, Authentication, Authorization, Accountability (Accounting)” ist wahrscheinlich neben der CIA-Triade (Confidentiality, Integrity, Availability) wahrscheinlich eine der bekanntesten in der Security-Welt, da diese vier Schritte die Basis des Cloud-Sicherheitsmodells bilden.
Identification (Identifikation) – In der ersten Phase gibt der User an, wer er ist. Dies soll eine eindeutige Identifikation sein, z. B. ein Benutzername, eine E-Mail oder eine Benutzer-ID.
Authentication (Authentifizierung)– Nachdem der User seine Identität angegeben hat, muss man beweisen, dass diese Identität genau diesem User tatsächlich gehört. Dies erfolgt durch Credentials, die aus einem oder mehreren Faktoren bestehen:
- Etwas, das man weiß: Passwort, PIN
- Etwas, das man besitzt: Token, Smartcard, OTP
- Etwas, das man ist: biometrische Merkmale wie Fingerabdruck oder Gesichtserkennung
Authorization (Autorisierung) – Nach erfolgreicher Authentifizierung entscheidet das System, welche Ressourcen der Benutzer nutzen und welche Aktionen er ausführen darf, durch Zugriffsrichtlinien wie RBAC oder ABAC.
Accountability oder Accounting (Nachvollziehbarkeit) – Der letzte Schritt, ist nicht direkt mit dem Logon-Prozess des Benutzers verbunden, aber extrem sicherheitsrelevant, besonders für Benutzer mit erhöhten Rechten. Es geht um Protokollierung, Überwachung und Aufzeichnung von Benutzeraktivitäten (z. B. Audit-Log).
In der Cloud ist es schwieriger als On-Premises, zwischen legitimen und verdächtigen Aktivitäten zu unterscheiden, denn der Zugriff ist per Design von überall möglich. Ein legitimer Login aus einem unbekannten Land kann genauso aussehen wie ein Angriff.
Best Practices
MFA (Multi-Faktor-Authentifizierung) – auch wenn MFA keine 100%ige Garantie bietet, fügt es eine wichtige zusätzliche Schutzschicht hinzu. Selbst wenn ein Passwort kompromittiert wird, kann sich ein Angreifer ohne den zweiten Faktor in den meisten Fällen nicht anmelden.
Cloud Access Security Broker (CASB) – ein externer Sicherheitsdienst oder eine CSP-eigene Lösung, die als Vermittler zwischen Cloud-Nutzern und Cloud-Anwendungen agiert. Dadurch lassen sich einheitliche Sicherheitsrichtlinien über alle genutzten Cloud-Dienste hinweg durchsetzen.
Identity as a Service (IDaaS) – Identitätsdienste als Cloud-Service (z. B. Microsoft Entra ID, Okta, Ping Identity), die eine zentrale Authentifizierung über verschiedene Plattformen, Integration von On-Premises- und Multi-Cloud-Systemen sowie SSO und MFA ermöglichen.
CASB und IDaaS ermöglichen unter anderem kontextbasierte Zugriffssteuerung: Die Authentifizierungsanforderungen werden dynamisch angepasst: je nach Standort, Gerätetyp, Sicherheitsstatus oder Tageszeit. Ein typisches Beispiel: Ein Login von einem bekannten Gerät am Arbeitsplatz erfordert nur ein Passwort – aus dem Homeoffice wird zusätzlich MFA verlangt. Das ist ein klassischer Zero-Trust-Ansatz in der Praxis.
Audit-Mechanismen
Dieser Abschnitt lässt sich als erweiterte Erklärung der IAAA-Phase „Accountability“ verstehen und betrifft drei Bereiche: Protokollerfassung, Korrelation und Paketerfassung.
Protokollerfassung (Log Collection)
Ohne lückenlose Protokollierung gibt es keine Nachvollziehbarkeit – und ohne Nachvollziehbarkeit kein funktionierendes Audit. Die systematische Aufzeichnung von Ereignissen, Zugriffen und Systemzuständen ist die Grundlage jedes Auditsystems.
Die größte Herausforderung, besonders in der Cloud sind die riesigen Mengen an generierten Logdaten, auch bekannt als Data Overload. Selektives Logging ist der erste Schritt, um dieser Herausforderung zu begegnen. Sinnvolle Logs umfassen z. B. erfolgreiche und fehlgeschlagene Authentifizierungsversuche, Änderungen an sicherheitsrelevanten Einstellungen sowie Zugriffe auf sensible Daten. Auch die Datenfelder sollten nur relevanten Kontext liefern: wann, wo, wer, was.
Das OWASP Logging Cheat Sheet bietet eine praktische Checkliste mit konkreten Logging-Empfehlungen.
Korrelation
Die gesammelten Logs werden in einem zentralen System zusammengeführt (aggregiert), am besten in einem SIEM. Ein SIEM verknüpft zusammenhängende Ereignisse aus vielen Quellen (Korrelation), um daraus eine Ereigniskette zu rekonstruieren: Was ist passiert? Wann? Auf welchem System? Durch wen?
Bevor Abweichungen als Anomalie erkannt werden können, muss das System wissen, was „normal“ ist. Dies kann durch eine festgelegte Baseline des typischen System- und Benutzerverhaltens definiert werden oder durch eine automatische Lernphase des Systems selbst (UEBA – User and Entity Behavior Analytics). Außerdem müssen Prozesse definiert werden, die verdächtige Ereignisse bewerten und behandeln.
Paketmitschnitt (Packet Capture)
Packet Capture bezeichnet die Erfassung von Netzwerkpaketen zur Analyse, Fehlersuche oder Angriffserkennung. In der Cloud ist dies nur in begrenztem Umfang möglich – da kein Zugriff auf die physische Netzwerkebene besteht, kann nur der eigene virtuelle Netzwerkverkehr erfasst werden.
Man unterscheidet zwei Hauptarten:
Flow Logs – erfassen nur Metadaten zu Verbindungen (Quelle, Ziel, Protokoll, Zeit, Port). Die Logs sind klein und leicht zu verarbeiten.
Full Packet Capture – erfasst vollständige Paketinhalte und ermöglicht eine komplette Rekonstruktion der Kommunikation. Produziert jedoch enorme Datenmengen und ist aus Datenschutzgründen kritisch zu bewerten.
Die großen CSPs bieten eigene Tools zur Traffic-Erfassung: