Amazon SAA-C03: Seguridad, IAM, KMS y gobernanza — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Fundamentos de Identidad: Usuarios, Raíz, Grupos y Roles

Identity and Access Management es el plano de control por el que pasa toda carga de trabajo, y su principio rector es el de privilegio mínimo: conceder solo lo que es necesario, únicamente durante el tiempo que sea necesario, y preferir identidades que producen credenciales de corta duración sobre aquellas que mantienen secretos estáticos.

El usuario raíz (root) es el propietario de la cuenta, posee permisos sin restricciones y no puede ser restringido por políticas de IAM o SCPs. Eso lo convierte en la credencial más sensible del entorno, y debe ser tratada como un recurso de emergencia (break-glass). En una cuenta nueva: habilite un dispositivo MFA de hardware o virtual en el usuario raíz, establezca una contraseña larga y única, elimine cualquier clave de acceso raíz histórica y registre contactos alternativos para facturación/operaciones/seguridad para que la recuperación sea posible. Después de la configuración inicial —crear una identidad de administrador de IAM, configurar la facturación y establecer el alias de la cuenta— el usuario raíz no se vuelve a utilizar, excepto para el conjunto limitado de tareas para las que AWS lo requiere explícitamente (cerrar la cuenta, cambiar el nombre de la cuenta, restaurar permisos de IAM eliminados, habilitar MFA Delete y un puñado de operaciones de S3/CloudFront firmadas por la raíz). Usar el usuario raíz para el trabajo diario es incorrecto porque no puede ser limitado por políticas, es difícil de atribuir en CloudTrail cuando se comparte y un solo compromiso otorga un control irrevocable.

El acceso diario de los humanos fluye a través de identidades de IAM limitadas por políticas de privilegio mínimo. Asocie las políticas administradas a grupos, no a usuarios individuales: un grupo Administrators con AdministratorAccess asociado, y usuarios nominales colocados en él, produce un único punto de cambio y evita el antipatrón de pegar políticas idénticas en cada usuario. Limite el alcance de los recursos con ARNs explícitos en lugar de *.

Los roles cumplen un propósito completamente diferente. Son asumidos por principales (principals) —servicios, instancias EC2, funciones Lambda, usuarios federados, llamadores entre cuentas— y producen credenciales temporales de STS que rotan automáticamente. Debido a que esas credenciales no pueden filtrarse en un commit de Git y expiran en minutos u horas en lugar de persistir hasta que se rotan manualmente, los roles son la identidad predeterminada para todo lo que no sea humano.

Dos Políticas por Rol: Permisos y Confianza

Cada rol se rige por dos documentos independientes, y olvidar cualquiera de ellos es un modo de fallo clásico.

La política de permisos (basada en identidad) declara lo que el rol puede hacer una vez asumido. La política de confianza (basada en recursos, asociada al propio rol) declara quién puede asumirlo. Asociar AmazonS3ReadOnlyAccess a un rol no logra nada si a ningún principal se le permite llamar a sts:AssumeRole sobre él y, a la inversa, una política de confianza permisiva sin una política de permisos produce un rol que puede ser asumido pero que no hace nada útil.

Un rol de ejecución de Lambda muestra el patrón de principal de servicio: el servicio mismo, no el propietario de la cuenta, es quien realiza la llamada:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Identidad para Cargas de Trabajo: Perfiles de Instancia, Roles de Tarea, IRSA, Roles Anywhere

Cada credencial que reside en una plantilla, variable de entorno o en un portátil es una futura brecha de seguridad. El patrón canónico de AWS reemplaza las claves de acceso estáticas con credenciales de corta duración y rotación automática entregadas a través de roles.

Para EC2, el mecanismo de entrega es el perfil de instancia (instance profile): un contenedor ligero que vincula un rol de IAM a una instancia para que el Servicio de Metadatos de Instancia (IMDSv2) pueda proporcionar credenciales temporales al SDK. La cadena de proveedores de credenciales predeterminada las encuentra sin configuración, por lo que boto3.client('s3') simplemente funciona y el código de la aplicación nunca ve una credencial. Se debe forzar el uso de IMDSv2 (HttpTokens: required) para evitar la exfiltración de credenciales basada en SSRF. Las credenciales rotan aproximadamente cada seis horas, y la revocación es una simple edición del rol.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Para ECS el análogo es el rol de tarea (task role); para Lambda es el rol de ejecución (execution role); para los pods de EKS es IRSA (IAM Roles for Service Accounts) o EKS Pod Identity. En todos los casos, es AWS mismo quien intermedia las credenciales contra un rol y la carga de trabajo nunca ve un secreto de larga duración.

Incrustar claves de acceso en una AMI, un script de user-data o un archivo .env es incorrecto por tres razones concretas: las claves nunca rotan automáticamente, no pueden ser limitadas al contexto de la sesión como un VPC endpoint de origen, y si la instancia se ve comprometida o una AMI se comparte inadvertidamente, la credencial se filtra de forma permanente.

Para cargas de trabajo fuera de AWS —servidores on-prem, otras nubes, CI runners— que necesitan credenciales temporales de AWS sin claves incrustadas, IAM Roles Anywhere utiliza certificados X.509 de una CA privada (AWS Private CA o una propia) como ancla de confianza (trust anchor). La carga de trabajo presenta su certificado de cliente y recibe credenciales STS de corta duración:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Esto cierra el mismo antipatrón que los roles de instancia y Secrets Manager cierran dentro de AWS.

Acceso Humano a Escala: Identity Center, SAML, Directory Service

Aprovisionar usuarios de IAM por cuenta a cualquier escala es inmanejable. AWS IAM Identity Center (sucesor de AWS SSO) es la puerta de entrada recomendada para el acceso de la fuerza laboral: un directorio único que se federa en cada cuenta de una Organization y emite sesiones temporales basadas en roles a través de conjuntos de permisos (permission sets), que son roles de IAM basados en plantillas y mapeados a grupos del IdP. Los usuarios se autentican una vez en el portal de Identity Center y luego asumen conjuntos de permisos en cualquier cuenta asignada.

Identity Center se integra con IdPs externos (Okta, Entra ID/Azure AD, Google Workspace, ADFS) a través de SAML 2.0 y SCIM para flujos automatizados de altas, cambios y bajas de personal (joiner/mover/leaver), y con Active Directory on-premises a través de AWS Directory Service AD Connector (un proxy) o AWS Managed Microsoft AD (una réplica completa en AWS). Para aplicaciones móviles o web que deben llamar a AWS desde usuarios no autenticados o autenticados por terceros, Amazon Cognito intercambia la identidad externa por credenciales STS temporales, evitando nuevamente las claves de larga duración incrustadas.

Acceso entre Cuentas

El acceso entre cuentas se expresa con roles, no con usuarios compartidos, y ambas partes deben estar de acuerdo. La cuenta de destino (B) crea un rol cuya política de confianza (trust policy) nombra a la Cuenta A (o a un principal específico en ella), y quien llama en A también debe tener el permiso sts:AssumeRole dirigido al ARN de ese rol. Ninguna de las partes por sí sola es suficiente. Esto produce credenciales de corta duración y un rastro de auditoría claro en CloudTrail en ambas cuentas.

Cuando un tercero (un proveedor de SaaS) es el principal que asume el rol, añade una condición ExternalId para evitar el problema del suplente confuso (confused deputy problem), y considera requerir MFA:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Para las invocaciones entre cuentas de servicio a servicio, las políticas de recursos hacen el trabajo. Para permitir que un tema de SNS en la Cuenta A invoque una Lambda en la Cuenta B:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

El --principal sns.amazonaws.com es el principal de servicio (el propio SNS invoca a Lambda), y --source-arn acota la confianza a un tema específico para prevenir el problema del suplente confuso.

Para compartir en S3 a través de una Organization, el enfoque ingenuo —listar el ARN de cada cuenta en la política del bucket— no escala y se rompe cada vez que se añade una nueva cuenta. El patrón correcto es aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Cualquier principal en cualquier cuenta de esa organización está permitido; cualquier otro es denegado. Ten en cuenta que Principal: "*" sin la condición convertiría el bucket en público; la clave de condición es lo que restringe el alcance. El lado de la identidad sigue siendo importante: los usuarios en las cuentas miembro también necesitan el permiso s3:GetObject otorgado por su propia política de IAM (a menos que sean el usuario raíz de la cuenta), porque el acceso entre cuentas requiere que ambas partes permitan la llamada.

Específicamente para S3, desde 2023 la configuración por defecto de Propiedad de Objetos (Object Ownership) Propietario del bucket obligatorio (Bucket owner enforced) deshabilita las ACL por completo, haciendo que las políticas de bucket sean el único mecanismo de autorización para el bucket. Cuando los objetos fueron subidos previamente por otras cuentas, las ACL históricas de los objetos o la ACL predefinida (canned ACL) bucket-owner-full-control pueden seguir en juego.

Organizations y Service Control Policies

AWS Organizations agrupa cuentas en un árbol de OUs (Unidades Organizativas) con una cuenta de gestión (management account) en la raíz. Las Service Control Policies (SCPs) son barreras de protección (guardrails) que se adjuntan a la raíz, a una OU o a una cuenta individual. Se aplican a cada usuario y rol de IAM en la cuenta —incluyendo al usuario raíz de la cuenta— pero no a la propia cuenta de gestión, razón por la cual las cargas de trabajo nunca deben ejecutarse allí.

El modelo mental crítico es: las SCPs nunca otorgan permisos. Definen el conjunto máximo de acciones permitidas en una cuenta. Una acción solo se permite si es otorgada por una política de identidad o de recurso y no está bloqueada por ninguna SCP en la ruta de la cuenta. Si un desarrollador tiene AdministratorAccess pero una SCP deniega ec2:RunInstances fuera de ap-southeast-2, el lanzamiento en us-east-1 fallará. A la inversa, una SCP que permite s3:* no hace nada por sí sola; el usuario todavía necesita una política de IAM que le otorgue s3:*. Las SCPs filtran lo que IAM ya ha permitido; son techos, no suelos.

Los usos típicos de las SCPs incluyen el bloqueo de regiones, la prohibición de desactivar CloudTrail o GuardDuty, la prohibición de eliminar claves KMS fuera de un rol de emergencia (break-glass role) y la imposición del cifrado. Para forzar el cifrado de EBS en el lanzamiento, combina dos mecanismos: habilita el cifrado de EBS por defecto en la región (una configuración de cuenta por región para que los usuarios no cambien los scripts), más una SCP como barrera de protección auditable:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Debido a que las SCPs se aplican a toda la cuenta, no pueden ser eludidas por un administrador comprometido en una cuenta miembro. Las políticas de etiquetas (Tag policies) imponen la estandarización de las claves y el uso de mayúsculas/minúsculas en las etiquetas (CostCenter, no costcenter) para que la asignación de costos y el ABAC funcionen de manera fiable. Organizations también soporta la administración delegada: en lugar de ejecutar los servicios de seguridad desde la cuenta de gestión, delega una cuenta miembro (“seguridad” o “auditoría”) como administradora para GuardDuty, Security Hub, IAM Access Analyzer o Config, preservando así la separación de responsabilidades.

KMS: Claves, políticas de clave y modelos de propiedad

KMS distingue el material de clave por propiedad y control:

Una CMK se rige por una política de clave (key policy), una política basada en recursos adjunta a la clave. A diferencia de casi cualquier otro recurso de AWS, las políticas de IAM por sí solas no pueden otorgar acceso a una clave de KMS a menos que la política de clave delegue primero en IAM:

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Sin esa declaración, ninguna política de IAM hace que la clave sea utilizable. Tanto la política de clave como la política de IAM de la entidad que realiza la llamada deben permitir la operación; este es el error de cifrado más frecuente. Otorgar kms:Decrypt en una política de IAM es necesario pero no suficiente; si la política de clave no delega en IAM o no nombra a la entidad principal (principal), el descifrado falla con AccessDenied incluso para un administrador.

Para los servicios que utilizan KMS en tu nombre (EBS, S3, RDS, Lambda), el rol que realiza la llamada normalmente necesita kms:GenerateDataKey, kms:Decrypt y, a menudo, kms:CreateGrant. Para un grupo de nodos administrados de EKS que cifra volúmenes de EBS con una CMK, el rol vinculado al servicio (service-linked role) de Auto Scaling debe aparecer en la política de clave con kms:CreateGrant, o el lanzamiento de instancias fallará silenciosamente.

La rotación de CMK administradas por el cliente requiere una habilitación explícita; muchos profesionales asumen incorrectamente que todas las claves de KMS rotan automáticamente:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

La rotación conserva el mismo ID de clave y alias; el material de respaldo cambia, pero el texto cifrado anterior sigue siendo descifrable porque KMS retiene el material antiguo para descifrar los textos cifrados existentes, mientras que las nuevas escrituras utilizan material nuevo. El material importado nunca rota automáticamente. KMS impone una ventana de eliminación pendiente obligatoria de 7 a 30 días; combina esto con una regla de EventBridge que coincida con ScheduleKeyDeletion o DisableKey en CloudTrail y apunte a un tema de SNS para un patrón de alerta sin servidor y sin sondeo (poll-free):

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

External Key Stores (XKS) amplían el modelo cuando las regulaciones exigen que el material de clave resida físicamente en un HSM controlado por el cliente. KMS reenvía las operaciones criptográficas a un proxy XKS que se comunica con el HSM on-premise; si el HSM está fuera de línea, el descifrado falla y la disponibilidad se convierte en responsabilidad del cliente.

Claves multirregión (MRK) comparten el mismo ID de clave y material entre Regiones, por lo que el texto cifrado producido en us-east-1 se descifra directamente en eu-west-1. Este es el patrón correcto para las Tablas Globales de DynamoDB, la Replicación entre Regiones de S3 con SSE-KMS y la recuperación ante desastres (DR) donde una Región de reserva debe leer copias de seguridad cifradas. Las claves estándar de una sola Región requerirían descifrar y luego volver a cifrar en el momento de la replicación.

Uso compartido de recursos cifrados entre cuentas

El uso compartido de AMI e instantáneas (snapshots) de EBS cifradas es uno de los modos de fallo entre cuentas más comunes porque requiere cuatro acciones coordinadas: (1) usar una CMK administrada por el cliente (las claves administradas por AWS no se pueden compartir); (2) agregar la cuenta de destino como una entidad principal (principal) en la política de clave con kms:Decrypt, kms:DescribeKey, kms:CreateGrant y kms:ReEncrypt*; (3) modificar los permisos de lanzamiento/uso compartido de la AMI o la instantánea para incluir esa cuenta; y (4) asegurarse de que la entidad principal de IAM en la cuenta de destino también tenga esas acciones de KMS. La operación de compartir parece tener éxito si omites el paso 2, pero la cuenta receptora no puede descifrar. Asumir que compartir la AMI es suficiente es la trampa clásica.

Modos de cifrado del lado del servidor de S3

Cuando un requisito especifica rotación anual automática, auditabilidad en CloudTrail y minimizar el costo de la clave, la respuesta es SSE-KMS con la clave aws/s3 administrada por AWS: rota anualmente sin cargo y cada llamada a GenerateDataKey/Decrypt queda registrada. SSE-S3 es más barato pero no deja rastro del uso de la clave. Una CMK administrada por el cliente añade $1/mes y solo rota si habilitas la rotación.

Confundir SSE-S3 y SSE-KMS es la trampa clásica con la información médica protegida (PHI). SSE-S3 cifra los datos pero no ofrece política de clave, ni visibilidad en CloudTrail, ni forma de que un equipo de cumplimiento administre la clave, por lo que incumple cualquier requisito que mencione “administrar”, “controlar”, “auditar” o “revocar el acceso a” la clave. Por el contrario, elegir SSE-KMS cuando el requisito es solo “cifrar en reposo con una gestión mínima” es un exceso de ingeniería (over-engineering).

Habilitar SSE-KMS no impide por sí solo las lecturas no autorizadas. Si la política del bucket permite s3:GetObject y la política de la clave otorga kms:Decrypt a la misma entidad principal, el objeto es legible. El cifrado en reposo protege contra la vulneración de los medios físicos y añade una segunda comprobación de autorización a través de la política de clave; no sustituye a las políticas de bucket, políticas de IAM, políticas de punto de conexión de VPC y condiciones aws:PrincipalOrgID con un alcance (scope) definido correctamente.

Aplicación del cifrado y TLS en S3

Hacer que un bucket esté “cifrado por defecto” no es suficiente; los clientes pueden omitir o sobreescribir la cabecera de cifrado. Se deben superponer dos barreras de protección: el cifrado de bucket por defecto (completa la cabecera si el cliente la omite) y una política de bucket basada en denegación que rechace PutObject sin la cabecera requerida, además de una declaración que deniegue el acceso que no sea TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

La condición aws:SecureTransport fuerza el uso de HTTPS, cumpliendo con el “cifrado en tránsito”. Combinado con SSE-KMS usando una CMK propiedad del equipo de cumplimiento (compliance), este es el patrón canónico para el almacenamiento de PHI.

Cifrado en tránsito vs. en reposo

El cifrado en reposo (EBS cifrado con KMS, almacenamiento de RDS, objetos de S3) y el cifrado en tránsito (TLS en la red) son controles independientes que abordan diferentes amenazas: el robo de discos frente a la interceptación de la red. Habilitar KMS en una instancia de RDS protege el almacenamiento subyacente; no hace nada por una sesión de cliente a base de datos, que por defecto puede no estar cifrada. Para RDS MySQL, la protección en tránsito requiere descargar el paquete de CA de RDS, establecer require_secure_transport=ON en el grupo de parámetros y conectar los clientes con --ssl-ca=rds-combined-ca-bundle.pem. Considerar que “el cifrado en reposo está activado” es suficiente es un fallo de auditoría frecuente.

Secrets Manager y Parameter Store

Las contraseñas de base de datos estáticas en archivos de configuración, variables de entorno o parámetros de CloudFormation son el principal vector de fuga de credenciales. AWS Secrets Manager almacena secretos cifrados con KMS, los expone a través de la llamada GetSecretValue controlada por IAM y, lo que es más importante, los rota automáticamente mediante una función Lambda de rotación. Para RDS, Aurora, Redshift y DocumentDB, AWS proporciona una Lambda de rotación gestionada que se conecta a la base de datos, genera una nueva contraseña, actualiza tanto el secreto como el usuario de la BD de forma atómica y admite estrategias de usuario único o multiusuario. Para otros sistemas, debes crear una Lambda que implemente el ciclo de vida de cuatro pasos: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Las aplicaciones almacenan en caché el valor brevemente (usando la biblioteca de caché del SDK de AWS) y se reconectan en caso de fallo de autenticación. La rotación es invisible y no se necesita ningún despliegue para cambiar una contraseña.

SSM Parameter Store SecureString es la alternativa cuando no se requiere rotación y el costo es el factor dominante:

Quien recupera un parámetro SecureString necesita tanto ssm:GetParameter como kms:Decrypt sobre la clave. Olvidar el permiso de KMS es una de las configuraciones erróneas más comunes: la política de IAM parece correcta, pero la llamada a la API falla al descifrar.

En EC2, ECS, EKS y Lambda, el código debe asumir un rol de IAM y llamar a GetSecretValue o GetParameter; sin credenciales de larga duración en disco. Incrustar claves de acceso de usuario de IAM directamente en el código de la aplicación, incluso si están cifradas, viola el principio de privilegio mínimo y complica la rotación.

Herramientas de auditoría y análisis forense

CloudTrail registra cada llamada a la API de AWS: quién, qué, cuándo y desde dónde. Un trail de organización habilitado desde la cuenta de administración captura eventos de todas las cuentas en un único bucket de S3, idealmente en una cuenta de seguridad blindada con S3 Object Lock y MFA Delete. Esto proporciona una línea de tiempo forense inmutable: qué principal eliminó un volumen, qué rol modificó un grupo de seguridad, qué clave de acceso llamó a ec2:RunInstances a las 03:17 UTC. Complementa con CloudWatch Logs y alarmas (inicio de sesión de root, cambios en políticas de IAM) y AWS Config para el estado de los recursos en un punto en el tiempo y los paquetes de conformidad (conformance packs). Evita la manipulación con una SCP que deniegue cloudtrail:StopLogging y cloudtrail:DeleteTrail.

MFA Delete en un bucket de S3 obliga al usuario root a presentar un token MFA para eliminar permanentemente la versión de un objeto o deshabilitar el versionado. Solo puede ser habilitado por el usuario root a través de la CLI y proporciona una fuerte protección contra el ransomware y la eliminación por parte de personal interno (insiders).

Amazon Macie utiliza ML gestionado para descubrir PII, PHI, credenciales y datos financieros en S3, produciendo hallazgos clasificados por severidad. Es una herramienta de descubrimiento, no una herramienta de cifrado.

Detección de amenazas: GuardDuty, Security Hub, Detective

Amazon GuardDuty analiza continuamente los VPC Flow Logs, los registros de DNS y los eventos de gestión y de datos de CloudTrail, con planes de protección dedicados para los registros de auditoría de EKS, los eventos de datos de S3, los escaneos de malware de EBS, la actividad de red de Lambda y los eventos de inicio de sesión de RDS. La protección de RDS de GuardDuty saca a la luz intentos de autenticación anómalos o de fuerza bruta contra Aurora y RDS, un comportamiento que un grupo de seguridad no puede detectar porque la conexión es legítima en la capa 4 (L4). Los hallazgos fluyen hacia los paneles de EventBridge, Security Hub y Detective.

Los grupos de seguridad operan solo en las capas 3 y 4 (L3–L4). Un grupo que permite 0.0.0.0/0 en el puerto 443 está haciendo su trabajo cuando reenvía una carga útil (payload) de inyección SQL; eso es precisamente para lo que existe WAF. La defensa en profundidad significa grupos de seguridad más WAF más Shield más GuardDuty, cada uno cubriendo una capa que los otros no pueden ver.

DDoS: Shield Standard y Advanced

AWS Shield Standard es automático y gratuito, y defiende cada cuenta contra ataques comunes de L3/L4 (inundaciones SYN, reflexión). Funciona de forma silenciosa sin visibilidad, sin mitigación personalizada y sin una vía de intervención humana.

AWS Shield Advanced ($3,000/mes por organización más transferencia de datos) es necesario siempre que el escenario mencione intervención proactiva, respuesta dedicada, protección de costos contra el escalado inducido por DDoS, o visibilidad de ataques casi en tiempo real. Cubre CloudFront, Global Accelerator, ALB, CLB, Route 53 y Elastic IPs, y proporciona acceso 24/7 al Shield Response Team (SRT) — preautorizado a través de un rol de IAM — para escribir reglas de WAF en tu nombre durante un ataque activo. Cuando un diseño detrás de un ALB y Route 53 necesita detección gestionada y respuesta humana, Shield Standard por sí solo es insuficiente; esa es la trampa recurrente. Advanced también otorga protección de costos para el escalado provocado por ataques. Cuando se menciona “MENOR esfuerzo de implementación” y la arquitectura ya incluye Global Accelerator o un ALB, la respuesta suele ser habilitar Shield Advanced y adjuntar los grupos de reglas de WAF gestionados por AWS, no construir Lambda@Edge personalizados ni migrar de CDN.

Protección de la capa de aplicación: AWS WAF

AWS WAF se adjunta a CloudFront, Application Load Balancers, API Gateway, AppSync, App Runner y grupos de usuarios de Cognito. No protege los Network Load Balancers directamente (coloca CloudFront delante). Inspecciona el tráfico L7 y aplica reglas para inyección SQL, XSS, restricciones de tamaño, geobloqueo, reputación de IP y limitación de velocidad (rate limiting). Las AWS Managed Rules proporcionan grupos de reglas seleccionados como AWSManagedRulesCommonRuleSet y AWSManagedRulesSQLiRuleSet sin necesidad de escribir regex.

Las reglas basadas en la velocidad (rate-based rules) son la defensa principal contra inundaciones HTTP y credential stuffing: cuentan las solicitudes por ventana de cinco minutos por IP de origen (o por encabezado reenviado) y bloquean a los infractores automáticamente:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF no es un servicio de DDoS; ese es el rol de Shield. WAF complementa las políticas de recursos (políticas de bucket de S3 que deniegan el acceso sin TLS, políticas de VPC endpoint que limitan los buckets accesibles) y los controles de red (grupos de seguridad, NACL) — una mala configuración en una sola capa no debe exponer los datos.

Aislamiento de red: Grupos de seguridad, NACL, Network Firewall

Dentro de una VPC, la defensa se organiza en capas:

• Los grupos de seguridad (Security groups) son stateful, se aplican a las ENI, solo permiten (allow-only) y evalúan todas las reglas en conjunto. El tráfico de retorno se permite automáticamente, por lo que no es necesario abrir explícitamente los puertos efímeros.
• Las ACL de red (Network ACLs) son stateless, se aplican a subredes, admiten tanto permitir (allow) como denegar (deny), y se evalúan en orden numérico. Como son stateless, si permites el tráfico entrante por el puerto 443, también debes permitir el tráfico saliente por los puertos efímeros 1024–65535 para las respuestas. Olvidar esto descarta todas las respuestas de manera sutil. Los grupos de seguridad no tienen este problema.
• AWS Network Firewall proporciona inspección profunda de paquetes (DPI), reglas de IPS compatibles con Suricata y filtrado de egreso basado en dominios, ubicándose entre las subredes y los IGW/TGW para una inspección centralizada.

Asumir que los grupos de seguridad por sí solos son suficientes ignora las amenazas a nivel de subred y los controles del radio de impacto (blast radius); asumir que las NACL por sí solas son suficientes ignora su naturaleza stateless y su granularidad.

Catálogo de trampas

Olvidar la política de confianza (trust policy). La política de permisos de un rol otorga capacidades; solo la política de confianza otorga la capacidad de ser asumido. Ambas deben permitir el acceso para que funcione el acceso entre cuentas o de servicio a servicio; la entidad que llama recibe AccessDenied en sts:AssumeRole sin importar cuán permisiva sea la política de identidad.

Política de IAM sin una política de clave (key policy) correspondiente. kms:Decrypt en IAM es necesario pero no suficiente. La política de la clave debe nombrar al principal o delegar en IAM con Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. El uso compartido de AMI/snapshots cifrados falla cuando solo se comparte la AMI y no se actualiza la política de la clave.

Tratar las SCP como si otorgaran permisos. Las SCP limitan, nunca otorgan. Una SCP con Allow s3:* no hace nada sin una política de identidad correspondiente. Por el contrario, una política de identidad permisiva está limitada por cualquier Deny en una SCP en la ruta de la cuenta.

Asumir la rotación automática de KMS. Las CMK gestionadas por el cliente no rotan hasta que se habilita la opción; el material de clave importado nunca rota automáticamente.

Elegir SSE-S3 para datos controlados por normativas (compliance). SSE-S3 no tiene política de clave, ni visibilidad en CloudTrail, ni una vía de revocación; incumple cualquier requisito que mencione “administrar”, “controlar”, “auditar” o “revocar” la clave.

Tratar el cifrado en reposo como si fuera suficiente. El cifrado en reposo y en tránsito son independientes. Una instancia de RDS con KMS todavía necesita require_secure_transport=ON y validación de la CA del cliente.

Nombrar cuentas individualmente en la política de bucket. No escala y se rompe con los cambios en la organización. Usa aws:PrincipalOrgID.

Claves de acceso hardcodeadas en cualquier lugar. En user data, archivos .env, parámetros de CloudFormation, Git… siempre es incorrecto. Usa perfiles de instancia, roles de tarea, roles de ejecución, IRSA/Pod Identity o Roles Anywhere.

Usuario raíz para trabajo diario o con políticas adjuntas. El usuario raíz no puede ser restringido por IAM o SCP; añadir una política al usuario raíz no tiene sentido. Cualquier respuesta que haga esto es incorrecta a primera vista.

Usuarios de IAM para acceso entre cuentas. Los usuarios de IAM no pueden ser asumidos desde otra cuenta; crea un rol en la cuenta de destino y permite que el principal de la cuenta de origen lo asuma.

NLB detrás de WAF. WAF no se adjunta a los NLB. Coloca el NLB detrás de CloudFront si se necesita filtrado L7.

Falta de puertos efímeros de salida en la NACL. Las NACL stateless necesitan reglas explícitas para la ruta de retorno. La falta de la regla de salida para los puertos 1024–65535 rompe silenciosamente todas las respuestas al tráfico entrante por el puerto 443.

Shield Standard para una intervención gestionada. Standard es pasivo y sin acceso al SRT; solo Advanced satisface los requisitos de “intervención proactiva gestionada” o “protección de costos”.

← Integración de aplicaciones · Todos los dominios · Gestión →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →