Wer hat eigentlich zuletzt deine Policies angefasst?
Genau. Keine Ahnung, oder?
Hunderte Policies in Azure, irgendwer hat irgendwann irgendwas geändert und das Portal zeigt dir nur einen bunten Strauß aus Non-Compliance-Warnungen, von denen die Hälfte für Services gilt, die du gar nicht nutzt.
Chris und Matthias kennen das. Und in dieser Folge räumen sie auf.
Doch vorher kommen noch die …
Azure News der Woche
**Azure Monitor Pipelines – jetzt Generally Available**
* **Zentrale Steuerung:** Telemetriedatenaufnahme auf Basis von OpenTelemetry.
* **Features:**
* Automatische Schematisierung
* Lokales Buffering gegen Datenverlust
* Filtermöglichkeiten zur Kostensenkung
* **Anwendungsfall:** Ideal, um Logs aus On-Prem- und Azure-Umgebungen zusammenzuführen.
Microsoft Dokumentation: Azure Monitor Pipelines
**Service Health Alerts – unterschätzt, aber unverzichtbar**
* **Empfehlung:** Azure-Workload-Betreiber sollten Service Health Alerts aktiv konfigurieren.
* **Vorteile:**
* Erhalt von Meldungen ausschließlich für genutzte Services.
* Inklusive Root-Cause-Analyse nach Incidents.
* Vorankündigung geplanter Wartungen.
* Proaktive Information von Microsoft, kein separates Support-Ticket nötig.
Das Problem: Policies per ClickOps sind eine Zeitbombe
Policies in Azure sind mächtig. Und genau deshalb sind sie gefährlich, wenn sie unkontrolliert wachsen.
Was in vielen Umgebungen passiert:
Eine Initiative mit 200+ Policies wird blindlings ausgerollt
Niemand prüft, ob die Regeln überhaupt zur eigenen Umgebung passen
Non-Compliance-Status leuchtet rot – für Services, die niemand nutzt
Und wer hat’s geändert? Wann? Warum? Schweigen.
„Wer schaut schon gerne im Portal, wo dann immer Non-Compliance aufblinkt für Sachen, die man eigentlich gar nicht nutzt.” – Chris
Das ist kein Governance-Problem.
Das ist ein Prozess-Problem. Und es hat eine Lösung.
Policy as Code: Versionierung, Vier-Augen-Prinzip, Automatisierung
Der Ansatz ist derselbe wie bei Infrastructure as Code, nur eben für Policies:
Versionierung: Jede Änderung landet im Git. Wer, wann, warum - alles nachvollziehbar.
Vier-Augen-Prinzip: Pull Request, Review, dann erst Deployment. Kein unkontrollierter Rollout mehr.
Automatisierung: CI/CD-Pipelines verteilen Policies in alle Umgebungen. Kein manuelles Klicken.
Sauberkeit: Nur Policies, die du wirklich brauchst. Kein Compliance-Rauschen.
„Am Anfang mag das eine Umstellung sein, aber im Betrieb ist es ein massiver Zeitgewinn und du hast den Sicherheitsfaktor mit drin.” – Matthias
Terraform vs. ePAC – Welches Tool passt wann?
Terraform
Multi-Cloud-fähig, große Community, flexibel
Höhere Einstiegshürde bei Azure Policies (JSON-Logik, manuelle Arbeit)
Kein Enterprise-Framework out of the box
Gut, wenn du ohnehin Terraform für alles nutzt
EPAC (Enterprise Policy as Code)
Von Microsoft, für Azure – kein Kompromiss
PowerShell-Framework mit klarer Struktur
Nahtlose Integration mit Azure Landing Zones, AMBA (Azure Monitor Baseline Alerts)
Policies aus Microsoft Git-Repos direkt importierbar
Schnellerer Einstieg, weniger Eigenarbeit
Matthias’ Fazit: Wer primär in Azure unterwegs ist und schnell starten will, ist mit EPAC besser bedient. Wer Multi-Cloud denkt, greift zu Terraform, muss dann aber mehr selbst bauen.
Wie das in der Praxis aussieht
Bei den Cloud Optimizern läuft es so:
Zwei parallele Pfade beim Kunden-Onboarding:
Links: Terraform deployt die Foundation, also Plattform, Landing Zones, Infrastruktur
Rechts: EPAC zieht die Policies hoch. Sauber strukturiert, vorkonfiguriert, reviewed
Das Policy-Set wurde einmal sauber zusammengestellt: ALZ-Policies, AMBA-Alerts für die genutzten Services, alles was nicht gebraucht wird fliegt raus.
Das Ergebnis: Compliance out of the box - von Tag eins an.
Tipp zum Einstieg: Start small
Fang nicht mit 300 Policies an.
Fang mit einer an.
Definiere gemeinsam mit Security und Fachbereich: Was sind eure echten Anforderungen?
Erstelle ein erstes kleines Policy-Set in einem Git-Repository
Bau eine einfache Pipeline für den Rollout
Review-Prozess etablieren - Pull Request, Vier-Augen, fertig
Wenn der Workflow einmal sitzt, skaliert er. Und dann wird Policy-Management kein Schmerz mehr, sondern wird Routine.
Fazit
Policy as Code ist keine Tool-Frage. Es ist eine Haltung.
Wer Policies weiterhin per ClickOps verwaltet, verliert den Überblick, garantiert.
Wer auf versionierten Code, klare Prozesse und das richtige Framework setzt, gewinnt Kontrolle, Transparenz und Sicherheit zurück.
Und das, wie Matthias sagen würde: ist Lifestyle.
Danke fürs Zuhören und bis zur nächsten Folge ♥️
Chris und Matthias Die Cloud Optimizer
PS: Folge uns auf LinkedIn und tausche dich mit uns aus
Christian: LinkedIn-Profil
Matthias: LinkedIn-Profil
