Cómo ver qué aplicaciones tienen acceso a su Microsoft 365

Puede ver todas las aplicaciones con acceso a su tenant de Microsoft 365 desde el centro de administración de Microsoft Entra, en Identity → Applications → Enterprise applications → All applications. Al seleccionar una aplicación y abrir su pestaña Permissions se muestra exactamente a qué datos de Microsoft Graph puede acceder, divididos en permisos aprobados por los administradores de su organización y permisos que usuarios individuales aprobaron para sí mismos.

Esta guía cubre esa ruta en su totalidad, la distinción entre consentimiento de administrador y consentimiento de usuario que suele confundir a la gente, y lo que una revisión aplicación por aplicación no puede decirle.

¿Dónde encuentro la lista de aplicaciones con acceso en Entra?

1. Inicie sesión en entra.microsoft.com con una cuenta que tenga al menos el rol de Cloud Application Administrator o Application Administrator.
2. Vaya a Identity → Applications → Enterprise applications → All applications.
3. Seleccione la aplicación que desea revisar y luego abra Permissions.

Esto muestra todas las aplicaciones que se agregaron a su tenant mediante consentimiento de usuario o de administrador, incluyendo asistentes de IA, bots de reuniones y extensiones de productividad que se conectan a través de la plataforma de identidad de Microsoft, junto con aplicaciones de línea de negocio. La lista abarca tanto aplicaciones propias de Microsoft como registros de terceros, por lo que vale la pena desplazarse más allá de los nombres conocidos para ver qué más ha ido acumulando permisos con el tiempo sin llamar la atención.

¿Cuál es la diferencia entre consentimiento de administrador y consentimiento de usuario?

La pestaña Permissions se divide en dos:

• Admin consent — permisos concedidos para toda la organización por un administrador. Estos se aplican a todos los usuarios que abarque la concesión, no solo a la persona que hizo clic para aceptar.
• User consent — permisos que un individuo aprobó para sí mismo, una persona a la vez, sin intervención de un administrador (cuando la configuración de consentimiento de su tenant lo permite).

Al seleccionar cualquier permiso de la lista se abre un panel de Permission Details que describe exactamente lo que permite.

¿Cómo revoco el acceso de una aplicación?

Para una concesión de admin consent: abra el permiso en la lista, seleccione el control … junto a él y elija Revoke permission; esto funciona directamente en el portal.

Para una concesión de user consent, el portal no tiene un botón de revocación. Retirarla requiere una llamada a la API de Microsoft Graph (DELETE /oAuth2PermissionGrants/{id} para permisos delegados, o la llamada equivalente appRoleAssignments para permisos de aplicación) o el cmdlet de PowerShell correspondiente, ejecutado por alguien con el rol de Cloud Application Administrator. Revocar una concesión tampoco impide que el mismo usuario vuelva a otorgar consentimiento la próxima vez que la aplicación lo solicite; para evitar eso hay que cambiar por separado la política de consentimiento del tenant, en Enterprise apps → Consent and permissions → User consent settings.

¿Qué ocurre cuando un usuario se encuentra con un permiso que no puede otorgar por sí mismo?

Si un tenant restringe el consentimiento de usuario, una persona que intenta iniciar sesión en una aplicación que solicita un permiso por encima de ese límite se topa con un bloqueo en lugar de una concesión. Un Global Administrator puede activar el admin consent workflow en Enterprise apps → Consent and permissions → Admin consent settings, lo que permite a esa persona enviar una solicitud en su lugar: se envía por correo electrónico a los usuarios, grupos o roles designados como revisores, quienes pueden aprobarla, bloquearla o denegarla desde su pestaña My Pending. Solo un Global Administrator puede aprobar una solicitud de permisos de aplicación de Microsoft Graph; ser designado revisor no otorga ese privilegio por sí solo. Cada solicitud también expira tras un número configurable de días, de modo que una solicitud sin revisar no queda abierta indefinidamente.

¿Qué pasa si mi organización abarca varios tenants de Microsoft 365 o un directorio de socios?

Una revisión dentro de un tenant solo muestra ese tenant. Si su organización trabaja en más de un directorio de Microsoft 365 —una empresa matriz y una subsidiaria adquirida, por ejemplo, o el propio tenant de un socio—, cada uno requiere este mismo procedimiento por separado, iniciando sesión con el rol correcto en cada caso. Las herramientas diseñadas para un único tenant fijo dejan de funcionar en cuanto se agrega un segundo directorio al panorama, por lo que cualquier herramienta pensada para cubrir más de un tenant debe admitir el consentimiento desde el directorio propio de cualquier organización, no solo el que se configuró originalmente.

¿Qué no puede decirle una revisión aplicación por aplicación, y cómo responde 8200.dev a eso?

Revisar las Enterprise applications una por una le dice qué puede alcanzar cada aplicación *según lo permitido*. No clasifica las aplicaciones según el riesgo real que representan, no señala qué concesiones se han quedado obsoletas y no permanece estática mientras usted avanza en la lista: puede aparecer un nuevo consentimiento mientras todavía está revisando el anterior. El conector de Microsoft 365 de 8200.dev lee Sites, Files, Directory, Application registrations, Users, políticas de seguridad del tenant, informes de registro de MFA, registros de auditoría, asignaciones de roles y concesiones de permisos delegados —todo mediante ámbitos de Graph de solo lectura— y los convierte en un inventario único, actualizado de forma continua y clasificado por riesgo, en lugar de una lista que hay que volver a abrir manualmente. Ese mismo acceso de solo lectura también ejecuta una auditoría de configuración de todo el tenant junto con el inventario de aplicaciones: el estado de Security Defaults y de las políticas de Conditional Access, la política de consentimiento de aplicaciones y la configuración de colaboración externa, de modo que una aplicación con permisos excesivos y una política del tenant demasiado permisiva que la dejó entrar aparecen juntas en lugar de en dos revisiones separadas. Se conecta de la misma manera al directorio de trabajo o escolar propio de Microsoft de cualquier organización, de modo que un grupo que abarque más de un tenant no necesita una configuración distinta para cada uno. Todos los ámbitos aquí son de solo lectura: nada cambia un permiso ni una política a menos que la organización decida por separado automatizar una acción específica.

Consulte la lista completa de conectores para ver cómo encaja esto junto a Google Workspace, Slack y GitHub.