Condividi tramite


Introduzione all'amministrazione delegata e agli ambienti isolati

Un'architettura a tenant singolo di Microsoft Entra con amministrazione delegata è spesso adeguata per separare gli ambienti. Come descritto in dettaglio in altre sezioni di questo articolo, Microsoft offre molti strumenti per eseguire questa operazione. Tuttavia, possono verificarsi momenti in cui l'organizzazione richiede un grado di isolamento oltre a ciò che può essere ottenuto in un singolo tenant.

Prima di discutere di architetture specifiche, è importante comprendere:

  • Funzionamento di un tenant singolo tipico.

  • Funzionamento delle unità amministrative in Microsoft Entra ID.

  • Relazioni tra le risorse di Azure e i tenant di Microsoft Entra.

  • Requisiti comuni che guidano l'isolamento.

Tenant di Microsoft Entra come limite di sicurezza

Un tenant di Microsoft Entra offre funzionalità di gestione delle identità e degli accessi (IAM) alle applicazioni e alle risorse usate dall'organizzazione.

Un'identità è un oggetto directory che può essere autenticato e autorizzato per l'accesso a una risorsa. Gli oggetti identity esistono per identità umane e identità non umane. Per distinguere tra identità umane e non umane, le identità umane vengono definite identità e identità non umane denominate identità del carico di lavoro. Le entità non umane includono oggetti applicazione, entità servizio, identità gestite e dispositivi. La terminologia è incoerente nel settore, ma in genere un'identità del carico di lavoro è necessaria per eseguire l'autenticazione dell'entità software con un sistema.

Per distinguere tra identità umane e non umane, i termini diversi emergono nel settore IT per distinguere tra i due:

  • Identity : identità avviata descrivendo l'oggetto Active Directory (AD) e Microsoft Entra usato dagli utenti per l'autenticazione. In questa serie di articoli l'identità fa riferimento a oggetti che rappresentano gli esseri umani.

  • Identità del carico di lavoro: in Microsoft Entra ID le identità del carico di lavoro sono applicazioni, entità servizio e identità gestite. L'identità del carico di lavoro viene usata per autenticare e accedere ad altri servizi e risorse.

Per altre informazioni sulle identità del carico di lavoro, vedere Che cosa sono le identità del carico di lavoro.

Il tenant di Microsoft Entra è un limite di sicurezza delle identità sotto il controllo degli amministratori. All'interno di questo limite di sicurezza, l'amministrazione di sottoscrizioni, gruppi di gestione e gruppi di risorse può essere delegata al controllo amministrativo delle risorse di Azure. Anche se non interagisce direttamente, questi raggruppamenti dipendono dalle configurazioni a livello di tenant di criteri e impostazioni. E queste impostazioni e configurazioni sono sotto il controllo degli amministratori globali di Microsoft Entra.

Microsoft Entra ID viene usato per concedere agli oggetti che rappresentano l'accesso alle identità alle applicazioni e alle risorse di Azure. In questo senso, sia le risorse di Azure che le applicazioni che considerano attendibile Microsoft Entra ID sono risorse che possono essere gestite con Microsoft Entra ID. Nel diagramma seguente il limite del tenant di Microsoft Entra mostra gli oggetti Identity di Microsoft Entra e gli strumenti di configurazione. Sotto la directory sono riportate le risorse che usano gli oggetti Identity per la gestione delle identità e degli accessi. Seguendo le procedure consigliate, l'ambiente viene configurato con un ambiente di test per testare il corretto funzionamento di IAM.

Diagramma che mostra il limite del tenant di Microsoft Entra.

Accesso alle app che usano Microsoft Entra ID

È possibile concedere alle identità l'accesso a molti tipi di applicazioni. Alcuni esempi:

  • Servizi di produttività Microsoft come Exchange Online, Microsoft Teams e SharePoint Online

  • Servizi IT Microsoft come Azure Sentinel, Microsoft Intune e Microsoft 365 Defender ATP

  • Microsoft Strumenti di sviluppo come Azure DevOps e l'API Microsoft Graph

  • Soluzioni SaaS come Salesforce e ServiceNow

  • Applicazioni locali integrate con funzionalità di accesso ibrido, ad esempio il proxy dell'applicazione Microsoft Entra

  • Applicazioni personalizzate sviluppate internamente

Le applicazioni che usano Microsoft Entra ID richiedono la configurazione e la gestione degli oggetti directory nel tenant Microsoft Entra attendibile. Esempi di oggetti directory includono registrazioni dell'applicazione, entità servizio, gruppi ed estensioni degli attributi dello schema.

Accesso alle risorse di Azure

Gli utenti, i gruppi e gli oggetti entità servizio (identità del carico di lavoro) nel tenant di Microsoft Entra vengono concessi ruoli usando il controllo degli accessi in base al ruolo di Azure e il controllo degli accessi in base all'attributo di Azure.

  • Il controllo degli accessi in base al ruolo di Azure consente di fornire l'accesso in base al ruolo determinato dall'entità di sicurezza, dalla definizione del ruolo e dall'ambito.

  • 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 altro controllo che è possibile aggiungere facoltativamente all'assegnazione di ruolo per fornire un controllo di accesso più granulare.

È possibile accedere a risorse di Azure, gruppi di risorse, sottoscrizioni e gruppi di gestione usando questi ruoli di controllo degli accessi in base al ruolo assegnati. Ad esempio, il diagramma seguente illustra la distribuzione delle funzionalità amministrative in Microsoft Entra ID usando il controllo degli accessi in base al ruolo.

Diagramma che mostra la gerarchia dei ruoli di Microsoft Entra.

Le risorse di Azure che supportano le identità gestite consentono alle risorse di eseguire l'autenticazione, di concedere l'accesso e di assegnare ruoli ad altre risorse entro il limite del tenant di Microsoft Entra.

Le applicazioni che usano l'ID Microsoft Entra per l'accesso possono usare anche risorse di Azure, ad esempio calcolo o archiviazione nell'ambito dell'implementazione. Ad esempio, un'applicazione personalizzata eseguita in Azure e considera attendibile l'ID Microsoft Entra per l'autenticazione ha oggetti directory e risorse di Azure.

Infine, tutte le risorse di Azure nel tenant di Microsoft Entra influiscono sulle quote e sui limiti di Azure a livello di tenant.

Accesso agli oggetti directory

Come descritto nel diagramma precedente, le identità, le risorse e le relative relazioni sono rappresentate in un tenant di Microsoft Entra come oggetti directory. Esempi di oggetti directory includono utenti, gruppi, entità servizio e registrazioni dell'app.

La presenza di un set di oggetti directory nel limite del tenant di Microsoft Entra genera le funzionalità seguenti:

  • Visibilità. Le identità possono individuare o enumerare risorse, utenti, gruppi, report sull'utilizzo e log di controllo in base alle autorizzazioni. Ad esempio, un membro della directory può individuare gli utenti nella directory per le autorizzazioni utente predefinite di Microsoft Entra ID.

  • Le applicazioni possono influire sugli oggetti. Le applicazioni possono modificare gli oggetti directory tramite Microsoft Graph come parte della logica di business. Gli esempi tipici includono la lettura/impostazione degli attributi utente, l'aggiornamento del calendario dell'utente, l'invio di messaggi di posta elettronica per conto dell'utente e così via. Il consenso è necessario per consentire alle applicazioni di influire sul tenant. Gli amministratori possono fornire il consenso per tutti gli utenti. Per altre informazioni, vedere Autorizzazioni e consenso in Microsoft Identity Platform.

Nota

Prestare attenzione quando si usano le autorizzazioni dell'applicazione. Ad esempio, con Exchange Online, è necessario definire l'ambito delle autorizzazioni dell'applicazione per cassette postali e autorizzazioni specifiche.

  • Limitazioni e limiti del servizio. Il comportamento di runtime di una risorsa potrebbe attivare la limitazione per evitare un sovraccarico o una riduzione delle prestazioni del servizio. La limitazione può verificarsi a livello di applicazione, tenant o intero servizio. In genere si verifica quando un'applicazione ha un numero elevato di richieste all'interno o tra tenant. Analogamente, esistono limiti e restrizioni del servizio Microsoft Entra che potrebbero influire sul comportamento di runtime delle applicazioni.

Unità amministrative per la gestione dei ruoli

Le unità amministrative limitano le autorizzazioni di un ruolo a qualsiasi parte dell'organizzazione definita dall'utente. È possibile, ad esempio, usare unità amministrative per delegare il ruolo Amministratore di supporto tecnico agli specialisti del supporto tecnico locale, in modo che possano gestire gli utenti solo nell'area che supportano. Un'unità amministrativa è una risorsa Microsoft Entra che può essere un contenitore per altre risorse di Microsoft Entra. Un'unità amministrativa può contenere solo:

  • Utenti

  • Gruppi

  • Dispositivi

Nel diagramma seguente, le unità amministrative vengono usate per segmentare ulteriormente il tenant di Microsoft Entra in base alla struttura aziendale o organizzativa. Ciò è utile quando diverse business unit o gruppi dispongono di personale di supporto IT dedicato. Le unità amministrative possono essere usate per fornire autorizzazioni con privilegi limitate a un'unità amministrativa designata.

Diagramma che mostra le unità amministrative di Microsoft Entra.

Per altre informazioni sulle unità amministrative, vedere Unità amministrative in Microsoft Entra ID.

Motivi comuni per l'isolamento delle risorse

A volte un gruppo di risorse deve essere isolato da altre risorse per motivi di sicurezza o altri motivi, ad esempio le risorse hanno requisiti di accesso univoci. Questo è un buon caso d'uso per l'uso di unità amministrative. È necessario determinare quali utenti e entità di sicurezza devono avere accesso alle risorse e in quali ruoli. I motivi per isolare le risorse possono includere:

  • I team di sviluppo hanno bisogno della flessibilità necessaria per eseguire un'iterazione sicura durante il ciclo di vita di sviluppo software delle app. Tuttavia, lo sviluppo e il test delle app che scrivono in Microsoft Entra ID possono influire potenzialmente sul tenant di Microsoft Entra tramite operazioni di scrittura. Ecco alcuni esempi:

    • Nuove applicazioni che possono modificare il contenuto di Office 365, ad esempio siti di SharePoint, OneDrive, MS Teams e così via.

    • Applicazioni personalizzate che possono modificare i dati degli utenti con MS Graph o API simili su larga scala (ad esempio, applicazioni concesse a Directory.ReadWrite.All)

    • Script DevOps che aggiornano grandi set di oggetti come parte di un ciclo di vita della distribuzione.

    • Gli sviluppatori di app integrate di Microsoft Entra hanno bisogno della possibilità di creare oggetti utente per il test e tali oggetti utente non devono avere accesso alle risorse di produzione.

  • Risorse e applicazioni di Azure non di produzione che possono influire su altre risorse. Ad esempio, potrebbe essere necessario isolare una nuova versione beta di un'applicazione SaaS dall'istanza di produzione degli oggetti utente dell'applicazione e di produzione

  • Risorse segrete che devono essere schermate dall'individuazione, dall'enumerazione o dall'acquisizione da amministratori esistenti per motivi normativi o aziendali critici.

Configurazione in un tenant

Le impostazioni di configurazione in Microsoft Entra ID possono influire su qualsiasi risorsa nel tenant di Microsoft Entra tramite azioni di gestione mirate o a livello di tenant. Esempi di impostazioni a livello di tenant includono:

  • Identità esterne: gli amministratori identificano e controllano le identità esterne di cui è possibile effettuare il provisioning nel tenant.

    • Indica se consentire identità esterne nel tenant.

    • Da cui è possibile aggiungere identità esterne di dominio o domini.

    • Indica se gli utenti possono invitare utenti da altri tenant.

  • Località denominate: gli amministratori possono creare posizioni denominate, che possono quindi essere usate per

    • Bloccare gli accessi da posizioni specifiche.

    • Attivare criteri di accesso condizionale, ad esempio MFA.

    • Ignorare i requisiti di sicurezza

  • Opzioni self-service. Gli amministratori impostano opzioni self-service, ad esempio la reimpostazione della password self-service e creano gruppi di Microsoft 365 a livello di tenant.

L'implementazione di alcune configurazioni a livello di tenant può essere definita come ambito, purché non vengano sottoposte a override da criteri globali. Ad esempio:

  • Se il tenant è configurato per consentire le identità esterne, un amministratore delle risorse può comunque escludere tali identità dall'accesso a una risorsa.

  • Se il tenant è configurato per consentire la registrazione del dispositivo personale, un amministratore delle risorse può escludere tali dispositivi dall'accesso a risorse specifiche.

  • Se sono configurati percorsi denominati, un amministratore delle risorse può configurare i criteri consentendo o escludendo l'accesso da tali posizioni.

Motivi comuni per l'isolamento della configurazione

Le configurazioni, controllate dagli amministratori, influiscono sulle risorse. Anche se è possibile definire l'ambito di una configurazione a livello di tenant con criteri da non applicare o parzialmente a una risorsa specifica, altri non possono. Se una risorsa ha esigenze di configurazione univoche, isolarla in un tenant separato. Esempi di scenari di isolamento della configurazione includono:

  • Le risorse che presentano requisiti in conflitto con il comportamento di sicurezza o collaborazione a livello di tenant esistente. (ad esempio, tipi di autenticazione consentiti, criteri di gestione dei dispositivi, possibilità di self-service, correzione delle identità per identità esterne e così via).

  • Requisiti di conformità che rientrano nell'ambito della certificazione per l'intero ambiente, incluse tutte le risorse e il tenant di Microsoft Entra stesso, soprattutto quando tali requisiti sono in conflitto con o devono escludere altre risorse organizzative.

  • Requisiti di accesso degli utenti esterni in conflitto con i criteri di produzione o di risorse sensibili.

  • Organizzazioni che si estendono su più paesi/aree geografiche e aziende ospitate in un singolo tenant di Microsoft Entra. Ad esempio, quali impostazioni e licenze vengono usate in paesi/aree geografiche diverse o filiali aziendali.

Amministrazione in un tenant

Le identità con ruoli con privilegi nel tenant di Microsoft Entra hanno la visibilità e le autorizzazioni per eseguire le attività di configurazione descritte nelle sezioni precedenti. L'amministrazione include sia l'amministrazione di oggetti di identità, ad esempio utenti, gruppi e dispositivi, sia l'implementazione con ambito di configurazioni a livello di tenant per l'autenticazione, l'autorizzazione e così via.

Amministrazione degli oggetti directory

Gli amministratori gestiscono il modo in cui gli oggetti Identity possono accedere alle risorse e in quali circostanze. Possono anche disabilitare, eliminare o modificare gli oggetti directory in base ai propri privilegi. Gli oggetti Identity includono:

  • Le identità dell'organizzazione, ad esempio le seguenti, sono rappresentate dagli oggetti utente:

    • Amministratori

    • Utenti dell'organizzazione

    • Sviluppatori dell'organizzazione

    • Account di servizio

    • Utenti di test

  • Le identità esterne rappresentano gli utenti esterni all'organizzazione, ad esempio:

    • Partner, fornitori o fornitori di cui viene effettuato il provisioning con account locali nell'ambiente dell'organizzazione

    • Partner, fornitori o fornitori di cui viene effettuato il provisioning tramite Collaborazione B2B di Azure

  • I gruppi sono rappresentati da oggetti come:

  • I dispositivi sono rappresentati da oggetti come:

    • Dispositivi aggiunti a Microsoft Entra ibrido (computer locali sincronizzati da Active Directory locale)

    • Dispositivi aggiunti a Microsoft Entra

    • Dispositivi mobili registrati da Microsoft Entra usati dai dipendenti per accedere alle applicazioni aziendali.

    • Microsoft Entra ha registrato dispositivi di livello inferiore (legacy). Ad esempio, Windows 2012 R2.

  • Identità del carico di lavoro

    • Identità gestite

    • Entità servizio

    • Applicazioni

In un ambiente ibrido le identità vengono in genere sincronizzate dall'ambiente Active Directory locale usando Microsoft Entra Connect.

Amministrazione dei servizi di gestione delle identità

Gli amministratori con autorizzazioni appropriate possono anche gestire il modo in cui i criteri a livello di tenant vengono implementati a livello di gruppi di risorse, gruppi di sicurezza o applicazioni. Quando si valuta l'amministrazione delle risorse, tenere presente quanto segue. Ognuno può essere un motivo per riunire le risorse o isolarle.

  • Un amministratore globale può assumere il controllo di qualsiasi sottoscrizione di Azure collegata al tenant.

  • Un'identità assegnata a un ruolo di amministratore di autenticazione può richiedere ai non amministratori di ripetere la registrazione per l'autenticazione MFA o FIDO.

  • Un amministratore dell'accesso condizionale può creare criteri di accesso condizionale che richiedono agli utenti di accedere a app specifiche per farlo solo dai dispositivi di proprietà dell'organizzazione. Possono anche definire l'ambito delle configurazioni. Ad esempio, anche se nel tenant sono consentite identità esterne, possono escludere tali identità dall'accesso a una risorsa.

  • Un amministratore di applicazioni cloud può fornire il consenso alle autorizzazioni dell'applicazione per conto di tutti gli utenti.

Motivi comuni per l'isolamento amministrativo

Chi deve avere la possibilità di amministrare l'ambiente e le relative risorse? In alcuni casi, gli amministratori di un ambiente non devono avere accesso a un altro ambiente. Alcuni esempi:

  • Separazione delle responsabilità amministrative a livello di tenant per ridurre ulteriormente il rischio di errori operativi e di sicurezza che interessano le risorse critiche.

  • Normative che vincolano chi può amministrare l'ambiente in base a condizioni quali cittadinanza, residenza, livello di autorizzazione e così via. che non può essere risolto con il personale.

Considerazioni sulla sicurezza e sulle operazioni

Data l'interdipendenza tra un tenant di Microsoft Entra e le relative risorse, è fondamentale comprendere i rischi operativi e di compromissione della sicurezza e dell'errore. Se si usa un ambiente federato con account sincronizzati, una compromissione locale può causare una compromissione di Microsoft Entra ID.

  • Compromissione dell'identità: entro il limite di un tenant, a qualsiasi identità può essere assegnato qualsiasi ruolo, dato che quello che fornisce l'accesso dispone di privilegi sufficienti. Anche se l'effetto delle identità non con privilegi compromessi è in gran parte contenuto, gli amministratori compromessi possono avere implicazioni generali. Ad esempio, se un account amministratore globale di Microsoft Entra è compromesso, le risorse di Azure possono diventare compromesse. Per ridurre il rischio di compromissione dell'identità o di utenti malintenzionati, implementare l'amministrazione a livelli e assicurarsi di seguire i principi dei privilegi minimi per i ruoli di amministratore di Microsoft Entra. Analogamente, assicurarsi di creare criteri di accesso condizionale che escludano in modo specifico gli account di test e le entità servizio di test dall'accesso alle risorse all'esterno delle applicazioni di test. Per altre informazioni sulla strategia di accesso con privilegi, vedere Accesso con privilegi: Strategia.

  • Compromissione dell'ambiente federato

  • Compromissione delle risorse attendibili: le identità umane non sono l'unica considerazione sulla sicurezza. Qualsiasi componente compromesso del tenant di Microsoft Entra può influire sull'attendibilità delle risorse in base al livello di autorizzazioni a livello di tenant e risorsa. L'effetto di un componente compromesso di una risorsa di attendibilità di Microsoft Entra ID è determinato dai privilegi della risorsa; le risorse profondamente integrate con la directory per eseguire operazioni di scrittura possono avere un impatto profondo sull'intero tenant. Le indicazioni seguenti per zero trust possono contribuire a limitare l'impatto della compromissione.

  • Sviluppo di applicazioni: fasi iniziali del ciclo di vita di sviluppo per le applicazioni con privilegi di scrittura nell'ID Microsoft Entra, in cui i bug possono scrivere involontariamente modifiche agli oggetti Microsoft Entra, presentano un rischio. Seguire le procedure consigliate di Microsoft Identity Platform durante lo sviluppo per attenuare questi rischi.

  • Errore operativo: un evento imprevisto di sicurezza può verificarsi non solo a causa di attori malintenzionati, ma anche a causa di un errore operativo da parte degli amministratori tenant o dei proprietari delle risorse. Questi rischi si verificano in qualsiasi architettura. Attenuare questi rischi con la separazione dei compiti, l'amministrazione a livelli, i principi dei privilegi minimi e le procedure consigliate seguenti prima di tentare di attenuare l'uso di un tenant separato.

L'incorporamento di principi zero-trust nella strategia di progettazione di Microsoft Entra ID può aiutare a guidare la progettazione per attenuare queste considerazioni. Per altre informazioni, vedere Adottare la sicurezza proattiva con Zero Trust.

Passaggi successivi