Compartir a través de


Control de acceso basado en rol 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: Control de acceso basado en rol (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 RBAC actual en Exchange Online y reemplaza a las directivas de acceso a aplicaciones.

Nota:

No se puede acceder al servicio Detección automática cuando se usan roles de aplicación de RBAC. Si necesita realizar solicitudes de detección automática en Exchange Online, use los permisos de Microsoft Entra ID con la directiva de acceso a aplicaciones para limitar el acceso al buzón.

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:

Diagrama del modelo de asignación de roles con ejemplo.

Instrucciones de configuración

Los pasos siguientes le guiarán 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 RBAC de Exchange Online 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

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 Unidades de administración nativo 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 las herramientas de Exchange Online. Las herramientas de Microsoft Entra 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 automáticamente las eliminaciones de entidades de servicio en el identificador de Microsoft Entra.

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:

Captura de pantalla de la página de aplicaciones de Microsoft Entra Enterprise.

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 el identificador de Microsoft Entra.

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 la unidad de administración de Europa

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 Descripción
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. Los permisos de Microsoft Entra 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 de 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:

  1. Cree un nuevo ámbito de administración, que apunte al grupo de ámbito desde la directiva de acceso a aplicaciones.
  2. Creación del objeto de puntero de entidad de servicio
  3. Asignar los permisos necesarios a la entidad de servicio en Exchange Online con la restricción de ámbito de administración
  4. Eliminación del consentimiento al permiso en Azure
  5. 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 los grupos de Microsoft 365, los grupos de seguridad Mail-Enabled y las 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 Microsoft Entra solo 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.