
Azure Policy vs. GCP Organization Constraints: Technisches Enforcement im regulierten Umfeld
Wer Cloud-Plattformen in regulierten Branchen wie Finanz- oder Versicherungswesen betreibt, steht vor einem klassischen Dilemma: Produktteams benötigen Agilität, während Compliance- und Risikomanagement strikte Kontrolle fordern. Shift-Left-Ansätze – also Compliance-Prüfungen direkt im Code und in der CI/CD-Pipeline – sind hierfür wichtig, reichen allein jedoch nicht aus. Sie bieten schnelles Feedback, decken aber weder Laufzeitänderungen noch manuelle Eingriffe wie Break-Glass-Zugriffe ab. Benötigt wird daher ein hybrides System: schnelle Validierung im Code und verbindliches Enforcement in der Plattform. Azure und Google Cloud setzen diese Policy-Ebene technisch unterschiedlich um.
Das Schweizer-Käse-Modell: Warum hybride Governance Pflicht ist
Ein gängiges Missverständnis ist, dass Governance ausschließlich in der CI/CD-Pipeline ausreichend ist. Pipeline-Prüfungen verhindern Fehlkonfigurationen frühzeitig, bieten aber keinen Schutz vor Konfigurationsdrift oder direkten API-Aufrufen.
Man kann sich eine Sicherheitsarchitektur wie das Schweizer-Käse-Modell vorstellen: Jede Ebene hat Schwachstellen (Löcher). Compliance-Prüfungen in der Pipeline fangen Syntax-Fehler und Compliance-Verstöße ab, können aber umgangen werden (z.B. durch manuelle Änderungen in der Konsole oder GUI). Erst durch eine passende Scheibe, wie z.B. die Cloud Policy Engine, entsteht eine potenziell undurchdringliche Wand.

Exkurs: Was fordert die Regulatorik?
In regulierten Branchen ist eine reine Shift-Left-Prüfung nicht ausreichend, da viele Anforderungen explizit laufzeitbezogene Kontrollen verlangen. Dazu gehören insbesondere:
- BAIT (Kapitel 5 & 8): fordert restriktive, technisch durchgesetzte Berechtigungen sowie eine kontinuierliche Überwachung des Betriebs.
- DORA (Artikel 9): verlangt eine fortlaufende Überwachung des tatsächlichen Betriebszustands und technische Mechanismen, die Abweichungen im laufenden Betrieb erkennen oder verhindern.
- BSI C5 (OIS-03): fordert automatisierte Sicherheitskontrollen und überprüfbare Mechanismen, die sichere Konfigurationen dauerhaft gewährleisten.
Um diese Anforderungen zu erfüllen, muss einerseits der Code in den Pipelines validiert werden, und andererseits müssen auf der Plattform selbst Policies aktiv sein, die unerwünschte Änderungen zur Laufzeit erkennen oder verhindern.
Architektur und Sprache: Azure JSON-Policies vs. GCP CEL-Constraints
Azure Policies basieren auf JSON-Definitionen, die tief in den Azure Resource Manager (ARM) greifen. Diese Sprache ist durch die Nutzung von Property Aliases und Funktionen wie count mächtig und flexibel, neigt aber dazu, in komplexen Anwendungsfällen unübersichtlich zu werden. Jede Policy besteht aus einer logischen Bedingung und einem Effekt (z.B. Audit, Deny oder DeployIfNotExists).
Die GCP setzt auf die Common Expression Language (CEL), die bewusst einfach und nicht Turing-vollständig ist, um schnelle bzw. deterministische Auswertungen zu garantieren. Ein Ausdruck wie „resource.management.autoUpgrade == false“ ist deutlich lesbarer als das Azure-Pendant, ist aber in manchen Anwendungsfällen weniger flexibel. Dazu werden zwischen Boolean-Constraints (aktivieren/deaktivieren von Funktionen) Listen-Constraints (Allow/Deny-Listen) und Custom Constraints (eigene Regeln) in der GCP getrennt.
Beide Clouds vererben Regeln hierarchisch von oben nach unten:
Azure priorisiert stets die härteste Regel (Deny > Audit).
GCP kann Regeln je nach Typ zusammenführen oder überschreiben. Eine untergeordnete Ebene kann also eine vererbte Regel der Organisation außer Kraft setzen.
Enforcement & Audit
Hier kommen wir zum kritischen Kern des Vergleichs. Wie testen wir Policies, bevor sie live gehen, und wie überwachen wir den Bestand?
Azure: integriertes Audit & klare Sichtbarkeit
Azure bietet ein vollständig integriertes Auditing. Wird eine Policy mit dem Effekt Audit zugewiesen, erhält man sofort eine vollständige Bestandsanalyse im Compliance-Dashboard. Somit werden Verstöße ohne Blockade identifiziert. Dies erlaubt es, die Auswirkungen einer neuen Policy vor der Aktivierung des Deny-Effekts umfassend zu verstehen. Die Ergebnisse sind visuell aufbereitet und erfordern keine manuellen Abfragen in Logs, was die Usability stark vereinfacht.
GCP: Dry Run, Logs und Policy Analyzer
In der Google Cloud sind Test- und Audit-Funktionen weniger einheitlich umgesetzt:
Dry Run prüft nur neue API-Transaktionen („Würde dieser Call blockiert werden?“).
Es ist kein Bestands-Scan.Ergebnisse werden nicht in einem UI angezeigt, sondern erscheinen im Log Explorer als „dryRunResult“.
Der Security Command Center (SCC) deckt allgemeine Sicherheitsstandards (CIS, PCI-DSS) ab, berücksichtigt Custom Constraints jedoch nur über zusätzliche Security-Health-Analytics-Module.
Bestandsanalysen erfolgen über den Policy Analyzer, ein separates Werkzeug oder der Policy Simulation. Beides kann nicht für mehrere Policies bei Verfügbarkeit gleichzeitig durchgeführt werden.
Infrastructure as Code (Terraform)
Egal welche Cloud, die Verwaltung sollte immer über Code erfolgen. Sowohl Azure als auch GCP lassen sich sauber über Terraform verwalten. Azure bietet jedoch nativ noch zusätzlich Objekte, wie „Policy Sets“ (Gruppierungen von Policies) und „Exemptions“ für temporäre oder begründete Ausnahmen. GCP bietet weder Policy-Gruppierungen noch native Exemptions in vergleichbarer Form.
Fazit: Was lässt sich aus dem Vergleich ableiten?
Shift-Left ist notwendig, aber nicht ausreichend. Schnelles Feedback in der Pipeline hilft bei der Prävention, doch Sicherheit und Compliance müssen zusätzlich zur Laufzeit technisch durchgesetzt werden.
Azure bietet hierfür ein stark integriertes Governance-Erlebnis: Policies, Auditing und Dashboarding greifen nahtlos ineinander und machen den Plattformzustand unmittelbar sichtbar.
GCP verfolgt einen technisch eleganten Ansatz mit klarer CEL-Syntax, verteilt die notwendigen Werkzeuge jedoch auf mehrere Stellen. Dry Run, Log Explorer, SCC und Policy Analyzer müssen zusammenspielen, was die Bedienung komplexer macht.
Terraform funktioniert in beiden Clouds zuverlässig, allerdings stellt Azure mit Policy Sets und Exemptions zusätzliche Governance-Objekte bereit, die den operativen Betrieb vereinfachen.
Für Organisationen mit hohen regulatorischen Anforderungen ist Azure damit primär das insgesamt rundere Governance-Modell. GCP ist leistungsfähig, verlangt jedoch eine bewusstere Betriebsstrategie und ein tieferes Verständnis der Grenzen seiner Policy-Mechanismen.
Empfehlung für die Praxis
Egal welche Cloud eingesetzt wird: Verlassen Sie sich nie auf nur eine Ebene. Eine Compliance-Prüfung in der CI/CD-Pipeline liefert Geschwindigkeit und gutes Entwicklererlebnis („Shift Left“), doch für die tatsächliche Sicherheit sollten stets die nativen Plattform-Policies maßgeblich sein.
Azure bringt ein stark gereiftes, gut integriertes Governance-System mit. Dennoch ist Compliance nur eines von vielen Kriterien bei der Auswahl einer Public Cloud; Architektur, Integrationsfähigkeit, Produktportfolio, Kostenmodell und Team-Know-how bleiben ebenso entscheidend.
Beide Anbieter entwickeln ihre Plattformen kontinuierlich weiter. Die heute beschriebenen Unterschiede und operativen Herausforderungen können sich daher mit künftigen Releases deutlich verändern oder vollständig entfallen. Governance in der Cloud bleibt ein bewegliches Ziel und die beste Lösung ist meist die, die sowohl technische Entwicklungen als auch regulatorische Anforderungen laufend im Blick behält.