Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
A medida que aprenda a desarrollar con principios de confianza cero, consulte este artículo después de la revisión 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 la aplicación siempre recibe sus permisos asignados previamente.
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 sofisticado sistema de administración de secretos.
- Al desarrollar sus servicios en Azure, utilice Managed Identities for Azure Resources (Identidades administradas para recursos de Azure), revise la sección siguiente, Administración de credenciales de aplicación.
La aplicación siempre requiere consentimiento previo del administrador. La aplicación solicita este permiso con el
.defaultámbito. Solicita los permisos que el administrador asigna a la aplicación.Funcionalidad para usuarios trans. De forma predeterminada,
User.ReadWrite.Allpermite que la aplicación actualice 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 maneras de limitar una aplicación a un acceso menor que el 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 Microsoft Teams y microsoft Graph API 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 su consentimiento para que su aplicación pueda acceder y modificar sus datos de Teams y Chat.
Para limitar el acceso de aplicaciones a buzones específicos con un script de PowerShell, los administradores de Microsoft Exchange pueden crear directivas de aplicación de Exchange. Pueden limitar una aplicación determinada a buzones específicos con acceso a
Calendar.ReadoMail.Read. Esto le permite, por ejemplo, crear una automatización que solo pueda leer un buzón o enviar correo desde un buzón y no desde todos los miembros de la empresa.Para permitir permisos granulares para acceder a SharePoint con una aplicación, SharePoint tiene Sites.Selected como ámbito específico. Elija
Sites.Selectedpara la aplicación en lugar de uno de los otros resultados de permisos, de forma predeterminada, en aplicaciones sin acceso a colecciones de sitios de SharePoint. El administrador usa el endpoint de permisos de sitio para conceder permisos de lectura, escritura o lectura y escritura a su 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 infracció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.
Quite todos los secretos del código y la configuración. Al usar 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 quitar y rotar secretos y certificados sin quitar 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, desarrolle o use un proceso seguro de implementación sin intervención manual y de rotación para ellos. 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.
Implementar 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 la estrategia de permisos delegados le ayuda a implementar el mejor enfoque para administrar permisos en la aplicación y desarrollar con 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.
- Los permisos de solicitud que requieren consentimiento administrativo describen 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.