Segmentación de red on‑prem y en la nube: VLANs, firewalls, Security Groups y buenas prácticas

La segmentación de red es una de las medidas más eficaces para reducir la superficie de ataque, limitar la propagación de incidentes y separar de forma nítida los procesos operativos. El término Segmentación de red designa la creación deliberada de zonas lógicas o físicas en la red en las que dispositivos, servicios y usuarios solo pueden comunicarse entre sí de forma controlada. En las empresas esto suele significar una combinación de VLANs (Virtual LANs), zonas de enrutamiento/Layer‑3, firewalls y mecanismos específicos de la nube como Security Groups o Network ACLs. Este artículo explica de modo práctico cómo diseñar, implementar, probar y operar de forma segura la segmentación on‑prem y en la nube.

Conceptos básicos, breves y concisos

Antes de abordar la configuración y el despliegue, a continuación una asignación breve y comprensible de los términos más importantes:

• VLAN (Virtual Local Area Network): separación lógica en Layer‑2 (enlace de datos). Las VLANs aíslan dominios de broadcast en puertos de switch; requieren enrutamiento (Layer‑3) para la comunicación inter‑VLAN.
• Firewall: dispositivo o software que permite o deniega tráfico según reglas. Puede ser stateful (con estado) o stateless (sin estado).
• Security Group: constructo en la nube (p. ej. AWS/Azure) para agrupar reglas; por lo general stateful y asociado a instancias.
• Network ACL: conjunto de reglas en la nube o on‑prem que suele operar de forma stateless y actúa a nivel de subred/red.
• Mikrosegmentierung: control fino de conexiones hasta nivel de proceso u host (p. ej. mediante firewall de host, iptables/nftables o políticas eBPF).

Segmentación de red: principios básicos y objetivos

Una buena segmentación sigue objetivos operativos claros: limitar la propagación de ataques, aislar datos sensibles, mejorar la distribución de la carga de red y separar responsabilidades operativas. Los principios son:

• Principio de mínimos privilegios: permitir solo las conexiones estrictamente necesarias.
• Zonificación por confianza: estructurar áreas de red según nivel de confianza (p. ej. DMZ, capa de aplicación, capa de base de datos).
• Registro y monitorización: todos los límites de zona deben registrar de forma trazable.
• Automatización: políticas como código (IaC), pipelines de revisión y automatización de pruebas previenen la deriva y las configuraciones erróneas.

On‑Prem: diseñar y operar VLANs en la práctica

Las VLANs son el método clásico para la segmentación on‑prem. Una VLAN agrupa puertos y constituye un dominio de broadcast propio; el enrutamiento entre VLANs se realiza mediante un router o un switch L3 (Inter‑VLAN‑Routing).

Requisitos y planificación

Requisitos importantes: switches con soporte de trunk (IEEE 802.1Q) para el transporte de VLANs, un plan de direcciones IP coherente, IDs de VLAN y convenciones de nombres documentadas, así como políticas de enrutamiento en el L3‑Gateway. Sin un plan IP ordenado aparece con rapidez solapamiento, gateways mal ubicados o tormentas de broadcast.

Ejemplo: crear una VLAN en un switch (Cisco IOS)

Configuración de un puerto trunk y de un puerto access:

configure terminal
vlan 10
 name VLAN-APP
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
interface GigabitEthernet1/0/2
 switchport mode access
 switchport access vlan 10
end
write memory

Por qué funciona: el trunk transmite varias VLANs entre switches; los puertos access pertenecen a exactamente una VLAN. Cuándo falla: falta de configuración de trunk en el extremo opuesto, native VLANs distintas o problemas de MTU (tener en cuenta voz/etiquetado VLAN).

Linux‑Host como router / interfaz VLAN

Para ubicaciones pequeñas o entornos de prueba, un Linux‑gateway puede manejar interfaces VLAN directamente:

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev eth0.10
ip link set eth0.10 up
sysctl -w net.ipv4.ip_forward=1

Riesgo: límites de rendimiento y falta de soporte de offload por hardware en hosts de commodity. Para cargas en producción se recomiendan switches L3 o routers/firewalls dedicados.

Conceptos de Cloud: Security Groups, NACLs y enrutamiento

En nubes públicas como AWS, Azure o Google Cloud existen otros bloques primitivos. Security Groups (SG) son reglas típicas ligadas a instancias, por lo general stateful. Network ACLs (NACL) operan a nivel de subred y suelen ser stateless, es decir, requieren reglas separadas para entrada/salida.

Stateful vs. stateless — explicación breve

Stateful significa que el firewall recuerda las conexiones (p. ej., una conexión TCP permitida autoriza posteriormente el tráfico de retorno). Stateless trata cada dirección de forma independiente y, por ello, requiere un mantenimiento de reglas más detallado. En AWS las SG son stateful; las NACL son stateless. En Azure las NSGs (Network Security Groups) son stateful.

Ejemplo: crear una Security Group (AWS CLI)

aws ec2 create-security-group --group-name zammad-app-sg --description "Zammad App SG" --vpc-id vpc-123abc
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 5432 --source-group sg-0dbonly

La última regla muestra un patrón importante: permitir el puerto de BD (5432) solo desde la Application‑SG. De este modo se evita el acceso directo desde Internet a las bases de datos.

Despliegue estratégico de firewalls: zonas, reglas, registro (logging)

La segmentación funciona mejor con zonas claras: perímetro/DMZ, capa de aplicación, capa de base de datos, gestión. Las firewalls aplican la política en los puntos de transición entre zonas. Puntos importantes:

• Reglas según la función, no por IP: agrupe servicios, no hosts individuales.
• Default‑Deny: política de perímetro por defecto denegatoria; permitir solo los flujos explícitamente autorizados.
• Restricción de protocolos y puertos: abra solo los protocolos necesarios (p. ej., HTTPS en lugar de HTTP, proxies de aplicación, mTLS).
• Registro y retención: recopile los logs de firewall de forma centralizada (SIEM) para detectar anomalías.

Ejemplo: cadena input mínima de nftables (firewall del host)

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0 ; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input tcp dport 22 ct state new limit rate 10/second accept
nft add rule inet filter input drop

Por qué funciona: estrategia simple de Default‑Deny con permiso para conexiones establecidas y servicios necesarios. Cuándo falla: ausencia de reglas de registro, dejar la consola (SSH) demasiado abierta o colocar reglas en orden incorrecto.

Buenas prácticas: diseño, automatización y operación

Directrices concretas que en los proyectos una y otra vez marcan la diferencia:

1. Etiquetado y convenciones de nombres: Utilice tags consistentes en la nube (p. ej. environment, role, owner) y una estructura de nombres VLAN on‑prem (p. ej. VLAN-APP-10).
2. Policy as Code: Gestionar firewalls y Security Groups mediante IaC (Terraform, ARM, CloudFormation), incluyendo revisión de código y pruebas.
3. Change‑Control: Cada cambio de política pasa por pruebas automatizadas (Connectivity‑Smoke, Regression) y dispone de una opción de rollback.
4. Least‑Privilege und explizite Regeln: No permitir reglas abiertas 0.0.0.0/0 salvo cuando sea estrictamente necesario.
5. Monitoring & Alerts: Alertar sobre anomalías como picos repentinos en el tráfico East‑West o escaneos de puertos inusuales.
6. Dokumentation: Mantener actualizado el IP‑Plan, el mapa de VLAN y la matriz de firewall (¿Quién puede alcanzar a quién?).

Migrations- und Rollout‑Plan: Schritt für Schritt

Al migrar de redes planas a entornos segmentados se recomienda un camino de rollback garantizado. Una secuencia ejemplar:

1. Análisis: Registrar los flujos actuales con NetFlow/sFlow, tcpdump y dependencias de servicios.
2. Diseño: Crear un mapa de zonas y servicios, documentar puertos y endpoints.
3. Desplegar de forma automatizada: Generar plantillas IaC, ejecutar Dry‑Run, revisión y despliegue en staging.
4. Canary: Aplicar la segmentación en un subconjunto reducido y monitorizar.
5. Despliegue en producción: Cutover por fases con monitorización y rollback de emergencia.

Wichtige Testbefehle

Use estos comandos de forma sistemática para comprobar conectividad y reglas:

# Verbindungstest TCP (Netcat)
nc -vz 192.168.10.5 5432

# Paketmitschnitt (z. B. DB‑Traffic)
tcpdump -i eth0 -n 'host 192.168.10.5 and port 5432'

# Firewall‑Rules anzeigen
nft list ruleset

# Route/Next‑Hop prüfen
ip route show

# Traceroute für Pfaddiagnose
traceroute -n 10.0.0.5

# HTTP‑Check
curl -v --connect-timeout 5 https://app.example.local/health

Monitoring, Logging und Drift‑Detection

La segmentación solo es tan buena como su supervisión. Requisitos centrales:

• Flow‑Logging: Active NetFlow/sFlow en los switches y VPC Flow Logs en la nube para analizar el tráfico East‑West.
• Firewall Logs: Enviar logs estructurados (JSON) a un SIEM para permitir correlaciones.
• Drift Detection: Comparar continuamente las configuraciones actuales con el estado IaC (z. B. Terraform plan in CI). Herramientas cloud como AWS Config o Azure Policy pueden notificar cambios no gestionados.

Ejemplo: activar VPC Flow Logs y una consulta sencilla de CloudWatch Logs Insights para direcciones IP de origen inusuales:

# VPC Flow Logs (Kurzbefehls-Beispiel - CLI)
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-123abc --traffic-type ALL --log-group-name /aws/vpc/flowlogs --deliver-logs-permission-arn arn:aws:iam::123456:role/flowlogs-role

# CloudWatch Logs Insights Beispielabfrage
fields @timestamp, srcAddr, dstAddr, action | filter action = 'REJECT' | stats count() by srcAddr | sort @timestamp desc

Performance, MTU und Latenz beachten

La segmentación puede tener efectos colaterales en la latencia y el MTU. Los tramas etiquetadas aumentan el tamaño del paquete; en VPNs u overlay‑networks (z. B. VXLAN) se suman cabeceras. Verifique las configuraciones de MTU a lo largo del trayecto y mida latencia/rendimiento antes y después de los cambios.

Herramientas de medición y comandos de ejemplo:

# MTU prüfen
ip link show dev eth0

# Latenz und Durchsatz messen (iperf3)
iperf3 -c 10.0.0.5 -p 5201 --parallel 4 --time 30

Microsegmentierung, Host‑Firewall und eBPF

Cuando Layer‑2/3 no son suficientes o se requiere operación multicliente, la microsegmentación ayuda: basada en host vía nftables/iptables, basada en agentes (p. ej. agentes específicos por área) o enfoques modernos con eBPF, que aporta filtros de paquetes de alto rendimiento al kernel. Ventaja: control muy granular; desventaja: mayor complejidad y carga operativa.

Complementos operativos y de resolución de problemas específicos para Zammad

Para instalaciones de Zammad, concrete su segmentación según los puntos siguientes:

• Lista de puertos mínimos: Web (80/443), Postgres (5432), Elasticsearch (9200), Redis (6379).
• Aseguramiento de las vías de administración: SSH/Management solo en la zona de gestión, 2FA para cuentas de administrador web y restricciones de IP para los paneles de administración.
• Health‑Checks y playbooks: endpoints de salud sencillos que verifiquen Web, conexiones a la base de datos y la salud de índices de Elasticsearch.

Secuencia de resolución de problemas ante problemas de conectividad:

1. Comprobar firewalls/grupos de seguridad (logs en ACCEPT/REJECT).
2. Probar la ruta de red (traceroute, tcpdump en el host de la aplicación).
3. Revisar registros de la aplicación (Zammad Rails Logs, Postgres Logs, Elasticsearch Logs).
4. Rollback a la versión anterior de Security‑Group/Firewall si se demuestra que la conectividad fue causada por la política.

Ejemplo: fragmento de Terraform para Security Group (Cloud‑Policy as Code)

resource "aws_security_group" "zammad_app" {
  name        = "zammad_app_sg"
  description = "App SG für Zammad"
  vpc_id      = var.vpc_id

  ingress {
    description = "Web"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description     = "DB Access aus App SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.zammad_db.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "zammad_app_sg"
  }
}

Importante: establezca versionado, comprobaciones CI (terraform plan) y aprobaciones automatizadas para garantizar despliegues sin drift.

Runbook operativo y estrategia de retroceso

Un runbook preciso reduce el estrés en un incidente. Puntos clave:

• Comandos de prueba rápida (conectividad, registros, comprobaciones de salud).
• IDs de snapshot/backup y el momento documentados.
• Comando de rollback o playbook de revert IaC, incluyendo responsables y cadena de escalado.
• Plan de comunicaciones: actualizaciones de estado a los equipos afectados y ventanas de mantenimiento.

Lista de verificación antes del inicio en producción

• Plan de IP y mapa de VLAN finalizados y distribuidos al equipo.
• Plantillas IaC creadas, revisión completada, pruebas automatizadas en verde.
• Backup/snapshot creado antes del rollout.
• Monitoring (flujos, registros de firewall) activo y umbrales de alerta establecidos.
• Playbook de rollback documentado y probado.
• Documentación de reglas y responsabilidades disponible.

Conclusión

La segmentación de red es un proceso continuo, no un proyecto de una sola vez. El mejor enfoque combina principios de diseño sólidos (Least‑Privilege, Trust Zoning), automatización (Policy as Code) y un procedimiento claro de pruebas y rollback. Los VLANs on‑prem y las Cloud‑Security‑Groups a menudo se complementan y, en la práctica, deben entenderse como un conjunto de políticas integrado. En soluciones digitales empresariales cercanas al proceso, como Zammad, una segmentación limpia resulta rentable: menor superficie de ataque, responsabilidades claras y despliegues reproducibles. Comience en pequeño (Canary), mida los flujos y automatice la distribución de políticas — así los proyectos de segmentación se vuelven manejables y sostenibles.