Amazon SCS-C02: Vulnerabilidades, Parches y Seguridad del Host — Guía de estudio
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.
Amazon Inspector: Escaneo Mejorado en EC2, Lambda y ECR
Amazon Inspector es un servicio de gestión de vulnerabilidades continuo y compatible con agentes que descubre CVE en instancias EC2, imágenes de contenedor almacenadas en ECR y funciones Lambda (tanto el código de la aplicación como las capas de dependencias). Habilitar Inspector a nivel de cuenta inscribe automáticamente los recursos elegibles —no existe un flujo de trabajo de suscripción por recurso— y los hallazgos se envían automáticamente a AWS Security Hub en el formato estandarizado ASFF, que es el patrón de integración correcto cuando se requiere un panel centralizado de postura de seguridad.
Para EC2, Inspector utiliza un modelo de escaneo híbrido. El SSM Agent (con la asociación proporcionada por AWS) recopila un inventario de software utilizado para la evaluación de paquetes y de alcanzabilidad de red al estilo sin agente (agentless), mientras que la evaluación profunda del host requiere que el agente esté en ejecución y que la instancia sea alcanzable a través de SSM. Es por esto que el enfoque de “solo sin agente” es una trampa: sin la ruta del SSM Agent (o la inspección profunda basada en agente de Inspector donde sea necesario), se obtienen hallazgos superficiales —exposición de red y CVE derivados de manifiestos— pero se omiten los inventarios de bibliotecas en tiempo de ejecución, los paquetes no gestionados y las configuraciones. El modo híbrido es lo que la mayoría de los entornos de producción necesitan.
Para Lambda, Inspector realiza dos tipos de escaneo: estándar (vulnerabilidades de paquetes en capas y dependencias de funciones) y escaneo de código (análisis estático del código de la función en busca de fallas de inyección, secretos codificados y API inseguras). Una regla de elegibilidad crítica: una función Lambda debe haber sido invocada al menos una vez en los últimos 90 días para ser escaneada. Las funciones inactivas o archivadas salen silenciosamente del alcance de Inspector. Los equipos que asumen que “Inspector está habilitado, por lo tanto, cada función está cubierta” se ven en problemas cuando los auditores piden evidencia sobre funciones que se ejecutan con poca frecuencia. La remediación es invocar las funciones según un cronograma (EventBridge) o aceptar la exclusión y documentarla.
Para ECR, el escaneo mejorado (enhanced scanning), impulsado por Inspector, reemplaza al antiguo escaneo básico basado en Clair. El escaneo mejorado admite tanto el escaneo al subir (scan on push) como el escaneo continuo (continuous scanning) de imágenes que ya están en el registro, de modo que los CVE recién divulgados para imágenes subidas previamente generan nuevos hallazgos sin necesidad de volver a subirlas. Habilite el escaneo mejorado a nivel de registro y configure filtros por repositorio (por ejemplo, prod/* continuo, sandbox/* solo escaneo al subir) para controlar los costos.
Administración Delegada y Supresión
En una configuración de múltiples cuentas con AWS Organizations, designe una cuenta de administrador delegado para Inspector desde la cuenta de gestión. El administrador delegado ve los hallazgos agregados de todas las cuentas miembro y controla la configuración de escaneo de toda la organización. Esto evita otorgar roles IAM entre cuentas para la recuperación de hallazgos y previene el antipatrón de habilitar Inspector de forma fragmentada por cuenta.
Las reglas de supresión permiten a un equipo de seguridad filtrar el ruido sin eliminar los hallazgos. Una regla establece coincidencias basadas en atributos como la etiqueta del recurso, la severidad, el ID del CVE o el repositorio de ECR. Para mantener los hallazgos de Lambda de desarrollo/pruebas fuera del panel de producción, aplique una regla de supresión basada en la etiqueta Environment=dev —los hallazgos siguen existiendo en el almacén de datos subyacente para auditoría, pero se excluyen de las vistas predeterminadas y de Security Hub si así se configura. No logre esto deshabilitando Inspector para las cuentas de desarrollo; perdería la capacidad de detectar la promoción de un artefacto vulnerable de desarrollo a producción.
Control de Acceso (Gating) en CI/CD para la Promoción de Imágenes
El escaneo mejorado de ECR genera hallazgos vinculados a un resumen de imagen (image digest) (no solo a la etiqueta), que es lo que un pipeline debe consultar. El patrón canónico es: construir imagen → subir a ECR (desencadena el escaneo al subir) → sondear o esperar a que se complete el escaneo → hacer que la compilación falle si existen hallazgos de severidad Alta o Crítica → de lo contrario, actualizar la tarea/despliegue de ECS/EKS.
Un paso mínimo de CodeBuild en buildspec.yml:
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
No realizar este control de acceso en esta etapa —confiando en que “Inspector nos alertará”— es el error clásico: las alertas llegan de forma asíncrona y después de que la imagen vulnerable ya está en ejecución. El control de acceso debe ser síncrono con la promoción. Del mismo modo, realizar el control de acceso solo sobre la etiqueta en lugar del resumen (digest) es inseguro porque las etiquetas son mutables; dos subidas con la misma etiqueta mezclarán los resultados de los escaneos.
Patch Manager, Líneas Base y Grupos de Parches
SSM Patch Manager opera sobre tres primitivas:
Línea base de parches (Patch baseline): define reglas de aprobación automática, parches aprobados, parches rechazados y nivel de conformidad por severidad/clasificación.
Grupo de parches (Patch group): una etiqueta con la clave exacta
Patch Groupcuyo valor registra instancias en una línea base específica.Ventana de mantenimiento (Maintenance window): el cronograma durante el cual
AWS-RunPatchBaselineejecuta tareas de Escaneo (Scan) o Instalación (Install).
Para un entorno que requiere que Dev apruebe automáticamente todos los parches de seguridad de inmediato, y que Prod apruebe automáticamente solo los Críticos/Importantes después de un período de prueba de 7 días mientras rechaza los paquetes del kernel, se crean dos líneas base. La línea base de Dev utiliza una regla de aprobación con ApproveAfterDays: 0 que cubre todas las clasificaciones de seguridad. La línea base de Prod utiliza ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtra por Classification=Security y Severity in [Critical, Important], y añade kernel* a la lista de parches rechazados con BlockAllPatchesFromRejectedList. Las instancias se etiquetan con Patch Group=Dev o Patch Group=Prod, y cada grupo de parches se registra en la línea base correspondiente. La conformidad se consolida a través de los informes de Patch Compliance y se puede exportar a S3 para una auditoría centralizada.
Una única línea base “con lógica” no puede expresar las diferencias entre Dev y Prod — las líneas base son estáticas por cada grupo registrado. No intente utilizar diferentes Ventanas de Mantenimiento para simular este comportamiento; la ventana controla cuándo se ejecuta el parcheo, no qué parches se aprueban.
Canalización de Notificaciones en Tiempo Real
Para las alertas en Slack o Microsoft Teams sobre nuevos hallazgos, la cadena operacionalmente eficiente es:
Inspector emite hallazgos a EventBridge en el origen de eventos
aws.inspector2.Una regla de EventBridge filtra por severidad (p. ej.,
HIGH,CRITICAL) y apunta a un tema de SNS.El tema de SNS tiene una suscripción de AWS Chatbot mapeada al canal de Slack o al espacio de trabajo de Teams.
Chatbot se suscribe directamente a SNS; no interpongas una función Lambda para reformatear mensajes, ya que Chatbot renderiza nativamente los hallazgos de Inspector. Un patrón de ejemplo para EventBridge:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Hay dos trampas que se deben evitar aquí: enrutar a través de Security Hub añade latencia y puede eliminar la granularidad de la severidad si las estadísticas personalizadas (custom insights) están mal configuradas; y usar SES o una Lambda con un webhook personalizado aumenta la sobrecarga operativa sin añadir capacidades que Chatbot ya proporciona de forma nativa.
Problema Práctico: Escenario de Caso de Uso
Escenario: Meridian Financial opera una organización de AWS multicuenta que soporta servicios web de cara al cliente, análisis por lotes (batch analytics) y procesadores de eventos sin servidor (serverless). Sus canalizaciones de CI/CD envían imágenes de contenedor a Amazon ECR, alojan flotas de EC2 para cargas de trabajo heredadas (legacy) y usan Lambda para servicios más nuevos; un equipo de seguridad central en una cuenta de seguridad debe gestionar la visibilidad de vulnerabilidades y la aplicación de parches en todas las cuentas.
Desafío: Recientemente, una imagen que contenía una librería con una vulnerabilidad de alta severidad fue promovida a producción porque los escaneos no se aplicaron de forma obligatoria en CI/CD, y la aplicación de parches en las instancias EC2 es inconsistente entre los entornos, dejando ventanas de exposición y hallazgos ruidosos que abruman al equipo.
Enfoque Recomendado:
- Habilitar Amazon Inspector Enhanced Scanning para EC2, Lambda y ECR desde la cuenta de seguridad, configurando la administración delegada en AWS Organizations para que los escaneos, hallazgos y reglas de supresión se puedan gestionar de forma centralizada.
- Configurar el escaneo de imágenes de ECR al subirlas (on push) e integrar puertas de escaneo (scan gates) en CodePipeline/CodeBuild: bloquear la promoción de imágenes hasta que los resultados del escaneo de Inspector/ECR cumplan con los umbrales de severidad y mostrar los hallazgos a través del paso de compilación (build step).
- Implementar AWS Systems Manager Patch Manager con líneas base de parches (patch baselines) y grupos de parches (patch groups) definidos por entorno, programar Ventanas de Mantenimiento (Maintenance Windows) para un despliegue que priorice los entornos de no producción, y automatizar la aprobación de correcciones para CVEs críticos usando documentos de SSM Automation.
- Crear una canalización de notificaciones en tiempo real usando Amazon EventBridge para capturar los hallazgos de Inspector y los eventos de conformidad de SSM, enrutarlos a Amazon SNS y a una AWS Lambda ligera que enriquezca, deduplique y publique alertas priorizadas en Slack y cree tickets de seguimiento.
- Automatizar la contención y remediación: usar runbooks de SSM Automation o Lambda activados por EventBridge para aislar las versiones de EC2/Lambda impactadas o para activar la reconstrucción de imágenes, y aplicar la supresión de Inspector solo para falsos positivos documentados a través de la cuenta de administrador delegado para reducir el ruido.
Justificación: La gestión centralizada de Inspector, las puertas de control en CI/CD, las líneas base de Patch Manager y una canalización impulsada por EventBridge siguen las mejores prácticas de AWS al imponer la prevención automatizada, la aplicación de parches consistente y una respuesta priorizada y auditable, al tiempo que se reduce la fatiga por alertas.
Descubrimiento de Vulnerabilidades con Amazon Inspector
Amazon Inspector es el principal servicio gestionado de evaluación de vulnerabilidades en AWS, y opera sobre tres superficies relevantes para la seguridad del host: instancias EC2, imágenes de contenedor en Amazon ECR y funciones Lambda. Cuando se habilita a nivel de cuenta o de Organizations (a través de un administrador delegado en la consola de Inspector), realiza un escaneo continuo basado en agente SSM o sin agente, en lugar de escaneos programados en un momento específico (point-in-time). Esta postura continua es importante porque las fuentes de CVEs cambian a diario; una instantánea de la semana pasada puede estar ya obsoleta.
Para EC2, Inspector depende del SSM Agent para enumerar los paquetes instalados y las versiones del kernel, y luego los correlaciona con los avisos de los proveedores y la National Vulnerability Database. Los hallazgos incluyen el identificador CVE, la puntuación CVSS, el paquete afectado, la versión corregida y el contexto de alcanzabilidad de red (las reglas de alcanzabilidad de red identifican los puertos expuestos a internet a través de ENIs, grupos de seguridad, NACLs y tablas de enrutamiento). Debido a que el escaneo depende de SSM, una instancia EC2 que carezca de la política gestionada AmazonSSMManagedInstanceCore en su perfil de instancia simplemente no aparecerá en los resultados de Inspector, un fallo silencioso que vale la pena recordar.
Para ECR, Inspector soporta dos modos de escaneo:
Escaneo básico (Basic scanning): gratuito, utiliza el motor de código abierto Clair, se ejecuta solo al subir una imagen (on push) o bajo demanda.
Escaneo mejorado (Enhanced scanning): impulsado por Inspector, reescanea continuamente las imágenes (tanto los paquetes del SO como los paquetes de lenguajes de aplicación como Python, Node, Java) a medida que se publican nuevos CVEs, incluso mucho después del evento de subida.
Una trampa común es tratar el escaneo al subir a ECR (scan-on-push) como una medida de seguridad de host suficiente. No lo es. El escaneo al subir valida la imagen en el momento de la compilación, pero el contenedor en ejecución hereda la imagen más cualquier desviación (drift), y el host subyacente de EC2 o Fargate tiene su propio kernel y paquetes de SO que deben ser parcheados de forma independiente. El escaneo mejorado combinado con el escaneo del host EC2 cierra esa brecha. Todos los hallazgos de Inspector deben ser enrutados a AWS Security Hub, que los normaliza al formato ASFF y permite la agregación entre cuentas, la deduplicación y la automatización posterior a través de EventBridge.
Patch Manager y remediación a nivel de flota
AWS Systems Manager Patch Manager complementa a Inspector al remediar realmente lo que Inspector descubre. Mientras que Inspector responde “¿qué CVE me afectan?”, Patch Manager responde “¿qué parches faltan y cómo los instalo de forma segura?”.
Patch Manager opera a través de líneas base de parches (patch baselines): reglas declarativas que definen qué parches están aprobados, basándose en la clasificación (Seguridad, Crítico, Corrección de errores), la severidad y un retraso de aprobación automática (por ejemplo, aprobar parches de seguridad siete días después de su lanzamiento para permitir la estabilidad del proveedor). AWS proporciona líneas base predeterminadas por sistema operativo (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, etc.), pero las flotas de producción suelen utilizar líneas base personalizadas vinculadas a grupos de parches (patch groups) a través de la etiqueta Patch Group en las instancias.
Un flujo de trabajo típico de escaneo y aplicación de parches utiliza dos operaciones:
Scan (Escanear): informa sobre el cumplimiento sin instalar nada; los resultados aparecen en el panel de cumplimiento de Patch Manager y en Config.
Install (Instalar): aplica los parches aprobados y, para muchos sistemas operativos, reinicia.
Estas operaciones se programan típicamente a través de ventanas de mantenimiento (maintenance windows) con un documento AWS-RunPatchBaseline como objetivo. Para escenarios urgentes de día cero, Patch Manager ofrece Patch Now (Aplicar parches ahora), una acción bajo demanda que omite la programación de la ventana de mantenimiento. El patrón recomendado es crear una línea base de parches específica que apruebe únicamente el KB o paquete concreto que corrige la vulnerabilidad, apuntar al grupo de parches afectado, ejecutar Patch Now y transmitir la salida de la ejecución a un bucket de S3 central y a un grupo de CloudWatch Logs. Ese registro centralizado se convierte en tu artefacto de auditoría: la prueba de la remediación para los auditores o la respuesta a incidentes.
Problema práctico: Escenario de caso de uso
Escenario: Meridian Financial opera un entorno de AWS multicuenta con varios cientos de instancias EC2 (Windows y Amazon Linux) y un pequeño clúster de EKS que da soporte a servicios de cara al cliente. Utilizan AWS Organizations, AWS Systems Manager para herramientas operativas y mantienen las AMIs en una cuenta de imágenes compartida, pero no tienen un escaneo de vulnerabilidades automatizado y consistente ni despliegues de parches coordinados entre cuentas.
Desafío: Se publica un CVE que afecta a OpenSSL y Amazon Inspector reporta hallazgos de alta severidad en múltiples instancias, pero la aplicación de parches ha sido desigual y un servicio de producción sufrió un breve intento de explotación debido a la demora en la remediación.
Enfoque recomendado:
- Habilitar Amazon Inspector en todas las cuentas y regiones para realizar escaneos de vulnerabilidades tanto en imágenes como en instancias en ejecución, y reenviar los hallazgos de alta severidad a AWS Security Hub y a un bus de eventos personalizado de EventBridge.
- Usar AWS Systems Manager Inventory para identificar las instancias afectadas y etiquetarlas por criticidad; crear una línea base de Patch Manager que incluya las correcciones requeridas para OpenSSL y apuntar a reglas para Windows/Linux.
- Crear una regla de EventBridge que active un documento de SSM Automation cuando los hallazgos de Inspector alcancen una severidad definida, pasando la lista de ID de instancia a un runbook de Automation que invoque a Patch Manager o Run Command para aplicar parches y reiniciar donde sea necesario.
- Para servicios con estado (stateful) o de alto riesgo, orquestar actualizaciones continuas (rolling updates) usando EC2 Image Builder para crear AMIs con los parches aplicados, actualizar los Auto Scaling Groups o los grupos de nodos de EKS con un despliegue controlado de tipo azul/verde o continuo, y verificar la salud del servicio con las comprobaciones de estado de Route 53/ALB.
- Después de la remediación, volver a ejecutar Amazon Inspector para validar que los hallazgos se han resuelto, actualizar los informes de SSM Compliance y enviar un resumen al equipo de seguridad a través de SNS; mantener el runbook de Automation en una biblioteca de Systems Manager Automation para una respuesta repetible a nivel de toda la flota.
Justificación: Este enfoque utiliza Amazon Inspector para el descubrimiento continuo, Systems Manager Patch Manager y Automation para la remediación controlada y automatizada, y reconstrucciones basadas en imágenes para una infraestructura inmutable, alineándose con las mejores prácticas de AWS para la detección, la respuesta automatizada y un radio de impacto mínimo.
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
El cumplimiento centralizado se habilita configurando la cuenta de administrador delegado en Systems Manager Explorer y activando la sincronización de datos de recursos (resource data sync) para agregar el estado de cumplimiento de parches de cada cuenta en un único bucket de S3, que luego puede ser consultado con Athena o visualizado en QuickSight.
Session Manager para una administración auditable
El acceso tradicional basado en SSH tiene tres debilidades estructurales: el material de claves de larga duración reside en los portátiles de los operadores, el puerto 22 debe ser accesible (aunque solo sea a través de un bastión), y la actividad del shell no se registra de forma centralizada sin herramientas adicionales. Session Manager elimina las tres.
Session Manager tuneliza un shell interactivo a través de la conexión HTTPS saliente del SSM Agent hacia los endpoints de SSM. No hay ningún puerto de entrada, ningún par de claves SSH y ningún host bastión. El acceso se autoriza mediante políticas de IAM (ssm:StartSession acotado por etiqueta de instancia o ARN), y cada sesión puede registrarse en CloudWatch Logs o S3, opcionalmente con cifrado de KMS. En Linux, las sesiones se ejecutan como ssm-user por defecto; el comportamiento de sudo se controla mediante la configuración de sudoers de la instancia, no por IAM.
El patrón de fortalecimiento (hardening) correcto para nuevas flotas es: lanzar instancias sin un par de claves EC2, adjuntar un perfil de instancia con AmazonSSMManagedInstanceCore, ubicar las instancias en subredes privadas con VPC endpoints para ssm, ssmmessages y ec2messages, y forzar el registro de sesiones a nivel de las preferencias de Session Manager. Continuar distribuyendo claves SSH junto con Session Manager es la trampa: preserva la misma superficie de ataque que Session Manager fue adoptado para eliminar, y deja un canal de acceso sin registrar. Elimine el aprovisionamiento de authorized_keys de su proceso de creación de AMIs.
Telemetría de host con el agente de CloudWatch
El agente unificado de CloudWatch recopila métricas a nivel de sistema operativo (memoria, disco, CPU por proceso) y archivos de registro que el hipervisor de EC2 no puede ver. Se configura mediante un archivo JSON que normalmente se almacena en Parameter Store y luego se aplica con
undefined
.
El fallo operativo más común con el agente es la falta de permisos de IAM en el perfil de instancia. El agente necesita, como mínimo:
logs:CreateLogGroup (a menos que el grupo se haya creado previamente)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (para métricas personalizadas)
ssm:GetParameter (para obtener la configuración desde Parameter Store)
La política administrada CloudWatchAgentServerPolicy agrupa estos permisos. Cuando faltan los permisos, el agente se inicia correctamente y parece estar en buen estado en systemctl status, pero los registros nunca llegan a CloudWatch; los fallos solo son visibles en /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Cualquier diseño de seguridad de host que dependa de registros centralizados debe validar la entrega, no solo el estado del agente.
Uniendo las piezas
El ciclo defensivo es el siguiente: Inspector descubre CVE en hosts e imágenes de contenedor, los hallazgos fluyen hacia Security Hub para su agregación, Patch Manager remedia a través de ventanas de mantenimiento programadas o con Patch Now para emergencias, Session Manager proporciona la única ruta de acceso administrativo, y el agente de CloudWatch transmite tanto la evidencia de los parches como los registros de tiempo de ejecución a una cuenta centralizada. Cada control presupone a los demás: Inspector sin Patch Manager produce informes sobre los que nadie actúa; Patch Manager sin registro centralizado no produce ninguna pista de auditoría; Session Manager sin los permisos de IAM adecuados deja un acceso excesivo o insuficiente; y el agente de CloudWatch sin los permisos de registro correctos produce la ilusión de visibilidad.
← Gobernanza · Todos los dominios · Seguridad de Contenedores y Serverless →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →