Adottare misure di protezione basate su criteri

Prima di usare i criteri, è necessario comprendere dove vengono usati all'interno delle implementazioni di riferimento della zona di destinazione di Azure e perché. Questo articolo consente di comprendere se si vuole impedire a DeployIfNotExists (DINE) o Modificare i criteri di apportare modifiche all'interno dell'ambiente Azure.

Perché usare le politiche DINE e Modify?

I criteri DINE e Modify fanno parte delle implementazioni di riferimento della zona di destinazione di Azure. Consentono all'utente e all'organizzazione di assicurarsi che le zone di destinazione, note anche come sottoscrizioni, e le risorse all'interno di esse siano conformi. Questi criteri riducono anche il carico operativo per i team della piattaforma e della landing zone man mano che l'ambiente Azure si espande.

Si consideri, ad esempio, uno scenario in cui viene creata una nuova sottoscrizione della zona di sbarco e inserita nel gruppo di gestione 'corp'. Applica i criteri DINE e Modify, quindi eseguono le seguenti azioni nella sottoscrizione della landing zone:

• Abilitare Microsoft Defender per il cloud. Configurare le esportazioni di Defender for Cloud nell'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.
• Abilitare Defender for Cloud per le diverse offerte supportate in base ai parametri dei criteri configurati nell'assegnazione dei criteri.
• Configurare i log attività di Azure per l'invio all'area centrale di lavoro di Log Analytics nell'abbonamento di amministrazione.
• Configurare le impostazioni di diagnostica per tutte le risorse da inviare all'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.
• Distribuire gli agenti di Monitoraggio di Azure necessari per le macchine virtuali e i set di scalabilità di macchine virtuali di Azure, inclusi i server connessi ad Azure Arc. Connetterli all'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.

Tutti i criteri assegnati aiutano l'utente e i proprietari della landing zone a rimanere conformi. Nessuna risorsa effettiva del carico di lavoro viene distribuita tramite DINE o Modify policies. Neanche noi lo consigliamo. Per ulteriori informazioni, vedere Dovremmo usare i Criteri di Azure per distribuire i carichi di lavoro? Solo le risorse o le impostazioni ausiliarie o di supporto vengono distribuite o configurate da questi criteri DINE.

Le implementazioni di riferimento delle zone di destinazione di Azure usano i criteri di Azure DINE per ottenere una governance basata su criteri all'interno dell'ambiente Azure. Ma forse non è possibile usare i criteri DINE o Modify oppure non si è pronti per abilitare questo tipo di effetto dei criteri di Azure a causa di:

• Criteri di conformità alle normative, standard o restrizioni legali.
• Processi rigorosi di controllo delle modifiche che richiedono l'approvazione umana per ogni azione all'interno dell'ambiente Azure.
• Mancanza di competenze, esperienza e comprensione di come gestire e usare i criteri DINE.
• I requisiti organizzativi impongono che tutte le configurazioni delle risorse del carico di lavoro, incluse le risorse ausiliarie, le risorse di supporto e le impostazioni, siano definite nell'infrastruttura come codice (IaC) dai team delle applicazioni di carico di lavoro.

Se si rientrano negli esempi precedenti o in scenari simili, questo articolo illustra come adottare l'architettura concettuale della zona di destinazione di Azure e rispettare i principi di progettazione. Anche se inizialmente non si useranno determinati criteri, è possibile scegliere di abilitarli gradualmente in futuro. L'obiettivo è quello di aiutare a raggiungere la governance basata su criteri.

Se si è ancora certi che l'organizzazione non può usare criteri DINE o Modify, questo articolo spiega come impedire (noto anche come disabilitare) i criteri di apportare modifiche automatiche all'ambiente Azure.

Il supporto per i selettori di risorse è applicabile anche per la governance basata su criteri per garantire che le procedure di distribuzione sicura (SDP) siano rispettate. I selettori di risorse consentono di implementare gradualmente le assegnazioni di criteri in base a fattori quali la posizione delle risorse, il tipo di risorsa o se la risorsa ha una posizione. Altre informazioni sono disponibili in questo documento.

Panoramica dell'approccio

Il diagramma seguente riepiloga l'approccio graduale suggerito:

1. Impostare la modalità di imposizione su DoNotEnforce per le assegnazioni di criteri:
   • Usando questa funzionalità, è possibile modificare il comportamento delle assegnazioni per farle diventare efficacemente un criterio solo di audit senza modificare la definizione sottostante del criterio.
   • Questo approccio consente anche di eseguire attività di correzione manuale su risorse non conformi usando le attività di correzione se si desidera.
2. Impostare la modalità di imposizione su Default per le assegnazioni di criteri per ripristinare la correzione automatica delle assegnazioni dei criteri DINE in un ambito ridotto:
   • È possibile scegliere di usare un intero ambiente, ad esempio il gruppo di gestione Sandbox.
   • Puoi usare una sottoscrizione per carichi di lavoro non critici.
3. Impostare la modalità di applicazione su Default per le assegnazioni delle policy nelle policy DINE rimanenti nell'intero ambiente Azure.

A causa delle restrizioni di conformità alle normative, alcuni clienti non possono mai passare dalla fase 1 precedente. Questo non è un problema ed è previsto di rimanere in questo stato, se necessario. Altri clienti possono passare alle fasi 2 e 3 per adottare completamente i criteri DINE e Modify per facilitare la governance basata su criteri per il proprio ambiente Azure.

Fase 1: Disabilitare DINE e modificare le azioni automatizzate dei criteri

Quando si assegna un criterio, per impostazione predefinita verrà applicato l'effetto definito nella definizione dei criteri. È consigliabile lasciare invariata la definizione dei criteri. Ad esempio, lasciare l'effetto di assegnazione dei criteri come DeployIfNotExists.

Anziché modificare la definizione dei criteri o il relativo effetto, è invece possibile influenzare questo comportamento con un impegno minimo usando la funzionalità per le assegnazioni di criteri.

Usare il portale di Azure per impostare la modalità di imposizione su Disabilitato

Questo screenshot mostra come usare il portale di Azure per impostare la modalità di imposizione su Disabilitato in un'assegnazione di criteri. Disabled è noto anche come DoNotEnforce.

Usare il modello di "ARM template" per impostare la modalità di imposizione su "DoNotEnforce".

Questo esempio di codice illustra come usare un modello ARM per impostare enforcementMode su DoNotEnforce in un'assegnazione di criteri. DoNotEnforce è noto anche come Disabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "___location": "[deployment().___location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "DoNotEnforce"
    … // other properties removed for display purposes
  }
}

Usando la modalità di imposizione, è possibile visualizzare l'effetto di una regola di criterio sulle risorse esistenti senza avviarne l'applicazione né attivare entrate nel registro delle attività di Azure. Questo scenario viene comunemente definito "What If" e si allinea alle procedure di distribuzione sicure.

Anche quando la modalità di imposizione è impostata su DoNotEnforce, le attività di correzione possono essere attivate manualmente. È possibile correggere risorse non conformi specifiche. È anche possibile vedere cosa avrebbe fatto la policy DINE o Modify se la modalità di applicazione fosse impostata su Default.

Rimanere nello stato della fase 1 in modo permanente

Come accennato nella sezione Panoramica dell'approccio , alcuni clienti potrebbero dover rimanere nella fase 1 per un lungo periodo o persino in modo permanente a causa dei requisiti. Questo stato è valido e i clienti possono rimanere in esso per qualsiasi periodo di tempo.

Forse è necessario rimanere in questo stato in modo permanente o per un lungo periodo, come anni. In tal caso, potrebbe essere preferibile adottare l'effetto AuditIfNotExists dei criteri (AINE) e le definizioni associate e impostare nuovamente la modalità di imposizione su Default.

Quando si passa da DINE a AINE e si reimposta la modalità di imposizione su Default come approccio a lungo termine o permanente per la fase 1, si otterranno le registrazioni nel log di attività di Azure per gli stati di conformità dei criteri. È possibile creare flussi di lavoro di automazione da queste voci di log nelle operazioni generali di gestione della piattaforma.

Si perderà la capacità di eseguire attività di correzione manuale. A differenza dei criteri DINE, i criteri AINE non eseguono distribuzioni, automatizzate o manuali.

Ricordarsi di aggiornare la definizione dei criteri per accettare e consentire l'effetto dell'assegnazione dei AuditIfNotExists criteri.

La tabella seguente riepiloga le opzioni e le implicazioni per i diversi tipi di effetti dei criteri e combinazioni di modalità di imposizione:

Fase 2: Abilitare DINE e modificare le politiche in un criterio specifico o su un ambito ristretto

In questa fase si apprenderà come impostare la modalità di applicazione su Default nelle assegnazioni delle policy.

Dopo aver completato la fase 1, si decide di voler testare e provare le funzionalità di automazione complete di DINE e Modificare i criteri in un criterio specifico o in un ambito ridotto. Vuoi utilizzare il gruppo di gestione Sandbox o una sottoscrizione non di produzione.

Per eseguire questa procedura, è prima necessario identificare il criterio o l'ambito ridotto che verrà usato per testare e provare le funzionalità complete di automazione dei criteri DINE e Modify.

Alcuni esempi suggeriti di ambiti e criteri sono illustrati nella tabella seguente:

È anche possibile decidere di usare un'attività di correzione manuale in un ambito limitato o in un set di risorse per testare il modo in cui questi criteri influiscono sull'ambiente. Per altre informazioni su come creare un'attività di correzione, vedere la documentazione di Criteri di Azure Creare un'attività di correzione.

Dopo aver identificato un criterio o criteri e l'ambito ridotto da assegnare, il passaggio successivo consiste nell'assegnare i criteri e impostare la modalità di imposizione su Default. Lascia l'effetto dei criteri, ad esempio DeployIfNotExists o Modify, così com'è nell'ambito ridotto selezionato.

Usare il portale di Azure per impostare la modalità di imposizione su Abilitato

Questo screenshot mostra come usare il portale di Azure per impostare la modalità di imposizione su Abilitato in un'assegnazione di criteri. Enabled è noto anche come predefinito.

Usare un modello di ARM per impostare la modalità di imposizione su Default

Questo esempio di codice illustra come usare un modello ARM per impostare enforcementMode su Default in un'assegnazione di criteri. Default è noto anche come Enabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "___location": "[deployment().___location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "Default"
    … // other properties removed for display purposes
  }
}

Testing

L'ultimo passaggio di questa fase consiste nell'eseguire i test necessari. Si vuole verificare se e in che modo i criteri DINE o Modify potrebbero influire e apportare modifiche ai carichi di lavoro, al codice, agli strumenti e ai processi.

Eseguire più test per acquisire l'intero ciclo di vita del carico di lavoro. Assicurarsi di comprendere appieno se e come i criteri "DINE" o "Modify" siano stati modificati.

Ecco alcuni esempi di test:

• Distribuzione iniziale del carico di lavoro.
• Distribuzione di codice/applicazione nell'ambiente di lavoro.
• Operazioni del giorno 2 e gestione del carico di lavoro.
• Disattivazione del carico di lavoro.

Fase 3: Abilitare DINE e modificare i criteri ovunque

In questa fase si apprenderà come impostare la modalità di applicazione su Default nelle assegnazioni delle policy.

Si presuppone che i test alla fine della fase 2 siano stati superati correttamente. In alternativa, forse si è soddisfatti che ora si capisce in che modo i criteri DINE o Modify interagiscono con il carico di lavoro. È ora possibile espandere l'uso dei criteri DINE e Modify nel resto dell'ambiente Azure.

Per procedere, seguire i passaggi simili ai passaggi della fase 2. Questa volta si imposta la modalità di imposizione su Default in tutte le assegnazioni di criteri DINE e Modifica nell'intero ambiente Azure.

Ecco una panoramica generale dei passaggi da eseguire in questa fase:

• Rimuovere gli incarichi utilizzati specificamente per i test durante la fase 2.
• Esaminare ogni assegnazione di criteri DINE e Modifica all'interno dell'ambiente Azure e impostare la modalità di imposizione su Default. Questo processo viene illustrato negli esempi della fase 2.
• Creare attività di correzione per le risorse esistenti non conformi seguendo le indicazioni riportate in Creare un'attività di correzione. Le nuove risorse verranno corrette automaticamente se corrispondono alle regole dei criteri e alle condizioni di esistenza.

Anche se nella fase 3 è consigliabile impostare la modalità di imposizione su Default per tutti i criteri DINE e Modify nell'ambiente Azure, questa scelta è comunque facoltativa. È possibile fare questa scelta per ogni criterio in base alle tue esigenze e requisiti.

Gestione avanzata dei criteri

Per la gestione avanzata di Criteri di Azure su larga scala, è consigliabile implementare Criteri aziendali come codice (EPAC) per gestire i criteri. EPAC offre un'esperienza di gestione stateful che utilizza IaC. In genere si adatta a scenari di gestione delle politiche di ampia portata con requisiti complessi.