Revisar consentimientos de aplicaciones en Entra ID sin romper procesos

Consentimiento no es lo mismo que inicio de sesión

Una aplicación puede autenticar usuarios y, además, recibir autorización para acceder a una API. Revisar únicamente quién puede iniciar sesión no acredita qué datos puede leer o modificar. Del mismo modo, una aplicación de automatización puede trabajar sin un usuario interactivo.

Microsoft distingue permisos delegados y permisos de aplicación. Los delegados se utilizan en contexto de usuario; los de aplicación permiten acceso sin ese contexto y requieren consentimiento administrativo. Esa diferencia determina las preguntas que debe hacer al propietario del proceso.

No confunda la lista de permisos solicitados en un registro de aplicación con las concesiones efectivas en el tenant. Conserve el identificador de la aplicación y el del objeto local que está revisando para evitar mezclar dos integraciones con nombres parecidos. Los nombres son útiles para comunicar, pero los identificadores sostienen la trazabilidad técnica.

Delegado y de aplicación: el contexto cambia la decisión

Quién consiente y para quién

El consentimiento de usuario y administrador depende de permisos y políticas del tenant. Algunos permisos delegados requieren administrador; no todos pueden aprobarse individualmente. Una concesión para un usuario y otra para todos necesitan registros separados. Deshabilitar nuevos consentimientos de usuario no retira automáticamente los que ya existen.

Para una revisión empresarial, identifique la población autorizada y el flujo que la usa. Un informe ejecutado por un usuario con acceso amplio no tiene el mismo contexto que una automatización app-only. Pregunte cómo se autentica cada componente y qué recursos solicita. Si una solución combina ambos modelos, inventaríe ambas concesiones: revisar una pantalla de inicio de sesión no cubre su componente de servidor.

La aplicación puede solicitar permisos en distintas fases. Compare lo declarado por el fabricante con la función activada en su organización. No interprete todo permiso solicitado como acceso concedido ni todo permiso concedido como uso demostrado. Son tres evidencias diferentes: configuración solicitada, concesión registrada y operación observada. El registro debe permitir explicar sus discrepancias.

Prepare el inventario que falta en una captura del portal

Para cada aplicación, registre propietario técnico, propietario del negocio, finalidad, recurso accedido, tipo de permiso, alcance concedido y justificación. Añada quién autoriza la decisión, la evidencia consultada y la próxima revisión. Si no conoce al propietario, marque ese dato como pendiente; no rellene el hueco con una suposición.

Incluya las integraciones de backup, migración, gestión, informes y automatización que puedan tener permisos amplios. El objetivo no es declarar peligrosas todas esas herramientas. Es confirmar que el acceso corresponde a una función necesaria, que existe un responsable y que el proceso sigue vigente.

La guía de integración de Entra ID con aplicaciones explica el contexto de autenticación e integración. Esta revisión añade la evidencia de autorización y el ciclo de decisión sobre permisos.

App Registrations y Enterprise Applications

Microsoft distingue el objeto de aplicación y el service principal. App Registrations muestra la definición de aplicaciones del tenant de origen; Enterprise Applications muestra su representación local. Conserve appId y object ID del service principal, que no son intercambiables. En una aplicación externa, el registro puede estar en el tenant del proveedor.

Ese modelo evita un error frecuente: buscar un registro local que no existe y concluir que el inventario está incompleto. Revise la instancia empresarial del tenant y sus concesiones. Diferencie además un service principal de aplicación de una identidad administrada. La revisión puede incluir ambos, pero no se mantienen de la misma forma ni necesitan las mismas credenciales. Identifique el tipo antes de asignar una intervención.

Propietarios y dependencias que el directorio no explica

Un propietario registrado en el directorio ayuda a localizar al equipo, pero no acredita quién aprueba la función de negocio. Confirme ambos responsables y un sustituto. Consulte contratos, inventario de aplicaciones, repositorios y automatizaciones con los equipos correspondientes. Una aplicación sin propietario necesita investigación y una decisión asignada; dejar el campo vacío indefinidamente no resuelve el riesgo.

Liste trabajos programados, conexiones de integración, destinos de datos y usuarios consumidores. Incluya procesos ocasionales como cierre mensual o recuperación que no aparecen en una semana normal. Registre la dependencia crítica y la prueba que la valida. Si el proveedor pide mantener un permiso amplio, solicite una justificación por función y versión. Una explicación comercial general no sustituye la relación entre permiso, API y operación.

Leer las concesiones con el rol adecuado

La documentación oficial de revisión de permisos de aplicaciones empresariales describe la sección de permisos y las vistas de consentimiento de administrador y de usuario. También detalla los requisitos de rol y las diferencias entre acciones disponibles en el portal y mediante Microsoft Graph o PowerShell.

Empiece en modo de lectura. Capture el conjunto concedido y su contexto antes de proponer cambios. No eleve su cuenta a administrador global por comodidad. La capacidad para revisar, revocar o conceder acceso no es necesariamente la misma; compruebe la operación concreta y el recurso implicado.

Una exportación de permisos debe mantenerse en un repositorio con acceso apropiado. No necesita contener secretos de cliente ni credenciales. Si recopila registros de uso, limite la información personal al mínimo requerido para verificar la integración.

Revisión en el portal y límites de cada operación

La ruta documentada es Entra ID > Enterprise apps > All applications > aplicación > Permissions. Distinga Admin consent y User consent. La guía de revisión exige Cloud Application Administrator o Application Administrator para su procedimiento. El portal no permite revocar desde User consent; para esas concesiones remite a Graph o PowerShell. Tener una pestaña visible no garantiza que todas las actuaciones estén disponibles.

Separe en el plan tres tareas: leer concesiones, aprobar una propuesta y ejecutar el cambio. Puede asignarlas a personas distintas. Documente el rol usado y la vigencia del acceso administrativo. La revisión de inventario no requiere añadir permisos de escritura al cliente de auditoría. Si una consulta falla por autorización, conserve el error y revise su requisito, sin convertir una lectura en un otorgamiento amplio de permisos.

Consultas Graph v1.0 de lectura

Los siguientes ejemplos son peticiones HTTP para un cliente autorizado; no son comandos PowerShell. Sustituya los marcadores por object IDs del tenant revisado. El primer ID identifica la aplicación cliente local; resourceId identifica la API de destino. Las consultas no conceden ni revocan acceso.

GET https://graph.microsoft.com/v1.0/servicePrincipals/{client-service-principal-id}/oauth2PermissionGrants
GET https://graph.microsoft.com/v1.0/servicePrincipals/{client-service-principal-id}/appRoleAssignments
GET https://graph.microsoft.com/v1.0/servicePrincipals/{resource-service-principal-id}?$select=id,appId,displayName,appRoles,oauth2PermissionScopes

Para oauth2PermissionGrants, el permiso mínimo documentado es Directory.Read.All. Para appRoleAssignments, es Application.Read.All; también permite la lectura del service principal. En acceso delegado, compruebe asimismo el rol del usuario; Directory Readers figura entre los roles admitidos por estas operaciones. La autorización del cliente Graph y el rol de Entra son comprobaciones distintas.

Convertir resultados en evidencia interpretable

En oAuth2PermissionGrant, conserve id, clientId, resourceId, scope, consentType y principalId. Scope contiene valores separados por espacios. Principal identifica un consentimiento para un usuario; AllPrincipals, para todos, con principalId nulo. En appRoleAssignments, relacione appRoleId con appRoles del recurso para resolver el permiso concedido.

Recorra las páginas mediante la URL completa de @odata.nextLink hasta que no aparezca. Identifique consultas que fallaron y no presente una exportación parcial como inventario completo. Para concesiones recientes, contemple el retraso de replicación documentado en appRoleAssignments. Conserve fecha, tenant, aplicación y consulta utilizada, junto con un resultado normalizado que otro administrador pueda interpretar. No distribuya cabeceras de autorización ni tokens.

Priorice por capacidad e impacto, no por cantidad

Diez permisos de lectura delimitados pueden plantear un riesgo distinto de un único permiso de escritura amplio. Examine qué recurso alcanza la concesión, si afecta a todos los usuarios y si la aplicación actúa de forma interactiva o en segundo plano. La evaluación también depende de la sensibilidad de los datos y de las restricciones adicionales aplicables al recurso.

Pregunte qué ocurre si la integración deja de funcionar. Una automatización de informes puede tolerar una ventana de prueba; un proceso de recuperación o de aprovisionamiento puede necesitar una validación más cuidadosa. Esa dependencia no justifica mantener cualquier acceso indefinidamente, pero sí afecta a la secuencia de cambios.

La tabla es una propuesta de gestión de MSAdvance. Si hay indicios de compromiso, la revisión periódica no sustituye el procedimiento de respuesta a incidentes ni sus prioridades de contención.

Interpretar permisos sensibles con contexto

Evalúe lectura, escritura, amplitud y capacidad de administración en conjunto. Un permiso de lectura amplio puede exponer información valiosa; la palabra Read no significa riesgo bajo. Una capacidad para modificar identidades o roles exige investigar quién controla la aplicación y su ejecución. Consulte la referencia de permisos Graph para la descripción exacta, tipo y requisito de consentimiento; no deduzca el alcance sólo del nombre.

Identifique restricciones adicionales verificadas en el recurso. Una intención de acceder sólo a un sitio no demuestra que exista una restricción efectiva. Si se propone un permiso menor, compruebe que el fabricante lo soporta y que la API utilizada permite la operación. Diseñe una prueba que confirme el acceso autorizado y otra que confirme que un recurso excluido no es accesible. Conserve las condiciones de ambas.

Uso, ausencia de uso y cobertura de registros

Revise actividad apropiada al modelo. Los inicios de sesión de service principals muestran actividad sin usuario; no equivalen a inicios interactivos. Un inicio correcto acredita autenticación, no cada operación de negocio ni que todos los permisos se hayan utilizado. Correlacione con registros del proceso o recurso cuando sea necesario.

Antes de concluir que la integración está inactiva, anote la ventana observada y compruebe retención y disponibilidad según licencia. Una tarea mensual puede quedar fuera de una ventana breve. Una laguna en logs puede impedir la conclusión sin justificar mantener el permiso para siempre: asigne al propietario una prueba y una fecha de decisión. La revisión de concesiones no debe confundirse con funciones adicionales de gobernanza que puedan tener sus propios requisitos de licencia.

Preparar una revocación que pueda verificarse

Defina la concesión exacta, el propietario que aprueba, el período de cambio, las pruebas posteriores y el criterio para revertir. Documente el estado previo y la alternativa de recuperación permitida. No describa una restauración como un botón universal: Microsoft explica métodos y condiciones de restauración de permisos revocados que deben revisarse antes de actuar.

Reotorgar consentimiento administrativo puede aplicar el conjunto solicitado actualmente por la aplicación, no reconstruir automáticamente la decisión anterior. Verifique el alcance propuesto antes de aceptar. Una recuperación del servicio no debería conceder inadvertidamente capacidades nuevas.

Después del cambio pruebe el proceso y el acceso que debe permanecer denegado. Revocar una concesión no elimina una copia de datos que la aplicación hubiera obtenido previamente. El tratamiento de esas copias requiere su propia decisión de conservación o retirada.

Reducir solicitudes y revocar concesiones son cambios distintos

Microsoft indica que retirar un permiso del registro de aplicación no revoca la concesión existente. En una integración propia, coordine código, permisos solicitados y concesiones locales. En una aplicación externa, acuerde con el proveedor la configuración soportada. Si sólo modifica la concesión y la aplicación sigue solicitando el permiso, investigue la siguiente experiencia de consentimiento antes de dar el cambio por estable.

Prepare una lista de cambios por concesión y recurso, con finalidad, impacto y prueba. No elimine la aplicación empresarial para retirar únicamente un permiso. Esa actuación tiene un alcance diferente y puede afectar otras configuraciones. Si el objetivo es retirar una integración completa, use un plan específico que incluya conexiones, credenciales, datos y responsables. Una revisión periódica de permisos no sustituye ese procedimiento.

Consentimiento administrativo y recuperación controlada

Los roles para otorgar consentimiento dependen de la API y del permiso. Cloud Application Administrator y Application Administrator tienen una excepción para app roles de Microsoft Graph; Privileged Role Administrator puede consentir cualquier permiso. Compruebe esa diferencia al planificar recuperación. No presuponga que quien consulta o revoca puede reotorgar toda concesión.

Conserve el conjunto anterior y el aprobado después del cambio. Defina la recuperación de la concesión exacta y revise el conjunto solicitado antes de pulsar Grant admin consent. Según la guía de restauración, reotorgarlo puede retirar concesiones ajenas al conjunto predeterminado del desarrollador. Recuperar un proceso necesita una comparación explícita; una captura previa sin IDs ni contexto puede ser insuficiente.

Pruebas tras el cambio

Ejecute el flujo de negocio con la identidad y condiciones previstas, compruebe que completa su función y registre errores. Incluya tareas en segundo plano y procesos ocasionales relevantes. Compruebe también acceso que debía quedar excluido. No dé por probado un cambio porque se guardó en el portal ni prometa que los tokens ya emitidos dejan de funcionar de inmediato; defina observación y contención según el recurso y el caso. Ante sospecha de compromiso, siga respuesta a incidentes.

Ejemplo: informe mensual con permisos sin justificar

Suponga una integración que prepara un informe de uso. El propietario confirma que necesita ciertas lecturas, pero no sabe por qué conserva una capacidad de escritura. El equipo revisa la documentación, ensaya el informe en un entorno adecuado y propone retirar únicamente la capacidad que no se utiliza, con un responsable de validación.

Este ejemplo es hipotético. No afirma que cualquier herramienta de informes funcione con un conjunto concreto de permisos. La decisión depende de cómo esté implementada y de lo que exija su fabricante. El registro debe conservar esa justificación y la evidencia de la prueba.

Desarrollar el caso antes de decidir

En el ejemplo del informe, inventaríe qué lecturas alimentan el resultado y qué operación podría necesitar escritura. Pida al propietario un informe de prueba con datos controlados. Compare contenido, completitud y entrega, no sólo el código de éxito del trabajo. Si el fabricante no documenta un conjunto menor, registre esa limitación y evalúe alternativas; no afirme que la escritura sobra porque el informe final parece de lectura.

Seleccione una ventana que permita ejecutar el ciclo completo. Un ensayo fuera del cierre mensual puede no cubrir una función adicional. Obtenga la aprobación del propietario y conserve el criterio para recuperar el servicio. Una vez modificada la concesión, compare resultados y acceso excluido. Si el ensayo no explica el comportamiento, el hallazgo continúa abierto con responsable. Mantener temporalmente un permiso como excepción requiere motivo, condiciones y una fecha de revisión.

Deje una revisión reutilizable

• Aplicación y recurso identificados sin ambigüedad.
• Propietarios técnico y de negocio confirmados.
• Permisos concedidos y necesidad explicados.
• Decisión, aprobación y pruebas registradas.
• Excepciones abiertas y siguiente revisión asignadas.

Un registro de decisiones, no una lista de nombres

Registre por aplicación y recurso el permiso, contexto, población, necesidad, evidencia y decisión. Para una excepción añada propietario, riesgo aceptado, medidas compensatorias y próxima revisión. Para un cambio añada su identificador, fecha, ejecutor y pruebas. Un estado como «revisado» es insuficiente si no permite distinguir mantener, reducir, revocar o investigar. El siguiente revisor debe poder reconstruir la decisión sin consultar al autor.

Establezca desencadenantes además de una periodicidad: cambio de proveedor, nuevas funciones, ampliación de permisos, salida del propietario o retirada del proceso. Cuando varias integraciones carecen de contexto o tienen acceso amplio sin pruebas, una auditoría especializada puede ordenar el inventario, resolver dependencias y planificar cambios graduales. El resultado esperado es una decisión técnica y operativa verificable, con tareas pendientes visibles y responsables confirmados.

Documentación oficial y alcance

• Microsoft: Application objects and service principals
• Microsoft: User and admin consent
• Microsoft: Review application permissions
• Microsoft: Graph: delegated grants
• Microsoft: Graph: application grants
• Microsoft: Graph permissions reference
• Microsoft: Restore permissions

El método de revisión, la priorización y el ejemplo son recomendaciones de MSAdvance. Las consultas son de lectura y requieren autorización y permisos adecuados. Compruebe las condiciones de cada operación antes de ejecutar cambios.