Distribuzione sicura delle assegnazioni di Criteri di Azure

Man mano che l'ambiente si espande, aumenta anche la richiesta di una pipeline di distribuzione continua (CD) controllata con controllo progressivo dell'esposizione. Di conseguenza, Microsoft consiglia ai team DevOps di seguire il framework SDP (Safe Deployment Practices). La distribuzione sicura delle definizioni e delle assegnazioni di Criteri di Azure consente di limitare l'impatto dei comportamenti imprevisti delle risorse dei criteri.

L'approccio generale all'implementazione di SDP con Criteri di Azure consiste nell'implementare gradualmente assegnazioni di criteri per livelli per rilevare le modifiche ai criteri che influiscono sull'ambiente nelle prime fasi prima che influisca sull'infrastruttura cloud critica.

I livelli di distribuzione possono essere organizzati in modi diversi. In questa esercitazione sulle procedure i livelli sono divisi per aree di Azure diverse con il livello 5 che rappresenta posizioni non critiche, con traffico basso e livello 0 che denota le posizioni di traffico più critiche e più elevate.

Passaggi per la distribuzione sicura delle assegnazioni di Criteri di Azure con effetti di negazione o aggiunta

Usare il diagramma di flusso seguente come riferimento durante l'applicazione del framework SDP alle assegnazioni di Criteri di Azure che usano gli effetti dei criteri di deny o append.

Numeri dei passaggi del diagramma di flusso:

1. Dopo aver selezionato la definizione dei criteri, assegnare il criterio all'ambito di livello più alto inclusivo di tutti i livelli di distribuzione. Applicare selettori di risorse per restringere l'applicabilità al livello meno critico usando la "kind": "resource location" proprietà . Configurare il tipo di effetto audit usando gli override delle assegnazioni. Selettore di esempio con posizione eastUS ed effetto come audit:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "overrides":[{
     "kind": "policyEffect",
     "value": "Audit"
   }]
   

2. Dopo aver distribuito l'assegnazione e aver completato l'analisi iniziale della conformità, verificare che il risultato della conformità sia quello previsto.

   È anche consigliabile configurare test automatizzati che eseguono controlli di conformità. Un controllo di conformità deve includere la logica seguente:

   • Raccogliere i risultati di conformità
   • Se i risultati della conformità sono come previsto, la pipeline deve continuare
   • Se i risultati della conformità non sono come previsto, la pipeline deve avere esito negativo ed è necessario avviare il debug

   Ad esempio, è possibile configurare il controllo di conformità usando altri strumenti all'interno della pipeline di integrazione continua/distribuzione continua (CI/CD).

   In ogni fase di implementazione, i controlli di integrità dell'applicazione devono confermare la stabilità del servizio e l'impatto dei criteri. Se i risultati non sono come previsto a causa della configurazione dell'applicazione, effettuare il refactoring dell'applicazione in modo appropriato.

3. Ripetere espandendo i valori delle proprietà del selettore di risorse per includere i livelli successivi. le posizioni e convalidando i risultati di conformità previsti e l'integrità dell'applicazione. Selettore di esempio con un valore di posizione aggiunto:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS", "westUS"]
     }]
   }]
   

4. Dopo aver assegnato correttamente il criterio a tutti i livelli usando audit la modalità, la pipeline deve attivare un'attività che modifica l'effetto dei criteri in deny e reimpostare i selettori di risorse nel percorso associato al livello 0. Selettore di esempio con un'area e un effetto impostato su Nega:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "overrides":[{
     "kind": "policyEffect",
     "value": "Deny"
   }]
   

5. Una volta modificato l'effetto, i test automatizzati devono verificare se l'imposizione avviene come previsto.

6. Ripetere includendo più livelli nella configurazione del selettore di risorse.

7. Ripetere questo processo per tutti i livelli di produzione.

Passaggi per la distribuzione sicura delle assegnazioni di Criteri di Azure con effetti di modifica o deployIfNotExists

I passaggi per i criteri che usano gli effetti modify o deployIfNotExists sono simili ai passaggi illustrati in precedenza con l'azione aggiuntiva di usare la modalità di imposizione e attivare un'attività di correzione. Esaminare il diagramma di flusso seguente con i passaggi modificati da 5 a 9:

Numeri dei passaggi del diagramma di flusso:

1. Dopo aver selezionato la definizione dei criteri, assegnare il criterio all'ambito di livello più alto inclusivo di tutti i livelli di distribuzione. Applicare selettori di risorse per restringere l'applicabilità al livello meno critico usando la "kind": "resource location" proprietà . Configurare la modalità di imposizione dell'assegnazione su DoNotEnforce. Selettore di esempio con posizione eastUS e enforcementMode come DoNotEnforce:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "enforcementMode": "DoNotEnforce"
   

2. Dopo aver distribuito l'assegnazione e aver completato l'analisi iniziale della conformità, verificare che il risultato della conformità sia quello previsto.

   È anche consigliabile configurare test automatizzati che eseguono controlli di conformità. Un controllo di conformità deve includere la logica seguente:

   • Raccogliere i risultati di conformità
   • Se i risultati della conformità sono come previsto, la pipeline deve continuare
   • Se i risultati della conformità non sono come previsto, la pipeline deve avere esito negativo ed è necessario avviare il debug

   È possibile configurare il controllo di conformità usando altri strumenti all'interno della pipeline di integrazione continua/distribuzione continua (CI/CD).

   In ogni fase di implementazione, i controlli di integrità dell'applicazione devono confermare la stabilità del servizio e l'impatto dei criteri. Se i risultati non sono come previsto a causa della configurazione dell'applicazione, effettuare il refactoring dell'applicazione in modo appropriato.

   È anche possibile attivare attività di correzione per correggere le risorse esistenti non conformi. Assicurarsi che le attività di correzione consentano di garantire la conformità delle risorse come previsto.

3. Ripetere espandendo i valori delle proprietà del selettore di risorse per includere le posizioni del livello successivo e convalidando i risultati di conformità previsti e l'integrità dell'applicazione. Selettore di esempio con un valore di posizione aggiunto:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS", "westUS"]
     }]
   }]
   

4. Dopo aver assegnato il criterio a tutti i livelli usando la modalità DoNotEnforce , la pipeline deve attivare un'attività che modifica il criterio enforcementMode in Abilitazione predefinita e reimpostare i selettori di risorse nel percorso associato al livello 0. Selettore di esempio con un'area e un effetto impostato su Nega:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "enforcementMode": "Default",
   

5. Una volta modificato l'effetto, i test automatizzati devono verificare se l'imposizione avviene come previsto.

6. Ripetere includendo più livelli nella configurazione del selettore di risorse.

7. Ripetere questo processo per tutti i livelli di produzione.

Passaggi per aggiornare in modo sicuro la versione di definizione predefinita nell'assegnazione di Criteri di Azure

1. All'interno dell'assegnazione esistente, applicare le sostituzioni per aggiornare la versione della definizione per il livello meno critico. Viene usata una combinazione di override per modificare definitionVersion e selettori all'interno della condizione overrides per restringere l'applicabilità in base alla proprietà "kind": "resource location". Tutte le risorse esterne alle posizioni specificate continueranno a essere valutate rispetto alla versione della proprietà di primo livello definitionVersion nell'assegnazione. Esempio di override che aggiorna la versione della definizione a 2.0.* e la applica solo alle risorse in EastUs.

   "overrides":[{
     "kind": "definitionVersion",
     "value": "2.0.*",
     "selectors": [{
       "kind": "resourceLocation",
       "in": [ "eastus"]
     }]
   }]
   

2. Dopo aver aggiornato l'assegnazione e aver completato l'analisi iniziale della conformità, verificare che il risultato della conformità sia quello previsto.

   È anche consigliabile configurare test automatizzati che eseguono controlli di conformità. Un controllo di conformità deve includere la logica seguente:

   • Raccogliere i risultati di conformità
   • Se i risultati della conformità sono come previsto, la pipeline deve continuare
   • Se i risultati della conformità non sono come previsto, la pipeline deve avere esito negativo ed è necessario avviare il debug

   Ad esempio, è possibile configurare il controllo di conformità usando altri strumenti all'interno della pipeline di integrazione continua/distribuzione continua (CI/CD).

   In ogni fase di implementazione, i controlli di integrità dell'applicazione devono confermare la stabilità del servizio e l'impatto dei criteri. Se i risultati non sono come previsto a causa della configurazione dell'applicazione, effettuare il refactoring dell'applicazione in modo appropriato.

3. Ripetere espandendo i valori delle proprietà del selettore di risorse per includere i livelli successivi. le posizioni e convalidando i risultati di conformità previsti e l'integrità dell'applicazione. Esempio con un valore di posizione aggiunto:

    "overrides":[{
     "kind": "definitionVersion",
     "value": "2.0",
     "selectors": [{
       "kind": "resourceLocation",
       "in": [ "eastus", "westus"]
     }]
   }]
   

4. Dopo aver incluso correttamente tutte le posizioni necessarie all'interno di _selectors, è possibile rimuovere l'override e aggiornare la proprietà definitionVersion all'interno dell'assegnazione:

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

Passaggi successivi

• Informazioni su come creare criteri a livello di codice.
• Vedere Flussi di lavoro di Criteri di Azure come codice.
• Vedere le indicazioni di Microsoft relative alle procedure di distribuzione sicura.
• Vedere Correggere le risorse non conformi con Criteri di Azure.