Condividi tramite

Progettare flussi di lavoro di Criteri di Azure come codice

  • Articolo

Lungo il percorso di implementazione dei processi di governance del cloud, arriva il momento in cui si è pronti a passare dalla gestione manuale di ogni assegnazione di criteri, tramite il portale di Azure o i vari SDK, a qualcosa di più gestibile e ripetibile su scala aziendale. Due degli approcci principali alla gestione dei sistemi su larga scala nel cloud sono:

  • Infrastruttura come codice: pratica che consiste nel trattare i contenuti che definiscono gli ambienti, inclusi i modelli di Azure Resource Manager (modelli ARM), le definizioni dei criteri e Azure Blueprints, come codice sorgente.
  • DevOps: unione di persone, processi e prodotti per consentire il recapito continuo di valore agli utenti finali.

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

Il passaggio di convalida deve essere anche un componente di altri flussi di lavoro di integrazione o distribuzione continua (CI/CD), ad esempio la distribuzione di un ambiente applicazione o di un'infrastruttura virtuale. Integrando la convalida di Criteri di Azure fin dalle prime fasi del processo di compilazione e distribuzione, i team responsabili delle applicazioni e delle operazioni possono scoprire se le modifiche apportate si comportano in modo atteso molto prima che sia troppo tardi e passino alla fase di distribuzione in produzione.

Definizioni e informazioni di base

Prima di ottenere i dettagli del flusso di lavoro di Criteri di Azure come codice, è importante comprendere alcuni concetti fondamentali, ad esempio come creare definizioni di criteri e di iniziative 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 ad altre risorse dei criteri:

File format Contenuto del file
policy-v#.json Definizione completa dei criteri per tale versione
policyset-v#.json Definizione dell'intera iniziativa per tale versione
policy-v#.parameters.json Parte properties.parameters della definizione dei criteri
policyset-v#.parameters.json Parte properties.parameters della definizione dell'iniziativa
policy-v#.rules.json Parte properties.policyRule della definizione dei criteri
policyset-v#.definitions.json Parte properties.policyDefinitions della definizione dell'iniziativa
exemptionName.json Esenzione dai criteri destinata a una risorsa o a un ambito determinato

Panoramica del flusso di lavoro

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

Diagramma che mostra le caselle del flusso di lavoro di Criteri di Azure come codice da Crea a Esegui test per la distribuzione.

Controllo del codice sorgente

È possibile esportare le definizioni di criteri e iniziative esistenti 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 dispone di un proprio set di file, ad esempio i parametri, le regole e i 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
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.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
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.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 di tale criterio 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 di iniziativa vengono create anche usando file JSON che devono essere archiviati nella stessa cartella delle definizioni dei criteri. La definizione di iniziativa richiede che la definizione dei criteri esista già, pertanto non può essere creata o aggiornata fino a quando l'origine del criterio non è stata aggiornata nel controllo del codice sorgente e, quindi, 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
|     |- versions ____________________ # Subfolder for versions of 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
|     |- versions ____________________ # Subfolder for versions of 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 di criteri, il flusso di lavoro deve aggiornare automaticamente la definizione di iniziativa in Azure quando ne viene aggiunta una o aggiornata una 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 alle 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, viene eseguito un test di integrazione della definizione di criteri nell'ambiente di Azure, distinto dalla verifica della funzionalità della definizione di criteri, che dovrebbe avvenire durante il processo di creazione della 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à di valutazione della sicurezza e della conformità di Azure Pipelines o le query di Azure Resource Graph (ARG) (vedereesempi) per ottenere i dati di conformità per la nuova assegnazione. L'ambiente usato per testare i criteri e le assegnazioni deve disporre di risorse con stati di conformità diversi. Analogamente a un buon unit test per il codice, si intende 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 disporre di un'attività di correzione che si attiva per far passare le risorse dallo stato di non conformità a quello di conformità.

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 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 di Criteri di Azure come codice prevede lo sviluppo e la distribuzione di criteri e iniziative in un ambiente su larga scala. La valutazione dei criteri, tuttavia, deve far parte del processo di distribuzione di qualsiasi flusso di lavoro che distribuisca o crei risorse in Azure, ad esempio la distribuzione di applicazioni o l'esecuzione di modelli ARM per creare un'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 in un ambiente di questo tipo potrebbero essere configurati con la proprietà enforcementMode disabilitata, è utile sapere in anticipo se la distribuzione di un'applicazione o di un'infrastruttura viola le definizioni dei criteri. 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.

Revisione

Questo articolo illustra il flusso di lavoro generale di Criteri di Azure come codice e descrive inoltre le situazioni in cui 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