Progettare flussi di lavoro di Criteri di Azure come codice

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 definizione 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: la pratica di trattare il contenuto che definisce gli ambienti, tutti gli elementi, dai modelli di Azure Resource Manager (modelli arm) alle definizioni di Criteri di Azure ad Azure Blueprints, come codice sorgente.
  • DevOps: l'unione di persone, processi e prodotti per consentire il recapito continuo di valore agli utenti finali.

Criteri di Azure come Codice è 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 della convalida dovrebbe essere un componente anche di altri flussi di lavoro di integrazione continua o distribuzione continua. Un esempio è la distribuzione di un ambiente applicativo o di un'infrastruttura virtuale. Rendendo Criteri di Azure convalida un componente iniziale del processo di compilazione e distribuzione, i team operativi e le applicazioni individuano se le modifiche non sono conformi, molto prima che sia troppo tardi e tentino di eseguire la distribuzione nell'ambiente di produzione.

Definizioni e informazioni fondamentali

Prima di accedere ai dettagli di Criteri di Azure come flusso di lavoro del codice, esaminare le definizioni e gli esempi seguenti:

I nomi di file sono allineati alle parti della definizione dei criteri o dell'iniziativa:

  • policy(set).json - L'intera definizione
  • policy(set).parameters.json - Parte properties.parameters della definizione
  • policy.rules.json - Parte properties.policyRule della definizione
  • policyset.definitions.json - Parte properties.policyDefinitions della definizione

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:

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

Diagramma che mostra la Criteri di Azure come caselle del flusso di lavoro Codice. Crea illustra la 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 illustra l'aggiornamento dell'assegnazione con la modalità di imposizione abilitata.

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 il 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
|     |- 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
|

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.

Vedere anche esportare Criteri di Azure risorse per ottenere le definizioni e le assegnazioni esistenti nell'ambiente di gestione del codice sorgente GitHub.

Creare e aggiornare le definizioni di iniziative

Anche le iniziative hanno il proprio file JSON e i file correlati che devono essere archiviati nella stessa cartella. La definizione di iniziativa richiede che la definizione dei criteri esista già, pertanto non può essere creata o aggiornata finché 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
|
|  |- 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
|

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

Nota

È consigliabile usare un meccanismo di distribuzione centralizzato, ad esempio 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 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.

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'azione GitHub analisi della conformità Criteri di Azure o l'attività Azure Pipelines Security and Compliance Assessment per ottenere i dati di conformità per la nuova assegnazione. L'ambiente usato per testare i criteri e le assegnazioni deve contenere risorse sia conformi che non conformi. Come un buon unit test per il codice, occorre verificare che le risorse siano come previsto e che non siano presenti 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 essere convertiti in un'attività di correzione e correggere le risorse da uno stato non conforme.

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. 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 un'applicazione o una distribuzione dell'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.

Verifica

Questo articolo illustra il flusso di lavoro generale per Criteri di Azure come codice e anche 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. Per un'esercitazione sull'uso di questo flusso di lavoro in GitHub, vedere Esercitazione: Implementare Criteri di Azure come codice con GitHub.

Passaggi successivi