Cloud-Fehlkonfigurationen in Azure vermeiden
Das Wichtigste in Kürze
- Die häufigste Azure-Schwachstelle sind zu weitreichende Berechtigungen — dauerhaft vergebene Owner-Rollen auf Subscription-Ebene sind ein erhebliches Risiko
- Fehlende Netzwerksegmentierung erlaubt Angreifern nach einem initialen Zugang laterale Bewegung durch die gesamte Umgebung
- Öffentlich zugängliche Storage Accounts und Blob-Container ohne Authentifizierung sind vermeidbare, aber regelmäßig anzutreffende Befunde
- Ohne Azure Activity Logs in einem SIEM und aktivierte Diagnostic Settings bleiben Angriffe oft wochenlang unbemerkt
- Veraltete Conditional-Access-Richtlinien und aktive Legacy-Authentifizierungsprotokolle sind typische Einfallstore, die im Assessment als Erstes geprüft werden
Die meisten Sicherheitsvorfälle in Cloud-Umgebungen gehen nicht auf ausgeklügelte Angriffe zurück, sondern auf Fehlkonfigurationen. In Azure-Umgebungen finden wir bei Security Assessments regelmäßig dieselben Schwachstellen. Die gute Nachricht: Die meisten lassen sich mit überschaubarem Aufwand beheben.
Zu weitreichende Berechtigungen
Das häufigste Problem, das wir in Azure-Umgebungen antreffen, sind zu weitreichende Berechtigungen. Nutzer und Anwendungen verfügen über mehr Rechte, als sie für ihre Aufgabe benötigen. Besonders kritisch sind dauerhafte Contributor- oder Owner-Rollen auf Subscription-Ebene, die nicht regelmäßig überprüft werden.
Das Risiko: Wird ein Konto mit zu weitreichenden Rechten kompromittiert, kann ein Angreifer auf die gesamte Umgebung zugreifen. Die Lösung ist die konsequente Anwendung des Least-Privilege-Prinzips: Berechtigungen werden nur so weitreichend wie nötig und idealerweise zeitlich begrenzt über Privileged Identity Management (PIM) vergeben.
Fehlende Netzwerksegmentierung
Viele Azure-Umgebungen wachsen organisch, ohne dass eine Netzwerksegmentierung geplant wird. Virtuelle Netzwerke sind flach strukturiert, Ressourcen können uneingeschränkt miteinander kommunizieren, und Network Security Groups (NSGs) sind entweder zu permissiv oder gar nicht konfiguriert.
Das Risiko: Ein Angreifer, der Zugang zu einer Ressource erlangt, kann sich lateral durch die gesamte Umgebung bewegen. Die Lösung beginnt mit einer sauberen Netzwerkarchitektur: Trennung von Workloads in eigene Subnetze, restriktive NSG-Regeln und wo möglich der Einsatz von Azure Private Endpoints, um Dienste vom öffentlichen Internet zu isolieren.
Ungeschützte Storage Accounts
Azure Storage Accounts mit öffentlichem Zugriff oder ohne Verschlüsselung sind ein wiederkehrender Befund. Teilweise sind Blob-Container so konfiguriert, dass sie ohne Authentifizierung aus dem Internet erreichbar sind.
Das Risiko ist offensichtlich: sensible Daten werden unbeabsichtigt öffentlich zugänglich. Die Behebung ist einfach: öffentlichen Zugriff deaktivieren, Verschlüsselung aktivieren und den Zugriff über Managed Identities oder SAS-Tokens mit begrenzter Gültigkeit steuern.
Fehlendes Logging und Monitoring
Ohne eine zentrale Protokollierung und Überwachung bleiben Sicherheitsvorfälle unbemerkt. Viele Azure-Umgebungen haben weder Azure Activity Logs in ein SIEM integriert noch Diagnostic Settings für kritische Ressourcen aktiviert.
Das Risiko: Angriffe werden erst bemerkt, wenn der Schaden bereits eingetreten ist. Die Lösung: Activity Logs, Sign-in Logs und Diagnostic Settings zentral in einen Log Analytics Workspace oder Microsoft Sentinel einbinden und Alerts für sicherheitsrelevante Ereignisse konfigurieren.
Veraltete Conditional-Access-Policies
Conditional-Access-Policies werden häufig einmalig eingerichtet und dann nicht mehr angepasst. Neue Anwendungen, veränderte Arbeitsweisen (etwa Homeoffice) oder neue Bedrohungsszenarien werden nicht berücksichtigt. Besonders kritisch: Legacy-Authentifizierungsprotokolle, die Conditional Access umgehen können, sind immer noch aktiviert.
Handlungsempfehlung
Diese fünf Punkte prüfen wir in jedem Security Assessment als Erstes. Wenn Sie unsicher sind, wie Ihre Azure-Umgebung in diesen Bereichen aufgestellt ist, bietet ein gezieltes Assessment eine klare Grundlage für priorisierte Verbesserungen.
Haeufig gestellte Fragen
Welche Azure-Fehlkonfiguration ist in der Praxis am gefährlichsten?
Zu weitreichende Berechtigungen auf Subscription-Ebene sind das häufigste und gefährlichste Problem. Wird ein Konto mit dauerhafter Owner- oder Contributor-Rolle kompromittiert, hat der Angreifer vollen Zugriff auf alle Ressourcen. Privileged Identity Management (PIM) löst dieses Problem durch zeitlich begrenzte, beantragte Rechtevergabe.
Reicht es aus, Network Security Groups (NSGs) einmal zu konfigurieren und dann zu belassen?
Nein. NSG-Regeln veralten schnell, weil Umgebungen wachsen und sich ändern. Neue Dienste, neue Teams und geänderte Arbeitsweisen führen dazu, dass Ausnahmen entstehen und sich mit der Zeit ansammeln. Eine regelmäßige Überprüfung — mindestens halbjährlich — ist notwendig.
Wie erkenne ich, ob meine Azure Activity Logs tatsächlich ausgewertet werden?
Prüfen Sie, ob Ihre Logs in einen Log Analytics Workspace oder Microsoft Sentinel fließen und ob dort aktive Alert-Regeln für sicherheitsrelevante Ereignisse konfiguriert sind. Logs, die zwar erfasst, aber nicht ausgewertet werden, bringen keinen Sicherheitsgewinn.
Was ist bei Storage Accounts das konkrete Risiko öffentlichen Zugriffs?
Blob-Container mit aktiviertem Public Access sind ohne Authentifizierung aus dem Internet lesbar. Das betrifft Backups, Exporte, Log-Dateien und Anwendungsdaten — oft unbeabsichtigt. Ein einziger vergessener Container kann vertrauliche Unternehmensdaten offenlegen.