Share via

Basisbeginselen van Azure Policy-definities

  • Artikel

Elke beleidsdefinitie in Azure Policy heeft één effect in de policyRulebijbehorende . Dit effect bepaalt wat er gebeurt wanneer de beleidsregel wordt geëvalueerd om overeen te komen. De effecten gedragen zich anders als ze voor een nieuwe resource, een bijgewerkte resource of een bestaande resource zijn.

Hier volgen de ondersteunde azure Policy-definitie-effecten:

Interchanging-effecten

Soms kunnen meerdere effecten geldig zijn voor een bepaalde beleidsdefinitie. Parameters worden vaak gebruikt om toegestane effectwaarden (allowedValues) op te geven, zodat één definitie veelzijdiger kan zijn tijdens de toewijzing. Het is echter belangrijk om te weten dat niet alle effecten uitwisselbaar zijn. Resource-eigenschappen en -logica in de beleidsregel kunnen bepalen of een bepaald effect als geldig wordt beschouwd voor de beleidsdefinitie. Beleidsdefinities met effect auditIfNotExists vereisen bijvoorbeeld andere details in de beleidsregel die niet vereist zijn voor beleid met effect audit. De effecten gedragen zich ook anders. audit beleid evalueert de naleving van een resource op basis van zijn eigen eigenschappen, terwijl auditIfNotExists beleidsregels de naleving van een resource beoordelen op basis van de eigenschappen van een onderliggende of extensieresource.

De volgende lijst bevat enkele algemene richtlijnen voor verwisselbare effecten:

  • audit, denyen of modify append zijn vaak uitwisselbaar.
  • auditIfNotExists en deployIfNotExists zijn vaak uitwisselbaar.
  • manual is niet uitwisselbaar.
  • disabled is uitwisselbaar met elk effect.

Volgorde van evaluatie

De eerste evaluatie van Azure Policy is voor aanvragen om een resource te maken of bij te werken. Door Azure Policy wordt een lijst opgesteld met alle toewijzingen die van toepassing zijn op de resource en vervolgens wordt de resource op basis van elke definitie geëvalueerd. Voor een Resource Manager-modus verwerkt Azure Policy verschillende effecten voordat de aanvraag aan de juiste resourceprovider wordt verzonden. Deze volgorde voorkomt onnodige verwerking door een resourceprovider wanneer een resource niet voldoet aan de ontworpen besturingselementen voor governance van Azure Policy. Met een resourceprovidermodus beheert de resourceprovider de evaluatie en het resultaat en rapporteert de resultaten terug naar Azure Policy.

  • disabled wordt eerst gecontroleerd om te bepalen of de beleidsregel moet worden geëvalueerd.
  • append en modify vervolgens worden geëvalueerd. Omdat een van beide de aanvraag kan wijzigen, kan een wijziging verhinderen dat een controle- of weigeringseffect wordt geactiveerd. Deze effecten zijn alleen beschikbaar in een Resource Manager-modus.
  • deny wordt vervolgens geëvalueerd. Door Weigeren te evalueren voordat de controle wordt uitgevoerd, wordt dubbele logboekregistratie van een ongewenste resource voorkomen.
  • audit wordt geëvalueerd.
  • manual wordt geëvalueerd.
  • auditIfNotExists wordt geëvalueerd.
  • denyAction wordt het laatst geëvalueerd.

Nadat de resourceprovider een succescode heeft geretourneerd voor een aanvraag auditIfNotExists in de Resource Manager-modus en deployIfNotExists evalueert om te bepalen of er meer nalevingslogboeken of -acties vereist zijn.

PATCH aanvragen die alleen gerelateerde velden wijzigen tags , beperken beleidsevaluatie tot beleidsregels met voorwaarden die gerelateerde velden inspecteren tags .

Beleidsdefinities voor lagen

Verschillende toewijzingen kunnen van invloed zijn op een resource. Deze toewijzingen kunnen zich in hetzelfde bereik of in verschillende bereiken bevinden. Elk van deze toewijzingen heeft waarschijnlijk ook een ander effect gedefinieerd. De voorwaarde en het effect voor elk beleid worden onafhankelijk geëvalueerd. Voorbeeld:

  • Beleid 1
    • Hiermee wordt de locatie van de resource beperkt tot westus
    • Toegewezen aan abonnement A
    • Effect weigeren
  • Beleid 2
    • Hiermee wordt de locatie van de resource beperkt tot eastus
    • Toegewezen aan resourcegroep B in abonnement A
    • Controle-effect

Deze installatie zou resulteren in het volgende resultaat:

  • Elke resource die zich al in resourcegroep B bevindt eastus , voldoet aan beleid 2 en niet-compatibel met beleid 1
  • Alle resources die zich al in eastus resourcegroep B bevinden, zijn niet compatibel met beleid 2 en niet-compatibel met beleid 1 als dat niet het geval is westus
  • Beleid 1 weigert een nieuwe resource in abonnement A niet in westus
  • Elke nieuwe resource in abonnement A en resourcegroep B wordt westus gemaakt en voldoet niet aan het beleid 2

Als zowel beleid 1 als beleid 2 van kracht waren op weigeren, verandert de situatie in:

  • Elke resource die zich al in eastus resourcegroep B bevindt, voldoet niet aan het beleid 2
  • Elke resource die zich al in westus resourcegroep B bevindt, voldoet niet aan het beleid 1
  • Beleid 1 weigert een nieuwe resource in abonnement A niet in westus
  • Elke nieuwe resource in resourcegroep B van abonnement A wordt geweigerd

Elke opdracht wordt afzonderlijk geëvalueerd. Als zodanig is er geen kans dat een resource door een hiaat loopt van verschillen in het bereik. Het nettoresultaat van gelaagde beleidsdefinities wordt beschouwd als cumulatief meest beperkend. Als beleid 1 en 2 bijvoorbeeld een deny effect hadden, wordt een resource geblokkeerd door de overlappende en conflicterende beleidsdefinities. Als u de resource nog steeds in het doelbereik wilt maken, controleert u de uitsluitingen voor elke toewijzing om te controleren of de juiste beleidstoewijzingen van invloed zijn op de juiste bereiken.

Volgende stappen