Grupos de Seguridad vs. ACL de Red: Eligiendo tu Cortafuegos de AWS VPC
Navega por las complejidades de la seguridad de AWS VPC dominando las diferencias entre los Grupos de Seguridad (SGs) y las ACL de Red (NACLs). Esta guía experta explica el alcance, la capacidad de estado y la evaluación de reglas de ambos controles. Aprende por qué los SGs son ideales para una protección de instancias detallada y con estado, mientras que las NACLs son esenciales para una segmentación de subred amplia y sin estado, y políticas de denegación explícitas. Implementa una estrategia de cortafuegos robusta y de múltiples capas para tu infraestructura en la nube.
Grupos de Seguridad vs. ACL de Red: Eligiendo tu Cortafuegos de AWS VPC
Al diseñar un entorno de Virtual Private Cloud (VPC) seguro en Amazon Web Services (AWS), los administradores confían en múltiples capas de control para gestionar el tráfico de red. Los dos componentes fundamentales para filtrar el tráfico a nivel de red son los Grupos de Seguridad (SGs) y las Listas de Control de Acceso a la Red (NACLs).
Se ven similares en la consola, pero fallan de maneras muy diferentes. Los grupos de seguridad suelen ser donde describes la intención de la aplicación. Las ACL de red son donde aplicas límites amplios de subred o denegaciones de emergencia.
El Rol de los Cortafuegos en AWS VPC
AWS proporciona seguridad de red en dos niveles principales dentro de una VPC:
- Nivel de Instancia (Grupos de Seguridad): Actúa como un cortafuegos para instancias EC2 específicas o recursos (como bases de datos RDS o Balanceadores de Carga Elásticos). Controla el tráfico hacia y desde la interfaz de red.
- Nivel de Subred (ACL de Red): Actúa como un cortafuegos sin estado para subredes enteras, controlando el flujo de tráfico que entra o sale del límite de la subred.
Análisis Profundo de los Grupos de Seguridad (SGs)
Los Grupos de Seguridad funcionan como el cortafuegos principal y detallado para recursos individuales. Son con estado y filtran por protocolo, puerto y origen o destino.
Características Clave de los Grupos de Seguridad
| Característica | Descripción | Implicaciones para el Uso |
|---|---|---|
| Alcance | Se aplica directamente a la Interfaz de Red Elástica (ENI) de una instancia. | Controla el flujo de tráfico hacia y desde la propia instancia. |
| Capacidad de Estado | Con estado. Si una solicitud entrante se permite explícitamente, el tráfico de retorno correspondiente (respuesta saliente) se permite automáticamente, independientemente de las reglas de salida. | Simplifica la configuración; solo necesitas definir la dirección del tráfico iniciador. |
| Tipo de Regla | Solo permitir. No son posibles las reglas de denegación explícitas. El tráfico que no coincide con una regla PERMITIR explícita se deniega implícitamente. |
Se centra en definir lo que está permitido. |
| Evaluación | Todas las reglas se evalúan antes de tomar una decisión. No están numeradas y no se procesa ninguna DENEGACIÓN implícita hasta que fallan todas las reglas PERMITIR. |
El orden no importa; todas las reglas se tratan por igual. |
Ejemplo de Configuración de Grupo de Seguridad
Para permitir el acceso SSH (puerto 22) a una instancia EC2, solo necesitas una regla de entrada. La regla de salida para la respuesta SSH se maneja automáticamente por la naturaleza con estado del SG.
| Tipo | Protocolo | Rango de Puertos | Origen | Descripción |
|---|---|---|---|---|
| Entrante | TCP | 22 | 0.0.0.0/0 (o IP de administración específica) | Permitir acceso SSH |
| Saliente | Todo | Todo | 0.0.0.0/0 | (Por defecto: Permite todo el tráfico, pero esto se puede restringir si es necesario) |
# Representación conceptual de un flujo con estado
Usuario (IP Origen) --> [Regla SG Entrante: PERMITIR 22] --> Instancia EC2
Instancia EC2 (Respuesta) --> [Seguimiento de Estado Implícito] --> Usuario (Respuesta recibida)
Consejo de Mejor Práctica: Siempre define las reglas del Grupo de Seguridad utilizando el principio de mínimo privilegio. Siempre que sea posible, restringe los rangos de IP de origen en lugar de permitir 0.0.0.0/0.
Análisis Profundo de las ACL de Red (NACLs)
Las ACL de Red proporcionan una segunda capa de defensa, actuando como un filtro sin estado en el límite de la subred. Son potentes para la segmentación de red y políticas de denegación amplias.
Características Clave de las ACL de Red
| Característica | Descripción | Implicaciones para el Uso |
|---|---|---|
| Alcance | Se aplica a una subred VPC completa. Una subred solo puede estar asociada con una NACL a la vez. | Controla todo el tráfico que entra o sale de la subred, afectando a todas las instancias dentro de ella. |
| Capacidad de Estado | Sin estado. Tanto las solicitudes entrantes como las respuestas salientes correspondientes deben permitirse explícitamente. | Requiere una configuración cuidadosa para el tráfico de retorno (puertos efímeros). |
| Tipo de Regla | Permitir y Denegar. Puedes definir explícitamente reglas para permitir o bloquear el tráfico. | Excelente para bloquear IPs maliciosas conocidas o denegar protocolos específicos en toda la red. |
| Evaluación | Las reglas están numeradas (1 a 32766) y se evalúan secuencialmente, comenzando desde el número más bajo. La primera regla que coincide se aplica inmediatamente. | El orden de las reglas es crítico. La regla de denegación implícita (la última regla procesada) deniega todo lo que no se ha permitido explícitamente. |
Manejo del Tráfico Sin Estado (Puertos Efímeros)
Debido a que las NACLs no tienen estado, debes considerar los puertos efímeros utilizados por los clientes que se conectan a tus servidores. Cuando un cliente inicia una conexión, utiliza un puerto de destino (ej., 80 para HTTP) y un puerto de origen de número alto (rango de puertos efímeros, típicamente 1024-65535).
Para permitir el tráfico web (HTTP) en una subred, necesitas dos reglas:
- Regla de Entrada: Permite el tráfico en el puerto de destino (ej., 80).
- Regla de Salida: Permite el tráfico de retorno al cliente utilizando los puertos de origen efímeros.
| Nº Regla | Tipo | Protocolo | Rango de Puertos | Origen/Destino | Acción de Regla |
|---|---|---|---|---|---|
| 100 | Entrante | TCP | 80 | 0.0.0.0/0 | PERMITIR (Tráfico web entrante) |
| 110 | Saliente | TCP | 1024-65535 | 0.0.0.0/0 | PERMITIR (Respuesta web saliente - Puertos efímeros) |
| * | Denegación Implícita | Todo | Todo | Todo | DENEGAR (Procesado al final) |
Advertencia: Si omites la regla de salida correspondiente para los puertos efímeros en una NACL, el tráfico llegará a la instancia (debido a la regla de entrada) pero la respuesta se descartará en el límite de la subred, lo que provocará tiempos de espera de conexión.
Resumen de Comparación: SG vs. NACL
La siguiente tabla resume las diferencias cruciales entre los dos tipos de cortafuegos:
| Característica | Grupo de Seguridad (SG) | ACL de Red (NACL) |
|---|---|---|
| Alcance de Aplicabilidad | Nivel de Instancia/ENI | Nivel de Subred |
| Estado | Con estado | Sin estado |
| Tipos de Regla | Solo Permitir | Permitir y Denegar |
| Evaluación de Reglas | Todas las reglas evaluadas, sin orden específico. | Reglas evaluadas secuencialmente por número (la más baja primero); la primera coincidencia gana. |
| Comportamiento por Defecto | Deniega todo el tráfico entrante, permite todo el tráfico saliente (a menos que se restrinja). | La NACL por defecto permite todo el tráfico entrante/saliente. Las NACLs personalizadas deniegan todo el tráfico entrante/saliente. |
| Efecto en el Tráfico | Solo aplica reglas si el tráfico está destinado a o se origina desde un recurso asociado. | Filtra el tráfico que pasa el límite de la subred, afectando a todos los recursos en la subred. |
Eligiendo el Cortafuegos Correcto: Escenarios y Mejores Prácticas
La seguridad exitosa de VPC se basa en usar SGs y NACLs juntos en un enfoque en capas (Defensa en Profundidad).
Cuándo Priorizar los Grupos de Seguridad
Los Grupos de Seguridad deben ser la herramienta principal para filtrar el acceso a la red debido a su naturaleza con estado y su capacidad para hacer referencia a otros SGs, simplificando la configuración de la aplicación.
- Control de Aplicación Detallado: Usa SGs para definir exactamente qué puertos y protocolos son necesarios para una aplicación específica (ej., solo permitir tráfico en el puerto 3306 desde el SG del servidor web al SG de la base de datos).
- Comunicación Interna: Gestiona la seguridad para el tráfico entre instancias dentro de la misma subred o a través de subredes (ej., asegurando que un balanceador de carga pueda hablar con sus grupos de destino).
- Facilidad de Gestión: Dado que tienen estado, los SGs requieren menos reglas y son menos propensos a errores que gestionar puertos efímeros con NACLs.
Cuándo Implementar ACL de Red
Las NACLs se utilizan mejor para establecer límites amplios de red y políticas de segmentación.
- Políticas de Denegación Amplias: Usa reglas
DENEGARexplícitas (Regla #100) para bloquear direcciones IP o rangos IP maliciosos específicos en una subred completa antes de que el tráfico llegue siquiera a las instancias. - Segmentación de Subredes: Aplica límites estrictos entre las capas de tu arquitectura (ej., asegurando que la NACL de la subred de base de datos deniegue explícitamente todo el tráfico entrante de internet, independientemente de cómo esté configurado un SG).
- Requisitos de Cumplimiento: Ciertos estándares de cumplimiento pueden exigir filtrado a nivel de subred, haciendo que las NACLs sean esenciales.
- Filtrado de Protocolos Sin Estado: Las NACLs son necesarias si necesitas filtrar protocolos sin estado que los SGs no pueden gestionar eficazmente por sí solos (aunque esto es raro para el tráfico TCP/UDP estándar).
Errores que causan interrupciones
La interrupción más común de NACL es olvidar el tráfico de retorno. Alguien permite TCP 443 entrante a una subred pública y deja las reglas de salida demasiado restrictivas. El balanceador de carga o la instancia reciben el SYN, pero la respuesta se descarta en el camino de salida. Desde el lado del cliente parece un tiempo de espera, y desde el lado de la instancia el servicio puede parecer perfectamente saludable.
Otro error es usar NACLs para políticas por aplicación. Si una subred contiene instancias web, worker y de administración, una NACL se aplica a todas ellas. Una regla añadida para una carga de trabajo puede exponer o romper inesperadamente otra carga de trabajo en la misma subred. Si necesitas un comportamiento de red diferente, usa diferentes grupos de seguridad y considera subredes separadas solo cuando haya un límite real que aplicar.
La numeración de reglas también merece cuidado. Deja espacios como 100, 110, 120 en lugar de 1, 2, 3 para que puedas insertar reglas de emergencia más tarde. Recuerda que la primera coincidencia gana. Una denegación en la regla 90 vencerá a una autorización en la regla 100, incluso si la autorización parece más específica para la persona que lee la consola rápidamente.
Para los grupos de seguridad, el error común son los rangos de origen amplios. 0.0.0.0/0 en el puerto 443 para un balanceador de carga público puede ser normal. El mismo origen en SSH, RDP, Redis, PostgreSQL o una API de administración interna suele ser un problema. Prefiere referencias a grupos de seguridad dentro de la VPC y CIDRs estrechos para el acceso del operador.
Cuando heredas una VPC existente, exporta las reglas y agrupa por intención: puntos de entrada públicos, tráfico de aplicación a aplicación, almacenes de datos, administración y denegaciones de emergencia. Las reglas sin un propietario claro o una razón son donde suele residir la exposición obsoleta.
El Enfoque de Defensa en Profundidad
En una VPC típica y bien diseñada, los flujos de tráfico deben pasar tanto por una NACL como por un Grupo de Seguridad. Si cualquiera de los controles de seguridad deniega el tráfico, el paquete se descarta.
- Flujo Entrante: El tráfico entra en la subred -> NACL verifica reglas -> El tráfico llega a la ENI de la instancia -> Grupo de Seguridad verifica reglas -> El tráfico llega a la aplicación.
- Flujo Saliente: La aplicación genera respuesta -> Grupo de Seguridad (Verificación de estado superada) -> El tráfico sale de la ENI de la instancia -> NACL verifica reglas -> El tráfico sale de la subred.
Al aprovechar la NACL para la segmentación gruesa y las reglas de denegación, y el SG para permisos precisos, con estado y a nivel de aplicación, maximizas la efectividad de la seguridad mientras mantienes la simplicidad de la configuración.
Un patrón de diseño práctico
Para la mayoría de las VPCs de aplicaciones, comienza con grupos de seguridad. Dale al balanceador de carga un grupo de seguridad orientado al público, dale a las instancias de la aplicación un grupo de seguridad que solo acepte tráfico del grupo de seguridad del balanceador de carga, y dale a la base de datos un grupo de seguridad que solo acepte tráfico del grupo de seguridad de la aplicación en el puerto de la base de datos. Ese modelo sigue el gráfico de dependencias de la aplicación y sobrevive a los cambios de IP.
Usa NACLs con más moderación. Un buen caso de uso de NACL es una denegación a nivel de subred para un CIDR malicioso conocido, un límite estricto alrededor de una subred de base de datos, o una regla de cumplimiento que debe aplicarse antes de que el tráfico llegue a cualquier ENI en la subred. Las NACLs se vuelven dolorosas cuando los equipos intentan reflejar cada regla de aplicación allí. Las reglas de puerto de retorno sin estado son fáciles de equivocar, y una denegación con un número bajo puede romper toda una subred.
Cuando una conexión agota el tiempo de espera, verifica ambas capas en la ruta del paquete. Para el tráfico entrante de internet a una instancia EC2 en una subred pública, la solicitud debe pasar la regla NACL entrante, la tabla de rutas y la regla del grupo de seguridad entrante. La respuesta debe pasar el seguimiento de estado del grupo de seguridad y la regla NACL saliente. Si los SGs parecen correctos pero los clientes aún se cuelgan, la regla de puerto efímero de la NACL suele ser la pieza faltante.
El modelo mental más limpio es este: los grupos de seguridad dicen qué recursos pueden hablar con qué otros recursos; las NACLs dicen lo que la subred nunca permitirá. Mantén esos trabajos separados y el diseño será más fácil de auditar.