Die Nutzung von Cloud-Diensten verändert nicht, wofür ein Unternehmen einsteht, sondern nur, wer welche Maßnahme ausführt. Der praktische Kern der Cloud-Sicherheit ist deshalb weniger technisch als organisatorisch: Die Trennlinie zwischen Anbieter- und Kundenverantwortung muss genau bekannt sein, und die eigene Seite muss tatsächlich besetzt werden.
Geteilte Verantwortung
| Bereich | IaaS | PaaS | SaaS |
|---|---|---|---|
| Rechenzentrum, Hardware, Netz | Anbieter | Anbieter | Anbieter |
| Virtualisierung | Anbieter | Anbieter | Anbieter |
| Betriebssystem, Aktualisierung | Kunde | Anbieter | Anbieter |
| Laufzeitumgebung, Middleware | Kunde | Anbieter | Anbieter |
| Anwendung, Konfiguration | Kunde | Kunde | teilweise Kunde |
| Identitäten und Berechtigungen | Kunde | Kunde | Kunde |
| Daten und deren Klassifizierung | Kunde | Kunde | Kunde |
Die beiden untersten Zeilen sind in jedem Modell Kundensache. Wer nur die oberen Zeilen betrachtet, kommt zu dem verbreiteten Fehlschluss, mit der Auswahl eines etablierten Anbieters sei die Sicherheitsfrage beantwortet.
Der häufigste Vorfall ist eine Fehlkonfiguration
Nicht der Einbruch beim Anbieter, sondern die eigene Einstellung ist der übliche Auslöser: öffentlich erreichbare Speicherbereiche, zu weit gefasste Zugriffsregeln, ungeschützte Verwaltungszugänge, ungenutzte Konten mit weitreichenden Rechten, offene Schnittstellen ohne Authentifizierung. Wirksam dagegen sind eine dokumentierte Soll-Konfiguration, eine regelmäßige automatisierte Prüfung gegen diese Vorgabe, Mehr-Faktor-Authentifizierung für alle administrativen Zugänge und die Auswertung der Protokolle des Anbieters im eigenen Betrieb.
Vertragliche und datenschutzrechtliche Seite
Werden personenbezogene Daten verarbeitet, ist der Anbieter regelmäßig Auftragsverarbeiter; erforderlich ist ein Vertrag nach Art. 28 DSGVO mit Weisungsbindung, Regelungen zu Unterauftragsverarbeitern, Unterstützungspflichten und Löschung oder Rückgabe am Vertragsende. Zu prüfen sind zudem die Verarbeitungsorte, der Kreis der Unterauftragsverarbeiter und die Frage, ob Daten in Drittländer übermittelt werden; für solche Übermittlungen sind geeignete Garantien erforderlich, deren Ausgestaltung rechtlich zu prüfen ist. Die eingesetzten Dienste gehören in das Verzeichnis von Verarbeitungstätigkeiten und in das Asset-Inventar.
Nachweise des Anbieters
Eigene Prüfungen vor Ort sind bei großen Anbietern praktisch nicht durchführbar; an ihre Stelle treten Nachweise:
- ISO/IEC 27001: Zertifikat über ein Informationssicherheits-Managementsystem; entscheidend ist der Geltungsbereich, nicht das Zertifikat als solches.
- BSI C5: Kriterienkatalog des BSI für Cloud-Dienste, in Deutschland verbreitet; die Berichte enthalten die Mitwirkungspflichten des Kunden, die häufig überlesen werden.
- ISO/IEC 27017 und 27018: ergänzende Leitfäden der 27000-Familie zu cloudspezifischen Maßnahmen und zum Umgang mit personenbezogenen Daten in öffentlichen Cloud-Diensten.
Jeder Nachweis gilt nur für den beschriebenen Geltungsbereich und einen bestimmten Zeitraum. Zu prüfen ist daher, ob der genutzte Dienst und die genutzte Region tatsächlich erfasst sind.
Ausstieg und Konzentration
Zwei Risiken werden regelmäßig unterschätzt. Erstens die Abhängigkeit: Ohne dokumentierten Ausstiegsplan mit Datenformaten, Übernahmewegen, Fristen und Zuständigkeiten ist ein Anbieterwechsel im Störungsfall keine reale Option. Zweitens die Konzentration: Wenn mehrere kritische Anwendungen bei demselben Anbieter oder in derselben Region liegen, entsteht ein gemeinsamer Ausfallpunkt, der in der Risikoanalyse ausdrücklich zu bewerten ist.
Was im eigenen Managementsystem bleibt
Die Auslagerung verkleinert den Betrieb, nicht die Governance: Cloud-Dienste sind zu inventarisieren, ihre Kritikalität ist zu bewerten, Berechtigungen sind zu rezertifizieren, Vorfälle beim Anbieter müssen im eigenen Meldeprozess ankommen, und der Wiederanlauf ist zu üben. Ein Dienst, der niemandem gehört und in keiner Übung vorkommt, ist die eigentliche Lücke.