Cloud Red Teaming: Wenn die Identität zum Perimeter wird

Der Perimeter, den Firewalls einst schützten, existiert in den meisten Unternehmen nicht mehr. Postfächer liegen in Microsoft 365, Workloads in AWS oder Azure, Identitäten in Entra ID, und Mitarbeitende melden sich von überall an. Die Verteidigung hat sich darauf einzustellen: Der entscheidende Kontrollpunkt ist nicht mehr die Netzwerkgrenze, sondern die Identität und die Rechte, die an ihr hängen.

Die Zahlen zeigen, wie stark sich der Schwerpunkt verschoben hat. CrowdStrike verzeichnet im Global Threat Report 2026 einen Anstieg staatsnaher Cloud-Intrusions um 266 Prozent. Im selben Report heißt es, dass 82 Prozent der Erkennungen malware-frei waren: Die Aktivität findet mit gültigen Zugangsdaten und über legitime Funktionen der Plattformen statt. Laut Verizon DBIR 2025 war der Missbrauch von Zugangsdaten mit 22 Prozent einer der häufigsten Wege zum Erstzugriff.

Dieser Beitrag beschreibt aus Verteidigungssicht, warum Identität der neue Perimeter ist, welche Schwachstellen in Entra ID, Microsoft 365, AWS und Azure immer wieder auftreten, wie ein Red Team Cloud und On-Premises in einem Einsatz zusammen betrachtet und welche Härtungsmaßnahmen die größte Wirkung haben. Am Ende steht eine Checkliste. Operative Angriffsdetails bleiben außen vor; sie gehören in einen autorisierten Test, nicht in einen öffentlichen Artikel.

Identität als neuer Perimeter

In der klassischen Architektur entschied die Netzwerkgrenze darüber, wer hineindurfte. Innen galt man als vertrauenswürdig. In einer Cloud-Umgebung gibt es dieses Innen nicht mehr: Jeder Zugriff kommt aus dem Internet, und was ihn legitimiert, ist eine Identität plus ein Nachweis, meist ein Token. Damit wird die Identitäts- und Zugriffsverwaltung zur wichtigsten Sicherheitskontrolle überhaupt. Wer eine gültige Identität mit weitreichenden Rechten übernimmt, braucht keinen Einbruch mehr.

Das ist der Kern des Zero-Trust-Gedankens: Kein Zugriff gilt als vertrauenswürdig, nur weil er aus einem bestimmten Netz kommt. Jeder Zugriff wird geprüft, abhängig von Identität, Gerätezustand, Standort und Risiko. Die Verteidigung verlagert sich damit von der Netzwerkgrenze auf die Frage, wer was unter welchen Bedingungen tun darf. Genau diese Frage prüfen wir in einem Cloud-fokussierten Red Teaming.

Diese Verlagerung hat Folgen für die Erkennung. In einem lokalen Netz zeigt sich ein Angreifer durch ungewöhnlichen Datenverkehr oder verdächtige Prozesse auf Endgeräten. In der Cloud sieht ein kompromittierter Zugriff zunächst aus wie jede andere legitime Anmeldung: dieselben Protokolle, dieselben Programmierschnittstellen, dieselben Dienste. Die entscheidenden Signale liegen deshalb nicht im Netzwerkverkehr, sondern in den Anmelde- und Audit-Protokollen der Plattformen: eine Anmeldung aus einem untypischen Land, ein Token, das von einem neuen Gerät verwendet wird, eine Anwendung, die plötzlich auf alle Postfächer zugreift. Wer diese Protokolle nicht zentral auswertet, ist in der Cloud weitgehend blind, auch wenn die lokale Erkennung ausgereift ist. Die Verteidigung muss ihre Sensorik dorthin verlegen, wo die Identität verwaltet wird.

Wiederkehrende Schwachstellen in der Cloud

Über alle Plattformen hinweg finden wir immer wieder dieselben fünf Schwachstellenklassen. Sie sind keine Produktfehler, sondern Folgen von Konfiguration und Betrieb.

• Diebstahl und Wiederverwendung von Tokens: Nach einer erfolgreichen Anmeldung stellt die Plattform ein Sitzungstoken aus. Gelangt dieses Token in falsche Hände, etwa über eine kompromittierte Arbeitsstation, kann es die Mehrfaktor-Authentifizierung umgehen, weil die Anmeldung bereits stattgefunden hat. Kurze Token-Lebensdauer und Bindung an Gerät und Sitzung begrenzen den Schaden.
• Consent-Phishing: Statt ein Passwort zu stehlen, bringt der Angreifer eine Nutzerin dazu, einer bösartigen Anwendung Zugriff auf ihr Postfach oder ihre Dateien zu gewähren. Die Zustimmung ist technisch legitim, deshalb fällt sie selten auf. Schutz bietet, Zustimmung zu Anwendungen durch Administratoren genehmigen zu lassen statt sie jeder Person freizustellen.
• Überprivilegierte Rollen: Konten und Anwendungen tragen Rechte, die sie nie brauchen, oft aus der Einführungsphase, als Berechtigungen großzügig vergeben wurden. Jede ungenutzte Berechtigung ist ein Angriffsweg. Das Prinzip Least Privilege und regelmäßige Rezertifizierung reduzieren die Angriffsfläche erheblich.
• Fehlendes oder lückenhaftes Conditional Access: Conditional Access entscheidet, unter welchen Bedingungen ein Zugriff erlaubt wird. Fehlen Regeln oder gibt es breite Ausnahmen, etwa für Altprotokolle oder Dienstkonten, entsteht eine Lücke, durch die auch ein gestohlenes Token funktioniert.
• Exponierte Schlüssel und Geheimnisse: Zugriffsschlüssel in Code-Repositories, in Container-Images, in Konfigurationsdateien oder in versehentlich öffentlichen Speicherbereichen. Sie sind der häufigste Einstieg in Cloud-Infrastruktur. Secrets-Management, automatische Rotation und das Scannen von Repositories sind die Gegenmittel.

Auffällig ist, dass keine dieser Klassen eine Sicherheitslücke im klassischen Sinn ist. Es sind Konfigurations- und Betriebsentscheidungen, die sich ohne Softwareänderung korrigieren lassen, sobald man sie kennt.

Plattformspezifische Schwerpunkte

Die genannten Klassen äußern sich auf jeder Plattform etwas anders. Die folgende Übersicht nennt den jeweiligen Schwerpunkt aus Verteidigungssicht.

Warum Red Teams Cloud und On-Premises zusammen betrachten

Die gefährlichsten Wege verlaufen nicht innerhalb einer Plattform, sondern zwischen Welten. Fast jedes Unternehmen betreibt ein hybrides Setup: Das lokale Active Directory ist mit Entra ID synchronisiert, Anmeldungen gelten in beiden Welten, Verwaltungswerkzeuge greifen über die Grenze. Das schafft Abhängigkeiten, die sich isoliert betrachtet nicht erkennen lassen.

Ein lokal kompromittiertes Konto kann unter Umständen Cloud-Rechte erben, und eine übernommene Cloud-Identität kann auf lokale Ressourcen zurückwirken, etwa über synchronisierte Verwaltungskonten oder Hybrid-Komponenten. Wer nur die Cloud prüft oder nur das lokale Netz, übersieht genau die Brücken, die ein realer Angreifer sucht. Deshalb betrachten wir in unserer Leistung Active Directory & Cloud beide Welten in einem Einsatz und bilden den vollständigen Weg ab, so wie ihn ein Angreifer gehen würde, von der ersten Identität bis zum Ziel. Die lokalen Schwachstellen, die dabei regelmäßig auftauchen, haben wir im Beitrag Active Directory: typische Fehler beschrieben.

Der typische Einstieg bleibt dabei die Identität einer Person, oft über Phishing oder Vishing. Von dort stellt sich die Frage, die jeder Einsatz beantwortet: Wie weit kommt diese eine Identität, und bemerkt es jemand? Die Erkennung in der Cloud prüfen wir dabei genauso wie On-Premises, idealerweise im Zusammenspiel mit Purple Teaming.

Härtungs-Checkliste für Cloud-Identitäten

1. Sind privilegierte Rollen zeitlich begrenzt vergeben (Just-in-Time) statt dauerhaft, und wird jede Aktivierung protokolliert?
2. Nutzen alle privilegierten Konten phishing-resistente Verfahren wie FIDO2 statt Push oder SMS?
3. Ist Legacy-Authentifizierung ohne moderne Prüfung vollständig abgeschaltet?
4. Greift Conditional Access ohne pauschale Ausnahmen, und werden Ausnahmen regelmäßig überprüft?
5. Muss die Zustimmung zu neuen Anwendungen durch Administratoren erfolgen, statt jeder Person freizustehen?
6. Werden statische Zugriffsschlüssel durch kurzlebige Anmeldungen ersetzt, und scannen Sie Repositories und Images auf Geheimnisse?
7. Sind Rollen und Berechtigungen nach dem Prinzip Least Privilege vergeben und werden sie mindestens halbjährlich rezertifiziert?
8. Lösen neue Postfach-Weiterleitungen, Posteingangsregeln und Anwendungsberechtigungen einen Alarm aus?
9. Werden Anmelde- und Audit-Protokolle der Cloud zentral ausgewertet und mit der lokalen Erkennung zusammengeführt?
10. Haben Sie die Abhängigkeiten zwischen lokalem Active Directory und Entra ID dokumentiert und geprüft, welche Konten über die Grenze hinweg wirken?

Wer die Mehrheit dieser Punkte nicht sicher bejahen kann, hat Angriffswege offen, die heute bevorzugt genutzt werden. Die gute Nachricht: Fast alle Maßnahmen sind Konfiguration, kein Produktkauf.

Fazit

Identität ist der neue Perimeter, und die Verteidigung muss ihr folgen. Die wiederkehrenden Schwachstellen in Entra ID, Microsoft 365, AWS und Azure sind keine Softwarefehler, sondern Konfigurations- und Betriebsentscheidungen, die sich korrigieren lassen, sobald man sie kennt. Der stärkste Hebel ist, Rechte zu reduzieren und Zugriffe an Bedingungen zu knüpfen. Weil reale Angriffe die Brücken zwischen Cloud und lokalem Netz suchen, lohnt sich eine Prüfung, die beide Welten zusammen betrachtet. Wie wir das aufsetzen, zeigt unsere Leistung Active Directory & Cloud; für ein erstes Gespräch erreichen Sie uns über Kontakt.

Quellen

• CrowdStrike, Global Threat Report 2026: staatsnahe Cloud-Intrusions +266 %; 82 % malware-freie Erkennungen.
• Verizon, Data Breach Investigations Report 2025: Missbrauch von Zugangsdaten als Erstzugriff bei 22 % der Breaches.
• MITRE ATT&CK for Cloud (Enterprise-Matrix), attack.mitre.org.

Häufige Fragen zum Thema