So konfigurieren Sie die Runbook-Rechte eines Automation Accounts zum sicheren Entfernen anderer Ressourcen

Die Automatisierung von Verwaltungsaufgaben in der Cloud ist ein Eckpfeiler moderner IT-Infrastrukturen. Insbesondere das automatische Entfernen nicht mehr benötigter Ressourcen, wie veraltete virtuelle Maschinen, ungenutzte Speicherkonten oder temporäre Testumgebungen, kann Kosten senken und die Übersichtlichkeit wahren. In Azure ist der **Automation Account** mit seinen **Runbooks** ein leistungsstarkes Werkzeug hierfür. Doch die Macht, Ressourcen zu löschen, birgt auch Risiken. Eine fehlerhafte Konfiguration der Berechtigungen könnte unbeabsichtigt kritische Systeme außer Betrieb setzen. Dieser Artikel führt Sie umfassend durch die sichere Konfiguration der Runbook-Rechte eines Automation Accounts, um Ressourcen zielgerichtet und mit dem **Prinzip der geringsten Rechte** zu entfernen.

### Warum Sicherheit bei der Ressourcenentfernung durch Automation so wichtig ist

Stellen Sie sich vor, ein fehlerhaftes Skript oder ein missbräuchlich genutzter Automation Account erhält die Berechtigung, alle Ressourcen in Ihrem gesamten Azure-Abonnement zu löschen. Die potenziellen Folgen wären katastrophal: Betriebsunterbrechungen, Datenverlust, Compliance-Verletzungen und erhebliche Kosten. Daher ist es unerlässlich, die Zugriffsrechte für Automation Runbooks, die Ressourcen entfernen sollen, sorgfältig zu definieren und auf das absolut notwendige Minimum zu beschränken. Das oberste Gebot ist das **Prinzip der geringsten Rechte (Principle of Least Privilege)**: Geben Sie einem System oder Benutzer immer nur die Berechtigungen, die es oder er für die Ausführung seiner Aufgabe zwingend benötigt – nicht mehr und nicht weniger.

### Azure Automation Account und Runbooks: Eine Einführung

Ein **Azure Automation Account** ist ein Cloud-basierter Dienst, der Ihnen hilft, Ihre Cloud- und On-Premise-Umgebungen zu automatisieren. Er bietet eine zentrale Plattform für die Automatisierung, die verschiedene Dienste und Tools integriert, darunter:
* **Runbooks**: Dies sind Skripte, die in PowerShell, Python oder graphisch erstellt werden und Aufgaben in Azure, auf Hybrid-Workern oder anderen Systemen ausführen.
* Konfigurationsmanagement (DSC)
* Update-Management
* Inventur
* Gemeinsam genutzte Ressourcen wie Variablen, Anmeldeinformationen, Zertifikate und Module.

Für die sichere Ressourcenentfernung konzentrieren wir uns auf die **Runbooks** und die Art und Weise, wie sie sich bei Azure authentifizieren, um die Löschvorgänge durchzuführen.

### Die Authentifizierungsgrundlage: Managed Identities

Der Schlüssel zur sicheren Interaktion von Azure Automation mit anderen Azure-Diensten ist die Verwendung von **Managed Identities (Verwaltete Identitäten)**. Managed Identities beseitigen die Notwendigkeit, Anmeldeinformationen (wie Benutzernamen und Passwörter oder Service Principal-Geheimnisse) manuell in Ihrem Code zu verwalten oder zu speichern. Azure übernimmt die Verwaltung der Identität und ihrer Geheimnisse für Sie.

Es gibt zwei Typen von Managed Identities:
1. **System-zugewiesene Managed Identity (System-assigned Managed Identity)**: Diese Identität ist direkt an die Lebensdauer des Automation Accounts gebunden. Sie wird automatisch erstellt, wenn Sie sie für den Automation Account aktivieren, und gelöscht, wenn der Automation Account gelöscht wird. Sie kann nur von dieser einen Azure-Ressource (Ihrem Automation Account) verwendet werden.
2. **Benutzer-zugewiesene Managed Identity (User-assigned Managed Identity)**: Dies ist eine eigenständige Azure-Ressource, die Sie unabhängig erstellen und verwalten. Sie können sie mehreren Azure-Ressourcen (einschließlich mehreren Automation Accounts) zuweisen. Dies ist nützlich, wenn Sie eine zentrale Identität für mehrere Automatisierungsaufgaben oder -konten verwenden möchten.

Für die meisten Szenarien, in denen ein Runbook Ressourcen löschen soll, ist eine **System-zugewiesene Managed Identity** ausreichend und oft die einfachste Option. Sie sollten diese für Ihren Automation Account aktivieren.

### Berechtigungen zuweisen mit Azure RBAC (Role-Based Access Control)

Nachdem Ihr Automation Account eine Managed Identity besitzt, müssen Sie dieser Identität die notwendigen Berechtigungen erteilen, um Aktionen in Azure durchzuführen. Dies geschieht über **Azure RBAC (Role-Based Access Control)**. RBAC ermöglicht es Ihnen, detaillierte Zugriffsrechte auf Azure-Ressourcen zu verwalten. Es basiert auf drei Kernelementen:
* **Prinzipal (Who)**: Die Identität, der Sie Berechtigungen zuweisen. In unserem Fall ist dies die Managed Identity Ihres Automation Accounts.
* **Rolle (What)**: Eine Sammlung von Berechtigungen, die definieren, welche Aktionen der Prinzipal ausführen darf (z. B. lesen, schreiben, löschen).
* **Bereich (Scope, Where)**: Die Ebene, auf der die Berechtigungen angewendet werden. Dies kann ein Abonnement, eine Ressourcengruppe oder eine einzelne Ressource sein.

#### Die Bedeutung des Bereichs (Scope)

Der **Bereich** ist entscheidend für das Prinzip der geringsten Rechte. Vergeben Sie Berechtigungen immer auf dem **niedrigstmöglichen Bereich**.
* **Abonnement (Subscription)**: Gewährt Zugriff auf alle Ressourcen innerhalb des gesamten Abonnements. Dies ist fast immer zu breit für Löschberechtigungen.
* **Ressourcengruppe (Resource Group)**: Gewährt Zugriff auf alle Ressourcen innerhalb einer spezifischen Ressourcengruppe. Besser als ein Abonnement, aber immer noch potenziell zu breit, wenn das Runbook nur bestimmte Ressourcen löschen soll.
* **Einzelne Ressource (Individual Resource)**: Gewährt Zugriff nur auf eine bestimmte Ressource. Dies ist der sicherste und restriktivste Bereich.

#### Rollen: Built-in vs. Custom Roles

Azure bietet eine Vielzahl von **integrierten Rollen (Built-in Roles)**, die gängige Szenarien abdecken. Beispiele hierfür sind:
* `Besitzer (Owner)`: Voller Zugriff auf alle Ressourcen und Delegierung von Rechten. **Niemals für Automation Accounts verwenden!**
* `Mitwirkender (Contributor)`: Voller Zugriff auf alle Ressourcen, aber keine Rechteverwaltung. **Für Löschvorgänge immer noch zu breit!**
* `Ressourcengruppen-Mitwirkender (Resource Group Contributor)`: Kann alle Ressourcen in einer Ressourcengruppe verwalten. In manchen Fällen akzeptabel, wenn das Runbook ganze Ressourcengruppen löschen soll, aber immer noch sehr mächtig.

Um das Prinzip der geringsten Rechte wirklich umzusetzen, insbesondere beim Löschen von Ressourcen, sollten Sie oft auf **benutzerdefinierte Rollen (Custom Roles)** zurückgreifen. Eine benutzerdefinierte Rolle ermöglicht es Ihnen, eine sehr spezifische Liste von Berechtigungen zu definieren, die ein Prinzipal benötigt.

**Beispiel für eine benutzerdefinierte Rolle zum sicheren Löschen:**
Angenommen, Ihr Runbook soll nur virtuelle Maschinen und ihre zugehörigen Netzwerkschnittstellen löschen, die sich in einer bestimmten Ressourcengruppe befinden. Sie würden eine benutzerdefinierte Rolle erstellen, die nur die folgenden Aktionen erlaubt:
* `Microsoft.Compute/virtualMachines/delete`
* `Microsoft.Network/networkInterfaces/delete`
* `Microsoft.Compute/virtualMachines/read` (oft benötigt, um die VM vor dem Löschen zu finden)
* `Microsoft.Network/networkInterfaces/read` (oft benötigt, um die NIC vor dem Löschen zu finden)

Diese Rolle würden Sie dann der Managed Identity Ihres Automation Accounts auf dem **Bereich der spezifischen Ressourcengruppe** zuweisen, in der die VMs gelöscht werden sollen.

### Schritt-für-Schritt-Konfiguration

#### 1. System-zugewiesene Managed Identity für den Automation Account aktivieren

1. Melden Sie sich im **Azure-Portal** an.
2. Navigieren Sie zu Ihrem **Automation Account**.
3. Wählen Sie unter „Kontoeinstellungen” die Option „**Identität**”.
4. Wählen Sie die Registerkarte „**System zugewiesen**”.
5. Schalten Sie den **Status** auf „**Ein**” und klicken Sie auf „**Speichern**”.
* Azure erstellt nun eine Managed Identity für Ihren Automation Account. Sie sehen die Objekt-ID der Prinzipal-ID dieser Identität.

#### 2. Die Managed Identity zu einer Rolle hinzufügen (RBAC-Zuweisung)

1. Identifizieren Sie die **Zielressourcengruppe** oder das **Abonnement**, in dem die Ressourcen gelöscht werden sollen.
2. Navigieren Sie im Azure-Portal zu dieser Ressourcengruppe (oder dem Abonnement).
3. Klicken Sie im linken Menü auf „**Zugriffssteuerung (IAM)**”.
4. Klicken Sie auf „**Rollenzuweisung hinzufügen**”.
5. Wählen Sie die entsprechende **Rolle**:
* **Built-in Role (Vorsicht!):** Wenn Sie z. B. eine ganze Ressourcengruppe löschen möchten, könnte die Rolle `Ressourcengruppen-Mitwirkender` in Betracht gezogen werden. Wenn Sie nur VMs löschen, gibt es eventuell eine spezifischere `Virtual Machine Contributor` Rolle, die das Löschen beinhaltet. Prüfen Sie genau die Aktionen, die diese Rollen beinhalten.
* **Custom Role (Empfohlen für Least Privilege):** Wählen Sie hier Ihre zuvor erstellte benutzerdefinierte Rolle (siehe nächsten Abschnitt für Erstellung).
6. Wählen Sie unter „**Mitgliedertyp**” die Option „**Verwaltete Identität**”.
7. Klicken Sie auf „**Mitglieder auswählen**”.
8. Wählen Sie unter „**Verwaltete Identität**” die Option „**Automation Account**”.
9. Wählen Sie Ihren Automation Account aus der Liste aus und klicken Sie auf „**Auswählen**”.
10. Klicken Sie auf „**Überprüfen und zuweisen**”.

#### 3. Erstellung einer benutzerdefinierten Rolle (Optional, aber empfohlen)

Wenn keine der integrierten Rollen dem Prinzip der geringsten Rechte entspricht, müssen Sie eine benutzerdefinierte Rolle erstellen. Dies kann über das Azure-Portal, Azure CLI oder PowerShell erfolgen.

**Beispiel für PowerShell zur Erstellung einer benutzerdefinierten Rolle zum Löschen von VMs und zugehörigen Netzwerk-Interfaces:**

„`powershell
# Definieren Sie die Aktionen, die die Rolle ausführen darf
$roleDefinition = @{
Name = „VM- und NIC-Entferner”
Description = „Ermöglicht das Löschen von VMs und zugehörigen Netzwerk-Interfaces in einer Ressourcengruppe.”
Actions = @(
„Microsoft.Compute/virtualMachines/delete”,
„Microsoft.Network/networkInterfaces/delete”,
„Microsoft.Compute/virtualMachines/read”,
„Microsoft.Network/networkInterfaces/read”
)
NotActions = @()
DataActions = @()
NotDataActions = @()
AssignableScopes = @(
„/subscriptions/” # Ersetzen Sie dies durch Ihre Abonnement-ID
# Sie könnten hier auch eine spezifische Ressourcengruppe angeben, z.B. „/subscriptions//resourceGroups/”
)
}

# Erstellen Sie die benutzerdefinierte Rolle
New-AzRoleDefinition -InputObject $roleDefinition
„`
Nachdem die benutzerdefinierte Rolle erstellt wurde, können Sie sie wie in Schritt 2 beschrieben Ihrer Managed Identity zuweisen.

#### 4. Runbook-Implementierung zum Löschen von Ressourcen

Ihr PowerShell-Runbook würde sich dann wie folgt authentifizieren und eine Ressource löschen:

„`powershell
# Verbinden Sie sich mit Azure unter Verwendung der Managed Identity des Automation Accounts
Connect-AzAccount -Identity

# Beispiel: Löschen einer virtuellen Maschine
# Stellen Sie sicher, dass Sie Parameter für Ressourcengruppe und VM-Name verwenden,
# anstatt sie fest zu codieren.
$ResourceGroupName = „MyDeleteTargetRG” # Dies würde normalerweise als Runbook-Parameter übergeben
$VMName = „OldVM-01” # Dies würde normalerweise als Runbook-Parameter übergeben

Write-Output „Versuche, VM ‘$VMName’ in Ressourcengruppe ‘$ResourceGroupName’ zu löschen…”

try {
# Abrufen der VM, um sie zu identifizieren
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName -ErrorAction Stop

# Identifizieren der zugehörigen NICs (optional, aber gute Praxis)
$nics = Get-AzNetworkInterface | Where-Object { $_.VirtualMachine.Id -eq $vm.Id }

# Löschen der VM
Remove-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName -Force -Confirm:$false -ErrorAction Stop
Write-Output „VM ‘$VMName’ erfolgreich gelöscht.”

# Löschen der zugehörigen NICs
foreach ($nic in $nics) {
Remove-AzNetworkInterface -ResourceGroupName $nic.ResourceGroupName -Name $nic.Name -Force -Confirm:$false -ErrorAction Stop
Write-Output „Netzwerkschnittstelle ‘$($nic.Name)’ erfolgreich gelöscht.”
}

}
catch {
Write-Error „Fehler beim Löschen der Ressourcen: $($_.Exception.Message)”
# Zusätzliche Fehlerbehandlung, z.B. Benachrichtigung senden
}

Write-Output „Automatisierter Löschvorgang abgeschlossen.”
„`

### Best Practices und Überlegungen

* **Parameterisierung von Runbooks:** Übergeben Sie Ressourcennamen, Ressourcengruppennamen oder IDs als Parameter an Ihr Runbook. Dies macht die Runbooks flexibler, wiederverwendbarer und sicherer, da keine hartkodierten Werte enthalten sind.
* **Fehlerbehandlung:** Implementieren Sie robuste `try-catch`-Blöcke in Ihren Runbooks, um potenzielle Fehler abzufangen und angemessen darauf zu reagieren (z. B. Protokollierung, Benachrichtigung, Wiederholungsversuche).
* **Testen, Testen, Testen:** Testen Sie Ihre Runbooks immer zuerst in einer nicht-produktiven, isolierten Umgebung mit begrenzten Testressourcen, bevor Sie sie in der Produktion einsetzen.
* **Überwachung und Auditierung:** Überwachen Sie die Ausführung Ihrer Runbook-Jobs im Azure Activity Log. Alle Aktionen, die von der Managed Identity ausgeführt werden, erscheinen dort und können auditiert werden. Richten Sie Warnungen für fehlgeschlagene Löschvorgänge oder unerwartete Aktivitäten ein.
* **Quellcodeverwaltung:** Speichern Sie Ihre Runbook-Skripte in einem Versionskontrollsystem (z. B. Azure DevOps, GitHub). Dies ermöglicht Änderungsnachverfolgung, Rollback-Möglichkeiten und Zusammenarbeit.
* **Deletion Policy:** Definieren Sie klare Richtlinien, wann welche Ressourcen automatisch gelöscht werden sollen und wer für die Genehmigung verantwortlich ist.
* **Separation of Duties:** Erwägen Sie, unterschiedliche Automation Accounts oder User-assigned Managed Identities für verschiedene Arten von Löschvorgängen zu verwenden, um die Zugriffskontrolle weiter zu granulieren.
* **Lock-Mechanismen:** Für kritische Ressourcen, die auf keinen Fall gelöscht werden dürfen, nutzen Sie **Azure Resource Locks** (z. B. `CanNotDelete`). Diese bieten eine zusätzliche Schutzschicht, selbst wenn ein Automation Account über die Berechtigung zum Löschen verfügt.

### Häufige Fallstricke

* **Vergessene Rollenzuweisung:** Die Managed Identity wurde aktiviert, aber es wurden keine oder falsche RBAC-Rollen zugewiesen. Das Runbook scheitert mit Zugriffsfehlern.
* **Zu breite Rollenzuweisung:** Der Managed Identity wird eine Rolle wie `Mitwirkender` auf Abonnementebene zugewiesen. Dies verstößt gegen das Prinzip der geringsten Rechte und ist ein erhebliches Sicherheitsrisiko.
* **Ungenügendes Testen:** Runbooks werden in der Produktion ausgeführt, ohne gründlich in einer Testumgebung validiert worden zu sein, was zu unbeabsichtigten Löschungen führt.
* **Fehlende Fehlerbehandlung:** Das Runbook stürzt bei einem Fehler ab, ohne eine Fehlermeldung zu protokollieren oder eine Benachrichtigung zu senden, was die Fehlersuche erschwert.
* **Statische Ressourcennamen:** Hardcodierte Ressourcennamen im Skript statt Parameter. Dies macht das Runbook unflexibel und fehleranfällig.

### Fazit

Die Automatisierung der Ressourcenentfernung mit Azure Automation Accounts und Runbooks ist ein mächtiges Werkzeug, das Effizienz steigert und Kosten senkt. Der Schlüssel zum sicheren und effektiven Einsatz liegt jedoch in der sorgfältigen Konfiguration der **Berechtigungen**. Durch die konsequente Nutzung von **Managed Identities** in Kombination mit einer präzisen **Azure RBAC**-Zuweisung – idealerweise durch **benutzerdefinierte Rollen** auf dem **niedrigstmöglichen Bereich** – stellen Sie sicher, dass Ihre Automatisierung nur das tut, was sie soll, und keine unbeabsichtigten oder schädlichen Aktionen ausführt. Beachten Sie die Best Practices für Tests, Überwachung und Fehlerbehandlung, um eine robuste und sichere Automatisierungsstrategie zu gewährleisten. So verwandeln Sie die Fähigkeit zum automatisierten Löschen von Ressourcen in einen Segen statt in ein Risiko für Ihre Azure-Umgebung.