Administración de identidades y accesos para el acelerador de zona de aterrizaje de Azure Spring Apps
En este artículo se describen las consideraciones de diseño y las recomendaciones para autenticar a los usuarios en Azure Spring Apps y se concede a los usuarios el nivel de acceso necesario a los recursos de carga de trabajo.
El equipo de la plataforma centralizada y los equipos de aplicaciones deben tener una buena comprensión de lo siguiente:
- Qué equipos necesitan acceso a la carga de trabajo de la aplicación Azure Spring implementada en la zona de aterrizaje de aplicaciones.
- Los roles y la responsabilidad de los usuarios y quién necesita acceso.
- Nivel mínimo de privilegio que se necesita para llevar a cabo esas responsabilidades.
Para obtener información sobre el diseño de la plataforma, consulte Área de diseño de administración de identidades y acceso de Azure.
Como propietario de la carga de trabajo, siga estos procedimientos recomendados para garantizar que los recursos de la aplicación no infringen los límites de seguridad o gobernanza de la organización. El objetivo es garantizar que la aplicación Azure Spring implementada y los recursos relacionados de la carga de trabajo sean seguros y solo puedan acceder a ellos los usuarios autorizados. Al seguir estas prácticas, se protegen los datos confidenciales y se evita el uso indebido de la aplicación y sus recursos.
Consideraciones de diseño
Acceso desde la aplicación a otros servicios. La aplicación debe autenticarse cuando se conecta a los servicios backend que forman parte de la carga de trabajo. Esta autenticación protege los servicios de accesos no autorizados. Considere la posibilidad de usar características de Microsoft Entra ID para evitar la sobrecarga de almacenar y administrar credenciales.
Acceso a la aplicación. Los usuarios pueden enviar solicitudes a la aplicación a través de la red pública de Internet. O las solicitudes pueden provenir de redes privadas o locales. En cualquier caso, el acceso debe autenticarse en función de los certificados de cliente o mediante Microsoft Entra.
Tenga en cuenta las opciones de tecnología para el mecanismo de detección de servicios que invoca llamadas entre aplicaciones. Las opciones varían en función del nivel de Azure Spring Apps.
Acceso de operador a los recursos. Los miembros del equipo con diferentes responsabilidades pueden acceder a la carga de trabajo. Por ejemplo, es posible que tenga que conceder acceso a:
- Miembros del equipo de la plataforma que necesitan acceso operativo.
- Miembros del equipo de desarrollo de aplicaciones.
- Ingenieros de DevOps que compilan y liberan canalizaciones para implementar la carga de trabajo y configurar mediante la infraestructura como código (IaC).
- Ingenieros de confiabilidad del sitio para solucionar problemas.
En función del propósito del acceso, decida el nivel de control que quiere proporcionar al usuario. Comience por el principio del menor privilegio. La asignación de funciones RBAC puede garantizar que los usuarios tengan el conjunto de privilegios adecuado para sus responsabilidades y mantener los límites. Considere los roles RBAC incorporados antes de crear roles personalizados.
Acceso a datos de configuración. En función del nivel que elija para Azure Spring Apps (Básico/Estándar o Enterprise), debe decidir las opciones del servidor de configuración.
Para Básico, considere la posibilidad de admitir el servidor y el lado cliente. Para almacenar los archivos del servidor de configuración, elija una configuración externaizada en un sistema distribuido, como Azure DevOps, GitHub, GitLab o Bitbucket.
Puede usar repositorios públicos o privados y elegir su mecanismo de autenticación. Azure Spring Apps admite la autenticación básica basada en contraseñas o en tokens, y SSH.
Para Enterprise, considere la posibilidad de usar Application Configuration Service for VMware Tanzu, que permite la administración de recursos ConfigMap nativos de Kubernetes que se rellenan a partir de las propiedades definidas en uno o varios repositorios de Git.
Recomendaciones de diseño
Identidades administradas
Use identidades administradas para la aplicación a fin de que se autentique mediante Microsoft Entra ID. No todos los servicios admiten esta característica de Microsoft Entra ID. Para más información, consulte Servicios de Azure que admiten la autenticación de Microsoft Entra.
Decida qué tipo de identidad administrada es adecuada para su caso de uso. Tenga en cuenta los inconvenientes respecto a la facilidad de administración. Por ejemplo, si la aplicación necesita acceder a varios recursos, se recomiendan las identidades administradas asignadas por el usuario. Pero si desea permisos vinculados al ciclo de vida de la aplicación, las identidades administradas por el sistema serían más adecuadas.
Para más información, consulte Elección de identidades administradas asignadas por el usuario o sistema.
Use roles de RBAC de Azure integrados para simplificar la administración de los permisos necesarios para una identidad administrada.
- Uso de su propia identidad administrada para Azure Spring Apps.
- Use identidades administradas asignadas por el sistema y asignadas por el usuario por separado. Para más información, consulte Procedimientos recomendados al usar identidades administradas.
- Use Privileged Identity Management en Microsoft Entra ID.
Protección de las comunicaciones de Internet
- Use certificados emitidos por una entidad de certificación, certificados de validación extendidos o certificados comodín.
- Use certificados autofirmados solo para entornos de preproducción.
- Cargue certificados de forma segura desde Azure Key Vault.
Control de acceso basado en roles (RBAC)
- Considere la posibilidad de crear roles personalizados. Siguiendo el principio de privilegios mínimos cuando los roles integrados requieran modificaciones en los permisos existentes.
- Elija almacenamiento de seguridad mejorada para claves, secretos, certificados y configuración de la aplicación.
- Para la implementación automatizada, configure una entidad de servicio que tenga los permisos mínimos necesarios para hacer la implementación desde la canalización de integración continua y entrega continua.
- Habilite el registro de diagnóstico para la consola de aplicaciones, los registros del sistema, los registros de entrada, los registros de compilación y los registros de eventos de contenedor. Puede usar estos registros detallados para diagnosticar problemas con la aplicación y supervisar las solicitudes de acceso. Cuando habilita estos registros, un registro de actividad de Azure Monitor le ofrece información sobre los eventos a nivel de suscripción.