Policy-Ausnahmen (beantragen, prüfen, deployen)¶

Standardänderung: Policy-Ausnahme.

Auswirkung: Eine Ressource, resource group, subscription oder management group wird für begrenzte Zeit von einer Azure-Policy-Zuweisung ausgenommen. Die Ausnahme ist Code: eine JSON-Datei, die wie jede andere Änderung geprüft, genehmigt und deployt wird.

Diese Seite beschreibt den Prozess für das Plattform-Team. Das JSON-Format und die Ordner stehen unter Policy-Zuweisungen. Die Sicht des workload-Teams steht unter Policy und Ausnahmen. Die Governance-Regel dahinter steht in Governance.

Wann eine Ausnahme die richtige Antwort ist¶

Eine Ausnahme ist die letzte Option. Frage zuerst:

Kann die Ressource so geändert werden, dass sie die Policy erfüllt? Das ist immer besser.
Ist die Policy mit dem richtigen Scope und den richtigen Parametern zugewiesen? Eine falsche Zuweisung ist eine Änderung an der Zuweisung, keine Ausnahme (Policy-Zuweisungen).
Ist das Risiko akzeptiert oder auf andere Weise abgedeckt? Nur dann kommt eine Ausnahme in Frage.

Kategorien¶

Kategorie	Bedeutung	Verwende sie, wenn
Waiver	Das Risiko wird bewusst akzeptiert.	Die Kontrolle passt nicht zur Ressource, und der Owner und Security akzeptieren das Risiko.
Mitigated	Das Risiko wird durch eine andere Kontrolle abgedeckt.	Es gibt eine kompensierende Kontrolle, zum Beispiel ein privater Netzwerkpfad statt eines von der Policy verlangten Private Endpoints. Nenne die Kontrolle in der Beschreibung.

In Azure Policy erscheint die Ressource bei beiden Kategorien als ausgenommen. Der Unterschied liegt in der Dokumentation: Sie sagt einem späteren Leser, ob jemand ein Risiko akzeptiert oder es an anderer Stelle behoben hat.

Anfrage¶

Der Anfragende liefert:

Information	Beschreibung
Policy oder initiative	Der genaue Name oder die ID und die Zuweisung, aus der sie stammt
Scope	Subscription, resource group oder bestimmte Ressourcen. Verwende den kleinsten Scope, der funktioniert.
Kategorie	Waiver oder mitigated
Begründung	Warum die Ressource nicht konform sein kann
Alternative Maßnahmen	Welche anderen Kontrollen das Risiko verringern
Enddatum	Wann die Ausnahme erneut geprüft wird. Wähle einen kurzen Zeitraum, normalerweise höchstens ein Jahr.
Genehmigung	Die Genehmigung des Security Officers, mit Referenz

Prozess¶

Der Ausnahmeprozess hat einen Genehmigungsschritt, bevor Code geschrieben wird. Ein üblicher Aufbau:

flowchart LR
    a["Workload team finds that an exemption is needed"] --> b["Request with justification and end date"]
    b --> c{"Approved by security officer?"}
    c -->|no| d["Change the design"]
    c -->|yes| e["Exemption file in a branch"]
    e --> f["Pull request linked to the ticket"]
    f --> g["Automatic checks of the file"]
    g --> h["Approval of the pull request"]
    h --> i["Pipeline deploys the exemption"]

Das workload-Team stellt die Anfrage. Das Plattform-Team prüft, ob die Felder vollständig sind.
Der Security Officer (oder das Gremium, das in deiner Organisation über Ausnahmen entscheidet) genehmigt oder lehnt die Anfrage ab.
Das Plattform-Team erstellt einen Branch und fügt die Ausnahme-Datei im Ordner für den jeweiligen Scope hinzu (policies/policy_exemptions/01_management_groups bis 04_resources). Das Datum expires_on wird immer gesetzt.
Ein pull request, verknüpft mit dem Ticket, durchläuft das Pull-request-Review.
Nach der Genehmigung deployt hub den layer postdeployment. Prüfe im portal unter Policy → Exemptions.

Das Register im Repository halten

Der Ordner mit den Ausnahme-Dateien ist das Register. Trage die Ticket-Referenz und die Genehmigung in description ein und prüfe die Dateien regelmäßig auf Ablaufdaten (Betriebsverantwortlichkeiten). Eine Ausnahme ohne Begründung und Enddatum ist in einem Audit schwer zu verteidigen.

Review-Checkliste¶

Prüfung	Warum
Die Genehmigungsreferenz steht im Ticket und in `description`	Der Audit Trail
`expires_on` ist gesetzt und nicht später als das vereinbarte Maximum	Ausnahmen dürfen nicht ewig gelten
Der Scope ist so klein wie möglich	Eine subscription-Ausnahme für eine Ressource verbirgt andere Findings
`policy_definition_ids` listet nur die benötigten Policies. Verwende `[]` nur, wenn die ganze Zuweisung ausgenommen werden muss	Eine Ausnahme für eine ganze initiative schaltet viele Kontrollen ab
Die Zuweisung ist eine initiative-Zuweisung	Ausnahmen für eine Zuweisung einer einzelnen Policy unterstützt das Modul nicht (Ausnahmen)
Die Kategorie passt zur Begründung	Waiver für akzeptiertes Risiko, mitigated für eine kompensierende Kontrolle
Dateiname und `name` sind eindeutig, und der Name lässt Platz für das Suffix des Mirrors (siehe unten)	Das Modul lässt den plan bei einem zu langen Namen fehlschlagen

Ausnahmen und der Secure Score von Defender for Cloud¶

Wenn Microsoft Defender for Cloud für eine subscription aktiv ist, weist Azure der subscription den Microsoft cloud security benchmark (MCSB) als Zuweisung SecurityCenterBuiltIn zu. Das portal zeigt sie als ASC Default. Die Plattform erstellt diese Zuweisung nicht, und sie zu löschen hilft nicht: Defender for Cloud legt sie neu an.

Der Secure Score wird nur aus den Bewertungen dieser Zuweisung berechnet. Die Compliance-Zuweisungen der Plattform sind eigene Zuweisungen, die der Score ignoriert. Eine Ausnahme auf einer Plattform-Zuweisung ist für das Compliance- Reporting richtig, ändert aber den Score nicht: Die Default-Zuweisung markiert dieselbe Ressource weiterhin.

Automatisches Spiegeln¶

Für jede berechtigte Ausnahme erstellt das Policy-Modul eine gespiegelte Ausnahme auf der Zuweisung SecurityCenterBuiltIn der subscription. Dafür änderst du die JSON-Datei nicht.

Der Mirror heißt <original-name>-mcsb, und sein Anzeigename erhält das Suffix (ASC Default).
Kategorie und Ablaufdatum werden vom Original übernommen.
Beide Kategorien sorgen dafür, dass die Ressource nicht mehr als fehlerhaft zählt. Mitigated behandelt die Ressource für diese Empfehlung als gesund, waiver nimmt die Ressource ganz aus der Bewertung heraus.
Die Variable mirror_exemptions_to_mcsb steuert das. Standard ist true; false schaltet das Spiegeln für eine Plattform aus (Feature flags).

Scope der Ausnahme	Gespiegelt	Grund
Subscription	Ja	Die Default-Zuweisung existiert auf subscription-Scope.
Resource group	Ja	Die subscription wird aus der ID der resource group abgeleitet.
Ressource	Ja	Die subscription wird aus der ID der Ressource abgeleitet.
Management group	Nein	Es gibt keine Default-Zuweisung pro management group.

Regeln, die dich schützen:

Eine Ausnahme, die bereits auf die Default-Zuweisung zielt, wird nicht erneut gespiegelt.
Eine Ausnahme mit leerer Liste policy_definition_ids wird nicht gespiegelt. Sie würde die subscription vom gesamten Benchmark ausnehmen.
Nur die Policies, die auch Teil des Benchmarks sind, werden in den Mirror kopiert. Ist keine dabei, wird kein Mirror erstellt.
Namen von Ausnahmen sind auf 64 Zeichen begrenzt. Der Mirror fügt -mcsb hinzu, daher lässt ein Name mit mehr als 59 Zeichen den plan mit einer klaren Fehlermeldung fehlschlagen.

Ausnahmen auf management-group-Scope¶

Eine Ausnahme auf management-group-Ebene erreicht den Secure Score nicht. In der Reihenfolge der Präferenz:

Den Scope verkleinern auf die subscriptions oder Ressourcen, für die sie gilt. Sie ist dann für das Spiegeln berechtigt.
Die Empfehlung deaktivieren in den Parametern der Default-Zuweisung: Defender for Cloud → Environment settings → der Scope → Security policies → Microsoft cloud security benchmark → die Empfehlung ausschalten. Sie wird dann für diesen Scope aus dem Score entfernt.
Den Benchmark auf management-group-Ebene zuweisen über die Security-Policy-Einstellungen von Defender for Cloud, sodass die subscriptions einer zentralen Zuweisung folgen und Ausnahmen an einer Stelle verwaltet werden.

Hinweise zum Betrieb¶

Ein Mirror setzt voraus, dass die Zuweisung SecurityCenterBuiltIn existiert. Sie existiert, sobald Defender for Cloud für die subscription aktiv ist. Bei einer subscription, auf der Defender for Cloud nie aktiviert war, schlägt das apply wegen der fehlenden Zuweisung fehl.
Defender for Cloud wertet alle 12 bis 24 Stunden aus. Rechne mit bis zu 24 Stunden, bis der Secure Score eine neue oder entfernte Ausnahme zeigt.
Mirrors sind normale Ausnahme-Ressourcen, die Terraform verwaltet. Bearbeite sie nicht von Hand im portal.

Ausnahmen, die zur Plattform gehören¶

Neben den Ausnahmen, die workload-Teams beantragen, hat eine Plattform eigene Ausnahmen. Sie existieren, damit die Plattform funktionieren kann, und unterscheiden sich von den Ausnahmen eines workloads: Das Plattform-Team besitzt sie und führt eine Liste mit der Begründung für jede (Ausnahmen dokumentieren, die für die Plattform gelten).

Die üblichen Muster, nach Grund gruppiert. Die aktuelle Liste deiner Version steht in docs/policy_exemptions/current-platform-exemptions.md und im layer postdeployment des Code-Repositorys. Betrachte diese beiden als Source of Truth, und siehe Bekannte Probleme für Unterschiede zwischen ihnen.

Grund	Typische Policies	Scope	Dauer
Das Plattform-Team arbeitet als Gäste im Tenant des Kunden	Gastkonten mit Schreib- oder Owner-Rechten sollten entfernt werden. Höchstens drei Owner auf einer subscription. Mehr als ein Owner auf einer subscription.	Landing-Zone-subscriptions	Solange das Gast-Modell besteht. Halte den Zugriff mit PIM nach dem Least-Privilege-Prinzip.
Das State-Storage-Account ist noch nicht mit einem gehärteten Modul gebaut	Netzwerkbeschränkungen des Storage Accounts, Private Link, Shared-Key-Zugriff, Customer-managed Key, Infrastructure Encryption, Secure Transfer	Das State-Storage-Account	Vorübergehend. Entfernen, sobald das Account mit dem gehärteten Modul deployt ist.
Eine Kontrolle passt nicht dazu, wie die Plattform deployt wird	Ein Activity-Log-Alert für bestimmte Policy-Operationen (CIS 3.0.0)	Die management group der Landing Zones	Mit jeder Version prüfen.
Gehört dem Tenant, nicht der Plattform	Einladung von Gästen und Beschränkungen des Gastzugriffs in Entra ID (CIS 3.0.0)	Nicht durch Plattform-Code ausgenommen	Die Tenant-Governance des Kunden regelt sie.

Eine Kontrolle, die nicht ausgenommen ist, wird weiter als nicht konform angezeigt, bis sie behoben ist. Zum Beispiel bleibt die Kontrolle Defender for APIs auf subscriptions nicht konform, auf denen der Plan Free oder nicht aktiviert ist. Die Plattform hat ein Gate für den Plan (defender_for_apis.enabled, standardmäßig aus) mit einem Default-Plan und Overrides pro subscription, sodass du ihn gezielt aktivieren kannst.

Die Begründung für jede dieser Ausnahmen ist in den Architecture Decision Records der Plattform festgehalten. Ändere die Ausnahmeliste nicht, ohne sie gelesen zu haben.

Optional: ein separates Ausnahme-Repository (älterer Ansatz)¶

Ältere Plattformversionen boten eine andere Art, Ausnahmen zu betreiben: ein separates Repository in einem separaten Projekt, sodass der Kunde kontrolliert, wer Ausnahmen beantragen und genehmigen darf, unabhängig vom Plattform-Team. Der aktuelle Standard sind die JSON-Dateien im Konfigurations-Repository, die der layer postdeployment deployt. Der Ausnahme-layer des älteren Ansatzes existiert noch im Code-Repository, aber die hub-pipeline verwendet ihn nicht (Layers, die nicht Teil der hub-pipeline sind).

Wenn du ihn noch betreibst, sind das die Bausteine:

Teil	Zweck
Ein Projekt für die Ausnahmen, mit eingeschränktem Zugriff	Vom Kunden gepflegte Zugriffskontrolle. Kann später weitere vom Kunden verwaltete Dateien enthalten.
Eine Gruppe von Genehmigern	Nutzer, die einen pull request auf den main-Branch genehmigen dürfen.
Eine Gruppe von Erstellern	Nutzer, die Ausnahme-Dateien hinzufügen dürfen. Mitglied der Contributors-Gruppe des Projekts.
Ein Repository mit den Ausnahme-Dateien und ihren JSON-Schemas	Ein Ordner pro Scope: management groups, subscriptions, resource groups, Ressourcen.
Eine pipeline, die die Dateien bei einem pull request prüft	Ein einfacher Health Check. Sie liest den Plattform-Code, um die referenzierten Ressourcen zu prüfen, und braucht daher eine service connection mit denselben Rechten wie das spoke-Deployment.
Branch Policy auf `main`	Keine direkten Commits, mindestens ein Reviewer, der nicht der letzte Pusher ist, Approval-Votes bei neuen Änderungen zurücksetzen, Kommentare gelöst, und die Check-pipeline als erforderliche Build-Validierung, die abläuft, wenn sich `main` ändert.
Eine Deployment-pipeline im Konfigurations-Repository	Läuft nach einem Merge auf `main` des Ausnahme-Repositorys, für die Produktions-Plattform-Umgebung.
Eine Projekteinstellung, die pipelines erlaubt, andere Repositories zu lesen	Nötig, weil die Check-pipeline den Plattform-Code liest. In Azure DevOps ist das Limit job authorization scope to current project for non-release pipelines, ausgeschaltet.

Die hub-pipeline deployt nur die JSON-Dateien des Konfigurations-Repositorys. Plane eine Migration älterer Plattformen mit dem Plattform-Team (Was zu tun ist, wenn eine neue Version veröffentlicht wird).

Prüfen¶

Azure portal → Policy → Exemptions: Die Ausnahme und (bei subscription-, resource-group- und Ressourcen-Scope) der -mcsb-Mirror existieren, mit der richtigen Kategorie und dem richtigen Ablaufdatum.
Compliance: Die ausgenommene Ressource wird nach der nächsten Auswertung als Exempt angezeigt.
Defender for Cloud: Rechne mit bis zu 24 Stunden für den Secure Score.

Rollback¶

Entferne die Datei (oder benenne sie in .json.ignore um) und führe hub aus. Die Ausnahme und ihr Mirror werden zerstört. Die Ressource wird wieder gegen die Policy ausgewertet.