Viele meiner Kund:innen setzen in hybriden Umgebungen längst ganz selbstverständlich auf Azure-Arc-Server. Der eigentliche Grund: Sie behalten ihre On-Prem-Server zentral im Griff, ohne auf Komfort oder Sicherheit zu verzichten. Das Onboarding im Azure-Portal wirkt zwar einfach, doch wer nicht gerade einen reinen Testtenant betreibt, sollte die Security nicht auf später verschieben. Bei der Verwaltung lokaler Windows- und Linux-Server über Arc stoße ich immer wieder auf dieselben Fehlannahmen und riskanten Abkürzungen. Es geht dabei jedes Mal um Identitäten, Rechte, Netzwerkzugriffe und die Kontrolle über die Automatisierung.

Für das Onboarding genügt ein Service Principal mit minimalen Rechten

In vielen Tenants, die ich betreue, läuft das Onboarding der Arc-Server noch immer über ein Konto mit globaler Contributor- oder sogar Owner-Rolle. Das ist unnötig und obendrein ein echtes Risiko. Sinnvoller ist ein eigener Service Principal mit der Rolle „Azure Connected Machine Onboarding“, die ihr ihm nur auf die Ressourcengruppe oder den Private Link Scope zuweist, in der bzw. dem die Arc-Server landen sollen. Das klappt unter Windows genauso wie unter Linux, auch wenn ihr die Bereitstellung per Skript automatisiert. Eine ausführliche Beschreibung findet ihr auf Microsoft Learn.

Praxistipp: Onboarding-Skripte mit dem Service Principal lassen sich so aufbauen, dass darin keine Schlüssel im Klartext stehen müssen – mit Managed Identities (bei VMs in Azure) oder, wo es passt, direkt per Zertifikatsauthentifizierung auf dem lokalen Server.

Ein Private Link Scope hält den Management-Traffic vom Internet fern

Aus Sicherheitssicht besonders wertvoll ist der Private Link Scope für Azure-Arc-Server. Mit ihm fließt der gesamte Management-Traffic (inklusive Azure Policy, Defender for Servers, Update Manager und Gasterweiterungen) über private Endpunkte. Die Angriffsfläche schrumpft dadurch deutlich, vor allem wenn Arc-Server in sensiblen Netzwerken stehen. Dafür müssen im eigenen Netzwerk die DNS-Einträge für arc.private.azure.com angepasst werden, und genau daran scheitert der Umstieg auf Private Link in der Praxis häufig. Welche Schritte nötig sind, steht in der Dokumentation von Microsoft.

Eine Allowlist am Agent begrenzt die zulässigen Extensions

Viele unterschätzen, dass alle Azure-Arc-Extensions auf den angebundenen Servern mit SYSTEM- bzw. root-Rechten laufen. In großen Tenants mit vielen Admins (und delegierter Rechtevergabe per RBAC) wird daraus schnell ein Einfallstor, sobald sich Extensions nachinstallieren oder manipulieren lassen. Auf fast allen produktiven Arc-Servern setze ich deshalb die Allowlist des Agents ein, damit nur ausdrücklich erlaubte Extensions zugelassen sind. Eingerichtet wird sie direkt am Server (im Windows- oder Linux-Terminal):

# Am Arc-Server als Administrator (Windows Terminal oder Bash)
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor,Microsoft.Azure.Security.Monitor,Microsoft.Azure.UpdateManagement,Microsoft.Azure.MachineConfig"

Anschließend sind nur noch die Extensions für Monitoring, Defender, Update Manager und Machine Configuration erlaubt, was die Angriffsfläche spürbar verkleinert.

Die wichtigsten Managementdienste lassen sich mit Azure-Arc-Servern sicher nutzen

Das Gesamtpaket rund um Azure-Arc-Server ist inzwischen wirklich ausgereift. Updates und Patches verteilt ihr mit dem Azure Update Manager ganz ohne Automation Accounts, Sicherheitsbewertungen und Schutz liefert Defender for Servers, und die Compliance auf Betriebssystemebene prüft Azure Machine Configuration. Auch SSH-Sitzungen lassen sich sicher über das Azure-Portal steuern, ohne dass ihr Ports nach außen öffnen müsst. Gerade in stark segmentierten Umgebungen möchte ich auf diese Funktion nicht mehr verzichten.

Im folgenden Überblick seht ihr, wie die wichtigsten Schutzmaßnahmen ineinandergreifen:

flowchart TD
    OnPrem["On-Prem Server"] --> Agent["Arc Agent"]
    Agent --> ExtAllow["Allowlist Extensions"]
    Agent --> PrivateLink["Private Link Scope"]
    Agent --> Azure["Azure Management Services"]
    Azure --> Update["Update Manager"]
    Azure --> Defender["Defender for Servers"]
    Azure --> Config["Machine Configuration"]
    Azure --> SSH["SSH via Arc"]

Abbildung: Azure-Arc-Server – Architektur und Sicherheitskontrollen

Azure Arc schlägt die Brücke zu PAYG-Lizenzen und ESU

Mit Windows Server 2025 wird Azure Arc noch wichtiger. Durch die Pay-as-you-go-Lizenzierung (und die automatische ESU-Verwaltung für ältere Versionen) entfallen lokale Volumenlizenzschlüssel ebenso wie die umständliche manuelle Aktivierung. Wo Windows Server 2012 R2 oder 2016 noch ein paar Jahre weiterlaufen müssen, gewinnt ihr dadurch viel für Compliance und Updatefähigkeit. Technisch ist die Integration zwar simpel. Trotzdem sollten Arc-Anbindung und Verwaltung auch hier über sichere Identitäten und Rollen laufen und nicht über einen Allzweck-Service-Principal oder gar ein interaktives Konto.

Weitere Details und meine Erfahrungen aus der Praxis habe ich in einem eigenen Beitrag zusammengetragen: Windows Server 2012 ESU über Azure Arc.

Arc-Adminrechte gehören in die Tier-0-Schutzstufe

Im Alltag geht oft unter, dass jeder, der Arc-Server administrieren darf, über Extensions und Policy-Deployments Code mit SYSTEM- bzw. root-Rechten auf beliebigen Servern ausführen kann. Arc-Adminrechte gehören deshalb in dieselbe Schutzstufe wie Domain Admins, Entra-Admins oder andere Tier-0-Konten. Konkret bedeutet das separate Konten, MFA, Just-in-Time-Berechtigungen (z. B. mit Privileged Identity Management) und eine strikte Kontrolle der RBAC-Zuweisungen im Azure-Portal. Wer das ignoriert, verschafft Angreifern direkten Zugriff aufs Blech – mit allen Folgen von Persistenz bis zur Ausbreitung von Ransomware.

Azure-Arc-Server sind ein starkes Werkzeug, aber kein Selbstläufer. Wer Rechtevergabe, Netzwerkzugang, Extension-Management und die Einbindung in die eigenen Sicherheitsprozesse von Anfang an ernst nimmt, erspart sich viel Ärger und schützt seine Umgebung dauerhaft.