Fehlkonfigurationen in Azure finden, verhindern und belegen

Eine Azure-Umgebung, die läuft, ist noch keine, die sicher konfiguriert ist. Viele Umgebungen wachsen über Jahre, Projekt für Projekt, und niemand hat den Gesamtzustand im Blick. Für die Geschäftsführung ist das ein Haftungsthema: Ob eine Fehlkonfiguration zu einem Vorfall führt, lässt sich vorher nicht sagen, wohl aber, ob sie bekannt war und bearbeitet wurde. Dieser Beitrag zeigt, welche Punkte wir zuerst prüfen und wie Sie sie mit Microsoft-Werkzeugen dauerhaft unter Kontrolle bringen.

Wie finden Sie Fehlkonfigurationen in Azure systematisch?

Mit Microsoft Defender for Cloud. Bereits die kostenfreie Stufe Foundational CSPM bewertet alle Ressourcen einer Subscription gegen den Microsoft Cloud Security Benchmark, gibt konkrete Empfehlungen und verdichtet das Ergebnis zum Secure Score. Für die Geschäftsführung ist der Score ein Verlaufswert: Er zeigt, ob sich die Lage verbessert. Für die IT sind die Empfehlungen die Arbeitsliste, sortiert nach betroffenen Ressourcen und Schweregrad. Erweiterte Funktionen wie Angriffspfadanalyse oder zusätzliche Standards im Compliance-Dashboard setzen den kostenpflichtigen Plan Defender CSPM voraus.

Lesen Sie den Score als Trend. Ein einzelner Wert sagt nichts darüber, ob die verbleibenden Befunde die kritischen sind.

Welche Fehlkonfigurationen prüfen wir zuerst?

Zu weitreichende Berechtigungen

Wer dauerhaft Owner- oder Contributor-Rechte auf Subscription-Ebene hat, kann im Fall einer Kompromittierung die gesamte Umgebung verändern oder löschen. Die Lösung ist das Least-Privilege-Prinzip: Rechte nur so weit wie nötig und für privilegierte Rollen zeitlich begrenzt über Privileged Identity Management (PIM) für Azure-Ressourcen. Defender for Cloud weist auf Subscriptions mit zu vielen Ownern und auf privilegierte Konten ohne MFA hin.

Fehlende Netzwerksegmentierung

In flachen virtuellen Netzwerken kann jede Ressource jede andere erreichen. Gelangt ein Angreifer auf eine Ressource, kann er sich seitlich durch die Umgebung bewegen. Abhilfe schaffen getrennte Subnetze je Workload, restriktive Network Security Groups (NSGs, also Regelsätze für den Netzwerkverkehr) und Private Endpoints, die PaaS-Dienste vom öffentlichen Internet trennen.

Öffentlich erreichbare Storage Accounts

Blob-Container mit anonymem Lesezugriff machen Daten ohne Anmeldung aus dem Internet lesbar, oft unbeabsichtigt. Azure Storage verschlüsselt Daten im Ruhezustand standardmäßig; das Risiko liegt in der Zugriffskonfiguration. Deaktivieren Sie anonymen Zugriff auf Ebene des Storage Accounts, bevorzugen Sie Managed Identities statt Kontoschlüsseln und vergeben Sie SAS-Token nur mit kurzer Gültigkeit.

Fehlende Protokollierung

Ohne Diagnoseeinstellungen fehlen die Daten, um einen Vorfall zu erkennen und später zu rekonstruieren. Activity Log, Entra-Anmeldeprotokolle und Ressourcenprotokolle gehören zentral in einen Log Analytics Workspace oder nach Microsoft Sentinel, mit aktiven Analyseregeln für sicherheitsrelevante Ereignisse.

Lücken bei der Anmeldung

Seit dem 1. Oktober 2025 führt Microsoft schrittweise verpflichtende MFA auch für ändernde Vorgänge über Azure CLI, PowerShell und Infrastructure-as-Code-Werkzeuge ein. Benutzerkonten, die als Dienstkonten in Skripten laufen, sollten deshalb durch Managed Identities oder andere Workload-Identitäten ersetzt werden. Prüfen Sie zusätzlich, ob Conditional-Access-Richtlinien Legacy-Authentifizierung blockieren. Wie Sie Conditional Access ohne Aussperren einführen, beschreiben wir in einem eigenen Beitrag.

Wie verhindern Azure Policy und Landing Zones neue Fehlkonfigurationen?

Ein behobener Befund kommt zurück, sobald jemand die nächste Ressource von Hand anlegt. Azure Policy setzt Regeln deshalb bei jeder Erstellung und Änderung durch. Entscheidend ist der Effekt einer Richtlinie: „audit“ markiert abweichende Ressourcen als nicht konform, „deny“ lehnt die Anfrage ab, bevor die Ressource entsteht, „deployIfNotExists“ ergänzt fehlende Einstellungen wie Diagnoseeinstellungen automatisch.

Bewährt hat sich ein zweistufiges Vorgehen: Richtlinien zuerst mit „audit“ zuweisen, die Auswirkungen auswerten und dann auf „deny“ umstellen. Mehrere Richtlinien fassen Sie zu einer Initiative zusammen und weisen sie auf einer Verwaltungsgruppe zu, damit sie für alle darunterliegenden Subscriptions gelten.

Eine Azure Landing Zone ist der Rahmen dafür: eine Hierarchie aus Verwaltungsgruppen, Subscriptions für Plattform und Workloads und eine Grundausstattung an Richtlinien, Rollen und zentralen Diensten wie Protokollierung und Netzwerk. Richtlinien, die überall gelten müssen, sitzen ganz oben in der Hierarchie, spezifischere Vorgaben weiter unten. Neue Subscriptions erben die Regeln, sobald sie in die richtige Verwaltungsgruppe einsortiert sind.

Wie werden Befunde zu Nachweisen?

Ein Nachweis zeigt den aktuellen Stand und den Umgang mit Abweichungen. Drei Quellen tragen dazu bei:

• Das Compliance-Dashboard in Defender for Cloud zeigt den Stand gegen den Microsoft Cloud Security Benchmark und lässt sich als PDF- oder CSV-Bericht herunterladen.
• Der kontinuierliche Export schreibt Empfehlungen, Secure Score und Compliance-Status laufend oder als wöchentliche Momentaufnahme in einen Log Analytics Workspace. So entsteht eine Historie, die auch nach Monaten noch belegt, wann ein Befund offen war und wann er behoben wurde.
• Der Compliance-Status von Azure Policy dokumentiert, welche Ressourcen den Regeln entsprechen. Begründete Abweichungen erfassen Sie als Policy-Ausnahme mit Kategorie, Begründung und Ablaufdatum, statt die Regel abzuschalten.

Für Auditoren nach NIS2, DORA oder ISO 27001 ist diese Kombination aus Regel, Messung und dokumentierter Ausnahme deutlich aussagekräftiger als eine einmalige Bildschirmkopie.

Der nächste Schritt

Unsere Leistungen zur Azure Cloud Security umfassen Landing-Zone-Aufbau, Policy-Design und den Betrieb von Defender for Cloud. Wenn Sie zunächst wissen möchten, wo Ihre Umgebung steht, prüft unser Gap Assessment Ihre Azure-Subscriptions zum Festpreis und liefert eine priorisierte Maßnahmenliste.

Erstgespräch vereinbaren

Häufig gestellte Fragen

Welche Azure-Fehlkonfiguration hat die größte Tragweite?

Dauerhafte Owner- oder Contributor-Rechte auf Subscription-Ebene, weil ein einziges kompromittiertes Konto dann alle Ressourcen dieser Subscription verändern kann. Privileged Identity Management begrenzt das Risiko, indem Rechte nur auf Antrag und zeitlich befristet aktiv werden.

Kostet Microsoft Defender for Cloud zusätzlich?

Die Stufe Foundational CSPM mit Empfehlungen, Secure Score und Microsoft Cloud Security Benchmark ist kostenfrei. Der Plan Defender CSPM und die Schutzpläne für Workloads, etwa für Server oder Datenbanken, werden nach Ressourcen abgerechnet.

Reicht es, Network Security Groups einmal zu konfigurieren?

Nein. Umgebungen ändern sich, und mit jedem neuen Dienst entstehen Ausnahmen. Planen Sie regelmäßige Überprüfungen ein und setzen Sie Grundregeln, etwa gegen öffentliche IP-Adressen auf Netzwerkschnittstellen, über Azure Policy durch.

Wie erkenne ich, ob meine Azure-Protokolle tatsächlich ausgewertet werden?

Prüfen Sie, ob Activity Log und Ressourcenprotokolle per Diagnoseeinstellung in einen Log Analytics Workspace oder nach Microsoft Sentinel fließen und ob dort aktive Analyseregeln Warnungen erzeugen. Protokolle, die nur gespeichert, aber nie ausgewertet werden, helfen erst nach einem Vorfall.