Control de Access Control basado en roles para aplicaciones en Exchange Online

Este artículo le guía por el uso del control de acceso granular, escalable y basado en recursos: Role Based Access Control (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 independientemente a los datos en Exchange Online. Esta concesión se puede emparejar con un ámbito de acceso (ámbito de recursos) para especificar a qué buzones puede tener acceso una aplicación. Esta característica amplía el modelo RBAC actual de 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 desempeñe algún rol en un conjunto de recursos de destino. Por ejemplo, un administrador puede configurar un sistema de reserva de salas con acceso a los datos del 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 guiarán para crear estas asignaciones RBAC de aplicación:

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

Requisitos

El grupo de roles de 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 rol Administración de la organización para asignar estos permisos. Como alternativa, puede usar RBAC de Exchange Online para otorgar asignaciones delegadas a estos roles de aplicación como considere oportuno. En Microsoft Entra ID, necesita el rol de administrador de Exchange para asignar estos permisos.

Definir el ámbito de recursos

• Ámbitos de administración: Entidad de Exchange que representa un conjunto de buzones de correo mediante una expresión de filtro en las propiedades de dichos buzones.
• Unidades de administración: recurso de Microsoft Entra que puede ser un contenedor para otros recursos de Microsoft Entra que solo contiene usuarios, grupos 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 establecer el ámbito de un conjunto de buzones en función de las propiedades de estos objetos. Consulte la documentación del ámbito de administración para agregar, quitary establecer. Esta es una lista de las propiedades filtrables en un ámbito de administración.

Entidades de servicio

Las entidades de servicio representan una instancia de una aplicación dentro de su 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 las herramientas de Exchange Online. Las herramientas de Microsoft Entra se usan para administrar los registros de entidades de servicio dentro de las organizaciones. Exchange evita la creación de punteros no válidos y refleja automáticamente cualquier eliminación de entidades de servicio en Microsoft Entra ID.

Nueva entidad de servicio

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

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

Puede usar otro enfoque para encontrar 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 la asignación de permisos para una entidad de servicio que desempeña 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 Quitar asignación de administración.

Autorización de prueba

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

Al probar la autorización, puede incluir un parámetro de recurso opcional para evaluar qué permisos de ámbito se aplican a ese buzón de destino. InScope will = true or false para representar si, verdadero, que ese permiso se aplica a ese buzón para esa entidad de servicio, o falso que la entidad de servicio tiene ese permiso, pero no sobre ese buzón en particular. Si se omite esta marca, se obtiene el mensaje "No ejecutado".

Los resultados de la prueba siempre incluyen el ámbito de recurso permitido para un permiso asignado concreto.

Probar el acceso a la entidad de servicio

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

Ejemplos

Después de utilizar 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

Segundo ejemplo: 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

Tercer ejemplo: Prueba de los 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 las aplicaciones están sujetos a un mantenimiento de caché que varía entre 30 minutos y 2 horas según el uso reciente de la aplicación. Cuando prueba configuraciones, el comando test omite esta 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 que puede aceptar en otra parte 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 un acceso granular con ámbito de recursos.

Preguntas más frecuentes

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

Debe asegurarse de haber eliminado los permisos sin ámbito para toda la organización asignados en Microsoft Entra ID. Los permisos asignados mediante la aplicación 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. En otras palabras, 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 de ámbito Mail.Read de recurso en la aplicación RBAC, es importante que quite la asignación de Mail.Read de Microsoft Entra ID. De lo contrario, la unión de una concesión sin ámbito Mail.Read de Microsoft Entra y una concesión de ámbito Mail.Read de recursos en la aplicación RBAC no da como resultado ningún ámbito de recursos efectivo.

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

Para garantizar que los administradores tengan una vista consolidada de los permisos de aplicación, exponemos estos permisos concedidos en Exchange Online en una experiencia de administración de Microsoft Entra. Esta característica está próximamente, estad atentos.

¿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, 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, aquí encontrará algunas instrucciones sobre cómo reutilizar grupos en una directiva de acceso a aplicaciones como ámbito para la concesión de RBAC para aplicaciones. Este proceso no provoca ninguna interrupción del uso de la aplicación.

Pasos de migración:

1. Cree un nuevo ámbito de administración, que señale al grupo de ámbito desde la Directiva de acceso a aplicaciones.

2. Cree el objeto 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. Quitar la directiva de acceso a aplicaciones.

   Al crear el ámbito de administración en el paso 1, usa un filtro de destinatarios 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 anidado se consideran fuera del ámbito. Solo la pertenencia directa al grupo hace que el miembro sea considerado en el ámbito de la autorización.
• Grupos de Microsoft 365, Mail-Enabled grupos de seguridad 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 las aplicaciones.

La interoperabilidad de la 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 para aplicaciones ofrece una expresión alternativa de autorización con un ámbito de recurso asociado.

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

• Los consentimientos de permisos son aditivos.

Ejemplo uno: consentimientos de 2 sistemas:

• Una aplicación tiene Mail.Read en Microsoft Entra ID.
• Esta aplicación se limita al grupo de seguridad habilitado para correo 1 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 se encuentra 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 tanto Mail.Read como Calendar.Read Aplicación 1:

• Destinatarios del buzón A: produce un error.
• Dirigirse al buzón B: falla.

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

Segundo ejemplo: Asignar el mismo permiso dos veces:

• Una aplicación tiene Mail.Read en Microsoft Entra ID.
• Esta aplicación se limita al grupo de seguridad habilitado para correo 1 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 se encuentra en el grupo de seguridad 1 habilitado para correo.
• El á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 destino A: permitir.
• Buzón de destino B: permitir.

Mientras que el Mail.Read de Microsoft Entra permite el acceso al buzón A, la asignación RBAC permite el acceso a todo excepto a A. En efecto, esta asignación permite el acceso a todo porque "A y No A" significa todo.

Aunque hemos descrito estos casos extremos para completar, no esperamos que las directivas de acceso a aplicaciones se utilicen normalmente con RBAC para aplicaciones. Los permisos para toda la organización deben asignarse en Microsoft Entra ID, mientras que los permisos de ámbito de recursos deben concederse mediante RBAC para aplicaciones.

¿Cuántas aplicaciones admite RBAC para Aplicaciones?

Puede tener hasta 10 000 aplicaciones por organización con RBAC para Aplicaciones. Indíquenos si este límite supone algún problema para usted. Construimos RBAC for Applications 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 de detección automática cuando se usan los roles de aplicación RBAC.

Si elimino una entidad de servicio en Microsoft Entra, ¿qué sucede 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 no afecta a los ámbitos de administración.

Comentarios sobre esta característica

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