In diesem Abschnitt geht es um die Fragen: wie managen Cloud-Provider ihre eigenen Risiken und was bedeutet das für den Cloud-Kunden?
Risikomanagementprogramme der CSP
Jeder CSP betreibt ein eigenes Risikomanagementprogramm, von dem man als Cloud-Kunde indirekt abhängig ist. Deshalb ist es wichtig zu verstehen, wie ein CSP Risiken identifiziert, bewertet und steuert.
Enterprise Risk Management (ERM)
ERM ist ein universelles Managementkonzept zur unternehmensweiten Steuerung aller Risiken technischer, strategischer, regulatorischer und operationeller Natur. Es ist nicht auf CSPs beschränkt, sondern wird in jeder größeren Organisation angewendet.
Im Cloud-Kontext ist ERM aus zwei Perspektiven relevant: Einerseits muss der Cloud-Kunde Cloud-spezifische Risiken in sein eigenes ERM integrieren. Andererseits muss er verstehen, wie der CSP sein ERM aufgebaut hat, da er indirekt davon abhängig ist. Aus diesem Gesamtbild leitet der CSP sein Risikoprofil und seine Risikobereitschaft (Risk Appetite) ab, also welche Risiken akzeptiert und welche aktiv mitigiert werden.
Supply-Chain-Risikomanagement (SCRM)
Ein Teilbereich des ERM ist das Supply-Chain-Risikomanagement. CSPs nutzen selbst Subdienstleister z. B. Hardwarelieferanten, Netzwerkanbieter oder Strom- und Wasserversorger. Diese Lieferkette bringt zusätzliche Risiken mit sich, auf die der Cloud-Kunde kaum direkten Einfluss hat. Deshalb muss der CSP auch die Risiken seiner eigenen Lieferkette systematisch bewerten und steuern.
Drittanbieter-Auditberichte
Da Kunden keinen direkten Einblick in die interne Infrastruktur von CSPs haben, müssen sie sich auf Auditberichte und Zertifizierungen von Drittanbietern verlassen.
- SOC 1 / SOC 2 / SOC 3 – bewertet interne Kontrollen des CSP (bereits ausführlich behandelt).
- FedRAMP – US-amerikanischer Standard für Cloud-Dienste, die von US-Bundesbehörden genutzt werden.
- ISO/IEC 27001 – Zertifizierung des ISMS des CSP.
- ISO/IEC 27017 – Cloud-spezifische Erweiterung von ISO 27001, im Bereich Sicherheitskontrollen für Cloud-Dienste.
- ISO/IEC 27018 – hier geht es um Schutz personenbezogener Daten in der Cloud.
- CSA STAR – Cloud-spezifisches Zertifizierungsprogramm der Cloud Security Alliance, das Transparenz über Sicherheitskontrollen des CSP schafft.
Regulatorische Transparenzanforderungen
Alle modernen Datenschutzgesetze erwarten in irgendeiner Form Transparenz gegenüber den Kunden, insbesondere wenn es um Fragen geht, wie Daten gesammelt, verarbeitet und gespeichert werden. Hinzu kommen die Meldepflichten im Falle von Datenpannen. Je nach Regelwerk bedeutet das konkret:
DSGVO – Datenpannen müssen innerhalb von 72 Stunden an die zuständige Aufsichtsbehörde gemeldet werden, außer, wenn die Datenpanne voraussichtlich kein Risiko für die Betroffenen darstellt. Die betroffenen Personen werden nur informiert, wenn ein hohes Risiko für ihre Rechte besteht.
SOX (Sarbanes-Oxley Act) – verpflichtet börsennotierte Unternehmen in den USA zur Transparenz über finanzrelevante Kontrollen und Prozesse. Verstöße müssen zeitnah offengelegt werden.
HIPAA – verlangt die Meldung von Datenpannen, die Gesundheitsdaten betreffen, innerhalb von 60 Tagen an das US-Gesundheitsministerium sowie an die betroffenen Personen.
Unterschied zwischen Data Owner, Controller, Custodian, Processor und Subject
Im Umgang mit personenbezogenen Daten sind mehrere Rollen und Verantwortlichkeiten klar definiert. Es ist wichtig, zwischen organisatorischen und rechtlichen Begriffen zu unterscheiden.
Der Data Owner (Dateneigentümer) ist eine Führungskraft, die für bestimmte Daten inhaltlich verantwortlich ist. Dies kann ein Abteilungsleiter, CIO oder CDO (Chief Data Officer) sein, abhängig davon, um welche Daten es sich handelt. Der Data Owner entscheidet, wer Zugriff erhält und wie die Daten genutzt werden dürfen.
Der Data Controller (Datenverantwortlicher) ist ein rechtlicher DSGVO-Begriff, der in der Praxis stark mit dem Data Owner überschneidet. Formal ist der Data Controller keine einzelne Person, sondern die Organisation als juristische Person, die über Zweck und Mittel der Datenverarbeitung entscheidet. Der Data Controller trägt die Hauptverantwortung und haftet für mögliche Datenschutzverstöße. Ein Beispiel für einen Data Controller ist eine Arztpraxis, die darüber entscheidet, welche Patientendaten zu welchem Zweck (Behandlung, Abrechnung) und wie lange sie gespeichert werden.
Der Data Custodian (Datenhüter) ist ebenfalls ein organisatorischer Begriff. Dies kann typischerweise die IT-Abteilung sein, die die Daten technisch verwaltet, ohne inhaltliche Entscheidungen zu treffen.
Der Data Processor (Datenverarbeiter) ist ein rechtlicher DSGVO-Begriff, der im Cloud-Kontext meist der CSP selbst ist. Der Data Processor verarbeitet personenbezogene Daten ausschließlich im Auftrag des Controllers. Er darf keine eigenen Entscheidungen über die Nutzung treffen. Seine Aufgaben sind rein technischer Natur.
Und der letzte Aktor ist der Data Subject (betroffene Person), also die natürliche Person, deren Daten verarbeitet werden. Beispielsweise ein Endkunde des Unternehmens. Die DSGVO gewährt der betroffenen Person klar definierte Rechte: das Recht auf Auskunft über gespeicherte Daten, das Recht auf Löschung, das Recht auf Einschränkung der Verarbeitung sowie das Widerspruchsrecht.
Risikobehandlung (Risk Treatment)
Die Risikobehandlung beschreibt die Methoden, die einem Unternehmen helfen, Risiken zu steuern. Als Grundlage dient eine vorherige Risikoanalyse, die sowohl die Eintrittswahrscheinlichkeit als auch die möglichen Auswirkungen bewertet. Die vier klassischen Strategien der Risikobehandlung sind:
Avoid (Vermeiden) – das Risiko wird vollständig vermieden, indem auf riskante Aktivitäten verzichtet wird.
Transfer (Übertragen) – das Risiko wird verlagert, z. B. durch Versicherung oder Outsourcing an Dritte.
Mitigate (Mildern) – das Risiko wird durch Kontrollen reduziert, sodass Eintrittswahrscheinlichkeit oder Auswirkung sinken.
Accept (Akzeptieren) – das Risiko wird bewusst toleriert, wenn es innerhalb der akzeptablen Risikogrenze liegt.
Unterschiedliche Risiko-Rahmenbedingungen (Risk Frameworks)
Im Bereich Risikomanagement gibt es eine Reihe von Frameworks, die helfen, Risiken systematisch zu identifizieren, zu bewerten und zu kontrollieren. Durch die Integration solcher Frameworks wird das Risikomanagement effizienter und messbar.
Wichtige Frameworks:
ISO 31000 – universelles Rahmenwerk mit Prinzipien und Prozessen zur Risikosteuerung, das in jeder Organisation angewendet werden kann.
ENISA Cloud Computing Risk Assessment – von der Europäischen Agentur für Netz- und Informationssicherheit entwickelt, fokussiert auf Sicherheits- und Datenschutzrisiken speziell in Cloud-Umgebungen. Cloud Computing Risk Assessment Download
NIST SP 800-37 – deckt den gesamten Lebenszyklus des Sicherheits- und Datenschutzmanagements ab, von der Risikobewertung über die Kontrollauswahl bis zur Überprüfung.
COSO Enterprise Risk Management (ERM) Framework – verknüpft Risikomanagement mit der Unternehmensstrategie und dient als Grundlage für Governance- und Entscheidungsprozesse.
Metriken für das Risikomanagement (Risk Metrics)
Risikometriken sind messbare Kennzahlen, die die Wirksamkeit von Sicherheits- und Risikoprogrammen bewerten. Einige dieser Kennzahlen, darunter MTTD, MTTC und MTTR, sind direkt entscheidend für die Incident-Response-Fähigkeit eines Unternehmens.
MTTD (Mean Time to Detect) – durchschnittliche Zeit, die benötigt wird, um einen Sicherheitsvorfall zu erkennen. Je kürzer, desto besser die Erkennungsfähigkeit.
MTTC (Mean Time to Contain) – Zeit zur Eingrenzung eines Vorfalls, um weiteren Schaden zu minimieren.
MTTR (Mean Time to Resolve) – Zeit bis zur vollständigen Behebung eines Vorfalls. MTTR ist ein Maß für die Resilienz und Reaktionsfähigkeit der Organisation.
Frequency of Intrusion Attempts – erfasst die Anzahl erkannter Angriffsversuche und gibt somit Aufschluss über die aktuelle Bedrohungslage.
Patch-Level – gibt an, wie viele Systeme mit aktuellen Sicherheitsupdates versorgt sind, bewertet damit den Stand des Schwachstellenmanagements.
Time to Deploy Patches – misst die Zeitspanne zwischen der Veröffentlichung und der tatsächlichen Implementierung eines Patches. Dies ist ein Indikator für die Effizienz der Reaktionsprozesse.
Bewertung der Risikoumgebung (Risk Assessment)
Die Risikobewertung bildet das Fundament des gesamten Risikomanagements. Sie hilft, fundierte Entscheidungen zu treffen und Risiken gezielt zu steuern.
Bei der Auswahl und der laufenden Bewertung eines CSP spielen folgende Kriterien eine zentrale Rolle:
Finanzielle Stabilität – die Fähigkeit des CSP, langfristig zuverlässige Leistungen zu erbringen.
Jurisdiktion – der Standort des Unternehmens und der Daten sowie die damit verbundenen rechtlichen Anforderungen.
Regulatorische Compliance – Nachweis über relevante Zertifizierungen.
Technische Resilienz – Verfügbarkeit, Redundanz sowie Backup- und Recovery-Fähigkeiten.