Nozioni fondamentali sulla gestione delle risorse di Azure

È importante comprendere la struttura e i termini specifici delle risorse di Azure. L'immagine seguente mostra un esempio dei quattro livelli di ambito forniti da Azure:

Terminologia

Di seguito sono riportati alcuni dei termini con cui si ha familiarità:

Risorsa: elemento gestibile disponibile tramite Azure. Sono ad esempio risorse le macchine virtuali, gli account di archiviazione, le app Web, i database e le reti virtuali.

Gruppo di risorse: contenitore che contiene risorse correlate per una soluzione di Azure, ad esempio una raccolta di macchine virtuali, reti virtuali associate e servizi di bilanciamento del carico che richiedono la gestione da parte di team specifici. Il gruppo di risorse include le risorse che si desidera gestire come gruppo. Si decide quali risorse appartengono a un gruppo di risorse in base alle esigenze dell'organizzazione. I gruppi di risorse possono essere usati anche per semplificare la gestione del ciclo di vita eliminando tutte le risorse che hanno la stessa durata contemporaneamente. Questo approccio offre anche vantaggi per la sicurezza senza frammenti che potrebbero essere sfruttati.

Sottoscrizione : dal punto di vista della gerarchia organizzativa, una sottoscrizione è un contenitore di fatturazione e gestione di risorse e gruppi di risorse. Una sottoscrizione di Azure ha una relazione di trust con Microsoft Entra ID. Una sottoscrizione considera attendibile Microsoft Entra ID per autenticare utenti, servizi e dispositivi.

Nota

Una sottoscrizione può considerare attendibile un solo tenant di Microsoft Entra. Tuttavia, ogni tenant può considerare attendibili più sottoscrizioni e sottoscrizioni possono essere spostate tra tenant.

- I gruppi di gestione di Azure offrono un metodo gerarchico per applicare criteri e conformità in ambiti diversi sopra le sottoscrizioni. Può trovarsi nel gruppo di gestione radice del tenant (ambito più alto) o a livelli inferiori nella gerarchia. Le sottoscrizioni sono organizzate in contenitori chiamati “gruppi di gestione” a cui vengono applicate le condizioni di governance. Tutte le sottoscrizioni all'interno di un gruppo di gestione ereditano automaticamente le condizioni applicate al gruppo di gestione. Si noti che le definizioni dei criteri possono essere applicate a un gruppo di gestione o a una sottoscrizione.

Provider di risorse: servizio che fornisce risorse di Azure. Ad esempio, un provider di risorse comune è Microsoft. Calcolo, che fornisce la risorsa macchina virtuale. Microsoft. L'archiviazione è un altro provider di risorse comune.

Modello di Resource Manager : file JSON (JavaScript Object Notation) che definisce una o più risorse da distribuire in un gruppo di risorse, una sottoscrizione, un tenant o un gruppo di gestione. Il modello può essere usato per distribuire le risorse in modo coerente e ripetuto. Vedere Panoramica della distribuzione di modelli. Inoltre, il linguaggio Bicep può essere usato invece di JSON.

Modello di Gestione risorse di Azure

Ogni sottoscrizione di Azure è associata ai controlli usati da Azure Resource Manager. Resource Manager è il servizio di distribuzione e gestione per Azure, ha una relazione di trust con Microsoft Entra ID per la gestione delle identità per le organizzazioni e l'account Microsoft (MSA) per utenti singoli. Resource Manager offre un livello di gestione che consente di creare, aggiornare ed eliminare risorse nella sottoscrizione di Azure. Si usano funzionalità di gestione come il controllo di accesso, i blocchi e i tag, per proteggere e organizzare le risorse dopo la distribuzione.

Nota

Prima di ARM, esiste un altro modello di distribuzione denominato Azure Service Manager (ASM) o "classico". Per altre informazioni, vedere Distribuzione classica di Azure Resource Manager. La gestione degli ambienti con il modello ASM non rientra nell'ambito di questo contenuto.

Azure Resource Manager è il servizio front-end che ospita le API REST usate da PowerShell, il portale di Azure o altri client per gestire le risorse. Quando un client effettua una richiesta per gestire una risorsa specifica, Resource Manager invia la richiesta al provider di risorse per completare la richiesta. Ad esempio, se un client effettua una richiesta per gestire una risorsa macchina virtuale, Resource Manager invia la richiesta a Microsoft. Provider di risorse di calcolo. Resource Manager richiede al client di specificare un identificatore sia per la sottoscrizione che per il gruppo di risorse per gestire la risorsa macchina virtuale.

Prima che qualsiasi richiesta di gestione delle risorse possa essere eseguita da Resource Manager, viene controllato un set di controlli.

• Controllo utente valido: l'utente che richiede di gestire la risorsa deve avere un account nel tenant di Microsoft Entra associato alla sottoscrizione della risorsa gestita.

• Controllo delle autorizzazioni utente: le autorizzazioni vengono assegnate agli utenti usando il controllo degli accessi in base al ruolo. Un ruolo di controllo degli accessi in base al ruolo specifica un insieme di autorizzazioni che un utente può avere per una risorsa specifica. Il controllo degli accessi in base al ruolo consente di gestire chi può accedere alle risorse di Azure, le operazioni che possono eseguire con tali risorse e le aree a cui hanno accesso.

• I criteri di Azure controllano - i criteri di Azure specificano le operazioni consentite o negate in modo esplicito per una risorsa specifica. Ad esempio, un criterio può specificare che gli utenti sono consentiti (o non consentiti) per distribuire un tipo specifico di macchina virtuale.

Il diagramma seguente riepiloga il modello di risorse appena descritto.

Azure Lighthouse di Azure Lighthouse - consente la gestione delle risorse tra tenant. Le organizzazioni possono delegare i ruoli a livello di sottoscrizione o gruppo di risorse alle identità in un altro tenant.

Le sottoscrizioni che abilitano la gestione delle risorse delegate con Azure Lighthouse hanno attributi che indicano gli ID tenant che possono gestire sottoscrizioni o gruppi di risorse e il mapping tra il ruolo controllo degli accessi in base al ruolo predefinito nel tenant delle risorse alle identità nel tenant del provider di servizi. In fase di esecuzione, Azure Resource Manager utilizzerà questi attributi per autorizzare i token provenienti dal tenant del provider di servizi.

Vale la pena notare che Azure Lighthouse stesso è modellato come provider di risorse di Azure, il che significa che gli aspetti della delega in un tenant possono essere destinati tramite Criteri di Azure.

Microsoft 365 Lighthouse Microsoft 365 Lighthouse - è un portale di amministrazione che consente ai provider di servizi gestiti di proteggere e gestire dispositivi, dati e utenti su larga scala per i clienti di piccole e medie dimensioni che usano Microsoft 365 Business Premium, Microsoft 365 E3 o Windows 365 Business.

Gestione delle risorse di Azure con Microsoft Entra ID

Ora che si ha una migliore comprensione del modello di gestione delle risorse in Azure, si esamineranno brevemente alcune delle funzionalità di Microsoft Entra ID che possono fornire la gestione delle identità e degli accessi per le risorse di Azure.

Fatturazione

La fatturazione è importante per la gestione delle risorse perché alcuni ruoli di fatturazione interagiscono con o possono gestire le risorse. La fatturazione funziona in modo diverso a seconda del tipo di contratto con Microsoft.

Contratto Enterprise di Azure

I clienti di Azure Contratto Enterprise (Azure EA) vengono eseguiti nel portale EA di Azure al momento dell'esecuzione del contratto commerciale con Microsoft. Al momento dell'onboarding, un'identità è associata a un ruolo di fatturazione dell'amministratore dell'organizzazione "radice". Il portale fornisce una gerarchia di funzioni di gestione:

• I reparti consentono di segmentare i costi in raggruppamenti logici e di impostare un budget o una quota a livello di reparto.

• Gli account vengono usati per segmentare ulteriormente i reparti. È possibile usare gli account per gestire le sottoscrizioni e accedere ai report. Il portale EA può autorizzare gli account Microsoft (MSA) o Microsoft Entra (identificati nel portale come "Account aziendali o dell'istituto di istruzione"). Le identità con il ruolo "Proprietario account" nel portale EA possono creare sottoscrizioni di Azure.

Fatturazione aziendale e tenant di Microsoft Entra

Quando un proprietario dell'account crea una sottoscrizione di Azure all'interno di un contratto Enterprise, la gestione delle identità e degli accessi della sottoscrizione viene configurata come segue:

• La sottoscrizione di Azure è associata allo stesso tenant di Microsoft Entra del proprietario dell'account.

• Al proprietario dell'account che ha creato la sottoscrizione verranno assegnati i ruoli Amministratore del servizio e Amministratore account. Il portale EA di Azure assegna ruoli di Azure Service Manager (ASM) o "classici" per gestire le sottoscrizioni. Per altre informazioni, vedere Distribuzione classica di Azure Resource Manager.

Un contratto Enterprise Può essere configurato per supportare più tenant impostando il tipo di autenticazione "Account aziendale o dell'istituto di istruzione tra tenant" nel portale EA di Azure. Date le informazioni precedenti, le organizzazioni possono impostare più account per ogni tenant e più sottoscrizioni per ogni account, come illustrato nel diagramma seguente.

È importante notare che la configurazione predefinita descritta in precedenza concede i privilegi di proprietario dell'account EA di Azure per gestire le risorse in tutte le sottoscrizioni create. Per le sottoscrizioni che contengono carichi di lavoro di produzione, è consigliabile separare la fatturazione e la gestione delle risorse modificando l'amministratore del servizio della sottoscrizione subito dopo la creazione.

Per separare ulteriormente e impedire al proprietario dell'account di ottenere nuovamente l'accesso dell'amministratore del servizio alla sottoscrizione, il tenant della sottoscrizione può essere modificato dopo la creazione. Se il proprietario dell'account non ha un oggetto utente nel tenant di Microsoft Entra, la sottoscrizione viene spostata in , non può recuperare il ruolo di proprietario del servizio.

Per altre informazioni, visitare i ruoli di Azure, i ruoli di Microsoft Entra e i ruoli di amministratore della sottoscrizione classica.

Contratto del cliente Microsoft

I clienti iscritti a un Contratto del cliente Microsoft (MCA) hanno un sistema di gestione della fatturazione diverso con i propri ruoli.

Un account di fatturazione per il Contratto del cliente Microsoft contiene uno o più profili di fatturazione che consentono di gestire le fatture e i metodi di pagamento. Ogni profilo di fatturazione contiene una o più sezioni della fattura per organizzare i costi nella fattura del profilo di fatturazione.

In un Contratto del cliente Microsoft, i ruoli di fatturazione provengono da un singolo tenant di Microsoft Entra. Per effettuare il provisioning delle sottoscrizioni per più tenant, le sottoscrizioni devono essere inizialmente create nello stesso tenant di Microsoft Entra dell'account del cliente microsoft e quindi modificate. Nel diagramma seguente le sottoscrizioni per l'ambiente di pre-produzione IT aziendale sono state spostate nel tenant ContosoSandbox dopo la creazione.

Controllo degli accessi in base al ruolo e assegnazioni di ruolo in Azure

Nella sezione Nozioni fondamentali su Microsoft Entra si è appreso che il controllo degli accessi in base al ruolo di Azure è il sistema di autorizzazione che fornisce una gestione degli accessi con granularità fine alle risorse di Azure e include molti ruoli predefiniti. È possibile creare ruoli personalizzati e assegnare ruoli in ambiti diversi. Le autorizzazioni vengono applicate assegnando ruoli controllo degli accessi in base al ruolo agli oggetti che richiedono l'accesso alle risorse di Azure.

I ruoli di Microsoft Entra operano su concetti come il controllo degli accessi in base al ruolo di Azure. La differenza tra questi due sistemi di controllo degli accessi in base al ruolo è che il controllo degli accessi in base al ruolo di Azure usa Gestione risorse di Azure per controllare l'accesso alle risorse di Azure, ad esempio macchine virtuali o archiviazione, e i ruoli di Microsoft Entra controllano l'accesso a Microsoft Entra ID, applicazioni e servizi Microsoft come Office 365.

Entrambi i ruoli di Microsoft Entra e i ruoli controllo degli accessi in base al ruolo di Azure si integrano con Microsoft Entra Privileged Identity Management per abilitare criteri di attivazione JIT, ad esempio flusso di lavoro di approvazione e MFA.

Controllo degli accessi in base al ruolo e assegnazioni di ruolo in Azure

Il controllo degli accessi in base all'attributo è un sistema di autorizzazione che definisce l'accesso in base agli attributi associati a entità di sicurezza, risorse e ambiente. Con il controllo degli accessi in base al ruolo è possibile concedere a un'entità di sicurezza l'accesso a una risorsa in base agli attributi. Il controllo degli accessi in base al ruolo di Azure fa riferimento all'implementazione del controllo degli accessi in base al ruolo per Azure.

Il controllo degli accessi in base al ruolo di Azure si basa sul controllo degli accessi in base al ruolo di Azure aggiungendo condizioni di assegnazione dei ruoli in base agli attributi nel contesto di azioni specifiche. Una condizione di assegnazione di ruolo è un controllo aggiuntivo che è possibile aggiungere facoltativamente all'assegnazione di ruolo per fornire un controllo di accesso più granulare. Una condizione filtra le autorizzazioni concesse come parte della definizione del ruolo e dell'assegnazione di ruolo. Ad esempio, è possibile aggiungere una condizione che richiede che un oggetto abbia un tag specifico per leggere l'oggetto. Non è possibile negare esplicitamente l'accesso a risorse specifiche usando le condizioni.

Accesso condizionale

L'accesso condizionale Microsoft Entra può essere usato per gestire l'accesso agli endpoint di gestione di Azure. I criteri di accesso condizionale possono essere applicati all'app cloud per le API di Gestione dei servizi di Windows Azure per proteggere gli endpoint di gestione delle risorse di Azure, ad esempio:

• Provider di Azure Resource Manager (servizi)

• API di Azure Resource Manager

• Azure PowerShell

• Interfaccia della riga di comando di Azure

• Azure portal

Ad esempio, un amministratore può configurare un criterio di accesso condizionale, che consente a un utente di accedere al portale di Azure solo da posizioni approvate e richiede anche l'autenticazione a più fattori (MFA) o un dispositivo aggiunto al dominio Microsoft Entra ibrido.

Azure Managed Identities

Una difficoltà comune durante la creazione di applicazioni cloud è rappresentata dalla gestione delle credenziali presenti nel codice per l'autenticazione ai servizi cloud. Garantire la sicurezza delle credenziali è fondamentale. Preferibilmente, le credenziali non vengono mai visualizzate nelle workstation per sviluppatori e non vengono archiviate nel controllo del codice sorgente. Le identità gestite per le risorse di Azure offrono ai servizi di Azure un'identità gestita automaticamente in Microsoft Entra ID. È possibile usare l'identità per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra senza credenziali nel codice.

Sono disponibili due tipi di identità gestite:

• Un'identità gestita assegnata dal sistema è abilitata direttamente in una risorsa di Azure. Quando la risorsa è abilitata, Azure crea un'identità per la risorsa nel tenant Microsoft Entra attendibile della sottoscrizione associata. Dopo aver creato l'identità, le credenziali vengono sottoposte a provisioning nella risorsa. Il ciclo di vita di un'identità assegnata dal sistema è direttamente associato alla risorsa di Azure. Se la risorsa viene eliminata, Azure pulisce automaticamente le credenziali e l'identità in Microsoft Entra ID.

• Un'identità gestita assegnata dall'utente viene creata come risorsa di Azure autonoma. Azure crea un'identità nel tenant di Microsoft Entra considerata attendibile dalla sottoscrizione a cui è associata la risorsa. Dopo aver creato l'identità, l'identità può essere assegnata a una o più risorse di Azure. Il ciclo di vita di un'identità assegnata dall'utente viene gestito separatamente dal ciclo di vita delle risorse di Azure a cui è assegnato.

Internamente, le identità gestite sono entità servizio di un tipo speciale, da usare solo da risorse di Azure specifiche. Quando l'identità gestita viene eliminata, l'entità servizio corrispondente viene rimossa automaticamente. Nessuna autorizzazione delle autorizzazioni dell'API Graph può essere eseguita solo da PowerShell, quindi non tutte le funzionalità dell'identità gestita sono accessibili tramite l'interfaccia utente del portale.

Servizi di dominio Microsoft Entra

Microsoft Entra Domain Services fornisce un dominio gestito per facilitare l'autenticazione per i carichi di lavoro di Azure tramite protocolli legacy. I server supportati vengono spostati da una foresta di Active Directory Domain Services locale e aggiunti a un dominio gestito di Microsoft Entra Domain Services e continuano a usare protocolli legacy per l'autenticazione (ad esempio, l'autenticazione Kerberos).

Directory di Azure AD B2C e Azure

Un tenant di Azure AD B2C è collegato a una sottoscrizione di Azure per scopi di fatturazione e comunicazione. I tenant di Azure AD B2C hanno una struttura di ruoli autonoma nella directory, indipendente dai ruoli con privilegi controllo degli accessi in base al ruolo di Azure della sottoscrizione di Azure.

Quando viene inizialmente effettuato il provisioning del tenant di Azure AD B2C, l'utente che crea il tenant B2C deve disporre delle autorizzazioni di collaboratore o proprietario nella sottoscrizione. Al momento della creazione, tale utente diventa il primo amministratore globale del tenant di Azure AD B2C e successivamente può creare altri account e assegnarli ai ruoli della directory.

È importante notare che i proprietari e i collaboratori della sottoscrizione di Microsoft Entra collegata possono rimuovere il collegamento tra la sottoscrizione e la directory, che influirà sulla fatturazione in corso dell'utilizzo di Azure AD B2C.

Considerazioni sulle identità per le soluzioni IaaS in Azure

Questo scenario illustra i requisiti di isolamento delle identità che le organizzazioni hanno per i carichi di lavoro IaaS (Infrastructure-as-a-Service).

Sono disponibili tre opzioni chiave relative alla gestione dell'isolamento dei carichi di lavoro IaaS:

• Macchine virtuali aggiunte a servizi di Dominio di Active Directory autonomi

• Macchine virtuali aggiunte a Microsoft Entra Domain Services

• Accedere alle macchine virtuali in Azure usando l'autenticazione di Microsoft Entra

Un concetto chiave da affrontare con le prime due opzioni è che esistono due aree di autenticazione di identità coinvolte in questi scenari.

• Quando si accede a una macchina virtuale Windows Server di Azure tramite RDP (Remote Desktop Protocol), si accede in genere al server usando le credenziali di dominio, che esegue un'autenticazione Kerberos su un controller di dominio Active Directory Domain Services locale o Microsoft Entra Domain Services. In alternativa, se il server non è aggiunto a un dominio, è possibile usare un account locale per accedere alle macchine virtuali.

• Quando si accede al portale di Azure per creare o gestire una macchina virtuale, si esegue l'autenticazione con l'ID Microsoft Entra (potenzialmente usando le stesse credenziali se sono stati sincronizzati gli account corretti) e questo potrebbe comportare un'autenticazione nei controller di dominio se si usa Active Directory Federation Services (AD FS) o l'autenticazione pass-through.

Macchine virtuali aggiunte a servizi Dominio di Active Directory autonomi

Servizi di dominio Active Directory è il servizio directory basato su Windows Server che le organizzazioni hanno ampiamente adottato per i servizi di gestione delle identità locali. È possibile distribuire Servizi di dominio Active Directory quando esiste un requisito per distribuire carichi di lavoro IaaS in Azure che richiedono l'isolamento delle identità dagli amministratori e dagli utenti di Servizi di dominio Active Directory in un'altra foresta.

In questo scenario è necessario tenere presenti le considerazioni seguenti:

Controller di dominio di Active Directory Domain Services: è necessario distribuire almeno due controller di dominio Active Directory Domain Services per garantire che i servizi di autenticazione siano a disponibilità elevata e prestazioni elevate. Per altre informazioni, vedere Progettazione e pianificazione di Active Directory Domain Services.

Progettazione e pianificazione di Active Directory Domain Services: è necessario creare una nuova foresta di Active Directory Domain Services con i servizi seguenti configurati correttamente:

• Servizi DNS (Domain Name Services) di Active Directory Domain Services: il DNS di Active Directory Domain Services deve essere configurato per le zone pertinenti all'interno di Servizi di dominio Active Directory per garantire che la risoluzione dei nomi funzioni correttamente per server e applicazioni.

• Siti e servizi di Active Directory Domain Services: questi servizi devono essere configurati per garantire che le applicazioni abbiano bassa latenza e accesso efficiente ai controller di dominio. Le reti virtuali, le subnet e le posizioni del data center pertinenti in cui si trovano i server devono essere configurate nei siti e nei servizi.

• AD DS FSMOs : i ruoli FSMO (Flexible Single Master Operation) necessari devono essere esaminati e assegnati ai controller di dominio di Active Directory Domain Services appropriati.

• Aggiunta a un dominio di Active Directory Domain Services : tutti i server (esclusi i "jumpbox") che richiedono Servizi di dominio Active Directory per l'autenticazione, la configurazione e la gestione devono essere aggiunti alla foresta isolata.

• Criteri di gruppo di Active Directory Domain Services: gli oggetti Criteri di gruppo di Active Directory Domain Services devono essere configurati per garantire che la configurazione soddisfi i requisiti di sicurezza e che la configurazione sia standardizzata tra le foreste e i computer aggiunti a un dominio.

• Unità organizzative di Active Directory Domain Services : le unità organizzative di Active Directory Domain Services devono essere definite per garantire il raggruppamento delle risorse di Active Directory Domain Services in silo di configurazione e gestione logica ai fini dell'amministrazione e dell'applicazione della configurazione.

• Controllo degli accessi in base al ruolo: il controllo degli accessi in base al ruolo deve essere definito per l'amministrazione e l'accesso alle risorse aggiunte a questa foresta. Valuta gli ambiti seguenti:

  • Gruppi di Active Directory Domain Services: i gruppi devono essere creati per applicare le autorizzazioni appropriate per gli utenti alle risorse di Active Directory Domain Services.

  • Account di amministrazione: come indicato all'inizio di questa sezione sono necessari due account di amministrazione per gestire questa soluzione.

    • Un account di amministrazione di Active Directory Domain Services con l'accesso con privilegi minimi necessari per eseguire l'amministrazione necessaria in Servizi di dominio Active Directory e nei server aggiunti a un dominio.

    • Un account di amministrazione di Microsoft Entra per portale di Azure l'accesso per connettersi, gestire e configurare macchine virtuali, reti virtuali, gruppi di sicurezza di rete e altre risorse di Azure necessarie.

  • Account utente di Active Directory Domain Services: è necessario effettuare il provisioning e aggiungere gli account utente pertinenti ai gruppi corretti per consentire l'accesso utente alle applicazioni ospitate da questa soluzione.

Reti virtuali (VNet) - Linee guida per la configurazione

• Indirizzo IP del controller di dominio di Active Directory Domain Services: i controller di dominio non devono essere configurati con indirizzi IP statici all'interno del sistema operativo. Gli indirizzi IP devono essere riservati nella rete virtuale di Azure per assicurarsi che rimangano sempre uguali e che il controller di dominio sia configurato per l'uso di DHCP.

• Server DNS di rete virtuale: i server DNS devono essere configurati nelle reti virtuali che fanno parte di questa soluzione isolata per puntare ai controller di dominio. Questa operazione è necessaria per garantire che le applicazioni e i server possano risolvere i servizi di Active Directory Domain Services necessari o altri servizi aggiunti alla foresta di Active Directory Domain Services.

• Gruppi di sicurezza di rete : i controller di dominio devono trovarsi nella propria rete virtuale o subnet con gruppi di sicurezza di rete definiti per consentire l'accesso solo ai controller di dominio dai server necessari (ad esempio, computer aggiunti a un dominio o jumpbox). I jumpbox devono essere aggiunti a un gruppo di sicurezza delle applicazioni (ASG) per semplificare la creazione e l'amministrazione del gruppo di sicurezza di rete.

Sfide: l'elenco seguente evidenzia le sfide principali con l'uso di questa opzione per l'isolamento delle identità:

• Un'altra foresta di Active Directory Domain Services da amministrare, gestire e monitorare con conseguente maggiore lavoro da eseguire per il team IT.

• È possibile che sia necessaria un'ulteriore infrastruttura per la gestione delle patch e delle distribuzioni software. Le organizzazioni devono prendere in considerazione la distribuzione di Gestione aggiornamenti di Azure, Criteri di gruppo o System Center Configuration Manager (SCCM) per gestire questi server.

• Credenziali aggiuntive per gli utenti da ricordare e usare per accedere alle risorse.

Importante

Per questo modello isolato si presuppone che non vi sia connettività da o verso i controller di dominio dalla rete aziendale del cliente e che non ci siano trust configurati con altre foreste. È necessario creare un jumpbox o un server di gestione per consentire la gestione e l'amministrazione dei controller di dominio di Active Directory Domain Services.

Macchine virtuali aggiunte a Microsoft Entra Domain Services

Quando esiste un requisito per distribuire carichi di lavoro IaaS in Azure che richiedono l'isolamento delle identità dagli amministratori e dagli utenti di Servizi di dominio Active Directory in un'altra foresta, è possibile distribuire un dominio gestito di Microsoft Entra Domain Services. Microsoft Entra Domain Services è un servizio che fornisce un dominio gestito per facilitare l'autenticazione per i carichi di lavoro di Azure tramite protocolli legacy. In questo modo si ottiene un dominio isolato senza le complessità tecniche di creazione e gestione di Servizi di dominio Active Directory. È necessario prendere in considerazione le considerazioni seguenti.

Dominio gestito di Microsoft Entra Domain Services: è possibile distribuire un solo dominio gestito di Microsoft Entra Domain Services per ogni tenant di Microsoft Entra e associato a una singola rete virtuale. È consigliabile che questa rete virtuale formi l'"hub" per l'autenticazione di Microsoft Entra Domain Services. Da questo hub è possibile creare "spoke" e collegare per consentire l'autenticazione legacy per server e applicazioni. Gli spoke sono reti virtuali aggiuntive in cui si trovano i server aggiunti a Microsoft Entra Domain Services e sono collegati all'hub usando gateway di rete di Azure o peering reti virtuali.

Percorso di dominio gestito: una posizione deve essere impostata quando si distribuisce un dominio gestito di Microsoft Entra Domain Services. La posizione è un'area fisica (data center) in cui viene distribuito il dominio gestito. È consigliabile:

• Si consideri una posizione geograficamente chiusa ai server e alle applicazioni che richiedono servizi di dominio Microsoft Entra.

• Prendere in considerazione le aree che forniscono funzionalità di zone di disponibilità per i requisiti di disponibilità elevata. Per altre informazioni, vedere Aree e zone di disponibilità in Azure.

Provisioning di oggetti: Microsoft Entra Domain Services sincronizza le identità dall'ID Microsoft Entra associato alla sottoscrizione in cui viene distribuito Microsoft Entra Domain Services. Vale anche la pena notare che se l'ID Microsoft Entra associato ha la sincronizzazione configurata con Microsoft Entra Connect (scenario foresta utente), il ciclo di vita di queste identità può essere riflesso anche in Microsoft Entra Domain Services. Questo servizio dispone di due modalità che possono essere usate per il provisioning di oggetti utente e gruppo da Microsoft Entra ID.

• Tutto: tutti gli utenti e i gruppi vengono sincronizzati da Microsoft Entra ID in Microsoft Entra Domain Services.

• Ambito: solo gli utenti nell'ambito di un gruppo vengono sincronizzati da Microsoft Entra ID in Microsoft Entra Domain Services.

Quando si distribuisce Microsoft Entra Domain Services per la prima volta, viene configurata una sincronizzazione unidirezionale automatica per replicare gli oggetti dall'ID Microsoft Entra. Questa sincronizzazione unidirezionale continua a essere eseguita in background per mantenere aggiornato il dominio gestito di Microsoft Entra Domain Services con eventuali modifiche da Microsoft Entra ID. Non viene eseguita alcuna sincronizzazione da Microsoft Entra Domain Services a Microsoft Entra ID. Per altre informazioni, vedere Modalità di sincronizzazione di oggetti e credenziali in un dominio gestito di Microsoft Entra Domain Services.

Vale la pena notare che se è necessario modificare il tipo di sincronizzazione da All a Scoped (o viceversa), il dominio gestito di Microsoft Entra Domain Services dovrà essere eliminato, ricreato e configurato. Inoltre, le organizzazioni devono considerare l'uso del provisioning "con ambito" per ridurre le identità solo a quelle che necessitano dell'accesso alle risorse di Microsoft Entra Domain Services come procedura consigliata.

Oggetti Criteri di gruppo : per configurare l'oggetto Criteri di gruppo in un dominio gestito di Microsoft Entra Domain Services, è necessario utilizzare gli strumenti di Gestione Criteri di gruppo in un server aggiunto al dominio gestito di Microsoft Entra Domain Services. Per altre informazioni, vedere Amministrare Criteri di gruppo in un dominio gestito di Microsoft Entra Domain Services.

LDAP sicuro: Microsoft Entra Domain Services fornisce un servizio LDAP sicuro che può essere usato dalle applicazioni che lo richiedono. Questa impostazione è disabilitata per impostazione predefinita e per abilitare ldap sicuro è necessario caricare un certificato, inoltre, il gruppo di sicurezza di rete che protegge la rete virtuale in cui è distribuito Microsoft Entra Domain Services deve consentire la connettività della porta 636 ai domini gestiti di Microsoft Entra Domain Services. Per altre informazioni, vedere Configurare LDAP sicuro per un dominio gestito di Microsoft Entra Domain Services.

Amministrazione : per eseguire compiti di amministrazione in Servizi di dominio Microsoft Entra (ad esempio, aggiungere computer o modificare oggetti Criteri di gruppo), l'account usato per questa attività deve far parte del gruppo Microsoft Entra DC Administrators. Gli account membri di questo gruppo non possono accedere direttamente ai controller di dominio per eseguire attività di gestione. Si crea invece una macchina virtuale di gestione aggiunta al dominio gestito di Microsoft Entra Domain Services, quindi si installano i normali strumenti di gestione di Active Directory Domain Services. Per altre informazioni, vedere Concetti di gestione per account utente, password e amministrazione in Servizi di dominio Microsoft Entra.

Hash delle password: per il funzionamento dell'autenticazione con Microsoft Entra Domain Services, gli hash delle password per tutti gli utenti devono essere in un formato adatto per l'autenticazione NT LAN Manager (NTLM) e Kerberos. Per garantire che l'autenticazione con Microsoft Entra Domain Services funzioni come previsto, è necessario eseguire i prerequisiti seguenti.

• Utenti sincronizzati con Microsoft Entra Connect (da Active Directory Domain Services): gli hash delle password legacy devono essere sincronizzati da Active Directory Domain Services locale a Microsoft Entra ID.

• Utenti creati in Microsoft Entra ID : è necessario reimpostare la password per generare gli hash corretti per l'utilizzo con Microsoft Entra Domain Services. Per altre informazioni, vedere Abilitare la sincronizzazione degli hash delle password.

Rete: Microsoft Entra Domain Services viene distribuito in una rete virtuale di Azure, pertanto è necessario tenere presenti considerazioni per garantire che i server e le applicazioni siano protetti e possano accedere correttamente al dominio gestito. Per maggiori informazioni, consultare la sezione Considerazioni sulla progettazione della rete virtuale e opzioni di configurazione per Servizi di dominio Microsoft Entra.

• Microsoft Entra Domain Services deve essere distribuito nella propria subnet: non usare una subnet esistente o una subnet del gateway.

• Un gruppo di sicurezza di rete (NSG) viene creato durante la distribuzione di un dominio gestito di Microsoft Entra Domain Services. Questo gruppo di sicurezza di rete contiene le regole necessarie per la comunicazione corretta del servizio. Non creare o usare un gruppo di sicurezza di rete esistente con regole personalizzate.

• Microsoft Entra Domain Services richiede 3-5 indirizzi IP: assicurarsi che l'intervallo di indirizzi IP della subnet possa fornire questo numero di indirizzi. La limitazione degli indirizzi IP disponibili può impedire a Microsoft Entra Domain Services di gestire due controller di dominio.

• Server DNS di rete virtuale: come descritto in precedenza sul modello "hub-spoke", è importante che il DNS sia configurato correttamente nelle reti virtuali per assicurarsi che i server aggiunti al dominio gestito di Microsoft Entra Domain Services dispongano delle impostazioni DNS corrette per risolvere il dominio gestito di Microsoft Entra Domain Services. Ogni rete virtuale ha una voce del server DNS passata ai server quando ottengono un indirizzo IP e queste voci DNS devono essere gli indirizzi IP del dominio gestito di Microsoft Entra Domain Services. Per altre informazioni, vedere Aggiornare le impostazioni DNS per la rete virtuale di Azure.

Sfide : l'elenco seguente evidenzia le sfide principali con l'uso di questa opzione per l'isolamento delle identità.

• Alcune configurazioni di Microsoft Entra Domain Services possono essere gestite solo da un server aggiunto a Microsoft Entra Domain Services.

• È possibile distribuire un solo dominio gestito di Microsoft Entra Domain Services per ogni tenant di Microsoft Entra. Come descritto in questa sezione, è consigliabile fornire l'autenticazione di Servizi di dominio Microsoft Entra ai servizi in altre reti virtuali.

• Un'ulteriore infrastruttura potrebbe essere necessaria per la gestione delle patch e delle distribuzioni software. Le organizzazioni devono prendere in considerazione la distribuzione di Gestione aggiornamenti di Azure, Criteri di gruppo o System Center Configuration Manager (SCCM) per gestire questi server.

Per questo modello isolato, si presuppone che non vi sia connettività alla rete virtuale che ospita il dominio gestito di Microsoft Entra Domain Services dalla rete aziendale del cliente e che non ci siano trust configurati con altre foreste. È necessario creare un jumpbox o un server di gestione per consentire la gestione e l'amministrazione di Microsoft Entra Domain Services.

Accedere alle macchine virtuali in Azure usando l'autenticazione di Microsoft Entra

Quando esiste un requisito per distribuire i carichi di lavoro IaaS in Azure che richiedono l'isolamento delle identità, l'opzione finale consiste nell'usare l'ID Microsoft Entra per l'accesso ai server in questo scenario. In questo modo è possibile rendere Microsoft Entra ID l'area di autenticazione per scopi di autenticazione e isolamento delle identità effettuando il provisioning dei server nella sottoscrizione pertinente, collegata al tenant Microsoft Entra richiesto. È necessario prendere in considerazione le considerazioni seguenti.

Sistemi operativi supportati: l'accesso alle macchine virtuali in Azure con l'autenticazione Microsoft Entra è attualmente supportato in Windows e Linux. Per altre informazioni sui sistemi operativi supportati, vedere la documentazione per Windows e Linux.

Credenziali: uno dei principali vantaggi dell'accesso alle macchine virtuali in Azure con l'autenticazione Microsoft Entra è la possibilità di usare le stesse credenziali federate o gestite di Microsoft Entra usate normalmente per l'accesso ai servizi Microsoft Entra per l'accesso alla macchina virtuale.

Nota

Il tenant di Microsoft Entra usato per l'accesso in questo scenario è il tenant di Microsoft Entra associato alla sottoscrizione in cui è stato effettuato il provisioning della macchina virtuale. Questo tenant di Microsoft Entra può essere un tenant con identità sincronizzate da Active Directory Domain Services locale. Le organizzazioni devono fare una scelta informata che sia allineata alle entità di isolamento quando si sceglie quale sottoscrizione e tenant Di Microsoft Entra vogliono usare per l'accesso a questi server.

Requisiti di rete: queste macchine virtuali dovranno accedere a Microsoft Entra ID per l'autenticazione, quindi è necessario assicurarsi che la configurazione di rete delle macchine virtuali consenta l'accesso in uscita agli endpoint di Microsoft Entra su 443. Per altre informazioni, vedere la documentazione relativa a Windows e Linux .

Controllo di accesso basata sui ruoli: sono disponibili due ruoli controllo degli accessi in base al ruolo per fornire il livello di accesso appropriato a queste macchine virtuali. Questi ruoli di controllo degli accessi in base al ruolo possono essere configurati tramite il portale di Azure o tramite l'esperienza di Azure Cloud Shell. Per altre informazioni, vedere Configurare le assegnazioni di ruolo per la macchina virtuale.

• Accesso amministratore macchina virtuale: gli utenti con questo ruolo assegnato possono accedere a una macchina virtuale di Azure con privilegi di amministratore.

• Accesso utente macchina virtuale: gli utenti con questo ruolo assegnato possono accedere a una macchina virtuale di Azure con privilegi utente normali.

Accesso condizionale: un vantaggio fondamentale dell'uso di Microsoft Entra ID per l'accesso alle macchine virtuali di Azure è la possibilità di applicare l'accesso condizionale come parte del processo di accesso. Ciò consente alle organizzazioni di richiedere che le condizioni vengano soddisfatte prima di consentire l'accesso alla macchina virtuale e di usare l'autenticazione a più fattori per fornire l'autenticazione avanzata. Per altre informazioni, vedere Uso dell'accesso condizionale.

Nota

La connessione remota alle macchine virtuali aggiunte a Microsoft Entra ID è consentita solo dai PC Windows 10, Windows 11 e Cloud PC aggiunti a Microsoft Entra o aggiunti a Microsoft Entra ibrido alla stessa directory della macchina virtuale.

Sfide: l'elenco seguente evidenzia le sfide principali con l'uso di questa opzione per l'isolamento delle identità.

• Nessuna gestione centrale o configurazione dei server. Ad esempio, non esistono criteri di gruppo che possono essere applicati a un gruppo di server. Le organizzazioni devono prendere in considerazione la distribuzione di Gestione aggiornamenti in Azure per gestire l'applicazione di patch e gli aggiornamenti di questi server.

• Non adatto per applicazioni a più livelli che hanno requisiti per l'autenticazione con meccanismi locali, ad esempio l'autenticazione integrata di Windows in questi server o servizi. Se si tratta di un requisito per l'organizzazione, è consigliabile esplorare i servizi di Dominio di Active Directory autonomi o gli scenari di Servizi di dominio Microsoft Entra descritti in questa sezione.

Per questo modello isolato, si presuppone che non ci sia connettività alla rete virtuale che ospita le macchine virtuali dalla rete aziendale del cliente. È necessario creare un jumpbox o un server di gestione per consentire un punto da cui questi server possono essere gestiti e amministrati.

Passaggi successivi

• Introduzione all'amministrazione delegata e agli ambienti isolati

• Nozioni fondamentali su Microsoft Entra

• Isolamento delle risorse in un singolo tenant

• Isolamento delle risorse con più tenant

• Procedure consigliate