Auditoría de roles personalizados Entra ID: roles admin sin asignación

Auditoría de roles personalizados Entra ID: ¿qué se mide?

Una auditoría de roles personalizados Entra ID debe responder a tres preguntas distintas: qué definiciones de permisos existen, qué principales las tienen y si esas asignaciones siguen atendiendo una necesidad empresarial. Microsoft representa una asignación como una conexión entre una definición, un principal y un ámbito. Encontrar únicamente una definición personalizada no demuestra acceso privilegiado. Microsoft Graph: unifiedRoleAssignment.

Las revisiones de acceso se ocupan de las asignaciones; una auditoría de definiciones examina por separado los permisos que estas conceden. Una revisión puede omitir asignaciones fuera de los roles, poblaciones o tipos de asignación seleccionados. Una revisión bien delimitada puede eliminar el acceso al aplicar sus resultados. Revisar las asignaciones también deja una pregunta independiente: ¿debe seguir existiendo la definición subyacente y son adecuados sus permisos? Crear revisiones de acceso a roles, completar y aplicar las revisiones.

Esta guía separa esas preguntas, ofrece solicitudes Graph documentadas y explica siete comprobaciones de etc-collector. No contiene resultados de un tenant ni operaciones Graph ejecutadas. El objetivo práctico es un conjunto de evidencias que permita a un administrador justificar el acceso conservado, eliminar asignaciones innecesarias y retirar definiciones personalizadas realmente redundantes sin confundir esas acciones.

Definiciones, roles habilitados y titulares

En Graph, isBuiltIn=false identifica una definición de rol personalizada. isEnabled indica si la definición está disponible para asignación; no dice si alguien tiene actualmente ese rol. rolePermissions contiene su colección de permisos. Microsoft indica que resourceScopes no debe utilizarse y que está previsto retirarlo; vincule el ámbito a la asignación en su lugar. Propiedades de unifiedRoleDefinition.

Los roles de directorio Microsoft Entra gobiernan los recursos Entra; el RBAC de recursos Azure gobierna recursos como máquinas virtuales y almacenamiento. Sus permisos no son intercambiables. Los roles de directorio personalizados pueden implementar una función laboral más restringida que un rol integrado, por lo que «personalizado» no es por sí solo un veredicto de seguridad. Introducción al RBAC de Microsoft Entra.

Para esta auditoría, mantenga tres categorías de hallazgos: complejidad de definiciones, asignaciones que necesitan justificación e incertidumbre de recopilación. Es un método de elaboración de informes recomendado. Evita presentar una lista vacía de asignaciones como una intrusión activa y evita sustituir el análisis de permisos por un catálogo de roles aparentemente pequeño.

Funcionamiento: los permisos y el ámbito determinan la exposición

El nombre de un permiso sigue una estructura de espacio de nombres, entidad, conjunto de propiedades y acción. Por ejemplo, microsoft.directory/applications/credentials/update es un permiso de directorio, y no un permiso de aplicación Graph denominado Application.ReadWrite.All al que se haya concedido consentimiento. La documentación de Microsoft sobre permisos privilegiados explica esta estructura y cómo estos permisos pueden convertir un rol integrado o personalizado en privilegiado. Roles y permisos privilegiados.

El catálogo de permisos de registro de aplicaciones identifica las actualizaciones de credenciales como cambios en certificados y secretos de aplicaciones de un solo tenant y de varios tenants. Su variante applications.myOrganization restringe el subtipo de aplicación. También distingue applications/permissions/update, que modifica la configuración de permisos, de la concesión efectiva de consentimiento. Mantenga estas diferencias al comparar definiciones; los nombres de acción parecidos no son intercambiables. Permisos personalizados de registro de aplicaciones.

Una ruta condicional de abuso de credenciales

Microsoft advierte que un administrador capaz de añadir credenciales de aplicación puede suplantar a esa aplicación, cuyos permisos pueden superar los suyos. Lo siguiente es una inferencia operativa derivada de esa advertencia y del modelo de ámbito de roles personalizados: una asignación efectiva de actualización de credenciales con ámbito de directorio puede exponer los registros de aplicaciones de ese directorio; una asignación limitada a un registro restringe el objetivo en consecuencia. Delegar permisos de administración de aplicaciones.

La cadena inferida necesita una asignación efectiva o una activación permitida, una credencial aceptada para la aplicación objetivo y permisos efectivos de aplicación útiles. No concede automáticamente Global Administrator. No demuestra el control de todas las identidades de carga de trabajo: un registro de aplicación local, una identidad administrada y un principal de servicio de una aplicación de propiedad externa son objetos distintos. Delegación de administración de aplicaciones, RBAC e identidades de carga de trabajo.

Un detector que cuenta definiciones no puede establecer esta cadena. PA_CUSTOM_ROLE_EXCESSIVE comprueba el número de roles no integrados, y no sus acciones ni los ámbitos de asignación (azure/privileged-access/roles/custom-role-excessive.go:24). Por ello, una sola definición potente puede merecer investigación aunque esa comprobación de recuento no dé un resultado positivo.

Los roles de administrador con nombre siguen siendo poblaciones distintas

Application Administrator se ocupa de la administración de aplicaciones; Exchange Administrator y SharePoint Administrator gobiernan sus respectivos servicios. Security Administrator gestiona la configuración de seguridad, mientras que Privileged Role Administrator gestiona las asignaciones de roles y PIM. En la referencia de roles de Microsoft son responsabilidades distintas, y no cinco nombres para el mismo privilegio. Referencia de roles integrados.

Recomendamos pedir a cada responsable de servicio que explique las tareas que necesitan su rol, el ámbito requerido y el período de acceso previsto. Mantenga visibles los titulares no humanos: nuestro artículo relacionado sobre los principales de servicio con roles administrativos y privilegios permanentes examina la responsabilidad y el ciclo de vida de los titulares. Complementa un inventario de definiciones, sin sustituirlo.

Medición: solicitudes Microsoft Graph documentadas

Las solicitudes siguientes se han copiado de los ejemplos HTTP o de la sintaxis de solicitud de Learn citados. Cada una tiene su propio bloque de código. Son documentación, y no instrucciones ejecutadas contra un tenant para este artículo. En una auditoría autorizada, registre la hora de recopilación, los permisos, el estado de respuesta y la paginación. Siga cada @odata.nextLink devuelto; clasifique una recopilación fallida o incompleta como desconocida, y no como cero asignaciones.

1. Enumerar definiciones y clasificar roles personalizados

El ejemplo de Learn del proveedor de directorio enumera las definiciones de roles:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions

La misma API documenta el filtrado por igualdad en isBuiltIn. Para la solicitud mostrada, clasifique localmente las definiciones devueltas mediante isBuiltIn=false, conserve sus identificadores y su estado de habilitación y examine las colecciones de permisos. RoleManagement.Read.Directory es un permiso de lectura admitido; las llamadas delegadas también requieren un rol de operador adecuado. Enumerar roleDefinitions.

Recomendamos conservar la definición original junto a su interpretación. Un nombre para mostrar como «Application Support» no explica qué acciones de escritura permite. Incluya las acciones exactas, el responsable empresarial y la justificación en el registro de auditoría para que un futuro revisor pueda comparar permisos en lugar de nombres.

2. Distinguir los roles integrados activados

El ejemplo documentado de directoryRoles es:

GET https://graph.microsoft.com/v1.0/directoryRoles

Esta operación devuelve los roles activados, y no todo el conjunto de definiciones integradas disponibles. La activación de un rol de directorio en esta API tampoco es la sesión de activación PIM de un usuario. Concilie roleTemplateId cuando corresponda en lugar de tratar los identificadores de instancia y de definición como intercambiables. Enumerar directoryRoles.

3. Recopilar las asignaciones activas

Learn documenta la sintaxis de solicitud del proveedor de directorio:

GET /roleManagement/directory/roleAssignments

Utilice la raíz de servicio v1.0 para esa ruta relativa. Learn también proporciona este ejemplo exacto de filtrado y expansión:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'&$expand=principal

El GUID corresponde al ejemplo Global Administrator de Microsoft, y no a una definición personalizada descubierta en su tenant. Para investigar por definición, sustitúyalo por el identificador de definición verificado. La API de enumeración admite $filter, $expand y $select, con RoleManagement.Read.Directory entre sus permisos de lectura. Enumerar unifiedRoleAssignments.

Vincule las asignaciones a las definiciones mediante roleDefinitionId y conserve principalId y directoryScopeId. Los principales admitidos incluyen usuarios, grupos a los que se pueden asignar roles y principales de servicio. Un principal de grupo expandido sigue siendo un objeto grupo; no es un recuento de las personas que reciben acceso mediante pertenencia. Campos y relaciones de asignaciones.

4. Recopilar por separado la elegibilidad PIM

El ejemplo documentado de elegibilidad es:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleInstances

La API devuelve instancias de elegibilidad y admite selección, filtrado y expansión. Su permiso de lectura de mínimo privilegio es RoleEligibilitySchedule.Read.Directory; el acceso delegado también exige un rol de operador. Enumerar roleEligibilityScheduleInstances.

Recomendamos conservar los registros activos y elegibles por separado antes de producir una vista combinada. Haga coincidir el principal, la definición, el ámbito y las fechas pertinentes. Una lista activa vacía no permite determinar si alguien sigue siendo elegible, y una respuesta de elegibilidad no puede establecer el uso histórico. Registre exactamente qué pregunta responde cada conjunto de datos.

5. Identificar las asignaciones privilegiadas sin ocultar la versión de API

La página de Learn sobre roles privilegiados ofrece este ejemplo opcional:

GET https://graph.microsoft.com/beta/roleManagement/directory/roleAssignments?$expand=roleDefinition&$filter=roleDefinition/isPrivileged eq true

Se trata explícitamente de una solicitud beta. No la reescriba silenciosamente como v1.0 ni dé a entender que isPrivileged es una propiedad documentada por el recurso de definición v1.0 utilizado antes. La página también describe la etiqueta PRIVILEGED en el centro de administración. Identificación de roles privilegiados.

Detección: contar asignaciones, principales distintos e incógnitas

Recomendamos producir la siguiente ficha por rol. Son campos de informe de auditoría, y no límites adicionales de Microsoft:

Para un rol habilitado sin asignaciones recopiladas, concilie primero los identificadores y confirme que ambas rutas de recopilación han funcionado. Después pregunte a su responsable si la definición tiene una finalidad prevista. Descríbalo como «habilitado sin asignación activa o elegible recopilada», y no como «nunca utilizado». El predicado UNUSED del colector comprueba las coincidencias en los datos de entrada actuales, y no el historial de actividad (azure/privileged-access/roles/unused-admin-role.go:36).

Para los recuentos de titulares, indique si la cifra representa registros de asignación o principales distintos. El detector compartido TOO_MANY compara identificadores de rol y cuenta las entradas de asignación coincidentes; no elimina duplicados de personas, no filtra el tipo de principal ni restringe el ámbito (azure/privileged-access/roles/too-many-privileged-roles.go:43). Trate su resultado como una señal de triaje que requiere esta ficha.

Convertir una señal en una decisión revisable

Recomendamos dar a cada hallazgo una resolución explícita: conservar con justificación, investigar evidencias incompletas, eliminar una asignación, restringir una asignación o retirar una definición personalizada. Registre a la persona responsable de la decisión y las evidencias que examinó. Conserve el resultado del detector junto a esa resolución para poder distinguir una excepción operativa de un error de medición.

Para un hallazgo de recuento de definiciones, solicite una comparación de permisos antes de recomendar la consolidación. Para un hallazgo UNUSED, solicite los registros de recopilación activa y elegible antes de recomendar la retirada. Para un hallazgo TOO_MANY, pregunte qué principales y ámbitos produjeron el recuento antes de recomendar una población menor. Estas preguntas siguen los tres predicados descritos antes; ninguna requiere inventar un resultado de explotación.

Recomendamos documentar la regla de recuento en la propia exportación. Si un principal aparece en varios ámbitos, explique si el informe cuenta esas asignaciones por separado. Si aparece un grupo, etiquete su asignación como una concesión a un grupo y reserve un campo independiente para las evidencias de pertenencia. Si no se pudo recopilar la elegibilidad, marque como provisional la conclusión de ausencia. Así el informe puede utilizarlo un revisor que no realizó la recopilación.

Elija las evidencias de cierre al abrir el hallazgo. Una tarea de retirada de definición debe terminar con la ausencia de la definición aprobada en un inventario nuevo. Una tarea de eliminación de asignación debe terminar con la ausencia de esa concesión concreta en el conjunto de datos pertinente. Una excepción conservada debe terminar con una finalidad documentada y una fecha futura de revisión. Son criterios de aceptación recomendados para la auditoría, y no afirmaciones sobre una función de aplicación automática.

Microsoft recomienda menos de cinco Global Administrators y menos de diez asignaciones de roles privilegiados en toda la organización. Son recomendaciones de gobernanza, y no techos de asignación impuestos. La página citada no establece un límite de dos a cuatro titulares por rol Application, Exchange, Security, SharePoint o Privileged Role Administrator. Los umbrales por rol del colector son valores predeterminados del producto. Buenas prácticas de roles Microsoft Entra.

Corrección: retirar definiciones redundantes y gobernar el acceso restante (Remediation)

1. Decidir qué roles personalizados deben mantenerse

Recomendamos revisar cada definición con el responsable del servicio: ¿qué operación exacta la necesita, qué ámbito más restringido funciona y quién responde por los cambios futuros? Consolide definiciones redundantes solo después de comparar sus acciones y las asignaciones previstas. Conserve roles personalizados útiles cuando implementen el conjunto de permisos requerido con más precisión que un rol integrado. Selección de roles con mínimo privilegio.

Trátelo como un registro de decisiones, y no como un intento de alcanzar un tamaño arbitrario del catálogo. Para una definición aparentemente vacía, capture los inventarios activos y elegibles, confirme la calidad de recopilación e investigue las dependencias previstas antes de aprobar su retirada. Donde el acceso siga siendo necesario, priorice reducir las acciones innecesarias de gestión de credenciales y los ámbitos amplios de aplicación. Permisos personalizados de registro.

2. Eliminar asignaciones innecesarias y después las definiciones personalizadas aprobadas

Recomendamos separar las dos decisiones de cambio. Eliminar una asignación trata el acceso de un titular; retirar una definición trata el catálogo de roles. La API de eliminación de Microsoft admite definiciones personalizadas, prohíbe eliminar roles integrados y documenta esta sintaxis:

DELETE /roleManagement/directory/roleDefinitions/{id}

Es una operación de escritura citada, no ejecutada aquí. Sustituya {id} únicamente por el identificador de definición personalizada aprobado. Learn especifica RoleManagement.ReadWrite.Directory como permiso API de mínimo privilegio y Privileged Role Administrator como rol de operador delegado admitido de mínimo privilegio. Una eliminación correcta devuelve 204 No Content. Eliminar unifiedRoleDefinition.

Para un rol integrado señalado por UNUSED, documente por qué no tiene titulares y si la instancia activada sigue siendo pertinente. No aplique una guía de eliminación de definiciones personalizadas a todos los resultados UNUSED. Recomendamos verificar los inventarios de definiciones y asignaciones posteriores al cambio antes de cerrarlo.

3. Establecer poblaciones justificadas y migrar a PIM el acceso humano adecuado

Recomendamos un presupuesto de acceso por rol basado en las funciones requeridas y la cobertura operativa, con excepciones explícitas. Evalúe las asignaciones privilegiadas agregadas de la organización respecto a las directrices de Microsoft en lugar de tratar los umbrales del colector como cuotas obligatorias de Microsoft.

PIM admite activación limitada en el tiempo y basada en aprobación para roles Entra integrados y personalizados. Su plan de despliegue recomienda probar un piloto, configurar los ajustes de cada rol y preservar el acceso de emergencia. Los principales de servicio no pueden recibir asignaciones elegibles; pueden recibir asignaciones activas limitadas en el tiempo. El plan de Microsoft recomienda dos cuentas de emergencia solo en la nube con asignaciones Global Administrator permanentes. Planificar un despliegue PIM.

Para las asignaciones humanas adecuadas, recomendamos probar aprobación, MFA, justificación y duración respecto al modelo operativo previsto antes del despliegue. Nuestro artículo sobre los controles de aprobación, MFA, justificación y duración de activación PIM aborda esa revisión independiente de configuración.

Confirme las licencias antes de adoptar el plan: el uso de roles personalizados requiere P1 para los usuarios asignados, mientras que PIM requiere P2 o Governance. Las revisiones de acceso de principales de servicio necesitan Workload ID Premium además de P2 o Governance. Licencias de roles personalizados, Licencias PIM y directrices de roles, Requisitos previos de revisiones PIM.

4. Revisar el acceso y aplicar las decisiones

En PIM, seleccione los roles Entra y las poblaciones pertinentes, elija asignaciones activas, elegibles o ambas, y configure los revisores responsables y el tratamiento de las faltas de respuesta. Una revisión captura una instantánea al comenzar; los grupos a los que se pueden asignar roles aparecen sin expansión de miembros. Crear revisiones de acceso a roles.

Recomendamos conservar el ámbito de revisión junto a los resultados para que «revisión completada» no se confunda con «todo el acceso administrativo revisado». Documente evidencias de pertenencia independientes cuando se asigne un rol a un grupo. Dé a los responsables de cargas de trabajo una tarea de revisión adecuada a la identidad de servicio en lugar de suponer que los controles de activación humana la cubren.

El acceso denegado se elimina cuando se aplican los resultados de revisión, manualmente o mediante la aplicación automática configurada. Registrar una denegación por sí solo no es el paso final de revocación. Completar revisiones de acceso a roles.

5. Verificar el resultado con las mismas mediciones

Recomendamos repetir las lecturas documentadas después de los cambios, comparando identificadores de definición, acciones de permisos, ámbitos y asignaciones activas y elegibles. Compruebe el cambio específico aprobado: un titular eliminado, un permiso restringido o una definición retirada. Conserve las excepciones y las incógnitas en lugar de declarar la auditoría satisfactoria porque bajó un recuento.

Cómo detecta EtcSec esta situación

Los siete identificadores siguientes existen en el catálogo. Sus implementaciones se leyeron en etc-collector en el commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Las rutas siguientes son relativas a public/internal/audit/detectors/.

CUSTOM utiliza azure/privileged-access/roles/custom-role-excessive.go:24; UNUSED utiliza azure/privileged-access/roles/unused-admin-role.go:36. Las cinco comprobaciones TOO_MANY utilizan el método compartido Detect() en azure/privileged-access/roles/too-many-privileged-roles.go:43. Sus constructores individuales too-many-*-admins.go establecen los umbrales en la línea 17 y las severidades en la línea 19. Cada implementación devuelve un hallazgo incluso con Count=0; la detección positiva requiere Count>0. Por encima del umbral, CUSTOM y TOO_MANY devuelven el recuento coincidente completo, y no solo el exceso.

Las cinco entradas TOO_MANY son Info con peso 0 en el catálogo, aunque sus constructores emiten High, o Critical para Privileged Role Administrator. Esta discrepancia se conserva explícitamente. No eleve silenciosamente la puntuación del catálogo ni describa las severidades de ejecución como valores del catálogo.

Las limitaciones de recopilación afectan a la interpretación

El proveedor revisado combina asignaciones activas con elegibilidad recopilada mediante principal, rol y ámbito (public/internal/providers/azure/client.go:1597, :1626, :1784). Su inventario de roles combina instancias integradas activadas con definiciones personalizadas, mapea los identificadores de definición personalizada a RoleTemplateID y establece su atributo interno IsEnabled=true sin copiar el valor de habilitación de Graph (client.go:1500).

Las lecturas de definiciones personalizadas se hacen con el mejor esfuerzo posible; las rutas de roles y elegibilidad revisadas no implementan bucles nextLink. Los fallos HTTP o de análisis de elegibilidad pueden devolver un mapa vacío (client.go:404). Por tanto, una recopilación de elegibilidad ausente puede producir un resultado UNUSED aparente o un recuento inferior al real de las poblaciones TOO_MANY. Son observaciones estáticas del código, y no fallos de tenant reproducidos.

Cierre la auditoría con evidencias separadas de la necesidad de las definiciones, la justificación de los titulares y la revocación efectiva. Un resultado sin superar umbrales es útil, pero la decisión de la que se debe responder es si cada permiso y asignación conservados siguen teniendo una finalidad documentada.