Procedimientos recomendados para identidades administradas
Las identidades administradas para recursos de Azure es una característica de Microsoft Entra ID. Cada servicio de Azure compatible con Managed Identities for Azure Resources está sujeto a su propia escala de tiempo. Asegúrese de revisar el estado de disponibilidad de las identidades administradas para el recurso y los problemas conocidos antes de comenzar.
Elección de identidades administradas asignadas por el sistema o por el usuario
Las identidades administradas asignadas por el usuario son más eficaces en una gama más amplia de escenarios que las asignadas por el sistema. Consulte la tabla siguiente para ver algunos escenarios y recomendaciones para el uso de identidades administradas asignadas por el usuario o por el sistema.
Varios recursos pueden usar identidades asignadas por el usuario y sus ciclos de vida se desacoplan de los ciclos de vida de los recursos a los que están asociados. Conozca qué recursos admiten identidades administradas.
Este ciclo de vida le permite separar las responsabilidades de creación de recursos y de administración de identidades. Las identidades asignadas por el usuario y sus asignaciones de roles se pueden configurar antes que los recursos que las requieren. Los usuarios que crean los recursos solo requieren el acceso para asignar una identidad asignada por el usuario, sin necesidad de crear nuevas identidades o asignaciones de roles.
A medida que se crean y eliminan identidades asignadas por el sistema junto con los recursos, las asignaciones de roles no se pueden crear de antemano. Esta secuencia puede producir errores al implementar la infraestructura si el usuario que crea el recurso no tiene acceso para crear asignaciones de roles.
Si la infraestructura necesita que varios recursos requieran acceso a los mismos recursos, se les puede asignar una única identidad asignada por el usuario. Se reducirá la sobrecarga de administración, ya que hay menos identidades distintas y asignaciones de roles que administrar.
Si necesita que cada recurso tenga su propia identidad o tiene recursos que requieren un conjunto único de permisos y quiere que la identidad se elimine a medida que se elimina el recurso, deberá usar una identidad asignada por el sistema.
| Escenario | Recomendación | Notas |
|---|---|---|
| Creación rápida de recursos (por ejemplo, informática efímera) con identidades administradas | Identidad asignada por el usuario | Si intenta crear varias identidades administradas en un breve espacio de tiempo (por ejemplo, la implementación de varias máquinas virtuales cada una con su propia identidad asignada por el sistema), puede que supere el límite de velocidad para las creaciones de objetos de Microsoft Entra y se producirá un error HTTP 429 en la solicitud. Si los recursos se crean o eliminan rápidamente, también puede que supere el límite en el número de recursos de Microsoft Entra ID si se usan identidades asignadas por el sistema. Aunque un recurso ya no pueda acceder a una identidad asignada por el sistema eliminada, seguirá contando de cara al límite hasta que se purgue completamente después de 30 días. La implementación de los recursos asociados a una única identidad asignada por el usuario requerirá la creación de una sola entidad de servicio en Microsoft Entra ID, lo que evitará el límite de velocidad. El uso de una identidad única creada de antemano también reducirá el riesgo de retrasos en la replicación que podrían producirse si se crean varios recursos cada uno con su propia identidad. Obtenga más información sobre los límites del servicio de suscripción de Azure. |
| Recursos y aplicaciones replicados | Identidad asignada por el usuario | Los recursos que llevan a cabo la misma tarea (por ejemplo, servidores web duplicados o una funcionalidad idéntica que se ejecuta en un servicio de aplicaciones y en una aplicación en una máquina virtual) normalmente requieren los mismos permisos. Al usar la misma identidad asignada por el usuario, se requieren menos asignaciones de roles, lo que reduce la sobrecarga administrativa. Los recursos no tienen que ser del mismo tipo. |
| Cumplimiento normativo | Identidad asignada por el usuario | Si su organización requiere que toda la creación de identidades pase por un proceso de aprobación, el uso de una única identidad asignada por el usuario en varios recursos requerirá menos aprobaciones que en el caso de las identidades asignadas por el sistema, que se crean a medida que se crean nuevos recursos. |
| Acceso necesario antes de implementar un recurso | Identidad asignada por el usuario | Algunos recursos pueden requerir acceso a determinados recursos de Azure como parte de su implementación. En este caso, es posible que no se cree una identidad asignada por el sistema a tiempo, por lo que se debe usar una identidad asignada por el usuario que ya exista. |
| Registro de auditoría | Identidad asignada por el sistema | Si necesita registrar qué recurso específico realizó una acción, en lugar de qué identidad, use una identidad asignada por el sistema. |
| Administración del ciclo de vida de permisos | Identidad asignada por el sistema | Si necesita que se quiten los permisos de un recurso junto con este, use una identidad asignada por el sistema. |
Uso de identidades asignadas por el usuario para reducir la administración
Los diagramas muestran la diferencia entre las identidades asignadas por el sistema y por el usuario, cuando se usan para permitir que varias máquinas virtuales accedan a dos cuentas de almacenamiento.
El diagrama muestra cuatro máquinas virtuales con identidades asignadas por el sistema. Cada máquina virtual tiene las mismas asignaciones de roles que les conceden acceso a dos cuentas de almacenamiento.
Cuando una identidad asignada por el usuario está asociada a las cuatro máquinas virtuales, solo se requieren dos asignaciones de roles, en comparación con las ocho de las identidades asignadas por el sistema. Si la identidad de las máquinas virtuales requiere más asignaciones de roles, se concederán a todos los recursos asociados a esta identidad.
Los grupos de seguridad también se pueden usar para reducir el número de asignaciones de roles necesarias. En este diagrama se muestran cuatro máquinas virtuales con identidades asignadas por el sistema que se han agregado a un grupo de seguridad, con las asignaciones de roles agregadas al grupo en lugar de las identidades asignadas por el sistema. Aunque el resultado es similar, esta configuración no ofrece las mismas funcionalidades de la plantilla de Resource Manager que las identidades asignadas por el usuario.
Varias identidades administradas
Los recursos que admiten identidades administradas pueden tener una identidad asignada por el sistema y una o varias identidades asignadas por el usuario.
Este modelo proporciona la flexibilidad de usar una identidad compartida asignada por el usuario y aplicar permisos específicos cuando es necesario.
En el ejemplo siguiente, "Virtual Machine 3" y "Virtual Machine 4" pueden acceder a las cuentas de almacenamiento y a los almacenes de claves, según la identidad asignada por el usuario que usen durante la autenticación.
En el ejemplo siguiente, "Virtual Machine 4" tiene una identidad asignada por el usuario, lo que le proporciona acceso a las cuentas de almacenamiento y a los almacenes de claves, según la identidad que se utilice durante la autenticación. Las asignaciones de roles para la identidad asignada por el sistema son específicas de esa máquina virtual.
Límites
Vea los límites de las identidades administradas y de los roles personalizados y asignaciones de roles.
Cumplimiento del principio de privilegios mínimos al conceder acceso
Al conceder a cualquier identidad, incluida una identidad administrada, los permisos para acceder a los servicios, conceda siempre los permisos mínimos necesarios para realizar las acciones deseadas. Por ejemplo, si se usa una identidad administrada para leer datos de una cuenta de almacenamiento, no es necesario permitir que esa identidad tenga permisos para escribir también datos en la cuenta de almacenamiento. Conceder permisos adicionales, como por ejemplo convertir la identidad administrada en colaboradora en una suscripción de Azure cuando no es necesario, aumenta el radio de impacto de seguridad asociado a la identidad. Siempre se debe minimizar el radio de impacto de seguridad para que, si se pone en peligro esa identidad, se causen los daños mínimos.
Tenga en cuenta el efecto de asignar identidades administradas a recursos de Azure o conceder permisos de asignación a un usuario.
Es importante tener en cuenta que cuando se asigna una identidad administrada a un recurso de Azure, como una aplicación lógica de Azure, una función de Azure, una máquina virtual, etc., todos los permisos concedidos a la identidad administrada ahora están disponibles para el recurso de Azure. Esto es importante porque si un usuario tiene acceso para instalar o ejecutar código en este recurso, el usuario tiene acceso a todas las identidades asignadas o asociadas al recurso de Azure. El propósito de la identidad administrada es proporcionar al código que se ejecuta en un recurso de Azure acceso a otros recursos, sin necesidad de que los desarrolladores manipulen o introduzcan las credenciales directamente en el código para obtener ese acceso.
Por ejemplo, si a una identidad administrada (ClientId = 1234) se le ha concedido acceso de lectura y escritura a StorageAccount7755 y se ha asignado a LogicApp3388, Alice, que no tiene acceso directo a la cuenta de almacenamiento, pero tiene permiso para ejecutar código en LogicApp3388, también puede leer o escribir datos en o desde StorageAccount7755 mediante la ejecución del código que usa la identidad administrada.
Del mismo modo, si Alice tiene permisos para asignar la identidad administrada, puede asignarla a otro recurso de Azure y tener acceso a todos los permisos disponibles para la identidad administrada.
En general, al conceder a un usuario acceso administrativo a un recurso que puede ejecutar código (como una aplicación lógica) y tiene una identidad administrada, tenga en cuenta si el rol que se asigna al usuario puede instalar o ejecutar código en el recurso y, en caso afirmativo, asigne ese rol solo si el usuario realmente lo necesita.
Mantenimiento
Las identidades asignadas por el sistema se eliminan automáticamente cuando se elimina el recurso, mientras que el ciclo de vida de una identidad asignada por el usuario es independiente de los recursos a los que está asociada.
Tendrá que eliminar manualmente una identidad asignada por el usuario cuando ya no sea necesaria, incluso si no hay recursos asociados a ella.
Las asignaciones de roles no se eliminan automáticamente cuando se eliminan las identidades administradas asignadas por el sistema o por el usuario. Estas asignaciones de roles se deben eliminar manualmente para que no se supere el límite de asignaciones de roles por suscripción.
Las asignaciones de roles asociadas a identidades administradas eliminadas se mostrarán con "Identidad no encontrada" cuando aparezcan en el portal. Más información.
Las asignaciones de roles que ya no están asociadas a un usuario o entidad de servicio aparecerán con un valor ObjectType de Unknown. Para quitarlas, puede canalizar varios comandos de Azure PowerShell para obtener primero todas las asignaciones de roles, filtrar solo a aquellas con un valor ObjectType de Unknown y, después, quitar esas asignaciones de roles de Azure.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Limitación del uso de identidades administradas para la autorización
El uso de grupos de Microsoft Entra ID para conceder acceso a los servicios es una excelente manera de simplificar el proceso de autorización. La idea es sencilla: conceder permisos a un grupo y agregar identidades al grupo para que hereden los mismos permisos. Se trata de un patrón bien establecido de varios sistemas locales y funciona bien cuando las identidades representan a los usuarios. Otra opción para controlar la autorización en Microsoft Entra ID es usando roles de aplicación, lo que permite declarar roles específicos de una aplicación (en vez de los grupos, que son un concepto global en el directorio). Después, puede asignar los roles de aplicación a identidades administradas (así como a usuarios o grupos).
En ambos casos, para las identidades no humanas, como las aplicaciones y las identidades administradas de Microsoft Entra, el mecanismo exacto de cómo se presenta esta información de autorización a la aplicación no es ideal en la actualidad. La implementación actual con Microsoft Entra ID y el control de acceso basado en roles de Azure (RBAC de Azure), usa tokens de acceso emitidos por Microsoft Entra ID para la autenticación de cada identidad. Si la identidad se agrega a un grupo o rol, se expresa como notificaciones en el token de acceso emitido por Microsoft Entra ID. RBAC de Azure usa estas notificaciones para evaluar aún más las reglas de autorización para permitir o denegar el acceso.
Dado que los grupos y roles de la identidad son notificaciones en el token de acceso, los cambios de autorización no tienen efecto hasta que se actualiza el token. Para un usuario humano, eso normalmente no es un problema, porque un usuario puede adquirir un nuevo token de acceso cerrando sesión e iniciándola de nuevo (o esperando a que expire la duración del token, que de forma predeterminada es de 1 hora). Por otro lado, la infraestructura subyacente de Azure almacena en caché los tokens de identidad administrada con fines de rendimiento y resistencia: los servicios back-end para identidades administradas mantienen una caché por URI de recurso durante unas 24 horas. Esto significa que los cambios en la pertenencia a grupos o roles de una identidad administrada pueden tardar varias horas en tener efecto. En la actualidad, no es posible forzar la actualización del token de una identidad administrada antes de su expiración. Si cambia la pertenencia a grupos o roles de una identidad administrada para agregar o quitar permisos, es posible que tenga que esperar varias horas a que el recurso de Azure que usa la identidad tenga el acceso correcto.
Si este retraso no es aceptable para sus requisitos, considere alternativas al uso de grupos o roles en el token. Para asegurarse de que los cambios en los permisos de las identidades administradas se apliquen rápidamente, se recomienda agrupar los recursos de Azure mediante una identidad administrada asignada por el usuario con los permisos aplicados directamente a la identidad, en lugar de agregar o quitar identidades administradas de un grupo de Microsoft Entra que tenga los permisos. Una identidad administrada asignada por el usuario se puede usar como un grupo porque se puede asignar a uno o varios recursos de Azure para usarla. La operación de asignación se puede controlar mediante el rol Colaborador de identidad administrada y el rol Operador de identidad administrada.