Compartir a través de


Reducción de permisos y aplicaciones con exceso de privilegios

Como desarrollador que pretende diseñar e implementar aplicaciones que siguen los principios rectores de confianza cero, quiere aumentar la seguridad de las aplicaciones con privilegios mínimos. Es fundamental reducir la superficie expuesta a ataques de la aplicación y el efecto de una vulneración de seguridad.

En este artículo, aprenderá por qué las aplicaciones no deben solicitar más permisos de los que necesitan. Comprenderá el término exceso de privilegios y obtendrá recomendaciones y procedimientos recomendados para limitar los privilegios en las aplicaciones, con el fin de administrar el acceso y mejorar la seguridad.

¿Qué significa tener más privilegios?

Se tiene más privilegios cuando una aplicación solicita o recibe más permisos de los que necesita para que funcione correctamente. En el resto de este artículo, mejorará su comprensión del exceso de privilegios con ejemplos de permisos no utilizados y reducibles.

Permisos no usados

Para este ejemplo de llave sin usar, imagine que hay tres puertas cerradas (azul, amarillo y verde), como se muestra en el diagrama siguiente.

En el diagrama se muestran tres puertas con las llaves correspondientes para ilustrar los permisos sin usar.

Sus activos están detrás de las puertas. Tiene tres llaves (azul, amarilla y verde) que le permiten abrir su puerta correspondiente. Por ejemplo, la llave azul puede abrir la puerta azul. Cuando solo necesita acceso a la puerta amarilla, solo lleva la llave amarilla.

Para proteger mejor los activos, solo lleva la llave que necesita cuando las necesita y la mantiene sin usar en una ubicación segura.

Permisos reducibles

El ejemplo de llaves reducibles es más complicado que el ejemplo de llave sin usar. Ahora se agregan dos llaves especiales, como se muestra en el diagrama siguiente.

En el diagrama se muestran tres puertas con las llaves correspondientes para ilustrar los permisos reducibles.

La primera llave negra es una llave de paso que puede abrir todas las puertas. La segunda llave negra puede abrir la puerta amarilla y la verde. Cuando solo necesita acceso a la puerta amarilla y a la verde, solo lleva la segunda llave negra. Mantiene la llave de paso en una ubicación segura con la llave verde redundante.

En el mundo de la identidad de Microsoft, las llaves son permisos de acceso. Los recursos y usted, el titular de la llave, son aplicaciones. Si comprende el riesgo de llevar llaves innecesarias, es consciente del riesgo de que las aplicaciones tengan permisos innecesarios.

Falta de permisos y riesgo

¿Cómo pueden ayudar las puertas y las llaves a comprender cómo se produce el exceso de privilegios? ¿Por qué la aplicación puede tener los permisos adecuados para realizar una tarea, pero seguir teniendo demasiados privilegios? Echemos un vistazo a un déficit de permisos que podría provocar la discrepancia en el diagrama siguiente.

Gráfico a la derecha: eje Y - Permisos, eje X - Tiempo; Curva superior - Permisos concedidos, curva inferior - Permisos usados; Estadísticas a la derecha que se describen en el contenido del artículo.

El eje X representa el tiempo y el eje Y representa los permisos. Al principio del tiempo medido, solicita y recibe permiso para la aplicación. A medida que la empresa crece y cambia con el tiempo, agrega nuevos permisos para satisfacer sus necesidades y aumenta la pendiente de permisos concedidos. Los permisos usados pueden ser inferiores a los permisos concedidos cuando se olvide de quitar permisos innecesarios (por ejemplo, si la aplicación no se interrumpe) lo que da lugar a un déficit de permisos.

Estas son observaciones interesantes en la Plataforma de identidad de Microsoft.

  • Tenemos más de 4000 API en Microsoft Graph.
  • Hay más de 200 permisos de Microsoft Graph disponibles en la Plataforma de identidad de Microsoft.
  • Los desarrolladores tienen acceso a una amplia gama de datos y la capacidad de aplicar granularidad a los permisos que solicitan sus aplicaciones.
  • En nuestras investigaciones, encontramos que las aplicaciones tienen solo un 10 % de permisos totalmente utilizados para sus escenarios.

Piense detenidamente en qué permisos requiere realmente la aplicación. Tenga en cuenta la falta de permisos y compruebe periódicamente los permisos de la aplicación.

Seguridad comprometida por exceso de privilegios

Profundicemos en los riesgos resultantes de la falta de permisos con un ejemplo. Este escenario en peligro consta de dos roles: administrador de TI y desarrollador.

  • Administrador de TI: Jeff es administrador de inquilinos, y garantiza que las aplicaciones de Microsoft Entra ID sean confiables y seguras. Parte del trabajo de Jeff consiste en conceder consentimiento a los permisos que requieren los desarrolladores de aplicaciones.
  • Desarrollador: Kelly es desarrolladora de aplicaciones que usa la Plataforma de identidad de Microsoft y posee aplicaciones. El trabajo de Kelly es garantizar que las aplicaciones tengan los permisos adecuados para realizar las tareas necesarias.

El siguiente escenario de riesgo de seguridad común para el exceso de privilegios normalmente tiene cuatro fases.

Diagrama descrito en el contenido del artículo: cuatro fases de un escenario de riesgo de seguridad.

  1. En primer lugar, el desarrollador empieza a configurar la aplicación y agrega permisos necesarios.
  2. En segundo lugar, el administrador de TI revisa los permisos necesarios y concede consentimiento.
  3. En tercer lugar, el actor malintencionado comienza a descifrar las credenciales de usuario y hackea correctamente la identidad del usuario.
  4. Si el usuario posee varias aplicaciones, también tiene exceso de privilegios. El actor malintencionado puede usar rápidamente el token del permiso concedido para recuperar datos confidenciales.

Aplicaciones con demasiados privilegios

Una entidad tiene exceso de privilegios cuando solicita o recibe más permisos de los que necesita. La definición de aplicación con exceso de privilegios en la plataforma de identidad de Microsoft es "cualquier aplicación con permisos no utilizables o reducibles".

Vamos a usar Microsoft Graph como parte de la Plataforma de identidad de Microsoft en un ejemplo real para comprender mejor el permiso no utilizado y el permiso reducible.

Columna izquierda: sin usar: se conceden uno o varios permisos que no son necesarios para la llamada API que se realiza. Columna derecha: reducible: permiso que tiene una alternativa con privilegios inferiores que seguiría proporcionando el acceso a las tareas necesarias.

El permiso no utilizado se produce cuando la aplicación recibe permisos que no son necesarios para las tareas deseadas. Por ejemplo, va a crear una aplicación de calendario. La aplicación de calendario solicita y recibe el permiso Files.ReadWrite.All. La aplicación no se integra con las API de los archivos. Por lo tanto, la aplicación tiene un permiso Files.ReadWrite.All sin usar.

El permiso reducible es más difícil de detectar. Se produce cuando la aplicación recibe pocos permisos, pero tiene una alternativa con privilegios inferiores que proporcionaría acceso suficiente para las tareas necesarias. En el ejemplo de la aplicación de calendario, la aplicación solicita y recibe el permiso Files.ReadWrite.All. Sin embargo, solo necesita leer archivos del OneDrive del usuario que ha iniciado sesión y nunca necesita crear nuevos archivos ni modificar los existentes. En este caso, la aplicación solo utiliza Files.ReadWrite.All de manera parcial, por lo que debe cambiar a Files.Read.All.

Recomendaciones para reducir escenarios con exceso de privilegios

La seguridad es un recorrido, no un destino. Hay tres fases distintas en el ciclo de vida de seguridad:

  • Prevención
  • Auditoría
  • Corrección

En el diagrama siguiente se muestran recomendaciones para reducir escenarios de exceso de privilegios.

Diagrama descrito en el contenido del artículo: recomendaciones para prevenir, auditar y remediar escenarios con privilegios excesivos.

  • Prevención: al crear una aplicación, debe comprender completamente el permiso necesario para las llamadas API que la aplicación necesita realizar, y solicitar solo lo necesario para habilitar el escenario. La documentación de Microsoft Graph tiene referencias claras para los permisos con privilegios mínimos para la mayoría de los permisos con privilegios para todos los puntos de conexión. Tenga en cuenta los escenarios con exceso de privilegios a medida que determine qué permisos necesita.
  • Auditoría: tanto usted como los administradores de TI deben revisar periódicamente los privilegios concedidos previamente a las aplicaciones existentes.
  • Corrección: si usted o los administradores de TI observan una aplicación con exceso de privilegios en el ecosistema, debería dejar de solicitar tokens para el permiso con exceso de privilegios. Los administradores de TI deberían revocar los consentimientos concedidos. Este paso normalmente requiere un cambio de código.

Procedimientos recomendados para mantener el permiso con privilegios mínimos

Dos incentivos importantes para mantener el permiso con privilegios mínimos con las aplicaciones están impulsando la adopción de la aplicación y deteniendo la propagación.

Columna izquierda: impulsar la adopción: cree una aplicación fiable para los clientes al evitar solicitudes de permisos excesivas. Columna derecha: detenga la propagación: los atacantes no pueden usar privilegios excesivos para obtener más acceso.

  • Aumente la adopción mediante la creación de una aplicación de confianza para los clientes que evita solicitudes de permisos excesivas. Limite los permisos de la aplicación solo a lo que necesita para completar su tarea. Esta práctica reduce el radio de explosión potencial de los ataques y aumenta la adopción del cliente de las aplicaciones. Aplique un examen más exhaustivo al revisar los permisos que solicitan las aplicaciones y decidir si se conceden permisos de aplicación.
  • Detenga la propagación asegurándose de que los atacantes no pueden usar privilegios excesivos para obtener más acceso. Al crear una aplicación que solicite permisos innecesarios, es menos probable que se apruebe y más que se deniegue directamente. La mejor manera de controlar los daños es evitar que los atacantes obtengan privilegios elevados que aumenten el ámbito del riesgo. Por ejemplo, si la aplicación solo tiene User.ReadBasic.All para leer información básica del usuario, su OneDrive, Outlook, Teams y los datos confidenciales están seguros si una aplicación está en peligro.

Pasos siguientes