Loading
_ DESCIFRANDO CONEXIÓN SEGURA...

Roles 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.

0 de 5 · 0%

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.

Inicia sesión para registrar tus puntos y progreso en el ranking.

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