Controles de egreso en AWS: cómo prevenir la exfiltración de datos

El tráfico saliente en entornos AWS suele quedar abierto por defecto para no romper dependencias de aplicación, y ese descuido se convierte en un vector de exfiltración silenciosa. AWS acaba de publicar una guía técnica detallada —disponible en el [AWS Security Blog](https://aws.amazon.com/blogs/security/prevent-data-exfiltration-aws-egress-controls-for-cloud-workloads/ rel='nofollow noopener')— que describe cómo implementar controles de egreso en capas usando AWS Network Firewall, Route 53 DNS Firewall, VPC endpoint policies, SCPs y GuardDuty. El modelo cubre tanto workloads tradicionales como agentes de IA autónomos desplegados sobre Amazon Bedrock, que según el OWASP Top 10 para aplicaciones agénticas son objetivos de alto valor para ataques de tipo Agent Goal Hijack (ASI01) y Unexpected Code Execution (ASI05). La arquitectura propuesta demuestra que un mismo pipeline de inspección centralizado puede proteger un EC2 comprometido y un agente manipulado mediante prompt injection con exactamente los mismos controles de red.

Por qué el tráfico saliente es el punto ciego más peligroso de tu entorno AWS

Los equipos de seguridad dedican la mayor parte de su presupuesto y atención a los controles de entrada: WAFs, grupos de seguridad, políticas de acceso. El tráfico saliente, en cambio, se deja abierto para que las aplicaciones funcionen sin fricciones. El resultado es predecible: cuando un atacante consigue acceso a un workload, lo primero que hace es establecer un canal de command-and-control hacia el exterior y comenzar a transferir datos.

El caso de CVE-2025-55182 (React2Shell), divulgado en diciembre de 2025, ilustra la velocidad del problema. Grupos organizados comenzaron a explotar la vulnerabilidad en React Server Components para lograr ejecución remota de código en cuestión de horas tras la divulgación pública. Sin controles de egreso, ese tráfico de exfiltración fluye libremente a través de un NAT gateway y puede pasar desapercibido durante semanas, hasta que una auditoría de cumplimiento o una notificación externa fuerza el descubrimiento.

Los agentes de IA autónomos añaden una dimensión nueva al problema. A diferencia de una aplicación tradicional con un conjunto acotado de dependencias externas, un agente puede invocar APIs de terceros, ejecutar código generado dinámicamente y acceder a intérpretes de código como parte de su operación normal. Eso lo convierte en un vector de exfiltración difícil de distinguir del tráfico legítimo si no existe una política de allow-list granular.

El OWASP Top 10 para aplicaciones agénticas identifica dos amenazas directamente relacionadas con el egreso:

• ASI01 – Agent Goal Hijack: un actor no autorizado manipula los objetivos del agente para redirigirlo a exfiltrar datos de forma silenciosa.
• ASI05 – Unexpected Code Execution: el agente genera y ejecuta código que establece reverse shells o transfiere datos sensibles a endpoints externos.

Ambos escenarios comparten el mismo denominador común: tráfico saliente no autorizado. Y ambos pueden mitigarse con los mismos controles de red si la arquitectura está bien diseñada.

Herramientas como Wiz permiten detectar recursos expuestos públicamente y configuraciones de red permisivas antes de que un atacante las aproveche, complementando los controles nativos de AWS que se describen en este artículo.

Arquitectura hub-and-spoke: cómo funciona el modelo de inspección centralizada

La arquitectura propuesta por AWS sigue un patrón hub-and-spoke para entornos multi-cuenta. Los workloads residen en VPCs spoke que se conectan a un AWS Transit Gateway, el cual actúa como hub central para enrutar el tráfico inter-VPC y el tráfico con destino a internet. El Transit Gateway aplica route tables específicas que garantizan la segmentación de red.

El flujo de tráfico saliente funciona así:

1. Un workload en una VPC spoke genera tráfico hacia internet.
2. El Transit Gateway recibe ese tráfico y lo redirige al endpoint de AWS Network Firewall antes de que llegue al NAT gateway.
3. Network Firewall inspecciona el tráfico en capas 3-7 usando reglas compatibles con Suricata, filtrando por IP, puerto, protocolo y contenido de paquetes.
4. Solo el tráfico que supera la inspección y coincide con el allow-list de dominios aprobados llega a internet.

Las VPCs spoke utilizan VPC endpoints para acceder a servicios AWS sin que el tráfico salga a internet, y cada endpoint lleva una VPC endpoint policy que restringe qué principales pueden usarlo y a qué recursos pueden acceder. Esto forma la base del modelo de data perimeter de AWS.

El Route 53 DNS Firewall se despliega en todas las VPCs para filtrar consultas DNS antes de que se establezca cualquier conexión de red. Usa listas de dominios gestionadas y personalizadas para bloquear la resolución de dominios no autorizados. Un matiz importante que señala la guía: el DNS Firewall solo actúa sobre consultas que pasan por el Route 53 VPC Resolver. Las consultas enviadas directamente a otros resolvers DNS eluden este control, pero pueden filtrarse con Network Firewall a nivel de paquete.

A nivel organizacional, las Service Control Policies (SCPs) y las Resource Control Policies (RCPs) en AWS Organizations añaden una capa de control que ninguna cuenta individual puede sobrescribir. IAM Access Analyzer se despliega a nivel de organización para detectar de forma continua recursos accesibles públicamente o compartidos con entidades externas.

Este modelo escala horizontalmente: añadir una nueva cuenta o VPC spoke no requiere modificar la infraestructura de inspección central, solo conectar la nueva VPC al Transit Gateway y aplicar las route tables correspondientes.

Capa de detección y respuesta: GuardDuty, Security Hub y remediación automática

Los controles preventivos bloquean el tráfico conocido como malicioso, pero la detección continua es necesaria para identificar amenazas nuevas o comportamientos anómalos que aún no están en las listas de bloqueo. La arquitectura integra tres servicios de detección principales:

• Amazon GuardDuty: detecta comportamientos anómalos en el tráfico de red, llamadas a la API de AWS y actividad de DNS. Genera findings cuando detecta comunicaciones con IPs o dominios asociados a infraestructura de C2, exfiltración de datos a buckets S3 externos o actividad de reconocimiento.
• AWS Security Hub: agrega findings de GuardDuty, IAM Access Analyzer y otros servicios en una vista centralizada, aplicando estándares de seguridad como CIS AWS Foundations Benchmark.
• IAM Access Analyzer: monitoriza de forma continua las políticas de recursos para detectar accesos externos no intencionados.

La integración entre detección y respuesta se articula a través de Amazon EventBridge, que enruta los findings hacia funciones AWS Lambda para remediación automatizada. El flujo es el siguiente:

GuardDuty Finding → EventBridge Rule → Lambda Function
                                          ├── Actualiza Network Firewall deny rules
                                          ├── Añade dominio a DNS Firewall block list
                                          └── Notifica vía Amazon SNS

Este bucle de retroalimentación es clave: cuando GuardDuty detecta tráfico hacia un dominio de C2 no conocido previamente, Lambda puede añadir ese dominio automáticamente a la block list del DNS Firewall y crear una regla de denegación en Network Firewall, reduciendo la ventana de exposición sin intervención manual.

La observabilidad centralizada se logra mediante Amazon CloudWatch Logs y dashboards de CloudWatch, donde se recopilan los flow logs y alert logs de Network Firewall. Estos logs son esenciales tanto para la investigación de incidentes como para la generación de evidencias en auditorías de cumplimiento.

Para equipos que ya operan con herramientas SIEM propias, Wazuh puede integrarse con los logs de CloudWatch para correlacionar eventos de egreso con otras señales del entorno, ampliando la cobertura de detección más allá de los servicios nativos de AWS.

Agentes de IA en Bedrock: por qué necesitan los mismos controles de egreso que cualquier EC2

Un agente de IA desplegado sobre Amazon Bedrock que reside en una VPC spoke no tiene ningún tratamiento especial en la arquitectura de red. Su tráfico saliente sigue exactamente el mismo camino que el de una instancia EC2 o un contenedor: Transit Gateway → Network Firewall → internet. No existe un carril separado ni una excepción implícita por ser un agente.

Esto es deliberado y correcto desde el punto de vista de seguridad. Sin embargo, el diseño del allow-list de dominios para agentes requiere más cuidado que para aplicaciones tradicionales, porque los agentes legítimamente necesitan invocar APIs externas, herramientas de terceros e intérpretes de código como parte de su operación normal. Abrir categorías amplias de dominios para satisfacer esas necesidades amplía innecesariamente la superficie de ataque.

La recomendación de la guía es clara: scope allowing domains tightly a los endpoints específicos que el agente necesita, no a categorías genéricas. Si un agente necesita llamar a una API de enriquecimiento de datos concreta, el allow-list debe incluir ese dominio exacto, no todo el TLD o el proveedor de hosting.

A nivel de aplicación, Amazon Bedrock Guardrails añade una capa de defensa previa a la red: filtra contenido dañino y detecta ataques de prompt injection antes de que el agente procese la instrucción maliciosa. Esto es especialmente relevante para mitigar ASI01 (Agent Goal Hijack), donde el vector de ataque es la manipulación de las instrucciones que recibe el agente, no una vulnerabilidad de red.

La combinación de controles es la siguiente:

Herramientas especializadas en seguridad de IA como Lakera Guard pueden complementar Bedrock Guardrails para detección de prompt injection más granular, especialmente en pipelines de agentes con múltiples pasos donde el contexto de la instrucción maliciosa puede distribuirse a lo largo de varias llamadas.

Cómo implementar los controles preventivos: pasos concretos y consideraciones operativas

La guía de AWS distingue explícitamente entre controles preventivos y controles de detección, y recomienda reservar los preventivos —los que interrumpen activamente el tráfico— para actividad confirmada o con alta probabilidad de ser maliciosa. Aplicar bloqueos agresivos sin suficiente contexto puede romper dependencias legítimas de aplicación.

Network Firewall: configuración de allow-list de dominios

El punto de partida es definir un allow-list de dominios aprobados en lugar de una deny-list reactiva. Las reglas de Network Firewall compatibles con Suricata permiten inspección de contenido de paquetes, lo que habilita controles más granulares que el simple filtrado por IP o puerto. Un ejemplo de regla Suricata para bloquear tráfico TLS hacia dominios no listados:

alert tls $HOME_NET any -> $EXTERNAL_NET any (
  msg:"TLS to unlisted domain";
  tls.sni; content:!"allowed-domain.com";
  sid:1000001; rev:1;
)

Las reglas deben revisarse periódicamente a medida que las aplicaciones añaden nuevas dependencias externas. Un proceso de change management que incluya la actualización del allow-list como requisito previo al despliegue reduce la fricción operativa.

DNS Firewall: listas gestionadas y personalizadas

Route 53 DNS Firewall ofrece listas de dominios gestionadas por AWS que se actualizan automáticamente con dominios asociados a malware, botnets y C2. Complementar estas listas con dominios personalizados específicos del sector o del entorno añade cobertura adicional. Feeds de inteligencia de amenazas como los que gestiona MISP pueden automatizar la actualización de estas listas personalizadas.

SCPs y RCPs: guardrails organizacionales

Las SCPs se aplican a nivel de unidad organizacional (OU) o cuenta y restringen las acciones de IAM que pueden realizarse, independientemente de los permisos que tenga el principal. Una SCP que deniegue la creación de Internet Gateways en cuentas de producción, por ejemplo, previene que un workload comprometido establezca un nuevo camino de salida a internet eludiendo el Transit Gateway.

Las RCPs, más recientes, actúan sobre los recursos directamente y permiten definir condiciones que deben cumplirse para que cualquier principal —incluso de otras cuentas— pueda acceder al recurso.

Consideraciones operativas

Antes de activar bloqueos en producción, la guía recomienda operar Network Firewall en modo de solo alertas durante un período de observación para mapear el tráfico saliente legítimo. Este inventario de dependencias externas es la base del allow-list inicial. Sin este paso, los bloqueos prematuros generan incidentes operativos que erosionan la confianza en los controles de seguridad.

La integración de los flow logs de Network Firewall con un SIEM como Wazuh facilita el análisis retrospectivo y la detección de patrones de exfiltración lentos (low-and-slow) que no generan alertas individuales pero sí son visibles en la agregación temporal.

Preguntas frecuentes

¿Qué diferencia hay entre AWS Network Firewall y los Security Groups para controlar el egreso?

Los Security Groups operan a nivel de instancia y solo filtran por IP, puerto y protocolo (capas 3-4). AWS Network Firewall opera de forma centralizada en capas 3-7, soporta inspección de contenido de paquetes con reglas Suricata, y puede filtrar por dominio (SNI en TLS) además de por IP. Para controlar egreso a nivel de dominio o detectar tráfico de C2 que usa IPs dinámicas, Network Firewall es imprescindible.

¿El Route 53 DNS Firewall bloquea todas las consultas DNS maliciosas en una VPC?

No todas. El DNS Firewall de Route 53 solo actúa sobre consultas que pasan por el Route 53 VPC Resolver (el resolver interno de la VPC). Si un workload comprometido configura un resolver DNS alternativo (por ejemplo, 8.8.8.8 directamente), esas consultas eluden el DNS Firewall. Para cubrir ese vector, es necesario combinar el DNS Firewall con reglas en AWS Network Firewall que bloqueen el tráfico UDP/TCP al puerto 53 hacia destinos externos no autorizados.

¿Cómo se aplican estos controles de egreso a agentes de IA en Amazon Bedrock?

Un agente de Bedrock que reside en una VPC spoke sigue el mismo camino de red que cualquier EC2 o contenedor: Transit Gateway → Network Firewall → internet. No existe ninguna excepción de red por ser un agente. La diferencia operativa está en el diseño del allow-list: los agentes necesitan invocar APIs externas legítimamente, por lo que el allow-list debe ser más granular (dominios específicos, no categorías amplias). A nivel de aplicación, Bedrock Guardrails añade detección de prompt injection antes de que el agente procese instrucciones maliciosas.

¿Qué es el modelo de data perimeter en AWS y cómo se relaciona con el egreso?

El data perimeter de AWS es un conjunto de controles que garantiza que solo identidades confiables acceden a recursos confiables desde redes confiables. En el contexto del egreso, las VPC endpoint policies restringen qué principals pueden usar los endpoints para acceder a servicios AWS y a qué recursos específicos pueden acceder, evitando que datos de una cuenta se transfieran a recursos AWS de otra cuenta no autorizada. Las SCPs y RCPs a nivel de organización añaden una capa que ninguna cuenta individual puede sobrescribir.

¿Cómo se automatiza la respuesta cuando GuardDuty detecta tráfico de exfiltración?

El flujo es: GuardDuty genera un finding → EventBridge lo captura con una regla específica → Lambda ejecuta la remediación. La función Lambda puede actualizar automáticamente las deny rules de Network Firewall con la IP o dominio detectado, añadir el dominio a la block list del DNS Firewall, y enviar una notificación vía SNS. Este bucle cierra la ventana de exposición sin intervención manual, aunque la guía recomienda validar los findings antes de activar bloqueos automáticos en producción para evitar falsos positivos que interrumpan servicios legítimos.

Artículos relacionados