Sichere Azure Automation Architektur: Ein Praxis-Guide

Azure Automation Accounts entstehen oft aus Bequemlichkeit. Jemand braucht einen geplanten Script-Lauf. Ein Automation Account wird erstellt, ein Runbook angelegt, und es funktioniert. Sechs Monate später laufen 30 Produktiv-Runbooks mit breiten Berechtigungen, geteilten Credentials und ohne Audit Trail über diesen Account.

Wir haben Automation-Umgebungen auditiert, in denen ein einzelner Account Contributor-Zugriff auf die gesamte Subscription hatte. In denen Credentials als unverschlüsselte Variables gespeichert waren. In denen jeder im IT-Team Runbooks direkt im Portal bearbeiten konnte.

Nichts davon war Absicht. Es fing an mit „sichern wir später ab.“ Später kam nie.

Dieser Guide behandelt die Architektur-Entscheidungen, die eine Azure Automation Umgebung von Anfang an sicher machen. Keine theoretischen Best Practices. Konkrete Konfigurationen, die wir in Consulting-Projekten umsetzen.

Authentifizierung: Managed Identity vor allem anderen

Run As Accounts sind deprecated. Zertifikatsbasierte Service Principals sind komplex in der Pflege. Application Secrets laufen ab und die Rotation ist umständlich. Managed Identity beseitigt all diese Probleme.

System-Assigned Managed Identity

Jeder Automation Account sollte eine System-assigned Managed Identity aktiviert haben. Ein einziger Schalter im Azure Portal. Einmal aktiviert, bekommt der Automation Account eine Identität in Entra ID, der RBAC-Rollen zugewiesen werden können.

In Runbooks wird die Authentifizierung zu einer einzigen Zeile:

Connect-AzAccount -Identity

Keine Zertifikate. Keine Secrets. Keine Rotation. Die Identität ist an den Lebenszyklus des Automation Accounts gebunden. Account löschen, Identität verschwindet.

User-Assigned Managed Identity

Für Szenarien, in denen mehrere Automation Accounts identische Berechtigungen brauchen, oder die Identität unabhängig vom Account bestehen bleiben soll: User-assigned Managed Identity verwenden.

Identität einmal erstellen. RBAC-Rollen zuweisen. An mehrere Automation Accounts anhängen. Wenn ein Automation Account neu aufgebaut wird: Dieselbe Identität wieder anhängen, ohne Berechtigungen neu zu vergeben.

In Runbooks angeben, welche Identität genutzt werden soll:

Connect-AzAccount -Identity -AccountId "client-id-der-user-assigned-identity"

Wann Service Principals noch nötig sind

Manchmal reicht Managed Identity nicht. Cross-Tenant-Zugriff, Drittanbieter-APIs die OAuth Client Credentials erfordern, oder Legacy-Anwendungen die nur Zertifikats-Auth unterstützen. In diesen Fällen: Credentials in Azure Key Vault speichern und zur Laufzeit abrufen. Nie als Automation Variables. Nie im Runbook-Code.

→ Die häufigsten Fehler bei der Authentifizierung: Die 10 häufigsten Azure Automation Fehler

Least Privilege: Nur was gebraucht wird

Der gefährlichste Automation Account ist einer mit Contributor-Zugriff auf die Subscription. Er kann Ressourcen erstellen, Konfigurationen ändern, ganze Resource Groups löschen. Wenn ein Runbook kompromittiert wird, ist der Blast Radius: alles.

Mit null Berechtigungen starten. Für jedes Runbook exakt dokumentieren, was es tun muss. Dann die minimale RBAC-Rolle im engsten Scope vergeben.

Beispiele:

VMs starten/stoppen: Virtual Machine Contributor, Scope auf die Resource Group mit den VMs

Log Analytics lesen: Log Analytics Reader, Scope auf den spezifischen Workspace

DNS Records verwalten: DNS Zone Contributor, Scope auf die spezifische DNS Zone

Entra ID User erstellen: User Administrator, Scope auf Directory-Ebene

E-Mail senden via Graph: Mail.Send, Scope auf spezifisches Postfach

Custom Roles funktionieren gut für Automation. Wenn ein Runbook VMs nur starten und stoppen soll (nicht löschen oder resizen): Eine Custom Role erstellen mit ausschließlich Microsoft.Compute/virtualMachines/start/action und Microsoft.Compute/virtualMachines/deallocate/action. Nichts weiter.

Berechtigungen vierteljährlich prüfen. Runbooks werden stillgelegt, aber ihre Berechtigungen bleiben bestehen. Wir haben Automation Accounts mit Rollen für Ressourcen gefunden, die es längst nicht mehr gibt.

RBAC auf dem Automation Account selbst

Wer was mit dem Automation Account tun darf, ist genauso wichtig wie die Frage, was der Account mit anderen Ressourcen tun kann.

Azure stellt drei relevante Built-in Roles bereit:

Automation Operator: Kann Jobs starten und Runbooks ansehen, aber nicht bearbeiten. Perfekt für Operations-Teams, die Runbooks auslösen müssen, ohne Code zu ändern.

Automation Contributor: Kann Runbooks erstellen und bearbeiten, Schedules verwalten und den Account konfigurieren. Für das Automation-Entwicklungsteam.

Reader: Kann alles sehen, aber nichts ändern. Für Auditoren, Manager oder alle, die Einblick brauchen ohne Kontrolle.

Nicht jedem Contributor-Zugriff geben. In den meisten Organisationen brauchen 2-3 Personen Contributor. Alle anderen sollten Operator oder Reader sein.

Für sensible Runbooks (User Provisioning, Finanzdaten, Security Operations): Einen dedizierten Automation Account mit engerer RBAC in Betracht ziehen. Separation of Duties ist nicht nur für Compliance. Es begrenzt den Schaden, wenn jemand einen Fehler macht.

Secrets Management mit Key Vault

Azure Automation hat eingebaute Credential Assets und verschlüsselte Variables. Die funktionieren. Aber Key Vault ist besser.

Warum Key Vault statt Automation Credentials:

• Zentrales Secrets Management. Ein Key Vault für alle Anwendungen, statt Secrets verstreut über Automation Accounts, App Services und Function Apps.
• Access Policies und RBAC. Granulare Kontrolle darüber, wer und was welche Secrets lesen darf.
• Audit Logging. Jeder Zugriff auf ein Secret wird geloggt. Key Vault Diagnostics + Log Analytics ergibt einen vollständigen Audit Trail.
• Rotation. Key Vault unterstützt automatische Rotation für bestimmte Secret-Typen. Automation Credential Assets nicht.
• Soft Delete und Purge Protection. Versehentliches Löschen heißt nicht, dass das Secret weg ist.

Implementierungsmuster:

# Mit Managed Identity verbinden
Connect-AzAccount -Identity

# Secrets aus Key Vault abrufen
$apiKey = Get-AzKeyVaultSecret -VaultName "automation-secrets" -Name "ServiceNow-APIKey" -AsPlainText
$dbPassword = Get-AzKeyVaultSecret -VaultName "automation-secrets" -Name "SQL-Password" -AsPlainText

# Secrets in der Runbook-Logik verwenden
$headers = @{ "Authorization" = "Bearer $apiKey" }

Der Managed Identity des Automation Accounts die Rolle „Key Vault Secrets User“ auf dem Key Vault zuweisen. Nicht „Key Vault Administrator“. Nicht „Key Vault Contributor“. Nur „Secrets User“ für Read-Only-Zugriff auf Secrets.

Netzwerksicherheit

Hybrid Worker Absicherung

Hybrid Runbook Workers laufen im eigenen Netzwerk. Das macht sie mächtig und zu einem potenziellen Angriffsvektor.

Netzwerkisolation:

• Hybrid Worker in ein dediziertes Subnet platzieren
• NSG-Regeln: Ausgehend HTTPS (443) zu Azure Automation Endpoints erlauben, alles andere verweigern
• Keine eingehenden Regeln nötig. Der Worker pollt Azure nach Jobs. Er hört nicht zu.
• Keine Public IP. Wenn der Worker Internetzugang für Runbook-Tasks braucht: NAT Gateway oder Azure Firewall für kontrollierten Egress

OS-Härtung:

• Regelmäßig patchen. Der Hybrid Worker ist eine Windows- oder Linux-VM, die Wartung braucht.
• Azure Update Manager oder den bestehenden Patching-Prozess nutzen
• Minimale Software installiert. Nur die Az Module und Tools, die die Runbooks brauchen.
• Endpoint Protection (Defender for Servers oder gleichwertig)

Monitoring:

• Azure Monitor Agent für Performance- und Security-Events
• Defender for Cloud für Vulnerability Assessment
• Alerts bei unerwarteten Prozessen oder Netzwerkverbindungen

Private Endpoints

Für Umgebungen, in denen kein Traffic über das öffentliche Internet laufen soll, unterstützt Azure Automation Private Endpoints. Das bedeutet:

• Runbook-Job-Management läuft über das eigene VNet, nicht über den öffentlichen Endpoint
• Der öffentliche Endpoint des Automation Accounts kann komplett deaktiviert werden
• Hybrid Workers kommunizieren mit Azure Automation über die private IP

Setup erfordert eine Private DNS Zone (privatelink.azure-automation.net) und einen Private Endpoint im VNet. Das Azure Portal führt durch die Einrichtung, oder Terraform/Bicep für Wiederholbarkeit verwenden.

Private Endpoints fügen Komplexität hinzu. Nicht jede Umgebung braucht sie. Aber für regulierte Branchen (Finanzen, Gesundheitswesen, öffentlicher Sektor) oder Umgebungen mit sensiblen Daten sind sie die richtige Wahl.

Source Control Integration

Runbooks sind Code. Code gehört in die Quellcodeverwaltung. Punkt.

Azure Automation integriert sich nativ mit GitHub und Azure DevOps. Einmal verbunden, synchronisieren sich Runbooks automatisch aus dem Repository. Kein Bearbeiten mehr im Portal.

Vorteile über Versionshistorie hinaus:

• Pull Request Reviews. Jemand anderes sieht den Code bevor er in Produktion läuft.
• Branch Protection. Der Main Branch erfordert Reviews. Keine direkten Pushes.
• Automatisierte Tests. Pester Tests auf Runbook-Code in der CI laufen lassen, bevor deployed wird.
• Change Tracking. Git Blame zeigt wer wann was geändert hat. Auditoren schätzen das.
• Rollback. Zu einem früheren Commit zurückkehren wenn eine Änderung etwas kaputt macht.

Für Organisationen mit striktem Change Management: Dieser Workflow lässt sich direkt auf ITIL Change Prozesse abbilden. Der Pull Request ist der Change Request. Das Review ist die Genehmigung. Der Merge ist die Implementierung. Das Git Log ist der Audit Trail.

→ Häufige Fehler bei Source Control und Modulen: Azure Automation Fehler vermeiden

Monitoring und Alerting

Eine sichere Umgebung ist eine überwachte Umgebung. Wenn ein Runbook um 3 Uhr nachts fehlschlägt und niemand es bis 9 Uhr bemerkt, sind das sechs Stunden potenzieller Auswirkung.

Job Monitoring

Azure Monitor Alerts konfigurieren für:

• Fehlgeschlagene Jobs: Jeder Job der im Status „Failed“ endet. Das absolute Minimum.
• Suspendierte Jobs: Jobs die das Fair Share Limit erreichen oder manuell suspendiert werden.
• Lang laufende Jobs: Jobs die ihre erwartete Laufzeit um mehr als Faktor 2 überschreiten.
• Ausgebliebene Jobs: Wenn ein geplanter Job gar nicht läuft (fehlerhafte Schedule-Konfiguration oder Hybrid Worker offline).

Log Analytics Integration

Automation Job Logs an einen Log Analytics Workspace senden. Das ermöglicht:

• Historische Analyse der Job-Performance
• Korrelation mit anderen Azure Events
• Custom KQL-Abfragen für spezifische Muster
• Workbooks und Dashboards für operativen Überblick

KQL-Beispielabfrage für Runbooks mit steigender Fehlerrate:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.AUTOMATION"
| where Category == "JobLogs"
| where ResultType == "Failed"
| summarize FailureCount = count() by RunbookName_s, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

Security Monitoring

Über operatives Monitoring hinaus auf sicherheitsrelevante Events achten:

• Neue RBAC-Rollenzuweisungen auf dem Automation Account
• Änderungen an Runbook-Inhalten außerhalb der Quellcodeverwaltung
• Unerwartete Job-Ausführungen (Runbooks die zu ungewöhnlichen Zeiten laufen)
• Fehlgeschlagene Authentifizierungsversuche der Managed Identity

Diese Events in Microsoft Sentinel oder das eigene SIEM einspeisen zur Korrelation mit breiteren Security Events.

Verschlüsselung

Variables und Credentials

Azure Automation verschlüsselt Credential Assets standardmäßig. Variables können optional verschlüsselt werden. Verschlüsselung immer aktivieren für Variables mit sensiblen Daten.

Aber die Einschränkung verstehen: Verschlüsselte Variables werden zur Laufzeit im Runbook entschlüsselt. Wenn das Runbook den Wert loggt (versehentlich oder absichtlich), hilft die Verschlüsselung nicht. Code Review und Output-Monitoring sind wichtig.

Daten in Transit

Jede Kommunikation zwischen Azure Automation und seinen Komponenten nutzt TLS 1.2+. Das umfasst:

• Portal zum Automation Account
• Hybrid Worker zu Azure Automation
• Runbook-Aufrufe an Azure APIs (via Az Module)

Für Runbooks die externe APIs aufrufen, TLS-Konfiguration verifizieren:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Standard in PowerShell 7.x, muss aber in 5.1-Umgebungen möglicherweise explizit gesetzt werden.

Die Referenzarchitektur

Die vollständige sichere Architektur, die wir empfehlen:

┌─────────────────────────────────────────────────┐
│  Azure Subscription                              │
│                                                   │
│  ┌──────────────────┐    ┌──────────────────┐    │
│  │ Automation Account│───▶│   Key Vault       │    │
│  │ (Managed Identity)│    │ (Secrets, Keys)   │    │
│  │ Source Control:   │    └──────────────────┘    │
│  │  GitHub/DevOps    │                            │
│  └────────┬─────────┘    ┌──────────────────┐    │
│           │              │  Log Analytics     │    │
│           │              │  (Job Logs, Diag)  │    │
│           ▼              └──────────────────┘    │
│  ┌──────────────────┐                            │
│  │  Hybrid Worker    │    ┌──────────────────┐    │
│  │  (Dediziertes     │───▶│  Azure Monitor    │    │
│  │   Subnet, NSG,   │    │  (Alerts)         │    │
│  │   Keine Pub IP)  │    └──────────────────┘    │
│  └──────────────────┘                            │
│                                                   │
└─────────────────────────────────────────────────┘

Jede Komponente hat eine einzige Verantwortung. RBAC ist eng geschnitten. Secrets leben im Key Vault. Änderungen gehen durch Source Control. Fehler lösen Alerts aus. Jede Aktion wird geloggt.

Das ist kein Overengineering. Das ist die Baseline für jeden Automation Account, der Produktiv-Workloads betreibt.

FAQ

System-assigned oder User-assigned Managed Identity?

System-assigned ist einfacher für Single-Account-Setups. Die Identität lebt und stirbt mit dem Automation Account. User-assigned ist besser, wenn mehrere Accounts dieselben Berechtigungen brauchen oder die Identität einen Account-Rebuild überleben soll. Die meisten Organisationen starten mit System-assigned und fügen User-assigned für spezifische Cross-Account-Szenarien hinzu.

Wie auditiert man, wer ein Runbook geändert hat?

Mit Source Control Integration ist jede Änderung ein Git Commit mit Autor, Zeitstempel und Diff. Ohne Source Control erfasst das Azure Activity Log, wer Automation Account Ressourcen geändert hat, allerdings mit weniger Detail. Source Control ist der zuverlässige Audit-Pfad.

Kann man einschränken, welche Runbooks ein User ausführen darf?

Nicht nativ auf Ebene einzelner Runbooks. RBAC gilt für den Automation Account als Ganzes. Um die Ausführung bestimmter Runbooks einzuschränken: Separate Automation Accounts mit unterschiedlichen RBAC-Zuweisungen verwenden. Manche Organisationen erstellen einen „Sensitive Operations“ Account mit engem Zugriff und einen „General Operations“ Account mit breiterem Zugriff.

Was kosten Private Endpoints?

Private Endpoints selbst haben geringe Stundenkosten (ca. 7,30 EUR/Monat pro Endpoint). Der größere Aufwand ist DNS-Management-Komplexität und die Voraussetzung, dass Hybrid Workers die Private DNS Zone auflösen. Für regulierte Umgebungen sind diese Kosten trivial im Vergleich zum Compliance-Nutzen.

Wie oft sollte man Automation Account Berechtigungen prüfen?

Mindestens vierteljährlich. In den regulären Access-Review-Zyklus einbinden. Prüfen: Braucht die Managed Identity noch alle ihre Rollen? Gibt es Rollen für Ressourcen, die nicht mehr existieren? Hat jemand Contributor-Zugriff bekommen, der Operator sein sollte?

---

Brauchen Sie Unterstützung bei der Absicherung Ihrer Azure Automation Umgebung? Wir konzipieren und implementieren sichere Automation-Architekturen für Unternehmen in ganz Europa. Von der initialen Bewertung bis zur vollständigen Umsetzung bringen wir Praxiserfahrung in jedes Projekt mit.

Beratungstermin vereinbaren.