Azure Automation ist eines dieser Microsoft-Produkte, die technisch extrem stark sind und trotzdem in vielen mittelständischen Unternehmen kaum jemand außerhalb eines kleinen Kreises von Cloud-Admins wirklich nutzt. Der Grund dafür ist meistens ganz banal: um ein Runbook zu starten, braucht man Zugriff auf die Automation Account Ressource im Azure Portal, und diesen Zugriff will aus gutem Grund niemand großzügig verteilen. Ein Runbook kann im Zweifel PowerShell-Code mit weitreichenden Berechtigungen ausführen, das ist nichts, was man dem gesamten IT-Team einfach so freischaltet.
Das Ergebnis, das ich in der Praxis immer wieder sehe, ist eine Art Flaschenhals-Effekt: es gibt zwei oder drei Leute im Unternehmen, die wissen, wie man in Azure Automation ein Runbook manuell auslöst und die Parameter richtig setzt, und alle anderen im IT-Team müssen bei diesen Personen anfragen, wenn sie einen automatisierten Prozess starten wollen, den es eigentlich schon gibt. Das automatisierte Skript ist da, aber der Zugang dazu ist genauso ein Flaschenhals wie die manuelle Arbeit, die es eigentlich ersetzen sollte.
Warum native RBAC in Azure hier nicht wirklich hilft
Man könnte jetzt denken, dass sich das über Azure RBAC lösen lässt, also über eine Rolle, die nur das Recht hat, Runbook-Jobs zu starten, ohne die Runbooks selbst bearbeiten zu können. Das gibt es tatsächlich, die Rolle heißt in etwa Automation Job Operator. Das Problem in der Praxis ist aber, dass diese Rolle immer noch vollen Zugriff auf das Azure Portal voraussetzt, inklusive der ganzen Navigation durch Ressourcengruppen, Abonnements und die für einen Nicht-Cloud-Menschen ziemlich unübersichtliche Oberfläche von Azure Automation selbst. Für einen Help-Desk-Mitarbeiter oder einen Fachbereichsleiter, der einfach nur “Bitte alle inaktiven Benutzerkonten der letzten 90 Tage deaktivieren” ausführen will, ist das eine viel zu hohe Hürde, unabhängig davon, welche RBAC-Rolle im Hintergrund zugewiesen ist.
Dazu kommt noch ein zweiter, oft unterschätzter Punkt: Wer im Azure Portal auf Automation Account Ressourcen zugreifen darf, sieht in der Regel auch andere Ressourcen im selben Abonnement oder in derselben Ressourcengruppe. Man müsste also entweder sehr fein granulare, aufwendig gepflegte RBAC-Zuweisungen bauen, oder man nimmt in Kauf, dass Leute mehr sehen, als sie eigentlich sehen sollten, nur um ein einziges Runbook starten zu können.
Wie ich das bei au2mator angegangen bin
Die Lösung, die sich für mich als sinnvoll herausgestellt hat, war, eine Ebene über Azure Automation zu bauen, die genau eine Sache macht: bestehende Runbooks als einfache, formularbasierte Aktionen zugänglich machen, ohne dass der ausführende Mitarbeiter jemals das Azure Portal selbst sieht. In au2mator läuft das so, dass ein Runbook einmal technisch angebunden und mit klar definierten Eingabeparametern versehen wird, zum Beispiel “Zeitraum in Tagen” oder “Zielgruppe”, und danach als Formular im Self-Service-Portal erscheint.
Ein IT-Teammitglied, das nicht Cloud-Admin ist, öffnet also nicht Azure, sondern ein simples Webformular mit vielleicht drei oder vier Eingabefeldern, klickt auf Ausführen, und im Hintergrund übernimmt ein dediziertes Service-Principal mit exakt den Berechtigungen, die für dieses eine Runbook nötig sind, die eigentliche Ausführung. Der Mitarbeiter selbst bekommt zu keinem Zeitpunkt Zugriff auf das Azure-Abonnement, die Ressourcengruppe oder andere Runbooks, die er nicht sehen soll.
Ein konkretes Beispiel aus der Praxis
Bei einem Kunden ging es konkret darum, monatlich alle Benutzerkonten zu deaktivieren, die seit mehr als 90 Tagen nicht mehr angemeldet waren, ein klassischer Compliance-Task, der vorher manuell von einem einzelnen AD-Administrator per Skript ausgeführt wurde, meistens irgendwann verspätet, weil er auch noch andere Sachen zu tun hatte. Nach der Umstellung konnte die HR-Abteilung, die eigentlich am besten weiß, welche Konten wirklich inaktiv sein sollten, dieses Runbook selbst mit einem Klick pro Monat anstoßen, ohne jemals mit Azure in Berührung zu kommen. Der AD-Administrator musste sich nur noch einmalig um die technische Anbindung kümmern, nicht mehr um die monatliche Wiederholung.
Was ich Unternehmen empfehle
Wenn ich mit Unternehmen über Azure Automation spreche, ist der häufigste Fehler, den ich sehe, dass Runbooks zwar geschrieben werden, aber als reines Cloud-Admin-Werkzeug betrachtet werden, statt als Prozess, den auch Fachabteilungen selbst anstoßen könnten. Der pragmatischste erste Schritt ist, sich die bereits existierenden Runbooks anzuschauen und zu fragen, wer im Unternehmen eigentlich der natürliche Owner dieses Prozesses wäre, wenn Azure kein Thema wäre. Meistens ist die Antwort nicht der Cloud-Admin, sondern jemand aus HR, aus dem Help Desk oder aus einer Fachabteilung, und genau dieser Person sollte man den Zugriff geben, ohne dass sie dafür Azure lernen muss.
Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Bauen von au2mator so unterkommt. Wenn du Fragen zu deiner eigenen Umgebung hast, meld dich einfach.
