Domande frequenti sulla zona di destinazione di Azure

Questo articolo risponde alle domande frequenti sull'architettura della zona di destinazione di Azure.

Per domande frequenti sull'implementazione dell'architettura della zona di destinazione di Azure, vedere Domande frequenti sull'implementazione su scala aziendale.

Cos'è l'acceleratore della zona di destinazione di Azure?

L'acceleratore della zona di destinazione di Azure è un'esperienza del portale di Azure che consente di distribuire un'implementazione guidata basata sull'architettura concettuale della zona di destinazione di Azure.

Quali sono gli acceleratori e le implementazioni consigliati per le zone di destinazione di Azure?

Microsoft sviluppa e gestisce attivamente gli acceleratori e le implementazioni della piattaforma e delle applicazioni in linea con i principi di progettazione e le linee guida per l'area di destinazione di Azure.

Per altre informazioni sulle zone di destinazione consigliate e sulle zone di destinazione dell'applicazione, vedere distribuire le zone di destinazione di Azure.

Per informazioni su come personalizzare la distribuzione delle zone di destinazione di Azure in base alle esigenze, vedere Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti

Cos'è l'architettura concettuale della zona di destinazione di Azure?

L'architettura concettuale della zona di destinazione di Azure rappresenta le decisioni relative a scalabilità e maturità. Si basa su lezioni apprese e feedback dai clienti che hanno adottato Azure come parte del proprio digital estate. Questa architettura concettuale consente all'organizzazione di definire una direzione per progettare e implementare una zona di destinazione.

Che cos'è una zona di destinazione in Azure nel contesto dell'architettura della zona di destinazione di Azure?

Dal punto di vista della zona di destinazione di Azure, le zone di destinazione sono singole sottoscrizioni di Azure.

Cosa significa governance basata su criteri e come funziona?

La governance basata su criteri è uno dei principi chiave di progettazione dell'architettura di livello aziendale.

La governance basata su criteri prevede l'uso di Criteri di Azure al fine di ridurre il tempo necessario per le attività operative comuni e ripetute nel tenant di Azure. Vengono usati molti effetti di Criteri di Azure, ad esempio Append, Deny, DeployIfNotExists e Modify, per impedire la mancata conformità limitando la creazione o l'aggiornamento delle risorse non conformi (come indicato dalla definizione dei criteri) oppure distribuendo le risorse o modificando le impostazioni di una richiesta di creazione o aggiornamento di una risorsa per renderle conformi. Alcuni effetti, come Audit, Disabled e AuditIfNotExists, non impediscono le azioni né le eseguono, ma controllano la mancanza di conformità e la segnalano.

Alcuni esempi di governance basata su criteri sono i seguenti:

• Effetto Deny. Impedisce la creazione o l'aggiornamento di subnet in modo che non siano associati gruppi di sicurezza di rete.

• DeployIfNotExists effetto: viene creata una nuova sottoscrizione (zona di destinazione) e inserita in un gruppo di gestione all'interno della distribuzione della zona di destinazione di Azure. Criteri di Azure garantisce che Microsoft Defender for Cloud (in precedenza noto come Centro sicurezza di Azure) sia abilitato nella sottoscrizione. Configura anche le impostazioni di diagnostica per il log attività al fine di inviare log all'area di lavoro Log Analytics nella sottoscrizione della gestione.

  La definizione dei criteri DeployIfNotExists consente di distribuire e configurare automaticamente le attività manuali e di codice quando viene creata una nuova sottoscrizione, eliminando la necessità di ripeterle.

Cosa accade se non è possibile o non è ancora possibile usare i criteri DeployIfNotExists (DINE) ?

È disponibile una pagina dedicata che illustra le varie fasi e le opzioni che è necessario "disabilitare" i criteri DINE o usare l'approccio a tre fasi per adottarli nel tempo all'interno dell'ambiente.

Per altre informazioni, vedere Adozione di misure di protezione basate su criteri

È consigliabile usare Criteri di Azure per distribuire i carichi di lavoro?

In breve, no. Usare Criteri di Azure per controllare, gestire e mantenere conformi i carichi di lavoro e le zone di destinazione. Criteri di Azure non è progettato per distribuire interi carichi di lavoro e altri strumenti. Usare il portale di Azure o l'infrastruttura come codice (modelli di ARM, Bicep, Terraform) per distribuire e gestire il carico di lavoro e ottenere l'autonomia necessaria.

Informazioni sulle zone di destinazione di Cloud Adoption Framework per Terraform (aztfmod)?

Le zone di destinazione di Cloud Adoption Framework (OSS) (note anche come aztfmod) sono un progetto guidato dalla community di proprietà e gestito all'esterno del team principale della zona di destinazione di Azure e dell'organizzazione GitHub di Azure. Se l'organizzazione sceglie di usare questo progetto OSS, è necessario considerare il supporto disponibile perché questo è basato sull'impegno della community tramite GitHub.

Cosa accade se sono già presenti risorse nelle zone di destinazione e successivamente si assegna una definizione di Criteri di Azure che le include nel proprio ambito?

Esaminare le sezioni della documentazione seguenti:

• Eseguire la transizione degli ambienti Azure esistenti all'architettura concettuale della zona di destinazione di Azure - sezione "Criteri"
• Guida introduttiva: Creare un'assegnazione di criteri per identificare risorse non conformi - Sezione "Identificare risorse non conformi

Come si gestiscono le zone di destinazione del carico di lavoro "sviluppo/test/produzione" nell'architettura della zona di destinazione di Azure?

Per altre informazioni, vedere Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure.

Perché viene chiesto di specificare le aree di Azure durante la distribuzione dell'acceleratore della zona di destinazione di Azure e per cosa vengono usate?

Quando si distribuisce l'architettura della zona di destinazione di Azure usando l'esperienza basata sul portale dell'acceleratore di zona di destinazione di Azure, selezionare un'area di Azure in cui eseguire la distribuzione. La prima scheda, Percorso di distribuzione, determina il percorso in cui vengono archiviati i dati di distribuzione. Per altre informazioni, Distribuzioni di tenant con modelli di ARM. Alcune parti di una zona di destinazione vengono distribuite a livello globale, ma i relativi metadati di distribuzione vengono rilevati in un archivio metadati a livello di area. I metadati relativi alla distribuzione vengono archiviati nell'area selezionata nella scheda Percorso di distribuzione.

Il selettore di area nella scheda Località di distribuzione viene usato anche per selezionare l'area di Azure in cui archiviare le risorse specifiche dell'area, ad esempio un'area di lavoro Log Analytics e un account di automazione, se necessario.

Se si distribuisce una topologia di rete nella scheda Topologia di rete e connettività , è necessario selezionare un'area di Azure in cui distribuire le risorse di rete. Questa area può essere diversa dall'area selezionata nella scheda Percorso di distribuzione.

Per altre informazioni sulle aree usate dalle risorse della zona di destinazione, vedere Aree della zona di destinazione.

Come si abilitano più aree di Azure quando si usa l'architettura della zona di destinazione di Azure?

Per informazioni su come aggiungere nuove aree a una zona di destinazione o come spostare le risorse della zona di destinazione in un'area diversa, vedere Aree di destinazione.

È consigliabile creare una nuova sottoscrizione di Azure ogni volta o riutilizzare le sottoscrizioni di Azure?

Che cos'è il riutilizzo della sottoscrizione?

Il riutilizzo della sottoscrizione è il processo di riemissione di una sottoscrizione esistente a un nuovo proprietario. Deve essere presente un processo per reimpostare la sottoscrizione a uno stato pulito noto e quindi riassegnato a un nuovo proprietario.

Perché è consigliabile riutilizzare le sottoscrizioni?

In generale, è consigliabile che i clienti adottino il principio di progettazione della democratizzazione delle sottoscrizioni. Tuttavia, esistono circostanze specifiche in cui il riutilizzo della sottoscrizione non è possibile o consigliato.

È consigliabile prendere in considerazione il riutilizzo della sottoscrizione se si soddisfa una delle circostanze seguenti:

• Si dispone di un Contratto Enterprise (EA) e si prevede di creare più di 5.000 sottoscrizioni in un singolo account proprietario dell'account EA (account di fatturazione), incluse le sottoscrizioni eliminate.
• Si dispone di una Contratto del cliente Microsoft (MCA) o Contratto Microsoft Partner Contratto Microsoft Partner e si prevede di avere più di 5.000 sottoscrizioni attive. Per altre informazioni sui limiti delle sottoscrizioni, vedere Account e ambiti di fatturazione nella portale di Azure.
• Sei un cliente con pagamento in base al consumo.
• Si usa una sponsorizzazione di Microsoft Azure.
• In genere si crea:
  1. Lab temporaneo o ambienti sandbox
  2. Ambienti demo per i modelli di verifica (POC) o i prodotti minimi validi (MVP), inclusi fornitori di software indipendenti (ISV) per l'accesso demo/versione di valutazione dei clienti
  3. Ambienti di training, ad esempio ambienti di apprendimento di MSPs/Trainer

Ricerca per categorie riutilizzare le sottoscrizioni?

Se si corrisponde a uno degli scenari o considerazioni precedenti, potrebbe essere necessario prendere in considerazione la possibilità di riutilizzare le sottoscrizioni non usate o rimosse esistenti e di riassegnarle a un nuovo proprietario e scopo.

Pulire la sottoscrizione precedente

È prima necessario pulire la sottoscrizione precedente per il riutilizzo. È necessario eseguire le azioni seguenti in una sottoscrizione prima che sia pronta per il riutilizzo:

• Rimuovere gruppi di risorse e risorse contenute.
• Rimuovere le assegnazioni di ruolo, incluse le assegnazioni di ruolo Privileged Identity Management (PIM) nell'ambito della sottoscrizione.
• Rimuovere definizioni di Controllo di accesso personalizzate basate su ruoli (RBAC) nell'ambito della sottoscrizione.
• Rimuovere definizioni di criteri, iniziative, assegnazioni ed esenzioni nell'ambito della sottoscrizione.
• Rimuovere le distribuzioni nell'ambito della sottoscrizione.
• Rimuovere i tag nell'ambito della sottoscrizione.
• Rimuovere tutti i blocchi delle risorse nell'ambito della sottoscrizione.
• Rimuovere tutti i budget di Gestione costi Microsoft nell'ambito della sottoscrizione.
• Reimpostare i piani di Microsoft Defender per il cloud ai livelli gratuiti, a meno che i requisiti dell'organizzazione non impostino questi log sui livelli a pagamento. Questi requisiti vengono in genere applicati tramite Criteri di Azure.
• Rimuovere i log attività della sottoscrizione (impostazioni di diagnostica) inoltrando ad aree di lavoro Log Analytics, Hub eventi, account di archiviazione o altre destinazioni supportate, a meno che i requisiti dell'organizzazione non impostino l'inoltro di questi log mentre è attiva una sottoscrizione.
• Rimuovere tutte le deleghe di Azure Lighthouse nell'ambito della sottoscrizione.
• Rimuovere tutte le risorse nascoste dalla sottoscrizione.

Riassegnare la sottoscrizione

È possibile riassegnare la sottoscrizione dopo aver pulito la sottoscrizione. Ecco alcune attività comuni che è possibile eseguire come parte del processo di riassegnazione:

• Aggiungere nuovi tag e impostarne i valori nella sottoscrizione.
• Aggiungere nuove assegnazioni di ruolo o privileged identity management (PIM) nell'ambito della sottoscrizione per i nuovi proprietari. In genere, queste assegnazioni sarebbero ai gruppi di Microsoft Entra anziché a singoli utenti.
• Inserire la sottoscrizione nel gruppo di gestione desiderato in base ai requisiti di governance.
• Creare nuovi budget di Gestione costi Microsoft e impostare avvisi per i nuovi proprietari quando vengono soddisfatte le soglie.
• Impostare Microsoft Defender per il cloud piani per i livelli desiderati. È consigliabile applicare questa impostazione tramite Criteri di Azure una volta inserita nel gruppo di gestione corretto.
• Configurare l'inoltro dei log attività della sottoscrizione (impostazioni di diagnostica) alle aree di lavoro Log Analytics, a Hub eventi, all'account di archiviazione o ad altre destinazioni supportate. È consigliabile applicare questa impostazione tramite Criteri di Azure una volta inserita nel gruppo di gestione corretto.

Che cos'è una zona di destinazione sovrana e come è correlata all'architettura della zona di destinazione di Azure?

La zona di destinazione sovrana è un componente di Microsoft Cloud for Sovranità destinato ai clienti del settore pubblico che necessitano di controlli avanzati di sovranità. Come versione personalizzata dell'architettura concettuale della zona di destinazione di Azure, la zona di destinazione sovrana allinea le funzionalità di Azure, ad esempio residenza dei servizi, chiavi gestite dal cliente, collegamento privato di Azure e confidential computing. Grazie a questo allineamento, la zona di destinazione sovrana crea un'architettura cloud in cui i dati e i carichi di lavoro offrono crittografia e protezione dalle minacce per impostazione predefinita.

Per altre informazioni sulla zona di destinazione sovrana, vedere Considerazioni sulla sovranità per le zone di destinazione di Azure.