Wer Governance in Azure ernst nimmt, landet früher oder später bei Azure Machine Configuration. In fast jedem Enterprise-Tenant, den ich betreue, sind OS-Konfiguration und Compliance ein Dauerthema. Das betrifft Windows-Server in Azure, vor allem aber auch Arc-aktivierte Maschinen im eigenen Rechenzentrum und in anderen Clouds. Die Anforderungen sind breit gestreut: Mal geht es darum, die Security-Baseline zu überwachen, mal sollen bestimmte Einstellungen erzwungen werden, etwa deaktiviertes RDP, Passwortvorgaben oder Audit-Log-Einstellungen, und oft kommen eigene Unternehmensstandards hinzu. Unter dem früheren Namen „Guest Configuration“ war das noch ein Nischenthema für stark regulierte Umgebungen. In den letzten zwei Jahren ist daraus ein Werkzeug für den Alltag geworden.

Microsoft liefert Security-Baselines als fertige Richtlinien mit

Die meisten Kunden steigen mit den Built-in-Policy-Initiativen von Microsoft ein. Am häufigsten sehe ich die Windows Security Baseline und das Linux-Security-Baseline-Paket, die beide als Richtlinienbündel bereitstehen. Sie arbeiten mit Azure Policy und den Effekten „AuditIfNotExists“ oder „DeployIfNotExists“, im Hintergrund übernimmt die Extension von Azure Machine Configuration die eigentliche Arbeit. Sie prüft auf der VM oder dem Arc-Server, wie das lokale Administratorkonto eingerichtet ist, welche Passwort-Policy und welche Firewall-Regeln gelten und ob sicherheitsrelevante Ereignisse protokolliert werden. Zugewiesen werden die Richtlinien in der Regel über Management Groups oder auf Subscription-Ebene, häufig als Teil einer Landing-Zone-Architektur (siehe Azure-Landing-Zone-Governance ohne Overkill aufbauen).

Dass sich manche Einstellungen auch erzwingen lassen („ApplyAndMonitor“), wissen viele gar nicht. Trotzdem rate ich dazu, das behutsam einzuführen. Gerade auf Arc-Servern sorgt ein zu forsches Enforcement schnell für böse Überraschungen, zum Beispiel wenn Altlasten oder Anwendungen mit den Baseline-Werten kollidieren.

Extension und Managed Identity müssen vor der ersten Richtlinie bereitstehen

In der Praxis hakt es am häufigsten bei den Voraussetzungen. Auf Azure-VMs ist die Machine-Configuration-Extension meist rasch verteilt. Auf Arc-Servern dagegen muss man sie gezielt nachinstallieren, am besten automatisiert per Skript oder über eine Azure-Policy-Initiative. Außerdem braucht jede Maschine eine System-assigned Managed Identity, sonst kann die Extension Policy-Status und Compliance nicht an Azure zurückmelden. Für beides zusammen stellt Microsoft die Initiative „Deploy prerequisites to enable guest configuration policies on virtual machines“ bereit, die Details stehen in der Dokumentation (Übersicht, Konfiguration zuweisen).

Bei Arc-Servern, ob On-Premises oder in anderen Clouds, sollte man die Kosten einplanen: Für jede angebundene Ressource wird die Nutzung von Machine Configuration berechnet. Im November 2025 liegt der Preis bei etwa 6 Dollar pro Server und Monat. Viele Unternehmen sehen diesen Betrag deshalb nur für besonders kritische Systeme vor.

Mein Praxistipp: Nutzt die Initiative für die Voraussetzungs-Policies gleich beim Onboarding der Server in Arc oder beim Bau neuer Azure-VM-Images. In großen Umgebungen ist das Nachrüsten deutlich mühsamer.

ApplyAndMonitor geht einen Schritt weiter als der reine Audit

Bevor man loslegt, muss man sich entscheiden, ob Einstellungen nur „auditiert“ werden sollen, also Abweichungen lediglich gemeldet werden, oder ob man sie tatsächlich durchsetzen will. Die meisten Built-in-Policies starten mit „AuditIfNotExists“. An der Umgebung ändert sich dabei zunächst nichts, im Compliance-Bericht des Azure-Portals sieht man aber, welche Systeme abweichen. Wer weiter gehen möchte, stellt ausgewählte Policies auf „ApplyAndMonitor“ um. Abweichungen werden dann automatisch korrigiert und weiterhin laufend überwacht. Diesen Wechsel sollte man sorgfältig vorbereiten, weil automatische Korrekturen bei kritischen Anwendungen unerwünschte Nebenwirkungen haben können.

Die Compliance-Übersicht liegt im Azure-Portal unter Policy → Compliance. Der Reiter „Machine Configuration“ zeigt gezielt, wie es um die Richtlinien auf VMs und Arc-Servern steht. Security- und Governance-Teams haben damit eine sehr hilfreiche Ansicht, die den Gesamtstatus ebenso abbildet wie die Details zu jeder einzelnen Ressource.

Das folgende Mermaid-Diagramm zeigt den Kontrollfluss in vereinfachter Form:

flowchart TD
A["Policy-Zuweisung"] --> B["Initiative deploy prerequisites"]
B --> C["Extension & Managed Identity"]
C --> D["Machine Configuration prüft Einstellungen"]
D --> E["Compliance-Status an Azure Policy"]
E --> F["Compliance-Ansicht im Azure-Portal"]

Abbildung: Ablauf von der Policy-Zuweisung bis zum Compliance-Reporting mit Azure Machine Configuration.

Eigene Anforderungen lassen sich mit PowerShell DSC abbilden

Sobald individuelle Vorgaben ins Spiel kommen, etwa hauseigene Security-Standards, bestimmte Registry-Werte oder eine aufwendigere Prüflogik, stoßen die Built-in-Policies an ihre Grenzen. Für solche Fälle kann man in Azure Machine Configuration eigene Konfigurationspakete erstellen. Die Grundlage bildet PowerShell Desired State Configuration (DSC), das Machine Configuration als Paket ausliefert. Das DSC-Skript entsteht lokal, wird anschließend paketiert und als Custom Guest Configuration Package in Azure hochgeladen. Die Zuweisung läuft auch hier über eine Policy.

Wie man solche Pakete erstellt und zuweist, ist mittlerweile ordentlich dokumentiert (Beispiel für eigene Baselines). Ich versioniere Custom Packages grundsätzlich sauber und binde sie im Azure Policy Center nur an die Ressourcen, für die sie gedacht sind. Andernfalls wird die Compliance-Ansicht gerade bei Arc-Servern mit unterschiedlichen Rollen schnell unübersichtlich.

So sieht die Registrierung eines eigenen Pakets per PowerShell aus, ausgeführt in einer PowerShell-7-Konsole mit dem Modul „Az.GuestConfiguration“:

# Voraussetzungen: Az.GuestConfiguration installiert, Contributor auf Subscription
gcPackage = New-GuestConfigurationPackage -Path .\MeinDSC -Name "CustomBaseline" -Type Audit
Publish-GuestConfigurationPackage -ResourceGroupName "meine-rg" -PackagePath $gcPackage.Path
New-AzPolicyAssignment -Name "CustomBaselineAssignment" -PolicyDefinition "<ID der Policy>" -Scope "/subscriptions/<sub>/resourceGroups/meine-rg"

Das Portal zeigt den Compliance-Status, die Kosten muss man selbst im Auge behalten

Im Tagesgeschäft schätze ich sehr, dass sich Compliance-Status und Abweichungen direkt im Azure-Portal nachvollziehen lassen. Unter Policy → Compliance und im Bereich Machine Configuration erkenne ich sofort, welche Server welche Richtlinien erfüllen und wo ich nachbessern muss. Mit den Policy-Reports kann ich außerdem Entwicklungen über längere Zeit verfolgen oder gezielt nach Tags auswerten (siehe Tag-Vererbung mit Azure Policy).

In größeren Arc-Umgebungen bleibt der Preis trotzdem ein Thema. Ich halte es für sinnvoll, Machine Configuration gezielt auf kritische Systeme wie DMZ, Management, AD und Datenbanken zu beschränken, statt wahllos alles einzubinden. Das spart Geld, und die Übersicht wird besser.

Machine Configuration gehört in meinen Projekten inzwischen zum Standard

Aus meinen Projekten ist Azure Machine Configuration mittlerweile nicht mehr wegzudenken, wenn es um eine zeitgemäße Governance- und Sicherheitsstrategie geht. Der eigentliche Gewinn besteht darin, dass ich Policies prüfen, Compliance sichtbar machen und Korrekturen automatisieren kann, ganz gleich, ob der Server in Azure läuft oder irgendwo per Arc angebunden ist. Wer seine Landing Zones sauber aufbaut und die Voraussetzungen gleich mitautomatisiert, erspart sich eine Menge Arbeit. Eine gut umgesetzte OS-Compliance sorgt zudem für Sicherheit bei Audits und bringt spürbar mehr Ruhe in den Arbeitsalltag des Teams.