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

By Laurynas Brazys · 15 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íces, Grupos y Roles

Identity and Access Management es el plano de control por el que pasa cada carga de trabajo, y su principio rector es el de privilegio mínimo: conceder solo lo necesario, solo durante el tiempo que sea necesario, y preferir identidades que produzcan credenciales de corta duración en lugar de las que tienen secretos estáticos.

El usuario root es el propietario de la cuenta, tiene permisos ilimitados y no puede ser restringido por políticas de IAM o SCPs. Esto lo convierte en la credencial más sensible del entorno, y debe tratarse como un acceso de emergencia. En una cuenta nueva: habilite un dispositivo MFA de hardware o virtual en root, establezca una contraseña larga y única, elimine cualquier clave de acceso root histórica y registre contactos alternativos de 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 root 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 firmadas por root de S3/CloudFront). Usar root 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 humano fluye a través de identidades de IAM limitadas por políticas de privilegio mínimo. Adjunte políticas gestionadas a grupos, no a usuarios individuales: un grupo de Administrators con AdministratorAccess adjunto, y usuarios nombrados colocados en él, produce un único punto de cambio y evita el antipatrón de pegar políticas idénticas en cada usuario. Limite los recursos con ARNs explícitos en lugar de *.

Los roles tienen un propósito completamente diferente. Son asumidos por principales —servicios, instancias EC2, funciones Lambda, usuarios federados, llamadores entre cuentas— y producen credenciales STS temporales 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 cualquier cosa no humana.

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, adjunta al propio rol) declara quién puede asumirlo. Adjuntar AmazonS3ReadOnlyAccess a un rol no logra nada si a ningún principal se le permite llamar a sts:AssumeRole en é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 no hace nada útil.

Un rol de ejecución de Lambda muestra el patrón de principal de servicio: el propio servicio, no el propietario de la cuenta, es el llamador:

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 de la carga de trabajo: perfiles de instancia, roles de tarea, IRSA, Roles Anywhere

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

Para EC2, el mecanismo de entrega es el perfil de instancia, un contenedor delgado que vincula un rol de IAM a una instancia para que el Servicio de Metadatos de Instancia (IMDSv2) pueda vender 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. IMDSv2 (HttpTokens: required) debe aplicarse 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 de 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; para Lambda es el rol de ejecución; para los pods de EKS es IRSA (IAM Roles for Service Accounts) o EKS Pod Identity. En cada caso, AWS mismo intermedia las credenciales contra un rol y la carga de trabajo nunca ve un secreto de larga duración.

Incorporar claves de acceso en una AMI, script de datos de usuario o archivo .env es incorrecto por tres razones concretas: las claves nunca rotan automáticamente, no se pueden limitar al contexto de la sesión como un punto final de VPC de origen, y si la instancia se ve comprometida o una AMI se comparte inadvertidamente, la credencial se filtra permanentemente.

Para cargas de trabajo fuera de AWS (servidores locales, otras nubes, ejecutores de CI) que necesitan credenciales temporales de AWS sin claves incrustadas, IAM Roles Anywhere utiliza certificados X.509 de una CA privada (AWS Private CA o la suya propia) como ancla de confianza. 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

El aprovisionamiento de usuarios de IAM por cuenta a cualquier escala es inmanejable. AWS IAM Identity Center (sucesor de AWS SSO) es la puerta principal recomendada para el acceso de la fuerza laboral: un directorio único que se federa en cada cuenta de una Organización y emite sesiones temporales basadas en roles a través de conjuntos de permisos, roles de IAM con plantilla mapeados a grupos de IdP. Los usuarios se autentican una vez en el portal de Identity Center, luego asumen conjuntos de permisos en cualquier cuenta asignada.

Identity Center se integra con IdP externos (Okta, Entra ID/Azure AD, Google Workspace, ADFS) a través de SAML 2.0 y SCIM para flujos automatizados de incorporación/movimiento/baja, y con Active Directory local 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 nombra a la Cuenta A (o a un principal específico en ella), y el llamador en A también debe tener permiso sts:AssumeRole dirigido al ARN de ese rol. Cualquiera de las partes por sí sola es insuficiente. Esto produce credenciales de corta duración y un claro registro de auditoría de CloudTrail en ambas cuentas.

Cuando un tercero (un proveedor de SaaS) es el principal que asume, agregue una condición ExternalId para evitar el problema del diputado confundido, y considere 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 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 (SNS mismo invoca a Lambda), y --source-arn limita la confianza a un tema específico para evitar el problema del diputado confundido.

Para el intercambio de S3 entre organizaciones, el enfoque ingenuo (listar cada ARN de cuenta en la política del bucket) no escala y se rompe cada vez que se agrega 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 otra persona es denegada. Tenga en cuenta que Principal: "*" sin la condición sería un bucket 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 s3:GetObject otorgado por su propia política de IAM (a menos que sean la raíz de la cuenta), porque el acceso entre cuentas requiere que ambas partes permitan la llamada.

Para S3 específicamente, desde 2023, la configuración predeterminada de Propiedad de objetos Bucket owner enforced deshabilita completamente las ACL, lo que convierte las políticas de bucket en el único mecanismo de autorización para el bucket. Cuando los objetos fueron cargados previamente por otras cuentas, las ACL de objetos históricas o la ACL predefinida bucket-owner-full-control aún pueden estar en juego.

Organizaciones y políticas de control de servicios

AWS Organizations agrupa cuentas en un árbol de UO con una cuenta de administración en la raíz. Las Políticas de Control de Servicios (SCP) son barreras de seguridad adjuntas a la raíz, una UO o una cuenta individual. Se aplican a cada usuario y rol de IAM en la cuenta — incluyendo la raíz de la cuenta — pero no a la propia cuenta de administración, razón por la cual las cargas de trabajo nunca deben ejecutarse allí.

El modelo mental crítico: las SCP 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 recursos 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 falla. Por el contrario, una SCP que permite s3:* no hace nada por sí misma; el usuario aún necesita una política de IAM que otorgue s3:*. Las SCP filtran lo que IAM ya ha permitido; son techos, no suelos.

Los usos típicos de las SCP incluyen el bloqueo de regiones, la prohibición de deshabilitar CloudTrail o GuardDuty, la prohibición de la eliminación de claves de KMS fuera de un rol de “break-glass”, y la aplicación del cifrado. Para forzar el cifrado de EBS en el lanzamiento, combine dos mecanismos: habilite 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 seguridad auditable:

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

Debido a que las SCP se aplican a toda la cuenta, no pueden ser eludidas por un administrador comprometido en una cuenta miembro. Las políticas de etiquetas aplican claves de etiquetas estandarizadas y mayúsculas/minúsculas (CostCenter, no costcenter) para que la asignación de costos y ABAC funcionen de manera confiable. Organizations también admite la administración delegada: en lugar de ejecutar servicios de seguridad desde la cuenta de administración, delegue una cuenta miembro (“seguridad” o “auditoría”) como administrador para GuardDuty, Security Hub, IAM Access Analyzer o Config, preservando la separación de funciones.

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

KMS distingue el material de clave por propiedad y control:

Una CMK se rige por una política de claves, 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 claves delegue primero a 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 claves como la política de IAM del llamador 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 claves no delega a IAM o no nombra al principal, el descifrado falla con AccessDenied incluso para un administrador.

Para los servicios que usan KMS en su nombre (EBS, S3, RDS, Lambda), el rol de llamada generalmente 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 de Auto Scaling debe aparecer en la política de claves con kms:CreateGrant, o los lanzamientos de instancias fallarán 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 usan material nuevo. El material importado nunca rota automáticamente. KMS aplica una ventana de eliminación pendiente obligatoria de 7 a 30 días; combine esto con una regla de EventBridge que coincida con ScheduleKeyDeletion o DisableKey en CloudTrail y dirija un tema de SNS para un patrón de alerta sin servidor y sin sondeo:

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

Los Almacenes de Claves Externos extienden el modelo cuando los reguladores 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 local; si el HSM está fuera de línea, el descifrado falla, la disponibilidad se convierte en responsabilidad del cliente.

Las Claves Multirregión (MRK) comparten el mismo ID de clave y material entre Regiones, de modo 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 DR donde una Región en espera 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.

Compartir recursos cifrados entre cuentas

El intercambio de AMI y instantáneas de EBS cifradas es uno de los modos de falla 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 principal en la política de claves con kms:Decrypt, kms:DescribeKey, kms:CreateGrant y kms:ReEncrypt*; (3) modificar los permisos de lanzamiento/compartición de la AMI o instantánea para incluir esa cuenta; y (4) asegurarse de que el principal de IAM en la cuenta de destino también tenga esas acciones de KMS. La operación de compartición parece tener éxito si se omite el paso 2, pero la cuenta receptora no puede descifrar. Asumir que solo el intercambio de 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 de CloudTrail, y minimización del costo de la clave, la respuesta es SSE-KMS con la clave aws/s3 gestionada por AWS — rota anualmente sin cargo y cada llamada a GenerateDataKey/Decrypt se registra. SSE-S3 es más barato pero no deja rastro de uso de clave. Un CMK gestionado por el cliente añade $1/mes y solo rota si se habilita la rotación.

Confundir SSE-S3 y SSE-KMS es la clásica trampa de la información de salud protegida (PHI). SSE-S3 cifra los datos pero no proporciona una política de claves, visibilidad en CloudTrail ni una forma para que un equipo de cumplimiento administre la clave, por lo que falla 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 una sobreingeniería.

Habilitar SSE-KMS no impide por sí mismo las lecturas no autorizadas. Si la política del bucket permite s3:GetObject y la política de claves otorga kms:Decrypt al mismo principal, el objeto es legible. El cifrado en reposo defiende contra la corrupción física de los medios y añade una segunda verificación de autorización a través de la política de claves; no sustituye a las políticas de bucket, políticas de IAM, políticas de punto final de VPC y condiciones aws:PrincipalOrgID correctamente definidas.

Aplicación del cifrado y TLS en S3

Hacer que un bucket esté “cifrado por defecto” no es suficiente: los clientes pueden omitir o anular el encabezado de cifrado. Deben superponerse dos barreras de seguridad: el cifrado de bucket por defecto (rellena el encabezado si el cliente omite uno) y una política de bucket basada en denegación que rechace PutObject sin el encabezado requerido, además de una declaración que deniegue el acceso no 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 HTTPS, satisfaciendo “cifrado en tránsito”. Combinado con SSE-KMS utilizando un CMK propiedad del equipo de cumplimiento, este es el patrón canónico de almacenamiento de PHI.

Cifrado en tránsito vs. en reposo

El cifrado en reposo (EBS cifrado con KMS, almacenamiento RDS, objetos S3) y el cifrado en tránsito (TLS en la red) son controles independientes que abordan diferentes amenazas: robo de disco versus interceptación de red. Habilitar KMS en una instancia 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. Tratar “el cifrado en reposo está activado” como suficiente es un error frecuente en las auditorías.

Secrets Manager y Parameter Store

Las contraseñas estáticas de bases de datos 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 GetSecretValue controlado por IAM y, lo que es fundamental, los rota automáticamente mediante una función de rotación de Lambda. Para RDS, Aurora, Redshift y DocumentDB, AWS proporciona una función 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 base de datos de forma atómica y admite estrategias de usuario único o multiusuario. Para otros sistemas, usted crea una función Lambda que implementa 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 ninguna implementación 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:

El recuperador de un parámetro SecureString necesita tanto ssm:GetParameter como kms:Decrypt en 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; no hay credenciales de larga duración en el disco. Incrustar claves de acceso de usuario de IAM directamente en el código de la aplicación, incluso cifradas, viola el principio de privilegio mínimo y complica la rotación.

Herramientas de auditoría y forenses

CloudTrail registra cada llamada a la API de AWS: quién, qué, cuándo, desde dónde. Un registro de la 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 bloqueada 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. Complemente con CloudWatch Logs y alarmas (inicio de sesión de root, cambios de política de IAM) y AWS Config para el estado de los recursos en un momento dado y los paquetes de conformidad. Evite 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 de MFA para eliminar permanentemente una versión de 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 interna.

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

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

Amazon GuardDuty analiza continuamente los registros de flujo de VPC, los registros de DNS y los eventos de datos y administración 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 detecta 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. Los hallazgos fluyen a los paneles de EventBridge, Security Hub y Detective.

Los grupos de seguridad operan solo en las capas 3 y 4. Un grupo que permite 0.0.0.0/0 en el puerto 443 está haciendo su trabajo cuando reenvía una carga útil de inyección SQL; eso es precisamente lo que WAF existe para detener. 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 capa 3/4 (inundaciones SYN, reflexión). Se ejecuta silenciosamente sin visibilidad, sin mitigación personalizada y sin ruta de intervención humana.

AWS Shield Advanced (3000 $/mes por organización más transferencia de datos) es necesario siempre que el escenario mencione participació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 su nombre durante un ataque activo. Cuando un diseño detrás de un ALB y Route 53 necesita detección administrada 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 activado por ataques. Cuando se menciona “MÍNIMO 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 administrados por AWS, no construir Lambda@Edge personalizados ni migrar 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 los grupos de usuarios de Cognito. No protege directamente los Network Load Balancers (coloque CloudFront delante). Inspecciona el tráfico de la capa 7 y aplica reglas para inyección SQL, XSS, restricciones de tamaño, geobloqueo, reputación de IP y limitación de velocidad. Las reglas administradas de AWS proporcionan grupos seleccionados como AWSManagedRulesCommonRuleSet y AWSManagedRulesSQLiRuleSet sin escribir expresiones regulares.

Las reglas basadas en tasas son la principal defensa contra las inundaciones HTTP y el relleno de credenciales: 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 DDoS, ese es el papel de Shield. WAF complementa las políticas de recursos (políticas de bucket de S3 que deniegan no TLS, políticas de punto final de VPC que limitan los buckets accesibles) y los controles de red (grupos de seguridad, NACL); una configuración incorrecta en cualquier capa no debe exponer los datos.

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

Dentro de una VPC, la defensa es por capas:

• Los grupos de seguridad tienen estado, se aplican a las ENI, solo permiten y evalúan todas las reglas juntas. El tráfico de retorno se permite automáticamente, por lo que no es necesario abrir explícitamente los puertos efímeros.
• Las NACL no tienen estado, se aplican a las subredes, admiten tanto permitir como denegar, y se evalúan en orden numérico. Debido a que no tienen estado, si permite la entrada 443, también debe permitir la salida efímera 1024–65535 para las respuestas. Olvidar esto descarta todas las respuestas de formas sutiles. Los grupos de seguridad no tienen este problema.
• AWS Network Firewall proporciona inspección profunda de paquetes, reglas IPS compatibles con Suricata y filtrado de salida basado en dominios, ubicándose entre subredes e 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 de radio de explosión; asumir que las NACL por sí solas son suficientes ignora su falta de estado y su tosquedad.

Catálogo de trampas

Política de confianza olvidada. La política de permisos de un rol otorga capacidades; solo la política de confianza otorga la capacidad de ser asumido. Ambas deben estar abiertas para que el acceso entre cuentas o de servicio a servicio funcione; el llamador recibe AccessDenied en sts:AssumeRole independientemente de cuán permisiva sea la política de identidad.

Política de IAM sin política de clave coincidente. kms:Decrypt en IAM es necesario pero no suficiente. La política de clave debe nombrar al principal o delegar a IAM con Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. El intercambio de AMI/instantáneas cifradas falla cuando solo se realiza el intercambio de AMI y la política de clave no se actualiza.

SCPs tratados como concesiones. Los SCPs limitan, nunca conceden. Un SCP Allow s3:* no hace nada sin una política de identidad coincidente. Por el contrario, una política de identidad permisiva está limitada por cualquier Deny de SCP en la ruta de la cuenta.

Asumiendo la rotación automática de KMS. Las CMK administradas por el cliente no rotan hasta que se habilitan; el material importado nunca rota automáticamente.

SSE-S3 elegido para datos controlados por cumplimiento. SSE-S3 no tiene política de clave, no tiene visibilidad de CloudTrail y no tiene ruta de revocación; falla cualquier requisito que mencione “administrar”, “controlar”, “auditar” o “revocar” la clave.

Cifrado en reposo tratado como suficiente. En reposo y en tránsito son independientes. RDS con KMS aún necesita require_secure_transport=ON y validación de CA del cliente.

Política de bucket nombrando cuentas individualmente. No escala y se rompe con los cambios de la organización. Use aws:PrincipalOrgID.

Claves de acceso codificadas en cualquier lugar. En datos de usuario, archivos .env, parámetros de CloudFormation, Git, siempre es incorrecto. Use perfiles de instancia, roles de tarea, roles de ejecución, IRSA/Pod Identity o Roles Anywhere.

Usuario root para el trabajo diario o políticas adjuntas. El usuario root no puede ser restringido por IAM o SCPs; agregar una política al usuario root no tiene sentido. Cualquier respuesta que lo haga es incorrecta de entrada.

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

NLB detrás de WAF. WAF no se adjunta a los NLB. Coloque CloudFront delante del NLB si se necesita filtrado de capa 7.

NACL sin efímero de salida. Las NACL sin estado necesitan reglas explícitas de ruta de retorno. La falta de salida 1024–65535 rompe silenciosamente todas las respuestas entrantes 443.

Shield Standard para compromiso gestionado. Standard es pasivo sin acceso a SRT; solo Advanced satisface el “compromiso gestionado proactivo” o la “protección de costos”.

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

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

Explorar Amazon →