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

Introducción

La segmentación en la Unidad 3.1 dio a FinCorp tres LAN: un borde público, un nivel de aplicación privado y un nivel de datos privado solo. La topología sola no hace cumplir quién puede hablar 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 la red: un Firewall y un Network Security Groups por NIC se unen a las interfaces de red de la máquina virtual, y ambos se configuran para denegar todo una vez que se activan.

Esta unidad termina construyendo esa aplicación en el Data Center Designer para el entorno de FinCorp: reglas Firewall que permiten solo los flujos entre niveles que requiere la arquitectura, más un registro de flujo escrito en un cubo Object Storage para que el equipo de seguridad pueda verificar, después de los hechos, exactamente qué conexiones se aceptaron y cuáles se rechazaron. Antes de la construcción, dos cosas deben estar claras: cómo el Firewall evalúa el tráfico, y dónde dejan de aplicarse las construcciones Firewall.

1. Mecánica de Firewall y el contrato de denegación por defecto

El Firewall de IONOS es una propiedad de una NIC de servidor individual, no de una subred, un LAN o el VDC en su conjunto. Una NIC sin Firewall permite todo el tráfico. En el momento en que activa el Firewall en esa NIC, el contrato se invierte: con el Firewall activado y sin reglas definidas, todo el tráfico de entrada es bloqueado. Cada conexión que desee permitir es entonces una regla de permitir explícita. No hay una regla de "denegar" separada que escribir, y el privilegio mínimo se logra simplemente no agregando una regla, lo que refleja la postura de control de acceso que vio en la gobernanza.

El Firewall es con estado. Cuando una regla permite una conexión saliente, los paquetes de respuesta correspondientes se permiten automáticamente; no escribe una regla de espejo para el tráfico de respuesta. Esto es importante para el nivel de aplicación de FinCorp: una regla que permite que los servidores de aplicaciones lleguen al punto de conexión PostgreSQL en el nivel de datos también permite que los resultados de la consulta fluyan hacia atrás, sin una segunda regla de entrada en la NIC de la aplicación para la respuesta de la base de datos.

Las reglas se pueden aplicar por dirección. Al activar el Firewall, elige Ingress, Egress o Bidirectional, y cada regla en sí lleva 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 una opción de "cualquier protocolo". Para TCP y UDP, especifica rangos de puertos; para ICMP y ICMPv6, especifica 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.

Debido a que escribir reglas a mano para roles comunes es propenso a errores, el DCD envía 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 que es adecuado para una NIC de borde que se enfrenta a Internet, pero es incorrecto para un nivel privado. Las reglas también se pueden clonar desde otra NIC, lo que mantiene una flota de servidores idénticos coherentes. El camino de datos del Firewall tiene una tasa de hasta 6 Gbps de rendimiento por la matriz de hechos, lo que es suficiente para el filtrado de nivel a nivel, pero es un número que hay que tener en cuenta para NICs de muy alta velocidad.

2. NSGs versus el Firewall de la NIC, y el límite donde ninguna de las dos opciones se aplica

El Firewall por NIC es local: sus reglas viven en una NIC y se gestionan allí. Los Network Security Groups resuelven el problema de escalabilidad. Un NSG es un conjunto de reglas con nombre, reutilizable, creado a nivel de VDC y luego adjuntado a servidores o NIC, por lo que una política puede gobernar muchas interfaces y un cambio en el grupo se propaga a cada miembro adjunto. Los NSGs se pueden gestionar a través del DCD, la nube API, la nube Go SDK y el Terraform.

Cada nuevo VM creado en un VDC se agrega automáticamente al NSG predeterminado, que viene con cuatro reglas predefinidas: permitir todo el tráfico de salida IPv4, permitir todo el tráfico de salida IPv6, permitir el tráfico de entrada IPv4 solo desde la gama 10.0.0.0/24 del VDC, y permitir el tráfico de entrada IPv6 solo desde la gama /56 IPv6 CIDR asignada al centro de datos. Ese valor predeterminado es permisivo en la salida y en la comunicación este-oeste por diseño, por lo que un inquilino regulado como FinCorp suele reemplazarlo con grupos personalizados que solo conceden los flujos requeridos. Los NSGs personalizados son de denegación de todos por defecto, al igual que el Firewall de la NIC, por lo que cada flujo permitido es nuevamente una regla explícita.

Los NSGs son con estado, admiten reglas tanto de entrada como de salida, 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 ajuste es granular: puede adjuntar un grupo a nivel de VM, donde cubre todas las NIC de ese VM, o a nivel de NIC individual para un control más estricto. Cuando un VM es miembro de un NSG, todas las NIC de ese VM heredan implícitamente las reglas.

La siguiente tabla contrasta las dos estructuras para guiar dónde pertenece cada una:

Un instinto de diseño común es capas tanto para la defensa en profundidad. Sea deliberado aquí: la matriz de hechos registra que el uso paralelo de NSGs y el Firewall de la NIC no es el patrón recomendado, así 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 nivel y se reutiliza en muchos servidores idénticos.

Hay un límite explícito que gobierna el REST del Módulo 3. Los NSGs y los cortafuegos de NIC se unen solo a las interfaces de red 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 Managed Kubernetes Cluster. Concretamente, no puede agregar nodos de grupo Managed Kubernetes Node (o Cubes suspendidos) a un NSG. Esto es por qué la arquitectura en capas aísla el nivel de datos con la topología y coloca el filtrado en los objetivos detrás de un equilibrador en lugar de en el equilibrador en sí: el ALB administrado no tiene un Firewall dedicado propio, y el NLB administrado solo lleva reglas Firewall básicas e inmutables generadas automáticamente a partir de sus reglas de reenvío, por lo que todas las reglas de permitir configurables por el cliente viven en las NIC de las máquinas virtuales de backend o en sus NSGs. Trate esto como una entrada de diseño, no como una brecha: el patrón nativo es el filtrado del lado del objetivo más la colocación privada por defecto.

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

Implementación de DCD: Guía paso a paso

Usted aplicará reglas de Firewall de nivel a nivel a los servidores de aplicaciones de FinCorp y luego habilitará un registro de flujo en una NIC para que el equipo de seguridad pueda verificar qué acepta y rechaza el Firewall. Esto realiza 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 existen, y un bucket de Object Storage propiedad del usuario debe existir antes de que el registro de flujo pueda dirigirse a él (solo los administradores de contrato y propietarios pueden habilitar Object Storage, y el creador del registro de flujo necesita el privilegio de Crear Flow Logs).

Objetivo de construcción: Aplicar reglas de Firewall entre niveles; habilitar un registro de flujo en un bucket de Object Storage.

Pasos (en el 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 red de aplicación privada LAN.
2. En el panel Inspector, abra la pestaña Red, luego abra las propiedades de la NIC que desea proteger.
3. Active el Firewall en esa NIC eligiendo el tipo de flujo de tráfico que se va a aplicar: Entrada, Salida o Bidireccional. Una vez activado sin reglas, la NIC bloquea todo el tráfico entrante, así que defina las reglas antes de confiar en ella.
4. Haga clic en Administrar reglas, luego en Crear regla de Firewall, y elija el protocolo para la regla (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP o cualquier protocolo). Para el flujo de aplicación a base de datos, cree una regla TCP.
5. Rellene los campos de la regla: un nombre; Dirección (Salida para que el servidor de aplicaciones llegue a la base de datos); Origen IP/CIDR y Destino IP/CIDR con los rangos privados; y el puerto de destino para la base de datos. Deje la versión de IP como Auto a menos que esté fijando una familia. El Firewall con estado permite el tráfico de respuesta automáticamente, por lo que no se necesita una regla de respuesta entrante.
6. Para servidores basados en roles, utilice opcionalmente Reglas desde plantilla (Servidor web genérico, Servidor de correo, Acceso remoto Linux, Acceso remoto Windows) como punto de partida, luego ajuste las fuentes; o utilice Clonar reglas de otra NIC para mantener servidores idénticos coherentes. Haga clic en Guardar.
7. Para habilitar un registro de flujo en la misma NIC, abra el menú desplegable del registro de flujo de las propiedades de la NIC (para un NLB administrado o Managed NAT Gateway, en su lugar, utilice la pestaña Configuración del elemento) e ingrese un nombre. Este nombre se convierte en la primera parte del prefijo de nombre de objeto en el bucket.
8. Establezca la Dirección (Entrada, Salida o Bidireccional), Acción (Rechazado para capturar solo el tráfico bloqueado, Aceptado para capturar solo el tráfico permitido o Cualquiera) y el bucket de destino Object Storage: un nombre de bucket existente y válido propiedad del usuario, más un prefijo de nombre de objeto opcional. Elija Agregar registro de flujo.
9. Una luz verde en las propiedades de la NIC confirma que la configuración es válida. Seleccione PROVISIONAR CAMBIOS. Después de que se complete la provisión, tanto las reglas de Firewall como el registro de flujo están activos, y los registros de flujo comienzan a llegar al bucket como archivos .log.gz comprimidos con gzip.

Cada registro de flujo es por flujo, agregado sobre un intervalo fijo de 10 minutos sin muestreo (todos los flujos en el intervalo se registran), y se saltan los intervalos sin tráfico. Cada registro lleva campos que incluyen la dirección y el puerto de origen y destino, el número de protocolo IANA, los recuentos de paquetes y bytes, las fechas y horas de inicio y fin, y un campo action de ACEPTAR o RECHAZAR. El campo action es precisamente la señal de verificación: configure la Acción del registro de flujo en Rechazado cuando desee ver solo qué está rechazando el Firewall, lo que es la forma más rápida de encontrar una regla de permitir que falta, o Aceptado para confirmar que solo los flujos previstos están pasando.

Errores comunes:

• Activar el Firewall en una NIC y luego abandonar. Con el Firewall activado y sin reglas, la NIC bloquea todo el tráfico entrante; defina las reglas de permitir en el mismo cambio.
• Escribir una regla de tráfico de respuesta. El Firewall y los NSG son con estado, por lo que las conexiones salientes permitidas tienen respuestas permitidas automáticamente. Una regla de entrada reflejada es redundante y llena de desorden la política.
• Ejecutar NSG y el Firewall de la NIC en paralelo para las mismas NIC. El uso 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 de salida y este-oeste dentro del VDC; reemplácelo con grupos personalizados que deniegan todo y solo conceden los flujos requeridos.
• Esperar que un Firewall o NSG proteja un Load Balancer o Kubernetes administrado. Ninguna de estas construcciones se une allí. Coloque las reglas de permitir en las NIC de backend VM y utilice las políticas de red dentro de Cluster para Kubernetes.
• Señalar un registro de flujo a un bucket que no existe aún, o uno que no es propiedad de su contrato. El destino debe ser un bucket 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 los nuevos registros, pero no elimina los objetos de registro existentes del bucket, ni cambia sus políticas o ACL.
• Tratar Flow Logs 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 completamente administrada por el cliente: configure una política de ciclo de vida de Object Storage en el bucket de destino (o elimínelo manualmente). Nada caduca automáticamente a menos que lo configure.

Un breve ionosctl después de la provisión 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 viviendo 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 el cumplimiento en las NIC de los servidores. Tanto el Firewall por NIC como el Network Security Groups se unen a las interfaces VM, son estatales y niegan por defecto una vez activados (con la notable excepción de la NSG predeterminada permisiva). Las NSG ganan cuando una política debe gobernar muchas interfaces; el Firewall por NIC se adapta a excepciones de un solo uso. Críticamente, ninguna de las dos estructuras alcanza los equilibradores de carga administrados o la abstracción Managed Kubernetes Cluster, lo que fuerza el filtrado hacia los objetivos y refuerza la colocación privada por defecto. Los Flow Logs cierran el bucle: escriben registros inmutables, ACCEPT/REJECT por flujo, en un cubo Object Storage propiedad del cliente, convirtiendo "¿qué hace el Firewall en realidad" de una suposición en evidencia.

Puntos clave:

• El Firewall de NIC y las NSG personalizadas son de denegación por defecto una vez activadas; cada flujo permitido es una regla explícita, y se logra el privilegio mínimo al no conceder.
• Ambos son estatales, por lo que el tráfico de retorno para una conexión permitida se permite automáticamente; no escriba reglas de espejo.
• Las NSG son políticas reutilizables a nivel de VDC (hasta 10 por NIC/VM, 100 reglas cada una, 200 por VDC); el Firewall de NIC es local. No se recomienda el uso paralelo de ambos.
• Las NSG y los firewalls de NIC no se aplican a los equilibradores de carga administrados ni a los nodos de grupo de Managed Kubernetes Node; el filtrado se mueve hacia los objetivos y hacia las políticas de red en Cluster.
• Los Flow Logs publican registros por flujo (agregación de 10 minutos, sin muestreo) con un campo de acción ACCEPT/REJECT a un cubo Object Storage propiedad del usuario; hay un registro de flujo por recurso, el formato es inmutable y la retención es administrada por el cliente a través de la política de ciclo de vida.