🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónPolíticas de recurso y confianza entre cuentas
5 tareas · 40 min · Principiante
Hasta aquí el permiso viajaba con la identidad. Pero hay otra puerta que se abre desde el otro lado: la política de un recurso (un bucket, una cola, una clave) puede nombrar a quién deja entrar, y un rol lleva su propia política de confianza que dice quién puede asumirlo. Ahí es donde una cuenta ajena acaba con acceso a la tuya. Quebrada Datos trabaja con un proveedor de tableros, con una cuenta de analítica y con un pipeline de despliegue. Lees las políticas que lo conectan todo y decides cuáles confían de más.
Objetivo de la sala
Hasta aquí el permiso viajaba con la identidad. Pero hay otra puerta que se abre desde el otro lado: la política de un recurso (un bucket, una cola, una clave) puede nombrar a quién deja entrar, y un rol lleva su propia política de confianza que dice quién puede asumirlo. Ahí es donde una cuenta ajena acaba con acceso a la tuya. Quebrada Datos trabaja con un proveedor de tableros, con una cuenta de analítica y con un pipeline de despliegue. Lees las políticas que lo conectan todo y decides cuáles confían de más.Un rol tiene dos políticas con papeles distintos. La política de permisos (de identidad) dice lo que el rol puede hacer una vez asumido. La política de confianza es una política de recurso adjunta al rol: su Principal dice quién tiene permitido asumirlo, con la acción sts:AssumeRole. Una sin la otra no sirve: el rol más limitado, si cualquiera puede asumirlo, es una puerta; y el rol más estricto en confianza, con permisos de administrador, entrega todo a quien entre.
Revisar un rol es revisar las dos: quién entra y qué puede hacer cuando está dentro.
Responde para continuar
¿Qué define la política de confianza de un rol?
Ver pista de ayuda
No confundir con la política de permisos: esta responde a quién, no a qué.
El elemento Principal es el que hay que mirar con más cuidado. Un ARN concreto nombra a una identidad o a una cuenta; un asterisco en el principal significa cualquiera. En una política de confianza, un principal * sin ninguna condición permite que cualquier identidad de AWS, de cualquier cuenta, intente asumir el rol; lo que lo frena es solo lo que el rol permita hacer. Abre los cuatro archivos confianza-*.json y lee cada principal.
Responde para continuar
¿Qué rol puede ser asumido por una identidad de cualquier cuenta, sin condición? Escribe su nombre.
Ver pista de ayuda
Mira el valor de Principal en cada archivo; busca el que no nombra ninguna cuenta.
Cuando un tercero asume un rol en tu cuenta, el principal que lo identifica es la cuenta del tercero. Eso crea un riesgo conocido como el problema del delegado confundido (confused deputy): si el proveedor atiende a muchos clientes, otro cliente suyo podría conseguir que el proveedor actúe en tu cuenta con ese rol. La defensa documentada es un identificador externo (sts:ExternalId): un valor acordado solo entre tu empresa y el proveedor, que la política de confianza exige como condición. Quien asume el rol tiene que presentarlo. No es una contraseña: es una comprobación de que la petición se hace en nombre de ti y no de otro cliente.
Un rol para un tercero debería nombrar su cuenta y exigir el identificador externo.
Responde para continuar
Un proveedor asume un rol en tu cuenta y atiende a muchos clientes. ¿Qué condición evita que otro de sus clientes use ese rol por el proveedor?
Ver pista de ayuda
La condición es un valor secreto compartido con quien realmente tiene el contrato.
La lista cuentas-conocidas.txt recoge las tres cuentas que la empresa reconoce: la propia, la de analítica y el proveedor aprobado. Cualquier otra cuenta nombrada en una política de confianza o de recurso es un acceso que nadie decidió. Cruza las políticas de confianza con la lista.
Responde para continuar
¿Qué id de cuenta puede asumir un rol de Quebrada Datos sin estar en la lista de cuentas reconocidas?
Ver pista de ayuda
Recorre los principales de los cuatro roles y descarta los que aparecen en la lista; no cuentan los que usan un asterisco.
La política del bucket compartido contiene una sentencia con Principal: "*", que a simple vista parece abrir el bucket al mundo. Pero lleva una condición: aws:PrincipalOrgID igual al identificador de la organización. Esa clave de condición compara con la organización a la que pertenece el principal que hace la solicitud. Con ella, el asterisco no significa cualquiera sino cualquier miembro de esa organización. Esa es la forma de compartir con todas las cuentas propias sin listarlas una por una.
Responde para continuar
En el bucket compartido, ¿qué efecto tiene la sentencia SoloMiembrosDeLaOrganizacion?
Ver pista de ayuda
El valor del Principal lo amplía; la condición lo estrecha de nuevo.
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.