Si su aplicación, función, máquina virtual o trabajo de automatización aún inicia sesión Azur con un nombre de usuario y un secreto, agrega una sobrecarga operativa y de seguridad evitable cada vez que alguien lo almacena, lo copia, lo rota u olvida que existe. Identidades administradas son la opción limpia: Azure retiene la credencial, la rota automáticamente y usted nunca la ve.

Este tutorial le guiará en la creación de una identidad administrada para su carga de trabajo de Azure y en cómo otorgarle exactamente el rol que necesita. Habilitará la identidad, asignará un rol de alcance limitado, validará que su carga de trabajo pueda obtener un token y eliminará el secreto anterior. tú también pondrás Gestión de identidad privilegiada (PIM) alrededor de los humanos que administran la carga de trabajo para que nada tenga privilegios permanentes cuando haya terminado.

Requisitos previos

Si desea seguir la práctica, necesitará:

Implementación de la identidad administrada

Esta es la parte que la mayoría de los equipos quieren apresurar. No. La configuración funciona cuando primero se crea la identidad, se asigna de forma restringida, se valida y solo después se elimina el antiguo secreto. Es extraño cómo eso sigue funcionando.

Información clave: la pregunta no es “¿Qué identidad parece moderna?” La pregunta es “¿Qué identidad coincide con el ciclo de vida de la carga de trabajo sin dejar ningún secreto?”

Esa pregunta sobre el ciclo de vida impulsa el resto de la configuración.

Asignado por el sistema versus asignado por el usuario

Identidades administradas venir en dos formas:

Utilice la asignación del sistema cuando la identidad deba morir con la carga de trabajo. Utilice la asignada por el usuario cuando necesite la misma identidad en varios recursos o una identidad estable antes de la implementación. Esa elección parece aburrida hasta que necesitas cambiarla más tarde.

Paso 1: encuentre lo que ya existe

Antes de crear algo, verifique qué identidades administradas ya existen en el inquilino. Desea evitar colisiones de nombres y comprender qué alcance ya está en uso.

az rest --method get --url 'https://graph.microsoft.com/v1.0/servicePrincipals?$filter=(servicePrincipalType eq '\''ManagedIdentity'\'')'

Esa consulta devuelve todas las identidades administradas del inquilino. Es útil cuando necesitas encontrar identidades existentes en lugar de adivinar qué equipo las nombró. prod-app y lo dejó allí.

Luego verifique las asignaciones de roles en el alcance que planea usar:

az role assignment list \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg-name> \
  --fill-principal-name false \
  -o table

Eso muestra lo que ya está asignado en el alcance del grupo de recursos. --fill-principal-name false evita que el comando realice búsquedas de gráficos adicionales que no necesita durante una pasada de revisión.

Paso 2: crear o habilitar la identidad administrada

Si la carga de trabajo necesita una identidad reutilizable, primero cree una identidad administrada asignada por el usuario:

az identity create \
  --name uai-ordering-api \
  --resource-group rg-shared-identities \
  --location eastus

Esto te da una principalId para RBAC y un clientId para la selección del tiempo de ejecución. Si la carga de trabajo debe ser propietaria de su ciclo de vida de identidad, habilite una identidad asignada por el sistema en el recurso de Azure en lugar de crear una independiente.

Paso 3: otorgar el rol útil más pequeño

Ahora vincule la identidad a los datos exactos que necesita. Para una aplicación respaldada por Key Vault, eso generalmente significa una función de datos con alcance de almacén, no acceso a toda la suscripción.

principalId=$(az identity show \
  --name uai-ordering-api \
  --resource-group rg-shared-identities \
  --query principalId -o tsv)

Esto extrae la identidad administrada. principalId para que puedas asignar el rol en el siguiente paso.

az role assignment create \
  --assignee-object-id "$principalId" \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.KeyVault/vaults/<vault-name>

Usuario de secretos de Key Vault es una función del plano de datos. Eso importa. El acceso al plano de control y el acceso al plano de datos no son lo mismo, y mezclarlos es la forma en que las personas accidentalmente entregan a una aplicación mucha más potencia de la que necesita.

Mantenga el alcance tan limitado como lo permita la carga de trabajo. El alcance de la suscripción es un último recurso, no un atajo.

Paso 4: Validar el acceso basado en tokens

Una vez asignada la identidad, pruébela desde el recurso de Azure que realmente ejecuta la carga de trabajo: el host de la carga de trabajo. Ese host es cualquier recurso de Azure que tenga adjunta la identidad administrada: una máquina virtual, una instancia de App Service, una aplicación de función o similar. En una máquina virtual, Azure App Service u otro recurso de Azure con una identidad administrada, use az login --identity. Si utiliza una identidad asignada por el usuario, especifique explícitamente el ID del cliente o el ID del recurso.

az login --identity --client-id <user-assigned-client-id>

Esto le indica a la CLI de Azure que inicie sesión con la identidad asignada por el usuario adjunta al host de carga de trabajo en lugar de con su cuenta personal.

az account get-access-token --resource https://vault.azure.net --query expiresOn -o tsv

Esto solicita a la CLI de Azure un token de Key Vault e imprime el tiempo de vencimiento, lo que confirma que la identidad administrada realmente puede generar un token para el servicio de destino.

Para el código de aplicación, el Credencial de Azure predeterminada La ruta es la forma normal en que las bibliotecas de Azure Identity cambian a la identidad administrada en producción sin cambiar la lógica de la aplicación.

Paso 5: eliminar el secreto

No deje el secreto del antiguo cliente en su lugar porque todavía está ahí.

Su limpieza debería ser simple:

• Elimine el secreto o la contraseña del cliente del registro de aplicación.

• Elimine el secreto de su almacén, variables de CI y archivos de implementación.

• Rote las credenciales dependientes que puedan haberla copiado.

• Vuelva a ejecutar la validación de la carga de trabajo después de la eliminación.

Si la aplicación aún funciona después de que desaparezca el secreto, habrá terminado con la pieza de implementación.

Ponga PIM alrededor de los humanos

Las identidades administradas protegen la carga de trabajo. Gestión de identidad privilegiada (PIM) asegura al pueblo. Necesitas ambos si quieres un privilegio permanente cero en lugar de un privilegio permanente más bonito.

A nadie le gusta esta sección porque genera fricción donde la gente está acostumbrada a la comodidad. Esa fricción es el control.

Utilice PIM para:

• Hacer Owner y User Access Administrator elegible, no permanentemente activo.

• Mantenga breves las ventanas de activación.

• Revise quién puede activar y quién puede aprobar.

• Deje de tratar “lo necesitamos para solucionar problemas” como un modelo operativo permanente.

Si alguien puede asignar identidades administradas, otorgar roles y conservar esos derechos para siempre, todavía tiene un problema de privilegios permanentes. Simplemente tiene una mejor documentación ahora.

Auditar quién puede abusar de la identidad

También debe auditar quién puede cambiar el modelo de permisos, no sólo quién puede usarlo. Esa es la parte que la gente se salta porque parece administrativa en lugar de emocionante, que es exactamente la razón por la que se ignora.

Usar Asignaciones de roles de Azure RBAC para encontrar los humanos que pueden otorgar o extender el acceso en el ámbito que le interesa:

az role assignment list \
  --scope /subscriptions/<sub-id> \
  --fill-principal-name false \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator'].[principalName, roleDefinitionName, scope]" \
  -o table

Ese comando muestra a los directores con el poder de otorgar más acceso en el ámbito de la suscripción. Ejecute el mismo patrón en el grupo de recursos o en el alcance del recurso si su identidad solo necesita un límite estrecho.

Luego haga tres preguntas simples:

• ¿Quién puede asignarle a la identidad un nuevo rol?

• ¿Quién puede activar PIM para las personas que gestionan esta carga de trabajo?

• Cual registros de aplicaciones ¿Y las entidades principales de servicio todavía guardan secretos que ya no deberían existir?

Si las respuestas son confusas, no tienes un problema de identidad. Tiene un problema de propiedad con un inicio de sesión adjunto.

Errores comunes

La implementación suele fallar por los mismos motivos:

El mayor error es tratar identidades administradas como autorización. Es autenticación. RBAC azul todavía funciona el permiso.

La última línea es la que los equipos pasan por alto con mayor frecuencia. La identidad está limpia, pero las personas que la rodean aún pueden ampliar el acceso cuando lo deseen.

Elimine el secreto y mantenga los privilegios con un límite de tiempo

Si su carga de trabajo de Azure aún depende de un secreto almacenado, el camino a seguir es sencillo: crear una identidad administrada, otorgar solo el rol que necesita, validar el flujo del token y eliminar el secreto del registro de aplicación. Entonces usa PIM entonces los humanos también permanecen limitados en el tiempo.

El estado final es aburrido en el mejor de los sentidos: no hay entrada a la bóveda de contraseñas que administrar y no se dejan privilegios permanentes porque nadie tuvo tiempo de limpiarlo. Sólo un modelo de identidad para la carga de trabajo y un modelo de privilegios para las personas que la gestionan. Eso es lo que realmente quiere el equipo de seguridad, incluso si te obligan a completar un formulario para decirlo.