Creación de una clave y entidad de servicio
Ahora que comprende el concepto de entidad de servicio, quizá se pregunte cómo demuestra su identidad en Microsoft Entra ID. En esta unidad, aprenderá sobre el proceso de autenticación y las credenciales de las entidades de servicio. También aprenderá a crear una entidad de servicio y a asignarle una clave.
Información sobre cómo se autentican las entidades de servicio
Cuando una entidad de servicio necesita comunicarse con Azure, inicia sesión en Microsoft Entra ID. Después de que Microsoft Entra ID comprueba la identidad de la entidad de servicio, emite un token que la aplicación cliente almacena y usa cuando realiza solicitudes a Azure.
En términos generales, este proceso es similar a cómo funcionan las cosas al iniciar sesión en Azure como usuario. Sin embargo, en comparación con los usuarios, las entidades de servicio tienen un tipo de credencial ligeramente distinto para demostrar su identidad. Las entidades de servicio usan dos credenciales principales: las claves y los certificados.
Nota:
Recuerde que las identidades administradas son entidades de servicio especiales que funcionan dentro de Azure. Tienen un tipo diferente de proceso de autenticación que no requiere que conozca o manipule las credenciales en lo absoluto.
Claves
Las claves son similares a las contraseñas. Sin embargo, las claves son mucho más largas y complejas. De hecho, en la mayoría de las situaciones, Microsoft Entra ID genera claves para asegurarse de lo siguiente:
- Las claves son criptográficamente aleatorias. Es decir, son muy difíciles de adivinar.
- Los humanos no usan accidentalmente contraseñas no seguras como claves.
Las entidades de servicio a menudo tienen permisos con privilegios elevados, por lo que es esencial que sean seguras. Normalmente, solo necesita manipular la clave brevemente al realizar la configuración inicial de la entidad de servicio y la canalización. Por lo tanto, no es necesario que la clave sea fácil de recordar ni de escribir.
Una única entidad de servicio puede tener varias claves al mismo tiempo, pero los usuarios no pueden tener varias contraseñas. Al igual que las contraseñas, las claves tienen una fecha de expiración. Obtendrá más información al respecto más adelante.
Nota:
Piense en las claves como contraseñas muy importantes, similares a las claves de una cuenta de almacenamiento. Debe tratarlas con el mismo nivel de seguridad y cuidado.
Certificados
Los certificados son otra manera de autenticar las entidades de servicio. Son muy seguros, pero pueden ser difíciles de administrar. Algunas organizaciones requieren el uso de certificados para determinados tipos de entidades de servicio.
No trataremos los certificados en este módulo. Sin embargo, si trabaja con una entidad de servicio que usa la autenticación de certificados, básicamente funciona de la misma manera que cualquier otra entidad de servicio en términos de administrarla y concederle permiso para la canalización.
Nota:
Los certificados son una buena opción cuando se pueden usar. Son más difíciles de robar para los atacantes. También es más difícil interceptar y modificar las solicitudes que usan certificados. Sin embargo, los certificados requieren más infraestructura y generan cierta sobrecarga de mantenimiento continua.
Trabajo con claves para entidades de servicio
Cuando se crea una entidad de servicio, normalmente se pide a Azure que cree una clave al mismo tiempo. Azure normalmente genera una clave aleatoria automáticamente.
Nota:
¿Recuerda la explicación anterior sobre cómo funcionan las entidades de servicio? Las claves se almacenan como parte del objeto de registro de la aplicación. Si abre Azure Portal, busque dentro de la configuración de Microsoft Entra y, a continuación, va a los registros de aplicaciones, también podrá crear y eliminar claves allí.
Azure muestra la clave al crear la entidad de servicio. Esta es la única vez que Azure le mostrará la clave. Después de eso, ya no se puede recuperar. Es importante copiar la clave de forma segura para poder usarla al configurar la canalización. No comparta la clave por correo electrónico ni por otro medio no seguro. Si pierde una clave, debe eliminarla y crear una nueva.
Administración de entidades de servicio para Azure Pipelines
Cuando cree una clave para la entidad de servicio de una canalización, se recomienda copiar inmediatamente la clave en la configuración de la canalización. De este modo, evitará almacenar o transmitir la clave innecesariamente.
Las herramientas de canalización incluyen formas seguras de especificar el identificador de aplicación y la clave de la entidad de servicio. Nunca almacene credenciales de ningún tipo en el control de código fuente. En su lugar, use conexiones de servicio cuando trabaje con Azure Pipelines. En este módulo, solo se explica cómo crear una entidad de servicio y una clave. Aprenderá a configurar la canalización con la clave en un módulo posterior.
Sugerencia
Azure Pipelines puede crear entidades de servicio automáticamente. En este módulo, creará y administrará manualmente las entidades de servicio para comprender mejor lo que sucede. En otros módulos, usará el método de creación automática para una mayor simplicidad.
Creación de una clave y entidad de servicio
Puede usar la CLI de Azure para crear y administrar entidades de servicio.
Nota:
La creación y modificación de entidades de servicio requiere que tenga los permisos relacionados en Microsoft Entra ID. En algunas organizaciones, es posible que necesite un administrador para realizar estos pasos.
Para crear una entidad de servicio y una clave, use el comando az ad sp create-for-rbac. Este comando acepta varios argumentos y, opcionalmente, puede asignar roles a la entidad de servicio. Aprenderá más sobre este tema más adelante en el módulo. Por ahora, este es un ejemplo que muestra cómo crear una entidad de servicio sin ninguna asignación de roles de Azure:
az ad sp create-for-rbac --name MyPipeline
Al ejecutar este comando, la CLI de Azure devuelve una respuesta JSON con una propiedad password. Esta propiedad es la clave de la entidad de servicio. No podrá volver a obtener esta clave, así que asegúrese de usarla inmediatamente o guárdela en algún lugar de forma segura.
Nota:
El comando az ad sp create-for-rbac crea un registro de aplicación en Microsoft Entra ID, agrega una entidad de servicio al inquilino de Microsoft Entra y crea una clave para el registro de la aplicación. Otro comando, az ad sp create, solo crea la entidad de servicio en el inquilino (pero no el registro de la aplicación). Cuando cree entidades de servicio para canalizaciones, se recomienda usar el comando az ad sp create-for-rbac.
Puede usar los cmdlets de Azure PowerShell para crear y administrar entidades de servicio.
Nota:
La creación y modificación de entidades de servicio requiere que tenga los permisos relacionados en Microsoft Entra ID. En algunas organizaciones, es posible que necesite un administrador para realizar estos pasos.
Para crear una entidad de servicio y una clave, use el cmdlet New-AzADServicePrincipal. Este cmdlet acepta varios argumentos y, opcionalmente, puede asignar roles a la entidad de servicio. Aprenderá más sobre este tema más adelante en el módulo. Por ahora, este es un ejemplo que muestra cómo crear una entidad de servicio sin ninguna asignación de roles de Azure:
$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline
Al ejecutar este comando, Azure PowerShell completa la variable servicePrincipal con información sobre la entidad de servicio, incluida la clave:
$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText
No podrá volver a obtener esta clave, así que asegúrese de usarla inmediatamente o guárdela en un lugar seguro.
Nota:
El cmdlet New-AzADServicePrincipal crea un registro de aplicación en Microsoft Entra ID, agrega una entidad de servicio al inquilino de Microsoft Entra y crea una clave para el registro de la aplicación.
Identificación de una entidad de servicio
Las entidades de servicio tienen varios identificadores y nombres que se usan para identificarlas y trabajar con ellas. Los siguientes son los identificadores que usará más a menudo:
- Id. de aplicación: el registro de la aplicación tiene un identificador único, a menudo denominado identificador de aplicación o, a veces, identificador de cliente. Normalmente se usa como nombre de usuario cuando la entidad de servicio inicia sesión en Azure.
- Id. de objeto: El registro de la aplicación y la entidad de servicio tienen sus propios identificadores de objeto independientes, que son identificadores únicos asignados por Microsoft Entra ID. En ocasiones, deberá usar estos identificadores de objeto al administrar una entidad de servicio.
- Nombre para mostrar: se trata de un nombre legible que describe la entidad de servicio.
Sugerencia
Use un nombre para mostrar claro y descriptivo para la entidad de servicio. Es importante ayudar a su equipo a comprender para qué es la entidad de servicio, a fin de que nadie la elimine accidentalmente o cambie sus permisos.
Precaución
Un nombre para mostrar no es único. Varias entidades de servicio pueden compartir el mismo nombre para mostrar. Tenga cuidado cuando conceda permisos a una entidad de servicio si está usando su nombre para mostrar para identificarla. Puede conceder permisos accidentalmente a la entidad de servicio incorrecta. Se recomienda usar el identificador de aplicación en su lugar.
Cuando se crea una entidad de servicio, normalmente solo debe establecer el nombre para mostrar. Azure asigna automáticamente los demás nombres e identificadores.
Control de claves expiradas
Las entidades de servicio no expiran, pero sus claves sí. Cuando cree una clave, puede configurar su fecha de expiración. De manera predeterminada, la fecha de expiración se establece en un año. Después de esta fecha de expiración, la clave ya no funciona y la canalización no puede iniciar sesión en Microsoft Entra ID. Debe renovar o rotar las claves con frecuencia.
Precaución
Puede resultar tentador establecer tiempos de expiración largos para las claves, pero no debe hacerlo. Las entidades de servicio solo están protegidas por sus credenciales. Si un atacante obtiene la clave de una entidad de servicio, puede causar mucho daño. La mejor estrategia para minimizar el período que puede durar un ataque es cambiar periódicamente las claves. También debe quitar y volver a crear claves si alguna vez sospecha que se han filtrado.
Para restablecer la clave de una entidad de servicio, use el comando az ad sp con el identificador de aplicación, como en este ejemplo:
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
También puede quitar y volver a crear la clave de la entidad de servicio en dos pasos independientes mediante el comando az ad sp credential delete y, a continuación, el comando az ad sp credential reset --append.
Para restablecer la clave de una entidad de servicio, use primero el cmdlet Remove-AzADServicePrincipalCredential para quitar la credencial existente. A continuación, use el cmdlet New-AzADServicePrincipalCredential para agregar una nueva credencial. Ambos cmdlets usan el identificador de objeto de la entidad de servicio para identificarlo. Antes de usar los cmdlets, debe obtener este identificador a partir del identificador de aplicación:
$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id
Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText
Sugerencia
Una única entidad de servicio puede tener varias claves. Puede actualizar la aplicación de forma segura para que use una nueva clave mientras la clave antigua sigue siendo válida y, a continuación, eliminar la clave anterior cuando ya no esté en uso. Este método evita el tiempo de inactividad debido a la expiración de las claves.
Administración del ciclo de vida de la entidad de servicio
Es importante tener en cuenta todo el ciclo de vida de cada entidad de servicio que cree. Al crear una entidad de servicio para una canalización, ¿qué ocurrirá si más tarde se elimina o ya no se usa?
Las entidades de servicio no se quitan automáticamente, por lo que debe auditar y quitar las entidades de servicio antiguas. Es importante quitar las entidades de servicio antiguas por la misma razón por la que se eliminan las cuentas de usuario antiguas: los atacantes pueden obtener acceso a sus claves. Es mejor no tener credenciales que no se estén usando activamente.
Se recomienda documentar las entidades de servicio en un lugar al que usted y su equipo puedan acceder fácilmente. Debe incluir la siguiente información para cada entidad de servicio:
- Información de identificación esencial, incluido su nombre y el identificador de aplicación.
- La finalidad de la entidad de servicio.
- Quién la creó, quién es responsable de administrarla (junto con sus claves), y quién podría tener respuestas si hay un problema.
- Los permisos que necesita y una justificación clara de por qué los necesita.
- Cuál es su vigencia esperada.
Debe auditar periódicamente las entidades de servicio para asegurarse de que se siguen utilizando y de que los permisos que se les han asignado siguen siendo correctos.