Cómo AWS Protege tu Red: Entendiendo las Capas de Seguridad en VPC

La Fortaleza Digital: Bienvenido a tu VPC

Tu Virtual Private Cloud (VPC) es como un estadio de fútbol de máxima seguridad. Nada entra ni sale sin pasar por los controles apropiados en las puertas designadas. Pero aquí viene la parte interesante: el perímetro es solo una porción de la seguridad que necesitas considerar como parte de tu estrategia de IT.

AWS ofrece un arsenal completo de herramientas que cubren cada capa de seguridad: firewalls, prevención de ataques DDoS, encriptación y mucho más. Hablaremos de esas maravillas más adelante en la sección de seguridad. Hoy vamos a enfocarnos en algunos aspectos del endurecimiento de red, específicamente en lo que ocurre dentro de la VPC.

Subnets: Dividiendo el Campo de Juego

Una de las principales razones para usar subnets en una VPC es controlar el acceso a los gateways. Las subnets públicas tienen acceso al internet gateway; las privadas no. Pero las subnets también pueden controlar los permisos de tráfico de una manera fascinante.

Los paquetes son mensajes provenientes de internet, y cada paquete que cruza los límites de una subnet es verificado contra algo llamado Network Access Control List, o Network ACL para los amigos. Esta verificación determina si el paquete tiene permisos para salir o entrar a la subnet, basándose en quién lo envió y cómo está intentando comunicarse.

Network ACLs: Los Árbitros del Partido

Piensa en los Network ACLs como los árbitros en un partido de fútbol. Si estás en la lista de jugadores aprobados para entrar al campo, pasas sin problema. Si no estás en la lista o si explícitamente apareces en la lista de "prohibida la entrada" (quizás por una tarjeta roja en partidos anteriores), te quedas afuera. Así de simple, así de brutal.

Los Network ACLs revisan el tráfico que entra y sale de una subnet. La lista se verifica cuando entras y cuando sales. Y aquí está el detalle que muchos pasan por alto: solo porque te dejaron entrar no significa que automáticamente te dejarán salir con la respuesta. Solo el tráfico explícitamente aprobado puede seguir su camino.

Esto suena como una seguridad fantástica, y lo es, pero no resuelve todos los problemas de control de red. Un Network ACL solo evalúa un paquete si cruza un límite de subnet, de entrada o salida. No evalúa si un paquete puede alcanzar una instancia EC2 específica o no.

El Problema de la Zona Mixta

A veces tendrás múltiples instancias EC2 en la misma subnet, pero pueden tener reglas diferentes sobre quién puede enviarles mensajes y a qué puerto esos mensajes están permitidos. Es como tener varios jugadores en el mismo sector del campo, pero cada uno tiene instrucciones defensivas diferentes. Necesitas seguridad a nivel de instancia también.

Security Groups: Los Porteros Personales

Para resolver las cuestiones de acceso a nivel de instancia, introducimos los Security Groups. Cada instancia EC2, cuando se lanza, automáticamente viene con un Security Group. Y por defecto, el Security Group no permite ningún tráfico hacia la instancia. Todos los puertos están bloqueados. Todas las direcciones IP que envían paquetes están bloqueadas.

Eso es muy seguro, pero quizás no muy útil si quieres que una instancia realmente acepte tráfico del exterior. Porque, seamos honestos, una instancia que no acepta tráfico es tan útil como un portero que rechaza todos los balones, incluso los de su propio equipo.

Obviamente, puedes modificar el Security Group para aceptar tipos específicos de tráfico. En el caso de un sitio web, quieres que el tráfico web como HTTPS sea aceptado, pero no otros tipos de tráfico.

La Gran Diferencia: Stateful vs Stateless

Si los Network ACLs son los árbitros del partido, los Security Groups son como los porteros personales de cada jugador. El portero verificará una lista para asegurar que alguien puede acercarse al jugador, pero no se molestará en verificar la lista cuando ese alguien se vaya. Con los Security Groups, permites tráfico específico de entrada y, por defecto, todo el tráfico de salida está permitido.

Acabamos de describir dos cosas diferentes: dejar entrar los paquetes buenos y mantener afuera los paquetes malos. La diferencia clave entre un Security Group y un Network ACL es que el Security Group es stateful. Es decir, tiene algún tipo de memoria cuando se trata de permitir entradas o salidas. El Network ACL es stateless, no recuerda nada y verifica cada paquete que cruza su frontera sin importar las circunstancias.

Es como si el árbitro stateless revisara el carnet de cada jugador cada vez que toca el balón, incluso si ya lo revisó hace 30 segundos. Obsesivo, pero efectivo.

El Viaje Completo: De Portería a Portería

Vamos a ilustrar el viaje completo de un paquete mientras va de una instancia a otra en una subnet diferente. Esta gestión de tráfico no se preocupa por el contenido del paquete en sí. De hecho, ni siquiera abre el sobre. No puede. Todo lo que puede hacer es verificar si el remitente está en la lista aprobada.

Empecemos con un par de instancias. Queremos enviar un paquete desde la Instancia A hasta la Instancia B en una subnet diferente (misma VPC, diferentes subnets). Parecido a un pase largo de una mitad del campo a la otra.

Salida desde la Instancia A

1. Security Group de Instancia A: La Instancia A envía el paquete. Lo primero que sucede es que el paquete llega al límite del Security Group de la Instancia A. Por defecto, todo el tráfico saliente está permitido desde un Security Group. Puedes pasar directamente junto al portero y salir. El paquete superó el Security Group de Instancia A.
2. Network ACL de Subnet 1 (salida): Ahora debe salir del límite de la subnet. En el límite, el paquete debe pasar por el control de pasaportes: el Network ACL. Al Network ACL no le importa lo que el Security Group permitió. Tiene su propia lista de quién puede pasar y quién no. Si la dirección de tráfico está permitida, puedes continuar tu viaje.

Entrada a la Instancia B

3. Network ACL de Subnet 2 (entrada): El paquete dejó completamente la Instancia A y la Subnet 1, así que ahora debe pasar por la Subnet 2. Es verificado por el Network ACL de entrada de Subnet 2. Si todo está en orden, continúa.
4. Security Group de Instancia B: Finalmente, debe pasar por el Security Group de la Instancia B. Una vez superado, la Instancia B puede recibir y procesar la solicitud. ¡Gooool! Bueno, no exactamente, pero el paquete llegó a destino.

El Camino de Regreso: Donde la Magia Ocurre

Después de que la transacción está completa, es hora de volver a casa. Este es el patrón de tráfico de retorno y es el más interesante porque aquí es donde la naturaleza stateful versus stateless de los diferentes motores entra en juego.

El paquete todavía tiene que ser evaluado en cada punto de control, pero ahora las cosas funcionan diferente:

Regreso desde la Instancia B

1. Security Group de Instancia B: Los Security Groups, por defecto, permiten todo el tráfico de retorno. No tienen que verificar una lista para ver si están permitidos salir. Automáticamente permiten que el tráfico de retorno pase, sin importar qué. Es como un portero que recuerda: "Ah sí, este tipo entró hace un momento, déjalo salir sin problema".
2. Network ACL de Subnet 2 (salida): En el límite de la subnet, estos Network ACLs no recuerdan el estado. Cada entrada y salida se verifica con la lista apropiada. Los controles stateless significan que siempre verifican su lista. Es una lista diferente que la de entrada, porque los Network ACLs tienen reglas tanto para tráfico entrante como saliente y pueden ser diferentes.
3. Network ACL de Subnet 1 (entrada): En el lado de la Instancia A, nuestro paquete es inspeccionado cuando el Network ACL stateless de Subnet 1 verifica la lista cada vez. Porque aparentemente confiar no es una opción en el mundo stateless.
4. Security Group de Instancia A: La última verificación es el Security Group de Instancia A. Nuevamente, porque este es tráfico de retorno, no verifica la lista en el camino de regreso. El paquete está permitido y continúa para completar el flujo en Instancia A.

¿Todo Este Esfuerzo Vale la Pena?

Puede parecer que gastamos mucho esfuerzo solo para llevar un paquete de una instancia a otra y de regreso. Si haz visto alguna vez un partido donde revisan cada jugada con el VAR, es exactamente igual: puede parecer tedioso, pero garantiza que todo se haga según las reglas.

Podrías estar preocupado por toda la sobrecarga de red que esto podría generar. La realidad es que todos estos intercambios ocurren instantáneamente como parte de cómo funciona realmente la red de AWS. Por eso es importante aprender todo esto.

Diseñando Tu Estrategia Defensiva

Quieres asegurar que tu estrategia de IT y diseño incluyan la definición de las reglas para tus Security Groups y Network ACLs. De esa manera, tu diseño de red cumplirá con tus necesidades específicas mientras también garantiza buena seguridad de red.

Después de todo, la seguridad es una consideración crítica en todas las redes para arquitecturas modernas. No es algo que puedas configurar una vez y olvidar. Es como mantener una defensa sólida durante todo el partido: requiere atención constante, ajustes estratégicos y, sobre todo, entender perfectamente cómo funciona cada componente de tu sistema de seguridad en capas.

Porque al final del día, un gol en contra en el mundo de la ciberseguridad puede costarte mucho más que tres puntos en la tabla de posiciones.