Procedure consigliate per l'enclave di Azure

Questo articolo descrive i concetti chiave e le procedure consigliate per Azure Enclave.

Azure Enclave accelera e semplifica la distribuzione e la gestione di ambienti cloud sicuri, isolati e conformi. Questi ambienti sono progettati per gestire le missioni e i carichi di lavoro più sensibili negli ambienti commerciali e in quelli isolati dalla rete.

La compilazione e l'esecuzione di carichi di lavoro in Azure Enclave richiedono la comprensione e l'implementazione di alcuni concetti chiave, tra cui:

• Modelli di progettazione di rete e organizzazione
• Modelli di progettazione della sicurezza
• Gruppi di risorse gestite

Il gruppo di prodotti Azure Enclave, i team di progettazione e i team sul campo hanno sviluppato le procedure consigliate e gli articoli concettuali seguenti. Gli articoli sono stati creati per aiutare i proprietari e gli sviluppatori di community e enclave a comprendere meglio i concetti importanti e implementare le funzionalità appropriate.

Configurazione di Azure

Leggere questi passaggi di installazione per determinare se questi passaggi di configurazione si adattano ai casi d'uso dell'enclave Azure.

Configurare i gruppi di risorse di Network Watcher

Per evitare potenziali problemi con la creazione del log del flusso di rete virtuale, configurare manualmente in anticipo il gruppo di risorse NetworkWatcherRG e assegnare all'app Mission Enclave il ruolo Owner per tale gruppo di risorse, oppure verificare che la configurazione e l'assegnazione del ruolo siano avvenute automaticamente prima di creare la prima enclave nella sottoscrizione.

Per attenuare questo potenziale problema, creare manualmente per ogni sottoscrizione il gruppo di risorse NetworkWatcher denominato NetworkWatcherRG nelle nuove sottoscrizioni e quindi concedere Mission Enclave all'app Azure Enclave Owner per NetworkWatcherRG:

1. Selezionare il NetworkWatcherRG gruppo di risorse, selezionare Access control (IAM), quindi selezionare Add e Add role assignment.

1. Selezionare Privileged administrator roles, selezionare owner, quindi selezionare Next.

1. Selezionare Select members, digitare Mission Enclave nella ricerca e selezionare l'app Mission Enclave , selezionare Select, quindi Next.

1. Se la sottoscrizione richiede una condizione, selezionare Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended), quindi selezionare Review + assign.

1. Al termine dell'aggiornamento, è possibile iniziare a distribuire le risorse Enclave di Azure.

Quando viene creata una community o un enclave, Azure Enclave tenta i passaggi seguenti:

1. Controllare se l'oggetto NetworkWatcherRG esiste. In caso contrario, tentare di creare quel gruppo di risorse.
2. Verificare se l'app Mission Enclave ha un'assegnazione Owner permanente su NetworkWatcherRG. In caso contrario, tentare di assegnare l'app Mission Enclave come assegnazione permanente Owner in NetworkWatcherRG. Anche se esiste un'autorizzazione ereditata Owner , viene tentata la creazione di un'assegnazione permanente Owner .
3. Se un passaggio non va a buon fine, le distribuzioni di enclave potrebbero non riuscire durante il tentativo di creare i log di flusso della rete virtuale.

Modelli di progettazione di rete e organizzazione per l'enclave di Azure

Multi-tenancy

• Come organizzare le risorse

Progettazione della rete

Azure Enclave riunisce le funzionalità e la flessibilità di diversi prodotti di rete Azure in un'interfaccia utente semplificata, tra cui:

• Rete WAN virtuale di Azure
• Firewall di Azure
• Rete virtuale di Azure
• Gruppi di sicurezza di rete

Azure Enclave offre le raccomandazioni generali seguenti:

• Le community devono essere distribuite quando si hanno requisiti di rete per fornire un Firewall di Azure, ovvero la piattaforma distribuita come servizio per la sicurezza del firewall intelligente di Azure.
• Le community devono essere usate quando si hanno requisiti di separazione organizzativa o di sensibilità dei dati per separare una rete WAN virtuale hub-spoke da un'altra rete WAN virtuale hub-spoke.
• Le community devono essere distribuite quando si hanno requisiti di rete per supportare i sistemi che si estendono su più aree Azure, in cui ogni area richiede un proprio Firewall di Azure. Altre informazioni sui casi d'uso di Firewall di Azure multi-hub.
• Le community devono essere implementate quando vi sono requisiti di rete per supportare un numero elevato di sistemi in una rete geografica distribuita di tipo hub-and-spoke. Altre informazioni sulle rete WAN virtuale di Azure.
• Le enclave devono essere distribuite quando si hanno requisiti di rete per distribuire carichi di lavoro simili come parte della stessa rete privata.
• Le enclave devono essere distribuite quando si hanno requisiti del carico di lavoro che richiedono una rete virtuale e si trovano all'interno dello stesso rete WAN virtuale di una community esistente.

Considerazioni sulla progettazione di una rete di comunità

Quando si pianificano le reti della community, è consigliabile seguire la documentazione delle procedure consigliate per i servizi Azure sottostanti. Incluse queste procedure consigliate:

• Procedure consigliate per Firewall di Azure
• Firewall di Azure multi-hub-spoke
• Architettura hub-and-spoke di rete WAN virtuale di Azure
• topologia di rete rete WAN virtuale di Azure
• Domande frequenti su rete WAN virtuale di Azure

Considerazioni sulla progettazione della rete enclave

Quando si pianificano le reti enclave, è consigliabile seguire la documentazione delle procedure consigliate per i servizi Azure sottostanti. Incluse queste procedure consigliate:

• Concetti e procedure consigliate della rete virtuale di Azure
• Panoramica dei gruppi di sicurezza di rete

Scopri di più sulle procedure consigliate generali relative alla rete di Azure.

Distribuzione del carico di lavoro

• I carichi di lavoro sono collegati a un gruppo di risorse gestite in cui i collaboratori dell'enclave possono distribuire Azure risorse.
• Per impostazione predefinita, tutti i carichi di lavoro dell'enclave Azure sono regolati tramite iniziative di Criteri di Azure predefinite
• I carichi di lavoro associati a una community con una configurazione di governance personalizzata, usano questa configurazione univoca anziché la configurazione predefinita di governance dell'enclave Azure.
• Considerazioni sulla denominazione delle risorse Azure

Modelli di progettazione della sicurezza per l'enclave di Azure

Prendere in considerazione questi modelli di progettazione della sicurezza durante la progettazione degli ambienti enclave Azure.

Limiti di sicurezza

Azure Enclave usa un approccio di difesa avanzata quando si tratta di cybersecurity. Quando si distribuisce una community e enclave, Azure Enclave stabilisce diversi livelli di isolamento della rete, sicurezza, controlli di accesso e registrazione e monitoraggio.

Responsabilità di sicurezza condivise

Come servizio in Azure, anche Azure Enclave si impegna a sostenere il modello di responsabilità condivisa nel cloud. Per Azure enclave in modo specifico, i carichi di lavoro sono responsabilità dell'utente. Il modello di responsabilità condivisa di Azure si applica ai carichi di lavoro se hai distribuito servizi PaaS nei tuoi carichi di lavoro.

Le comunità e le enclave rappresentano una responsabilità condivisa. Le community e gli enclave usano un modello di responsabilità condivisa in cui il provider di risorse dell'enclave Azure crea l'ambiente di rete hub-spoke preconfigurato protetto. È possibile gestire questo ambiente di rete creando endpoint dell'enclave, endpoint della community, hub di transito o connessioni enclave. Alcune versioni di anteprima di Azure Enclave consentono anche di apportare manualmente modifiche alla rete tramite i controlli sottostanti forniti da rete WAN virtuale di Azure, Rete virtuale di Azure e altri servizi di rete Azure sottostanti.

Il governo di Azure Enclave è anche una responsabilità condivisa. Il provider di risorse dell'enclave Azure crea un elenco protetto e preconfigurato di iniziative Criteri di Azure per distribuzione del carico di lavoro. Tuttavia, le community ora hanno la possibilità di personalizzare la community Criteri di Azure Iniziative, che sostituisce l'elenco preconfigurato per il carico di lavoro. Nonostante i requisiti dei criteri, mantenere la possibilità di effettuare esenzioni manuali per queste assegnazioni di iniziative di Criteri di Azure, a seconda dei requisiti di conformità o governance.

Procedure consigliate per la sicurezza di Azure

Azure Enclave consiglia di seguire Microsoft Azure procedure consigliate e modelli di sicurezza per la distribuzione di risorse Azure e l'implementazione dei carichi di lavoro.

È consigliabile seguire le procedure consigliate per la sicurezza Azure: Cloud Adoption Framework per organizzare i sistemi, l'infrastruttura cloud, il personale IT e le strutture di raggruppamento e formazione sulla sicurezza informatica aziendale.

Esfiltrazione di dati tramite Domain Name System

L'esfiltrazione dei dati tramite DNS (Domain Name System) rappresenta un problema di sicurezza significativo per le organizzazioni, poiché usa un protocollo generalmente consentito tramite firewall e raramente monitorato per attività dannose. Gli utenti malintenzionati possono sfruttare le query DNS per estrarre i dati sensibili da sistemi compromessi codificando le informazioni all'interno dei nomi di dominio o usando tecniche di tunneling DNS. Questo metodo è insidioso perché il traffico DNS appare legittimo e spesso ignora gli strumenti di monitoraggio della sicurezza tradizionali.

Negli attacchi di esfiltrazione di dati basati su DNS, gli attori malintenzionati codificano i dati rubati in query DNS, spesso usando tecniche come l'etichettatura del sottodominio o le query sui record TXT. Ad esempio, un utente malintenzionato potrebbe suddividere i dati sensibili in blocchi e incorporare ogni blocco come sottodominio nelle query DNS ai domini controllati dall'utente malintenzionato. I dati possono essere estratti dai log DNS sul server DNS dell'attaccante. Questo approccio consente l'esfiltrazione graduale di set di dati di grandi dimensioni mantenendo un profilo basso, perché le query DNS vengono visualizzate come richieste di risoluzione dei nomi normali.

Affrontare l'esfiltrazione dei dati con i criteri di sicurezza DNS di Azure

I criteri di sicurezza di DNS di Azure garantiscono una protezione completa contro gli attacchi di esfiltrazione dei dati basati su DNS offrendo un controllo granulare sul traffico DNS all'interno delle reti virtuali di Azure. Questo servizio consente alle organizzazioni di implementare misure di sicurezza proattive in grado di rilevare, inviare avvisi e bloccare attività DNS sospette prima che i dati possano essere esfiltrati correttamente.

Il criterio di sicurezza di DNS di Azure affronta l'esfiltrazione di dati DNS attraverso diversi meccanismi chiave. In primo luogo, offre la possibilità di creare regole di traffico DNS che possono bloccare le query a domini dannosi noti o modelli di dominio sospetti comunemente usati nei tentativi di esfiltrazione. Le organizzazioni possono gestire elenchi di domini bloccati associati ai servizi di comando e controllo dell'infrastruttura o dell'esfiltrazione dei dati. In secondo luogo, il servizio offre funzionalità di registrazione DNS complete che acquisisce tutte le query e le risposte DNS all'interno di reti virtuali protette. Questa registrazione consente ai team di sicurezza di analizzare i modelli di traffico DNS e identificare potenziali tentativi di esfiltrazione. In terzo luogo, il motore delle policy supporta il filtraggio dei domini tramite caratteri jolly, consentendo alle organizzazioni di bloccare intere categorie di domini sospetti o definire liste di elementi consentiti per destinazioni DNS approvate.

L'implementazione di criteri di sicurezza di DNS di Azure crea più livelli di difesa contro l'esfiltrazione di dati DNS. Le regole di traffico possono essere configurate con diversi livelli di priorità, consentendo criteri di sicurezza complessi che bilanciano la sicurezza con i requisiti operativi. Il servizio supporta il blocco in tempo reale di query dannose, fornendo log dettagliati per l'analisi forense e la ricerca di minacce. Inoltre, i collegamenti di rete virtuale assicurano che i criteri di sicurezza DNS vengano applicati in modo coerente in tutte le risorse all'interno di segmenti di rete protetti, creando un perimetro di sicurezza completo che è difficile per gli utenti malintenzionati ignorare.

Per le distribuzioni di Azure Enclave, i criteri di sicurezza DNS di Azure devono essere integrati nell'ambito dell'architettura di sicurezza complessiva. Le organizzazioni devono configurare i criteri di sicurezza DNS per monitorare e controllare il traffico DNS dai carichi di lavoro dell'enclave, assicurandosi che i dati sensibili rimangano protetti anche se i singoli carichi di lavoro vengono compromessi. La revisione e l'aggiornamento regolari degli elenchi di domini DNS, combinati con il monitoraggio continuo dei log DNS, offre una protezione continua dalle minacce basate su DNS in continua evoluzione e consente di mantenere l'integrità della sicurezza dell'ambiente dell'enclave Azure.

Per altre informazioni, vedere la documentazione relativa ai criteri di sicurezza DNS.

Implementazione di criteri di sicurezza DNS con negazione predefinita

Per garantire la massima sicurezza negli ambienti enclave di Azure, le organizzazioni devono implementare un approccio "Nega per impostazione predefinita, consenti per eccezione" al filtro DNS. Questo modello di sicurezza garantisce che tutte le query DNS vengano bloccate, a meno che non siano consentite in modo esplicito, fornendo la protezione più avanzata dall'esfiltrazione dei dati basata su DNS e dalle comunicazioni di comando e controllo.

L'approccio di negazione predefinita viene implementato mediante una struttura di regole DNS a due livelli nei Criteri di sicurezza DNS di Azure:

Passaggio 1: Creare la regola di negazione predefinita Creare un elenco di domini DNS contenente solo il dominio . radice (punto). Questo dominio wildcard corrisponde a tutte le possibili query DNS. Associare questo elenco di domini a una regola di traffico DNS configurata con:

• Priorità: 65000 (priorità più bassa)
• Azione: Blocco
• Elenco domini: dominio radice (.)

Questa regola funge da regola residuale e blocca qualsiasi query DNS non esplicitamente consentita da regole con priorità superiore.

Passaggio 2: Creare regole per l'elenco elementi consentiti Creare elenchi di domini DNS separati contenenti domini specifici necessari per le operazioni aziendali legittime. Questi potrebbero includere:

• Servizi di Azure essenziali ( ad esempio *.azure.com, *.microsoft.com)
• Domini aziendali e servizi non Microsoft attendibili
• Servizi di aggiornamento del sistema operativo
• Domini dell'autorità di certificazione

Associare gli elenchi consentiti alle regole di traffico DNS configurate con:

• Priorità: 500-1000 (priorità superiore alla negazione predefinita)
• Azione: Consenti
• Elenchi di dominio: domini approvati specifici

Elaborazione delle regole basata sulla priorità Il criterio di sicurezza di DNS di Azure elabora le regole in ordine di priorità (numeri inferiori = priorità più alta). Quando viene eseguita una query DNS:

1. Il sistema valuta innanzitutto le regole di autorizzazione ad alta priorità (priorità 500-1000)
2. Se il dominio corrisponde a un elenco di elementi consentiti, la query è consentita
3. Se non corrisponde alcuna allow regola, la query passa alla regola di negazione predefinita (priorità 65000) e il traffico viene bloccato

Questo approccio offre diversi vantaggi per la sicurezza:

• Modello zero trust: non sono consentite query DNS a meno che non siano autorizzate in modo esplicito
• Controllo granulare: le organizzazioni possono controllare con precisione quali domini sono accessibili
• Audit trail: tutte le query bloccate vengono registrate, offrendo visibilità sulle potenziali minacce
• Aggiornamenti incrementali: è possibile aggiungere nuovi domini approvati per consentire elenchi senza modificare la regola di negazione predefinita

Implementazione di esempio:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

Le organizzazioni che implementano questo approccio devono iniziare con un inventario completo dei domini necessari e perfezionare gradualmente l'elenco dei domini consentiti in base alle esigenze operative e ai log di sicurezza. La revisione regolare delle query bloccate consente di identificare i domini legittimi che potrebbero essere necessari per essere aggiunti agli elenchi consenti mantenendo al tempo stesso un comportamento di sicurezza sicuro.

Implementare criteri DNS di negazione predefinita con Server DNS di Windows

Per gli ambienti che non possono utilizzare i Criteri di sicurezza di DNS di Azure o che richiedono il controllo DNS on-premises, è possibile implementare un modello di sicurezza simile basato sul principio del blocco predefinito usando il Server DNS di Windows con le funzionalità dei criteri DNS. Questo approccio offre una protezione paragonabile rispetto all'esfiltrazione di dati basata su DNS mantenendo al contempo la compatibilità con l'infrastruttura di Windows esistente.

Windows server DNS (Windows Server 2016 e versioni successive) supporta la funzionalità dei criteri DNS che consente alle organizzazioni di implementare regole di filtro DNS sofisticate. Il modello deny-by-default può essere ottenuto tramite una combinazione di regole di criteri DNS e configurazioni di zona.

Gruppi di risorse gestiti in Azure Enclave

Gruppi di risorse che contengono risorse gestite da Azure Enclave.

Gruppo di risorse gestite dalla community

Il gruppo di risorse gestite dalla community contiene le risorse dell'infrastruttura descritte in Che cos'è una community?.

Il nome del gruppo di risorse gestito dalla community segue questa convenzione di denominazione: myCommunityName-HostedResources-<GUID>. Ogni distribuzione della community crea questo gruppo di risorse e inserisce l'infrastruttura della community al suo interno. Quando si elimina la community, il provider di risorse Azure Enclave elimina automaticamente il gruppo di risorse gestito dalla community.

Il gruppo di risorse gestite dalla community presenta le limitazioni seguenti:

• Non è possibile specificare un gruppo di risorse esistente per il gruppo di risorse gestito dalla community.
• Non è possibile specificare una sottoscrizione diversa per il gruppo di risorse gestite dalla community.
• Non è possibile modificare il nome del gruppo di risorse gestito dalla community dopo la creazione della community.
• Non è possibile specificare nomi per le risorse gestite all'interno del gruppo di risorse gestite della community.
• Non è possibile modificare o eliminare tag creati Azure di risorse gestite all'interno del gruppo di risorse gestite della community.

Se si modificano o si eliminano tag, risorse e altre proprietà delle risorse creati Azure nel gruppo di risorse gestite dalla community, è possibile che vengano visualizzati risultati imprevisti. Come Azure Enclave gestisce il ciclo di vita dell'infrastruttura nel gruppo di risorse gestite dalla community, eventuali modifiche potrebbero potenzialmente spostare l'enclave in uno stato non supportato.

Uno scenario comune in cui si vuole modificare le risorse consiste nell'usare i tag. Azure Enclave consente di creare e modificare tag propagati alle risorse nel gruppo di risorse gestite dalla community. Potrebbe essere necessario creare o modificare tag personalizzati da assegnare ad esempio a una business unit o a un centro di costo. Questo può essere ottenuto anche creando criteri di Azure con ambito nel gruppo di risorse gestito dalla community.

Note

Se il blocco del gruppo di risorse gestito dalla community non è abilitato, è possibile modificare direttamente qualsiasi risorsa nel gruppo di risorse gestite dalla community. La modifica diretta delle risorse nel gruppo di risorse gestite dalla community può causare l'instabilità o la mancata risposta dell'enclave.

Gruppo di risorse gestite dall'enclave

Il gruppo di risorse gestite dall'enclave contiene le risorse dell'infrastruttura descritte in Che cos'è un enclave?.

Il nome del gruppo di risorse gestite dall'enclave segue questa convenzione di denominazione: myEnclaveName-HostedResources-<GUID>. Ogni distribuzione dell'enclave crea questo gruppo di risorse e inserisce l'infrastruttura dell'enclave al suo interno. Quando si elimina l'enclave, il provider di risorse Azure Enclave elimina automaticamente il gruppo di risorse gestite dall'enclave.

Il gruppo di risorse gestite dall'enclave presenta le limitazioni seguenti:

• Non è possibile specificare un gruppo di risorse esistente per il gruppo di risorse gestite dall'enclave.
• Non è possibile specificare una sottoscrizione diversa per il gruppo di risorse gestite dall'enclave.
• Non è possibile modificare il nome del gruppo di risorse gestite dall'enclave dopo la creazione dell'enclave.
• Non è possibile specificare nomi per le risorse gestite all'interno del gruppo di risorse gestite dell'enclave.
• Non è possibile modificare o eliminare tag creati Azure di risorse gestite all'interno del gruppo di risorse gestite dell'enclave.

Se si modificano o si eliminano tag, risorse e altre proprietà delle risorse create Azure nel gruppo di risorse gestite dall'enclave, è possibile ottenere risultati imprevisti, ad esempio errori di rete, accesso e monitoraggio. Poiché Azure Enclave gestisce il ciclo di vita dell'infrastruttura nel gruppo di risorse gestite dall'enclave, eventuali modifiche potrebbero potenzialmente spostare l'enclave in uno stato non supportato.

Uno scenario comune in cui si vuole modificare le risorse consiste nell'usare i tag. Azure Enclave consente di creare e modificare tag propagati alle risorse nel gruppo di risorse gestite dall'enclave. Potrebbe essere necessario creare o modificare tag personalizzati da assegnare ad esempio a una business unit o a un centro di costo. L'assegnazione di tag alle risorse può essere ottenuta anche creando criteri di Azure con ambito impostato sul gruppo di risorse gestite dell'enclave.

Avvertimento

La modifica delle risorse nel gruppo di risorse gestito dell'enclave può rendere l'enclave instabile o non rispondente.

Gruppo di risorse per il carico di lavoro

Il carico di lavoro è collegato a uno o più gruppi di risorse in cui è possibile creare e organizzare le risorse Azure.

Aggiungere un gruppo di risorse a un carico di lavoro

L'aggiunta di un nuovo gruppo di risorse richiede in genere all'utente di avere le autorizzazioni per creare un nuovo gruppo di risorse. I ruoli della sottoscrizione Owner o Contributor dispongono di questa autorizzazione, ma la persona che crea il gruppo di risorse del carico di lavoro potrebbe non disporre di questa autorizzazione privilegiata né averne bisogno. Azure Enclave tenta tre modi per creare il nuovo gruppo di risorse, dal più alto al più basso requisito di autorizzazione utente, offrendo flessibilità per l'utente:

• Opzione 1: richiede le autorizzazioni con privilegi più elevate per il singolo utente che crea o aggiorna il carico di lavoro, fornendo il controllo completo, ma richiedendo l'accesso con privilegi elevati.
• Opzione 2: prevede la configurazione manuale da parte dell'utente per concedere Mission Enclave la proprietà dell'applicazione a livello di sottoscrizione, che potrebbe non essere allineata alle preferenze.
• Opzione 3: non richiede autorizzazioni per l'utente o l'applicazione Mission Enclave , rendendo il metodo più semplice ma imponendo una relazione 1:1 rigorosa tra il gruppo di risorse e il carico di lavoro.

Ogni opzione presenta vantaggi e limitazioni, controllo di bilanciamento, praticità e flessibilità per soddisfare esigenze diverse. Queste opzioni vengono valutate a partire dall'opzione 1 e la prima opzione per avere esito positivo viene usata per creare il nuovo gruppo di risorse.

Dopo aver creato un gruppo di risorse del carico di lavoro usando l'opzione 3, viene visualizzato un avviso che indica che l'opzione 3 non può essere usata per i gruppi di risorse del carico di lavoro successivi in tale carico di lavoro. È anche possibile creare un nuovo carico di lavoro e quindi creare un nuovo gruppo di risorse del carico di lavoro usando di nuovo l'opzione 3.

Aggiungere un gruppo di risorse all'enclave:

1. Aprire la pagina del portale di Azure per il carico di lavoro.
2. Selezionare Manage e quindi Resource Groups.
3. Seleziona Add a resource group.
4. Nella finestra laterale visualizzata selezionare Create new per specificare il nome del nuovo gruppo di risorse vuoto oppure selezionare l'elenco Resource Group a discesa per scegliere un gruppo di risorse esistente.
5. Selezionare OK e quindi Save.

In che modo un gruppo di risorse del carico di lavoro è diverso da altri gruppi di risorse Azure?

Un gruppo di risorse del carico di lavoro è un componente fondamentale della sicurezza e della conformità dell'enclave Azure, perché è qui che vengono create le risorse importanti. Poiché questi gruppi di risorse del carico di lavoro sono collegati a un carico di lavoro e il carico di lavoro è collegato a un enclave, Azure Enclave gestisce l'eliminazione dei gruppi di risorse gestiti del carico di lavoro.

Inoltre, i criteri vengono applicati ai gruppi di risorse del carico di lavoro. Analogamente al flusso dei criteri della community fino all'enclave, i criteri dell'enclave passano verso il basso fino alle risorse del carico di lavoro e ai gruppi di risorse del carico di lavoro. Quando si crea un nuovo gruppo di risorse del carico di lavoro, i ruoli vengono impostati a livello di enclave ed ereditati dalla sottoscrizione. Alcuni di questi criteri vengono ereditati dalla community ed è anche possibile creare criteri nell'enclave che passano verso i carichi di lavoro e i gruppi di risorse del carico di lavoro.

Organizzazione delle risorse nei gruppi di risorse del carico di lavoro

Se si vuole suddividere le risorse in due gruppi di risorse, è possibile scegliere una di queste opzioni:

• suddividere tali risorse tra due gruppi di risorse collegati a un carico di lavoro
• suddividere tali risorse tra due carichi di lavoro ognuno con uno o più gruppi di risorse

Eliminazione del carico di lavoro

Quando viene richiesta un'eliminazione del carico di lavoro, i gruppi di risorse del carico di lavoro vengono controllati per assicurarsi che siano vuoti. Se i gruppi di risorse del carico di lavoro contengono risorse, l'eliminazione del carico di lavoro richiesta ha esito negativo e visualizza un errore. Per eliminare il carico di lavoro e i gruppi di risorse del carico di lavoro, svuotare prima i gruppi di risorse del carico di lavoro. I gruppi di risorse del carico di lavoro vuoti consentono di evitare l'eliminazione accidentale di risorse importanti.

L'eliminazione di una risorsa collegata al carico di lavoro segue lo stesso comportamento. Ad esempio, se viene richiesta un'eliminazione della community ma tutti i gruppi di risorse del carico di lavoro non sono vuoti, l'operazione visualizza un errore. Svuoti i gruppi di risorse del carico di lavoro e riprovi.

Il gruppo di risorse gestite del carico di lavoro presenta le limitazioni seguenti:

• Non è possibile specificare un gruppo di risorse esistente per il gruppo di risorse gestito del carico di lavoro.
• Non è possibile specificare una sottoscrizione diversa per il gruppo di risorse gestite del carico di lavoro.
• Non è possibile modificare il nome del gruppo di risorse gestite dal carico di lavoro dopo la creazione del carico di lavoro.
• Non è possibile modificare o eliminare tag creati Azure di risorse gestite all'interno del gruppo di risorse gestite del carico di lavoro.

Uno scenario comune in cui si vuole modificare le risorse consiste nell'usare i tag. Azure Enclave consente di creare e modificare tag propagati alle risorse nel gruppo di risorse gestite del carico di lavoro. Potrebbe essere necessario creare o modificare tag personalizzati da assegnare ad esempio a una business unit o a un centro di costo. L'applicazione di tag può essere ottenuta anche creando Criteri di Azure con ambito impostato sul gruppo di risorse gestite del carico di lavoro.

Altre procedure consigliate per Azure

Quando si creano community, enclave e carichi di lavoro in Azure, è importante tenere presenti i principi di progettazione universali seguenti:

• Progettazione dell'architettura di rete in Azure
• Topologia di rete hub-spoke in Azure
• Collegamento privato di Azure in una rete hub-and-spoke
• Firewall di Azure - Well-Architected Framework
• Considerazioni sulla denominazione delle risorse Azure
• procedure consigliate e modelli di sicurezza di Microsoft Azure