Návrh pracovních postupů pro Azure Policy jako kód

  • Článek
  • 7 min ke čtení

Během své cesty se zásadou správného řízení v cloudu budete chtít přejít od ruční správy jednotlivých definic zásad v Azure Portal nebo přes různé sady SDK až po něco, co se bude spravovat a opakovat v podnikovém měřítku. Dva z převládajících přístupů ke správě systémů ve velkém měřítku v cloudu jsou:

  • Infrastruktura jako kód: Postup při zacházení s obsahem, který definuje vaše prostředí, od šablon Azure Resource Manager (šablon ARM) až po Azure Policy definice až Azure Blueprints jako se zdrojovým kódem.
  • DevOps: Spojení lidí, procesů a produktů, které koncovým uživatelům umožní průběžné doručování hodnoty.

Azure Policy kódem je kombinace těchto myšlenek. V podstatě udržujte definice zásad ve zdrojovém kódu a při každé změně ji otestujte a ověřte. To by ale neměl být rozsah zapojení zásad s infrastrukturou jako kód nebo DevOps.

Krok ověření by měl být také součástí jiných pracovních postupů průběžné integrace nebo průběžného nasazování. Příkladem může být nasazení aplikačního prostředí nebo virtuální infrastruktury. Provedením ověření Azure Policy součástí procesu sestavení a nasazení zjistí týmy aplikace Azure Policy provozu, jestli jejich změny nedodržují předpisy, dlouho předtím, než bude příliš pozdě a pokusí se provést nasazení v produkčním prostředí.

Definice a základní informace

Než se dočtete o podrobnostech pracovního Azure Policy kódu, projděte si následující definice a příklady:

Názvy souborů jsou v souladu s částmi definice zásady nebo iniciativy:

  • policy(set).json – Celá definice
  • policy(set).parameters.json – properties.parameters Část definice
  • policy.rules.json – properties.policyRule Část definice
  • policyset.definitions.json – properties.policyDefinitions Část definice

Příklady těchto formátů souborů jsou k dispozici v Azure Policy GitHub:

Přehled pracovního postupu

Doporučený obecný pracovní postup pro Azure Policy code vypadá jako v tomto diagramu:

Diagram znázorňující Azure Policy jako pole pracovních postupů kódu od vytvoření po testování až po nasazení

Vytvoření a aktualizace definic zásad

Definice zásad se vytvářejí pomocí formátu JSON a ukládají se do správy zdrojového kódu. Každá zásada má vlastní sadu souborů, jako jsou parametry, pravidla a parametry prostředí, které by měly být uložené ve stejné složce. Následující struktura je doporučeným způsobem, jak udržovat definice zásad ve zdrojovém kódu.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|

Po přidání nové zásady nebo aktualizaci existující zásady by měl pracovní postup automaticky aktualizovat definici zásady v Azure. Testování nové nebo aktualizované definice zásady přijde v pozdějším kroku.

Také si prohlédněte export Azure Policy prostředků a získejte existující definice a přiřazení do prostředí pro správu zdrojového kódu GitHub.

Vytvoření a aktualizace definic iniciativ

Iniciativy mají také vlastní soubor JSON a související soubory, které by měly být uložené ve stejné složce. Definice iniciativy vyžaduje, aby definice zásady už existovala, takže ji není možné vytvořit ani aktualizovat, dokud se zdroj zásad ne aktualizované ve zdrojovém kódu a pak ne aktualizovaný v Azure. Následující struktura je doporučeným způsobem, jak udržovat definice iniciativ ve zdrojovém kódu:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|

Podobně jako definice zásad by měl pracovní postup při přidávání nebo aktualizaci existující iniciativy automaticky aktualizovat definici iniciativy v Azure. Testování nové nebo aktualizované definice iniciativy přijde v pozdějším kroku.

Testování a ověření aktualizované definice

Jakmile automatizace získá nově vytvořené nebo aktualizované definice zásad nebo iniciativ a aktualizuje objekt v Azure, je čas otestovat provedené změny. Zásady nebo iniciativy, které jsou součástí, by se pak měly přiřadit k prostředkům v prostředí, které je od produkčního prostředí nejdále. Toto prostředí je obvykle Dev.

Přiřazení by mělo používat enforcementMode zakázané, aby se vytváření a aktualizace prostředků neblokovaly, ale stávající prostředky se stále auditují kvůli dodržování aktualizované definice zásad. I s parametrem enforcementMode se doporučuje, aby rozsah přiřazení byl buď skupina prostředků, nebo předplatné, které je určené speciálně pro ověřování zásad.

Poznámka

I když je režim vynucení užitečný, není to náhrada za důkladné testování definice zásady za různých podmínek. Definice zásady by se měla testovat s voláními REST API, prostředky dodržujícími předpisy a prostředky, které nedodržují předpisy, a hraničními případy, jako je chybějící PUT PATCH vlastnost prostředku.

Po nasazení přiřazení použijte sadu Azure Policy SDK, akci kontroly dodržování předpisů GitHubAzure Policy nebo úlohu posouzení zabezpečení a dodržování předpisů Azure Pipelines k získání dat dodržování předpisů pro nové přiřazení. Prostředí použité k testování zásad a přiřazení by mělo mít prostředky, které dodržují předpisy, i prostředky nedodržující předpisy. Stejně jako dobrý test jednotek pro kód chcete otestovat, že prostředky jsou podle očekávání a že také nemáte žádné falešně pozitivní nebo falešně negativní výsledky. Pokud testujete a ověřujete pouze to, co očekáváte, může to mít na zásady neočekávaný a neidentifikovaný dopad. Další informace najdete v tématu Vyhodnocení dopadu nové definice Azure Policy .

Povolení nápravných úloh

Pokud ověření přiřazení splňuje očekávání, dalším krokem je ověření nápravy. Zásady, které používají buď deployIfNotExists, nebo je upravují, je možné přepnout na úlohu nápravy a opravit prostředky ze stavu nedodržující předpisy.

Prvním krokem k nápravě prostředků je udělit přiřazení zásady k přiřazení role definované v definici zásady. Toto přiřazení role poskytuje spravované identitě přiřazení zásad potřebná oprávnění k provedení potřebných změn, aby prostředky byly v souladu s předpisy.

Jakmile má přiřazení zásady příslušná práva, pomocí sady Policy SDK aktivujte úlohu nápravy proti sadě prostředků, u které je známo, že nedodržují předpisy. Než budete pokračovat, měli byste pro tyto napravené úlohy provést tři testy:

  • Ověření úspěšného dokončení úlohy nápravy
  • Spusťte vyhodnocení zásad a podívejte se, jestli se výsledky dodržování zásad aktualizují podle očekávání.
  • Spusťte test jednotek prostředí přímo u prostředků, abyste ověřili, že se jejich vlastnosti změnily.

Testováním aktualizovaných výsledků vyhodnocení zásad a prostředí přímo zajistíte potvrzení, že úlohy nápravy změnily očekávané výsledky a že definice zásady viděli změnu dodržování předpisů podle očekávání.

Aktualizace na vynucená přiřazení

Po dokončení všech ověřovacích bran aktualizujte přiřazení tak, aby se pro použití enforcementMode povolilo. Tuto změnu se doporučuje provést na začátku ve stejném prostředí, které je daleko od produkčního prostředí. Po ověření, že prostředí funguje podle očekávání, by změna měla být vymezená tak, aby zahrnovala další prostředí atd., dokud se zásady nenasadí do produkčních prostředků.

Zpracování integrovaných vyhodnocení

Obecný pracovní postup pro Azure Policy kódu je pro vývoj a nasazování zásad a iniciativ do prostředí ve velkém měřítku. Vyhodnocení zásad by však mělo být součástí procesu nasazení jakéhokoli pracovního postupu, který nasazovat nebo vytvářet prostředky v Azure, jako je nasazení aplikací nebo spouštění šablon ARM pro vytvoření infrastruktury.

V těchto případech by se po nasazení aplikace nebo infrastruktury do testovacího předplatného nebo skupiny prostředků mělo provést vyhodnocení zásad pro toto ověření rozsahu kontroly všech stávajících zásad a iniciativ. I když je v takovém prostředí možné nakonfigurovat jako enforcementMode zakázané, je užitečné včas vědět, jestli nasazení aplikace nebo infrastruktury v rané fázi porušuje definice zásad. Vyhodnocení této zásady by proto mělo být krokem v těchto pracovních postupech a selháním nasazení, která vytvářejí prostředky nedodržující předpisy.

Opakování

Tento článek popisuje obecný pracovní postup pro Azure Policy kódu a také tam, kde by vyhodnocení zásad mělo být součástí jiných pracovních postupů nasazení. Tento pracovní postup je možné použít v jakémkoli prostředí, které podporuje skriptované kroky a automatizaci na základě triggerů. Kurz týkající se používání tohoto pracovního postupu na GitHub najdete v tématu Kurz: Implementace Azure Policy jako kódu pomocí GitHub.

Další kroky