Paquetes de acceso Entra Entitlement Management: piloto gobernado

¿Qué son los paquetes de acceso Entra Entitlement Management?

Los paquetes de acceso Entra Entitlement Management convierten una tarea empresarial definida en una solicitud de acceso gobernada. Un primer paquete útil responde a preguntas prácticas: ¿qué recursos necesita esta tarea, quién es responsable de la decisión, quién puede solicitar acceso y cuándo debe terminar la asignación? Empiece con un proyecto cuyos propietarios de recursos puedan explicar esas respuestas y ayudar a comprobarlas.

Microsoft describe un paquete como un conjunto de acceso a recursos regido por directivas, dentro de un catálogo. Los grupos, las aplicaciones empresariales y los sitios de SharePoint Online son recursos compatibles. Las directivas definen la elegibilidad, la aprobación y la duración de la asignación. Los catálogos delimitan la delegación. Los paquetes pueden servir a empleados o usuarios externos. Estos conceptos proceden de la introducción a Entitlement Management de Microsoft Learn.

La ausencia de un paquete es una observación de configuración que debe investigarse. No demuestra que su organización carezca de gobernanza de acceso. Puede que ya tenga un servicio documentado de solicitudes, aprobación por los propietarios de recursos y procedimientos fiables de retirada. Evalúe ese proceso frente a la necesidad empresarial antes de decidir si Entitlement Management lo mejoraría.

Cómo funciona: delimitar el piloto gobernado

Considere un equipo de proyecto que necesita un rol específico de aplicación y acceso a los documentos del proyecto. Este es un escenario ilustrativo de planificación, no un hallazgo medido en un tenant. Anote los usuarios previstos, los recursos, los niveles de permisos, el aprobador y la condición de finalización antes de abrir el asistente. Pida a cada propietario de recurso que confirme que el acceso propuesto es suficiente para la tarea y no es más amplio de lo necesario.

Mantenga el piloto lo bastante acotado para poder explicar cada permiso incluido. Evite agrupar accesos sin relación simplemente porque esos recursos aparecen en el mismo departamento. Registre a la persona responsable de mantener el paquete y a la responsable de cada recurso. Esas responsabilidades pueden corresponder a personas distintas; la coordinación importa cuando cambia un recurso o termina un proyecto.

La introducción sitúa expresamente los paquetes junto a otros mecanismos de asignación. Encajan en tareas limitadas en el tiempo, accesos sujetos a aprobación y escenarios de colaboración; no sustituyen todos los métodos de asignación existentes. Compare su piloto con la pertenencia ordinaria a grupos y el proceso actual de solicitudes de servicio. Elija el mecanismo que permita al propietario aprobar el acceso adecuado y demostrar su retirada. Microsoft Learn: cuándo usar paquetes de acceso.

La pertenencia dinámica y el acceso gobernado también responden a preguntas operativas distintas. La selección basada en atributos puede identificar una población, mientras que una directiva de paquete aborda cómo recibe esa población un derecho concreto. Nuestro artículo sobre la retirada del operador memberOf trata la pertenencia dinámica y las dependencias de la asignación automática de Entitlement Management. Úselo para revisar la lógica de asignación existente antes de diseñar un piloto basado en solicitudes, sin suponer que una migración de reglas de grupo aporta pruebas de aprobación o expiración.

Comprobar las licencias y los requisitos administrativos

Los requisitos de licencia de la introducción de Learn mencionan Microsoft Entra ID Governance o Microsoft Entra Suite para los usuarios de la organización e indican que algunas capacidades pueden funcionar con Microsoft Entra ID P2. Trátelo como una comprobación de licencias por funcionalidad, en lugar de una instrucción universal para adquirir una suscripción determinada.

La tabla de fundamentos de licencias de Governance incluye las solicitudes de autoservicio de usuarios, los grupos, las aplicaciones, los sitios de SharePoint, los responsables jerárquicos o aprobadores específicos y la expiración de asignaciones bajo P2, además de Governance y Suite. En esa tabla, las directivas de asignación automática y los patrocinadores del perfil de usuario como aprobadores requieren Governance o Suite. Los productos Governance también tienen suscripciones previas obligatorias; la gobernanza de invitados tiene consideraciones de facturación separadas. Verifique las capacidades previstas y la población elegible frente a la documentación actual de Learn antes de habilitar el piloto. No deduzca el derecho de uso de la mera presencia de una licencia en algún lugar del tenant.

Centre su primera prueba en usuarios humanos y recursos ordinarios del proyecto. Si después añade funciones avanzadas, revise las licencias y los permisos delegados en vez de conservar las suposiciones del piloto. Registre la decisión de licencias junto al diseño del paquete para que el siguiente responsable comprenda qué decisiones fueron deliberadas.

Detección: establecer si faltan paquetes

En el Microsoft Entra admin center, examine ID Governance > Entitlement management > Access package, la ruta documentada en la guía de creación. Confirme el directorio y su visibilidad antes de interpretar una vista vacía. Guarde la fecha de observación, el observador y el alcance junto al inventario.

Para un inventario mediante API, Microsoft documenta la siguiente solicitud en List accessPackages:

GET https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages

La API devuelve los paquetes que el llamador puede leer entre los catálogos. La tabla de permisos indica EntitlementManagement.Read.All como el permiso OAuth de menor privilegio para acceso delegado y de aplicación; los llamadores delegados también necesitan un rol compatible. Para llamadores que usan solo una aplicación, Microsoft también admite asignar un rol adecuado en lugar de ese permiso de aplicación; Catalog reader es una opción menos privilegiada. El acceso específico a un catálogo puede limitar lo que ve el llamador. Por tanto, una respuesta vacía correcta solo respalda una conclusión de ausencia en todo el tenant cuando el alcance de la recopilación cubre sus catálogos. Complete la enumeración, incluido cualquier enlace de continuación devuelto, antes de registrar un inventario como completo.

La documentación del recurso Graph accessPackage describe el catálogo del paquete, sus directivas de asignación y sus relaciones con los roles de recursos. Enumerar objetos de paquete es una comprobación de existencia; es necesario examinar esas relaciones por separado para evaluar si un paquete representa el acceso previsto.

La solicitud anterior es un método documentado de inspección, no una consulta ejecutada contra un tenant de cliente para este artículo. Conserve el estado real, el alcance de la recopilación y la respuesta de su auditoría autorizada. Un error de autenticación, un error de autorización, una ejecución interrumpida o un alcance sin verificar deben figurar en las pruebas como limitaciones de recopilación. Ninguno permite escribir «no hay paquetes configurados».

Remediación: crear el paquete y demostrar su ciclo de vida (Remediation)

1. Seleccionar el catálogo y los roles de recursos

Siga el flujo de creación de Learn: seleccione New access package, introduzca su nombre y descripción en Basics y elija su catálogo. Identity Governance Administrator, catalog owner o access package manager pueden crear paquetes dentro de su alcance autorizado. Los access package managers utilizan recursos que ya están en el catálogo; no pueden añadirle recursos. En Resource roles, seleccione los recursos y roles previstos.

Elija el catálogo de forma deliberada e identifique a su propietario responsable en el registro del piloto. Use una descripción que permita al solicitante reconocer la tarea empresarial. Pida a los propietarios de recursos que revisen los roles seleccionados antes de continuar. El rol de propietario de un grupo es sustancialmente distinto de la pertenencia, y un rol de administrador de aplicación puede ser innecesario para un trabajo ordinario del proyecto. Revise el permiso real, no solo el nombre mostrado del recurso.

2. Definir los solicitantes y los aprobadores

En Requests, configure los usuarios elegibles y los ajustes de aprobación de la directiva inicial. Exija aprobación para el piloto, elija al aprobador designado y solicite una justificación. Si usa la opción del responsable jerárquico, configure una alternativa cuando falte esa información. En Who can request access, seleccione Self para este piloto en el que el usuario solicita el acceso. Estos controles están documentados en los ajustes de aprobación de la guía de creación.

Prefiera una población piloto claramente definida a un alcance amplio de solicitudes. Pregunte al aprobador qué información necesita para decidir y si puede reconocer una solicitud inadecuada. Pruebe con un usuario elegible y otro fuera del alcance. Registre las decisiones esperadas antes de la prueba para distinguir un defecto de la directiva de un requisito mal entendido.

Para la colaboración externa, revise también el acceso condicional de invitados y la configuración de colaboración externa. Ese artículo aborda la protección del inicio de sesión de invitados, las invitaciones, la visibilidad y los controles del ciclo de vida. Úselo para enmarcar los controles que rodean a la población externa; la aprobación del paquete por sí sola no documenta esa revisión más amplia.

3. Configurar la expiración antes de crear el paquete

En Lifecycle, seleccione una expiración de asignación por fecha o duración y decida si las extensiones están permitidas y requieren aprobación. Revise la configuración en Review + create y seleccione Create para crear el paquete y la directiva inicial. Estos son los pasos de creación documentados.

Elija la condición de finalización según el calendario empresarial de la tarea. Para el piloto, use una asignación de prueba que pueda llegar a su expiración programada durante su ventana de verificación. Acuerde ese calendario con el propietario del recurso. Documente cómo se gestionarán las extensiones legítimas y quién las decidirá. Evite dejar una asignación permanente solo porque probar la expiración requiere más coordinación.

4. Verificar el acceso entregado y después el acceso tras la expiración

La guía de gestión de asignaciones de Microsoft documenta Assignments, los detalles de cada asignación y los filtros de estado Delivering y Expired. Los errores de entrega pueden investigarse mediante la entrada correspondiente en Requests. Use esas vistas para recopilar pruebas del estado real de la asignación de prueba.

Envíe la solicitud del piloto por su ruta de aprobación configurada. Registre el solicitante, la directiva seleccionada, la decisión, el identificador de asignación y la hora de finalización prevista. Verifique que el usuario de prueba recibe el rol de recurso previsto y puede realizar la tarea permitida. Pruebe también una operación significativa que el usuario no debería poder realizar. Un inicio de sesión correcto dice poco, por sí solo, sobre si el rol asignado es adecuado.

Después de la expiración programada, capture la asignación expirada y vuelva a comprobar el acceso a los recursos. Compare la pertenencia, la asignación de aplicación y la capacidad del usuario para realizar la tarea con las pruebas anteriores. Si el acceso permanece, investigue otras concesiones antes de afirmar que el paquete falló o que la expiración eliminó todo acceso efectivo. El mismo usuario puede tener otro derecho que su piloto nunca pretendió retirar.

Conserve ambas observaciones en el registro del piloto. «Paquete creado» es un hito de configuración; «acceso aprobado entregado, después su asignación expiró y se retiró el acceso previsto a los recursos» es el resultado de verificación que intenta establecer. Este artículo no afirma que una prueba así ya haya tenido éxito en ningún tenant.

Cómo detecta EtcSec esta configuración

El detector AZ_ENTITLEMENT_MANAGEMENT de etc-collector de EtcSec evalúa la existencia de paquetes recopilados mediante AzureAccessPackagesProbed y AzureAccessPackagesCount. El método Detect() examinado tiene estas ramas:

El Count: 1 del hallazgo es el número de hallazgos a nivel de tenant, no el número de usuarios afectados o directivas ausentes. Un resultado nil no valida la selección de recursos, los aprobadores, el alcance de las solicitudes, las licencias, la expiración ni la retirada. El detector comprueba la existencia, no la calidad de las directivas. Un hallazgo de ausencia tampoco demuestra que falten todos los procesos alternativos de gobernanza.

Use el resultado para abrir la investigación adecuada: cobertura de recopilación para Info, una evaluación empresarial y de licencias para Medium y una revisión separada del ciclo de vida cuando ya existen paquetes. Conserve las pruebas de entrega y expiración del piloto junto a la auditoría para que la próxima revisión pueda distinguir un hallazgo de existencia resuelto de una gobernanza de acceso demostrada.