DMZ: la zona neutral entre internet y tu red interna que decide si un ataque exitoso es incidente o catástrofe.

Una DMZ aísla los servicios expuestos a internet (web, correo, VPN) del resto de la infraestructura corporativa. Si un atacante compromete un servicio en la DMZ, no puede saltar directamente a los servidores internos. Es un patrón de arquitectura de red con 30 años de historia que sigue siendo crítico.

Adrián Recio
Comunicaciones
7 min de lectura
Junio 2026
Ver firewall perimetral
Una DMZ (Demilitarized Zone, Zona Desmilitarizada) es un segmento de red que aísla los servicios que necesitan ser accesibles desde internet del resto de la infraestructura corporativa. Si un atacante consigue comprometer un servidor web en la DMZ, no llega automáticamente al ERP, al servidor de archivos o a las bases de datos.

Qué es exactamente una DMZ

Una DMZ es una red intermedia entre la red interna corporativa (LAN) y la red exterior (internet). Los servidores que necesitan ser accesibles desde internet (web, correo entrante, VPN endpoint, FTP público) viven en la DMZ. La idea base: si comprometen un servidor de la DMZ, todavía hay un firewall entre el atacante y la red interna.

Topológicamente, la DMZ está controlada por uno o dos firewalls que filtran el tráfico entre tres zonas: internet, DMZ y LAN interna. Los flujos están estrictamente definidos: internet puede acceder a la DMZ en puertos específicos, la DMZ no puede iniciar conexiones a la LAN interna libremente.

El nombre viene de la analogía militar — zonas neutrales entre dos territorios en conflicto. En redes, el "conflicto" es entre la confianza limitada de internet y la confianza alta de la red interna.

Por qué la DMZ sigue siendo necesaria

Algunos argumentan que con cloud y arquitecturas modernas la DMZ ya no es relevante. La realidad es la opuesta: el patrón sigue siendo crítico, solo que se aplica de forma distinta en cloud (subnets públicas vs privadas, security groups).

01 Servicios expuestos a internet seguirán siendo objetivo de ataque, sin importar la arquitectura.
02 Sin segmentación, un servidor comprometido es un punto de pivote para alcanzar el resto de la red.
03 Cumplimiento (PCI DSS, ENS, NIS2) exige segmentación de servicios expuestos. La DMZ es la implementación más común y aceptada.
04 Defensa en profundidad — varias capas de control limitan el impacto cuando una falla.

Las 2 topologías clásicas de DMZ

DMZ con un solo firewall (3-legged)

Un firewall con 3 interfaces: internet, DMZ, LAN. Más simple y barato. Adecuado para empresas medianas. Punto único de fallo en el firewall.

DMZ con dos firewalls (back-to-back)

Firewall externo entre internet y DMZ; firewall interno entre DMZ y LAN. Más caro y complejo pero mayor seguridad. Idealmente los firewalls son de fabricantes distintos para evitar vulnerabilidades comunes.

¿Cómo está realmente segmentada tu red corporativa?

Auditamos la arquitectura de red, identificamos servicios expuestos sin DMZ correcta y proponemos arquitectura objetivo.

Solicitar auditoría de red

Qué servicios deben vivir en la DMZ

01 Servidores web públicos (corporativo, e-commerce, portales clientes).
02 Servidores de correo entrante (con gateway antispam delante si aplica).
03 Concentrador VPN para acceso remoto.
04 Servidores DNS públicos (autoritativos).
05 Proxy reverso para aplicaciones internas accesibles desde fuera.
06 Puerta de enlace API expuesta a partners o clientes.
07 FTP/SFTP público (si todavía es necesario).

DMZ moderna: cómo se aplica el patrón en cloud

En AWS, Azure o Google Cloud, la "DMZ" se traduce a subnets públicas y privadas con tablas de routing y security groups. El concepto es el mismo: aislar lo expuesto a internet del resto.

Patrón típico: subnets públicas con balanceadores y NAT gateways, subnets privadas con servidores de aplicación y BBDD, comunicación estricta entre ellas mediante security groups. Mismo principio de defensa en profundidad.

Para arquitecturas Kubernetes o microservicios, el patrón se aplica con ingress controllers en la "DMZ lógica" y servicios internos en subnets privadas. Service mesh para gobernar comunicación interna.

Errores comunes al implementar DMZ

Permitir tráfico desde DMZ hacia LAN sin restricciones

Anula completamente el propósito. La DMZ debe poder iniciar conexiones muy limitadas a la LAN (solo lo estrictamente necesario, en puertos específicos).

Dejar servicios internos en la DMZ por comodidad

A veces se mete el ERP en DMZ para que esté accesible. Es la peor decisión posible — si la DMZ cae, también cae el ERP.

No segmentar dentro de la DMZ

Si la DMZ tiene 10 servicios, todos en la misma red, un servicio comprometido alcanza a los otros 9. Sub-segmentación dentro de la DMZ es buena práctica.

No mantener actualizados los servidores de la DMZ

Son los más expuestos. Si no están al día de parches, el riesgo se multiplica.

¿Te ayudamos a diseñar o rediseñar tu DMZ?

Diseño de arquitectura de red, configuración de firewall, segmentación por VLAN y políticas estrictas. Llave en mano o consultoría.

Solicitar consultoría de arquitectura

Si tienes servicios expuestos a internet sin DMZ, no es cuestión de si te atacarán — es cuándo y con cuánto daño.

La DMZ es un patrón maduro y probado. Quien la implementa bien limita el impacto de los ataques inevitables. Quien no la tiene apuesta a que su perímetro sea perfecto — y nunca lo es.

En AO Data Cloud diseñamos arquitecturas de firewall perimetral con DMZ correctamente segmentada y redes corporativas defendibles. Si tu red actual mezcla servicios internos con expuestos a internet, una revisión inicial identifica los riesgos prioritarios.