Progettare flussi di lavoro di Criteri di Azure come codice

Man mano che si procede con la governance del cloud, è consigliabile passare dalla gestione manuale di ogni assegnazione di criteri nel portale di Azure o tramite i vari SDK a qualcosa di più gestibile e ripetibile a livello aziendale. Due degli approcci principali alla gestione dei sistemi su larga scala nel cloud sono:

  • Infrastruttura distribuita come codice: la pratica di trattare il contenuto che definisce gli ambienti, tutti gli elementi, dai modelli di Azure Resource Manager ai Criteri di Azure definizioni ad Azure Blueprints, come codice sorgente.
  • DevOps: unione di persone, processi e prodotti per consentire la distribuzione continua di valore agli utenti finali.

Criteri di Azure come Codice è la combinazione di queste idee. Essenzialmente, mantenere le definizioni dei criteri nel controllo del codice sorgente e ogni volta che viene apportata una modifica, testare e convalidare tale modifica. Tuttavia, questo non dovrebbe essere l'unico ambito del coinvolgimento dei criteri con Infrastruttura come codice o DevOps.

Il passaggio di convalida deve anche essere un componente di altri flussi di lavoro di integrazione continua o distribuzione continua (CI/CD), ad esempio la distribuzione di un ambiente applicazione o di un'infrastruttura virtuale. Effettuando Criteri di Azure convalida un componente iniziale del processo di compilazione e distribuzione, i team dell'applicazione e delle operazioni individuano se le modifiche si comportano come previsto prima che sia troppo tardi e tentano di eseguire la distribuzione nell'ambiente di produzione.

Definizioni e informazioni di base

Prima di ottenere i dettagli di Criteri di Azure come flusso di lavoro del codice, è importante comprendere alcuni concetti fondamentali, ad esempio come creare definizioni di criteri e definizioni di iniziativa e come sfruttare le esenzioni per le assegnazioni di tali definizioni:

I nomi dei file corrispondono a determinate parti di definizioni di criteri o iniziative e altre risorse dei criteri:

File format Contenuto del file
policy.json L'intera definizione dei criteri
policyset.json Definizione dell'intera iniziativa
policy.parameters.json Parte properties.parameters della definizione dei criteri
policyset.parameters.json Parte properties.parameters della definizione dell'iniziativa
policy.rules.json Parte properties.policyRule della definizione dei criteri
policyset.definitions.json Parte properties.policyDefinitions della definizione dell'iniziativa
exemptionName.json Esenzione dei criteri destinata a una determinata risorsa o ambito

Esempi di questi formati di file sono disponibili nel repository GitHub Criteri di Azure

Panoramica del flusso di lavoro

Il flusso di lavoro generale consigliato di Criteri di Azure come codice è simile al seguente diagramma:

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

Diagramma che mostra il Criteri di Azure come caselle flusso di lavoro codice. Crea informazioni sulla creazione delle definizioni di criteri e iniziative. Il test copre l'assegnazione con la modalità di imposizione disabilitata. Un controllo del gateway per lo stato di conformità è seguito dalla concessione delle autorizzazioni M S I alle assegnazioni e alla correzione delle risorse. La distribuzione copre l'aggiornamento dell'assegnazione con la modalità di imposizione abilitata.

Controllo del codice sorgente

Le definizioni di criteri e iniziative esistenti possono essere esportate in modi diversi, ad esempio tramite powerShell, interfaccia della riga di comando o query di Azure Resource Graph (ARG). L'ambiente di gestione del controllo del codice sorgente preferito per archiviare queste definizioni può essere una delle numerose opzioni, tra cui GitHub o Azure DevOps.

Creare e aggiornare le definizioni dei criteri

Le definizioni dei criteri vengono create tramite JSON e archiviate nel controllo del codice sorgente. Ogni criterio ha un proprio set di file, ad esempio parametri, regole e parametri di ambiente che devono essere archiviati nella stessa cartella. Di seguito è riportata la struttura consigliata da usare per mantenere le definizioni dei criteri nel controllo del codice sorgente.

.
|
|- 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
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- 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
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Quando viene aggiunto un nuovo criterio o ne viene aggiornato uno esistente, il flusso di lavoro deve aggiornare automaticamente la definizione dei criteri in Azure. Il test della definizione del criterio nuovo o aggiornato avviene in una seconda fase.

Creare e aggiornare le definizioni di iniziative

Le definizioni dell'iniziativa vengono create anche usando file JSON che devono essere archiviati nella stessa cartella delle definizioni dei criteri. La definizione dell'iniziativa richiede che la definizione dei criteri esista già, quindi non può essere creata o aggiornata fino a quando l'origine del criterio non è stata aggiornata nel controllo del codice sorgente e quindi aggiornata in Azure. Di seguito è riportata la struttura consigliata da usare per mantenere le definizioni di iniziative nel controllo del codice sorgente:

.
|
|- 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
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- 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
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Analogamente alle definizioni dei criteri, il flusso di lavoro deve aggiornare automaticamente la definizione dell'iniziativa in Azure quando viene aggiunta o aggiornata un'iniziativa esistente. Il test della definizione dell'iniziativa nuova o aggiornata avviene in una seconda fase.

Nota

È consigliabile usare un meccanismo di distribuzione centralizzato come i flussi di lavoro gitHub o Azure Pipelines per distribuire i criteri. Ciò consente di garantire che nell'ambiente vengano distribuite solo le risorse dei criteri esaminate e che venga usato un meccanismo di distribuzione graduale e centrale. Le autorizzazioni di scrittura per le risorse dei criteri possono essere limitate all'identità usata nella distribuzione.

Testare e convalidare la definizione aggiornata

Dopo che il processo di automazione ha acquisito le definizioni di criteri o di iniziative create o aggiornate e ha eseguito l'aggiornamento all'oggetto in Azure, è il momento di testare le modifiche apportate. I criteri o le iniziative di cui fanno parte dovrebbero quindi essere assegnati alle risorse nell'ambiente più lontano da quello di produzione. Questo ambiente è in genere quello di sviluppo.

Nota

In questo passaggio vengono eseguiti test di integrazione della definizione dei criteri all'interno dell'ambiente Azure, questo è separato dalla verifica della funzionalità della definizione dei criteri che deve verificarsi durante il processo di creazione della definizione di definizione.

L'assegnazione deve disabilitare la proprietà enforcementMode in modo da non bloccare le operazioni di creazione e aggiornamento delle risorse, ma in modo che la conformità delle risorse esistenti alla definizione di criteri aggiornata continui a essere controllata. Anche con enforcementMode, è consigliabile che l'ambito dell'assegnazione sia un gruppo di risorse o una sottoscrizione designata in modo specifico per la convalida dei criteri.

Nota

Sebbene la modalità di imposizione sia utile, non si sostituisce al test accurato di una definizione di criteri in varie condizioni. La definizione dei criteri deve essere testata con le chiamate API REST PUT e PATCH, con risorse conformi e non conformi e con casi limite come una proprietà mancante nella risorsa.

Dopo aver distribuito l'assegnazione, usare l'SDK di Criteri di Azure, l'attività Azure Pipelines Security and Compliance Assessment o le query di Azure Resource Graph (ARG) (vedere gli esempi) per ottenere i dati di conformità per la nuova assegnazione. L'ambiente usato per testare i criteri e le assegnazioni deve avere risorse con stati di conformità diversi. Analogamente a un buon unit test per il codice, si vuole verificare che le risorse vengano valutate come previsto senza falsi positivi o falsi negativi. Se si esegue il test e la convalida solo dei comportamenti previsti, i criteri potrebbero dare risultare imprevisti e non identificati. Per altre informazioni, vedere Valutare l'impatto di una nuova definizione di Criteri di Azure.

Abilitare le attività di correzione

Se la convalida dell'assegnazione soddisfa le aspettative, il passaggio successivo consiste nel convalidare la correzione. I criteri che usano deployIfNotExists o modify possono avere un'attività di correzione associata attivata per correggere le risorse da uno stato non conforme e renderle conformi.

Il primo passaggio dell'attività di correzione delle risorse consiste nel concedere all'assegnazione dei criteri l'assegnazione di ruolo definita nella definizione dei criteri. Questa assegnazione di ruolo concede all'identità gestita dell'assegnazione dei criteri un numero sufficiente di diritti per apportare le modifiche necessarie per rendere la risorsa conforme.

Quando l'assegnazione dei criteri dispone dei diritti appropriati, usare l'SDK dei criteri per attivare un'attività di correzione su un set di risorse note come non conformi. Prima di procedere, è necessario completare tre test sulle attività di correzione seguenti:

  • Verificare che l'attività di correzione sia stata completata correttamente
  • Eseguire la valutazione dei criteri per verificare che i risultati di conformità dei criteri siano aggiornati come previsto
  • Eseguire un unit test dell'ambiente direttamente sulle risorse per verificare che le relative proprietà siano state modificate

Il test sia dei risultati di valutazione dei criteri aggiornati che dell'ambiente fornisce direttamente la conferma che le attività di correzione hanno modificato ciò che ci si aspettava e che la definizione dei criteri ha rilevato la modifica di conformità come previsto.

Aggiornare le assegnazioni applicate

Una volta completati tutti i controlli di convalida, aggiornare l'assegnazione in modo da abilitare la proprietà enforcementMode. È consigliabile apportare questa modifica all'inizio nello stesso ambiente lontano da quello di produzione. Verificare che gli effetti desiderati vengano applicati durante la creazione della risorsa e l'aggiornamento delle risorse. Una volta convalidato il funzionamento previsto dell'ambiente, occorre definire l'ambito della modifica in modo da includere l'ambiente successivo e così via, finché i criteri non vengono distribuiti alle risorse di produzione.

Valutazioni integrate nel processo

Il flusso di lavoro generale per Criteri di Azure come codice è per lo sviluppo e la distribuzione di criteri e iniziative in un ambiente su larga scala. Tuttavia, la valutazione dei criteri deve far parte del processo di distribuzione per qualsiasi flusso di lavoro che distribuisce o crea risorse in Azure, ad esempio la distribuzione di applicazioni o l'esecuzione di modelli arm per creare l'infrastruttura.

In questi casi, dopo aver eseguito la distribuzione dell'applicazione o dell'infrastruttura in una sottoscrizione o un gruppo di risorse di test, è necessario eseguire la valutazione dei criteri per tale ambito convalidando tutti i criteri e le iniziative esistenti. Anche se possono essere configurati come enforcementModedisabilitati in un ambiente di questo tipo, è utile sapere in anticipo se una distribuzione di un'applicazione o di un'infrastruttura è in violazione delle definizioni dei criteri in anticipo. La valutazione dei criteri deve quindi essere un passaggio di questi flussi di lavoro e contrassegnare come non riuscite le distribuzioni che creano risorse non conformi.

Rivedi

Questo articolo illustra il flusso di lavoro generale per Criteri di Azure come codice e anche dove la valutazione dei criteri deve far parte di altri flussi di lavoro di distribuzione. Questo flusso di lavoro può essere usato in qualsiasi ambiente che supporti i passaggi controllati da script e l'automazione basata sui trigger.

Passaggi successivi