Gestione delle identità e degli accessi della zona di destinazione

Dopo aver identificato l'architettura delle identità, è necessario gestire l'autorizzazione e l'accesso per le risorse nelle zone di destinazione dell'applicazione e della piattaforma. Prendere in considerazione le risorse a cui ogni entità autenticata ha accesso e deve accedere e come ridurre il rischio di accesso non autorizzato alle risorse. Per altre informazioni, vedere Progettazione dell'architettura delle identità.

Panoramica

L'area di progettazione della gestione delle identità e degli accessi fornisce indicazioni per implementare il modello di accesso aziendale in Azure e implementare e proteggere i piani di controllo. Quando si incorpora il principio di progettazione della democratizzazione delle sottoscrizioni, il team dell'applicazione può gestire i propri carichi di lavoro all'interno dei criteri sorveglianti impostati dal team della piattaforma. Questo approccio segue anche il principio di governance basato su criteri.

Il team della piattaforma è responsabile del provisioning di nuove sottoscrizioni o zone di destinazione delle applicazioni. Quando effettua il provisioning di una zona di destinazione per un proprietario dell'applicazione, il team della piattaforma deve configurarlo con i controlli di accesso appropriati in modo che il proprietario dell'applicazione possa gestire le proprie risorse. Il proprietario dell'applicazione deve essere in grado di creare e gestire utenti e gruppi all'interno di Microsoft Entra ID e assegnare ruoli a tali utenti e gruppi. Il proprietario dell'applicazione può quindi gestire l'accesso alle proprie risorse e delegare l'accesso ad altri utenti e gruppi in base alle esigenze. La zona di destinazione deve avere anche la connettività di rete facoltativa a Dominio di Active Directory Services (AD DS) o Microsoft Entra Domain Services nella sottoscrizione di Microsoft Identity Platform, a seconda dei requisiti dell'applicazione.

Usare il controllo degli accessi in base al ruolo di Azure per gestire l'accesso amministrativo alle risorse di Azure. Valutare se gli utenti richiedono autorizzazioni per un ambito ristretto, ad esempio un amministratore per una singola applicazione o un ambito ampio, ad esempio un amministratore di rete in più carichi di lavoro dell'applicazione. In entrambi i casi, seguire il principio di accesso just-enough e assicurarsi che l'utente abbia solo i ruoli necessari per le normali attività. Usare ruoli personalizzati e Microsoft Entra Privileged Identity Management (PIM) dove necessario per applicare l'accesso JIT (Just-In-Time). Anche se il team della piattaforma è responsabile della base di gestione delle identità e degli accessi, sia i team della piattaforma che delle applicazioni sono consumer del servizio e devono seguire gli stessi principi.

La gestione delle identità e degli accessi è importante per la corretta separazione di una zona di destinazione da un'altra e l'isolamento dei carichi di lavoro all'interno di un'organizzazione. Si tratta di un'area di progettazione critica per le zone di destinazione della piattaforma e dell'applicazione.

Se l'organizzazione usa un processo di distribuzione automatica delle sottoscrizioni, è possibile automatizzare molte delle configurazioni di identità e accesso per le zone di destinazione dell'applicazione. Implementare vendita di abbonamenti per standardizzare la creazione della zona di destinazione e in modo che i team delle applicazioni possano gestire le proprie risorse.

Considerazioni relative alla progettazione

Alcune organizzazioni condividono servizi tra più applicazioni. Ad esempio, potrebbe essere presente un servizio di integrazione centralizzato usato da diverse applicazioni indipendenti. In questo scenario, considerare quali servizi vengono gestiti centralmente e che vengono devolvuti ai team delle applicazioni e comprendere dove devono essere applicati i limiti di sicurezza. Concedere ai team dell'applicazione l'accesso amministrativo al servizio condiviso potrebbe essere utile per la produttività degli sviluppatori, ma potrebbe fornire un accesso maggiore del necessario.

La gestione delle risorse dell'applicazione che non superano i limiti di sicurezza può essere delegata ai team delle applicazioni. Valutare l'opportunità di delegare anche altri aspetti necessari per mantenere la sicurezza e la conformità. Consentire agli utenti di effettuare il provisioning delle risorse all'interno di un ambiente gestito in modo sicuro consente alle organizzazioni di sfruttare la natura agile del cloud e impedire la violazione di qualsiasi limite critico di sicurezza o governance.

RBAC

Importante

Le risorse classiche e gli amministratori classici vengono ritirati il 31 agosto 2024. Rimuovere i coamministratori non necessari e usare il controllo degli accessi in base al ruolo di Azure per il controllo degli accessi con granularità fine.

Comprendere la differenza tra i ruoli di Microsoft Entra ID e i ruoli controllo degli accessi in base al ruolo di Azure.

• I ruoli MICROSOFT Entra ID controllano i privilegi amministrativi per i servizi a livello di tenant, ad esempio Microsoft Entra ID e altri servizi Microsoft, tra cui Microsoft Teams, Microsoft Exchange Online e Microsoft Intune.

• I ruoli controllo degli accessi in base al ruolo di Azure controllano i privilegi amministrativi per le risorse di Azure, ad esempio macchine virtuali, sottoscrizioni e gruppi di risorse.

• I ruoli Proprietario controllo degli accessi in base al ruolo di Azure e Amministratore accesso utenti possono modificare le assegnazioni di ruolo nelle risorse di Azure. Per impostazione predefinita, il ruolo amministratore globale di Microsoft Entra non dispone dell'autorizzazione per gestire l'accesso alle risorse di Azure. Deve essere abilitata in modo esplicito. Per altre informazioni, vedere Elevare i privilegi di accesso per gestire tutte le sottoscrizioni e i gruppi di gestione di Azure.

Importante

Microsoft consiglia di usare i ruoli con le autorizzazioni più poche. Ciò consente di migliorare la sicurezza per l'organizzazione. L'amministratore globale è un ruolo con privilegi elevati che deve essere limitato agli scenari di emergenza quando non è possibile usare un ruolo esistente.

Il diagramma seguente illustra la relazione tra i ruoli di Microsoft Entra ID e i ruoli controllo degli accessi in base al ruolo di Azure:

• È possibile creare gruppi assegnabili a ruoli e assegnare ruoli Di Microsoft Entra ai gruppi se si imposta la isAssignableToRole proprietà su true. Solo i gruppi con questo set di proprietà sono protetti. Gli unici ruoli che possono modificare l'appartenenza di un gruppo sono Amministratori globali, Amministratori ruolo con privilegi o proprietario del gruppo.

• Solo alcuni ruoli possono reimpostare le impostazioni di autenticazione a più fattori o password per un altro amministratore. Questa restrizione impedisce agli amministratori non autorizzati di reimpostare le credenziali di un account con privilegi più elevati per ottenere altre autorizzazioni.

• Se i ruoli predefiniti di Azure non soddisfano le esigenze specifiche dell'organizzazione, è possibile creare ruoli personalizzati. Analogamente ai ruoli predefiniti, è possibile assegnare ruoli personalizzati a utenti, gruppi e entità servizio negli ambiti tenant, gruppo di gestione, sottoscrizione e gruppo di risorse. L'obiettivo è usare i ruoli predefiniti di Azure, se possibile, e creare solo ruoli personalizzati quando necessario.

• Quando si progetta la strategia di controllo di accesso, conoscere i limiti del servizio per ruoli, assegnazioni di ruolo e ruoli personalizzati.

• Alcuni ruoli controllo degli accessi in base al ruolo di Azure supportano il controllo degli accessi in base all'attributo o le condizioni di assegnazione dei ruoli. Quando si usano condizioni, gli amministratori possono assegnare in modo dinamico i ruoli in base agli attributi della risorsa. Ad esempio, è possibile assegnare il ruolo Collaboratore dati BLOB di archiviazione, ma solo per i BLOB con un tag di indice specifico anziché tutti i BLOB in un contenitore.

• È possibile usare ruoli di controllo degli accessi in base al ruolo predefiniti e personalizzati con Microsoft.Authorization/roleAssignments/write o Microsoft.Authorization/roleAssignments/delete autorizzazioni per creare, eliminare e aggiornare le assegnazioni di ruolo. Chiunque abbia questo ruolo può decidere chi ha autorizzazioni di scrittura, lettura ed eliminazione per qualsiasi risorsa nell'ambito di assegnazione. I membri del team della piattaforma o dell'applicazione di destinazione devono considerare come delegare ruoli con privilegi ad altri utenti e gruppi per concedere loro l'autonomia necessaria. Per garantire la conformità ai principi di accesso con privilegi minimi, è possibile usare le condizioni per delegare gli utenti.

Suggerimenti per la progettazione

Raccomandazioni generali

• Applicare l'autenticazione a più fattori (MFA) di Microsoft Entra per gli utenti che dispongono dei diritti per l'ambiente Azure, tra cui la sottoscrizione della piattaforma, la sottoscrizione dell'applicazione e il tenant microsoft Entra ID. Molti framework di conformità richiedono l'imposizione dell'autenticazione a più fattori. L'autenticazione a più fattori consente di ridurre il rischio di furto di credenziali e accesso non autorizzato. Per impedire l'accesso non autorizzato alle informazioni riservate, assicurarsi di includere gli utenti con ruoli lettore nei criteri di autenticazione a più fattori.

• Usare i criteri di accesso condizionale di Microsoft Entra per gli utenti che dispongono dei diritti per l'ambiente Azure. L'accesso condizionale è un'altra funzionalità che consente di proteggere un ambiente di Azure controllato da accessi non autorizzati. Gli amministratori di applicazioni e piattaforme devono avere criteri di accesso condizionale che riflettono il profilo di rischio del proprio ruolo. Ad esempio, potrebbero essere necessari requisiti per eseguire attività amministrative solo da posizioni specifiche o workstation specifiche. In alternativa, la tolleranza di rischio di accesso per gli utenti con accesso amministrativo alle risorse di Azure potrebbe essere inferiore a quella per gli utenti standard di Microsoft Entra ID.

• Abilitare Microsoft Defender per identità per proteggere le identità utente e proteggere le credenziali utente. Defender per identità fa parte di Microsoft Defender XDR. È possibile usare Defender per identità per identificare le attività utente sospette e ottenere sequenze temporali degli eventi imprevisti. È anche possibile usarlo con l'accesso condizionale per negare i tentativi di autenticazione ad alto rischio. Distribuire i sensori di Defender per identità nei controller di dominio locali e nei controller di dominio nella sottoscrizione di identità di Azure.

• Usare Microsoft Sentinel per fornire funzionalità di intelligence sulle minacce e indagini. Sentinel usa i log dei log di Monitoraggio di Azure, l'ID Microsoft Entra, Microsoft 365 e altri servizi per fornire funzionalità proattive di rilevamento delle minacce, analisi e risposta.

• Separare l'accesso amministrativo dall'accesso non amministrativo e giornaliero, ad esempio l'esplorazione Web e l'accesso alla posta elettronica. Web e posta elettronica sono vettori di attacco comuni. Quando un account utente viene compromesso, è meno probabile che si verifichi una violazione della sicurezza se l'account non viene usato per l'accesso amministrativo.

  • Usare account separati solo cloud per i ruoli con privilegi. Non usare lo stesso account per l'uso giornaliero per l'amministrazione con privilegi. I ruoli Privileged Microsoft Entra ID e Controllo degli accessi in base al ruolo di Azure sono contrassegnati come PRIVILEGED nella portale di Azure e nella documentazione.

  • Per i ruoli della funzione di processo senza privilegi in grado di gestire le risorse dell'applicazione Azure, valutare se è necessario un account amministrativo separato o usare Microsoft Entra PIM per controllare l'accesso amministrativo. PIM garantisce che l'account disponga delle autorizzazioni necessarie solo quando necessario e che le autorizzazioni vengano rimosse al termine dell'attività (noto anche come accesso JUST-In-Time).

• Per rendere più gestibili le assegnazioni di ruolo, non assegnare ruoli direttamente agli utenti. Assegnare invece ruoli ai gruppi per ridurre al minimo il numero di assegnazioni di ruolo, con un limite per ogni sottoscrizione.

  • Usare Microsoft Entra PIM per i gruppi per applicare controlli di accesso amministrativo JIT agli utenti con privilegi. Valutare la possibilità di controllare l'appartenenza al gruppo con la gestione entitlement. È possibile usare la funzionalità di gestione entitlement per aggiungere flussi di lavoro di approvazione e controllo alle operazioni di appartenenza ai gruppi e garantire che i membri del gruppo amministrativo non vengano aggiunti o rimossi inutilmente.

  • Quando si concede l'accesso alle risorse, usare i gruppi solo Entra di Microsoft per le risorse del piano di controllo di Azure. Sia gli utenti che i gruppi entra-only, e quelli sincronizzati dall'ambiente locale con Microsoft Entra Connect, possono essere aggiunti a un gruppo solo Entra. Aggiungere gruppi locali al gruppo solo Microsoft Entra se è già presente un sistema di gestione dei gruppi. L'uso dei gruppi entra-only consente di proteggere il piano di controllo cloud da modifiche non autorizzate dei servizi directory locali. Si noti che solo Microsoft Entra-only è noto solo come cloud.

• Creare account di accesso di emergenza o account break-glass per evitare di essere accidentalmente bloccati dall'organizzazione microsoft Entra ID. Gli account di accesso di emergenza hanno privilegi elevati e vengono assegnati solo a utenti specifici. Archiviare le credenziali per gli account in modo sicuro, monitorarne l'uso e testarle regolarmente per assicurarsi di poterle usare in caso di emergenza.

  Per altre informazioni, vedere Procedure di accesso sicuro per gli amministratori in Microsoft Entra ID.

Raccomandazioni per Microsoft Entra ID

• Integrare Microsoft Entra ID con Monitoraggio di Azure per analizzare l'attività di accesso e il audit trail delle modifiche all'interno del tenant. Configurare un'impostazione di diagnostica per inviare i log di accesso e i log di controllo all'area di lavoro Log di Monitoraggio di Azure centrale della piattaforma nella sottoscrizione di gestione.

• Usare la funzionalità di gestione entitlement di Microsoft Entra ID Governance per creare pacchetti di accesso che controllano l'appartenenza ai gruppi tramite processi di approvazione automatica e verifiche di accesso regolari per i membri del gruppo con privilegi.

• Usare i ruoli predefiniti di Microsoft Entra per gestire le impostazioni di identità seguenti a livello di tenant:

  Ruolo	Descrizione	Nota
  Amministratore globale	Gestisce tutti gli aspetti di Microsoft Entra ID e servizi Microsoft che usano le identità di Microsoft Entra.	Non assegnare più di cinque persone a questo ruolo.
  Amministratore delle identità ibride	Gestisce il provisioning cloud da Active Directory a Microsoft Entra ID e gestisce anche Microsoft Entra Connect, l'autenticazione pass-through di Microsoft Entra, la sincronizzazione dell'hash delle password di Microsoft Entra, Microsoft Entra seamless Single Sign-On (SSO) e le impostazioni di federazione.
  Amministratore della sicurezza	Legge informazioni e report sulla sicurezza e gestisce le configurazioni in Microsoft Entra ID e Microsoft 365.
  Amministratore applicazione	Crea e gestisce tutti gli aspetti delle registrazioni delle app e delle app aziendali.	Non è possibile concedere il consenso amministrativo a livello di tenant.

• Non assegnare un ruolo con privilegi più elevati a un'attività che un ruolo con privilegi inferiori può eseguire. Ad esempio, assegnare il ruolo Amministratore utenti per gestire gli utenti, non il ruolo amministratore globale. Per altre informazioni, vedere Autorizzazioni dei ruoli predefiniti di Microsoft Entra.

• Usare le unità amministrative per limitare un set di amministratori in modo che possano gestire solo oggetti specifici nel tenant. È possibile usare unità amministrative per delegare l'amministrazione di un subset della directory. Ad esempio, è possibile delegare l'amministrazione di un service desk a una singola business unit all'interno di un'organizzazione più ampia.

  Le unità amministrative possono anche aiutare a eliminare la necessità di separare i tenant di Microsoft Entra ID come limite di sicurezza, in cui team separati gestiscono la piattaforma Microsoft 365 e la piattaforma Azure nella stessa organizzazione. Ad esempio, è possibile usare le unità amministrative per delegare la gestione delle entità di sicurezza delle applicazioni di Azure al team dell'applicazione senza concedere privilegi all'intero tenant di Microsoft Entra ID.

• Usare le unità amministrative di gestione con restrizioni per fornire ulteriore protezione. Impedire a chiunque altro di un set specifico di amministratori designati di modificare oggetti specifici. Ad esempio, la separazione dei criteri di servizio potrebbe richiedere l'uso di questa funzionalità per impedire a chiunque di modificare un account utente specifico, anche gli utenti con il ruolo Amministratore utenti. Questa restrizione è utile per gli account del servizio usati da applicazioni e che anche gli amministratori non devono modificare. È anche possibile impedire l'escalation dei privilegi, ad esempio se un utente modifica un account utente o un gruppo con privilegi di amministrazione della piattaforma o dell'area di destinazione.

Consigli sul controllo degli accessi in base al ruolo di Azure

• Per semplificare l'amministrazione e ridurre il rischio di errori di configurazione, standardizzare ruoli e assegnazioni di ruolo in tutte le zone di destinazione dell'applicazione. Ad esempio, se si ha un ruolo che delega gli utenti alla gestione delle macchine virtuali, usare lo stesso ruolo in tutte le zone di destinazione dell'applicazione. Questo approccio semplifica anche il processo di spostamento delle risorse tra le zone di destinazione.

• Usare il controllo degli accessi in base al ruolo di Azure per gestire l'accesso del piano dati alle risorse, se possibile. Esempi di endpoint del piano dati sono Azure Key Vault, un account di archiviazione o un database SQL.

• Assicurarsi che le aree di lavoro Log di Monitoraggio di Azure siano configurate con il modello di autorizzazione appropriato. Quando si usa un'area di lavoro centralizzata log di Monitoraggio di Azure, usare le autorizzazioni per le risorse per assicurarsi che i team dell'applicazione abbiano accesso ai propri log, ma non ai log di altri team.

Ruoli predefiniti

• Valutare se i ruoli predefiniti sono adatti ai requisiti. In molti casi, è possibile assegnare più ruoli predefiniti a un gruppo di sicurezza per fornire l'accesso appropriato per un utente. In alcuni casi, tuttavia, non è possibile usare ruoli predefiniti e rispettare anche l'accesso con privilegi minimi perché i ruoli possono includere autorizzazioni che superano le richieste degli utenti. Per un controllo più granulare, è consigliabile creare un ruolo personalizzato che rifletta le autorizzazioni specifiche necessarie per eseguire una funzione di processo. Per altre informazioni, vedere Fornire l'autorizzazione basata sui ruoli.

• Molti ruoli predefiniti di Azure forniscono assegnazioni di ruolo predefinite a livello di piattaforma e risorsa. Quando si combinano diverse assegnazioni di ruolo, prendere in considerazione gli effetti complessivi.

• L'acceleratore di zona di destinazione di Azure include diversi ruoli personalizzati per le funzioni amministrative comuni. È possibile usare questi ruoli insieme ai ruoli predefiniti di Azure. La tabella seguente descrive i ruoli amministrativi personalizzati o le aree per l'acceleratore di zona di destinazione di Azure:

  Ruolo amministrativo o area	Descrizione	Azioni	NotActions
  Proprietario della piattaforma Azure (ad esempio il ruolo proprietario predefinito)	Gestisce i gruppi di gestione e i cicli di vita delle sottoscrizioni	*
  Proprietario della sottoscrizione	Ruolo delegato per il proprietario della sottoscrizione	*	Microsoft.Authorization/*/write, Microsoft.Network/vpnGateways/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnSites/*
  Proprietario dell'applicazione (DevOps, operazioni dell'app)	Ruolo collaboratore per l'applicazione o il team operativo nell'ambito della sottoscrizione	*	Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write, Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action
  Gestione della rete (NetOps)	Gestisce la connettività globale a livello di piattaforma, ad esempio reti virtuali, route definite dall'utente, gruppi di sicurezza di rete, appliance virtuali di rete, VPN, Azure ExpressRoute e altri	*/read, Microsoft.Network/*, Microsoft.Resources/deployments/*, Microsoft.Support/*
  Operazioni per la sicurezza (SecOps)	Ruolo amministratore della sicurezza con una visualizzazione orizzontale nell'intero ambiente di Azure e nei criteri di eliminazione dell'insieme di credenziali delle chiavi	*/read, */register/action, Microsoft.KeyVault/locations/deletedVaults/purge/action, Microsoft.PolicyInsights/*, Microsoft.Authorization/policyAssignments/*, Microsoft.Authorization/policyDefinitions/*, Microsoft.Authorization/policyExemptions/*, Microsoft.Authorization/policySetDefinitions/*, Microsoft.Insights/alertRules/*, Microsoft.Resources/deployments/*, Microsoft.Security/*, Microsoft.Support/*

  Questi ruoli potrebbero richiedere diritti aggiuntivi a seconda del modello di responsabilità. In alcune organizzazioni, ad esempio, è possibile che un ruolo NetOps debba solo gestire e configurare la connettività globale. Nelle organizzazioni che richiedono un approccio più centralizzato, è possibile arricchire il ruolo NetOps con azioni più consentite, ad esempio la creazione di peering tra hub e i relativi spoke.

Assegnazioni di ruolo e gruppi

• Quando il team della piattaforma effettua il provisioning di una zona di destinazione dell'applicazione, deve assicurarsi che vengano creati tutti gli oggetti di gestione delle identità e degli accessi necessari, ad esempio gruppi di sicurezza, assegnazioni di ruolo standard e identità gestite assegnate dall'utente.

• Creare assegnazioni di ruolo della zona di destinazione nell'ambito della sottoscrizione o del gruppo di risorse. Criteri di Azure assegnazioni si verificano nell'ambito del gruppo di gestione, pertanto è consigliabile effettuare il provisioning delle assegnazioni di ruolo della zona di destinazione in un ambito inferiore. Usare questo approccio per garantire che gli amministratori della zona di destinazione abbiano piena autonomia sulle risorse, ma non possano modificare le assegnazioni Criteri di Azure che regolano la zona di destinazione.

• Ogni zona di destinazione dell'applicazione deve avere gruppi e assegnazioni di ruolo specifici. Non creare gruppi generici e assegnarli a più zone di destinazione. Questo approccio può causare errori di configurazione e violazioni della sicurezza ed è difficile gestirlo su larga scala. Se un utente richiede l'accesso a più zone di destinazione, assegnarle ai gruppi appropriati in ogni zona di destinazione. Usare la governance degli ID per gestire l'appartenenza al gruppo.

• Assegnare ruoli ai gruppi, non agli utenti. Questo approccio consente di garantire che gli utenti dispongano delle autorizzazioni corrette quando accedono o lasciano l'organizzazione. Consente anche di assicurarsi che gli utenti dispongano delle autorizzazioni corrette quando si spostano tra team. Ad esempio, se un utente passa dal team di rete al team di sicurezza, è necessario rimuoverli dal gruppo di rete e aggiungerli al gruppo di sicurezza. Se si assegna un ruolo direttamente a un utente, il ruolo viene mantenuto dopo il passaggio a un team diverso. Usare la governance degli ID per gestire l'appartenenza ai gruppi anziché aggiungere e rimuovere manualmente i membri del gruppo.

• Mantenere configurazioni di sicurezza separate per ambienti diversi della stessa applicazione, ad esempio sviluppo/test e produzione. Creare gruppi e assegnazioni di ruolo separati per ogni ambiente. Non condividere identità gestite o entità servizio tra ambienti. Considerare ogni ambiente come una zona di destinazione separata. Questo approccio consente di garantire l'isolamento tra sviluppo/test e produzione e standardizza il processo di spostamento delle distribuzioni di applicazioni tra ambienti. Se la stessa persona richiede l'accesso a diverse zone di destinazione, è necessario assegnarle ai gruppi appropriati in ogni zona di destinazione.

• Valutare se gli amministratori della piattaforma richiedono autorizzazioni per le zone di destinazione dell'applicazione. In tal caso, usare Microsoft Entra PIM per controllare l'accesso a tali risorse e assegnare le autorizzazioni con privilegi minimi necessarie. Ad esempio, un amministratore della piattaforma potrebbe richiedere l'accesso a una zona di destinazione dell'applicazione specifica per risolvere un problema, ma non deve avere accesso di routine ai dati o al codice dell'applicazione. In questo caso, l'amministratore della piattaforma può richiedere l'accesso all'applicazione. Un amministratore del ruolo con privilegi approva la richiesta e all'amministratore della piattaforma sono concesse le autorizzazioni necessarie per il periodo di tempo specificato. Questo approccio consente di applicare la separazione dei compiti e protegge le zone di destinazione dell'applicazione da errori di configurazione accidentali o dannosi.

• Quando si delega la responsabilità amministrativa ad altri utenti, ad esempio i team dell'applicazione, valutare se richiedono il set completo di privilegi o solo un subset. Seguire il principio dei privilegi minimi (PoLP). Ad esempio, è possibile assegnare il ruolo Amministratore accesso utenti o Amministratore controllo degli accessi in base al ruolo a un utente che deve gestire l'accesso alle risorse di Azure, ma non deve gestire le risorse stesse. Per limitare le identità, i tipi di identità e i ruoli a cui gli utenti possono delegare e assegnare assegnazioni di controllo degli accessi in base al ruolo di Azure, usare assegnazioni di ruolo delegate con condizioni. I team delle applicazioni possono usare le condizioni per gestire le proprie entità di sicurezza entro i vincoli impostati dal team della piattaforma. Le assegnazioni di ruolo con privilegi più richiedono l'escalation al team della piattaforma. Quando si usano le condizioni per delegare i ruoli controllo degli accessi in base al ruolo, tenere presenti i fattori seguenti:

  • Esaminare le assegnazioni di ruolo correnti per i ruoli con privilegi predefiniti e personalizzati e valutare se è necessario aggiungere condizioni appropriate a tali assegnazioni esistenti. Ad esempio, è possibile aggiungere condizioni ai ruoli personalizzati Proprietario sottoscrizione e Proprietario applicazione forniti dall'acceleratore di zona di destinazione di Azure. Queste condizioni possono limitare i tipi di entità a cui possono assegnare ruoli o limitare ruoli specifici che possono assegnare.

  • Seguire il poLP quando si aggiungono condizioni alle assegnazioni di ruolo. Ad esempio, limitare i delegati per assegnare ruoli solo ai gruppi o consentire ai delegati di assegnare tutti i ruoli ad eccezione dei ruoli di amministratore con privilegi come Proprietario, Amministratore accesso utenti e Amministratore controllo degli accessi in base al ruolo.

  • Creare condizioni personalizzate se i modelli di condizione disponibili non soddisfano i requisiti o i criteri.

    

  • Esaminare le limitazioni note della delega della gestione degli accessi di Azure ad altri utenti.

• La tabella seguente illustra una struttura di assegnazione di ruolo di esempio per un ambiente della zona di destinazione di Azure. Offre un equilibrio tra sicurezza e facilità di amministrazione. È possibile adattare la struttura in base ai requisiti dell'organizzazione. È possibile assegnare lo stesso individuo a più gruppi, a seconda del proprio ruolo all'interno dell'organizzazione. È tuttavia consigliabile applicare le assegnazioni di controllo degli accessi in base al ruolo a un gruppo specifico all'interno di una zona di destinazione specifica.

  Conto risorse	User	Assegnazione di ruolo	Destinazione assegnazione	Ambito dell'assegnazione
  Zona di destinazione application X	Proprietari di Application X	Proprietario dell'applicazione (personalizzato, incluso nell'acceleratore di zona di destinazione di Azure)	Application X Admins gruppo di sicurezza	Sottoscrizioni di produzione e sviluppo/test dell'applicazione X
  Zona di destinazione application X	Proprietari di Application X	Amministratore dell'accesso alle applicazioni (personalizzato, con condizioni di assegnazione di ruolo per gestire l'accesso alla propria applicazione)	Application X Admins gruppo di sicurezza	Sottoscrizioni di produzione e sviluppo/test dell'applicazione X
  Zona di destinazione application X	Amministratore dati di Application X	Amministratore dati (personalizzato, con autorizzazioni per le risorse dati necessarie)	Application X Data Team gruppo di sicurezza	Sottoscrizioni di produzione e sviluppo/test dell'applicazione X
  Zona di destinazione dell'applicazione Y	Proprietari dell'applicazione Y	Proprietario dell'applicazione (personalizzato, incluso nell'acceleratore di zona di destinazione di Azure)	Application Y Admins gruppo di sicurezza	Sottoscrizioni di produzione e sviluppo/test dell'applicazione Y
  Zona di destinazione dell'applicazione Y	Team di test dell'applicazione Y	Collaboratore test (personalizzato, con autorizzazioni necessarie per il test dell'applicazione)	Application Y Test Team gruppo di sicurezza	Sottoscrizione di sviluppo/test dell'applicazione Y
  Sandbox	Team di sviluppo di Application Z	Proprietario (impostazione predefinita)	Application Z developers gruppo di sicurezza	Gruppi di risorse Z dell'applicazione nella sottoscrizione sandbox
  Risorse della piattaforma	Team di gestione della piattaforma	Collaboratore (impostazione predefinita)	Platform Admins Gruppo PIM	Platform gruppo di gestione
  Zone di destinazione della piattaforma	Team di gestione della piattaforma	Lettore (impostazione predefinita)	Platform Team gruppo di sicurezza	Gruppo di gestione di primo livello dell'organizzazione
  A livello di tenant	Team di sicurezza	Operazioni di sicurezza (personalizzate, incluse nell'acceleratore di zona di destinazione di Azure)	Security Ops gruppo di sicurezza	Gruppo di gestione di primo livello dell'organizzazione
  A livello di tenant	Team di sicurezza	Amministratore dell'accesso condizionale (predefinito, con azioni protette abilitate)	Security administrators gruppo di sicurezza	Tenant microsoft Entra ID
  A livello di tenant	Team responsabile della rete	Operazioni di rete (personalizzato, incluso nell'acceleratore di zona di destinazione di Azure)	Network Ops gruppo di sicurezza	Tutte le sottoscrizioni
  A livello di tenant	Team di FinOps	Lettore di fatturazione (predefinito)	FinOps Team gruppo di sicurezza	Gruppo di gestione di primo livello dell'organizzazione

• Criteri di Azure assegnazioni che hanno effetto richiedono un'identità DeployIfNotExists gestita per correggere le risorse non conformi. Se si usa un'identità gestita assegnata dal sistema come parte del processo di assegnazione Criteri di Azure, Azure concede automaticamente le autorizzazioni necessarie. Se si usa un'identità gestita assegnata dall'utente, le autorizzazioni devono essere concesse manualmente. Le assegnazioni di ruolo dell'identità gestita devono seguire il poLP e abilitare solo le autorizzazioni necessarie per eseguire la correzione dei criteri nell'ambito di destinazione. Le identità gestite di correzione dei criteri non supportano definizioni di ruolo personalizzate. Applicare le assegnazioni di ruolo direttamente alle identità gestite e non ai gruppi.

Raccomandazioni di Microsoft Entra PIM

• Usare Microsoft Entra PIM per rispettare il modello Zero Trust e l'accesso con privilegi minimi. Correlare i ruoli dell'organizzazione ai livelli di accesso minimi necessari. In Microsoft Entra PIM è possibile usare strumenti nativi di Azure, estendere gli strumenti e i processi esistenti oppure usare strumenti nativi e esistenti in base alle esigenze.

• Usare le verifiche di accesso di Microsoft Entra PIM per convalidare regolarmente i diritti delle risorse. Le verifiche di accesso sono incluse in numerosi framework di conformità, pertanto molte organizzazioni hanno già un processo di verifica di accesso.

• Usare le identità con privilegi per i runbook di automazione che richiedono autorizzazioni di accesso elevate o per le pipeline di distribuzione con privilegi. È possibile usare gli stessi strumenti e criteri per gestire flussi di lavoro automatizzati che accedono ai limiti di sicurezza critici usati per gestire gli utenti con privilegi equivalenti. Le pipeline di automazione e distribuzione per i team delle applicazioni devono avere assegnazioni di ruolo che impediscono a un proprietario dell'applicazione di inoltrare i propri privilegi.

• Controllare i ruoli con controllo degli accessi in base al ruolo di Azure con privilegi elevati, ad esempio Proprietario o Amministratori accesso utenti assegnati ai membri del team della piattaforma o dell'applicazione di destinazione in una sottoscrizione o in un gruppo di gestione. Usare Microsoft Entra PIM per i gruppi per configurare i ruoli controllo degli accessi in base al ruolo di Azure in modo che richiedano lo stesso processo di elevazione dei privilegi dei ruoli di Microsoft Entra ID.

  Ad esempio, un utente potrebbe richiedere regolarmente accesso amministrativo limitato alle risorse in una zona di destinazione dell'applicazione. In alcuni casi, potrebbero richiedere il ruolo Proprietario. È possibile creare due gruppi di sicurezza: Amministratori applicazioni e Proprietari di applicazioni. Assegnare i ruoli con privilegi minimi al gruppo Amministratori applicazioni e assegnare il ruolo proprietario al ruolo Proprietari dell'applicazione. Usare i gruppi PIM in modo che l'utente possa richiedere il ruolo Proprietario quando necessario. In qualsiasi momento, l'utente ha solo le autorizzazioni necessarie per eseguire le attività tipiche.

• Usare le azioni protette con Microsoft Entra PIM per aggiungere livelli aggiuntivi di protezione. In Microsoft Entra ID le azioni protette sono autorizzazioni assegnate ai criteri di accesso condizionale. Quando un utente tenta di eseguire un'azione protetta, deve prima soddisfare i criteri di accesso condizionale assegnati alle autorizzazioni necessarie. Ad esempio, per consentire agli amministratori di aggiornare le impostazioni di accesso tra tenant, è possibile richiedere che soddisfino prima i criteri di autenticazione a più fattori resistenti al phishing.

Gestione delle identità e degli accessi nell'acceleratore delle zone di destinazione di Azure

La gestione delle identità e degli accessi è una funzionalità di base dell'implementazione dell'acceleratore di zona di destinazione di Azure. La distribuzione include una sottoscrizione dedicata all'identità, in cui le organizzazioni possono distribuire controller di dominio Active Directory Domain Services o altri servizi di identità, ad esempio i server Microsoft Entra Connect, necessari per il proprio ambiente. Non tutte le organizzazioni richiedono servizi nella sottoscrizione. Ad esempio, alcune organizzazioni potrebbero avere applicazioni già completamente integrate con Microsoft Entra ID.

La sottoscrizione di identità ha una rete virtuale con peering alla rete virtuale hub nella sottoscrizione della piattaforma. Con questa configurazione, il team della piattaforma può gestire la sottoscrizione di identità e i proprietari delle applicazioni hanno accesso ai servizi di identità in base alle esigenze. È necessario proteggere la sottoscrizione di identità e la rete virtuale per proteggere i servizi di identità da accessi non autorizzati.

L'implementazione dell'acceleratore di zona di destinazione di Azure include anche opzioni per:

• Assegnare i criteri consigliati per gestire i controller di identità e di dominio.
• Creare una rete virtuale e connettersi all'hub tramite il peering di rete virtuale.

Passaggi successivi

Gestione delle identità e degli accessi delle applicazioni