Abrir la puerta con cuidado

Qué ha pasado

Una subred pública es una fila en su tabla

Para que algo entre o salga de la VPC hace falta una puerta: el gateway de internet. Se pega a la VPC y, por sí solo, no hace nada; lo que convierte una subred en pública es una fila en su tabla de rutas: 0.0.0.0/0 → gateway. Esa fila contiene cualquier dirección, así que gana siempre que no haya otra más concreta: es la ruta por defecto. Además, cada pieza que quiera hablar con internet necesita una IP pública, porque el gateway traduce una a otra: la privada dentro, la pública fuera.

A la izquierda, la subred es pública y todas las piezas tienen IP pública. Ana llega a la API directamente.probar en el laboratorio A la derecha solo tiene IP pública el balanceador, que recibe a Ana y le pasa la petición a la API por dentro. El grupo de seguridad de la API solo deja entrar al balanceador: aunque alguien supiera su IP privada, no le serviría.

Saldo no disponible

En los dos paneles, Ana llega a la API y la app le dice «saldo no disponible». La API pide el saldo a Cuentas, en 10.0.12.20, y busca en su tabla de rutas. No hay ninguna fila para el CPD, pero sí la ruta por defecto, que lo contiene todo. Así que el paquete sale a internet, por el gateway a la izquierda o por el NAT a la derecha, y allí una IP privada no lleva a ninguna parte. La ruta por defecto no significa «a donde haga falta»: significa «a internet». Conectar con el CPD es el episodio 3.

Entrar no es lo mismo que salir

Notificaciones no necesita que nadie la llame: solo necesita salir. A la izquierda sale por el gateway con su propia IP pública. A la derecha, la ruta por defecto de la subred privada apunta al NAT, que está en la pública: cambia la IP de Notificaciones por la suya, apunta la conexión y, cuando vuelve la respuesta, sabe a quién dársela.probar en el laboratorio

La diferencia se ve cuando alguien intenta entrar.probar en el laboratorio A la izquierda, el paquete llega hasta Notificaciones, porque tiene IP pública, y lo para su grupo de seguridad, que no deja entrar nada. Está protegida por una regla: basta con que alguien añada otra por error. A la derecha, Notificaciones no tiene IP pública y el NAT no acepta conexiones que nadie de dentro haya abierto. No hay regla que olvidar, porque no hay camino. El gateway deja entrar y salir; el NAT solo deja salir.

Con estado y sin estado

La respuesta del proveedor de avisos vuelve a Notificaciones sin que nadie haya abierto ninguna regla para ella. Es porque el grupo de seguridad tiene estado: recuerda que la conexión la abrió Notificaciones y deja pasar su respuesta. En la ficha lo verás como «conexión conocida».

La nube tiene otro firewall, la ACL de subred, que filtra todo lo que entra y sale de una subred y no tiene estado. Ponla en la subred de Notificaciones y traza el aviso.probar en el laboratorio El aviso sale (la ACL deja salir todo), pero la respuesta llega desde una IP de internet a un puerto alto, el efímero que eligió Notificaciones al abrir la conexión, y la ACL la mira como si fuera un paquete nuevo. Ninguna regla lo permite, así que se descarta. Para que funcione hay que abrir la vuelta: de 1024 a 65535, desde cualquier sitio.probar en el laboratorio Es decir, dejar entrar a casi todos los puertos para que entren las respuestas. Por eso la ACL se usa como red gruesa, y el filtro fino se deja al grupo de seguridad.

Cuándo hace daño: la base de datos en la subred pública

El panel de la izquierda tiene una pieza que nadie quería publicar: la base de datos de la API. Está en la subred pública, así que tiene IP pública, y su grupo de seguridad deja entrar al puerto 5432 desde cualquier sitio porque un día alguien quiso conectarse desde casa.probar en el laboratorio Cualquiera en internet llega a ella; solo la separa del mundo su contraseña. A la derecha, la base de datos no tiene IP pública: desde internet no hay ni por dónde intentarlo.

«¿Quién llega a Cuentas?» sigue a cero en los dos paneles, porque Cuentas aún no está conectada. Pero la fila Se ve desde internet cuenta otra cosa: a la izquierda, la API y su base de datos; a la derecha, solo el balanceador. Cada pieza que se ve es una pieza más que alguien puede probar.

Cuándo hace daño: el NAT se cobra

La derecha es más segura, y también más cara. El NAT es un servicio gestionado: se paga por hora y por cada GB que pasa por él, en los dos sentidos. El aviso de Notificaciones cuesta 0,09 €/GB a la izquierda (la salida a internet) y 0,18 €/GB a la derecha: la salida más el NAT a la ida y a la vuelta. Es la primera línea de coste de la serie que se puede diseñar, y no será la última. Para un banco la cuenta sale sola; para lo que manda muchos datos a internet, conviene hacerla.

Criterio

La pregunta para cada pieza no es si necesita internet, sino en qué sentido.

1. ¿Tiene que recibir conexiones desde internet?Ana llega a la app; nadie llama a Notificaciones.
   subred pública, y mejor un balanceador delante que la pieza misma
2. no ↓
3. ¿Tiene que salir a internet?Avisos, pagos a terceros, actualizaciones.
   subred privada con salida por NAT
4. no ↓
5. Subred privada sin salida. Y filtra con grupos de seguridad; la ACL, para separar subredes a grandes rasgos.

El panel de la izquierda no es un hombre de paja: para un prototipo, una tarea que solo descarga datos o algo que manda muchos GB a internet, una IP pública con un grupo de seguridad estricto es razonable y más barata. Lo que no es razonable es que la base de datos acabe en la misma subred por comodidad.

En el mundo real

Las bases de datos expuestas son una de las causas más comunes de filtraciones. En 2017, decenas de miles de bases de datos MongoDB abiertas a internet se vaciaron en pocos días y se sustituyeron por una nota pidiendo un rescate; después vinieron Elasticsearch, Redis y compañía. Hay buscadores, como Shodan, que recorren internet sin parar apuntando qué puertos responden en cada IP: una base de datos con IP pública y el puerto abierto aparece en ellos en cuestión de horas.

El NAT gestionado de AWS cuesta, en la región más barata, unos 0,045 $ por hora y otros 0,045 $ por GB procesado, más la salida a internet (unos 0,09 $ por GB). No es raro encontrar facturas donde el NAT cuesta más que las máquinas que hay detrás, casi siempre por tráfico que no necesitaba pasar por él: el episodio 4 enseña el caso más típico.

Sobre firewalls: AWS tiene las dos piezas, grupos de seguridad con estado y ACL de subred sin estado, y recomienda abrir en las ACL los puertos 1024–65535 para las respuestas. Azure y Google Cloud solo tienen firewalls con estado (en Azure, los grupos de seguridad de red se pueden asociar a una subred entera, pero siguen teniendo estado). Y cada proveedor abre la puerta a internet a su manera: en AWS hay que crear el gateway y la ruta; en Google Cloud la ruta por defecto viene puesta; Azure está retirando el acceso de salida implícito que daba a las máquinas nuevas, para que salir a internet sea siempre una decisión.

Equivalencias

Siguiente episodio

Ana llega a la API y la API no llega a Cuentas. Hace falta un camino privado entre la nube y el CPD: un túnel por internet o una línea propia. Y ahí aparecerá el rango que se eligió a ojo en el episodio 1.

← Todos los episodios · Notificaciones en el mapa de BCPS Bank