„Die Daten liegen in der Cloud“ klingt manchmal, als würden sie an einen abstrakten Ort außerhalb normaler Computertechnik verschoben.

Tatsächlich besteht die Cloud weiterhin aus sehr realer Infrastruktur:

Servern,

Speichersystemen,

Netzwerken,

Datenbanken,

Anwendungen

und Rechenzentren.

Der wesentliche Unterschied liegt darin, wie diese Ressourcen bereitgestellt und verwaltet werden. NIST definiert Cloud Computing als Modell, bei dem konfigurierbare IT-Ressourcen wie Rechenleistung, Speicher, Netzwerke und Anwendungen bedarfsgerecht über ein Netzwerk bereitgestellt und mit vergleichsweise geringem Verwaltungsaufwand skaliert beziehungsweise wieder freigegeben werden können. Zu den klassischen Merkmalen gehören On-Demand-Self-Service, breiter Netzwerkzugriff, gemeinsam genutzte Ressourcen, schnelle Elastizität und messbare Nutzung. (NIST Computer Security Resource Center)

Das Grundmodell lautet:

Nutzer oder Unternehmen
↓
Internet
↓
Cloudplattform
├── Anwendungen
├── Datenbanken
├── Speicher
├── virtuelle Server
├── Netzwerke
└── Identitäten

Cloud-Sicherheit beantwortet nun die Frage:

Wer darf unter welchen Bedingungen auf welche dieser Ressourcen zugreifen, wie werden die darin gespeicherten Daten geschützt und wie lässt sich der Betrieb nach Fehlern oder Angriffen wiederherstellen?

Die Cloud ist nicht automatisch sicher – aber auch nicht automatisch unsicher

Die verbreitete Aussage:

Cloud bedeutet, dass meine Daten auf dem Computer eines anderen liegen.

ist nicht völlig falsch, aber zu oberflächlich.

Ein großer Cloudanbieter kann hoch spezialisierte Rechenzentren, physische Sicherheitsmaßnahmen, redundante Infrastruktur, professionelle Netzwerke und umfangreiche Sicherheitsfunktionen betreiben, die ein kleines Unternehmen selbst kaum wirtschaftlich nachbauen könnte. Gleichzeitig kann der Kunde mit einer einzigen falschen Berechtigung eine eigentlich gut geschützte Ressource unnötig öffentlich machen.

Deshalb ist die sinnvollere Betrachtung:

Cloudanbieter
↓
schützt bestimmte Ebenen

und:

Cloudkunde
↓
muss andere Ebenen
richtig konfigurieren

Dieses Prinzip wird meist als Shared Responsibility, also geteilte Verantwortung, bezeichnet. CISA empfiehlt Cloudkunden ausdrücklich, das konkrete Verantwortungsmodell ihres Anbieters zu prüfen und zu verstehen, welche Schutzaufgaben bei ihnen selbst verbleiben. (cisa.gov)

Was bedeutet Shared Responsibility?

Ein Cloudanbieter kann beispielsweise dafür verantwortlich sein, dass:

das Rechenzentrum physisch geschützt ist,

die darunterliegende Hardware funktioniert,

bestimmte Plattformkomponenten gewartet werden,

die angebotene Infrastruktur technisch verfügbar ist.

Der Kunde entscheidet aber möglicherweise selbst:

welche Benutzer Administratoren sind,

ob MFA aktiviert wird,

welche Daten öffentlich erreichbar sind,

welche Anwendungen installiert werden,

wie lange Backups aufbewahrt werden,

welche API-Schlüssel existieren.

Das Sicherheitsmodell sieht deshalb eher so aus:

Cloudanbieter
+
Cloudkunde
↓
gemeinsame Gesamtsicherheit

und nicht:

Cloudanbieter
↓
kümmert sich um alles

Welche Seite genau welche Aufgaben übernimmt, hängt stark vom genutzten Cloudmodell ab. (NIST Computer Security Resource Center)

SaaS, PaaS und IaaS verändern die Verantwortung

NIST unterscheidet drei grundlegende Servicemodelle. Bei Software as a Service, kurz SaaS, nutzt der Kunde im Wesentlichen die Anwendung des Anbieters. Bei Platform as a Service, PaaS, stellt der Anbieter zusätzlich eine Laufzeit- beziehungsweise Entwicklungsplattform bereit. Bei Infrastructure as a Service, IaaS, erhält der Kunde wesentlich mehr Kontrolle über virtuelle Server, Betriebssysteme, Anwendungen und Netzwerkkonfiguration. (NIST Computer Security Resource Center)

Modell	Kunde verwaltet typischerweise	Anbieter übernimmt typischerweise
SaaS	Benutzer, Daten, Freigaben, viele Sicherheitseinstellungen	Anwendung, Plattform, Betriebssystem, Infrastruktur
PaaS	eigene Anwendungen, Daten, Benutzer, Anwendungskonfiguration	Laufzeitplattform und darunterliegende Infrastruktur
IaaS	Betriebssystem, Anwendungen, Daten, viele Netzwerk- und Sicherheitsregeln	physische Infrastruktur und Virtualisierung

Diese Darstellung ist bewusst vereinfacht. Das konkrete Vertrags- und Servicemodell eines Anbieters ist entscheidend.

SaaS bedeutet nicht „keine eigene Sicherheitsarbeit“

Ein Unternehmen verwendet beispielsweise eine cloudbasierte Bürosoftware.

Der Anbieter kümmert sich um:

Server,

Betriebssystem,

Updates der eigentlichen SaaS-Anwendung.

Das Unternehmen entscheidet weiterhin:

Wer bekommt ein Konto?

Wer ist Administrator?

Wer darf Dateien teilen?

Ist MFA aktiv?

Welche externen Freigaben existieren?

Was passiert mit ehemaligen Mitarbeitern?

CISAs Secure Cloud Business Applications Projekt konzentriert sich genau auf solche Fragen und stellt Sicherheitskonfigurationen für SaaS-Umgebungen bereit. Dazu gehören beispielsweise MFA, sichere Kontokonfiguration und Audit-Logging. (cisa.gov)

Ein SaaS-Anbieter kann also die Plattform hervorragend absichern, während der Kunde:

Gastfreigabe:
Jeder mit Link

für vertrauliche Dokumente aktiviert.

Das Problem liegt dann nicht im Rechenzentrum.

Es liegt in der Konfiguration.

Bei IaaS wächst die eigene Verantwortung erheblich

Ein virtueller Cloudserver ähnelt aus Sicht des Administrators in vielen Bereichen einem eigenen Server.

Der Provider betreibt beispielsweise:

Hardware,

Virtualisierung,

physisches Netzwerk.

Du betreibst:

virtuellen Server
├── Betriebssystem
├── Benutzer
├── SSH
├── Webserver
├── Datenbank
├── Firewallregeln
├── Anwendung
└── Updates

Ein ungepatchtes Betriebssystem bleibt ungepatcht, nur weil es in einem professionellen Rechenzentrum läuft.

Ein öffentlich erreichbarer Administrationsport bleibt öffentlich erreichbar.

Eine falsch konfigurierte Datenbank bleibt falsch konfiguriert.

Cloud verlagert Infrastruktur. Sie beseitigt Administration nicht automatisch.

Identitäten sind das neue Zentrum der Cloud-Sicherheit

Bei einem klassischen Büro konnte eine wichtige Sicherheitsgrenze früher ungefähr so aussehen:

Internet
↓
Firewall
↓
Firmennetz
↓
Server

Cloudanwendungen sind dagegen häufig bewusst über das Internet erreichbar.

Die entscheidende Grenze wird damit zunehmend:

Wer bist du?
↓
Wie authentifizierst du dich?
↓
Was darfst du?

CISA weist darauf hin, dass aktuelle fortgeschrittene Angriffe auf Cloudumgebungen besonders Identitäten, Authentifizierungstokens, Schlüssel, Logging und Drittanbieterabhängigkeiten ins Visier nehmen. (cisa.gov)

Das bedeutet:

Ein Cloudkonto ist nicht einfach ein Benutzerkonto. Es kann ein Schlüssel zu einer kompletten Infrastruktur sein.

Das wichtigste Konto ist oft der Cloud-Administrator

Ein normaler Mitarbeiter darf vielleicht:

Dokumente lesen.

Ein Cloudadministrator kann unter Umständen:

Benutzer anlegen,

Berechtigungen ändern,

Speicher löschen,

Server starten,

Backups entfernen,

API-Schlüssel erzeugen,

Sicherheitsregeln verändern.

Das Schadenspotential unterscheidet sich erheblich.

normales Konto kompromittiert
↓
begrenzter Schaden

gegen:

Cloud-Administrator kompromittiert
↓
möglicherweise gesamte Umgebung

Deshalb sollten privilegierte Cloudkonten besonders stark geschützt werden – insbesondere mit MFA beziehungsweise phishing-resistenter Authentifizierung, getrennten Administrationsrollen und möglichst geringen dauerhaften Berechtigungen. CISA empfiehlt Least Privilege und eine klare Trennung von Aufgaben ausdrücklich auch für Cloud- und Drittanbieterzugriffe. (cisa.gov)

Nicht täglich mit dem mächtigsten Konto arbeiten

Ein sehr einfacher Sicherheitsgewinn besteht darin, Administration und normale Arbeit zu trennen.

Nicht:

Super-Administrator
↓
E-Mail lesen
Dokumente öffnen
Websites besuchen
alles verwalten

sondern beispielsweise:

normales Konto
→ tägliche Arbeit

und:

Admin-Konto
→ nur Administration

So wird aus einem Phishingangriff gegen den täglichen Arbeitsplatz nicht automatisch ein Angriff mit maximalen Cloudrechten.

Least Privilege

Das Grundprinzip lautet:

Ein Benutzer, Dienst oder Programm erhält nur die Rechte, die er tatsächlich benötigt.

Ein Backupdienst muss vielleicht:

Daten lesen
+
Backup schreiben

Er muss deshalb nicht unbedingt:

Benutzerverwaltung ändern
+
Netzwerk löschen
+
Cloudkonto schließen

dürfen.

CISA empfiehlt Least Privilege ausdrücklich, um die Auswirkungen kompromittierter Accounts und Drittanbieterzugriffe zu begrenzen. (cisa.gov)

Rollen sind besser als wild verteilte Einzelrechte

In einer wachsenden Umgebung wird es schnell unübersichtlich, jedem Mitarbeiter zwanzig einzelne Berechtigungen zu geben.

Ein saubereres Modell:

Rolle:
WordPress-Administrator
↓
definierte Rechte

Rolle:
Buchhaltung
↓
andere Rechte

Rolle:
Backup-Service
↓
nur Backup-Rechte

Menschen beziehungsweise Dienste werden anschließend diesen Rollen zugeordnet.

Das erleichtert:

Onboarding,

Offboarding,

Kontrolle,

Audit.

Offboarding gehört zur Cloud-Sicherheit

Ein Mitarbeiter verlässt ein Unternehmen.

Damit sollte nicht nur:

Laptop zurückgeben

erledigt sein.

Zu prüfen sind beispielsweise:

Cloudkonto,

API-Zugänge,

Gruppen,

Freigaben,

MFA-Geräte,

aktive Sitzungen,

gemeinsame Geheimnisse.

Mitarbeiter verlässt Unternehmen
↓
Konto sperren
↓
Sessions beenden
↓
Berechtigungen entfernen
↓
geteilte Secrets prüfen

Cloudsysteme machen Zugriff sehr bequem. Genau deshalb muss der Entzug von Zugriff ebenso systematisch funktionieren.

Menschliche Konten sind nur ein Teil der Identitäten

Cloudsysteme bestehen zunehmend aus Anwendungen, die miteinander kommunizieren.

Zum Beispiel:

WordPress
↓
Objektspeicher

Backupsoftware
↓
Cloudspeicher

Automatisierung
↓
API
↓
Clouddienst

Diese Programme brauchen ebenfalls Identitäten.

Dafür existieren beispielsweise:

Service Accounts,

API-Schlüssel,

Tokens,

Zertifikate,

Workload-Identitäten.

CISA hat Cloud-Identität, Tokens, Schlüsselverwaltung und Secrets ausdrücklich als zentrale aktuelle Sicherheitsfelder hervorgehoben. (cisa.gov)

API-Schlüssel sind Passwörter für Programme

Ein API-Key sieht vielleicht so aus:

sk_xxxxxxxxxxxxxxxxx

Er ist kein Benutzerpasswort.

Aber sicherheitstechnisch kann er eine ähnliche Funktion besitzen:

Wer diesen Schlüssel besitzt
↓
kann bestimmte API-Rechte nutzen

Deshalb darf er nicht gedankenlos in:

Quellcode,

öffentliche Git-Repositories,

Supporttickets,

Logdateien

geschrieben werden.

Secrets gehören in eine kontrollierte Secret-Verwaltung

Eine Anwendung benötigt beispielsweise:

Datenbankpasswort,

API-Key,

privaten Schlüssel.

Schlechte Lösung:

config.php
↓
Passwort im Klartext
↓
Git Repository

Besser ist eine Architektur, bei der Geheimnisse kontrolliert bereitgestellt, Zugriffe protokolliert und Schlüssel bei Bedarf ersetzt beziehungsweise rotiert werden können.

CISA hebt korrekt verwaltete Secrets, Schlüsselrotation und Schlüsselmanagement als wichtige Bestandteile moderner Cloud-Identity-Sicherheit hervor. (cisa.gov)

Langfristige API-Schlüssel vermeiden, wenn bessere Identitäten möglich sind

Ein statischer Schlüssel funktioniert vielleicht fünf Jahre lang.

Das ist bequem.

Aber wenn er irgendwann kopiert wurde, kann er möglicherweise ebenso lange missbraucht werden.

Moderne Cloudarchitekturen können stattdessen kurzlebige Anmeldeinformationen beziehungsweise Workload-Identitäten verwenden.

Das zugrunde liegende Prinzip:

dauerhaftes Geheimnis
↓
großes Zeitfenster bei Diebstahl

gegen:

kurzlebiger Nachweis
↓
kleineres Missbrauchsfenster

Welche technischen Möglichkeiten bestehen, hängt vom konkreten Cloudsystem ab.

Cloudkonten brauchen MFA

Ein Cloudadministrator nur mit:

E-Mail
+
Passwort

ist ein unnötig attraktives Ziel.

Das gilt besonders, weil Cloudkonten über das Internet erreichbar sein sollen.

Die bereits unter 2FA, MFA und Passkeys beschriebenen Prinzipien greifen hier unmittelbar. Phishing-resistente Authentifizierung kann besonders wertvoll sein, weil ein erfolgreich gestohlener Adminzugang enorme Auswirkungen haben kann. NISTs aktuelle Digital Identity Guidelines Revision 4 behandeln starke Authentifizierung und phishing-resistente Verfahren entsprechend als zentrale Bausteine moderner Identitätssicherheit. (NIST)

Recovery des Administratorkontos nicht vergessen

Starke MFA ist hervorragend.

Dann geht das einzige registrierte Gerät verloren.

Nun darf der Wiederherstellungsprozess nicht zum schwächsten Teil des Systems werden.

starker Login
+
schwaches Recovery
=
schwaches Gesamtsystem

Deshalb gehören zu wichtigen Cloudzugängen:

Recovery-Codes,

Backup-Authenticatoren,

definierte Notfallprozesse.

Das ist dieselbe Logik wie beim Passwortmanager.

Die Control Plane ist besonders kritisch

Cloudplattformen besitzen vereinfacht zwei Ebenen.

Die Data Plane verarbeitet die eigentlichen Daten beziehungsweise Anwendungen.

Website
Datenbank
Dateispeicher

Die Control Plane steuert diese Ressourcen.

Server erstellen
Speicher löschen
Firewall verändern
Benutzer anlegen
Schlüssel erzeugen

Wer die Control Plane kontrolliert, kann häufig die komplette Umgebung verändern.

Deshalb ist der Schutz des Cloud-Administrationszugangs mindestens so wichtig wie der Schutz eines einzelnen Servers.

Fehlkonfigurationen sind ein zentrales Cloudrisiko

Cloudressourcen lassen sich sehr schnell bereitstellen.

Das ist einer ihrer größten Vorteile.

Klick
↓
neuer Speicher

API
↓
20 Server

Template
↓
komplette Umgebung

Die Kehrseite:

Falsche Konfigurationen skalieren genauso schnell.

NIST-Forschung zur Cloud-Sicherheitsautomatisierung hebt deshalb die Bedeutung kontinuierlicher Kontrolle von Konfigurationen und Sicherheitsvorgaben hervor. CISA stellt mit SCuBA ebenfalls konkrete Sicherheitsbaselines für cloudbasierte Geschäftsanwendungen bereit. (NIST)

„Public“ ist eine mächtige Einstellung

Ein Cloudspeicher kann beispielsweise enthalten:

Kundenexporte,

Backups,

Fotos,

Dokumente.

Wenn dessen Zugriffsregel lautet:

öffentlich lesbar

hilft die hervorragende physische Sicherheit des Rechenzentrums wenig.

Die Daten wurden vom Kunden selbst freigegeben.

Deshalb gehören zu Cloud-Sicherheitsprüfungen Fragen wie:

Welche Ressourcen sind öffentlich erreichbar?

Warum?

Müssen sie öffentlich sein?

Wer kann die Freigabe verändern?

Standardmäßig privat ist besser

Ein sicheres Grundmodell lautet:

neue Ressource
↓
standardmäßig geschlossen
↓
Zugriff bewusst hinzufügen

statt:

neue Ressource
↓
erst einmal öffentlich
↓
später vielleicht absichern

Dieses Prinzip entspricht sowohl Least Privilege als auch dem Datenschutzgedanken Privacy by Default aus Datenschutz verstehen.

Netzwerkregeln ebenfalls minimal halten

Eine Cloud-Firewall könnte beispielsweise erlauben:

SSH
Port 22
Quelle:
gesamtes Internet

Vielleicht benötigt aber nur ein Administrationssystem Zugriff.

Dann wäre ein engerer Zugangsweg angemessener.

Internet
↓
kontrollierter Admin-Zugang
↓
Server

Der Grundgedanke aus dem VPN-Artikel bleibt bestehen:

Nur weil eine Ressource technisch über das Internet erreichbar sein kann, muss sie nicht öffentlich erreichbar sein.

Zero Trust passt besonders gut zur Cloud

Cloudsysteme verteilen Ressourcen über:

SaaS,

mehrere Clouds,

Rechenzentren,

Homeoffice,

mobile Geräte.

Die alte Vorstellung:

internes Netzwerk
=
vertrauenswürdig

funktioniert dadurch immer schlechter.

NIST beschreibt Zero Trust deshalb als Modell, bei dem weder Benutzer noch Geräte allein aufgrund ihrer Netzwerkposition automatisch vertraut werden. Zugriff soll stärker an Identität, Gerät, Ressource und konkrete Berechtigung gebunden werden. (cisa.gov)

Das bedeutet:

Wer?
+
welches Gerät?
+
welche Ressource?
+
welcher Kontext?
↓
Zugriff erlauben oder ablehnen

Daten in der Cloud brauchen Schutz in verschiedenen Zuständen

Daten können grob drei Zustände besitzen:

Data at Rest
→ gespeichert

Data in Transit
→ werden übertragen

Data in Use
→ werden gerade verarbeitet

Für gespeicherte und übertragene Daten stehen heute weit verbreitete Verschlüsselungsmechanismen zur Verfügung. Für besonders sensible Anwendungen entwickelt sich zusätzlich sogenanntes Confidential Computing weiter, das auch Daten während bestimmter Verarbeitungsvorgänge in geschützten Ausführungsumgebungen absichern soll; NIST veröffentlichte dazu 2026 einen neuen Entwurf speziell für Cloud- und KI-Workloads. (NIST Computer Security Resource Center)

Für einen normalen Cloudnutzer sind zunächst die ersten beiden Ebenen entscheidend.

Verschlüsselung bei der Übertragung

Daten sollten zwischen Benutzer beziehungsweise Anwendung und Cloudservice über geschützte Protokolle transportiert werden.

Bei Webanwendungen bedeutet das beispielsweise:

HTTPS / TLS

wie unter SSL und HTTPS beschrieben.

Auch APIs, Datenbankverbindungen und Verwaltungszugänge sollten entsprechend geschützt werden.

Verschlüsselung gespeicherter Daten

Viele Cloudplattformen können Daten auf Speichermedien verschlüsselt ablegen.

Das reduziert insbesondere bestimmte Risiken, falls physische Datenträger beziehungsweise darunterliegende Speicherbereiche unberechtigt gelesen werden.

Aber:

verschlüsselte Festplatte
+
Angreifer hat legitime Cloud-Administratorrechte

kann trotzdem ein Problem sein.

Denn ein berechtigter Dienst muss die Daten schließlich entschlüsseln können.

Verschlüsselung ersetzt daher kein Berechtigungsmanagement.

Wer kontrolliert die Schlüssel?

Das führt zur eigentlichen Schlüsselfrage.

Daten
↓
verschlüsselt
↓
Schlüssel

Wer den Schlüssel kontrolliert, besitzt einen entscheidenden Teil der Sicherheitsarchitektur.

Je nach Cloudmodell können Schlüssel:

vom Anbieter verwaltet,

vom Kunden kontrolliert,

über spezielle Key-Management-Systeme verwaltet

werden.

Das sinnvollste Modell hängt vom Schutzbedarf ab.

Eigene Schlüssel bedeuten auch eigene Verantwortung

„Wir verwalten die Schlüssel selbst“ klingt sicherer.

Kann es sein.

Aber dann muss auch gelöst werden:

Wo liegt der Schlüssel?

Wer darf ihn verwenden?

Wie wird er gesichert?

Wie wird er rotiert?

Was passiert bei Verlust?

Wie funktioniert Recovery?

Ein verlorener Schlüssel kann genauso problematisch sein wie ein gestohlener.

Schlüssel gestohlen
→ Vertraulichkeit gefährdet

Schlüssel verloren
→ eigene Daten eventuell unzugänglich

Schlüsselmanagement ist damit gleichzeitig Sicherheits- und Verfügbarkeitsmanagement.

Cloud-Synchronisierung ist kein Backup

Dieser Satz ist so wichtig, dass er erneut vorkommen muss.

Ein Ordner wird zwischen Notebook und Cloud synchronisiert.

Datei lokal geändert
↓
Cloud aktualisiert

Das ist praktisch.

Wird die Datei versehentlich gelöscht:

Datei gelöscht
↓
Löschung synchronisiert

kann auch die Cloudkopie verschwinden.

Wird sie durch Ransomware verschlüsselt:

Datei verschlüsselt
↓
geänderte Datei synchronisiert

kann der beschädigte Zustand ebenfalls übertragen werden.

Deshalb unterscheiden wir seit Backup-Grundlagen:

Synchronisierung
→ aktuellen Zustand verteilen

von:

Backup
→ früheren Zustand wiederherstellbar halten

„Der Anbieter hat doch Backups“ reicht nicht

Bei SaaS kann der Anbieter interne Sicherungen besitzen, um seinen Dienst nach technischen Fehlern wiederherzustellen.

Das bedeutet nicht zwangsläufig, dass du einzelne:

gelöschte Dateien,

Postfächer,

Kundeneinträge

von vor sechs Monaten nach deinen Vorstellungen restaurieren kannst.

Die relevante Frage lautet daher:

Was garantiert der Dienst?

Was kann ich selbst restaurieren?

Wie lange existieren Versionen?

Welche Löschfristen gelten?

Brauche ich ein zusätzliches Backup?

Cloud-to-Cloud-Backup kann sinnvoll sein

CISA empfiehlt im Ransomware-Kontext ausdrücklich häufige Backups und nennt neben Offline-Backups auch Cloud-to-Cloud-Backup als mögliche Strategie. (cisa.gov)

Beispielsweise:

SaaS-System A
↓
separater Backupdienst
↓
Backup-Speicher B

Das schafft eine stärkere Trennung als:

Produktivdaten
+
Backup
↓
im exakt selben Fehlerbereich
mit exakt denselben Rechten

Backups gegen Löschen schützen

Ein kompromittierter Administrator könnte versuchen:

Produktivdaten löschen,

Backups löschen,

Logs löschen.

CISA empfiehlt deshalb für Cloudressourcen unter anderem:

Delete Protection,

Object Lock beziehungsweise unveränderbaren Speicher,

Versionierung

und Restriktionen, die verhindern, dass normale Benutzer oder Rollen kritische Logging- und Recovery-Konfigurationen einfach verändern. (cisa.gov)

Das Grundprinzip lautet:

Angreifer kontrolliert
Produktivkonto
↓
Recovery-Pfad bleibt
trotzdem erhalten

Versionierung ist sehr wertvoll

Ein Speicherobjekt wird verändert:

Version 1
↓
Version 2
↓
Version 3

Wenn Version 3 beschädigt ist, kann möglicherweise Version 2 wiederhergestellt werden.

Das hilft bei:

versehentlichen Änderungen,

Löschungen,

bestimmten Ransomware-Szenarien.

CISA empfiehlt Versionierung für Cloudspeicher ausdrücklich als zusätzliche Recovery-Möglichkeit. (cisa.gov)

Versionierung ist trotzdem kein vollständiges Backup

Wenn ein kompromittierter Administrator:

alle Versionen löschen

darf, nützt Versionierung möglicherweise wenig.

Deshalb müssen zusammen betrachtet werden:

Versionierung
+
Löschschutz
+
Berechtigungen
+
separate Recovery-Strategie

Cloud-Sicherheit besteht selten aus einer einzigen Checkbox.

Ransomware funktioniert auch in der Cloud

Wie unter Malware und Ransomware beschrieben, muss ein Angreifer nicht zwingend eine Festplatte klassisch verschlüsseln.

Ein kompromittiertes Cloudkonto könnte möglicherweise über legitime APIs:

Dateien verändern,

Objekte löschen,

Snapshots entfernen,

Daten kopieren.

gestohlene Cloudidentität
↓
legitime API
↓
böswillige Aktionen

Der Angriff kann also vollständig über Funktionen erfolgen, die der Cloudservice absichtlich anbietet.

CISA empfiehlt daher speziell für Cloudressourcen Backups, Versionierung, Logging, Löschschutz und Einschränkungen privilegierter Aktionen. (cisa.gov)

Eine legitime API kann gefährlicher sein als Malware

Das ist ein wichtiger Cloudgedanke.

Ein Angreifer besitzt einen gültigen API-Schlüssel mit Administratorrechten.

Nun braucht er vielleicht überhaupt keinen Schadcode.

API:
delete-object

API:
create-user

API:
change-policy

sind legitime Funktionen.

Das Problem ist:

Wer führt sie aus und mit welcher Berechtigung?

Cloud-Sicherheit konzentriert sich deshalb so stark auf Identität, Autorisierung und Audit-Logs.

APIs müssen authentifiziert werden

CISA empfiehlt bei programmatischem Cloudzugriff, wo unterstützt, signierte API-Anfragen einzusetzen, damit der Cloudservice die Identität des Anfragenden prüfen und die Integrität beziehungsweise Authentizität des Requests absichern kann. (cisa.gov)

Das Prinzip:

Anwendung
↓
authentifizierte API-Anfrage
↓
Cloudplattform
↓
Berechtigung prüfen
↓
Aktion erlauben / ablehnen

Nicht:

API öffentlich
↓
jeder darf alles

Secrets nicht in URLs oder Logs schreiben

Ein API-Key in einer URL kann anschließend möglicherweise auftauchen in:

Browserhistorie,

Proxylogs,

Serverlogs,

Analysewerkzeugen.

Ein Secret sollte deshalb wie ein Passwort behandelt werden.

Secret
↓
nur dort verfügbar,
wo es benötigt wird

und nicht:

Secret
↓
möglichst viele Systeme

Logging ist in der Cloud unverzichtbar

Cloudumgebungen verändern sich schnell.

Eine Ressource kann:

um 14:01 erstellt,

um 14:03 öffentlich gemacht,

um 14:07 wieder gelöscht

werden.

Ohne Logs weiß man später vielleicht nicht:

wer,

wann,

was

gemacht hat.

CISA nennt zu kurze oder fehlende Logs ausdrücklich als Problem moderner Cloud-Identity-Sicherheit und empfiehlt für Cloudressourcen umfassendes Logging sowie Warnungen bei ungewöhnlicher Nutzung. (cisa.gov)

Besonders wichtig sind Administrationslogs

Beispielsweise:

Benutzer erstellt

MFA deaktiviert

API-Key erzeugt

Firewall geändert

Speicher öffentlich gemacht

Backup gelöscht

Diese Ereignisse können sicherheitsrelevanter sein als ein einzelner normaler Dateizugriff.

Logging ohne Auswertung bringt wenig

Zehn Millionen Logzeilen zu besitzen ist noch keine Detection.

Das Ziel lautet:

Ereignisse
↓
auffälliges Muster
↓
Alarm

Beispielsweise:

Administrator
meldet sich normalerweise
aus Österreich an
↓
plötzlich neue Region
+
neues Gerät
+
mehrere kritische Änderungen

Das ist kein automatischer Beweis für einen Angriff.

Aber ein guter Grund zur Prüfung.

Logs müssen selbst geschützt werden

Wenn ein Angreifer Administrator wird und anschließend:

Angriff durchführen
↓
Logs löschen

kann die Analyse erschwert werden.

CISA empfiehlt deshalb Richtlinien, mit denen Rollen daran gehindert werden können, kritische Logging-Konfigurationen beziehungsweise Logs zu verändern oder zu löschen. (cisa.gov)

Ein robustes Modell:

Produktionskonto kompromittiert
↓
zentrale Logs bleiben erhalten

Alarmierung vor dem Totalschaden

Cloudplattformen besitzen den Vorteil, dass sehr viele Verwaltungsvorgänge zentral beobachtbar sind.

Damit lassen sich Warnungen definieren:

MFA deaktiviert
→ Alarm

öffentliche Freigabe erstellt
→ Alarm

ungewöhnlich viele Daten heruntergeladen
→ Alarm

Backup-Schutz deaktiviert
→ Alarm

neuer Administrator
→ Alarm

CISA empfiehlt ausdrücklich, Cloudlogging zu aktivieren und Warnungen bei abnormaler Nutzung einzurichten. (cisa.gov)

Cloud-Sicherheit sollte automatisiert überprüft werden

Eine Konfiguration kann heute stimmen.

Morgen verändert jemand:

Firewall,

Rolle,

Speicherfreigabe.

Deshalb ist Cloud-Sicherheit besonders gut für kontinuierliche Prüfungen geeignet.

gewünschter Soll-Zustand
↓
automatisch prüfen
↓
Abweichung?
├── nein → weiter
└── ja → melden / korrigieren

NIST beschreibt genau diese Idee in Arbeiten zur automatisierten Konfiguration und kontinuierlichen Überwachung von Cloud-Sicherheitskontrollen. (NIST)

Infrastructure as Code kann Sicherheit reproduzierbarer machen

Anstatt Server und Netzwerke ausschließlich von Hand anzuklicken, kann die Infrastruktur als definierte Konfiguration beschrieben werden.

Code / Template
↓
Netzwerk
Server
Firewall
Berechtigungen

Vorteil:

Die gewünschte Konfiguration lässt sich:

versionieren,

prüfen,

wiederholen,

reviewen.

Der Nachteil ist ebenfalls offensichtlich:

Fehler im Template
↓
Fehler wird automatisch
überall ausgerollt

Automatisierung beseitigt keine Fehler.

Sie macht gute und schlechte Entscheidungen skalierbar.

Deshalb brauchen Konfigurationen Reviews

Gerade Sicherheitsregeln verdienen denselben Reviewgedanken wie Anwendungscode.

Änderung
↓
Review
↓
Test
↓
Deployment

Das ist besser als:

Administrator klickt
Freitag 23:47
irgendeine Firewallregel

ohne nachvollziehbare Historie.

Cloud-Sicherheit ist auch Kosten-Sicherheit

Ein kompromittierter Cloudaccount kann nicht nur Daten stehlen.

Er könnte beispielsweise teure Ressourcen anlegen.

gestohlener Account
↓
100 leistungsfähige Instanzen
↓
hohe Rechnung

Deshalb können Budgetwarnungen und ungewöhnliche Nutzungsspitzen ebenfalls Sicherheitsindikatoren sein.

Cloudsicherheit und Kostenkontrolle überschneiden sich hier.

Verfügbarkeit bedeutet mehr als „Cloudanbieter hat mehrere Server“

Eine Cloudplattform kann sehr robust sein.

Trotzdem können Ausfälle entstehen durch:

Providerstörung,

Netzwerkproblem,

Fehlkonfiguration,

gelöschte Ressource,

gesperrtes Konto,

Softwarefehler.

Eine wichtige Anwendung sollte deshalb fragen:

Was passiert,
wenn dieser Dienst ausfällt?

und nicht nur:

Hat der Anbieter
eine gute Verfügbarkeitszahl?

Region und Availability Zone sind keine Backupstrategie

Eine Anwendung über mehrere Rechenzentrumsbereiche zu verteilen kann die Verfügbarkeit verbessern.

Zone A fällt aus
↓
Zone B übernimmt

Das hilft gegen bestimmte Infrastrukturfehler.

Wenn ein Administrator aber sagt:

DELETE Datenbank

und die Änderung korrekt repliziert wird, kann Redundanz die Löschung ebenfalls replizieren.

Redundanz
→ schützt Betrieb
gegen bestimmte Ausfälle

Backup
→ schützt früheren Zustand

Diese Konzepte dürfen nicht verwechselt werden.

Multi-Cloud ist nicht automatisch sicherer

Zwei Anbieter können Abhängigkeiten reduzieren.

Aber:

Cloud A
+
Cloud B

bedeutet auch:

zwei Identitätssysteme,

zwei Berechtigungsmodelle,

zwei Loggingwelten,

zwei Netzwerke,

zwei Kostenmodelle,

mehr Konfiguration.

Komplexität kann selbst zum Sicherheitsrisiko werden.

Multi-Cloud sollte deshalb ein konkretes Problem lösen und nicht als Sicherheitszauberwort verwendet werden.

Vendor Lock-in ist kein unmittelbares Sicherheitsproblem – aber ein Recovery-Thema

Ein Unternehmen sollte wissen:

Wie exportieren wir unsere Daten?

In welchem Format?

Wie lange dauert das?

Was passiert bei Vertragsende?

Was passiert bei Kontosperre?

Wenn eine Anwendung technisch hervorragend geschützt ist, du deine Daten aber im Notfall praktisch nicht mehr herausbekommst, besteht ein Verfügbarkeits- und Geschäftsrisiko.

SaaS braucht einen Exit-Plan

Bei kritischen SaaS-Anwendungen sollte geklärt sein:

Welche Daten können exportiert werden?

Gibt es API-Zugang?

Welche Metadaten fehlen im Export?

Wie lange bleiben Daten nach Kündigung erhalten?

Wie werden Accounts migriert?

Ein Exit-Plan muss nicht bedeuten, morgen den Anbieter zu wechseln.

Er bedeutet:

Das Unternehmen weiß, wie es im Ernstfall weiterarbeiten könnte.

Datenschutz bleibt auch in der Cloud Datenschutz

Personenbezogene Daten verlieren ihren Charakter nicht, weil sie in einem Cloudservice gespeichert werden.

Wie unter Datenschutz verstehen erklärt, muss weiterhin geklärt werden:

Zweck,

Rechtsgrundlage,

Verantwortlichkeiten,

Empfänger,

Auftragsverarbeitung,

Speicherfristen,

Sicherheitsmaßnahmen

und gegebenenfalls internationale Datenübermittlungen.

Cloud-Sicherheit beantwortet damit nicht automatisch sämtliche Datenschutzfragen.

technisch sicher
≠
automatisch datenschutzrechtlich zulässig

Datenstandort ist nur eine von mehreren Fragen

Die Frage:

In welchem Land steht der Server?

kann wichtig sein.

Aber sie reicht nicht.

Ebenso relevant sind beispielsweise:

Wer betreibt den Dienst?

Welche Unternehmen können Daten verarbeiten?

Welche Unterauftragnehmer existieren?

Wo erfolgt Support?

Welche rechtlichen Transfermechanismen gelten?

Wer besitzt Administrationszugang?

Datenschutzarchitektur ist daher komplexer als die physische Position einer Festplatte.

Verschlüsselung ersetzt keine Datenschutzprüfung

Ein Unternehmen könnte rechtswidrig erhobene personenbezogene Daten perfekt verschlüsseln.

Sie bleiben dadurch nicht automatisch zulässig.

Umgekehrt verlangt eine rechtmäßige Verarbeitung angemessene Sicherheitsmaßnahmen.

Datenschutz
+
Cloud-Sicherheit

ergänzen sich.

Cloudanbieter sorgfältig auswählen

Bei einem wichtigen Dienst sollten mehr Kriterien betrachtet werden als:

Preis,

Speicherplatz,

schöne Oberfläche.

Sicherheitsrelevant sind beispielsweise:

Authentifizierungsoptionen,

MFA beziehungsweise Passkey-Unterstützung,

Rollenmodell,

Logging,

Exportmöglichkeiten,

Backup- und Versionierungsfunktionen,

Verschlüsselung,

Schlüsselmanagement,

Incident-Kommunikation,

Datenstandorte,

Zertifizierungen und Prüfberichte.

NIST empfiehlt bereits in seinen grundlegenden Public-Cloud-Leitlinien, Cloudservices risikobasiert auszuwählen und Verträge, Verantwortlichkeiten, Sicherheitskontrollen und Datenbehandlung vor einer Auslagerung zu beurteilen. (NIST)

Zertifikate sind hilfreich, aber keine Garantie

Ein Anbieter kann umfangreiche Sicherheitszertifizierungen besitzen.

Das ist ein positives Signal.

Es bedeutet dennoch nicht:

zertifiziert
↓
jede Kundenkonfiguration
automatisch sicher

Das Shared-Responsibility-Prinzip bleibt bestehen.

Der Provider kann seine Infrastruktur korrekt betreiben, während der Kunde sein Administratorkonto ohne MFA nutzt.

Drittanbieter sind Teil der Angriffsfläche

Cloudsysteme bestehen selten aus nur einem Anbieter.

Cloudplattform
↓
Backupdienst
↓
Monitoringdienst
↓
Identity Provider
↓
Supportanbieter

Jede zusätzliche Integration kann neue Berechtigungen und Abhängigkeiten schaffen.

CISA empfiehlt deshalb ausdrücklich, Sicherheitspraktiken von Drittanbietern und Managed Service Providern in die eigene Risikobetrachtung einzubeziehen und deren Berechtigungen nach Least Privilege zu gestalten. (cisa.gov)

Der Supportzugang ist ebenfalls ein Zugang

Ein externer Dienstleister sagt:

Wir brauchen für Wartung Administratorrechte.

Vielleicht stimmt das.

Dann sollte geklärt werden:

Welche Systeme?

Welche Rechte?

Wie lange?

Welche Person?

Wird der Zugriff protokolliert?

Kann er danach wieder entfernt werden?

„Der Dienstleister braucht Admin“ sollte kein ewiger Zustand sein.

Zeitlich begrenzte Rechte sind besser als dauerhafte Rechte

Cloudsysteme machen es technisch möglich, Privilegien nur bei Bedarf zu vergeben.

Konzeptionell:

normal:
kein Admin

Wartung:
Admin für begrenzte Zeit

danach:
wieder kein Admin

Je kürzer mächtige Berechtigungen existieren, desto kleiner das mögliche Missbrauchsfenster.

Was tun bei einem Cloud-Sicherheitsvorfall?

Ein kompromittiertes Cloudkonto unterscheidet sich von einem infizierten Einzelrechner.

Der Angreifer könnte bereits:

neue Accounts,

Tokens,

API-Schlüssel,

Freigaben,

Weiterleitungen,

Rollen

angelegt haben.

Nur das Passwort zu ändern kann deshalb unzureichend sein.

Ein möglicher Untersuchungsrahmen:

Konto kompromittiert
↓
aktive Sessions widerrufen
↓
Passwort / Authenticatoren sichern
↓
Tokens und API-Keys prüfen
↓
neue Benutzer prüfen
↓
Rollen prüfen
↓
Logs analysieren
↓
Datenzugriffe untersuchen
↓
Manipulationen rückgängig machen
↓
Einfallstor beseitigen

CISA betont bei Cloud-Identity-Sicherheit insbesondere die Bedeutung von Token-, Schlüssel- und Loggingkontrollen, weil Angriffe nicht nur klassische Passwörter betreffen. (cisa.gov)

API-Schlüssel bei Vorfällen nicht vergessen

Ein Angreifer meldet sich als Administrator an.

Dann erzeugt er:

neuen API-Key

Du bemerkst den Angriff und änderst:

Administratorpasswort

Der API-Key funktioniert möglicherweise weiterhin.

Deshalb muss Incident Response alle relevanten Authentifikatoren betrachten:

Passwörter
MFA
Sessions
Tokens
API-Keys
Zertifikate
Service Accounts

Cloudidentität besteht aus mehr als dem interaktiven Login.

Logs helfen, den Schaden zu bestimmen

Nach einem Vorfall muss unter anderem geklärt werden:

Welche Ressourcen wurden gelesen?

Welche Daten heruntergeladen?

Welche Rechte verändert?

Welche neuen Credentials erstellt?

Welche Backups gelöscht?

Logs
↓
Zeitlinie
↓
Ausmaß des Angriffs

Deshalb sollte Logging vor einem Vorfall eingerichtet werden.

Nachträglich lässt sich eine nicht aufgezeichnete Historie nicht rekonstruieren. CISA weist gerade bei Cloud-Identitätsangriffen darauf hin, dass eingeschränkte Telemetrie und kurze Logaufbewahrung die Erkennung und Untersuchung erheblich erschweren können. (cisa.gov)

Incident Response sollte Cloudzugänge berücksichtigen

Ein allgemeiner Notfallplan sollte daher nicht nur enthalten:

Server vom Netz trennen

sondern auch:

Cloudadministrator sperren

Sessions widerrufen

API-Schlüssel rotieren

Freigaben prüfen

Audit-Logs sichern

Backups schützen

Der Incident-Response-Plan muss zur tatsächlichen Infrastruktur passen.

Häufige Irrtümer über Cloud-Sicherheit

„Beim großen Cloudanbieter sind meine Daten automatisch sicher“

Der Anbieter kann viele Infrastrukturaufgaben hervorragend absichern. Benutzer, Berechtigungen, Datenfreigaben und Konfiguration bleiben je nach Servicemodell trotzdem teilweise oder weitgehend Kundensache. CISA empfiehlt deshalb ausdrücklich, das Shared-Responsibility-Modell zu verstehen. (cisa.gov)

„SaaS bedeutet, dass ich mich um Sicherheit gar nicht kümmern muss“

Nein. Konten, MFA, Rollen, externe Freigaben und viele Tenant-Einstellungen bleiben weiterhin relevant. CISAs SCuBA-Projekt existiert gerade deshalb, um sichere SaaS-Konfigurationen zu fördern. (cisa.gov)

„Cloud bedeutet automatisch Backup“

Nein. Synchronisierung, Hochverfügbarkeit und Backup sind unterschiedliche Dinge. CISA empfiehlt Cloudkunden ausdrücklich, eigene Backup- und Recovery-Strategien zu prüfen und nennt auch Cloud-to-Cloud-Backups. (cisa.gov)

„Mehrere Availability Zones sind mein Backup“

Sie verbessern Verfügbarkeit gegenüber bestimmten Infrastrukturfehlern, bewahren aber nicht automatisch einen früheren Datenzustand nach logischen Löschungen oder kompromittierten Administratoraktionen.

„Wenn Daten verschlüsselt sind, sind Berechtigungen egal“

Nein. Ein legitimer Benutzer beziehungsweise Dienst benötigt einen Weg zur Entschlüsselung. Ein Angreifer mit dessen Rechten kann deshalb unter Umständen ebenfalls auf Klartextdaten zugreifen.

„MFA reicht für komplette Cloud-Sicherheit“

MFA ist enorm wichtig, löst aber nicht Fehlkonfigurationen, überprivilegierte Rollen, gestohlene API-Keys, Datenfreigaben, fehlende Backups oder kompromittierte Endgeräte.

„Ein API-Key ist kein richtiges Passwort“

Aus Sicht der Berechtigung kann ein API-Key ein äußerst wertvolles Geheimnis sein. Cloud-Identity-Sicherheit umfasst deshalb auch Tokens, Schlüssel und Secrets. (cisa.gov)

„Wenn ich das Adminpasswort ändere, ist ein Angriff beendet“

Nicht zwangsläufig. Bestehende Sessions, Tokens, Service Accounts oder neu erzeugte API-Schlüssel können weitere Zugangspfade darstellen.

„Logs brauche ich erst, wenn etwas passiert“

Dann ist es zu spät. CISA empfiehlt Cloudlogging und Warnungen für ungewöhnliche Nutzung ausdrücklich als Präventions- und Ermittlungsgrundlage. (cisa.gov)

„Public Cloud bedeutet, dass meine Daten öffentlich sind“

Nein. „Public Cloud“ bezeichnet das Bereitstellungsmodell der Cloudinfrastruktur und nicht die Zugriffsrechte auf einzelne Kundendaten. NIST unterscheidet Public, Private, Community und Hybrid Cloud als Deployment-Modelle. (NIST Computer Security Resource Center)

„Private Cloud ist automatisch sicherer“

Nicht automatisch. Eine schlecht administrierte private Cloud kann weniger sicher sein als ein professionell betriebener Public-Cloud-Service. Entscheidend sind Architektur, Konfiguration, Betrieb und Bedrohungsmodell.

„Multi-Cloud beseitigt Anbieterabhängigkeit“

Sie kann sie reduzieren, schafft aber gleichzeitig zusätzliche Systeme, Identitäten und Komplexität.

„Cloudanbieter kümmert sich um Ransomware“

Der Provider schützt seine Infrastruktur. Ein kompromittierter Kundenaccount kann trotzdem Daten über legitime Cloudfunktionen löschen oder verändern. CISA empfiehlt deshalb Versionierung, Löschschutz, Backups und geeignete Berechtigungskontrollen ausdrücklich auf Kundenseite. (cisa.gov)

Ein praktischer Cloud-Sicherheitsplan

Für kleine und mittlere Umgebungen muss Cloud-Sicherheit nicht mit hunderten Kontrollen beginnen. Eine sinnvolle Reihenfolge ist:

1. Inventar erstellen: Welche Cloud- und SaaS-Dienste existieren überhaupt, wem gehören sie und welche Daten liegen darin?
2. Adminzugänge absichern: Einzigartige Zugangsdaten, MFA beziehungsweise möglichst phishing-resistente Authentifizierung, getrennte Administratorkonten und sichere Recovery-Wege.
3. Berechtigungen reduzieren: Jeder Mensch und jeder Dienst erhält nur die Rechte, die er benötigt.
4. Öffentliche Freigaben prüfen: Speicher, Datenbanken, Adminoberflächen und Netzwerkdienste nur öffentlich machen, wenn es tatsächlich erforderlich ist.
5. API-Keys und Secrets inventarisieren: Wissen, welche maschinellen Zugangsdaten existieren, wo sie liegen und wie sie ersetzt werden.
6. Logging aktivieren: Besonders Administrations-, Identitäts- und Datenzugriffsereignisse nachvollziehbar speichern und kritische Änderungen alarmieren.
7. Backup und Recovery definieren: Nicht auf Synchronisierung oder Providerredundanz verlassen; Versionierung, getrennte Backups und Schutz vor Löschen prüfen.
8. Restore testen: Wissen, wie Daten und Anwendungen tatsächlich zurückkommen.
9. Konfiguration regelmäßig kontrollieren: Cloudumgebungen verändern sich schnell; sicherer Zustand muss kontinuierlich überprüft werden.
10. Incident Response vorbereiten: Verfahren für gestohlene Accounts, Tokens, API-Keys, Datenabfluss und kompromittierte Ressourcen festlegen.

Diese Schwerpunkte decken sich mit aktuellen CISA-Empfehlungen für Cloudressourcen, darunter Shared Responsibility, Least Privilege, Backups, Logging, Alarmierung, Löschschutz und API-Sicherheit. (cisa.gov)

Für kleine Unternehmen ist Identität oft wichtiger als komplizierte Netzwerktechnik

Wer nur einige SaaS-Systeme betreibt, braucht vielleicht keine komplexe Cloud-Firewallarchitektur.

Aber fast immer braucht er:

MFA
+
saubere Rollen
+
Offboarding
+
Backup
+
Logging

Ein kompromittiertes zentrales Cloudkonto kann sonst gleichzeitig Zugriff auf:

Mail,

Dokumente,

Kalender,

Kundeninformationen,

Backups

ermöglichen.

Für selbst betriebene Server kommen weitere Ebenen hinzu

Bei IaaS beziehungsweise eigenen Cloudservern:

Cloudkontosicherheit
+
Serverhärtung
+
Firewall
+
Updates
+
Anwendungssicherheit
+
Backup
+
Monitoring

Das Shared-Responsibility-Modell verschiebt also mehr Arbeit in Richtung Kunde. NIST definiert IaaS genau als Modell, bei dem der Kunde unter anderem Kontrolle über Betriebssysteme, Speicher und bereitgestellte Anwendungen besitzt, während die zugrunde liegende physische Cloudinfrastruktur beim Anbieter bleibt. (NIST Computer Security Resource Center)

Das Cloudkonto selbst gehört ins Backup-Konzept

Eine subtile Frage lautet:

Was passiert, wenn nicht die Daten, sondern das gesamte Cloudkonto verloren geht?

Beispielsweise durch:

Fehlkonfiguration,

Kontosperre,

administrativen Fehler,

erfolgreichen Angriff.

Wenn Produktivsystem und einzige Sicherung vollständig vom selben Konto und denselben Administratorrechten abhängen, entsteht ein gemeinsamer Fehlerbereich.

Cloudkonto verloren
↓
Produktivdaten weg
+
Backup ebenfalls unerreichbar

Eine robuste Recovery-Strategie betrachtet deshalb auch die administrative Trennung.

Ein Backup muss außerhalb des Angriffswegs liegen

Das muss nicht zwingend bedeuten:

andere Cloud

Es bedeutet:

Der normale Angriffsweg auf das Produktionssystem darf nicht automatisch sämtliche Recovery-Kopien zerstören können.

Das kann erreicht werden durch geeignete Kombinationen aus:

separaten Accounts,

unveränderbaren Backups,

Offlinekopien,

Löschschutz,

getrennten Berechtigungen.

CISA empfiehlt genau diese Schutzmechanismen im Ransomware-Kontext. (cisa.gov)

Die Cloud kann Sicherheit sogar vereinfachen

Cloudplattformen machen einige Dinge leichter:

zentrale Identitätsverwaltung,

automatische Updates bei SaaS,

zentrale Audit-Logs,

standardisierte Rollen,

automatische Verschlüsselung,

Versionierung,

geografische Redundanz,

Sicherheitswarnungen.

Diese Funktionen müssen allerdings:

aktiviert
+
richtig konfiguriert
+
überwacht

werden.

Sicherheit entsteht nicht durch das Vorhandensein einer Funktion.

Sondern durch ihren richtigen Einsatz.

Die Cloud kann Sicherheit gleichzeitig komplexer machen

Ein physischer Server hatte vielleicht:

einen Administrator,

eine Firewall,

eine Festplatte.

Eine Cloudumgebung besitzt möglicherweise:

Benutzer
Rollen
Gruppen
Service Accounts
Tokens
API-Keys
Policies
Buckets
Objekte
Snapshots
Regionen
Netzwerke
Security Groups
Serverless Functions
APIs

Die Möglichkeiten steigen.

Damit steigt auch die Gefahr, dass niemand mehr den vollständigen Zustand versteht.

Deshalb sind:

Inventar,

Standards,

Automatisierung,

Dokumentation

so wichtig.

Security by Default ist besonders wertvoll

Ein guter Cloudservice sollte möglichst sichere Grundeinstellungen besitzen.

CISA verfolgt mit seinem Secure by Design-Ansatz generell das Ziel, dass Anbieter Sicherheitsfunktionen nicht unnötig auf den Kunden abschieben und sichere Standardeinstellungen fördern. Auch in Cloudumgebungen reduziert jede sichere Voreinstellung die Wahrscheinlichkeit, dass ein Nutzer durch eine übersehene Checkbox eine kritische Schwachstelle erzeugt. (cisa.gov)

Trotzdem sollte der Kunde den Ist-Zustand kennen.

Das vollständige Cloud-Sicherheitsmodell

Alle bisherigen Themen dieses Wissensblocks laufen hier zusammen:

Identität
↓
Wer bist du?

Authentifizierung
↓
Wie beweist du das?

Autorisierung
↓
Was darfst du?

Konfiguration
↓
Welche Ressourcen sind erreichbar?

Verschlüsselung
↓
Wie werden Daten geschützt?

Logging
↓
Was ist passiert?

Backup
↓
Wie kommen Daten zurück?

Incident Response
↓
Was tun wir bei einem Angriff?

Datenschutz
↓
Dürfen und sollen wir
diese Daten überhaupt verarbeiten?

Cloud-Sicherheit ist damit kein einzelnes Produkt.

Sie ist die Verbindung dieser Ebenen.

Was du dir über Shared Responsibility merken solltest

Der wichtigste Cloudgrundsatz lautet:

Cloudanbieter
≠
allein verantwortlich

und ebenso:

Cloudkunde
≠
für alles verantwortlich

Die Grenze hängt vom Servicemodell ab.

Bei SaaS übernimmt der Anbieter sehr viele technische Ebenen.

Bei IaaS verwaltet der Kunde wesentlich mehr selbst.

NIST unterscheidet genau deshalb SaaS, PaaS und IaaS als verschiedene Servicemodelle. (NIST Computer Security Resource Center)

Was du dir über Cloudidentitäten merken solltest

In der Cloud ist ein mächtiges Benutzerkonto häufig wertvoller als der Zugriff auf einen einzelnen Server.

Administrator
↓
kontrolliert Ressourcen

Deshalb gehören:

MFA,

Least Privilege,

getrennte Administrationskonten,

sauberes Offboarding

an den Anfang jedes Sicherheitskonzepts.

Auch maschinelle Identitäten wie Tokens, Schlüssel und Service Accounts müssen gleichwertig behandelt werden. CISA nennt Identität, Token- und Schlüsselmanagement ausdrücklich als zentrale aktuelle Cloud-Sicherheitsfelder. (cisa.gov)

Was du dir über Backups merken solltest

Cloudspeicher ist kein Synonym für Backup.

Cloud-Synchronisierung
≠
Backup

Redundanz
≠
Backup

Versionierung
≠
vollständiges Backup

Ein belastbarer Recovery-Plan verwendet diese Funktionen sinnvoll zusammen und schützt zumindest einen Wiederherstellungsweg gegen dieselben Berechtigungen und Angriffe, die das Produktivsystem beschädigen könnten. CISA empfiehlt dafür unter anderem Cloud-to-Cloud-Backup, Versionierung, Delete Protection und Object Lock. (cisa.gov)

Was du dir über Verschlüsselung merken solltest

Verschlüsselung ist wichtig.

Aber:

Verschlüsselung
≠
Berechtigungsmanagement

Ein legitimer Dienst muss Daten verwenden können.

Hat ein Angreifer die legitime Benutzer- oder Administratoridentität übernommen, kann er möglicherweise ebenfalls Zugriff bekommen.

Darum gehören zusammen:

Verschlüsselung
+
Identität
+
Berechtigungen
+
Schlüsselmanagement

Was du dir über Logging merken solltest

Cloudsysteme können sich innerhalb von Minuten verändern.

Ohne nachvollziehbare Ereignisse ist später möglicherweise nicht mehr feststellbar:

wer einen Benutzer angelegt,

wer eine Datei geteilt,

wer eine Firewall verändert

oder wer ein Backup gelöscht hat.

CISA empfiehlt deshalb umfassendes Cloudlogging und Alarmierung bei ungewöhnlicher Nutzung. (cisa.gov)

Was du dir über Cloud-Sicherheit insgesamt merken solltest

Die Frage lautet nicht:

Ist die Cloud sicher?

Genauso wenig wie man sinnvoll fragen kann:

Ist ein Server sicher?

Die richtige Frage lautet:

Wie ist diese konkrete Cloudumgebung aufgebaut, wer trägt welche Verantwortung, welche Identitäten und Berechtigungen existieren und wie sind Daten, Administration und Wiederherstellung geschützt?

Das zentrale Modell lautet:

sichere Cloud
=
sicherer Anbieter
+
sichere Konfiguration
+
starke Identitäten
+
minimale Berechtigungen
+
geschützte Daten
+
Logging
+
funktionierendes Backup
+
vorbereitete Wiederherstellung

Ein großer professioneller Cloudanbieter kann viele Sicherheitsprobleme sehr gut lösen.

Er kann aber nicht wissen, dass:

Mitarbeiter X
diesen Ordner
nicht öffentlich teilen sollte

oder:

dieser API-Key
nicht mehr gebraucht wird

oder:

dieses Administratorrecht
viel zu weit gefasst ist

Genau darin liegt der Kern von Shared Responsibility.

Der zentrale Merksatz lautet:

Cloud-Sicherheit entsteht nicht dadurch, dass Daten „in der Cloud“ liegen. Sie entsteht dadurch, dass Anbieter und Kunde ihre jeweiligen Aufgaben richtig erfüllen. Der Provider kann die Infrastruktur schützen, während der Kunde Identitäten, Berechtigungen, Konfigurationen, Daten, Backups und Anwendungen kontrolliert. Je stärker diese Verantwortungsgrenzen verstanden, Zugriffe minimiert, Administrationsvorgänge protokolliert und unabhängige Recovery-Wege geplant werden, desto weniger entscheidend ist am Ende die Frage, ob ein System im eigenen Keller oder in einem Rechenzentrum eines Cloudanbieters läuft.