Unidad 3.2: Seguridad de red: Firewall y grupos de seguridad

Introducción

La segmentación en la Unidad 3.1 proporcionó a FinCorp tres LAN: un borde público, un nivel de aplicaciones privado y un nivel de datos de solo acceso privado. La topología por sí sola no impone quién puede comunicarse con quién. La capa de aplicación se encuentra en las NIC de los servidores, y es la siguiente decisión en el diseño de red: tanto un firewall por NIC como los Network Security Groups se asocian a las interfaces de red de las máquinas virtuales, y ambos se configuran por defecto para denegar todo una vez que se activan.

Esta unidad concluye construyendo dicha aplicación en el Data Center Designer para el entorno de FinCorp: reglas de firewall que permiten solo los flujos entre niveles que la arquitectura requiere, además de un registro de flujos escrito en un contenedor de Object Storage para que el equipo de seguridad pueda verificar, a posteriori, exactamente qué conexiones se aceptaron y cuáles se rechazaron. Antes de la construcción, dos aspectos deben estar claros: cómo evalúa el firewall el tráfico y dónde dejan de aplicarse las construcciones del firewall.

1. Mecánica del cortafuegos de NIC y el contrato de denegación por defecto

El cortafuegos de IONOS CLOUD es una propiedad de una NIC de servidor individual, no de una subred, una LAN o del VDC en su conjunto. Una NIC sin cortafuegos permite todo el tráfico. En el momento en que se activa el cortafuegos en esa NIC, el contrato se invierte: con el cortafuegos activado y sin reglas definidas, todo el tráfico entrante se bloquea. Cada conexión que se desee permitir es, entonces, una regla de permiso explícita. No existe una regla de "denegación" separada que escribir, y el principio de privilegio mínimo se logra simplemente al no añadir una regla, lo cual refleja la postura de control de acceso que se observó en la gobernanza.

El cortafuegos es con estado. Cuando una regla permite una conexión saliente, los paquetes de respuesta correspondientes se permiten automáticamente; no se escribe una regla especular para el tráfico de respuesta. Esto es importante para la capa de aplicaciones de FinCorp: una regla que permite a los servidores de aplicaciones acceder al punto de acceso de PostgreSQL en la capa de datos también permite que los resultados de las consultas fluyan de vuelta, sin necesidad de una segunda regla entrante en la NIC de la aplicación para la respuesta de la base de datos.

Las reglas pueden aplicarse por dirección. Al activar el cortafuegos, se elige Ingress, Egress o Bidirectional, y cada regla lleva consigo una dirección de Ingress o Egress. Una regla coincide con el protocolo y los campos relevantes para ese protocolo. Los protocolos admitidos son TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH y ESP, además de la opción "Cualquier protocolo". Para TCP y UDP se especifican rangos de puertos; para ICMP e ICMPv6 se especifican tipo y código (por ejemplo, tipo 8 para solicitudes de eco). Una regla también puede restringir la MAC de origen, la IP/CIDR de origen y la IP/CIDR de destino, donde el campo de destino es útil cuando una NIC lleva direcciones IP virtuales.

Dado que escribir reglas a mano para roles comunes es propenso a errores, DCD incluye plantillas de reglas. Las siguientes plantillas están disponibles y preconfiguran un conjunto de reglas típico:

Una plantilla es un punto de partida, no una política terminada. La plantilla de servidor web genérico, por ejemplo, permite HTTP y HTTPS desde todas las fuentes, lo cual es apropiado para una NIC de borde orientada a internet, pero incorrecto para una capa privada. Las reglas también pueden clonarse desde otra NIC, lo que mantiene la consistencia en una flota de servidores idénticos. La ruta de datos del cortafuegos tiene una clasificación de hasta 6 Gbps de ancho de banda según la matriz de hechos, lo cual es suficiente para el filtrado entre capas, pero es un número que debe tenerse en cuenta para NICs de muy alto ancho de banda.

2. NSGs frente al firewall de la NIC, y el límite donde ninguno aplica

El firewall por NIC es local: sus reglas residen en una NIC y se gestionan allí. Los Network Security Groups resuelven el problema de escalabilidad. Un NSG es un conjunto de reglas nombrado y reutilizable, creado a nivel de VDC y luego adjuntado a servidores o NICs, de modo que una sola política puede gobernar muchas interfaces y un cambio en el grupo se propaga a todos los miembros adjuntos. Los NSGs pueden gestionarse a través de DCD, la Cloud API, el Go Cloud SDK y Terraform.

Cada VM recién creada en un VDC se agrega automáticamente al Default NSG, que incluye cuatro reglas predefinidas: permitir todo el tráfico IPv4 de salida, permitir todo el tráfico IPv6 de salida, permitir el tráfico IPv4 de entrada solo desde el rango 10.0.0.0/24 del VDC, y permitir el tráfico IPv6 de entrada solo desde el CIDR IPv6 /56 asignado al centro de datos. Esa configuración predeterminada es permisiva en la salida y en el tráfico este-oeste por diseño, por lo que un inquilino regulado como FinCorp suele reemplazarla con grupos personalizados que solo conceden los flujos necesarios. Los NSGs personalizados son de denegar todo por defecto, al igual que el firewall de la NIC, por lo que cada flujo permitido vuelve a ser una regla explícita.

Los NSGs son con estado, admiten reglas INGRESS y EGRESS, y aceptan el conjunto de protocolos UDP, TCP, ICMP, ICMPv6, GRE, VRRP, ESP, AH y ANY. Los límites de capacidad son importantes de conocer en el momento del diseño: hasta 10 NSGs por NIC, hasta 10 por VM, hasta 100 reglas por NSG, y hasta 200 NSGs por VDC. El adjuntamiento es granular: puede adjuntar un grupo a nivel de VM, donde cubre todas las NICs de esa VM, o a nivel de NIC individual para un control más estricto. Cuando una VM es miembro de un NSG, todas las NICs de esa VM heredan implícitamente las reglas.

La siguiente tabla contrasta ambos constructos para orientar dónde corresponde cada uno:

Un instinto de diseño común es superponer ambos para la defensa en profundidad. Sea deliberado aquí: la matriz de hechos registra que el uso paralelo de NSGs y del firewall de la NIC no es el patrón recomendado, por lo que elija un modelo de aplicación por entorno en lugar de ejecutar conjuntos de reglas superpuestos que son difíciles de razonar. Para FinCorp, los NSGs son la mejor opción porque la postura de seguridad se define por capa y se reutiliza en muchos servidores idénticos.

Existe un límite explícito que rige el resto del Módulo 3. Los NSGs y los firewalls de NIC se vinculan únicamente a interfaces de red de VM. NO se aplican a los equilibradores de carga administrados (el Managed Application Load Balancer y el Managed Network Load Balancer) y NO se aplican a la abstracción de clúster de Managed Kubernetes. Concretamente, no puede agregar nodos de grupos de nodos de Managed Kubernetes (o Cubes suspendidos) a un NSG. Por esta razón, la arquitectura por capas aísla la capa de datos mediante la topología y coloca el filtrado en los objetivos detrás de un equilibrador, en lugar de en el propio equilibrador: el Managed ALB no tiene un firewall dedicado propio, y el Managed NLB solo lleva reglas de firewall básicas e inmutables generadas automáticamente a partir de sus reglas de reenvío, por lo que todas las reglas de permiso configurables por el cliente residen en las NICs de las VMs de backend o en sus NSGs. Considere esto como un insumo de diseño, no como una carencia: el patrón nativo es el filtrado en el lado del objetivo junto con una ubicación privada por defecto.

Una advertencia operativa sobre el control de acceso: desactivar el privilegio de NSG para un subusuario no lo bloquea por completo. Un usuario que aún puede acceder al centro de datos relevante puede continuar gestionando NSGs existentes; el privilegio controla la creación y el uso de NSGs, no la gestión de grupos que ya existen. Planifique la propiedad de los grupos y el acceso al centro de datos de forma conjunta.

Guía de implementación de DCD

Aplicará reglas de firewall de nivel a nivel a los servidores de aplicaciones de FinCorp y, a continuación, habilitará un registro de flujo en una NIC para que el equipo de seguridad pueda verificar lo que el firewall acepta y rechaza. Esto materializa la capa de aplicación sobre la topología de tres LAN de la Unidad 3.1. Requisitos previos: el VDC y sus NICs de servidor de la Unidad 3.1 ya deben existir, y debe existir un cubo de Object Storage propiedad del usuario antes de que el registro de flujo pueda apuntar a él (solo los administradores de contrato y los propietarios pueden habilitar Object Storage, y el creador del registro de flujo necesita el privilegio Create Flow logs).

Objetivo de construcción: Aplicar reglas de firewall entre niveles; habilitar un registro de flujo hacia un cubo de Object Storage.

Pasos (en Data Center Designer):

1. Abra el VDC y, en el Workspace, seleccione un servidor de nivel de aplicación que tenga una NIC en la LAN de aplicación privada.
2. En el panel Inspector, abra la pestaña Network y, a continuación, abra las propiedades de la NIC que desea proteger.
3. Active el firewall en esa NIC seleccionando el tipo de flujo de tráfico que desea aplicar: Ingress, Egress o Bidirectional. Una vez activo y sin reglas, la NIC bloquea todo el tráfico entrante, por lo que defina reglas antes de depender de ella.
4. Haga clic en Manage Rules, luego en Create Firewall Rule, y elija el protocolo para la regla (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP o Any Protocol). Para el flujo de aplicación a base de datos, cree una regla TCP.
5. Complete los campos de la regla: un Name; Direction (Egress para el servidor de aplicación que accede a la base de datos); Source IP/CIDR y Destination IP/CIDR acotados a los rangos privados; y el puerto de destino para la base de datos. Deje IP Version como Auto a menos que esté fijando una familia. El firewall con estado permite el tráfico de retorno automáticamente, por lo que no se necesita una regla de respuesta entrante.
6. Para servidores basados en roles, use opcionalmente Rules from Template (Generic Webserver, Mailserver, Remote Access Linux, Remote Access Windows) como punto de partida y, a continuación, restrinja las fuentes; o use Clone Rules desde otra NIC para mantener la consistencia entre servidores idénticos. Haga clic en Save.
7. Para habilitar un registro de flujo en la misma NIC, abra el menú desplegable Flow Log de las propiedades de la NIC (para un Managed NLB o Managed NAT Gateway, usaría en su lugar la pestaña Settings del elemento) e introduzca un Name. Este nombre se convierte en la primera parte del prefijo del nombre del objeto en el cubo.
8. Establezca Direction (Ingress, Egress o Bidirectional), Action (Rejected para capturar solo el tráfico bloqueado, Accepted para capturar solo el tráfico permitido, o Any) y el cubo de Object Storage de destino: un nombre de cubo existente y válido propiedad del usuario más un prefijo de nombre de objeto opcional. Elija Add flow log.
9. Una luz verde en las propiedades de la NIC confirma que la configuración se validó. Seleccione PROVISION CHANGES. Después de que la aprovisionamiento se complete, tanto las reglas de firewall como el registro de flujo estarán activos, y los registros por flujo comenzarán a llegar al cubo como archivos .log.gz comprimidos con gzip.

Cada registro de flujo es por flujo, agregado sobre un intervalo fijo de 10 minutos sin muestreo (se registran todos los flujos del intervalo), y los intervalos sin tráfico se omiten. Cada registro contiene campos que incluyen dirección y puerto de origen y destino, número de protocolo IANA, recuentos de paquetes y bytes, marcas de tiempo de inicio y fin, y un campo action de ACCEPT o REJECT. El campo action es precisamente la señal de verificación: establezca Action del registro de flujo en Rejected cuando desee ver solo lo que el firewall está descartando, que es la forma más rápida de encontrar una regla de permiso faltante, o Accepted para confirmar que solo los flujos previstos están pasando.

Errores comunes:

• Activar el firewall en una NIC y luego irse. Con el firewall activado y sin reglas, la NIC bloquea todo el tráfico entrante; defina las reglas de permiso en el mismo cambio.
• Escribir una regla de tráfico de retorno. El firewall y los NSGs son con estado, por lo que las respuestas de una conexión saliente permitida se permiten automáticamente. Una regla entrante espejo es redundante y ensucia la política.
• Ejecutar NSGs y el firewall de NIC en paralelo para las mismas NICs. El uso en paralelo no es el patrón recomendado; elija un modelo de aplicación por entorno.
• Dejar el NSG predeterminado en su lugar para un nivel regulado. Permite todo el tráfico saliente y de este a oeste dentro del VDC; reemplácelo con grupos personalizados de denegar todo que otorguen solo los flujos necesarios.
• Esperar que un firewall o NSG proteja un balanceador de carga administrado o nodos de Kubernetes. Ninguna de estas estructuras se une allí. Coloque las reglas de permiso en las NICs de los VM de backend y use políticas de red dentro del clúster para Kubernetes.
• Apuntar un registro de flujo a un cubo que aún no existe, o que no es propiedad de su contrato. El destino debe ser un cubo de Object Storage existente y propiedad del usuario; créelo primero.
• Suponer que eliminar la regla del registro de flujo limpia los datos. Eliminar la regla detiene nuevos registros, pero no elimina los objetos de registro existentes del cubo, ni cambia sus políticas o ACLs.
• Tratar los registros de flujo como un servicio de retención administrado. Hay un registro de flujo por recurso, el formato de registro y la configuración son inmutables después de la creación, y la retención es gestionada completamente por el cliente: establezca una política de ciclo de vida de Object Storage en el cubo de destino (o elimine manualmente). Nada caduca automáticamente a menos que lo configure.

Una breve verificación con ionosctl después del aprovisionamiento confirma las reglas de firewall adjuntas a la NIC, lo cual es útil en un script de auditoría:

ionosctl firewallrule list --datacenter-id "$DC_ID" \
  --server-id "$SRV_ID" --nic-id "$NIC_ID"

El punto arquitectónico es que el conjunto de reglas es consultable y, por lo tanto, auditable como configuración; la decisión de aplicación sigue estando en el diseño anterior, no en el comando.

Resumen

La topología de tres niveles de FinCorp se convierte en un límite de seguridad solo cuando se aplica la aplicación en las NIC de los servidores. Tanto el firewall por NIC como los Network Security Groups se asocian a las interfaces de VM, son con estado y, una vez activos, rechazan por defecto (con la notable excepción del NSG predeterminado permisivo). Los NSG prevalecen cuando una sola política debe gobernar muchas interfaces; el firewall por NIC es adecuado para excepciones puntuales. Es fundamental que ninguna de estas estructuras alcanza a los equilibradores de carga administrados ni a la abstracción del clúster Managed Kubernetes, lo que obliga a aplicar el filtrado en los destinos y refuerza la colocación privada por defecto. Los registros de flujo cierran el ciclo: escriben registros inmutables de ACCEPT/REJECT por flujo en un bucket de Object Storage propiedad del cliente, convirtiendo "qué hace realmente el firewall" de una suposición en evidencia.

Puntos clave:

• El firewall de NIC y los NSG personalizados rechazan por defecto una vez activos; cada flujo permitido es una regla explícita, y el privilegio mínimo se logra mediante la no concesión.
• Ambos son con estado, por lo que el tráfico de retorno de una conexión permitida se permite automáticamente; no se deben escribir reglas espejo.
• Los NSG son políticas reutilizables a nivel de VDC (hasta 10 por NIC/VM, 100 reglas cada uno, 200 por VDC); el firewall de NIC es local. No se recomienda el uso paralelo de ambos.
• Los NSG y los firewalls de NIC no se aplican a los equilibradores de carga administrados ni a los nodos de los grupos de nodos de Managed Kubernetes; el filtrado se traslada a los destinos y a las políticas de red dentro del clúster.
• Los registros de flujo publican registros por flujo (agregación de 10 minutos, sin muestreo) con un campo de acción ACCEPT/REJECT en un bucket de Object Storage propiedad del usuario; hay un registro de flujo por recurso, el formato es inmutable y la retención la gestiona el cliente mediante una política de ciclo de vida.