In diesem Abschnitt befassen wir uns mit Cloud-Risiken – von der Identifikation, Analyse und Bewertung unterschiedlicher Bedrohungsarten bis hin zu den Maßnahmen zur Risikominderung.
Risikobewertung (Risk Assessment)
Identifikation
Jede Risikoanalyse, nicht nur in der IT, beginnt mit der Frage: Was genau wollen wir schützen? Der erste Schritt besteht darin, die Assets zu identifizieren und diese den kritischen Geschäftsprozessen zuzuordnen.
Assets umfassen alle Objekte, die für den Geschäftsbetrieb wichtig sind:
- Physische Assets – Rechenzentren, Server, Netzwerke, Storage-Systeme
- Logische Assets – VMs, Datenbanken, Anwendungen
- Immaterielle Assets – Daten, geistiges Eigentum, Markenimage, Verträge, Reputation
Alle diese Objekte werden in einem Asset-Register erfasst, einer strukturierten Liste mit Attributen wie Eigentümer, Klassifizierung, Standort und Kritikalität. Dies kann eine einfache Tabelle sein, aber auch spezialisierte Tools wie ServiceNow oder andere CMDB-Systeme (Configuration Management Database) übernehmen diese Funktion.
Nachdem die Assets identifiziert sind, müssen diese den entsprechenden Geschäftsprozessen zugeordnet werden, um festzustellen, welche Auswirkungen der Verlust oder die Störung eines bestimmten Assets auf das Unternehmen hätte.
Analyse
Die Anzahl der möglichen Option kann sich unterscheiden.
Nachdem die Assets identifiziert und zugeordnet sind, folgt die Analysephase. Hier geht es darum, Risiken zu priorisieren, indem man sie in zwei Kategorien bewertet:
- Likelihood – Wie wahrscheinlich ist das Eintreten des Risikos?
- Impact – Welche Auswirkungen hätte es auf das Unternehmen?
Likelihood – die Wahrscheinlichkeit wird auf Basis historischer oder statistischer Daten sowie unternehmenseigener Erfahrungswerte geschätzt. Risiken wie Phishing, Fehlkonfiguration oder Software-Schwachstellen gelten als häufig und wahrscheinlich – schwerwiegende Ereignisse wie Naturkatastrophen hingegen als selten.
Impact – hier werden die möglichen Auswirkungen bewertet: Finanzschäden, Reputationsschäden, betriebliche oder rechtliche Folgen. Da der Schaden völlig unterschiedliche Bereiche betreffen kann, ist die Zusammenarbeit mehrerer Abteilungen bei der Bewertung unerlässlich.
Schwachstellen, Bedrohungen und Angriffe in der Cloud
Aufgrund ihrer Architektur sind Cloud-Dienste spezifischen Risiken ausgesetzt: technischer, organisatorischer oder juristischer Natur. Da wir uns bereits in Abschnitt 1.3 ausführlich mit Schwachstellen beschäftigt haben, spare ich hier die Zeit und verweise nur auf die zwei wichtigsten Informationsquellen:
Ergänzend sind drei Cloud-spezifische Bedrohungsszenarien erwähnenswert:
Internetbasierte Angriffsfläche. Auch wenn Brute-Force-, DDoS- oder Port-Scanning-Angriffe keine Cloud-exklusiven Risiken sind, gibt es einen wichtigen Unterschied. In der Standardkonfiguration der meisten Public-Cloud-Umgebungen ist die Management Plane über das Internet erreichbar, im Gegensatz zu on-Premises, wo sie typischerweise im internen Netz liegt. Das lässt sich zwar durch Private Endpoints oder VPN-Verbindungen einschränken, in der Praxis wird dies oft vernachlässigt.
Indirekte Bedrohungen durch Angriffe auf den CSP: Nicht nur einzelne Kunden, sondern auch der Cloud-Anbieter selbst kann Ziel von Angriffen werden. Ein groß angelegter DDoS-Angriff auf den CSP kann die Verfügbarkeit beeinträchtigen. Das muss aber ehrlich gesagt ein eher kleiner CSP sein.
Multi-Tenancy-Risiken. Auch wenn das Thema bereits mehrfach angesprochen wurde, ist es aus Gründen der Vollständigkeit erwähnenswert. Theoretisch kann eine Isolationsschwachstelle, beispielsweise durch VM Escape dazu führen, dass ein Angreifer auf die VMs eines anderen Mandanten zugreift.
Strategien zur Risikominderung (Risk Mitigation Strategies)
Da viele Maßnahmen bereits in früheren Abschnitten behandelt wurden oder noch detailliert folgen, hier ein kompakter Überblick der wichtigsten Strategien:
Hybrid-Cloud-Strategie – die Kombination von On-Premises- und Cloud-Ressourcen kann zur Resilienzsteigerung beitragen. Ehrlich gesagt handelt es sich dabei oft um abstrakte Theorie, die nicht auf jeden Use-Case passt. Die Grundidee ist aber logisch: Wenn ein Teil der Infrastruktur ausfällt, übernimmt der andere nahtlos.
Schlüsselmanagement – die korrekte Verwaltung kryptografischer Schlüssel ist essenziell. Auch wenn es banal klingt: Wer die Kontrolle über die Schlüssel hat, behält die Kontrolle über die Daten. Je nach Schutzbedarf stehen verschiedene Modelle zur Verfügung:
- von KMS (Key Management Service) – (CSP verwaltet die Schlüssel)
- über CMK (Customer-Managed Keys) – (Kunde verwaltet Schlüssel im KMS des CSP)
- und BYOK (Bring Your Own Key) (Kunde bringt eigene Schlüssel mit)
- bis hin zu HYOK (Host Your Own Key) (Schlüssel verlassen die eigene Infrastruktur nie).
Regelmäßige Sicherheitsüberprüfungen – externe Penetrationstests und Vulnerability Scans ermöglichen die frühzeitige Erkennung sicherheitskritischer Schwachstellen.
Zero Trust und SIEM – die Implementierung einer Zero-Trust-Architektur sowie der Einsatz von SIEM-Lösungen sind oft keine Empfehlung mehr, sondern eine Notwendigkeit.
Schulungen – Administratoren, Entwickler und Endnutzer müssen regelmäßig sensibilisiert werden. Nur wer potenzielle Gefahren kennt, kann auch effektiv dagegen vorgehen.