Policy-uitzonderingen (aanvragen, reviewen, deployen)¶

Standaardwijziging: Policy-uitzondering.

Effect: een resource, resource group, subscription of management group wordt voor beperkte tijd uitgezonderd van een Azure Policy-toewijzing. De uitzondering is code: een JSON-bestand dat wordt gereviewd, goedgekeurd en gedeployed zoals elke andere wijziging.

Deze pagina beschrijft het proces voor het platformteam. Het JSON-formaat en de mappen staan bij Policy-toewijzingen. De kant van het workload team staat in Policies en uitzonderingen. De governanceregel erachter staat in Governance.

Wanneer een uitzondering het juiste antwoord is¶

Een uitzondering is de laatste optie. Vraag eerst:

Kan de resource zo veranderen dat hij aan de policy voldoet? Dat is altijd beter.
Is de policy op de juiste scope toegewezen, met de juiste parameters? Een foute toewijzing is een wijziging van de toewijzing, geen uitzondering (Policy-toewijzingen).
Is het risico geaccepteerd of op een andere manier afgedekt? Alleen dan komt een uitzondering in beeld.

Categorieën¶

Categorie	Betekenis	Gebruik het wanneer
Waiver	Het risico wordt bewust geaccepteerd.	De control past niet bij de resource, en de eigenaar en security accepteren het risico.
Mitigated	Het risico wordt door een andere control afgedekt.	Er is een compenserende control, bijvoorbeeld een privé-netwerkpad in plaats van een door de policy vereist private endpoint. Noem de control in de beschrijving.

In Azure Policy tonen beide categorieën de resource als uitgezonderd. Het verschil zit in de documentatie: die vertelt een latere lezer of iemand een risico heeft geaccepteerd of het elders heeft opgelost.

Aanvraag¶

De aanvrager levert:

Informatie	Beschrijving
Policy of initiative	De exacte naam of ID, en de toewijzing waar hij vandaan komt
Scope	Subscription, resource group of specifieke resources. Gebruik de kleinste scope die werkt.
Categorie	Waiver of mitigated
Onderbouwing	Waarom de resource niet kan voldoen
Alternatieve maatregelen	Welke andere controls het risico verkleinen
Einddatum	Wanneer de uitzondering opnieuw wordt beoordeeld. Kies een korte periode, normaal maximaal een jaar.
Goedkeuring	De goedkeuring van de security officer, met een verwijzing

Proces¶

Het uitzonderingsproces heeft een goedkeuringsstap voordat er code wordt geschreven. Een gangbare opzet:

flowchart LR
    a["Workload team ziet dat een uitzondering nodig is"] --> b["Aanvraag met onderbouwing en einddatum"]
    b --> c{"Goedgekeurd door security officer?"}
    c -->|nee| d["Pas het ontwerp aan"]
    c -->|ja| e["Uitzonderingsbestand in een branch"]
    e --> f["Pull request gekoppeld aan het ticket"]
    f --> g["Automatische controles van het bestand"]
    g --> h["Goedkeuring van de pull request"]
    h --> i["Pipeline deployt de uitzondering"]

Het workload team plaatst de aanvraag. Het platformteam controleert of de velden compleet zijn.
De security officer (of het orgaan dat in jouw organisatie over uitzonderingen beslist) keurt de aanvraag goed of af.
Het platformteam maakt een branch en voegt het uitzonderingsbestand toe in de map voor de scope (policies/policy_exemptions/01_management_groups tot 04_resources). De datum expires_on is altijd ingesteld.
Een pull request, gekoppeld aan het ticket, doorloopt de review van pull requests.
Na goedkeuring deployt hub de postdeployment-layer. Controleer in de portal onder Policy → Exemptions.

Houd het register in de repository

De map met uitzonderingsbestanden is het register. Zet de ticketverwijzing en de goedkeuring in description, en controleer de bestanden regelmatig op vervaldatums (Operationele verantwoordelijkheden). Een uitzondering zonder onderbouwing en einddatum is bij een audit moeilijk te verdedigen.

Reviewchecklist¶

Controle	Waarom
De goedkeuringsverwijzing staat in het ticket en in `description`	Het audit trail
`expires_on` is ingesteld en niet later dan het afgesproken maximum	Uitzonderingen mogen niet eeuwig blijven bestaan
De scope is zo klein mogelijk	Een uitzondering op subscription-niveau voor één resource verbergt andere bevindingen
`policy_definition_ids` bevat alleen de policies die nodig zijn. Gebruik `[]` alleen als de hele toewijzing moet worden uitgezonderd	Een uitzondering voor een hele initiative schakelt veel controls uit
De toewijzing is een initiative-toewijzing	Uitzonderingen voor een toewijzing van één policy worden niet ondersteund door de module (Uitzonderingen)
De categorie past bij de onderbouwing	Waiver voor een geaccepteerd risico, mitigated voor een compenserende control
De bestandsnaam en de `name` zijn uniek, en de naam laat ruimte voor het achtervoegsel van de mirror (zie hieronder)	De module laat de plan falen op een te lange naam

Uitzonderingen en de secure score van Defender for Cloud¶

Als Microsoft Defender for Cloud voor een subscription aan staat, wijst Azure de Microsoft cloud security benchmark (MCSB) aan de subscription toe als de toewijzing SecurityCenterBuiltIn. De portal toont die als ASC Default. Het platform maakt deze toewijzing niet aan, en verwijderen helpt niet: Defender for Cloud maakt hem opnieuw aan.

De secure score wordt alleen berekend uit de assessments van die toewijzing. De compliance-toewijzingen van het platform zijn aparte toewijzingen die de score negeert. Een uitzondering op een platformtoewijzing is correct voor de compliance- rapportage, maar verandert de score niet: de standaardtoewijzing blijft dezelfde resource markeren.

Automatische mirroring¶

Voor elke in aanmerking komende uitzondering maakt de policymodule een gespiegelde uitzondering op de SecurityCenterBuiltIn- toewijzing van de subscription. Je past hiervoor het JSON-bestand niet aan.

De mirror heet <original-name>-mcsb, en zijn weergavenaam krijgt het achtervoegsel (ASC Default).
Categorie en vervaldatum worden van het origineel overgenomen.
Beide categorieën zorgen dat de resource niet meer als unhealthy meetelt. Mitigated behandelt de resource voor die aanbeveling als healthy, waiver haalt de resource helemaal uit de assessment.
De variabele mirror_exemptions_to_mcsb bepaalt dit. Standaard is die true; false schakelt de mirroring voor een platform uit (Feature flags).

Scope van de uitzondering	Gespiegeld	Reden
Subscription	Ja	De standaardtoewijzing bestaat op subscription-scope.
Resource group	Ja	De subscription wordt afgeleid van de ID van de resource group.
Resource	Ja	De subscription wordt afgeleid van de resource-ID.
Management group	Nee	Er is geen standaardtoewijzing per management group.

Regels die je beschermen:

Een uitzondering die al op de standaardtoewijzing is gericht, wordt niet nog eens gespiegeld.
Een uitzondering met een lege lijst policy_definition_ids wordt niet gespiegeld. Dat zou de subscription van de hele benchmark uitzonderen.
Alleen de policies die ook deel van de benchmark zijn, worden naar de mirror gekopieerd. Is dat er geen, dan wordt er geen mirror aangemaakt.
Namen van uitzonderingen zijn beperkt tot 64 tekens. De mirror voegt -mcsb toe, dus een naam langer dan 59 tekens laat de plan falen met een duidelijke foutmelding.

Uitzonderingen op management group-scope¶

Een uitzondering op een management group bereikt de secure score niet. In volgorde van voorkeur:

Verklein de scope tot de subscriptions of resources waarop hij van toepassing is. Dan komt hij in aanmerking voor mirroring.
Schakel de aanbeveling uit in de parameters van de standaardtoewijzing: Defender for Cloud → Environment settings → de scope → Security policies → Microsoft cloud security benchmark → zet de aanbeveling uit. Ze wordt dan voor die scope uit de score gehaald.
Wijs de benchmark toe op management group-niveau via de securitypolicy-instellingen van Defender for Cloud, zodat de subscriptions één centrale toewijzing volgen en uitzonderingen op één plek worden beheerd.

Operationele opmerkingen¶

Een mirror heeft de SecurityCenterBuiltIn-toewijzing nodig. Die bestaat zodra Defender for Cloud voor de subscription aan staat. Op een subscription waar Defender for Cloud nooit is ingeschakeld, faalt de apply op de ontbrekende toewijzing.
Defender for Cloud evalueert elke 12 tot 24 uur. Reken op maximaal 24 uur voordat de secure score een nieuwe of verwijderde uitzondering toont.
Mirrors zijn gewone uitzonderingsresources die door Terraform worden beheerd. Pas ze niet met de hand aan in de portal.

Uitzonderingen die bij het platform horen¶

Naast de uitzonderingen die workload teams aanvragen, heeft een platform uitzonderingen van zichzelf. Ze bestaan zodat het platform kan werken, en verschillen van de uitzonderingen van een workload: het platformteam is er eigenaar van en houdt één lijst bij met de reden van elk ervan (Uitzonderingen documenteren die voor het platform gelden).

De gebruikelijke patronen, gegroepeerd op reden. De actuele lijst van jouw versie staat in docs/policy_exemptions/current-platform-exemptions.md en in de postdeployment-layer van de coderepository. Beschouw die twee als bron van waarheid, en zie Bekende problemen voor verschillen tussen beide.

Reden	Typische policies	Scope	Duur
Het platformteam werkt als gast in de tenant van de klant	Guest accounts met schrijf- of eigenaarrechten moeten worden verwijderd. Maximaal drie eigenaren op een subscription. Meer dan één eigenaar op een subscription.	Landing zone-subscriptions	Zolang het gastmodel bestaat. Houd de toegang least-privilege met PIM.
Het state storage account is nog niet met een geharde module gebouwd	Netwerkbeperkingen van het storage account, private link, shared key-toegang, customer-managed key, infrastructure encryption, secure transfer	Het state storage account	Tijdelijk. Verwijder wanneer het account met de geharde module is gedeployed.
Een control past niet bij de manier waarop het platform wordt gedeployed	Een activity log alert voor specifieke policy-operaties (CIS 3.0.0)	De management group van de landing zones	Review bij elke versie.
Eigendom van de tenant, niet van het platform	Beperkingen voor gastuitnodigingen en gasttoegang in Entra ID (CIS 3.0.0)	Niet uitgezonderd door platformcode	De governance van de klanttenant handelt ze af.

Een control die niet is uitgezonderd, blijft als niet-compliant zichtbaar totdat hij is opgelost. De control Defender for APIs blijft bijvoorbeeld niet-compliant op subscriptions waar het plan Free is of niet is ingeschakeld. Het platform heeft een gate voor het plan (defender_for_apis.enabled, standaard uit) met een standaardplan en overrides per subscription, zodat je het bewust kunt inschakelen.

De redenering achter elk van deze uitzonderingen staat in de architecture decision records van het platform. Wijzig de uitzonderingslijst niet zonder ze te lezen.

Optioneel: een aparte uitzonderingsrepository (oudere aanpak)¶

Oudere platformversies boden een andere manier om uitzonderingen te draaien: een aparte repository in een apart project, zodat de klant bepaalt wie uitzonderingen mag aanvragen en goedkeuren, onafhankelijk van het platformteam. De huidige standaard zijn de JSON-bestanden in de configuratierepository, gedeployed door de postdeployment-layer. De uitzonderingslayer van de oudere aanpak bestaat nog in de coderepository, maar de hub pipeline gebruikt hem niet (Layers die geen deel van de hub pipeline zijn).

Draai je hem nog, dan zijn dit de bouwstenen:

Onderdeel	Doel
Een project voor de uitzonderingen, met beperkte toegang	Toegangsbeheer dat de klant onderhoudt. Kan later andere door de klant beheerde bestanden bevatten.
Een groep approvers	Gebruikers die een pull request op de main branch mogen goedkeuren.
Een groep creators	Gebruikers die uitzonderingsbestanden mogen toevoegen. Lid van de contributors-groep van het project.
Een repository met de uitzonderingsbestanden en hun JSON-schema's	Eén map per scope: management groups, subscriptions, resource groups, resources.
Een pipeline die de bestanden bij een pull request controleert	Een basale gezondheidscheck. Hij leest de platformcode om de gerefereerde resources te controleren, dus hij heeft een service connection nodig met dezelfde rechten als de spoke-deployment.
Branch policy op `main`	Geen directe commits, minstens één reviewer die niet de laatste pusher is, goedkeuringen resetten bij nieuwe wijzigingen, opmerkingen opgelost, en de checkpipeline als verplichte buildvalidatie die vervalt wanneer `main` verandert.
Een deploymentpipeline in de configuratierepository	Draait na een merge naar `main` van de uitzonderingsrepository, voor de productie-platformomgeving.
Een projectinstelling die pipelines toestaat andere repositories te lezen	Nodig omdat de checkpipeline de platformcode leest. In Azure DevOps is dit Limit job authorization scope to current project for non-release pipelines op uit.

De hub pipeline deployt alleen de JSON-bestanden van de configuratierepository. Plan een migratie van oudere platformen samen met het platformteam (Wat te doen als een nieuwe versie wordt gereleased).

Controleren¶

Azure portal → Policy → Exemptions: de uitzondering en (voor subscription-, resource group- en resource-scope) de -mcsb-mirror bestaan, met de juiste categorie en vervaldatum.
Compliance: de uitgezonderde resource wordt na de volgende evaluatie als Exempt getoond.
Defender for Cloud: reken op maximaal 24 uur voor de secure score.

Rollback¶

Verwijder het bestand (of hernoem het naar .json.ignore) en draai hub. De uitzondering en zijn mirror worden vernietigd. De resource wordt opnieuw tegen de policy geëvalueerd.