Amazon SCS-C02: Seguridad de Contenedores y Serverless — Guía de estudio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

ECS Exec e inspección en tiempo de ejecución sin SSH

ECS Exec proporciona un shell interactivo en un contenedor en ejecución —incluyendo tareas de Fargate— sin exponer SSH, hosts bastión o IP públicas. Funciona aprovechando el agente de SSM que AWS inyecta en el entorno de ejecución sidecar de la tarea. Como no hay un demonio SSH, ni material de claves, ni una ruta de red de entrada que asegurar, la sobrecarga operativa es mínima y cada sesión es auditable a través de CloudTrail y (opcionalmente) registrada en S3 o CloudWatch Logs.

Se deben cumplir tres requisitos para que ECS Exec funcione:

• Permisos del rol de la tarea: el rol de la tarea (no el rol de ejecución) necesita ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel y ssmmessages:OpenDataChannel. El rol de ejecución solo descarga imágenes y escribe logs; el tráfico de SSM en tiempo de ejecución fluye a través del rol de la tarea porque esa es la identidad que asume el proceso del contenedor.

• Configuración del servicio o la tarea: el servicio debe crearse o actualizarse con --enable-execute-command. Esta bandera activa enableExecuteCommand en las nuevas tareas; las tareas existentes deben ser reemplazadas.

• Soporte de la imagen del contenedor: el contenedor necesita un shell (/bin/sh o /bin/bash) presente en la imagen.

Un flujo de inspección típico se ve así:

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

Desde ese shell, un ingeniero puede copiar logs a S3, desencadenar un volcado de memoria (heap dump) o leer /proc para análisis forense. La alternativa —intentar acceder al contenedor por SSH o reiniciar la tarea para habilitar un agente de depuración— o falla en Fargate o destruye la evidencia que intentabas recopilar.

Bloqueo del acceso a IMDS desde contenedores en EC2

Un error común es pensar que la configuración del límite de saltos (hop-limit) de IMDSv2 en la instancia EC2 protege a los contenedores en esa instancia. No lo hacen, al menos no por defecto en los modos de red bridge o host: los contenedores comparten el espacio de nombres de red del host o un puente NAT y pueden alcanzar 169.254.169.254 y recuperar las credenciales del perfil de instancia, que suelen tener muchos más privilegios que el rol de la tarea. Eso anula por completo el principio de privilegio mínimo.

La solución, cuando no es posible migrar a Fargate, tiene dos partes:

• Usar el modo de red awsvpc para las tareas. Cada tarea obtiene su propia ENI y su propio espacio de nombres de red. El tráfico de IMDS ya no llega de forma transparente al endpoint link-local del host.

• Establecer ECS_AWSVPC_BLOCK_IMDS=true en /etc/ecs/ecs.config en la instancia de contenedor. Esto le indica al agente de ECS que instale una regla de iptables que descarte los paquetes de las tareas awsvpc destinados a 169.254.169.254.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Combina eso con un perfil de instancia mínimo (esencialmente solo lo que necesita el agente de ECS: AmazonEC2ContainerServiceforEC2Role) y roles de IAM por tarea para los permisos de la aplicación. Establecer el límite de saltos de IMDS de la instancia en 1 con IMDSv2 requerido es una medida útil de defensa en profundidad, pero no es un sustituto; los contenedores en modo bridge aún pueden alcanzar IMDS en el salto 1 porque la solicitud se origina desde el host.

GuardDuty Runtime Monitoring, EKS Protection y logs del plano de control

GuardDuty ofrece detección de contenedores por capas:

• EKS Protection analiza los logs de auditoría de EKS para detectar actividad sospechosa en la API de Kubernetes: acceso anónimo, creación de pods privilegiados, exec en pods del sistema.

• Runtime Monitoring despliega un sensor basado en eBPF (como un add-on gestionado para EKS, o un agente gestionado por SSM para ECS/Fargate) que observa la actividad de procesos, archivos y red dentro de los contenedores. Expone hallazgos como shells inversas, binarios de criptominería y exfiltración de credenciales desde dentro de un Pod o una tarea.

EKS Protection no sirve de nada a menos que los logs de auditoría del plano de control de EKS se estén emitiendo realmente a CloudWatch Logs. Habilita al menos los tipos de log audit y authenticator en el clúster:

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Sin eso, GuardDuty no tiene plano de datos que inspeccionar para los hallazgos de EKS Protection, una trampa que aparece con frecuencia porque los operadores habilitan la función de GuardDuty pero dejan desactivada la configuración de logs del clúster, y luego se preguntan por qué no aparecen hallazgos de Kubernetes.

Análisis de imágenes con ECR Enhanced Scanning

ECR Enhanced Scanning está impulsado por Amazon Inspector y proporciona un análisis continuo de las imágenes de contenedor en busca de CVEs de sistemas operativos y paquetes de lenguajes (Python, Node, Java, Go, Ruby). El análisis básico es de una sola vez en el momento del push y cubre solo los paquetes del sistema operativo; el mejorado es continuo e incluye las dependencias de la aplicación, que es donde residen la mayoría de las vulnerabilidades modernas.

Los hallazgos fluyen automáticamente a Security Hub cuando ambos servicios están habilitados, lo que proporciona un panel único (single pane of glass) para el cumplimiento y te permite escribir reglas de EventBridge que fallen las compilaciones de CI/CD. Un patrón de aplicación típico:

Problema práctico: Escenario de caso de uso

Escenario: NovaTech Corp ejecuta microservicios de cara al cliente en un entorno de cómputo mixto: varios clústeres de ECS en EC2, un clúster de EKS para el procesamiento de datos y Lambdas sin servidor para el manejo de eventos. Las imágenes se almacenan en ECR, las operaciones utilizan SSM para el acceso a los hosts, y GuardDuty/CloudWatch están habilitados, pero la visibilidad es desigual entre los contenedores y los componentes del plano de control.

Desafío: Un contenedor en producción exhibió conexiones salientes sospechosas y un ingeniero descubrió que un pod podía alcanzar el servicio de metadatos de la instancia EC2, arriesgando la exfiltración de credenciales; las vulnerabilidades en las imágenes y el registro insuficiente del plano de control pueden ocultar la causa raíz.

Enfoque recomendado:

1. Habilitar ECS Exec para las tareas y requerir AWS Systems Manager Session Manager para la inspección del host y del tiempo de ejecución del contenedor (ECS Exec + SSM), eliminando la necesidad de SSH y asegurando que la actividad de la sesión se registre en CloudTrail y CloudWatch Logs.
2. Forzar el uso de IMDSv2 en las instancias EC2 (Instance Metadata Service HttpTokens=required, hop limit=1) y aplicar reglas de red a nivel de host para bloquear 169.254.169.254 desde los espacios de nombres de red de los contenedores para que estos no puedan consultar los metadatos de la instancia.
3. Activar la monitorización en tiempo de ejecución y la protección contra malware de Amazon GuardDuty para contenedores y Lambda, y reenviar los hallazgos a Security Hub y EventBridge para playbooks de contención automatizados.
4. Fortalecer EKS habilitando los registros del plano de control (audit, authenticator, controllerManager, scheduler) hacia CloudWatch Logs, adoptar IAM Roles for Service Accounts (IRSA) y aplicar controles de admisión (Pod Security u OPA Gatekeeper) para limitar capacidades riesgosas.
5. Activar el escaneo de imágenes mejorado de Amazon ECR (escaneo de Inspector/ECR) con escaneo al momento del push (scan-on-push) e integrar los hallazgos en el CI para bloquear/poner en cuarentena las imágenes a través de EventBridge + Lambda para su aplicación.
6. Centralizar la telemetría: enviar los registros de CloudTrail, los hallazgos de GuardDuty, los registros del plano de control de EKS y los resultados del escaneo de ECR a un pipeline centralizado de S3/Lambda/Security Hub y alimentar las reglas de AWS Config para un cumplimiento continuo.

Justificación: Esta secuencia elimina el acceso basado en SSH, previene el robo de credenciales de metadatos, proporciona detección en tiempo de ejecución y respuesta automatizada, impone la higiene de las imágenes y ofrece visibilidad del plano de control, alineándose con las mejores prácticas de AWS de mínimo privilegio, defensa en profundidad y observabilidad centralizada.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

La integración en el pipeline es lo que convierte el escaneo de un ejercicio de panel de control a un control real.

Lambda: Autorizadores, secretos y roles de ejecución

La seguridad a nivel de función Lambda tiene tres planos que frecuentemente se confunden:

• Política de recursos (política de la función): controla qué principales (API Gateway, EventBridge, otras cuentas) pueden invocar la función. Los Lambda Authorizers en API Gateway son la puerta de identidad para las llamadas HTTP; devuelven una política de IAM que API Gateway almacena en caché y aplica antes de invocar la función de backend.

• Rol de ejecución: la identidad que el código de la función asume en tiempo de ejecución. Su política de confianza debe incluir lambda.amazonaws.com, y debe otorgar logs:CreateLogGroup, logs:CreateLogStream y logs:PutLogEvents para que CloudWatch Logs funcione. Si faltan los registros, la solución es casi siempre el rol de ejecución, no la consola de Lambda, que simplemente renderiza los registros que CloudWatch haya recibido. Confiar únicamente en los “registros de la consola” es una trampa de diagnóstico: la falta de permisos en el rol de ejecución significa que no hay flujo de registros, y la consola no muestra nada.

• Recuperación de secretos: nunca incruste credenciales en texto plano en las variables de entorno. Almacénelos en Secrets Manager o SSM Parameter Store SecureString y recupérelos en el arranque en frío (cold start):

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

El rol de ejecución necesita ssm:GetParameter y kms:Decrypt sobre la CMK. Almacene en caché en el ámbito del módulo para que las invocaciones tibias (warm invocations) eviten la llamada a la API; use la extensión de Lambda para Secrets Manager para un almacenamiento en caché automático y consciente de la rotación en funciones de mayor rendimiento (throughput).

Cifrado y protección de repositorios de ECR

Amazon ECR cifra todas las imágenes en reposo por defecto usando AES-256 con una clave administrada por AWS, pero las cargas de trabajo reguladas suelen requerir una clave KMS administrada por el cliente para que la rotación de claves, las políticas de clave y la auditabilidad de CloudTrail estén bajo el control del cliente. El cifrado con KMS se configura solo en el momento de la creación del repositorio; un repositorio de ECR existente no puede cambiarse de AES-256 a KMS a posteriori. Por lo tanto, la migración requiere crear un nuevo repositorio cifrado con KMS, replicar o volver a subir (re-pushing) las imágenes, actualizar los consumidores posteriores y eliminar el repositorio antiguo. Los consumidores de otras cuentas que extraen (pulling) de un repositorio cifrado con KMS deben tener permisos de kms:Decrypt sobre la CMK además de los permisos de lectura de ECR, o la extracción fallará con un error de acceso de KMS aunque la política del repositorio permita al principal.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

Las etiquetas inmutables previenen ataques de secuestro de etiquetas (tag-hijack) donde una etiqueta v1.2.3 validada es sobrescrita silenciosamente por una imagen maliciosa después del escaneo.

Escaneo de Imágenes: Básico, Mejorado e Inspector

ECR ofrece dos modos de escaneo. El escaneo básico utiliza la base de datos de CVE de Clair de código abierto, se ejecuta solo al hacer push (o por invocación manual) y devuelve los hallazgos en la consola de ECR. Es gratuito, pero no realiza reescaneos continuos, no cubre paquetes del SO y de lenguajes de programación juntos, y no tiene integración nativa con Security Hub. El escaneo mejorado está impulsado por Amazon Inspector y cubre tanto los paquetes del sistema operativo como los paquetes de lenguajes de aplicación (Python, Java, Node.js, Go, Ruby, .NET). Inspector monitorea continuamente las imágenes subidas contra la inteligencia de vulnerabilidades actualizada, por lo que un CVE divulgado una semana después de que la imagen fue subida aun así produce un hallazgo sin necesidad de una reconstrucción.

El escaneo mejorado se habilita a nivel de registro (por Región), con filtros de inclusión por repositorio que usan patrones de comodín como prod-* o team-a/*. Este es el control correcto para el requisito común de “escanear la mayoría de los repositorios pero excluir los de sandbox/experimentación” — se definen filtros positivos que listan lo que debe ser escaneado en lugar de exclusiones negativas en repositorios individuales.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Integración con Inspector y Agregación en Security Hub

Amazon Inspector debe estar habilitado en cada cuenta y Región donde se requiera el escaneo. En una configuración de AWS Organizations, la cuenta de herramientas de seguridad se designa como el administrador delegado para Inspector, lo que le permite habilitar el escaneo, configurar la inscripción automática para nuevas cuentas miembro y ver los hallazgos agregados. Olvidar delegar —u olvidar activar la inscripción automática— es un modo de fallo sutil: las nuevas cuentas que se unen a la organización envían contenedores a ECR en silencio que nunca son escaneados, rompiendo las garantías de cobertura sin ninguna superficie de error.

Los hallazgos de Inspector fluyen hacia AWS Security Hub automáticamente cuando ambos servicios están habilitados y la integración de Inspector en Security Hub está activada. Security Hub luego normaliza los hallazgos al formato AWS Security Finding Format (ASFF), los correlaciona con los hallazgos de GuardDuty, Macie y Config, y —cuando se combina con un administrador delegado de Security Hub más la agregación entre Regiones— presenta un panel único. Las reglas de EventBridge sobre los hallazgos de Security Hub pueden enrutar CVEs críticos a Lambda para la creación automatizada de tickets, etiquetar la imagen infractora con una etiqueta quarantine=true, o bloquear el despliegue a través de una puerta de pipeline.

Escaneo Centralizado y CI/CD entre Cuentas

El patrón recomendado para cargas de trabajo de contenedores multicuenta sitúa una cuenta de registro central reforzada en el núcleo:

• Cuenta central: aloja repositorios de ECR cifrados con KMS con escaneo mejorado, etiquetas inmutables y firma de imágenes (a través de Notation/Sigstore integrado con AWS Signer).
• Cuentas de compilación: ejecutan trabajos de CodeBuild/CodePipeline que compilan, suben a ECR central, esperan los hallazgos de Inspector y bloquean en función de umbrales de severidad.
• Cuentas de carga de trabajo (dev/stage/prod): obtienen imágenes del registro central a través de permisos entre cuentas.

El acceso de lectura entre cuentas requiere dos capas: una política de IAM en la cuenta consumidora que otorga ecr:GetDownloadUrlForLayer, ecr:BatchGetImage y ecr:GetAuthorizationToken, más una política de repositorio en el repo de ECR en la cuenta central que permite a la cuenta o rol consumidor específico.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

Debido a que las políticas de repositorio de ECR están basadas en recursos, la intersección de la política de identidad y la de recurso determina el acceso — omitir cualquiera de las capas produce AccessDeniedException. Cuando KMS está involucrado, la política de clave de KMS también debe otorgar kms:Decrypt al principal de la otra cuenta.

Registros y Observabilidad del Plano de Control de EKS

Para EKS, el plano de control gestionado no es directamente accesible, por lo que los eventos de Kubernetes relevantes para la seguridad se exponen solo cuando los registros del plano de control están habilitados explícitamente. Hay cinco tipos de registro disponibles: api, audit, authenticator, controllerManager y scheduler. El registro de audit es el artefacto de seguridad de mayor valor —registra cada llamada a la API del clúster con la identidad del llamante resuelta a través del autenticador de IAM— y authenticator registra las decisiones de mapeo de IAM a RBAC de Kubernetes. Todos los tipos se transmiten a CloudWatch Logs en un grupo de registros /aws/eks/<cluster>/cluster, desde el cual pueden ser suscritos a Kinesis Data Firehose, reenviados a S3 o enviados a un SIEM.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Complemente los registros del plano de control con GuardDuty EKS Protection (detección de amenazas en tiempo de ejecución en los nodos), y use IRSA (IAM Roles for Service Accounts) en lugar de perfiles de instancia de nodo para que los registros de auditoría atribuyan la actividad de la API de AWS a pods específicos.

Errores comunes

Confiar solo en el escaneo al subir (scan-on-push): El escaneo básico al subir (scan-on-push) detecta vulnerabilidades conocidas en el momento de la subida, pero no hace nada con los CVE que se revelan más tarde en imágenes que ya están en el registro. Los marcos de auditoría como PCI DSS y FedRAMP exigen una evaluación continua de vulnerabilidades, lo que requiere un escaneo mejorado con frecuencia CONTINUOUS_SCAN y la agregación en Security Hub. Una instantánea única por subida no cumple con el control.

Omitir KMS en ECR cuando se requiere cifrado en reposo: El cifrado AES-256 por defecto es un cifrado real, pero los regímenes de cumplimiento que exigen claves administradas por el cliente (customer-managed keys), registros de rotación de claves y pistas de auditoría de kms:Decrypt por principal no pueden satisfacerse con claves propiedad de AWS. Debido a que el tipo de cifrado es inmutable por repositorio, esto debe abordarse en el momento de la creación; un “ya lo activaremos más tarde” es imposible sin tener que volver a crear el repositorio.

Olvidar el administrador delegado de Inspector o la inscripción automática: Sin un administrador delegado para Inspector, el propietario de cada cuenta debe habilitar el escaneo y reenviar los hallazgos de forma independiente, lo cual es inviable desde el punto de vista operativo y produce brechas de cobertura. Sin la habilitación automática para nuevas cuentas miembro, cada nueva cuenta creada a través de Control Tower u Organizations comienza con Inspector deshabilitado, por lo que sus imágenes de ECR no se escanean, aunque Security Hub en la cuenta central no muestre hallazgos, lo que resulta en un falso negativo silencioso en lugar de un error obvio.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial opera un entorno de AWS multicuenta con clústeres de EKS en producción, servicios de ECS y múltiples registros de ECR distribuidos entre las cuentas de producción, desarrollo y una cuenta de seguridad dedicada. Sus equipos de ingeniería suben imágenes de contenedor a través de pipelines de CI/CD a ECR y las despliegan en EKS/ECS, mientras que el equipo de seguridad mantiene una cuenta centralizada para el monitoreo y el cumplimiento.

Desafío: Un despliegue reciente entregó un contenedor con una vulnerabilidad de alta severidad que no se detectó antes de la producción, y los investigadores encontraron registros limitados del plano de control de EKS y resultados de escaneo fragmentados entre las cuentas, lo que ralentizó la remediación.

Enfoque recomendado:

1. Habilitar protecciones a nivel de repositorio de ECR: forzar la inmutabilidad de las etiquetas de imagen, aplicar políticas de repositorio que limiten el push/pull a roles de IAM específicos y cifrar los repositorios en reposo con una clave administrada por el cliente (CMK) de AWS KMS dedicada.
2. Activar el escaneo de imágenes al subirlas (básico) y habilitar el escaneo de imágenes mejorado de Amazon Inspector para ECR para producir hallazgos de vulnerabilidades; integrar Inspector con AWS Security Hub para la agregación centralizada de severidades entre cuentas.
3. Implementar un escaneo centralizado entre cuentas: configurar la replicación de ECR o conceder a un rol de CodeBuild/CodePipeline de la cuenta de seguridad permisos de pull entre cuentas para que la cuenta de seguridad escanee cada imagen con Inspector y cualquier herramienta adicional de SCA/DAST, almacenando los artefactos en un bucket de S3 centralizado y cifrado con la CMK de la cuenta de seguridad.
4. Forzar puertas de control (gating) en CI/CD: añadir una etapa de escaneo en el pipeline (CodeBuild/CodePipeline o GitHub Actions con STS assume-role) que consulte los hallazgos de Inspector/Security Hub y bloquee automáticamente o requiera aprobación para imágenes con hallazgos altos/críticos.
5. Mejorar la observabilidad de EKS: habilitar los registros del plano de control de EKS (API, Audit, Authenticator, ControllerManager, Scheduler) hacia CloudWatch Logs en una cuenta de registro centralizada, habilitar CloudTrail para eventos de la API de EKS y usar Container Insights y GuardDuty para el monitoreo en tiempo de ejecución.

Justificación: Este enfoque aplica una defensa en profundidad: cifrar y proteger los registros, automatizar el escaneo mejorado con Inspector, centralizar los hallazgos en Security Hub para una aplicación de políticas consistente, controlar los despliegues en CI/CD y habilitar los registros del plano de control de EKS para una detección y análisis forense rápidos, alineándose con las mejores prácticas de AWS de mínimo privilegio y monitoreo centralizado.

← Vulnerabilidades · Todos los dominios · Respuesta a Incidentes y Análisis Forense →

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

Explorar Amazon →