Desarrollo de la estrategia de permisos de aplicación

A medida que aprenda a desarrollar mediante principios de confianza cero, consulte este artículo después de revisar Adquisición de autorización para acceder a los recursos y Desarrollo de la estrategia de permisos delegados. Defina el enfoque de permisos de aplicación para la administración de credenciales cuando use la Plataforma de identidad de Microsoft para autenticar y autorizar las aplicaciones y administrar permisos y consentimiento.

Cuando no hay ningún usuario implicado, no tiene un modelo de permisos efectivo porque a su aplicación siempre se le conceden sus permisos preasignados.

• La aplicación demuestra que es la aplicación que solicita permiso. La aplicación demuestra su propia identidad con uno de los métodos siguientes:

  • Un certificado, que es la mejor opción
  • Un secreto en un sistema de administración de secretos sofisticado
  • cuando desarrolle los servicios en Azure, use Identidades administradas para recursos de Azure, revise la siguiente sección Administración de credenciales de aplicación.

• La aplicación siempre requiere consentimiento previo del administrador. La aplicación solicita este permiso con el ámbito de .default. Solicita los permisos que el administrador asigna a la aplicación.

• Funcionalidad transusuario. De forma predeterminada, User.ReadWrite.All permite a la aplicación actualizar el perfil de cada usuario. Como permiso de aplicación, permite que la aplicación lea y actualice el perfil de todos los usuarios del inquilino.

• Los permisos concedidos a la aplicación siempre son los permisos usados. A diferencia de un permiso delegado, los permisos de aplicación no están enlazados por lo que puede hacer ningún usuario determinado.

Limitar los permisos de aplicación

Hay tres formas de limitar una aplicación a un acceso inferior al global.

• Las aplicaciones de Microsoft Teams tienen consentimiento específico del recurso (RSC) que permite a una aplicación acceder a un equipo específico en lugar de acceder a todos los equipos de la empresa. RSC es una integración de API de Microsoft Teams y Microsoft Graph que permite a la aplicación usar puntos de conexión de API y administrar recursos específicos. Su modelo de permisos permite a los propietarios de Teams y Chat conceder consentimiento para que la aplicación acceda y a sus datos de Teams y Chat, y los modifique.

• Los administradores de Microsoft Exchange pueden crear directivas de aplicación de Exchange para limitar el acceso de la aplicación a buzones específicos con un script de PowerShell. Pueden limitar una aplicación determinada a buzones específicos con acceso Calendar.Read o Mail.Read. Esto le permite, por ejemplo, crear una automatización que solo pueda leer un buzón o enviar correos desde un buzón y no desde todos los miembros de la empresa.

• SharePoint tiene Sites.Selected como ámbito específico para permitir permisos granulares a fin de acceder a SharePoint con una aplicación. Elegir Sites.Selected para la aplicación en lugar de uno de los otros resultados de permisos, de forma predeterminada, en la aplicación no tiene acceso a ninguna colección de sitios de SharePoint. El administrador usa el punto de conexión de permisos de sitio para conceder permisos de lectura, escritura o lectura y escritura a la aplicación.

Administración de credenciales de aplicaciones

La higiene de credenciales puede garantizar que la aplicación se recupere rápidamente de una posible vulneración. Los siguientes procedimientos recomendados le guían en el desarrollo de aplicaciones que llevan a cabo la detección y corrección, a la vez que evitan el tiempo de inactividad y afectan a los usuarios legítimos. Estas recomendaciones admiten el principio de Confianza cero de asumir la vulneración en la preparación para responder a un incidente de seguridad.

• Elimine todos los secretos del código y la configuración. Cuando use la plataforma Azure, coloque secretos en Key Vault y acceda a ellos a través de identidades administradas para recursos de Azure. Haga que el código sea resistente para controlar las rotaciones de secretos si se produce un riesgo. Los administradores de TI pueden eliminar y rotar secretos y certificados sin retirar la aplicación o afectar a los usuarios legítimos.

• Use certificados en lugar de secretos de cliente a menos que haya un proceso seguro para administrar secretos. Los atacantes saben que los secretos de cliente tienden a controlarse de forma menos segura y es difícil realizar un seguimiento del uso de secretos filtrados. Los certificados se pueden administrar y revocar mejor si están en peligro. Al usar secretos, cree o use un proceso seguro de implementación no táctil y sustitución. Use secretos con un período de tiempo de expiración establecido (por ejemplo, un año, dos años) y evite que nunca expire.

• Implemente periódicamente certificados y secretos para crear resistencia en la aplicación y evitar interrupciones debido a una sustitución de emergencia.

Pasos siguientes

• Adquirir autorización para acceder a los recursos le ayuda a comprender cómo garantizar mejor Confianza cero al adquirir permisos de acceso a recursos para la aplicación.
• Desarrollar estrategia de permisos delegados le ayuda a implementar el mejor enfoque para administrar permisos en la aplicación y desarrollar mediante principios de confianza cero.
• Procedimientos recomendados de autorización le ayuda a implementar los mejores modelos de autorización, permisos y consentimiento para las aplicaciones.
• Solicitar permisos que requieren consentimiento administrativo describe la experiencia de permisos y consentimiento cuando los permisos de aplicación requieren consentimiento administrativo.
• En el artículo Protección de API se describen los procedimientos recomendados para proteger la API mediante su registro, la definición de permisos y del consentimiento, y la aplicación del acceso para lograr los objetivos de confianza cero.
• Proporcionar credenciales de identidad de aplicación cuando no hay ningún usuario explica por qué Identidades administradas para recursos de Azure es la mejor práctica de credenciales de cliente para servicios (aplicaciones que no son de usuario) en Azure.