🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónRoles federados y condiciones de confianza
5 tareas · 40 min · Principiante
Cuando una persona entra a AWS por federación no tiene usuario propio: el proveedor de identidad le dice a AWS «esta persona puede usar este rol» y AWS decide si le cree. Esa decisión depende de dos cosas que se revisan por separado: la política de confianza del rol, que dice a quién le cree, y el mapeo de grupos del proveedor de identidad, que dice a quién le da el rol. Un fallo en cualquiera abre una puerta. En la Cooperativa Alborada lees cuatro políticas de confianza y el mapeo de grupos a roles, y encuentras dónde la confianza es floja y dónde el mapeo regala demasiado.
Objetivo de la sala
Cuando una persona entra a AWS por federación no tiene usuario propio: el proveedor de identidad le dice a AWS «esta persona puede usar este rol» y AWS decide si le cree. Esa decisión depende de dos cosas que se revisan por separado: la política de confianza del rol, que dice a quién le cree, y el mapeo de grupos del proveedor de identidad, que dice a quién le da el rol. Un fallo en cualquiera abre una puerta. En la Cooperativa Alborada lees cuatro políticas de confianza y el mapeo de grupos a roles, y encuentras dónde la confianza es floja y dónde el mapeo regala demasiado.Para asumir un rol por SAML intervienen dos piezas. La aserción trae el atributo Role, con una pareja de ARN: el rol que se pide y el proveedor SAML que lo respalda. Del otro lado, el rol tiene una política de confianza que nombra a ese proveedor como principal federado y permite la acción sts:AssumeRoleWithSAML. Si una de las dos no coincide, no hay sesión.
Esto separa dos preguntas de auditoría. ¿Qué roles aceptan a este proveedor? Se responde leyendo las confianzas. ¿Quién recibe cada rol? Se responde leyendo el mapeo de grupos en el proveedor.
Responde para continuar
Para que una persona asuma por SAML un rol de AWS, ¿qué debe cumplirse?
Ver pista de ayuda
Una pieza viaja en el mensaje y la otra vive en la política del rol.
La documentación de AWS para crear un rol de SAML indica que la política de confianza debe llevar tres cosas: la acción sts:AssumeRoleWithSAML, el proveedor como principal federado y una condición StringEquals sobre SAML:aud, que compara el destinatario de la aserción con la dirección de inicio de sesión de AWS. Sin la condición, la confianza depende solo de quién firma; con ella, además, la aserción tiene que haber sido emitida para entrar a AWS.
Abre los cuatro confianza-*.json de la carpeta. Tres siguen el patrón de la documentación. Uno se apartó.
Responde para continuar
¿Qué rol tiene una política de confianza sin la condición sobre SAML:aud? Escribe su nombre.
Ver pista de ayuda
Lee el bloque Condition de cada archivo y busca el que no existe.
El mapeo de grupos a roles vive en el proveedor de identidad: mapeo-grupos-roles.csv dice qué rol nombra la aserción para los miembros de cada grupo, y grupos-idp.csv, cuántos miembros tiene cada uno. Un mapeo se revisa con el mismo criterio que un permiso: cuántas personas lo reciben y si todas lo necesitan. Un grupo general de toda la plantilla no debería abrir ningún rol de administración.
Responde para continuar
¿Qué grupo con más de cien miembros nombra el rol de administración en el mapeo? Escribe su nombre.
Ver pista de ayuda
Filtra el mapeo por el rol de administración y mira cuántos miembros tiene cada grupo en la otra tabla.
El fallo está en el mapeo, no en la confianza: la política del rol de administración es correcta, pero demasiadas personas reciben el rol. Una corrección que toca otra cosa deja la causa intacta. Acortar la sesión reduce el tiempo de exposición, pero no cambia quién puede entrar, y quitar la condición de audiencia debilita una comprobación que estaba bien.
Responde para continuar
El grupo general abre el rol de administración. ¿Qué corrige la causa?
Ver pista de ayuda
La causa es quién recibe el rol, no cuánto dura ni cómo se valida el mensaje.
Para el informe a la gerencia hace falta una cifra, no una impresión. Suma los miembros de los grupos que nombran el rol de administración. La columna de solapamiento indica cuántos miembros de cada grupo están también en otro grupo que abre ese rol, así que puedes sumar sin contar a nadie dos veces.
Responde para continuar
¿Cuántas personas pueden asumir el rol de administración según el mapeo? Escribe solo el número.
Ver pista de ayuda
Suma los miembros de los grupos mapeados al rol; revisa la columna de solapamiento.
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.