Azure Policy rollt Diagnoseeinstellungen auch in großen Umgebungen aus

In vielen Tenants, die ich betreue, sind Ressourcendiagnose und Logging in Azure noch immer erstaunlich uneinheitlich geregelt. Manchmal landen die Ressourcenlogs nur für einzelne Dienste zentral, manchmal fehlen sie komplett, und eine klare Governance für Diagnoseeinstellungen gibt es selten. Dabei braucht man konsistente Logs für Security und Compliance ohnehin, und bei der Kostenkontrolle und bei der Fehlersuche sind sie unbezahlbar. Mit Azure Policy lassen sich Diagnoseeinstellungen skalierbar und automatisiert auf Ressourcen ausrollen – vorausgesetzt, man kennt die richtigen Initiativen und weiß um ein paar Stolperfallen.

Built-in-Initiativen setzen Diagnoseeinstellungen per Azure Policy automatisch

Für Diagnoseeinstellungen bringt Azure Policy gleich mehrere Built-in-Initiativen von Microsoft mit. Am wichtigsten ist die Initiative „[Deploy Diagnostic Settings for {category} to Log Analytics workspace]“, die mit dem Effekt DeployIfNotExists arbeitet. Sie sorgt dafür, dass unterstützte Ressourcentypen einheitlich die Kategoriegruppe „allLogs“ an einen Log-Analytics-Workspace schicken. So aktiviert man das Logging etwa für sämtliche Azure Key Vaults, Storage Accounts oder App Services an einer Stelle, und niemand muss jede Ressource einzeln anfassen. Wichtig ist, dass man die Policies mit dem passenden Log-Analytics-Workspace parametrieren und dynamisch auf große Umgebungen anwenden kann, zum Beispiel über Management Groups. Damit gehören sie zu den Grundbausteinen einer Governance-Landing-Zone, wie ich sie im Beitrag Azure Landing Zone mit Verwaltungsgruppen und Policy aufbauen beschrieben habe.

Viele vergessen die Berechtigungen der Managed Identity

Eine häufige Fehlerquelle: DeployIfNotExists-Policies, die Diagnoseeinstellungen setzen, brauchen eine Managed Identity. Sie muss mindestens die Rolle „Log Analytics Contributor“ auf dem Ziel-Workspace haben und dazu ausreichende Rechte auf den Zielressourcen, etwa „Contributor“ oder eine passende Custom Role. Fehlen diese Berechtigungen, scheitert die automatische Remediation. Zugewiesen wird die Identity im Policy-Assignment-Wizard, wo man entweder eine neue Managed Identity anlegt oder eine vorhandene auswählt. In gewachsenen Umgebungen sollte man unbedingt prüfen, ob die Identity die nötigen Rechte auch nachträglich bekommen hat. Sonst bleiben viele Ressourcen dauerhaft auf „not compliant“ stehen.

Ein Remediation Task bringt bestehende Ressourcen in die Compliance

Ressourcen, die schon vor der Policy-Zuweisung existierten, erfasst die Policy nicht von selbst. Dafür braucht es einen Remediation Task, den man unter „Azure Policy → Remediation“ anstößt und der die Diagnoseeinstellungen für alle betroffenen, also nicht konformen Ressourcen nachträglich setzt. Auch hier gilt, dass die Managed Identity wirklich auf alle Ressourcen zugreifen können muss. Kommt es zu RBAC-Fehlern, stehen die Details im Remediation-Log.

# PowerShell (Az-Modul, z.B. Cloud Shell), Rolle: Policy Contributor + Zugang zur Ziel-RG
Start-AzPolicyRemediation -Name "diagnostic-remediate" -PolicyAssignmentId <ID> -ResourceGroupName <RG>

In großen Tenants laufen Remediation Tasks nach meiner Erfahrung gern einige Stunden, manchmal sogar Tage, je nachdem, wie viele Ressourcen betroffen sind und wie die Policies konfiguriert sind. Das Warten lohnt sich trotzdem, denn danach gibt es einen Audit-Trail, der für jede einzelne Ressource zeigt, ob und wann die Policy die Diagnoseeinstellungen gesetzt hat.

Kategorien, Retention und Workspace-Wahl bestimmen die Kosten

Was beim flächendeckenden Logging per Policy gern unterschätzt wird, sind die Kosten. Wer „allLogs“ pauschal für alle Ressourcen einschaltet, produziert schnell mehrere Terabyte Logdaten im Monat, und das macht sich beim Preis des Log-Analytics-Workspace (Pay-as-you-go) deutlich bemerkbar. Deshalb sollte man genauer hinsehen:

• Nicht jede Kategorie ergibt für jeden Ressourcentyp Sinn – oft genügen z. B. Audit oder einzelne Metrics.
• Die Data Retention im Workspace sollte man auf das Nötige begrenzen (z. B. 30/90 Tage statt der Standardeinstellung von 2 Jahren).
• Sehr große Organisationen fahren unter Umständen besser mit eigenen Workspaces pro Ressourcentyp oder Abteilung.

In der Übersicht unter Azure Monitor → Diagnoseeinstellungen lässt sich genau nachvollziehen, welche Logs gerade wohin fließen.

Tipp aus dem Alltag: Wer die Kosten unter Kontrolle halten will, weist die Policies anfangs nur mit der Kategoriegruppe „AuditLogs“ oder nur für ausgewählte Ressourcengruppen zu und baut das Logging dann nach und nach aus. Damit erlebt man auf der Rechnung keine bösen Überraschungen.

Auch die Aktivitätslogs auf Abonnementebene gehören dazu

Zusätzlich zu den Ressourcenlogs gibt es auf Abonnementebene die Activity Logs, die früher Azure Audit Logs hießen. Für Compliance und Security sind sie besonders wertvoll, weil sie Änderungen an der Azure-Konfiguration und Zugriffsversuche festhalten. Die zugehörige Diagnoseeinstellung muss man für jede Subscription einzeln einrichten, was sich ebenfalls per Policy erledigen lässt. Eine kürzere Retention reicht hier meist aus, denn Activity Logs braucht man vor allem für Forensik und Change-Tracking. Dank der automatischen Export-Policy gehen keine Events verloren, auch wenn jemand die Konfiguration aus Versehen löscht oder verändert.

Die Compliance-Übersicht zeigt, ob die Policies greifen

Ob die Policies tatsächlich wirken, zeigt das Azure-Policy-Portal unter „Compliance“. Dort sind konforme und nicht konforme Ressourcen aufgeführt, und bei Bedarf startet man direkt von hier aus eine Remediation. Wie Ressourcen, Azure Policy, Managed Identity und Log Analytics zusammenspielen, zeigt das folgende Diagramm:

flowchart TD
    mg["Management Group"] --> policy["Azure Policy"]
    policy --> mi["Managed Identity"]
    policy --> rem["Remediation Task"]
    rem --> res["Resource"]
    res --> diag["Diagnostic Setting"]
    diag --> la["Log Analytics Workspace"]

Abbildung: So werden Diagnoseeinstellungen per Azure Policy und Remediation ausgerollt.

In komplexen Umgebungen gehört der regelmäßige Blick in die Compliance-Übersicht zur Pflicht, damit Lücken früh auffallen. Wer Azure Policy konsequent einsetzt, hat das Logging sauber im Griff und legt damit zugleich die Basis für zentrale Auswertungen, Alarmierung und Kostenkontrolle.

Diagnoseeinstellungen per Azure Policy gehören in jeden produktiven Tenant

Ich halte es für unverzichtbar, die Ressourcendiagnose in produktiven Tenants über Azure Policy auszurollen. Dafür braucht es ein durchdachtes Rollenkonzept für die Managed Identity, eine klare Linie bei den Kosten und den regelmäßigen Blick in die Compliance-Reports. Wer sich daran hält, spart sich lästige Nacharbeit und findet im Ernstfall alle Logs sofort. Beim Aufbau moderner Azure Landing Zones ist eine saubere Logging-Policy inzwischen Standard, und mit den Bordmitteln von Azure gelingt sie heute zum Glück deutlich leichter als noch vor ein paar Jahren.