🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónIdentidades administradas y principales de servicio
5 tareas · 35 min · Principiante
No todas las identidades son personas. Las aplicaciones y los servicios también entran a Azure, y lo hacen con una identidad que se ve en el directorio como un principal de servicio. Hay dos formas de dársela. Con un registro de aplicación y un secreto, la credencial la guarda alguien, caduca, se copia y se filtra. Con una identidad administrada no hay credencial que custodiar: Azure la entrega y la rota. En Almacenes Guaduales hay de las dos clases, y esta sala las revisa con la misma pregunta de siempre: qué puede hacer cada una, sobre qué ámbito y quién responde por ella.
Objetivo de la sala
No todas las identidades son personas. Las aplicaciones y los servicios también entran a Azure, y lo hacen con una identidad que se ve en el directorio como un principal de servicio. Hay dos formas de dársela. Con un registro de aplicación y un secreto, la credencial la guarda alguien, caduca, se copia y se filtra. Con una identidad administrada no hay credencial que custodiar: Azure la entrega y la rota. En Almacenes Guaduales hay de las dos clases, y esta sala las revisa con la misma pregunta de siempre: qué puede hacer cada una, sobre qué ámbito y quién responde por ella.Una identidad administrada de asignación por el sistema nace con un recurso, solo ese recurso puede usarla y se elimina cuando se elimina el recurso. Una de asignación por el usuario es un recurso propio, con ciclo de vida independiente, que puede asignarse a varios recursos a la vez. En ambos casos el código obtiene un token sin guardar ningún secreto.
La compartición es cómoda y es el riesgo: cuantos más recursos usan la misma identidad, más amplio tiene que ser su permiso y más difícil saber cuál de ellos actuó.
Responde para continuar
¿Qué ocurre con una identidad administrada asignada por el sistema cuando se elimina el recurso al que pertenece?
Ver pista de ayuda
«Por el sistema» quiere decir que nace y muere con el recurso.
Una aplicación registrada con un secreto de cliente tiene una contraseña que alguien debe guardar, renovar antes de que venza y cambiar si se filtra. Los secretos se copian a repositorios, a variables de entorno y a chats. Cuando el código corre dentro de Azure, la alternativa es una identidad administrada con el rol justo sobre el recurso justo: no hay secreto que se pueda copiar, y el permiso se revoca quitando una asignación de rol.
Responde para continuar
Una aplicación que corre en Azure debe leer blobs de un almacenamiento. ¿Qué opción evita guardar un secreto?
Ver pista de ayuda
Busca la que no deja ninguna credencial en manos de nadie.
Abre registros-de-aplicacion.txt. Una credencial vencida tiene dos lecturas: si la aplicación sigue funcionando, hay otro secreto que no se ve en esta lista; si dejó de funcionar, alguien tuvo que improvisar. En ambos casos el registro está descuidado, y descuidar un registro es el primer paso hacia un secreto olvidado con permisos amplios. Compara cada fecha de vencimiento con la fecha de la revisión que encabeza el archivo.
Responde para continuar
¿Qué aplicación tiene un secreto de cliente que ya había vencido a la fecha de la revisión? Escribe su nombre.
Ver pista de ayuda
`cat registros-de-aplicacion.txt` y compara la columna «vence» con la fecha de la revisión.
Abre identidades-administradas.txt. Para cada identidad, mira el rol y el ámbito. Un rol de Owner concede, además de todo el acceso a recursos, la capacidad de asignar roles; en una identidad que usa código, eso significa que un fallo en ese código se convierte en la capacidad de repartir permisos.
Responde para continuar
¿Qué identidad administrada tiene el rol Owner? Escribe su nombre.
Ver pista de ayuda
`grep Owner identidades-administradas.txt`.
El radio de daño de una identidad compartida es la suma de los recursos que la usan: si uno se compromete, el atacante hereda lo que la identidad puede hacer en todos. La columna «recursos que la usan» permite contarlos. Recortar el rol y repartir la identidad en una por recurso es la corrección habitual.
Responde para continuar
¿A cuántos recursos sirve la identidad que tiene el rol Owner? Escribe el número.
Ver pista de ayuda
Cuenta los nombres separados por comas en la columna «recursos que la usan» de esa fila.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.