Condividi tramite

Adottare misure di protezione basate su criteri

  • Articolo

Prima di usare criteri, è necessario determinare dove vengono usati nelle implementazioni di riferimento delle zone di destinazione di Azure e perché. Questo articolo aiuta a definire se si vuole impedire che i criteri DeployIfNotExists (DINE) o Modify apportino modifiche all'interno dell'ambiente Azure.

Perché usare criteri DINE e Modify?

I criteri DINE e Modify fanno parte delle implementazioni di riferimento delle zone di destinazione di Azure. Consentono all'utente e all'organizzazione di garantire la conformità delle zone di destinazione, note anche come sottoscrizioni, e delle risorse in esse contenute. Questi criteri eliminano anche il carico operativo per i team della piattaforma e della zona di destinazione man mano che l'ambiente Azure si ridimensiona.

Ad esempio, si consideri uno scenario in cui venga effettuato il provisioning della sottoscrizione di una nuova zona di destinazione e la sottoscrizione venga inserita nel gruppo di gestione "corp". I criteri DINE e Modify eseguiranno quindi le azioni seguenti per la sottoscrizione della zona di destinazione:

  • Abilitano Microsoft Defender for Cloud. Configurano le esportazioni di Defender for Cloud nell'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.
  • Abilitano Defender for Cloud per le diverse offerte supportate in base ai parametri dei criteri configurati nell'assegnazione dei criteri.
  • Configurano i log attività di Azure da inviare all'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.
  • Configurano le impostazioni di diagnostica per tutte le risorse da inviare all'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.
  • Distribuiscono 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. Li connettono all'area di lavoro Log Analytics centrale nella sottoscrizione di gestione.

Nota

È possibile disabilitare le opzioni precedenti in qualsiasi momento o durante la distribuzione delle implementazioni di riferimento delle zone di destinazione di Azure.

L'elenco precedente mostra un subset di tutti i criteri assegnati nell'ambito dell'acceleratore della zona di destinazione di Azure. Per un elenco completo dei criteri che possono essere assegnati dall'implementazione di riferimento della zona di destinazione di Azure, vedere Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione di Azure.

Il repository bicep delle zone di destinazione di Azure è modulare. I criteri predefiniti precedenti possono essere distribuiti con il modulo Assegnazioni di criteri predefinite di ALZ.

Tutti i criteri assegnati consentono all'utente e ai proprietari della zona di destinazione di restare conformi. Nessuna effettiva risorsa del carico di lavoro viene distribuita tramite i criteri DINE o Modify. E questa opzione non è consigliata. Per altre informazioni, vedere È consigliabile usare Criteri di Azure per distribuire i carichi di lavoro?. Questi criteri DINE distribuiscono o configurano solo risorse o impostazioni ausiliarie o di supporto.

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

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

Se ci si riconosce negli esempi precedenti o in scenari simili, questo articolo descrive come adottare l'architettura concettuale delle zone di destinazione di Azure e rispettarne i principi di progettazione. Anche se inizialmente non sarà necessario usare determinati criteri, è possibile scegliere di abilitarli gradualmente in futuro. L'obiettivo è contribuire a realizzare una governance basata su criteri.

Importante

In questo articolo verranno usati due possibili valori per i termini correlati alla modalità di imposizione:

  • Disabled o DoNotEnforce
  • Enabled o Default

Il portale di Azure usa Disabled e Enabled per la modalità di imposizione. I modelli di Azure Resource Manager (ARM) e altre interfacce API usano DoNotEnforce e Default per le stesse opzioni.

Per altre informazioni, vedere Modalità di imposizione.

Se i dubbi relativi alla possibilità di usare criteri DINE o Modify persistono, questo articolo descrive come impedire ai criteri di apportare modifiche automatiche all'ambiente Azure (o disabilitarli).

Nota

Questa operazione non è permanente. I criteri possono essere riabilitati in qualsiasi momento da un membro del team della piattaforma se in seguito si decide di usare criteri DINE o Modify.

Per altre informazioni, vedere le fasi 2 e 3.

Il supporto per i selettori di risorse è applicabile anche per la governance basata su criteri per garantire che le procedure di distribuzione (SDP) Cassaforte 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 mostra un riepilogo dell'approccio per fasi suggerito:

Immagine che mostra una panoramica delle fasi DINE.

  1. Impostare la modalità di imposizione su DoNotEnforce per le assegnazioni di criteri:
    • Usando questa funzionalità, è possibile modificare il comportamento delle assegnazioni in modo che i criteri diventino di solo controllo, senza modificare la definizione dei criteri sottostante.
    • Questo approccio consente anche di eseguire correzioni manuali su risorse non conformi usando attività di correzione se necessario.
  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 dell'ambiente sandbox.
    • In alternativa, è possibile usare una sottoscrizione di un carico di lavoro non critico.
  3. Impostare la modalità di imposizione su Default nelle assegnazioni dei criteri per i criteri DINE rimanenti nell'intero ambiente Azure.

A causa di restrizioni di conformità alle normative, alcuni clienti potrebbero non superare mai la fase 1. Questo non è un problema e l'eventualità di restare in questo stato è supportata, se necessario. Altri clienti possono continuare fino alle fasi 2 e 3 per adottare completamente i criteri DINE e Modify in modo da semplificare la governance basata su criteri per l'ambiente Azure.

Nota

Lo scenario e l'approccio presentati in questo articolo non sono destinati o consigliati per la maggior parte dei clienti. Vedere la sezione Perché usare i criteri DINE e Modify? prima di decidere se questi criteri sono adatti e necessari per il proprio ambiente.

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

Quando si assegna un criterio, per impostazione predefinita viene applicato l'effetto specificato nella definizione del criterio. È consigliabile lasciare la definizione del criterio così com'è. Ad esempio, lasciare l'effetto della definizione del criterio come DeployIfNotExists.

Invece di modificare la definizione del criterio o il suo effetto, è possibile influire su questo comportamento con attività minime usando la funzionalità nelle assegnazioni dei criteri.

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

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

Impostare la modalità di imposizione su Disabilitato nella portale di Azure.

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

Questo esempio di codice mostra come usare un modello di ARM per impostare enforcementMode su DoNotEnforce in un'assegnazione di criteri. L'impostazione DoNotEnforce è nota 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 osservare l'effetto di un criterio sulle risorse esistenti senza avviarlo o attivare voci nel log attività di Azure. Questo scenario è normalmente noto come "What If" ed è allineato a procedure di distribuzione sicure.

Anche quando la modalità di imposizione è impostata su DoNotEnforce, è possibile attivare manualmente le attività di correzione. È possibile correggere risorse non conformi specifiche. È anche possibile osservare quale operazione verrebbe eseguita dai criteri DINE o Modify se la modalità di imposizione fosse impostata su Default.

Importante

Quando la modalità di imposizione è impostata su DoNotEnforce, le voci nel log attività di Azure non vengono generate. Tenere conto di questo fattore se si vuole ricevere una notifica quando viene creata una risorsa non conforme.

Restare in modo permanente nello stato della fase 1

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

Può essere necessario restare in questo stato in modo permanente o per un lungo periodo, ad esempio per più anni. In questo caso, può essere preferibile adottare l'effetto del criterio AuditIfNotExists (AINE) e le definizioni associate e impostare la modalità di imposizione di nuovo su Default.

Nota

Passando a usare un criterio AINE e impostando la modalità di imposizione su Default, si raggiunge lo stesso obiettivo della disabilitazione dei criteri DINE.

Quando si passa da DINE ad AINE e si imposta la modalità di imposizione su Default come approccio a lungo termine o permanente per la fase 1, si riottengono le voci del log attività di Azure per gli stati di conformità ai 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 manuali. A differenza dei criteri DINE, i criteri AINE non eseguono alcuna distribuzione, né automatica né manuale.

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

La tabella seguente contiene un riepilogo delle opzioni e implicazioni per i diversi tipi di effetti dei criteri e le combinazioni con la modalità di imposizione:

Effetto dei criteri Modalità di imposizione Voce del log attività Azione di correzione
DINE Enabled o Default Sì Correzione attivata dalla piattaforma su larga scala dopo la creazione o l'aggiornamento delle risorse. È necessaria la creazione manuale di un'attività di correzione se la risorsa dipendente viene modificata o è preesistente prima dell'assegnazione dei criteri.
DINE Disabled o DoNotEnforce No È necessaria la creazione manuale di un'attività di correzione.
Modifica Enabled o Default Sì Correzione automatica durante la creazione o l'aggiornamento.
Modifica Disabled o DoNotEnforce No È necessaria la creazione manuale di un'attività di correzione.
Nega Enabled o Default Sì Creazione o aggiornamento negato.
Nega Disabled o DoNotEnforce No Creazione o aggiornamento consentito. È necessaria un'attività di correzione.
Audit/AINE Enabled o Default Sì È necessaria un'attività di correzione.
Audit/AINE Disabled o DoNotEnforce No È necessaria un'attività di correzione.

Nota

Esaminare le linee guida in Reazione a eventi di modifica dello stato di Criteri di Azure per determinare se l'uso dell'integrazione di Griglia di eventi di Azure con Criteri di Azure offra un approccio appropriato se si intende creare un'automazione personalizzata in base agli eventi di stato dei criteri.

Fase 2: Abilitare i criteri DINE e Modify in un criterio specifico o in un ambito ridotto

In questa fase si apprenderà come impostare la modalità di imposizione su Default nelle assegnazioni dei criteri.

Al termine della fase 1, si decide di testare e provare le funzionalità di automazione completa dei criteri DINE e Modify in un criterio specifico o in un ambito ridotto. Si vuole usare il gruppo di gestione dell'ambiente sandbox o una sottoscrizione di un carico di lavoro non di produzione.

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

Nota

Potrebbe essere necessario esaminare e implementare un approccio di test per una piattaforma di livello aziendale. In questo modo, è possibile testare i criteri e altre modifiche della piattaforma in una gerarchia di gruppi di gestione separati all'interno dello stesso tenant.

Questo approccio è noto anche come distribuzione "canary".

La tabella seguente contiene alcuni esempi suggeriti di ambiti e criteri:

Quando si vuole... Scegliere tra questi ambiti Criteri di esempio da usare
- Testare le funzionalità di correzione automatizzata dei criteri DINE/Modify.
- Verificare quale può essere l'effetto sui processi di distribuzione completa e sulle pipeline CI/CD, inclusi i test.
- Verificare quale può essere l'effetto sul carico di lavoro.		 - Sottoscrizione sandbox
- Gruppo di gestione sandbox
- Sottoscrizione della zona di destinazione del carico di lavoro non di produzione
- Ambiente "canary" di livello aziendale		 - Configurare i log attività di Azure per il flusso in un'area di lavoro Log Analytics specificata.
- Distribuire La configurazione di Defender for Cloud.
- Abilitare Monitoraggio di Azure per le macchine virtuali o i set di scalabilità di macchine virtuali.
- Distribuire impostazioni di diagnostica nei servizi di Azure.
- Abilitare potenzialmente solo per servizi specifici all'interno dell'iniziativa.

Si potrebbe anche decidere di usare un'attività di correzione manuale in un ambito o un set di risorse limitato per verificare in che modo questi criteri influiranno sull'ambiente. Per altre informazioni su come creare un'attività di correzione, vedere la documentazione di Criteri di Azure su come creare un'attività di correzione.

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

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

Questo screenshot mostra come usare il portale di Azure per impostare la modalità di imposizione su Enabled in un'assegnazione di criteri. L'impostazione Enabled è nota anche come Default.

Screenshot che mostra l'impostazione della modalità di imposizione su Abilitato nel portale di Azure.

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

Questo esempio di codice mostra come usare un modello di ARM per impostare enforcementMode su Default in un'assegnazione di criteri. L'impostazione Default è nota 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
  }
}

Test in corso

L'ultimo passaggio di questa fase consiste nell'eseguire i test necessari. Si vuole verificare se e come i criteri DINE o Modify hanno influito su carichi di lavoro, codice, strumenti e processi e hanno apportato modifiche.

Eseguire più test per acquisire l'intero ciclo di vita del carico di lavoro. Si vuole avere la certezza di determinare in modo completo se e come i criteri DINE o Modify hanno apportato modifiche.

Ecco alcuni esempi di test:

  • Distribuzione iniziale del carico di lavoro.
  • Distribuzione del codice/dell'applicazione nel carico di lavoro.
  • Operazioni del giorno 2 e gestione del carico di lavoro.
  • Rimozione delle autorizzazioni del carico di lavoro.

Fase 3: Abilitare i criteri DINE e Modify ovunque

In questa fase si apprenderà come impostare la modalità di imposizione su Default nelle assegnazioni dei criteri.

Si presuppone che i test alla fine della fase 2 siano stati superati. Oppure si è soddisfatti di aver determinato il modo in cui i criteri DINE o Modify interagiscono con il carico di lavoro. È ora possibile espandere l'uso dei criteri DINE e Modify in tutto l'ambiente Azure.

Per continuare, è necessario seguire passaggi simili a quelli della fase 2. Questa volta si imposterà la modalità di imposizione su Default in tutte le assegnazioni di criteri DINE e Modify nell'intero ambiente Azure.

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

  • Rimuovere le assegnazioni usate in modo specifico per i test durante la fase 2.
  • Passare tra le diverse assegnazioni dei criteri DINE e Modify nell'ambiente Azure e impostare la modalità di imposizione su Default. Questo processo viene mostrato negli esempi nella fase 2.
  • Creare attività di correzione per le risorse esistenti non conformi seguendo le linee guida incluse in Creare un'attività di correzione. Le nuove risorse verranno automaticamente corrette 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 scegliere in base ai criteri per soddisfare esigenze e requisiti specifici.

Gestione avanzata dei criteri

Per la gestione avanzata dei Criteri di Azure su larga scala, prendere in considerazione l'implementazione di Criteri aziendali come codice (EPAC) per gestire i criteri. EPAC offre un'esperienza di gestione con stato che usa IaC. In genere si adatta a scenari di gestione dei criteri di grandi dimensioni con requisiti complessi.