Controllo degli accessi in base al ruolo per le applicazioni in Exchange Online

Questo articolo illustra come usare il controllo degli accessi granulare e scalabile con ambito risorsa: controllo degli accessi in base al ruolo (RBAC) per le applicazioni in Exchange Online.

Panoramica

Il controllo degli accessi in base al ruolo per le applicazioni in Exchange Online consente agli amministratori di concedere le autorizzazioni a un'applicazione che accede in modo indipendente ai dati in Exchange Online. Questa concessione può essere associata a un ambito di accesso (ambito della risorsa) per specificare le cassette postali a cui un'app può accedere. Questa funzionalità estende il modello di controllo degli accessi in base al ruolo corrente in Exchange Online e sostituisce i criteri di accesso alle applicazioni.

Alla base di questo sistema c'è la configurazione dell'assegnazione del ruolo di gestione, che esprime la finalità di un amministratore di consentire a un'entità di accedere ai dati. In questo caso, consentendo a un'app di svolgere un ruolo in un set di risorse di destinazione. Ad esempio, un amministratore potrebbe configurare un sistema di prenotazione delle sale con accesso ai dati del calendario solo in aree specifiche usando un ambito di gestione. Vedere il diagramma seguente che illustra il modello di assegnazione di ruolo:

Istruzioni di configurazione

I passaggi seguenti guideranno la creazione di queste assegnazioni del controllo degli accessi in base al ruolo dell'applicazione:

1. Creare un nuovo ambito di risorsa (facoltativo)
2. Creare un puntatore a un'entità servizio Microsoft Entra
3. Selezionare il ruolo dell'applicazione appropriato
4. Creare un'assegnazione di nuovo ruolo
5. Testare la nuova entità servizio

Requisiti

Il gruppo di ruoli Gestione organizzazione ha l'assegnazione del ruolo di delega per i nuovi ruoli controllo degli accessi in base al ruolo dell'applicazione. Per assegnare queste autorizzazioni, è necessario essere membri del gruppo di ruoli Gestione organizzazione. In alternativa, è possibile usare il controllo degli accessi in base al ruolo di Exchange Online per concedere assegnazioni di delega a questi ruoli dell'applicazione nel modo più adatto. In Microsoft Entra ID è necessario il ruolo di amministratore di Exchange per assegnare queste autorizzazioni.

Definire l'ambito della risorsa

• Ambiti di gestione:Un'entità di Exchange che rappresenta un set di cassette postali usando un'espressione di filtro sulle proprietà di tali cassette postali.
• Unità amministrative: Una risorsa di Microsoft Entra che può essere un contenitore per altre risorse di Microsoft Entra che contiene solo gruppi di utenti o dispositivi. Per altre informazioni, vedere Unità amministrative in Microsoft Entra ID e Creare o eliminare unità amministrative.

Ambiti di gestione

Gli ambiti di gestione consentono a un amministratore di definire l'ambito di un set di cassette postali in base alle proprietà di questi oggetti. Per aggiungere, rimuovere, impostare, fare riferimento alla documentazione relativa all'ambito di gestione. Ecco un elenco delle proprietà filtrabili in un ambito di gestione.

Entità servizio

Le entità servizio rappresentano un'istanza di un'applicazione all'interno del tenant. È consigliabile considerare l'entità servizio in Exchange come un puntatore a un'entità servizio esistente nell'ID di Microsoft Entra. Le entità servizio non possono essere create direttamente tramite gli strumenti di Exchange Online. Gli strumenti di Microsoft Entra vengono usati per gestire le registrazioni dell'entità servizio all'interno dei tenant. Exchange impedisce la creazione di un puntatore non valido e riflette automaticamente eventuali eliminazioni di entità servizio in Microsoft Entra ID.

Nuova entità servizio

New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>

Lo screenshot seguente consente di trovare questi ID in Microsoft Entra ID:The following screenshot will help you find these ID in Microsoft Entra ID:

È possibile usare un altro approccio per trovare questi ID usando Get-MgServicePrincipal.

Rimuovere l'entità servizio

Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName> 

Impostare l'entità servizio

Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>

Ruoli applicazione

I ruoli dell'applicazione sono un tipo speciale di ruolo di gestione in Exchange Online, che è assegnabile solo a un'applicazione. Questi ruoli possono essere enumerati usando Get-ManagementRole.

Assegnazioni di ruolo

Le assegnazioni di ruolo di gestione uniscono un'entità, un ruolo e un ambito di accesso personalizzato alle risorse. Questa assegnazione funge da assegnazione di autorizzazioni per un'entità servizio che esegue un ruolo in un ambito.

Nuova assegnazione di ruolo

New-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Impostare l'assegnazione di ruolo

Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

Rimuovere l'assegnazione di ruolo

Per rimuovere un'assegnazione di ruolo, vedere Rimuovere l'assegnazione di gestione.

Test dell'autorizzazione

È possibile usare un cmdlet di test per simulare il comportamento abilitato dalle assegnazioni del controllo degli accessi in base al ruolo per una particolare entità servizio.

Durante il test dell'autorizzazione, è possibile includere un parametro di risorsa facoltativo per valutare quali autorizzazioni con ambito si applicano a tale cassetta postale di destinazione. InScope will = true or false per rappresentare se, true che l'autorizzazione si applica a tale cassetta postale per l'entità servizio o false tale entità servizio dispone di tale autorizzazione, ma non su quella particolare cassetta postale. Se si omette questo flag, verrà restituito "Not Run".

I risultati dei test includono sempre l'ambito della risorsa consentito per una determinata autorizzazione assegnata.

Testare l'accesso all'entità servizio

Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>

Esempi

Dopo aver usato Connect-ExchangeOnline in PowerShell, seguire questa procedura:

Esempio uno: Configurazione dell'accesso in lettura del calendario per i dipendenti canadesi tramite un ambito di gestione

New-ServicePrincipal -AppId 71487acd-ec93-476d-bd0e-6c8b31831053 -ObjectId 6233fba6-0198-4277-892f-9275bf728bcc -DisplayName "example"

DisplayName   ObjectId                              AppId
-----------   ---------                              -----
example       6233fba6-0198-4277-892f-9275bf728bcc   71487acd-ec93-476d-bd0e-6c8b3183105

New-ManagementScope -Name "Canadian employees" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

Name                 ScopeRestrictionType      Exclusive      RecipientRoot          RecipientFilter 
----                 --------------------      ---------      -------------          --------------- 
Canadian employees    RecipientScope            False                                CustomAttribute1 -eq '012332'

New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian Employees"

Name                      Role                 RoleAssigneeName       RoleAssigneeType        AssignmentMethod
----                      ----                 ----------------       ----------------        ----------------
Application Calendar...   Application Ca...    6233fba6-0198-...      ServicePrincipal        Direct

Esempio due: Configurazione di Mail.Read per tutte le cassette postali europa admin unit

New-ServicePrincipal -AppId eb19847b-5563-42ea-b719-ea47cb0cf4b3 -ObjectId 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -DisplayName "example"

DisplayName    ObjectId                                  AppId
-----------    ---------                                  -----
example        59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36       eb19847b-5563-42ea-b719-ea47cb0cf4b3

New-ManagementRoleAssignment -App 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -Role "Application Mail.Read" -RecipientAdministrativeUnitScope 4d819ce9-9257-44d7-af20-68a49e6697f4

Name                         Role                RoleAssigneeName         RoleAssigneeType             AssignmentMethod
----                         ----                ----------------          ----------------            ----------------
Application Mail.Rea...      Application Ma...   59b7c6cb-58d3-...         ServicePrincipal            Direct

Esempio tre: Test delle autorizzazioni assegnate a un'entità servizio

Test-ServicePrincipalAuthorization -Resource b -Identity "DemoB" | Format-Table

RoleName                      GrantedPermissions          AllowedResourceScope        ScopeType                 InScope 
--------                      ------------------          --------------------        ---------                 ------
Application Mail.Read         Mail.Read                   Scope-MESGaDN                CustomRecipientScope     False 
Application Calendars.Read    Calendars.Read              Scope-DL1                    CustomRecipientScope     False 
Application Contacts.Read     Contacts.Read               Scope-MESGa                  CustomRecipientScope     False 

Limitazioni

• Le applicazioni non possono diventare membri di un gruppo di ruoli.
• I ruoli dell'applicazione possono essere assegnati solo alle entità servizio.
• I ruoli dell'applicazione non possono essere copiati o derivati.
• Gli ambiti di gestione esclusivi non limitano l'accesso alle app.
• Le modifiche alle autorizzazioni dell'app sono soggette a manutenzione della cache che varia tra 30 minuti e 2 ore a seconda dell'utilizzo recente dell'app. Quando si testano le configurazioni, il comando di test ignora questa cache. Un'app senza chiamate in ingresso alle API avrà la reimpostazione della cache in 30 minuti, mentre un'app usata attivamente manterrà attiva la cache per un massimo di 2 ore.

Protocolli supportati

• MS Graph
• EWS

Ruoli dell'applicazione supportati

Si potrebbe notare che questi ruoli rappresentano le autorizzazioni di Microsoft Graph che è possibile concedere altrove nella piattaforma Azure Identity. Queste autorizzazioni avranno lo stesso effetto di quelle autorizzazioni Graph, ad eccezione di queste assegnazioni di ruolo che consentono l'accesso granulare con ambito risorsa.

Domande frequenti

Perché l'applicazione ha ancora accesso alle cassette postali a cui non viene concesso il controllo degli accessi in base al ruolo?

È necessario assicurarsi di aver rimosso le autorizzazioni senza ambito a livello di tenant assegnate in Microsoft Entra ID. Le autorizzazioni assegnate tramite il controllo degli accessi in base al ruolo agiscono oltre alle concessioni effettuate in Microsoft Entra ID. Le autorizzazioni di Microsoft Entra possono essere vincolate solo usando i criteri di accesso alle applicazioni.

Come è possibile visualizzare e modificare tutte le autorizzazioni dell'applicazione in un'unica interfaccia?

Per garantire agli amministratori una visualizzazione consolidata delle autorizzazioni per le app, verranno visualizzate queste autorizzazioni concesse in Exchange Online in un'esperienza di amministratore di Microsoft Entra. Questa funzionalità è imminente e resta aggiornata.

Come eseguire la migrazione dai criteri di accesso alle applicazioni al controllo degli accessi in base al ruolo per le applicazioni?

Con i criteri di accesso alle applicazioni sono disponibili un'entità servizio, il consenso per le autorizzazioni in Azure e un criterio associato a un'entità servizio in Exchange Online. Anche se è possibile ristrutturare il meccanismo di ambito in qualsiasi modo che funzioni correttamente usando gli ambiti di gestione di Exchange o le unità amministrative, ecco alcune indicazioni sul riutilizzo dei gruppi in un criterio di accesso alle app come ambito per la concessione del controllo degli accessi in base al ruolo per le applicazioni. Questo processo non comporterà alcuna interruzione dell'uso per l'app.

Procedura di migrazione:

1. Creare un nuovo ambito di gestione, che punta al gruppo di ambito dai criteri di accesso alle applicazioni
2. Creare l'oggetto puntatore dell'entità servizio
3. Assegnare le autorizzazioni necessarie all'entità servizio in Exchange Online con la restrizione dell'ambito di gestione
4. Rimuovere il consenso all'autorizzazione in Azure
5. Rimuovere i criteri di accesso alle applicazioni

Quando si crea l'ambito di gestione nel passaggio 1, si userà un filtro destinatario con il parametro MemberOfGroupdi filtro . Ecco un esempio: "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

Limitazioni:

• I membri del gruppo annidati vengono considerati fuori ambito. Solo l'appartenenza diretta ai gruppi determina che il membro venga considerato nell'ambito dell'autorizzazione.
• Sono supportati i gruppi di Microsoft 365, i gruppi di sicurezza Mail-Enabled e le liste di distribuzione.

Come funziona il controllo degli accessi in base al ruolo per le applicazioni insieme ai criteri di accesso alle applicazioni?

Compatibilità con i criteri di accesso alle app

Il controllo degli accessi in base al ruolo per le applicazioni sostituisce i criteri di accesso alle applicazioni.

L'interoperabilità dell'autorizzazione può essere descritta come segue:

• I criteri di accesso alle applicazioni vincolano SOLO le autorizzazioni assegnate in Microsoft Entra ID.

• Il controllo degli accessi in base al ruolo per le applicazioni offre un'espressione alternativa di autorizzazione con un ambito di risorse associato.

• Un'app può avere sia le autorizzazioni concesse da Microsoft Entra che le assegnazioni di controllo degli accessi in base al ruolo. Si prevede questo caso quando un'app ha ad esempio Mail.Read e Mail.Send con ambito tenant.

• I consensi delle autorizzazioni sono additivi.

Esempio 1: consenso da 2 sistemi

• Un'app ha Mail.Read in Microsoft Entra ID
• Questa app ha come ambito il gruppo di sicurezza abilitato alla posta elettronica 1 usando un criterio di accesso alle applicazioni
• La stessa app ha il consenso Calendar.Read per l'ambito di gestione 1 nel controllo degli accessi in base al ruolo per le applicazioni
• La cassetta postale A è nel gruppo di sicurezza abilitato alla posta elettronica 1
• La cassetta postale B è nell'ambito dell'ambito di gestione 1

Accesso di MS Graph a un endpoint che richiede sia Mail.Read che Calendar.Read per l'app 1:

• Destinazione della cassetta postale A: errore
• Destinazione della cassetta postale B: errore

Questo endpoint richiede sia Mail.Read che Calendar.Read. Anche se l'app dispone di queste autorizzazioni singolarmente per due cassette postali separate, non dispone di entrambe le autorizzazioni per una cassetta postale.

Esempio due: assegnazione della stessa autorizzazione due volte

• Un'app ha Mail.Read in Microsoft Entra ID
• Questa app ha come ambito il gruppo di sicurezza abilitato alla posta elettronica 1 usando un criterio di accesso alle applicazioni
• La stessa app ha il consenso mail.read per l'ambito di gestione 1 usando il controllo degli accessi in base al ruolo per le applicazioni
• La cassetta postale A è nel gruppo di sicurezza abilitato alla posta elettronica 1
• L'ambito di gestione 1 consente l'accesso a ogni cassetta postale ad eccezione della cassetta postale A (in base a un filtro come 'Alias -ne mbxa')

Accesso di MS Graph a un endpoint che richiede Mail.Read per l'app 1:

• Destinazione cassetta postale A: consenti
• Destinazione cassetta postale B: consenti

Anche se Mail.Read da Microsoft Entra-only consente l'accesso alla cassetta postale A, l'assegnazione del controllo degli accessi in base al ruolo consente l'accesso a tutti gli elementi tranne A. In effetti, questo consente l'accesso a tutto perché "A e non A" significa tutto.

Anche se questi casi perimetrali sono stati descritti per completezza, non è previsto che i criteri di accesso alle applicazioni vengano in genere usati con il controllo degli accessi in base al ruolo per le applicazioni. Le autorizzazioni a livello di tenant devono essere assegnate nell'ID Microsoft Entra, mentre le autorizzazioni con ambito risorsa devono essere concesse usando il controllo degli accessi in base al ruolo per le applicazioni.

Quante applicazioni sono supportate dal controllo degli accessi in base al ruolo per le applicazioni?

È possibile avere fino a 10.000 applicazioni per tenant usando il controllo degli accessi in base al ruolo per le applicazioni. Comunicaci se questo limite rappresenta un problema per te. Il controllo degli accessi in base al ruolo per le applicazioni è stato creato in modo altamente scalabile per soddisfare le esigenze dei clienti più grandi.

Commenti e suggerimenti su questa funzionalità

Il feedback su questa funzionalità può essere condiviso con exoapprbacpreview@microsoft.com.