ESEN

← Letra chica por examen

Amazon Web Services · Specialty

SCS-C03 · AWS Certified Security - Specialty (SCS-C03)

AWS Certified Security - Specialty

Despliegue desde CI sin secretos (federación OIDC)

Seguridad● verificado hace 34 días◌ sin revisor externo

IAM exige una condición sobre sub, pero acepta una que igual abre la puerta

El issuer de GitHub es el mismo para todas las organizaciones: sin acotar el sub, cualquier repositorio de GitHub podría asumir tu rol. Por eso IAM rechaza crear o actualizar una trust policy hacia ese provider si falta la condición sobre sub (o job_workflow_ref) o si es solo un comodín. Pero "repo:*" o "repo:mi-org/*" pasan la validación. El límite real lo ponés vos: este módulo usa StringEquals con un sub por environment.

⚑ Reportar desactualizado

Ver en el patrón →

IAM● verificado hace 34 días◌ sin revisor externo

Si el job declara un environment, el sub deja de tener la rama

GitHub incluye el environment en el sub cuando el job lo referencia; pull_request y la ref solo entran si el job no referencia un environment. Un job en main con environment production presenta repo:org/repo:environment:production, así que una trust policy que espera repo:org/repo:ref:refs/heads/main rechaza el AssumeRoleWithWebIdentity.

⚑ Reportar desactualizado

Ver en el patrón →

Operación● verificado hace 34 días◌ sin revisor externo

Hay un solo OIDC provider por URL y por cuenta

Crear un segundo provider para token.actions.githubusercontent.com en la misma cuenta falla: IAM no permite registrar la misma URL dos veces en una cuenta. Si cada repo trae su propio stack de Terraform con el provider adentro, el segundo apply rompe. Crealo una vez (en el stack de la cuenta) y referencialo con el data source; el módulo lo permite con create_oidc_provider = false.

⚑ Reportar desactualizado

Ver en el patrón →

Operación● verificado hace 34 días◌ sin revisor externo

Para GitHub, IAM no usa el thumbprint para verificar (y no hace falta cargarlo)

IAM valida el certificado de GitHub contra su librería de CAs raíz confiables, así que thumbprint_list es opcional y, en el provider de Terraform, para IdPs como GitHub se guarda pero no se usa para verificar. Los thumbprints solo entran en juego si el IdP usa un certificado que no firma una de esas CAs, o si AWS no puede obtener el certificado TLS o se requiere TLS v1.3.

⚑ Reportar desactualizado

Ver en el patrón →

Confiabilidad● verificado hace 34 días◌ sin revisor externo

La sesión dura 1 hora por default, y encadenar roles la limita a 1 hora sí o sí

AssumeRoleWithWebIdentity da 3600 s por default; podés pedir hasta el MaxSessionDuration del rol (máximo 12 h), y pedir más que eso hace fallar la llamada. Si desde ese rol asumís otro (role chaining, típico en multi-cuenta), la sesión queda en 1 hora como máximo. Un apply largo que se pasa del límite falla a mitad de camino con el state a medio escribir.

⚑ Reportar desactualizado

Ver en el patrón →

Ingesta privada de objetos con expiración (TTL)

IAM● verificado hace 34 días◌ sin revisor externo

Un Deny por aws:SourceVpce también te deja afuera a vos

Un Deny explícito gana sobre cualquier Allow, incluido el del admin. Si la policy niega todo s3:* fuera del endpoint, la consola y el pipeline de CI (que no están en la VPC) pierden acceso, y podés terminar sin poder editar la propia bucket policy. Este módulo limita el Deny a operaciones de objetos y permite excluir principals de break-glass con aws:PrincipalArn.

⚑ Reportar desactualizado

Ver en el patrón →

Web API privada Zero Trust con PostgreSQL sin contraseñas

Seguridad● verificado hace 34 días◌ sin revisor externo

HTTPS en un ALB interno igual necesita un certificado de servidor SSL

Para crear un listener HTTPS hay que desplegar al menos un certificado de servidor SSL (de ACM o de IAM). ACM no puede validar recursos en una private hosted zone de VPC ni en ningún otro dominio privado, aunque el ALB sea interno. ACM no valida la propiedad del dominio en certificados importados ni firmados por una CA privada.

⚑ Reportar desactualizado

Ver en el patrón →

Seguridad● verificado hace 34 días◌ sin revisor externo

Que la contraseña del master user la gestione Secrets Manager

Con manage_master_user_password = true, RDS genera la contraseña del master y la guarda en Secrets Manager. El provider de Terraform no permite combinarlo con password, y RDS no lo soporta en algunos escenarios (por ejemplo Blue/Green deployments), así que decidilo de entrada.

⚑ Reportar desactualizado

Ver en el patrón →