Consideraciones sobre la administración de acceso e identidades para el acelerador de zonas de aterrizaje de los Servicios de integración Azure
Este artículo se basa en la orientación proporcionada en el artículo sobre la zona de aterrizaje de Azure Área de diseño de la zona de aterrizaje de Azure para la administración de acceso e identidades. Las indicaciones proporcionadas en el siguiente artículo le ayudarán a identificar las consideraciones y recomendaciones de diseño relacionadas con la administración de acceso e identidades específicas para la implementación de Servicios de integración Azure (AIS). Si AIS se implementa para ser compatible con plataformas de misión crítica, la orientación sobre las áreas de diseño de la zona de aterrizaje de Azure también debe estar incluida en su diseño.
Introducción a la administración de acceso e identidades (IAM)
A efectos de este artículo, la administración de acceso e identidades (IAM) hace referencia a las opciones de autenticación y autorización disponibles para implementar o mantener recursos dentro de Azure. En la práctica, esto implica identificar qué identidades tienen permiso para crear, actualizar, eliminar y administrar recursos a través de Azure Portal o a través de la API de Resource Manager.
IAM es una consideración independiente de la seguridad de los puntos de conexión, que define qué identidades pueden llamar a los servicios y acceder a ellos. La seguridad de los puntos de conexión se trata en el artículo Seguridad independiente de esta serie. Dicho esto, a veces las dos áreas de diseño se superponen: para algunos servicios de Azure, el acceso al punto de conexión se configura a través de los mismos controles RBAC que se usan para administrar el acceso a los recursos.
Consideraciones de diseño
Determine los límites de administración de recursos de Azure para los recursos que implemente, teniendo en cuenta la separación de tareas y la eficacia operativa.
Revise las actividades de administración y supervisión de Azure que deben llevar a cabo los equipos. Tenga en cuenta los recursos de AIS que implementará y cómo los usará. Determine el mejor reparto posible de responsabilidades dentro de la organización.
Recomendaciones de diseño
Uso de identidades administradas para recursos de Integration Services: consulte el artículo Seguridad de esta serie para obtener una descripción detallada de esta recomendación.
Use Microsoft Entra ID para la autenticación en los recursos de servicios de integración.
Tenga en cuenta el nivel de acceso necesario para los roles de su organización y aplique el principio de privilegios mínimos por rol. Estos roles pueden incluir propietarios de plataformas, propietarios de cargas de trabajo, ingenieros de devops y administradores del sistema, por ejemplo.
Con el principio de privilegios mínimos, tenga en cuenta los roles que necesitará para administrar y mantener las aplicaciones de AIS. Preguntas que se van a formular a este respecto:
¿Quién necesitará ver los archivos de registro de orígenes como Application Insights, Log Analytics y cuentas de almacenamiento?
¿Alguien necesita ver los datos de solicitud originales (incluidos los datos confidenciales)?
¿Desde dónde se pueden ver los datos de la solicitud original (por ejemplo, solo desde su red corporativa)?
¿Quién puede ver el historial de ejecución de un flujo de trabajo?
¿Quién puede volver a enviar una ejecución con errores?
¿Quién necesita acceder a las claves de suscripción de API Management?
¿Quién puede ver el contenido de un tema o una suscripción de Service Bus, o ver las métricas de cola o tema?
¿Quién debe ser capaz de administrar Key Vault?
¿Quién debe poder agregar, editar o eliminar claves, secretos y certificados en Key Vault?
¿Quién debe poder ver y leer claves, secretos o certificados en Key Vault?
¿Los roles y grupos integrados de Microsoft Entra existentes cubren los requisitos que ha identificado?
Cree roles personalizados para limitar el acceso o para proporcionar más granularidad sobre los permisos cuando los roles incorporados no bloqueen suficientemente el acceso. Por ejemplo, el acceso a la URL de devolución de llamada de una aplicación lógica requiere un único permiso, pero no hay ningún rol incorporado para ese tipo de acceso que no sea "Colaborador" o "Propietario", que son demasiado amplios.
Examine el uso de Azure Policy para restringir el acceso a determinados recursos o para aplicar el cumplimiento de la directiva de la empresa. Por ejemplo, puede crear una directiva que solo permita la implementación de API de API Management que usen protocolos cifrados.
Revise las actividades comunes implicadas en la administración y gestión de AIS en Azure y asigne los permisos RBAC adecuadamente. Para más detalles sobre los permisos disponibles, consulte Operaciones del proveedor de recursos.
Algunos ejemplos de actividades comunes de administración de Azure son:
| Recurso de Azure | Proveedor de recursos de Azure | Actividades |
|---|---|---|
| Plan de servicio de aplicación | Microsoft.Web/serverfarms | Leer, unir, reiniciar, obtener conexiones de red virtual |
| API Connection | Microsoft.Web/connections | Actualizar, confirmar |
| Logic Apps y Functions | Microsoft.Web/sites | Leer, iniciar, detener, reiniciar, intercambiar, actualizar configuración, leer diagnósticos, obtener conexiones de red virtual |
| Integration Account | Microsoft.Logic/integrationAccounts | Leer/añadir/actualizar/eliminar conjuntos, Leer/añadir/actualizar/eliminar mapas, Leer/añadir/actualizar/eliminar esquemas, Leer/añadir/actualizar/eliminar contratos, Leer/añadir/actualizar/eliminar partners |
| Service Bus | Microsoft.ServiceBus | Leer, obtener cadena de conexión, actualizar configuración de DR, leer colas, leer temas, leer suscripciones |
| Cuenta de almacenamiento | Microsoft.Storage/storageAccounts | Leer, cambiar (por ejemplo, historial de ejecución de flujo de trabajo) |
| API Management | Microsoft.ApiManagement | Registrar/eliminar un usuario, leer API, administrar autorizaciones, administrar caché |
| KeyVault | Microsoft.KeyVault/vaults | Crear un almacén, editar directivas de acceso |
Paso siguiente
Revise las áreas de diseño críticas para realizar consideraciones y recomendaciones completas de la arquitectura.