Compliance by Code: Wie automatisierte Policies die Cloud Governance von Unternehmen vereinfachen
Cloud Governance zählt heute zu den zentralen Herausforderungen moderner IT-Landschaften. Plattformen wie Microsoft Azure oder Google Cloud bieten enorme Flexibilität, doch genau darin liegt auch das Risiko: Cloud-Ressourcen sind in Sekunden bereitgestellt, Kontrolle, Sicherheit und Compliance bleiben oft auf der Strecke.
Viele Unternehmen mussten feststellen, dass Cloud-Agilität und Governance nicht automatisch zusammenpassen. Wenn ein Entwickler "mal eben“ eine VM oder ein Storage anlegt, kann er unbeabsichtigt Datenschutzrichtlinien verletzen, Kosten in die Höhe treiben oder bestehende Sicherheitsvorgaben umgehen. Was in der On-Prem-Welt durch Prozesse, Tickets und manuelle Freigaben geregelt war, geschieht in der Cloud inzwischen automatisiert in wenigen Minuten und ist damit ebenso schnell missbrauchbar.
Cloud Governance im Nebel
Ein zentrales Problem ist die fehlende Sichtbarkeit. Große Unternehmen betreiben oft hunderte Cloud-Umgebungen, häufig mit unterschiedlichen Sicherheitsniveaus oder eben überhaupt keinem. Wer nicht genau weiß, welche Cloud-Ressourcen wo laufen, kann keine fundierten Aussagen zur Compliance treffen. Schatten-IT wird so zur realen Bedrohung: Selbst wenn die Informationssicherheit (2nd Line) Richtlinien definiert, bleiben sie oft wirkungslos, wenn Teams eigenständig ohne Leitplanken in der Cloud agieren.
Hinzu kommen Inkonsistenzen: Manche Teams dokumentieren sorgfältig, andere gar nicht. Manche Umgebungen sind abgesichert, andere experimentelle Spielwiesen, wo dann doch wieder vertrauliche Daten landen. Und genau für diese stufenweise Härtung in der Cloud sollten Stages existieren, welche den Entwicklern den notwendigen Freiraum mit flexiblen Leitplanken ermöglichen und step-by-step mit sicheren Cloud-Ressourcen in die Produktion gelangen können.
Vom Regelwerk zur Automatisierung
Viele Unternehmen versuchen Cloud Governance über manuelle Kontrollen oder zentrale Cloud-Teams sicherzustellen. Doch dieser Ansatz ist nicht skalierbar. Wenn jede Cloud-Ressource manuell geprüft werden muss, leidet die Innovationsgeschwindigkeit sofort. Entwickler empfinden Sicherheits- und Compliance-Checks dann als Bremse und suchen Wege, sie zu umgehen. Spätestens hier stößt klassische Compliance an ihre Grenzen. Statt nachträglicher Prüfung braucht es Governance, die von Anfang an mitläuft, kurz: "Compliance by Code".
Compliance by Code – Härtungsgrade für jede Stage
"Compliance by Code" bedeutet, dass Sicherheits- und Governance-Regeln als Code definiert und wie Anwendungen oder Infrastruktur behandelt werden. Policies sind somit keine starren Dokumente mehr, sondern können versioniert, getestet und automatisiert ausgerollt werden.
Der entscheidende Vorteil: Cloud Policies können stufenweise eingeführt werden. In einer LAB Stage gelten nur grundlegende Sicherheitsrichtlinien (sog. "Redlines", welche sich durch alle Stages ziehen), z.B. untersagter Public Access. Gleichzeitig den Teams aber dennoch maximale Experimentierfreiheit lassen. Neue Services können dort ungehindert ausprobiert werden.
In der DEV Stage werden die Policies dann erweitert, etwa um Vorgaben zur Verschlüsselung, Netzsegmentierung oder Backup & Recovery. Schließlich greift in der PROD Stage ein vollständiges Set aus Sicherheitsvorgaben, das sicherstellt, dass produktive Cloud-Ressourcen vollständig konform und gehärtet betrieben werden.
So entsteht ein kontrollierter Reifeprozess:
- Freiheit in der "Labor"-Entwicklung, um Innovation und Flexibilität nicht zu behindern
- stufenweise Härtung, damit jede Stage sicherer wird
- Compliance Integration: Entwickler müssen keine separaten Checklisten abarbeiten, sondern der Compliance-Check läuft automatisch im Hintergrund mit, wo der Status eingesehen werden kann.
- automatisierte Durchsetzung, um menschliche Fehler zu vermeiden
Cloud Governance als Enabler, nicht als Hürde
Anstelle manueller Prüfprozesse definieren Unternehmen wiederverwendbare Policy Sets, die in allen Projekten gemäß entsprechender (Entwicklungs-)Stage greifen. Teams wissen genau, innerhalb welcher Grenzen sie sich bewegen können, und Security-Teams konzentrieren sich anstatt auf Standardfehler eher auf Sonderfälle, welche ggfs. Security-Ausnahmen benötigen.
Erstellung via Policy as Code mit unternehmensspezifischen Anpassungen
Policy as Code (PaC) ist das Fundament moderner Cloud Governance. Anstatt Sicherheitsrichtlinien in PDF-Dokumenten oder internen Wikis zu pflegen, werden sie in Codeform wie YAML oder JSON definiert und automatisiert durchgesetzt, ähnlich wie Anwendungen oder Infrastruktur bspw. in Terraform. Damit lassen sich Sicherheitsvorgaben direkt in Cloud-Umgebungen oder vorweg in CI/CD-Pipelines integrieren, ohne manuelle Eingriffe oder Interpretationsspielräume.
Cloud Policies als Code
Im Kern beschreibt eine Policy, welche Bedingungen erfüllt sein müssen, damit eine Ressource konform ist. Sie bildet also ein Regelwerk, das automatisch gegen Cloud-Konfigurationen geprüft wird (beim Deployment, in CI/CD-Pipelines oder durch kontinuierliche Compliance-Scans).
- Typische Anwendungsfälle sind:
- Storage Accounts müssen mit Kundenschlüsseln (Customer-managed Keys - CMK) verschlüsselt sein
- keine öffentlichen IPs (Public Access) erlaubt
- Einsatz von privaten Endpoints oder auch Cloud-nativen Identitäten (Managed Identity – Azure oder Service Account – Google Cloud)
Beispiel: Definition von Azure Policies & Google Cloud Org Policies
Disclaimer: Alle nachfolgenden Code-Beispiele wurden natürlich für den Demo-Part abgeändert bzw. anonymisiert :-)
Ein Beispiel aus der Praxis verdeutlicht, wie einfach sich eine Sicherheitsanforderung als Code definieren lässt. Ein klassisches Beispiel sind Azure Policies, die Richtlinien in JSON- oder YAML-Form beschreiben. Eine Regel kann folgendermaßen aussehen:
# Definition - Built-in Policy in Azure
{
"properties": {
"displayName": "Storage account public access should be disallowed",
"policyType": "BuiltIn",
"mode": "Indexed",
"description": "Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it.",
"metadata": {
"version": "3.1.1",
"category": "Storage"
},
"version": "3.1.1",
"parameters": {
"effect": {
"type": "string",
"metadata": {
"displayName": "Effect",
"description": "The effect determines what happens when the policy rule is evaluated to match"
},
"allowedValues": [
"audit",
"Audit",
"deny",
"Deny",
"disabled",
"Disabled"
],
"defaultValue": "Audit"
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"allOf": [
{
"field": "id",
"contains": "/resourceGroups/aro-"
},
{
"anyOf": [
{
"field": "name",
"like": "cluster*"
},
{
"field": "name",
"like": "imageregistry*"
}
]
}
]
}
},
{
"not": {
"field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
},
"versions": [
"3.1.1",
"3.1.0-PREVIEW"
]
},
"id": "/providers/Microsoft.Authorization/policyDefinitions/4fa4b6c0-31ca-4c0d-b10d-24b96f62a751",
"name": "4fa4b6c0-31ca-4c0d-b10d-24b96f62a751"
}Diese Azure Policy prüft bzw. auditiert (Default-Wert), ob ein Storage Account den anonymen öffentlichen Zugriff auf Container/Blobs deaktiviert hat. Wenn man den Effekt auf "deny" ändert, wird bei Unstimmigkeit das Deployment in Azure automatisch abgelehnt, bevor die Cloud-Ressource überhaupt erstellt wird.
Ein ähnlicher Mechanismus existiert in der Google Cloud (GCP). An dieser Stelle dargestellt über eine Custom GCP Policy:
# Definition – Custom Policy in GCP
name: organizations/1234567890123/customConstraints/custom.preventpublicaccesstobucktsandobjects
resourceTypes:
- storage.googleapis.com/Bucket
methodTypes:
- CREATE
- UPDATE
condition: "!has(resource.ipFilter) || (resource.ipFilter.mode == 'Disabled' || resource.ipFilter.publicNetworkSource.allowedIpCidrRanges.size() > 0)"
actionType: DENY
displayName: Prevent public access to buckets and objects
description: Prevents unintentional exposure of data to the public internet.Hier auch nochmal vereinfacht über eine vorhandene Built-in GCP Policy:
# Definition – Built-in Policy in GCP
constraints/storage.publicAccessPrevention
enforce = "TRUE"Unternehmensspezifische Anpassungen
In der Praxis nutzt jedes Unternehmen eigene Sicherheits- und Governance-Vorgaben, die über Standard-Frameworks hinausgehen. Während Cloud-Anbieter viele Basisrichtlinien mitbringen, müssen Unternehmen häufig zusätzliche Anforderungen definieren, insbesondere im regulierten Umfeld oder bei Multi-Cloud-Szenarien.
Typische Regeln, wo oftmals unternehmensspezifische Anpassungen notwendig werden, sind folgende:
- Verschlüsselung: Kundenschlüssel statt Plattformschlüssel (Azure Key Vault, GCP KMS)
- Netzwerkzugriffe: keine Zugriffe in bestimmte virtuelle Netzwerke (Notwendigkeit von VNET Peering) oder fremde Azure Tenants bzw. andere Google Organizations
- Service-Freigaben: nur definierte Dienste oder Regionen für produktive Cloud-Ressourcen (Whitelisting)
Ein Beispiel für unternehmensspezifische Azure Policies, mit welchen der Public Access für Proxy IPs des Unternehmens ermöglicht wird:
# Defintion - Custom Policy in Azure
{
"Name": "5wgfh584-ez54-dg43-2sgr-4gdgfz753ads",
"ResourceId": "/providers/Microsoft.Management/managementGroups/companyname/providers/Microsoft.Authorization/policyDefinitions/5wgfh584-ez54-dg43-2sgr-4gdgfz753ads",
"ResourceName": "5wgfh584-ez54-dg43-2sgr-4gdgfz753ads",
"ResourceType": "Microsoft.Authorization/policyDefinitions",
"SubscriptionId": null,
"Properties": {
"Description": "Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts. Excluded from this rule are specified IP adresses owned by company (e.g. proxies)",
"DisplayName": "Custom_Storage_accounts_should_restrict_network_access_using_virtual_network_rules-Company_owned_IP_adresses_allowed",
"Metadata": {
"category": "CUSTOM-storage"
},
"Mode": "All",
"Parameters": {
"effect": {
"type": "String",
"metadata": {
"displayName": "Effect",
"description": "Enable or disable the execution of the audit policy"
},
"allowedValues": [
"Audit",
"Deny",
"Disabled"
],
"defaultValue": "Audit"
},
"allowedipaddresses": {
"type": "Array",
"metadata": {
"displayName": "Allowed IP Adresses CIDR",
"description": "Allowed IP Adresses CIDR for public access"
}
}
},
"PolicyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "Microsoft.Storage/storageAccounts/publicNetworkAccess",
"notEquals": "Disabled"
},
{
"anyOf": [
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
"notEquals": "Deny"
},
{
"allOf": [
{
"count": {
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]"
},
"greaterOrEquals": 1
},
{
"count": {
"value": "[parameters('allowedipaddresses')]",
"name": "allowedIpAddresses",
"where": {
"value": "[ipRangeContains(current('allowedIpAddresses'), first(field('Microsoft.Storage/storageAccounts/networkAcls.ipRules[*].value')))]",
"equals": true
}
},
"equals": 0
}
]
}
]
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
},
"PolicyType": "Custom"
},
"PolicyDefinitionId": "/providers/Microsoft.Management/managementGroups/companyname/providers/Microsoft.Authorization/policyDefinitions/5wgfh584-ez54-dg43-2sgr-4gdgfz753ads"
}# Anpassung der Custom Policy, um Proxy IPs des Unternehmens konkret anzugeben
{
"policyDefinitionReferenceId": "Custom Storage accounts should restrict network access using virtual network rules - Company owned_1",
"policyDefinitionId": "/providers/Microsoft.Management/managementGroups/companyname/providers/Microsoft.Authorization/policyDefinitions/5wgfh584-ez54-dg43-2sgr-4gdgfz753ads",
"parameters": {
"effect": {
"value": "Deny"
},
"allowedipaddresses": {
"value": [
"194.XXX.XXX.0/24",
"195. XXX.XXX.0/24",
"195. XXX.XXX.0/24"
]
}
},
"groupNames": [
"Custom"
]
}Integration in DevOps Workflows
Die technische Integration erfolgt dabei meist nach einem dreistufigen Prinzip:
- Validierung vor dem Deployment (Pre-Deployment): Policies prüfen Infrastructure as Code (Terraform etc.), bevor sie ausgerollt werden. Nicht konforme Ressourcen können direkt blockiert werden (Deny).
- Kontinuierliche Überwachung (Runtime): Laufende Ressourcen werden regelmäßig gegen die definierten Policies geprüft (Compliance Dashboard).
- Korrektur (Remediation): Verstöße lassen sich beheben, z. B. durch Aktivierung von Verschlüsselung oder Entfernen öffentlicher IPs.
Damit wird Compliance zu einem kontinuierlichen Prozess. Änderungen an der Cloud-Infrastruktur sind nur dann erfolgreich, wenn sie die definierten Regeln einhalten. Unabhängig davon, durch welche Entwickler oder in welcher Pipeline sie ausgeführt werden.
Ein solcher automatischer Workflow entlastet operative Security-Teams (1st Line) und Informationssicherheit (2nd Line) erheblich. Statt jeden Azure Tenant oder jede Google Organization manuell zu prüfen, konzentrieren sie sich auf die Erstellung und die Weiterentwicklung der Cloud Policies selbst.
Entwicklungsteams erhalten klare Leitplanken, ohne deren Flexibilität einzuschränken. Compliance ist dadurch von Anfang an integriert und wird nicht nachträglich aufgesetzt. Sie ist als zentraler Bestandteil des Entwicklungszyklus von Cloud-Ressourcen etabliert.
Assignment und Deployment von Cloud Policies je Stage (LAB, DEV, PROD)
Sobald Cloud Policies als Code vorliegen, beginnt ein entscheidender Teil:
Zuweisung und Bereitstellung. Denn diese können erst Wirkung zeigen, wenn sie in der Cloud-Umgebung angewendet werden, also einem konkreten Scope und Stage zugewiesen sind.
Von der Definition zur aktiven Cloud Policy
In Azure oder Google Cloud besteht die Policy-Verwaltung in der Regel aus drei Elementen:
- Definition: Die eigentliche Sicherheitsvorgabe, die beschreibt, was erlaubt oder verboten ist
- Assignment: Die Zuweisung der Policy an einen Scope und Stage. So können bspw. über die Tenant-/Organisationsebene globale Sicherheitsvorgaben für das gesamte Unternehmen, z. B. verpflichtende Verschlüsselung oder Einschränkung der Region (z.B. Europa) gelten oder über die Management Group/Folder-Ebene entsprechend gruppierte Policies für Use Cases, Projekte oder auch geeignet für die Umsetzung einer stufenweisen Umgebung (Stages).
| Cloudprovider | Azure | GCP |
| Tenant | Organization | |
| Scope (Verwaltungsebene) | Management Group | Folder |
| Subscription | Project | |
| ResourceGroup | - | |
| Ressource | Ressource |
In einer stufenweisen Umgebung (LAB => DEV => PROD) können Policies differenziert ausgerollt werden:
| Stage | Effekt | Beschreibung |
| LAB | Audit | Verstöße werden lediglich protokolliert (audit-Effekt) z. B. wenn ein Storage-Account öffentlich erreichbar ist oder die Verschlüsselung nicht mit einem Kundenschlüssel (CMK) erfolgt. Entwickler sehen die Warnung, werden aber nicht blockiert und können trotzdem deployen (Lernhilfe im „Labor“). |
| DEV | Audit + Deny | Erste automatische Enforcement-Mechanismen greifen. Ein unsicherer Zugriff oder fehlende Verschlüsselung kann hier bereits das Deployment blockieren oder eine Warnung auslösen, um Fehlkonfigurationen frühzeitig abzufangen (Spielraum für Anpassungen). |
| PROD | Deny | Es gilt schließlich durchgängige Compliance: Verstöße führen unmittelbar zu einer Ablehnung (deny-Effekt) des Deployments oder zur automatischen Remediation (deployIfNotExist). Dadurch bleibt die Produktivumgebung stabil und sicher, während Flexibilität in der Entwicklung in früheren Phasen möglich bleibt. |
3. Enforcement durch Rollout: Die technische Durchsetzung (Aktivierung) der
Cloud Policies.
Eine Policy Definition allein ist somit noch wirkungslos. Sie wird erst aktiv, wenn sie entsprechend zugewiesen wird. So kann ein Unternehmen etwa festlegen, dass Sicherheitsvorgaben zur zentralen Authentifizierung, wie bspw. "Storage accounts should prevent shared key access" nur für PROD-Umgebungen gelten, während in DEV-Umgebungen dieselbe Policy lediglich Warnungen ausgibt, da an dieser Stelle noch lokale Authentifizierungsmöglichkeiten vorhanden sind.
Automatisiertes Deployment über CI/CD-Pipelines
Cloud-Policies werden heute behandelt wie Anwendungen: aus einem zentralen Repository versioniert, überprüft und automatisiert ausgerollt. Über CI/CD werden bei Änderungen an dem durch die operativen Security-Teams (1st-Line) verwalteten Cloud-Policies automatisch Build- und Deployment Prozesse ausgelöst (z. B. via GitLab CI).
Beispiel: Assignment und Deployment von Cloud-Policies
Auf ein Beispiel zur Policy-Definition wird an dieser Stelle verzichtet, da Beispiele bereits in Kap. 2 „Erstellung via Policy as Code“ vorgestellt worden sind, in welcher auch der „Effekt“ festgelegt wird.
Dabei ist gut zu wissen, dass aus den einzelnen Policy-Definitions (siehe Kap. 2) ein gruppiertes Policy-Set erstellt werden kann, welches bspw. das Policy-Set für die DEV-Stage darstellen kann und im weiteren Verlauf nur noch zugewiesen werden muss.
Im Nachfolgenden möchte ich anhand von Beispielen das Assignment je Scope und Stage verdeutlichen:
# Zuweisung eines PolicySets auf Management Group-Ebene in Azure
{
"Identity": {
"PrincipalId": null,
"TenantId": null,
"IdentityType": "UserAssigned",
"UserAssignedIdentities": {
"/subscriptions/eo396755-5957-4a9f-81d3-e93659616c21/resourcegroups/rg-companyname/providers/Microsoft.ManagedIdentity/userAssignedIdentities/mi-companyname-Policy-Contributor": {
"PrincipalId": "653f62dd-55ef-4ddd-9d04-52765f3ra6f7",
"ClientId": "3370b6b8-c446-4d5c-9cf6-b4de39b096b5"
}
}
},
"Location": "westeurope",
"Name": "15b5v26708d3s3d4eb80dcf3",
"ResourceId": "/providers/Microsoft.Management/managementGroups/PolicyDev/providers/Microsoft.Authorization/policyAssignments/15b5v26708d3s3d4eb80dcf3",
"ResourceName": "15b5v26708d3s3d4eb80dcf3",
"ResourceGroupName": null,
"ResourceType": "Microsoft.Authorization/policyAssignments",
"SubscriptionId": null,
"Sku": null,
"PolicyAssignmentId": "/providers/Microsoft.Management/managementGroups/PolicyDev/providers/Microsoft.Authorization/policyAssignments/15b5v26708d3s3d4eb80dcf3",
"Properties": {
"Scope": "/providers/Microsoft.Management/managementGroups/PolicyDev",
"NotScopes": null,
"DisplayName": "Policy-Storage-Dev",
"Description": "Umsetzung der Cloud-Policies Storage fuer die Entwicklungs-Stufe (Dev).",
"Metadata": {
"assignedBy": "Vorname Nachname",
"parameterScopes": {}
},
"EnforcementMode": "Default",
"PolicyDefinitionId": "/providers/Microsoft.Management/managementGroups/companyname/providers/Microsoft.Authorization/policySetDefinitions/5d1e8d32-7198-4r61-2c42-8d91bcfe4a7t",
"Parameters": {},
"NonComplianceMessages": null
}
}
Dieser Code sorgt dafür, dass die Policy in der angegebenen Management Group (hier DEV-Stage) automatisch aktiviert wird. Der Code-Stand im Repository definiert den Zielzustand (SOLL) der Compliance.
Eine ähnliche Vorgehensweise lässt sich in GCP auf Folder-Ebene (ebenfalls DEV-Stage) abbilden:
# Zuweisung mehrerer GCP Policies auf Folder-Ebene (DEV-Stage mit taget_id)
module "cloud_storage_policydev" {
source = "../../gcp-terraform-policy-modules/policy"
# Bereich [ lab | dev | prod ] auf dem das Assignment wirken soll
target_type = "folders"
target_id = "342426567081"
constraint = each.key
inherit_from_parent = false
policy_rules = [each.value]
for_each = {
# GCP-NS-CST-T-1
"storage.publicAccessPrevention" = {
enforce = "TRUE"
},
# GCP-NS-CST-T-2
"storage.secureHttpTransport" = {
enforce = "TRUE"
},
# GCP-IM-CST-T-1
"storage.uniformBucketLevelAccess" = {
enforce = "TRUE"
},
# GCP-IM-CST-T-3
"storage.restrictAuthTypes" = {
denied_values = ["in:ALL_HMAC_SIGNED_REQUESTS"]
}
}
}
Kontinuierliches Monitoring der Compliance
Cloud-Umgebungen verändern sich permanent: Neue Ressourcen entstehen, alte werden gelöscht, Konfigurationen ändern sich. Ohne ein kontinuierliches Monitoring der Compliance bleibt unklar, ob die Sicherheitsvorgaben auch dauerhaft eingehalten werden. Deshalb setzen moderne Plattformen wie Microsoft Azure und Google Cloud Platform (GCP) auf integrierte Mechanismen, um Policy-Verstöße fortlaufend zu erkennen, zu bewerten und visuell darzustellen. Somit wird Compliance nicht punktuell geprüft, sondern kann an zentraler Stelle kontinuierlich bewertet werden.
Automatisiertes Monitoring als Dauerprozess
Sobald Policies in der Cloud aktiviert sind, läuft das Monitoring meist vollständig automatisiert ab. Die Cloud-Plattform scannt regelmäßig alle Ressourcen und gleicht deren Konfiguration mit den hinterlegten Soll-Zustand der definierten und zugewiesenen Cloud-Policies ab.
Azure bietet dafür das Azure Compliance-Dashboard, welches anzeigt:
- wie viele Cloud-Ressourcen konform sind,
- welche Policies am häufigsten verletzt werden,
- und welche Cloud-Ressourcen besondere Aufmerksamkeit erfordern.
In der Google Cloud liefert das Security Command Center (SCC) Dashboard und die Security Health Analytics (SHA)-Reports vergleichbare Einblicke. Dort werden Verstöße in Kategorien wie Network, Storage, IAM oder Encryption zusammengefasst.
Der Ablauf ist in beiden Welten vergleichbar:
- Evaluierung: Jede Ressource wird regelmäßig gegen alle aktiven Cloud-Policies geprüft.
- Status-Ermittlung: Der Compliance-Status ("compliant" / "non-compliant") wird pro Cloud-Policy und Ressource dargestellt.
- Aggregation: Mögliche Zusammenfassung auf höheren Ebenen (Subscription, Project, Management Group)
- Reporting: Verstöße werden in Dashboards und Reports visualisiert.
So entsteht ein dauerhafter Compliance-Check, der sichtbar macht, ob Infrastruktur und Deployments noch dem gewünschten Soll-Zustand in der Cloud entsprechen.
Stage-spezifische Compliance (LAB, DEV, PROD)
Wie anfangs erwähnt, braucht nicht jede Umgebung denselben Compliance-Druck. Zu strenge Regeln in frühen Phasen bremsen Flexibilität der Entwickler. Daher setzen viele Unternehmen auf ein gestuftes Monitoring-Modell.
In der LAB-Stage sollen Policies dargestellt werden, welche im weiteren Verlauf verletzt werden. Entwickler sollen frühzeitig einen Hinweis erhalten und gleichzeitig ihre Cloud-Ressourcen weiter testen können.
In der DEV-Stage hingegen erfolgt die Kombination aus Blockierung und Warnung, um Flexibilität zum Reagieren anzubieten.
Schließlich in der PROD-Stage werden alle Policies mit Deny-Effekt durchgesetzt, wodurch keine Abweichungen mehr zulässig sind und keine Non-Compliance mehr dargestellt wird (auch mit ggfs. notwendigen Security-Ausnahmen, beschreibe ich im weiteren Verlauf)
Security-Ausnahmen (Exemptions) as Code
So konsequent Cloud-Compliance mit Policies umgesetzt werden kann, in der Praxis gibt es immer wieder Ausnahmesituationen, die sich nicht vollständig standardisieren lassen. Bestimmte Cloud-Ressourcen brauchen aufgrund spezieller Gegebenheiten bewusst eine Ausnahme von der Regel. Genau dafür existiert das Konzept der technischen Exemptions: Befristete Security-Ausnahmen, die trotzdem transparent und nachvollziehbar bleiben.
Warum Ausnahmen vereinzelnd nötig sind
Automatisierte Cloud-Policies sorgen zwar für Konsistenz, können aber in bestimmten Situationen gerade in der Cloud zu starr sein. Das Grundprinzip ist simpel: Eine Ausnahme wird nicht mündlich oder per E-Mail genehmigt, sondern als Exemption-Definition in Codeform gepflegt.
Typische Fälle, in denen Ausnahmen nötig werden, sind:
- PoC- oder Migrationsprojekte, die temporär außerhalb der Standards laufen
- Eingesetzte Hersteller, mit ggf. technischen Limitierungen
- Laufzeitprobleme, die eine temporäre Ausnahme (z.B. zum nur zum Aufbau) benötigen
- Eingesetzte Legacy-Systeme oder OnPrem-Systeme, die alte Sicherheitsmechanismen nutzen oder schlichtweg noch kein cloud-nativer Dienst verwendet wird
Der große Vorteil von Exemptions as Code ist nicht, dass Sicherheitsvorgaben umgangen werden dürfen, sondern dass jede Abweichung dokumentiert, nachvollziehbar und befristet bleibt und stets einem Review des operativen Security-Teams (1st-Line) unterzogen werden.
In der Praxis entsteht dadurch ein Governance-Prozess mit definiertem Entscheidungsprozess:
- Antrag: Ein Entwicklerteam stellt eine Ausnahme als Ticket (bspw. JIRA)
- Review: Security-Team prüft Begründung, Scope und Zeitrahmen.
- Genehmigung: Nach Freigabe wird die Exemption im Repository erstellt und anschließend ausgerollt. Jede Ausnahme ist nachvollziehbar und Teil des Repositorys.
- Monitoring: Die gültige Ausnahme wird automatisch berücksichtigt, sodass keine Non-Compliance mehr dargestellt wird.
So entsteht eine saubere Trennung zwischen bewusst genehmigtem Risiko und ungewollter Non-Compliance. Es kann jederzeit nachvollzogen werden, wann, warum und von wem eine Security-Ausnahme genehmigt wurde.
Beispiel: Exemption Definition als Code
Die folgenden Beispiele zeigen eine vereinfachte JSON- bzw. YAML-Definition für eine Exemption in einer Azure- sowie GCP-Policy-Umgebung anhand der dokumentierten Grundlage aus dem JIRA-Ticket.
Der Zugriff auf die Storage Accounts in der hier benannten Ressource Group darf innerhalb der PROD Stage temporär über Shared Keys und ohne SAS-Richtlinien erfolgen.
# Exemption mehrerer Azure Policies
{
"PolicyAssignmentId": "/providers/Microsoft.Management/managementGroups/PolicyProd/providers/Microsoft.Authorization/policyAssignments/6e7e4332559d9r3c08f2971s",
"PolicyDefinitionReferenceIds": [
"Storage accounts should prevent shared key access",
"Storage accounts should have shared access signature (SAS) policies configured"
],
"ExemptionCategory": "Mitigated",
"DisplayName": "rg-companyname-prod-001 - Policy-Storage - TicketNr – TenantName",
"Description": "Abweichung gem. TicketNr",
"ExpiresOn": null,
"Metadata": {},
"SystemData": null,
"Name": "7a5352621963491cdb82e914",
"Id": "/subscriptions/cdae3b04-0a8e-4931-9bde-4ade43d66926/resourceGroups/rg-companyname-prod-001/providers/Microsoft.Authorization/policyExemptions/7a5352621963491cdb82e914",
"ResourceName": "7a5352621963491cdb82e914",
"ResourceGroupName": "rg-companyname-prod-001",
"ResourceType": "Microsoft.Authorization/policyExemptions",
"SubscriptionId": " cdae3b04-0a8e-4931-9bde-4ade43d66926"
}Bei jedem Scan wird erkannt, dass die Cloud-Ressourcen zwar gegen diese beiden Storage Policies verstoßen, aber durch eine gültige Exemption gedeckt sind.
Das Beispiel der Exemption im GCP-Umfeld ermöglicht, dass der benannte Folder trotz der übergeordneten Einschränkung weiterhin "interconnect" nutzen darf, also von der zentralen Zugriffsbeschränkung ausgenommen ist.
# Exemption einer GCP Policy
module "allow_dedicatedinterconnectusage_policyprod_folder_network" {
source = "../gcp-terraform-policy-modules/policy"
for_each = {
# GCP-NS-NETW-T-18
"compute.restrictDedicatedInterconnectUsage" = {
allowed_values = ["under:folders/341392481021"]
}
}
target_id = "341392481021"
target_type = "folders"
constraint = each.key
inherit_from_parent = false
policy_rules = [each.value]
}
Fazit
Cloud Governance war lange ein Balanceakt zwischen Sicherheit und Flexibilität. Zu viele Sicherheitsvorgaben, unklare Ausnahmen, zu wenig Transparenz. Mit dem Ansatz "Compliance by Code" ändert sich das grundlegend: Sicherheitsvorgaben werden selbst zu Code - automatisiert und nachvollziehbar über alle Stages hinweg.
Cloud Policies prüfen Infrastruktur noch vor dem Deployment, erkennen Verstöße automatisiert und härten Cloud-Umgebungen schrittweise – von LAB über DEV bis PROD. Statt Dokumenten und Checklisten gibt es Richtlinien im Codeformat, die direkt integriert sind. So entsteht die Möglichkeit, Security von Beginn an mitzudenken.
Entwicklerteams behalten ihre Flexibilität, während Security und Compliance vollständige Transparenz über den Ist-Zustand gewinnen. Und wo Security-Ausnahmen notwendig sind, werden sie nachvollziehbar als Exemptions as Code definiert.
Damit wird Cloud Governance nicht länger als Hürde, sondern als Enabler verstanden.
