Access Control basada en roles para aplicaciones en Exchange Online

Este artículo le guía por el uso de un control de acceso granular y escalable con ámbito de recursos: Access Control basado en roles (RBAC) para aplicaciones en Exchange Online.

Información general

RBAC para aplicaciones en Exchange Online permite a los administradores conceder permisos a una aplicación que accede de forma independiente a los datos de Exchange Online. Esta concesión se puede emparejar con un ámbito de acceso (ámbito de recurso) para especificar a qué buzones puede acceder una aplicación. Esta característica amplía el modelo de RBAC actual en Exchange Online y reemplaza las directivas de acceso a aplicaciones. Estas concesiones de permisos son independientes de las concesiones sin ámbito en Microsoft Entra ID.

El núcleo de este sistema es la configuración de asignación de roles de administración, que expresa la intención de un administrador de permitir que una entidad de seguridad acceda a los datos. En este caso, permitir que una aplicación realice algún rol en un conjunto de recursos de destino. Por ejemplo, un administrador podría configurar un sistema de reserva de salas con acceso a datos de calendario solo en regiones específicas mediante un ámbito de administración. En el diagrama siguiente se muestra el modelo de asignación de roles:

Instrucciones de configuración

Los pasos siguientes le guían para crear estas asignaciones de RBAC de aplicación:

1. Creación de un nuevo ámbito de recursos (opcional)
2. Creación de un puntero a una entidad de servicio de Microsoft Entra
3. Selección del rol de aplicación adecuado
4. Creación de una asignación de roles
5. Prueba de la nueva entidad de servicio

Requisitos

El grupo de roles Administración de la organización tiene la asignación de roles de delegación para los nuevos roles RBAC de aplicación. Debe ser miembro del grupo de roles Administración de la organización para asignar estos permisos. Como alternativa, puede usar Exchange Online RBAC para conceder asignaciones de delegación a estos roles de aplicación como considere oportuno. En Microsoft Entra ID, necesita el rol Administrador de Exchange para asignar estos permisos.

Definición del ámbito de recursos

• Ámbitos de administración: Una entidad de Exchange que representa un conjunto de buzones mediante una expresión de filtro en las propiedades de esos buzones.
• Unidades de Administración: un recurso de Microsoft Entra que puede ser un contenedor para otros recursos de Microsoft Entra que contiene solo grupos de usuarios o dispositivos. Para obtener más información, consulte Unidades administrativas en Microsoft Entra ID y Crear o eliminar unidades administrativas.

Ámbitos de administración

Los ámbitos de administración permiten a un administrador limitar un conjunto de buzones en función de las propiedades de estos objetos. Consulte la documentación del ámbito de administración para agregar, quitar y establecer. Esta es una lista de las propiedades filtrables de un ámbito de administración.

Entidades de servicio

Las entidades de servicio representan una instancia de una aplicación dentro de la organización. Debe considerar que la entidad de servicio de Exchange es un puntero a una entidad de servicio existente en Microsoft Entra ID. Las entidades de servicio no se pueden crear directamente con herramientas de Exchange Online. Microsoft Entra herramientas se usan para administrar registros de entidad de servicio dentro de las organizaciones. Exchange impide la creación de un puntero no válido y refleja las eliminaciones de entidades de servicio en Microsoft Entra ID automáticamente.

Nueva entidad de servicio

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

La captura de pantalla siguiente le ayuda a encontrar estos identificadores en Microsoft Entra ID:

Puede usar otro enfoque para buscar estos identificadores mediante Get-MgServicePrincipal.

Quitar entidad de servicio

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

Establecer entidad de servicio

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

Roles de aplicación

Los roles de aplicación son un tipo especial de rol de administración en Exchange Online, que solo se puede asignar a una aplicación. Estos roles se pueden enumerar mediante Get-ManagementRole.

Asignaciones de roles

Las asignaciones de roles de administración vinculan un ámbito de acceso de entidad de seguridad, rol y recurso personalizado. Esta asignación actúa como asignación de permisos para una entidad de servicio que realiza un rol en un ámbito.

Nueva asignación de roles

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

Establecer asignación de roles

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

Quitar asignación de roles

Para quitar una asignación de roles, consulte Eliminación de la asignación de administración.

Autorización de pruebas

Se puede usar un cmdlet de prueba para simular el comportamiento habilitado por las asignaciones de RBAC para una entidad de servicio determinada.

Al probar la autorización, puede incluir un parámetro de recurso opcional para evaluar qué permisos con ámbito se aplican a ese buzón de destino. InScope will = true or false para representar si, true que el permiso se aplica a ese buzón para esa entidad de servicio, o false que la entidad de servicio tiene ese permiso, pero no sobre ese buzón determinado. La omisión de esta marca da como resultado "No ejecutar".

Los resultados de las pruebas siempre incluyen el ámbito de recursos permitido para un permiso asignado determinado.

Prueba del acceso de la entidad de servicio

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

Ejemplos

Después de usar Connect-ExchangeOnline en PowerShell, siga estos pasos:

Ejemplo uno: Configuración del acceso de lectura del calendario para usuarios canadienses mediante un ámbito de administración

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 users" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

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

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

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

Ejemplo dos: Configuración de Mail.Read para todos los buzones de europa Administración unidad

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

Ejemplo tres: Prueba de permisos asignados a una entidad de servicio

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

Limitaciones

• Las aplicaciones no pueden convertirse en miembros de un grupo de roles.
• Los roles de aplicación solo se pueden asignar a entidades de servicio.
• Los roles de aplicación no se pueden copiar ni derivar.
• Los ámbitos de administración exclusivos no restringen el acceso a la aplicación.
• Los cambios en los permisos de la aplicación están sujetos a un mantenimiento de caché que varía entre 30 minutos y 2 horas, en función del uso reciente de la aplicación. Al probar las configuraciones, el comando de prueba omite esta memoria caché. La memoria caché de una aplicación sin llamadas entrantes a las API se restablece después de 30 minutos. La memoria caché de una aplicación activa se mantiene activa durante un máximo de 2 horas.

Protocolos compatibles

• MS Graph
• EWS

Roles de aplicación admitidos

Es posible que observe que estos roles representan permisos de Microsoft Graph a los que puede dar su consentimiento en otro lugar de la plataforma de identidad de Azure. Estos permisos tienen el mismo efecto que los permisos de Graph, excepto para estas asignaciones de roles, lo que permite el acceso con ámbito de recursos pormenorizados.

Preguntas más frecuentes

¿Por qué mi aplicación sigue teniendo acceso a buzones que no se conceden por el ámbito que usé en Exchange Online RBAC de aplicación?

Debe asegurarse de quitar los permisos sin ámbito de toda la organización asignados en Microsoft Entra ID. Los permisos asignados mediante RBAC de aplicación actúan además de las concesiones que realice en Microsoft Entra ID. Microsoft Entra permisos solo se pueden restringir mediante directivas de acceso a aplicaciones. Es decir, los permisos asignados son una operación de unión en los permisos de Microsoft Entra ID y los permisos asignados en Exchange Online RBAC. Cada autoridad puede actuar de forma independiente.

Por ejemplo, si la entidad de servicio ha Mail.Read concedido en Microsoft Entra ID y configura un permiso con ámbito Mail.Read de recursos en RBAC de aplicación, es importante que quite la asignación de de Mail.Read Microsoft Entra ID. De lo contrario, la unión de una concesión sin ámbito Mail.Read de Microsoft Entra y una concesión con Mail.Read ámbito de recursos en RBAC de aplicación no da lugar a un ámbito de recursos efectivo.

¿Cómo puedo ver y modificar todos los permisos de aplicación en una interfaz?

Para asegurarse de que los administradores tienen una vista consolidada de los permisos de aplicación, exponemos estos permisos concedidos en Exchange Online en una experiencia de administrador Microsoft Entra. Esta característica está próximamente, manténgase atento.

¿Cómo migrar de directivas de acceso de aplicaciones a RBAC para aplicaciones?

Con las directivas de acceso a aplicaciones, tiene una entidad de servicio, el consentimiento de permisos en Azure y una directiva asociada a una entidad de servicio en Exchange Online. Aunque puede reestructurar el mecanismo de ámbito mediante ámbitos de administración de Exchange o unidades administrativas, estas son algunas instrucciones sobre la reutilización de grupos en una directiva de acceso a aplicaciones como ámbito de la concesión de RBAC para aplicaciones. Este proceso no da lugar a ninguna interrupción del uso de la aplicación.

Pasos de migración:

1. Cree un nuevo ámbito de administración, que apunte al grupo de ámbito desde la directiva de acceso a aplicaciones.

2. Cree el objeto de puntero de entidad de servicio.

3. Asigne los permisos necesarios a la entidad de servicio en Exchange Online con la restricción de ámbito de administración.

4. Quite el consentimiento al permiso en Azure.

5. Quite la directiva de acceso a la aplicación.

   Al crear el ámbito de administración en el paso 1, se usa un filtro de destinatario con el parámetro MemberOfGroupde filtro . Aquí le mostramos un ejemplo:

   "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

Limitaciones:

• Los miembros del grupo anidados se consideran fuera del ámbito. Solo la pertenencia directa a grupos da como resultado que el miembro se considere en el ámbito de la autorización.
• se admiten Grupos de Microsoft 365, grupos de seguridad Mail-Enabled y listas de distribución.

¿Cómo funciona RBAC para aplicaciones junto con las directivas de acceso a aplicaciones?

Compatibilidad con la directiva de acceso a aplicaciones:

RBAC para aplicaciones reemplaza las directivas de acceso a aplicaciones.

La interoperabilidad de autorización se puede describir de la siguiente manera:

• Las directivas de acceso a aplicaciones restringen SOLO los permisos asignados en Microsoft Entra ID.

• RBAC for Applications ofrece una expresión alternativa de autorización con un ámbito de recursos asociado.

• Una aplicación puede tener permisos con consentimiento de Microsoft Entra y asignaciones de RBAC. Esperamos este caso cuando una aplicación tiene (por ejemplo) toda la organización Mail.Read y tiene ámbito Mail.Send.

• Los consentimientos de permisos son aditivos.

Ejemplo uno: consentimientos de dos sistemas:

• Una aplicación tiene Mail.Read en Microsoft Entra ID.
• Esta aplicación tiene como ámbito el grupo de seguridad 1 habilitado para correo mediante una directiva de acceso a aplicaciones.
• La misma aplicación ha Calendar.Read dado su consentimiento para el ámbito de administración 1 en RBAC para aplicaciones.
• El buzón A está en el grupo de seguridad 1 habilitado para correo.
• El buzón B está en el ámbito de Ámbito de administración 1.

Acceso de MS Graph a un punto de conexión que requiere tanto Mail.Read como Calendar.Read para la aplicación 1:

• Se produce un error en el buzón de correo de destino A.
• Se produce un error en el buzón B de destino.

Este punto de conexión necesita tanto Mail.Read como Calendar.Read. Aunque la aplicación tiene estos permisos individualmente en dos buzones de correo independientes, no tiene ambos permisos en un buzón.

Ejemplo dos: asignación del mismo permiso dos veces:

• Una aplicación tiene Mail.Read en Microsoft Entra ID.
• Esta aplicación tiene como ámbito el grupo de seguridad 1 habilitado para correo mediante una directiva de acceso a aplicaciones.
• La misma aplicación ha Mail.Read dado su consentimiento para el ámbito de administración 1 mediante RBAC para aplicaciones.
• El buzón A está en el grupo de seguridad 1 habilitado para correo.
• Ámbito de administración 1 permite el acceso a todos los buzones excepto al buzón A (según algún filtro como Alias -ne mbxa).

Acceso de MS Graph a un punto de Mail.Read conexión que requiere para la aplicación 1:

• Buzón de correo de destino A: permitir.
• Buzón B de destino: permitir.

Mail.Read Aunque desde solo Microsoft Entra permite el acceso al buzón A, la asignación de RBAC permite el acceso a todo excepto A. De hecho, esta asignación permite el acceso a todo porque "A y No A" significa todo.

Aunque hemos descrito estos casos perimetrales para la integridad, no esperamos que las directivas de acceso a aplicaciones se usen normalmente con RBAC para aplicaciones. Los permisos de toda la organización se deben asignar en Microsoft Entra ID, mientras que los permisos con ámbito de recursos se deben conceder mediante RBAC para aplicaciones.

¿Cuántas aplicaciones admite RBAC para aplicaciones?

Puede tener hasta 10 000 aplicaciones por organización mediante RBAC para aplicaciones. Háganos saber si este límite supone un problema para usted. Hemos creado RBAC para aplicaciones de una manera altamente escalable para satisfacer las necesidades de nuestros clientes más grandes.

¿Por qué no funciona la detección automática?

Actualmente, no se puede acceder al servicio Detección automática cuando se usan roles de aplicación de RBAC.

Si elimino una entidad de servicio en Microsoft Entra ¿qué ocurre en Exchange?

Las entidades de servicio eliminadas en Microsoft Entra también se quitan automáticamente en Exchange. Esta eliminación elimina las asignaciones realizadas a estas entidades de servicio, pero deja sin afectados los ámbitos de administración.

Comentarios sobre esta característica

Los comentarios sobre esta característica se pueden compartir con exoapprbacpreview@microsoft.com.