Redes en la Nube Explicadas: VPC, Gateways, Virtualización y Seguridad

Serie Redes Informáticas para Principiantes — Parte 5. Esta publicación continúa la Parte 1: Guía Completa de Cómo Funcionan las Redes, la Parte 2: ¿Qué Es el Modelo OSI?, la Parte 3: Dispositivos de Red Explicados y la Parte 4: CDN, VPN, QoS y TTL. Cada publicación de la serie toma un tema y lo explica a fondo. Esta lleva todo lo que has aprendido hasta ahora a la nube.

Hasta ahora en esta serie, las redes han estado hechas de cosas físicas: cables, switches, routers y firewalls en un armario o en un centro de datos. Pero gran parte del internet de hoy funciona en la nube, en plataformas como Amazon Web Services (AWS), Microsoft Azure, Google Cloud y Oracle Cloud, donde nunca tocas el hardware.

La buena noticia es que las redes en la nube usan las mismas ideas que ya conoces. Sigue habiendo subredes, routers, firewalls, NAT y VPN. La diferencia es que son virtuales: los creas con unos cuantos clics o líneas de configuración, en lugar de comprar y cablear equipos. Esta publicación muestra cómo los conceptos físicos de la Parte 1 y la Parte 3 se traducen a la nube, y cómo diseñar una red en la nube que esté conectada y sea segura.

Fundamentos de la Computación en la Nube

La computación en la nube consiste en rentar recursos de cómputo (servidores, almacenamiento, bases de datos y redes) a un proveedor a través de internet, en lugar de tenerlos y operarlos tú mismo. Pagas por lo que usas, y puedes crear o eliminar recursos en minutos.

Algunas propiedades hacen que la nube sea especialmente útil:

• Escalabilidad: la capacidad de manejar más trabajo agregando recursos. Puedes escalar verticalmente (darle más CPU y memoria a un servidor) o escalar horizontalmente (agregar más servidores detrás de un balanceador de carga).
• Elasticidad: escalar automáticamente, en ambas direcciones, para ajustarse a la demanda en tiempo real. Una tienda en línea puede agregar servidores durante una venta de temporada y quitarlos cuando baja el tráfico, así que solo paga la capacidad extra mientras la necesita.
• Multitenencia (multi-tenancy): muchos clientes (inquilinos) comparten el mismo hardware físico en los centros de datos del proveedor, pero los recursos de cada uno se mantienen separados y aislados lógicamente de los demás. Compartir el hardware es lo que hace que la nube sea accesible; el aislamiento es lo que la hace segura.
• Autoservicio bajo demanda: tú mismo creas los recursos desde una consola web o con código, sin esperar a que alguien pida o instale hardware.

Modelos de Implementación: Nube Pública, Privada e Híbrida

Un modelo de implementación describe dónde funciona la nube y quién puede acceder a ella:

• Nube pública: la infraestructura del proveedor la comparten muchos clientes y cualquiera puede acceder a ella por internet. AWS, Microsoft Azure, Google Cloud y Oracle Cloud son nubes públicas. Obtienes una capacidad casi ilimitada sin tener nada de hardware.
• Nube privada: infraestructura de nube dedicada a una sola organización, normalmente un centro de datos virtualizado que ella misma opera (o que un proveedor opera solo para ella). Los empleados tienen el mismo autoservicio y la misma flexibilidad que en la nube pública, mientras la organización mantiene el control total del hardware, los datos y la seguridad, muchas veces por razones regulatorias o de cumplimiento.
• Nube híbrida: una combinación de nube pública y privada, conectadas para que las aplicaciones y los datos puedan moverse entre ellas. Una empresa podría guardar los registros sensibles de sus clientes en su nube privada mientras su sitio web público funciona en la nube pública, o usar la nube pública para tener capacidad extra cuando su propio centro de datos está saturado. Las VPN y las conexiones dedicadas que verás más adelante en esta publicación son las que unen ambas.

También escucharás hablar de las nubes comunitarias, compartidas por organizaciones con necesidades parecidas (como las dependencias de gobierno), y de la multinube (multicloud), que significa usar más de un proveedor de nube pública.

El modelo correcto depende de quién necesita acceder a la aplicación y de cuánto control y responsabilidad quieres conservar.

Modelos de Servicio: IaaS, PaaS y SaaS

Un modelo de servicio describe cuánto administra el proveedor por ti. Del mayor control al menor trabajo:

• IaaS (Infraestructura como Servicio), a veces llamada Hardware como Servicio (HaaS), proporciona recursos de cómputo en bruto: servidores virtuales, almacenamiento y redes. Tú eres responsable de instalar, administrar, actualizar y proteger todo lo que va encima: el sistema operativo, tu software y tus datos. Los servidores virtuales de AWS, Azure o Google Cloud, y las VPC de esta publicación, son IaaS. Esta publicación trata sobre todo de las redes en IaaS.
• PaaS (Plataforma como Servicio) es el punto intermedio. El proveedor proporciona y mantiene los servidores, los sistemas operativos y las herramientas y el motor para ejecutar tu código (como los entornos de ejecución de los lenguajes de programación y las bases de datos), y tú te concentras en construir y mantener tus propias aplicaciones. Algunos ejemplos son Heroku, Google App Engine, AWS Elastic Beanstalk y la plataforma de Salesforce para crear aplicaciones de negocio personalizadas.
• SaaS (Software como Servicio) es una aplicación terminada, lista para usar, disponible bajo demanda a través de internet. El proveedor administra todo (la aplicación, sus actualizaciones y toda la infraestructura que tiene debajo), y tú solo inicias sesión y la usas. Gmail, Microsoft 365 (antes Office 365) y Zoom son SaaS.

Una forma útil de recordarlos: con IaaS rentas los bloques de construcción; con PaaS rentas un taller con las herramientas listas; con SaaS rentas el producto terminado.

La Matriz de Responsabilidades en la Nube

El modelo de servicio que elijas decide quién administra qué. En un entorno local (on-premises), es decir, tu propio centro de datos, eres responsable de todo, desde los cables de red hasta la aplicación. En la nube, el trabajo se reparte entre tú y el proveedor, y esa división sube por las capas a medida que pasas de IaaS a SaaS:

Fíjate en la primera fila: tus datos y quién puede acceder a ellos siempre son tu responsabilidad, incluso con SaaS. Si alguien entra a tu cuenta de Microsoft 365 con una contraseña robada, no es culpa del proveedor. Por eso las contraseñas seguras y la autenticación de dos factores importan en todos los modelos.

Virtualización: La Base de la Nube

La nube está construida sobre la virtualización: usar software para dividir una computadora física en muchas máquinas virtuales (VM), cada una con su propio sistema operativo, como si fuera una computadora separada. El software que crea y ejecuta las VM se llama hipervisor. (Para una introducción sencilla, consulta ¿Qué Es una Máquina Virtual?)

Las redes también se virtualizan:

• Cada VM tiene una tarjeta de interfaz de red virtual (vNIC): una versión en software de una tarjeta de red, con su propia dirección MAC y su propia dirección IP.
• Las VM de un mismo servidor físico se conectan mediante un switch virtual dentro del hipervisor, que funciona igual que los switches físicos de la Parte 3.
• La red definida por software del proveedor conecta todo esto a través de miles de servidores físicos, así que tu red virtual se comporta igual sin importar en qué máquinas físicas se ejecuten tus VM.

Virtualización de Funciones de Red (NFV)

La virtualización de funciones de red (NFV) va un paso más allá: en lugar de comprar hardware dedicado para cada función de red, ejecutas esa función como software (un appliance virtual) en servidores estándar, administrado por un hipervisor. Los routers, switches, firewalls, balanceadores de carga y concentradores VPN pueden ser virtuales.

Eso trae varias ventajas:

• Rapidez: crear un firewall o un balanceador de carga nuevo toma minutos, no semanas de pedir, enviar e instalar equipo.
• Flexibilidad: los appliances virtuales se pueden redimensionar, copiar, mover o eliminar según cambien las necesidades.
• Costo: no compras hardware especializado por adelantado, y puedes escalarlo según la demanda.

En la nube, muchas de estas funciones son servicios integrados (como los gateways y las reglas de seguridad de esta publicación). Muchos fabricantes de equipos de red también ofrecen versiones virtuales de sus firewalls y routers, para que las empresas puedan usar los mismos productos en sus propios centros de datos y en la nube.

Nubes Privadas Virtuales (VPC)

Una Nube Privada Virtual (VPC) es tu propia red privada y aislada dentro de un proveedor de nube. Es el equivalente en la nube de la red local de tu oficina: nada puede llegar a los recursos que contiene a menos que tú lo permitas. Las VPC de otros clientes están en el mismo hardware físico, pero no pueden ver la tuya. (Cada proveedor tiene su propio nombre: VPC en AWS y Google Cloud, VNet en Azure y VCN en Oracle Cloud.)

Muchas organizaciones usan VPC separadas para aislar distintas aplicaciones o entornos (por ejemplo, una VPC para producción, una para pruebas y una para desarrollo), para que un error o un problema de seguridad en una no se extienda a las demás.

Direcciones IP y Subredes en una VPC

Cuando creas una VPC, le asignas un rango de direcciones IP privadas en notación CIDR, como 10.0.0.0/16. Luego divides ese rango en subredes, igual que en ¿Qué Es una Subred?:

VPC: 10.0.0.0/16          (65,536 direcciones)
├── Subred pública:  10.0.1.0/24   (servidores web, balanceadores de carga)
├── Subred privada:  10.0.2.0/24   (servidores de aplicación)
└── Subred privada:  10.0.3.0/24   (bases de datos)

Cada subred /24 tiene 256 direcciones, aunque los proveedores de nube reservan algunas en cada subred para su propio uso (AWS, por ejemplo, reserva cinco).

Hay dos tipos de subredes:

• Una subred pública tiene una ruta hacia internet, así que sus recursos pueden tener direcciones IP públicas y ser alcanzados desde internet. Los balanceadores de carga y los servidores web suelen ir aquí.
• Una subred privada no tiene una ruta directa desde internet, así que sus recursos no se pueden alcanzar desde afuera. Los servidores de aplicación y las bases de datos van aquí.

Los grandes proveedores de nube operan varios centros de datos separados en cada región, llamados zonas de disponibilidad. Poner subredes (y copias de tus servidores) en más de una zona de disponibilidad mantiene tu aplicación funcionando aunque un centro de datos tenga una falla.

Tablas de Rutas

Cada subred tiene una tabla de rutas, la misma idea que la tabla de enrutamiento de un router físico. Enumera los destinos y a dónde enviar el tráfico de cada uno. La diferencia entre una subred pública y una privada es simplemente lo que hay en su tabla de rutas:

Tabla de rutas de la subred pública:

Tabla de rutas de la subred privada:

0.0.0.0/0 significa “cualquier dirección”: es la ruta predeterminada, igual que la puerta de enlace predeterminada de la red de tu casa.

Cómo Conectar tu Red en la Nube

Una VPC por sí sola está completamente aislada. Los gateways y otras conexiones te permiten controlar exactamente qué puede entrar y salir.

Gateways de Internet

Un gateway de internet conecta una VPC con internet. Es lo que hace pública a una subred pública: el tráfico de la tabla de rutas de la subred pasa por el gateway de internet, y los recursos con direcciones IP públicas pueden ser alcanzados desde internet. Piensa en él como la versión en la nube de la conexión del router de tu casa con tu proveedor de internet.

Gateways NAT

Los servidores de las subredes privadas muchas veces necesitan salir a internet (para descargar actualizaciones de software o llamar a una API externa) sin poder ser alcanzados desde internet. Un gateway NAT resuelve esto. Se ubica en una subred pública, y los servidores privados envían su tráfico de internet a través de él. Igual que el NAT del router de tu casa (consulta la Parte 1), reemplaza las direcciones privadas de los servidores por su propia dirección pública y envía las respuestas de regreso al servidor correcto, mientras bloquea cualquier conexión que empiece desde afuera.

Transit Gateways y Emparejamiento de VPC

A medida que una organización crea más VPC, estas necesitan comunicarse entre sí. Hay dos formas comunes de conectarlas:

• El emparejamiento de VPC (VPC peering) conecta dos VPC directamente, para que se comuniquen usando direcciones IP privadas. Es sencillo, pero el emparejamiento no es transitivo: si la VPC A está emparejada con la B, y la B con la C, la A todavía no puede llegar a la C. Con muchas VPC, el número de emparejamientos se vuelve rápidamente inmanejable.
• Un transit gateway funciona como un concentrador central: cada VPC se conecta a él una sola vez, y él enruta el tráfico entre todas, junto con las conexiones VPN y los enlaces con los centros de datos locales. Es la versión en la nube de un router central, y convierte una maraña de conexiones en un diseño sencillo de concentrador y radios (hub-and-spoke).

Uses lo que uses, planea tus rangos de IP para que las VPC conectadas no se traslapen. Dos VPC que usan 10.0.0.0/16 no se pueden conectar sin hacer cambios importantes.

VPN y Conexiones Dedicadas

Para conectar tu oficina o tu centro de datos local con la nube:

• Una VPN de sitio a sitio crea un túnel cifrado a través de internet entre la red de tu oficina y tu VPC, como se describe en la Parte 4. Es rápida de configurar y económica.
• Las VPN de acceso remoto permiten que usuarios individuales (como los administradores que trabajan desde casa) se conecten de forma segura a una VPC, sin exponer los servidores a internet.
• Las conexiones privadas dedicadas (como AWS Direct Connect o Azure ExpressRoute) usan un enlace físico privado entre tu centro de datos y el proveedor de nube, en lugar de internet. Son más costosas, pero más rápidas y estables.

Endpoints de VPC

Los proveedores de nube ofrecen muchos servicios fuera de tu VPC, como el almacenamiento de archivos y las bases de datos. Normalmente, un servidor llegaría a ellos por internet, a través de un gateway de internet o un gateway NAT. Un endpoint de VPC le da a tu VPC una conexión directa y privada con esos servicios: el tráfico se queda en la red propia del proveedor y nunca cruza internet. Eso es más seguro, muchas veces más rápido y puede bajar los costos de transferencia de datos.

Los endpoints privados también pueden conectar tu VPC con servicios que otras empresas operan en la nube, para que dos organizaciones se conecten de forma privada sin que ninguna exponga un servicio a internet.

Seguridad de Redes en la Nube

Las redes en la nube usan la misma idea que los firewalls de la Parte 3: reglas que permiten o bloquean el tráfico según el protocolo, el puerto y la dirección de origen o de destino. La gran diferencia es dónde se aplican las reglas. Hay dos niveles principales.

Listas de Seguridad de Red: Reglas para Toda una Subred

Una lista de seguridad de red (o lista de control de acceso de red) aplica un solo conjunto de reglas a toda una subred. Cada recurso de la subred recibe las mismas reglas automáticamente. Es una primera línea de defensa amplia; por ejemplo, “nada de internet puede llegar a la subred de las bases de datos”.

Según el proveedor, estas reglas pueden ser sin estado (stateless): no recuerdan las conexiones, así que tienes que permitir el tráfico de respuesta por separado, en ambas direcciones. Eso las hace poderosas, pero es fácil equivocarse.

Grupos de Seguridad de Red: Reglas para Recursos Individuales

Un grupo de seguridad de red asigna reglas a interfaces de red virtuales (vNIC) individuales; en otras palabras, a servidores específicos. Esto te da una granularidad mucho más fina: dos servidores de la misma subred pueden tener reglas completamente distintas, según lo que haga cada uno.

Los grupos de seguridad suelen ser con estado (stateful), como los firewalls con estado de la Parte 3: si se permite la entrada de una conexión, las respuestas se permiten automáticamente. También pueden hacer referencia a otros grupos de seguridad en lugar de a direcciones IP; por ejemplo, “la base de datos acepta conexiones solo de los servidores del grupo de seguridad de la aplicación”. Así, las reglas siguen funcionando aunque se agreguen o quiten servidores, o cambien sus direcciones IP.

Así podrían proteger los grupos de seguridad a una aplicación típica de tres capas:

Fíjate en que a la base de datos solo pueden llegar los servidores de aplicación, y nada puede llegar a los servidores de aplicación directamente desde internet. (Para saber más sobre los números de puerto, consulta Números de Puerto Conocidos, y sobre el acceso remoto seguro, ¿Qué Es SSH?)

Listas de Seguridad vs. Grupos de Seguridad

Lo mejor es usar ambos, una práctica llamada defensa en profundidad. Las listas de seguridad funcionan como un límite exterior amplio para cada subred, y los grupos de seguridad aplican reglas precisas a cada servidor. Si una capa está mal configurada, la otra te sigue protegiendo. En ambos casos, sigue el principio de mínimo privilegio: permite solo el tráfico que realmente se necesita y bloquea todo lo demás.

Las Mismas Ideas con Nombres Distintos

Cada proveedor de nube usa sus propios nombres para estas funciones, lo que puede confundir al empezar:

El Modelo de Responsabilidad Compartida

En la nube, la seguridad es compartida, según la matriz de responsabilidades que viste antes en esta publicación. El proveedor es responsable de la seguridad de la nube: los centros de datos físicos, el hardware y la plataforma de virtualización. Tú eres responsable de la seguridad en la nube: cómo configuras tus VPC, subredes y reglas de seguridad, y los servidores y datos que pones ahí. Con IaaS, como las VPC de esta publicación, eso es mucho, y por eso las reglas de seguridad de arriba son tan importantes. La mayoría de los incidentes de seguridad en la nube vienen de errores de configuración de los clientes (como una base de datos abierta a todo internet), no de la infraestructura del proveedor.

Todo Junto: Una Aplicación Web Típica en la Nube

Así encajan las piezas en una aplicación web en la nube:

Cuando un visitante abre el sitio web:

1. Su solicitud llega por el gateway de internet al balanceador de carga de la subred pública, que su grupo de seguridad permite en el puerto 443.
2. El balanceador de carga reenvía la solicitud a un servidor de aplicación en una subred privada. El grupo de seguridad del servidor de aplicación la acepta, porque viene del balanceador.
3. El servidor de aplicación consulta la base de datos en otra subred privada, que solo acepta conexiones de los servidores de aplicación.
4. Cuando el servidor de aplicación necesita descargar una actualización, sale por el gateway NAT. Cuando guarda archivos subidos, usa el endpoint de VPC, así que ese tráfico nunca toca internet.
5. Los administradores llegan a los servidores por la VPN de sitio a sitio desde la oficina, conectada mediante el transit gateway, así que ningún servidor necesita tener SSH abierto a internet.

De lo Físico a la Nube: Tabla de Equivalencias

Errores Comunes en las Redes en la Nube

• Abrir SSH o el escritorio remoto a todo internet. Una regla que permite el puerto 22 o el 3389 desde 0.0.0.0/0 invita a ataques automatizados constantes. Permítelo solo desde una VPN o un rango de direcciones específico.
• Poner las bases de datos en subredes públicas. Las bases de datos casi nunca necesitan ser alcanzables desde internet. Mantenlas en subredes privadas, accesibles solo desde tus servidores de aplicación.
• Traslapar rangos de IP. Las VPC que usan el mismo rango de direcciones no se pueden conectar después. Planea tus rangos de direcciones antes de construir.
• Olvidar una ruta. Un gateway NAT o una VPN no hace nada hasta que una tabla de rutas le envía tráfico. Cuando algo no se puede conectar, revisa la tabla de rutas además de las reglas de seguridad.
• Olvidar el tráfico de respuesta con reglas sin estado. Si tus reglas a nivel de subred son sin estado, permite también el tráfico de regreso, o las conexiones fallarán en una dirección.
• Ignorar los costos. Los gateways NAT y la transferencia de datos se cobran por hora y por gigabyte. Los endpoints de VPC pueden reducir ambos.

Lo que Sigue en esta Serie

Las redes en la nube usan todos los conceptos de esta serie (subredes, enrutamiento, NAT, firewalls, VPN y más), solo que en forma virtual. Las próximas publicaciones de la serie Redes Informáticas para Principiantes seguirán construyendo sobre estas bases. Si mientras tanto quieres practicar, la mayoría de los proveedores de nube ofrecen un nivel gratuito: crea una VPC pequeña con una subred pública y una privada, lanza un servidor virtual y experimenta con las tablas de rutas y las reglas de seguridad. Para aprender a configurar y proteger un servidor en la nube, consulta Aprende VPS: De los Fundamentos a tu Primer Despliegue.

Conclusión

Las redes en la nube toman los conceptos físicos que ya conoces y los vuelven virtuales. Las nubes pueden ser públicas, privadas o híbridas, y los servicios se ofrecen como IaaS, PaaS o SaaS, con la matriz de responsabilidades decidiendo qué administras tú y qué administra el proveedor. La virtualización y la NFV convierten servidores, routers, switches y firewalls en software que se crea en minutos y escala de forma elástica, mientras que la multitenencia permite que muchos clientes compartan el mismo hardware de forma segura. Una VPC te da tu propia red aislada, dividida en subredes públicas y privadas, con tablas de rutas que deciden a dónde va el tráfico. Los gateways de internet conectan las subredes públicas con internet, los gateways NAT permiten que los servidores privados salgan sin poder ser alcanzados, los transit gateways conectan muchas VPC, las VPN conectan tus oficinas y usuarios, y los endpoints de VPC llegan a los servicios de la nube de forma privada. Por último, las listas de seguridad protegen subredes completas mientras que los grupos de seguridad protegen servidores individuales, y usar ambos, con mínimo privilegio, te da defensa en profundidad.

Cuando puedes relacionar cada función de la nube con su equivalente físico, las redes en la nube dejan de parecer un mundo nuevo: es la misma red, construida en software.

Siguiente en la serie Redes Informáticas para Principiantes: El Protocolo de Internet Explicado: Cómo Viajan los Datos por las Redes, cómo TCP, UDP, los puertos y los sockets entregan los datos a la aplicación correcta.

Serie Redes Informáticas para Principiantes: Parte 1: Guía Completa de Cómo Funcionan las Redes · Parte 2: ¿Qué Es el Modelo OSI? · Parte 3: Dispositivos de Red Explicados · Parte 4: CDN, VPN, QoS y TTL · Parte 5: Redes en la Nube Explicadas · Parte 6: El Protocolo de Internet Explicado · Parte 7: Números de Puerto Conocidos · Parte 8: Protocolos para Diagnóstico, Túneles y Seguridad