Cloud-Sicherheit wird noch immer zu oft wie klassische Rechenzentrums-Sicherheit gedacht. Unternehmen sprechen über Firewalls, offene Ports und Netzwerksegmente – während Angreifer längst über Identitäten, Tokens, Service Principals und falsch vergebene Rollen in Cloud-Umgebungen einsteigen. 2026 ist die wichtigste Sicherheitsgrenze nicht mehr nur das Netzwerk. Sie ist die Berechtigung.
Warum Identitäten im Cloud-Zeitalter so kritisch sind
Ein gültiges Cloud-Konto oder ein kompromittierter Service Principal kann sich innerhalb erlaubter APIs bewegen, ohne dass klassische Perimeter-Kontrollen Alarm schlagen. Wenn eine Identität weitreichende Rollen besitzt, kann ein Angreifer Ressourcen auflisten, Secrets auslesen, Daten verschieben oder Infrastruktur verändern – alles über legitime Management-Schnittstellen.
Deshalb muss Identity Security mit derselben Disziplin betrieben werden wie Netzwerk-Security: starke MFA, Conditional Access, getrennte Admin-Konten, kurze Token-Laufzeiten, regelmäßige Rezertifizierung von Rollen und konsequentes Least Privilege.
Service Principals sind Maschinenkonten mit echter Macht
Service Principals, Managed Identities und API-Credentials ermöglichen Automatisierung. Genau deshalb werden sie häufig sehr weitreichend berechtigt und anschließend jahrelang nicht überprüft. Ein altes Secret in einer Pipeline oder ein kompromittiertes Zertifikat kann damit denselben Effekt haben wie ein privilegiertes Benutzerkonto.
Unternehmen sollten für jede nicht-menschliche Identität beantworten können: Wer ist Owner? Welche Ressource braucht diese Identität wirklich? Wann wurde die Berechtigung zuletzt überprüft? Wo liegen Secrets oder Zertifikate? Und wie wird ungewöhnliche Nutzung erkannt? Ohne diese Informationen entsteht unsichtbare Dauerberechtigung.
Backups müssen einen Cloud-Angriff überleben
Ein Backup ist nur dann ein Sicherheitsmechanismus, wenn der Angreifer es nicht mit denselben Zugangsdaten löschen kann wie die Produktivsysteme. Deshalb werden getrennte Backup-Berechtigungen, Soft Delete, Immutable-Mechanismen, getrennte Recovery-Accounts und regelmäßige Restore-Tests immer wichtiger.
Besonders gefährlich sind destruktive Cloud-Angriffe, bei denen virtuelle Maschinen, Ressourcen, Snapshots oder Backups gezielt entfernt werden. Eine gute Architektur geht davon aus, dass ein privilegiertes Produktionskonto kompromittiert werden kann – und baut die Wiederherstellung so, dass sie trotzdem möglich bleibt.
Logging: Cloud-Aktivität muss zusammengeführt werden
Cloud-Angriffe verteilen sich über Identity Provider, Management Plane, Storage, DevOps, SaaS und Endgeräte. Einzelne Logs wirken oft harmlos. Erst in der Korrelation wird sichtbar, dass ein Service Principal plötzlich hunderte Ressourcen enumeriert, ein Admin-Token aus einer ungewöhnlichen Region verwendet wird oder kurz vor einer Datenübertragung Rollen verändert wurden.
Daher sollten Identity Logs, Azure/AWS/GCP Activity Logs, EDR/XDR, DevOps-Auditdaten und relevante SaaS-Protokolle zentral korreliert werden. Moderne Security Operations brauchen Kontext über mehrere Plattformen hinweg.
Die fünf Fragen für jede Cloud-Architektur
Wer darf was? Wie wird starke Authentifizierung erzwungen? Wie erkennen wir missbräuchliche legitime Zugriffe? Kann ein kompromittiertes Konto auch unsere Backups zerstören? Wie schnell können wir kritische Ressourcen aus einer sauberen Quelle wiederherstellen? Wer diese fünf Fragen belastbar beantworten kann, ist weiter als viele Unternehmen mit einer langen Liste einzelner Security-Produkte.
Fazit
Cloud Security 2026 bedeutet, Identitäten, Automatisierung und Wiederherstellung als zusammenhängendes System zu betrachten. Firewalls bleiben wichtig, aber sie schützen nicht vor einem gültigen Token mit zu vielen Rechten. Eine starke Cloud-Architektur begrenzt Berechtigungen, überwacht Identitäten, schützt Backups unabhängig vom Produktionskonto und testet Wiederherstellung regelmäßig.
Quellen und weiterführende Hinweise
Microsoft Security Research: Storm-3168: Agentic-driven cloud attacks using compromised service principals.
Microsoft Security: Beyond source code: A path to the keys to the kingdom.