Servicios Nube M03

En el contexto de AWS IAM, ¿qué diferencia hay entre autenticación y autorización?. Son sinónimos. IAM las trata como una única fase que solo se ejecuta al iniciar sesión en la consola. La autenticación verifica la identidad del principal que realiza la petición; la autorización decide, evaluando las políticas aplicables, si esa identidad puede ejecutar la acción sobre el recurso. La autenticación decide qué acciones puede ejecutar un usuario y la autorización comprueba su contraseña. La autorización solo se aplica a las peticiones de la consola web; las de la AWS CLI únicamente se autentican.

Un usuario tiene adjunta una política que concede `s3:*` sobre todos los recursos y otra que deniega explícitamente `s3:DeleteObject` sobre el bucket `cafeteria-pedidos`. ¿Qué ocurre si intenta borrar un objeto de ese bucket?. La petición se deniega, porque un Deny explícito prevalece siempre sobre cualquier Allow. La petición se permite, porque `s3:*` es más general y tiene prioridad sobre la denegación concreta. El resultado es aleatorio, porque IAM tiene consistencia eventual. La petición se permite, porque las políticas se evalúan por orden de antigüedad y la de `s3:*` se adjuntó antes.

¿Cuál de las siguientes afirmaciones sobre los grupos IAM es correcta?. Un grupo puede contener otros grupos, lo que permite construir jerarquías departamentales. Un grupo dispone de sus propias claves de acceso, que comparten todos sus miembros. Los roles IAM pueden añadirse a un grupo para heredar sus permisos. Un grupo agrupa usuarios IAM para asignarles políticas en bloque, pero no es un principal: no puede autenticarse ni aparecer en el elemento `Principal` de una política de recursos.

¿Qué ventaja principal ofrece el control de acceso basado en atributos (ABAC) frente al control basado en roles (RBAC) en AWS?. Una única política que compara etiquetas del principal y del recurso, como \`aws:PrincipalTag/Project\` con \`aws:ResourceTag/Project\`, sirve para cualquier número de proyectos sin crear políticas nuevas. ABAC no requiere ningún control sobre quién puede modificar las etiquetas. ABAC permite que el usuario raíz quede sujeto a las políticas IAM. ABAC elimina la necesidad de escribir políticas JSON, porque los permisos se deducen automáticamente del nombre del usuario.

¿Cuál de los siguientes ARN identifica correctamente a todos los objetos del bucket `cafeteria-web-prod-assets`?. `s3://cafeteria-web-prod-assets/*`. `arn:aws:s3:::cafeteria-web-prod-assets/*`. `arn:aws:s3:us-east-1:123456789012:cafeteria-web-prod-assets`. `arn:aws:s3:::cafeteria-web-prod-assets`.

¿Qué elemento distingue a una política basada en recursos, como una política de bucket S3, de una política basada en identidad?. La política basada en recursos solo puede tener `Effect` igual a `Deny`. La política basada en recursos incluye obligatoriamente el elemento `Principal`, que indica a quién se concede o deniega el acceso; la de identidad no lo lleva porque se aplica a la identidad a la que está adjunta. La política basada en recursos no admite el elemento `Condition`. La política basada en identidad puede adjuntarse a un bucket S3 desde la consola de IAM.

Al revisar la salida de un comando, un alumno observa un identificador de clave de acceso que empieza por `ASIA`. ¿Qué indica ese prefijo?. Que la credencial pertenece a un grupo IAM. Que la clave se ha creado en la región Asia Pacífico. Que es una credencial temporal emitida por AWS STS, que va acompañada de un token de sesión y caduca automáticamente. Que es una clave de acceso de larga duración del usuario raíz.

¿Qué función cumple la política de confianza (trust policy) de un rol IAM?. Define qué principales pueden asumir el rol, por ejemplo el servicio `ec2.amazonaws.com`, mediante la acción `sts:AssumeRole`. Indica qué usuarios IAM pertenecen al rol, igual que en un grupo. Define qué acciones sobre S3 o EC2 puede ejecutar la entidad que asume el rol. Establece la contraseña de consola del rol y su caducidad.

¿Por qué se recomienda lanzar las instancias con `--metadata-options HttpTokens=required`?. Porque cifra el volumen EBS raíz con la clave del rol IAM. Porque impide que la instancia obtenga credenciales del rol, de modo que hay que usar `aws configure`. Porque reduce el coste de la instancia en el Learner Lab. Porque obliga a usar IMDSv2, que exige un token de sesión obtenido con PUT antes de consultar los metadatos y dificulta que un ataque SSRF robe las credenciales del rol.

Una política concede `ec2:StopInstances` sobre todas las instancias con la condición `StringEquals` de `aws:ResourceTag/Project` igual a `${aws:PrincipalTag/Project}`. Un rol con la etiqueta `Project=cafeteria` intenta detener una instancia etiquetada con `Project=tienda`. ¿Qué ocurre?. Se permite, porque las condiciones sobre etiquetas solo se evalúan en el momento de crear la instancia. Da un error de sintaxis, porque las variables de política no se pueden usar dentro de `Condition`. Se permite, porque la política concede `ec2:StopInstances` sobre todas las instancias. Se deniega, porque el valor de la etiqueta del recurso no coincide con el de la etiqueta del principal, así que la condición no se cumple y no hay Allow aplicable.

Un alumno intenta crear un usuario IAM en el Learner Lab para separar los permisos de su aplicación y recibe un error de acceso denegado. ¿Cuál es la interpretación correcta?. Debe crear el usuario en otra región, porque IAM está limitado a `us-west-2`. Es un error temporal de consistencia eventual. Basta con reintentarlo hasta que funcione. El sandbox de AWS Academy bloquea la creación de usuarios IAM. La solución profesional es usar el rol `LabRole` mediante `LabInstanceProfile` y entregar la política de mínimo privilegio como diseño. Debe iniciar sesión con el usuario raíz del Learner Lab para crear el usuario.

Una aplicación tiene esta política: `"Action": ["s3:ListBucket", "s3:GetObject"], "Resource": "arn:aws:s3:::cafeteria-pedidos/*"`. La descarga de objetos funciona, pero `aws s3 ls s3://cafeteria-pedidos` devuelve `AccessDenied`. ¿Cuál es la causa?. La consistencia eventual de S3 impide listar objetos recién subidos. Falta el elemento `Principal` en la política de identidad. `s3:ListBucket` solo puede concederse en una política de bucket, nunca en una de identidad. `s3:ListBucket` actúa sobre el bucket, cuyo ARN es `arn:aws:s3:::cafeteria-pedidos` sin `/*`, y ese recurso no aparece en la política.

Desde una instancia con `LabInstanceProfile`, el alumno ejecuta `aws sts get-caller-identity`. ¿Qué ARN confirma que la instancia está usando correctamente el rol?. `arn:aws:iam::123456789012:user/LabInstanceProfile`. `arn:aws:iam::123456789012:root`. `arn:aws:sts::123456789012:assumed-role/voclabs/user1234567=alumno`. `arn:aws:sts::123456789012:assumed-role/LabRole/i-0abc123def4567890`.

Un usuario recibe `AccessDenied` al ejecutar `aws sts assume-role` sobre `CafeteriaDeployRole`. Su política de identidad le concede `sts:AssumeRole` sobre el ARN de ese rol. ¿Qué es lo más probable que falte?. Que el usuario pertenezca a un grupo con el mismo nombre que el rol. Que la política de confianza del rol incluya a ese usuario, o a su cuenta, como `Principal` autorizado. Que el parámetro `--duration-seconds` supere las 12 horas. Que el usuario active la consola de IAM en la región `us-east-1`.

La aplicación web de la cafetería solo necesita subir y leer imágenes de pedidos en el bucket `cafeteria-pedidos`. ¿Qué política de permisos aplica correctamente el principio de mínimo privilegio?. Política administrada `AmazonS3FullAccess`, porque es la opción recomendada por AWS. Allow de `s3:GetObject` y `s3:PutObject` sobre `*`. Allow de `s3:*` sobre `arn:aws:s3:::cafeteria-pedidos/*`. Allow de `s3:GetObject` y `s3:PutObject` sobre `arn:aws:s3:::cafeteria-pedidos/*`.

¿Qué combinación de efecto y condición bloquea cualquier petición a un bucket que no viaje cifrada con TLS, aunque otra política conceda `s3:*`?. Effect `Deny` con la condición `Bool` sobre `aws:SecureTransport` igual a `false`. No es posible: el cifrado en tránsito solo se configura en las propiedades del bucket, no en las políticas. Effect `Allow` con la condición `Bool` sobre `aws:SecureTransport` igual a `true`. Effect `Deny` con la condición `IpAddress` sobre `aws:SourceIp`.

¿Cuál de las siguientes medidas forma parte de las buenas prácticas obligatorias para proteger el usuario raíz de una cuenta de AWS?. Compartir la contraseña raíz con todo el equipo para que cualquiera pueda resolver incidencias urgentes. Crear claves de acceso raíz y guardarlas en el repositorio Git privado del proyecto para automatizar los despliegues. Adjuntar al usuario raíz una política IAM con Deny explícito para limitar sus permisos en el día a día. Activar MFA en el usuario raíz y no crear claves de acceso para él, reservando su uso para las tareas que solo él puede realizar.

Se crea un rol IAM nuevo con una política de confianza válida, pero sin ninguna política de permisos adjunta. ¿Qué puede hacer una instancia EC2 que lo asuma?. Solo operaciones de lectura (`Describe*`, `Get*`, `List*`), que IAM permite por defecto. Todo, porque sin políticas no existe ninguna restricción. Solo acceder a los buckets S3 de su misma región. Nada. Todas sus peticiones se deniegan implícitamente porque ninguna política le concede un Allow.

En el reto R02, el servidor web en EC2 debe subir archivos a S3. ¿Cuál es la forma correcta de dar permisos a la instancia en el Learner Lab?. Crear un usuario IAM para la aplicación y guardar sus claves `AKIA` en el fichero `.env` del proyecto. Ejecutar `aws configure` dentro de la instancia y pegar las credenciales que muestra el Learner Lab en AWS Details. Hacer público el bucket para que la instancia pueda escribir sin credenciales. Lanzar o asociar la instancia con el perfil `LabInstanceProfile`, para que la AWS CLI y los SDK obtengan credenciales temporales de `LabRole` a través del servicio de metadatos.

Tras un `AccessDenied` en una operación `PutObject`, ¿qué información de AWS CloudTrail permite identificar con precisión qué identidad hizo la petición y por qué falló?. Las métricas de CPU de la instancia en Amazon CloudWatch. La política de bucket, que guarda el historial de las peticiones denegadas. Los registros de acceso del servidor web Apache en `/var/log/httpd/access_log`. Los campos `userIdentity`, `eventName`, `sourceIPAddress` y `errorCode` del evento registrado.