Access Control basada en roles para aplicaciones en Exchange Online
En este artículo se le guiará 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.
En el núcleo de este sistema se encuentra 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. Vea el diagrama siguiente que ilustra el modelo de asignación de roles:
Instrucciones de configuración
Los pasos siguientes le guiarán para crear estas asignaciones de RBAC de aplicación:
- Creación de un nuevo ámbito de recursos (opcional)
- Creación de un puntero a una entidad de servicio de Microsoft Entra
- Selección del rol de aplicación adecuado
- Creación de una asignación de roles
- 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 los roles Administrador global o 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.
Nota:
Aunque hay una propiedad denominada Unidades administrativas, se recomienda usar el parámetro nativo Administración Units en una asignación de roles para evitar la creación de un ámbito como un objeto de puntero intermediario.
Entidades de servicio
Las entidades de servicio representan una instancia de una aplicación dentro del inquilino. 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 los registros de entidad de servicio dentro de los inquilinos. 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 ayudará a encontrar estos identificadores en Microsoft Entra ID:
Nota:
No use los identificadores de la página Registros de aplicaciones, ya que muestra valores diferentes. El "Id. de aplicación" de esquema rojo es AppID y el "Id. de objeto" es ServiceID.
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.
Nota:
Este método excluye los permisos que se pueden conceder por sí solos en Microsoft Entra ID.
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. Si se omite esta marca, se producirá "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 empleados 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 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
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é. Una aplicación sin llamadas entrantes a las API tendrá su restablecimiento de caché en 30 minutos, mientras que una aplicación que se usa activamente mantendrá activa su memoria caché durante hasta 2 horas.
Protocolos compatibles
- MS Graph
- EWS
Roles de aplicación admitidos
| Nombre | Protocolo | Lista de permisos | Description |
|---|---|---|---|
| Application Mail.Read | MS Graph | Mail.Read | Permite que la aplicación lea el correo electrónico en todos los buzones sin que un usuario haya iniciado sesión. |
| Application Mail.ReadBasic | MS Graph | Mail.ReadBasic | Permite que la aplicación lea el correo electrónico excepto el cuerpo, previewBody, los datos adjuntos y las propiedades extendidas de todos los buzones sin que un usuario haya iniciado sesión. |
| Application Mail.ReadWrite | MS Graph | Mail.ReadWrite | Permite que la aplicación cree, lea, actualice y elimine correo electrónico en todos los buzones sin que un usuario haya iniciado sesión. No incluye permiso para enviar correo. |
| Correo de aplicación.Send | MS Graph | Mail.Send | Permite que la aplicación envíe correos como cualquier usuario sin la necesidad de que un usuario haya iniciado sesión. |
| Buzón de correo de la aplicaciónSettings.Read | MS Graph | MailboxSettings.Read | Permite que la aplicación lea la configuración del buzón del usuario en todos los buzones sin que un usuario haya iniciado sesión. |
| Buzón de correo de la aplicaciónSettings.ReadWrite | MS Graph | MailboxSettings.ReadWrite | Permite que la aplicación cree, lea, actualice y elimine la configuración del buzón del usuario en todos los buzones sin que un usuario haya iniciado sesión. |
| Application Calendars.Read | MS Graph | Calendars.Read | Permite que la aplicación lea los eventos de todos los calendarios sin la necesidad de que un usuario haya iniciado sesión. |
| Calendarios de aplicación.ReadWrite | MS Graph | Calendars.ReadWrite | Permite que la aplicación cree, lea, actualice y elimine eventos en todos los calendarios sin la necesidad de que un usuario haya iniciado sesión. |
| Contactos de la aplicación.Read | MS Graph | Contacts.Read | Permite que la aplicación lea todos los contactos de todos los buzones sin la necesidad de que un usuario haya iniciado sesión. |
| Contactos de aplicación.ReadWrite | MS Graph | Contacts.ReadWrite | Permite que la aplicación cree, lea, actualice y elimine todos los contactos en todos los buzones sin la necesidad de que un usuario haya iniciado sesión. |
| Acceso completo al correo de la aplicación | MS Graph | Mail.ReadWrite, Mail.Send | Permite a la aplicación crear, leer, actualizar y eliminar correo electrónico en todos los buzones de correo y enviar correo como cualquier usuario sin un usuario que haya iniciado sesión. |
| Acceso completo a Exchange de aplicaciones | MS Graph | Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite, Calendars.ReadWrite, Contacts.ReadWrite | Sin un usuario que ha iniciado sesión: permite que la aplicación cree, lea, actualice y elimine correo electrónico en todos los buzones de correo y envíe correo como cualquier usuario. Permite que la aplicación cree, lea, actualice y elimine la configuración del buzón del usuario en todos los buzones de correo. Permite que la aplicación cree, lea, actualice y elimine eventos de todos los calendarios. Permite que la aplicación cree, lea, actualice y elimine todos los contactos de todos los buzones de correo. |
| EWS de aplicación. AccessAsApp | EWS | EWS. AccessAsApp | Permite que la aplicación use servicios web de Exchange con acceso completo a todos los buzones de correo. |
Es posible que observe que estos roles representan permisos de Microsoft Graph que puede dar su consentimiento en otra parte de la plataforma Azure Identity. Estos permisos tendrán 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 mediante RBAC?
Debe asegurarse de que ha quitado los permisos sin ámbito de todo el inquilino que asignó en Microsoft Entra ID. Los permisos asignados mediante RBAC 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.
¿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, se mostrarán 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 de cualquier manera que funcione bien con á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 dará lugar a ninguna interrupción del uso de la aplicación.
Pasos de migración:
- Cree un nuevo ámbito de administración, que apunte al grupo de ámbito desde la directiva de acceso a aplicaciones.
- Creación del objeto de puntero de entidad de servicio
- Asignar los permisos necesarios a la entidad de servicio en Exchange Online con la restricción del ámbito de administración
- Eliminación del consentimiento al permiso en Azure
- Eliminación de la directiva de acceso a aplicaciones
Al crear el ámbito de administración en el paso 1, usará un filtro de destinatario con el parámetro MemberOfGroupde filtro .
Este es un ejemplo: "MemberOfGroup -eq 'CN=mesga2020818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"
Nota:
Este parámetro de filtro usa el nombre distintivo del grupo, que puede encontrar mediante cmdlets de Get-Group.
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 de 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 mail.read para todo el inquilino y mail.send con ámbito, por ejemplo.
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 tiene el consentimiento de Calendar.Read 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 del ámbito de administración 1.
Acceso de MS Graph a un punto de conexión que requiere Mail.Read y Calendar.Read para la aplicación 1:
- Se produce un error en el buzón de correo de destino A:
- Buzón de destino B: se produce un error
Este punto de conexión necesita Mail.Read y 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 tiene mail.read con 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 conexión que requiere Mail.Read para la aplicación 1:
- Buzón de correo de destino A: permitir
- Buzón de destino B: permitir
Aunque Mail.Read de solo Microsoft Entra permite el acceso al buzón A, la asignación de RBAC permite el acceso a todo excepto A. En efecto, esto 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 todo el inquilino deben asignarse 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 inquilino 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.
Comentarios sobre esta característica
Los comentarios sobre esta característica se pueden compartir con exoapprbacpreview@microsoft.com.