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 vogliono 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 facilitare la semplificazione della 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.
Gruppo di gestione - 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 le 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 a un gruppo di risorse, a una sottoscrizione, a un tenant o a 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, è possibile usare il linguaggio Bicep invece di JSON.
Modello di gestione delle 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. È possibile usare 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 Azure Resource Manager rispetto a classica. 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, dal portale di Azure o da altri client per gestire le risorse. Quando un client effettua una richiesta di gestione di una risorsa specifica, Resource Manager inoltra la richiesta al provider di risorse per completarla. 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 sia possibile eseguire qualsiasi richiesta di gestione delle risorse da Resource Manager, vengono verificati alcuni 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.
Verifica delle autorizzazioni utente: le autorizzazioni vengono assegnate agli utenti tramite il controllo degli accessi in base al ruolo (RBAC). 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 contribuisce a gestire chi può accedere alle risorse di Azure, le operazioni che si possono eseguire e le aree accessibili.
Controllo dei criteri di Azure - I criteri di Azure specificano le operazioni consentite o negate in modo esplicito per una risorsa specifica. Ad esempio, un criterio può specificare che agli utenti sia consentito (o meno) distribuire solo un tipo specifico di macchina virtuale.
Il diagramma seguente riepiloga il modello di risorse appena descritto.
Azure Lighthouse - 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 in grado di gestire sottoscrizioni o gruppi di risorse e il mapping dal 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 aiuta i Provider di servizi gestiti (MSP) a proteggere e gestire dispositivi, dati e utenti su larga scala per i clienti di piccole e medie dimensioni (SMB) 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.
Contratti Enterprise di Azure
I clienti con Contratto Enterprise di Azure (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 contribuiscono a 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 Azure Resource Manager rispetto a classica).
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 di amministratore del servizio alla sottoscrizione, è possibile modificare il tenant 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 ulteriori informazioni, vedere Ruoli di Azure, ruoli di Microsoft Entra e ruoli di amministratore della sottoscrizione classica.
Contratto del cliente Microsoft
I clienti registrati con un Contratto del cliente Microsoft (MCA) hanno un sistema di gestione della fatturazione differente 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 per la 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 più accurato alle risorse di Azure e include diversi 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 all’attributo e assegnazioni di ruolo in Azure
Il Controllo degli accessi in base all'attributo (ABAC) è 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 all'attributo di Azure si basa sul controllo degli accessi in base al ruolo di Azure aggiungendo condizioni di assegnazione di ruolo basate su 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ù accurato. 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
È possibile usare l'Accesso condizionale Microsoft Entra 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 ibrido aggiunto al dominio Microsoft Entra.
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 l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra senza dover inserire le credenziali nel codice.
Sono disponibili due tipi di identità gestite:
Un'identità gestita assegnata dal sistema viene 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 la creazione dell'identità, viene effettuato il provisioning delle credenziali 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 la creazione, 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 l'identità è assegnata.
Internamente, le identità gestite sono entità servizio di un tipo speciale, che è possibile usare 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 Active Directory B2C e Azure
Un tenant di Azure Active Directory B2C è collegato a una sottoscrizione di Azure per scopi di fatturazione e comunicazione. I tenant di Azure Active Directory 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 Active Directory 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 Active Directory B2C ed è successivamente in grado di 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 link tra la sottoscrizione e la directory, che influirà sulla fatturazione in corso dell'utilizzo di Azure Active Directory 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 Infrastructure-as-a-Service (IaaS).
Sono disponibili tre opzioni chiave relative alla gestione dell'isolamento dei carichi di lavoro IaaS:
Macchine virtuali aggiunte ad Active Directory Domain Services (AD DS) autonome
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 Microsoft Entra ID (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 di dominio Active Directory autonomi
Active Directory Domain Services è il servizio directory basato su Windows Server che le organizzazioni hanno ampiamente adottato per i servizi di gestione delle identità locali. È possibile distribuire Active Directory 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 Active Directory Domain Services 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:
Domain Name Service (DNS) di Active Directory Domain Services: è necessario configurare il DNS di Active Directory Domain Services per le zone pertinenti all'interno di Active Directory Domain Services, così da garantire che la risoluzione dei nomi funzioni correttamente per server e applicazioni.
Siti e servizi di Active Directory Domain Services: è necessario configurare questi servizi 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.
FSMO di Active Directory Domain Services: è necessario prendere in esame i ruoli Flexible Single Master Operation (FSMO) e assegnarli 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 Active Directory Domain Services per l'autenticazione, la configurazione e la gestione devono essere aggiunti alla foresta isolata.
Criteri di gruppo (GPO) di Active Directory Domain Services: è necessario configurare i criteri di gruppo di Active Directory Domain Services per garantire che la configurazione soddisfi i requisiti di sicurezza e che sia standardizzata tra le foreste e i computer aggiunti a un dominio.
Unità organizzative (OU) di Active Directory Domain Services: è necessario definire le unità organizzative di Active Directory Domain Services 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: è necessario definire il Controllo degli accessi in base al ruolo per l'amministrazione e l'accesso alle risorse aggiunte a questa foresta. Valuta gli ambiti seguenti:
Gruppi di Active Directory Domain Services: è necessario creare gruppi 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 privilegiato minimi necessari per eseguire l'amministrazione necessaria in Active Directory Domain Services e nei server aggiunti a un dominio.
Un account di amministrazione di Microsoft Entra per l'accesso al portale di Azure 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) - Indicazioni sulla 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: è necessario configurare i server DNS 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 (NSG): i controller di dominio devono trovarsi nella propria rete virtuale o nel subnet con gruppi di sicurezza di rete definiti in modo da consentire l'accesso esclusivamente 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 correlate all'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 degli aggiornamenti di Azure, Criteri di gruppo (GPO) 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 Active Directory Domain Services 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 Active Directory Domain Services. È necessario considerare quanto segue.
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 il suddetto è 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: è necessario impostare una posizione 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 Microsoft Entra Domain Service.
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à dal Microsoft Entra ID associato alla sottoscrizione in cui viene distribuito Microsoft Entra Domain Services. Vale anche la pena notare che se Microsoft Entra ID 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 è possibile usare 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.
Con ambito: solo gli utenti nell'ambito di uno o più gruppi 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 da Microsoft Entra ID. 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 Come vengono sincronizzati gli oggetti e le 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 (GPO): 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 Gestire i criteri di gruppo per un dominio gestito di Microsoft Entra Domain Services.
LDAP sicuro: Microsoft Entra Domain Services fornisce un servizio LDAP sicuro utilizzabile 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 l'accesso LDAP sicuro (LDAPS) per un dominio gestito di Microsoft Entra Domain Services.
Amministrazione: per eseguire compiti di amministrazione in Microsoft Entra Domain Services (ad esempio, aggiungere computer a un dominio o modificare oggetti Criteri di gruppo), l'account usato per questa attività deve far parte del gruppo Administrators di Microsoft Entra Domain Services. 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 relativi alla gestione di account utente, password e amministrazione in Microsoft Entra Domain Services.
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 corretta comunicazione del servizio. Non creare né 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 sia in grado di fornire tale 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 indicato in precedenza in merito al modello "gruppo a ruota", è 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 correlate all'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 il modello “gruppo a ruota” per fornire l'autenticazione di Microsoft Entra Domain Service 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 degli aggiornamenti di Azure, Criteri di gruppo (GPO) 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 Microsoft Entra ID 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 considerare quanto segue.
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 capacità 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, in modo da 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 di Windows e Linux.
Controllo degli accessi in base al ruolo (RBAC):sono disponibili due ruoli RBAC 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 alle macchine virtuali: gli utenti a cui è stato assegnato questo ruolo possono accedere a una macchina virtuale di Azure con i privilegi di amministratore.
Accesso utente alle macchine virtuali: gli utenti a cui è stato assegnato questo ruolo possono accedere a una macchina virtuale di Azure con i privilegi di utente normale.
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 Utilizzo 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 correlate all'uso di questa opzione per l'isolamento delle identità.
Nessuna gestione centrale o configurazione dei server. Ad esempio, non esistono criteri di gruppo che è possibile applicare 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 Active Directory autonomi o gli scenari di Microsoft Entra Domain Service 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
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per