Los rendimientos decrecientes de apilar capas de DMZ

Tesis. Agregar más capas de DMZ, más zonas, más firewalls y más saltos de inspección produce rendimientos de seguridad decrecientes y costos operativos crecientes. Más allá de cierto punto, cada firewall adicional bloquea menos ataques y más trabajo legítimo. El objetivo arquitectónico debe ser controles en capas, no subredes en capas. El verdadero reto es reconocer cuándo una zona ya no justifica su costo y tener el criterio para quitarla.

---

Resumen ejecutivo

Una DMZ es un segmento de red ubicado entre un firewall externo y uno interno. También es uno de los patrones más confiables de la seguridad empresarial. NIST la ha formalizado desde principios de los años 2000; prácticamente todo regulador importante espera ver algo parecido. Y para una clase clara de cargas de trabajo, el patrón todavía justifica su costo.

La pregunta que plantea este artículo no es si el patrón DMZ es válido. Es si apilar más capas sigue siendo la respuesta correcta cuando un entorno crece, se moderniza o se mueve a la nube. La evidencia de la última década apunta en otra dirección. El Data Breach Investigations Report de Verizon, la reformulación de las fronteras de confianza en NIST SP 800-207 y la transición pública de Google hacia BeyondCorp sugieren lo mismo: el beneficio marginal de agregar capas DMZ se aplana rápido. El costo operativo, mientras tanto, sigue subiendo.

El peligro no es tener un firewall de más. El peligro es terminar con una topología que ya nadie puede explicar sin abrir cuatro diagramas, convocar a tres equipos y descubrir que producción tomó otro camino hace seis meses.

Este texto defiende una posición más afilada que la habitual en los debates de nube contra on-prem:

• Los controles en capas, como protección de borde, segmentación, identidad, política de carga de trabajo y observabilidad, siguen siendo fundamentales.
• Las subredes en capas reforzadas por firewalls tipo appliance son una implementación de esos controles. Agregar más capas deja de ser gratis, luego deja de ser neutral y, finalmente, se vuelve netamente negativo.
• La pregunta arquitectónica correcta ya no es “¿dónde va la DMZ?” sino “¿dónde tienen que vivir realmente las fronteras de confianza, los puntos de inspección y la aplicación de política para esta carga de trabajo?”

El recorrido es este: qué es realmente una DMZ en capas, por qué se volvió el patrón por defecto, cómo funciona el argumento de los rendimientos decrecientes, dónde aparece el antipatrón con capas de más, cuándo el patrón sigue justificando su costo, qué hacen mejor los controles modernos, cinco arquitecturas de referencia, una matriz de decisión, tres notas de caso y una lista práctica para arquitectos. Las fuentes quedan al final.

---

Qué significa realmente “DMZ en capas”

En sentido estricto, una DMZ (“zona desmilitarizada”) es un segmento de red entre la red interna de una organización y una red no confiable, normalmente internet. Su propósito es simple: exponer lo mínimo necesario y mantener la red interna detrás de una frontera inspeccionada. NIST SP 800-41 Rev. 1 (Scarfone & Hoffman, 2009) define este patrón explícitamente y lo recomienda como línea base para organizaciones que exponen servicios a internet ³.

Una DMZ en capas extiende el patrón introduciendo zonas adicionales, normalmente llamadas DMZ Externa, DMZ Interna (o “DMZ trasera”) e Interna / Intranet, separadas por firewalls adicionales. La variante empresarial más desplegada es de cuatro zonas:

• Internet No confiable. Usuarios externos, socios, atacantes, bots.
• DMZ Externa Servicios de cara a internet: WAFs, proxies inversos, servidores web públicos, balanceadores de borde, front-ends públicos de API. La única zona autorizada a recibir tráfico entrante de internet.
• DMZ Interna Servicios de aplicación e integración: servidores de aplicación, APIs internas, brokers de integración, colas de mensajes. Alcanzables desde la DMZ Externa por un conjunto pequeño y explícito de puertos, pero nunca directamente desde internet.
• Interna / Intranet Capa de datos, identidad, aplicaciones internas, red corporativa. Solo es alcanzable desde la DMZ Interna por rutas estrictamente delimitadas.

Algunas organizaciones se detienen en una DMZ, el patrón original “entre dos firewalls”. Otras la extienden a tres, cuatro o más capas para gestión, integraciones de socios, servicios, gateways de datos y fronteras de cumplimiento. Los entornos de defensa y gobierno a menudo agregan más capas para coincidir con etiquetas de confianza por clasificación.

El principio detrás de cada variante es el mismo: ubicar inspección con estado entre cada frontera de confianza significativa y forzar el tráfico norte-sur a atravesarla.

Algunas organizaciones se detienen en una DMZ; otras la extienden más. El corte Externa/Interna es el patrón empresarial más común, y es la línea base que usa este artículo.

---

Por qué se volvió el patrón por defecto de la industria

Tres fuerzas convirtieron a las DMZ en capas en el patrón empresarial por defecto durante casi dos décadas.

1. El modelo de amenaza encajaba. Hasta principios de los años 2000, la amenaza externa predominante era de red: escaneos, gusanos, intentos de explotación y fuerza bruta contra puertos expuestos. NIST SP 800-41 codificó el firewalling basado en zonas como mitigación probada. La mayoría de las arquitecturas empresariales de esa época, como núcleos bancarios, retail, telco y utilities, ya tenían un eje claro de tráfico norte-sur que defender ³.

2. La regulación lo hizo auditable. PCI-DSS, HIPAA, NERC CIP y varios regímenes nacionales bancarios y de telecomunicaciones han esperado desde hace mucho alguna forma de segmentación de red entre los datos sensibles y el resto de la red. PCI DSS v4.0 (PCI SSC, marzo 2022) sigue tratando la segmentación de red como estrategia primaria de reducción de alcance ⁷. Una DMZ de dos o tres zonas es una manera limpia de demostrarlo ante un auditor: dos firewalls, dos conjuntos de reglas, dos ventanas de cambio.

3. El modelo operativo ya existía. Las redes on-prem tenían dueños: un equipo de redes, un equipo de seguridad de perímetro, un equipo de firewalls. La DMZ en capas encajaba limpiamente con esa estructura de propiedad. Agregar más zonas parecía agregar más rigor. En el mundo on-prem, con topologías estables y cadencias lentas de cambio, a menudo lo era.

Cuando una carga de trabajo combina amenazas predominantemente de red, expectativas del regulador, topología on-prem estable y un equipo de red dedicado, la DMZ en capas sigue siendo una opción por defecto razonable. El argumento de este artículo no es contra el patrón. Es contra tratar “más capas” como sinónimo de “más seguridad” cuando una o más de esas condiciones ya no se sostienen.

---

La matemática de los rendimientos decrecientes

Si una sola DMZ eleva el costo de comprometer de X a X + \delta_1, y una segunda capa lo eleva a X + \delta_1 + \delta_2, la pregunta arquitectónica no es si la segunda capa agrega algo. Casi siempre agrega algo. La pregunta es si \delta_2 es suficientemente grande para justificar la fricción que introduce y si importa frente a las amenazas reales.

Tres líneas de evidencia sugieren que \delta_2, \delta_3 y las capas sucesivas se encogen rápidamente.

1. Los vectores de ataque empíricos no atraviesan el tercer firewall

El Data Breach Investigations Report 2026 de Verizon señala que el 31% de las brechas ahora empiezan con la explotación de vulnerabilidades de software, por encima de las credenciales robadas como vector principal de acceso inicial, y que el 48% involucra ransomware ¹. A lo largo de informes anteriores, los ataques a aplicaciones web, el compromiso de cadena de suministro y el abuso de credenciales han dominado de forma consistente las categorías de acceso inicial. Pocos de esos caminos se benefician del tercer o cuarto firewall en una DMZ en capas:

• Una inyección SQL a través de una capa web expuesta no se preocupa por cuántos firewalls hay detrás. Tiene éxito en la capa de aplicación, no en la capa de red.
• Una librería de proveedor comprometida no tiene noción de fronteras de subred. Viaja con la aplicación hacia la zona donde la aplicación corra.
• Una credencial válida usada por un atacante atraviesa la pila de firewalls igual que la del usuario legítimo, porque para el firewall es el usuario legítimo.

Una DMZ de dos zonas que filtra el ruido obvio y expone solo los servicios necesarios ya atiende a la mayor parte del riesgo de capa de red. Una tercera o cuarta zona filtra principalmente tráfico de fuentes internas que el atacante, por hipótesis, ya alcanzó.

2. La identidad ha desplazado a la ubicación como frontera de confianza significativa

NIST SP 800-207, Zero Trust Architecture (Rose, Borchert, Mitchell, Connelly, agosto 2020), reformuló la seguridad empresarial alrededor de una premisa explícita: “no se otorga confianza implícita a activos o cuentas de usuario basada únicamente en su ubicación física o de red” ². La publicación no es anti-firewall. Es anti-“posición de red igual a confianza”.

El artículo de BeyondCorp de Google (Ward & Beyer, ;login:, diciembre 2014) dijo lo mismo seis años antes y desde dentro de un proveedor de hiperescala:

“Prácticamente toda empresa hoy usa firewalls para imponer seguridad de perímetro. Sin embargo, este modelo de seguridad es problemático porque, cuando ese perímetro se rompe, un atacante tiene acceso relativamente fácil a la intranet privilegiada de la empresa. A medida que las empresas adoptan tecnologías móviles y de nube, el perímetro se vuelve cada vez más difícil de imponer.” ⁵

De ahí se desprenden dos consecuencias para el diseño de DMZ en capas. Primera: una carga de trabajo que autentica cada petición contra una identidad real (identidad de carga de trabajo, OIDC, mTLS) no necesita una zona de red adicional para hacer el mismo trabajo con menos precisión. Segunda: un atacante con una credencial válida no se frena por el cuarto firewall más de lo que se frena por el primero.

3. La complejidad misma agranda la superficie de ataque

La formulación recurrente de Bruce Schneier, “la complejidad es el peor enemigo de la seguridad”, se ha confirmado a lo largo de dos décadas de datos de incidentes ⁸. NIST SP 800-160 Vol. 2 Rev. 1 (Ross et al., diciembre 2021) nombra la reducción de complejidad como objetivo fundacional de ciber-resiliencia, sobre la base de que los sistemas demasiado complejos para razonar sobre ellos también son demasiado complejos para defenderlos ⁴.

Cada capa DMZ adicional introduce:

• otro conjunto de reglas de firewall, con su propio drift a lo largo del tiempo,
• otra superficie de gestión de cambios y otra frontera entre equipos,
• otra preocupación de escalamiento y planificación de capacidad,
• otro dominio potencial de fallo en la ruta crítica de cada petición.

La afirmación simultánea de que “esta capa adicional reduce aún más la probabilidad de brecha” y de que “esta capa adicional agrega latencia de cambio de reglas, costo de throughput y fricción operativa” se puede comprobar. La primera rara vez se mide. La segunda se siente en cada release.

Lo que los datos no muestran

Es difícil encontrar evidencia empírica de que las organizaciones que operan cuatro o cinco zonas DMZ en capas experimenten tasas de brecha materialmente menores que pares que operan dos zonas bien gestionadas, controlando por sector y madurez. Lo que los datos de brechas sí muestran es que los atacantes normalmente explotan un solo eslabón débil: servicio expuesto, credencial válida, componente vulnerable o inserción en cadena de suministro. No suelen derrotar sistemáticamente controles de red sucesivos. Apilar más controles de red más allá de cierto punto no atiende los modos de fallo dominantes; solo atiende versiones más exigentes de modos de fallo que la segunda capa ya cubría en buena medida.

---

El antipatrón de la DMZ con capas de más

Un modo de fallo específico aparece repetidamente en empresas maduras que han estado agregando zonas durante años sin quitar ninguna:

Los síntomas se reconocen rápido:

• Apilamiento de latencia Cada salto de inspección adicional suma milisegundos y, más importante, otro modo de fallo. Los presupuestos de latencia pensados para APIs sincrónicas desaparecen antes de llegar a la carga de trabajo.
• Combinatoria de control de cambios Una nueva ruta de aplicación requiere reglas de firewall en cinco lugares, de tres equipos, cada uno con una ventana de cambio diferente. El cambio de red se mide en semanas; el ritmo del equipo de entrega se mide en días. Esa discordancia es donde nace la infraestructura sombra.
• Rutas sombra Bajo presión de entrega, los equipos encuentran formas de rodear la ruta oficial: un túnel “temporal” desde una VM de desarrollo, una excepción de servicio que se vuelve permanente, una integración de socio que evade tres de los cuatro firewalls. Cuando existe una ruta sombra, la topología oficial deja de describir la verdadera superficie de ataque.
• Falsa tranquilidad de auditoría El diagrama luce riguroso en una revisión de controles. El grafo de tráfico real en producción, visible en logs de flujo si alguien se toma el trabajo de revisar, no coincide con el diagrama.
• Visibilidad de operador decreciente Mientras más dispositivos haya en la ruta, más difícil es reconstruir qué pasó cuando algo se rompe o se explota. El análisis forense a través de cinco puntos de inspección y tres equipos es significativamente más difícil que a través de dos.
• Riesgo de concentración en appliances compartidos Cuando todas las rutas atraviesan el mismo par NVA o de firewalls de hub, ese par se vuelve punto único de fallo para toda la infraestructura. La capacidad de inspección se convierte en restricción de entrega en horas pico.

Ninguno de estos modos de fallo es hipotético. Son la razón por la que muchas empresas maduras terminan consolidando: pasan de “muchas DMZ” a “menos zonas, mejor controladas”, con identidad más fuerte y política a nivel de carga de trabajo asumiendo el peso adicional.

La lectura honesta incomoda: muchas infraestructuras DMZ con capas de más eran defendibles cuando cada capa se agregó, pero dejaron de serlo en conjunto. Ninguna decisión individual estuvo mal; faltó el hábito de preguntar periódicamente si las decisiones anteriores seguían justificando su costo.

---

Dónde las DMZ en capas siguen justificando su costo

El argumento de los rendimientos decrecientes no es un ataque contra cualquier DMZ en capas. Hay entornos donde las premisas originales siguen siendo válidas y el patrón sigue siendo la opción más defendible:

• Cargas de trabajo altamente reguladas Los auditores esperan fronteras de red explícitas e inspeccionables, algo típico de algunas interpretaciones de PCI-DSS Req. 1, la Security Rule de HIPAA, NERC CIP-005, FedRAMP High y ciertos regímenes bancarios nacionales.
• Aplicaciones legadas La aplicación asume una red interna plana y confiable, y no tolera proxies con identidad, mTLS o política por carga de trabajo sin cambios invasivos.
• Integraciones híbridas y de mainframe El sistema de registro no puede moverse y debe alcanzarse por una ruta on-prem controlada e inspeccionada.
• Requisitos fijos de inspección Inspección de TLS exigida por política, DLP en el perímetro, filtrado de egreso atado a feeds de threat-intel, controles de flujo de datos clasificados.
• Modelos operativos centralizados de red y seguridad Un equipo dedicado es dueño de los cables y puede operarlos a la cadencia a la que el negocio entrega software.
• Aislamiento estricto y demostrable Procesamiento clasificado, entornos multi-nivel seguros de defensa, o plataformas con aislamiento por inquilino donde la separación a nivel de subred es contractualmente requerida.
• Arquitecturas de transición durante migración a nube Una DMZ hub-and-spoke en la nube replica temporalmente el patrón on-prem el tiempo necesario para migrar cargas de trabajo sin reescribir su modelo de seguridad.

En estos casos, “DMZ en capas” no es nostalgia. Es la manera defendible más barata de cumplir una restricción real.

---

Dónde se han vuelto puro impuesto

El mismo patrón empieza a fallar cuando esas premisas ya no se sostienen:

• Aplicaciones nativas de nube Aplicaciones construidas sobre servicios administrados; forzar todo el tráfico a través de un punto central de inspección rompe el modelo de servicio o remueve las protecciones nativas del proveedor.
• Plataformas de microservicios y Kubernetes El tráfico este-oeste domina, y la política con identidad a nivel de carga de trabajo es más expresiva que las reglas por subred.
• Cargas de trabajo serverless Las cargas no tienen una posición de red durable que defender; la gobernanza pasa por IAM y política de origen de evento.
• Plataformas PaaS y de datos administradas Los endpoints privados resuelven la alcanzabilidad; la superficie de control significativa es la identidad y la política de recurso, no una subred DMZ.
• Front-ends globalmente distribuidos El lugar correcto para absorber tráfico de ataque es el borde del proveedor (CDN/WAF/anti-DDoS), no un par de firewalls regional.
• Entornos de entrega de alta cadencia Los tickets de cambio de firewall se vuelven el cuello de botella, y silenciosamente aparecen rutas sombra de ingreso para rodearlos.
• Inspección central forzada La latencia, los hairpins, los puntos únicos de fallo o los costos de licenciamiento crecen desproporcionados al riesgo residual removido.

El modo de fallo aquí no es inseguridad. Es pagar por inspección que la carga de trabajo ya no justifica. El patrón se ve riguroso en un diagrama, pero ya no corresponde al lugar donde vive realmente la superficie de ataque.

---

Qué reemplazan realmente los controles modernos

El caso para menos capas DMZ depende de tener algo que poner en su lugar. Varias categorías de control han madurado lo suficiente para asumir parte del trabajo que antes recaía casi por completo sobre firewalls de perímetro y subredes DMZ:

• Protección de borde a escala CDN + WAF + anti-DDoS en los bordes de proveedor (Akamai, Cloudflare, Fastly, AWS WAF, Azure Front Door, Google Cloud Armor, Imperva y otros) absorben la mayoría de los ataques volumétricos y estilo OWASP lejos del origen, con capacidad global que los appliances on-prem no pueden igualar económicamente.
• Balanceadores de carga y API gateways nativos de nube AWS ALB/NLB, Azure Application Gateway y Front Door, y Google Cloud Load Balancing ofrecen puntos de entrada L4/L7 administrados con integración nativa de TLS, identidad y WAF.
• Conectividad privada a servicios administrados AWS PrivateLink, Azure Private Endpoint, GCP Private Service Connect y VPC Service Controls sacan los servicios administrados del internet público sin forzarlos a pasar por una subred DMZ.
• Primitivos de microsegmentación Security groups, NSGs, NACLs y tablas de rutas proveen política de red por carga de trabajo sin appliances dedicados. Las herramientas CSPM/CNAPP/CWPP extienden esa visibilidad al comportamiento de la carga.
• Firewalls nativos de nube y NVAs AWS Network Firewall, Azure Firewall, GCP Cloud NGFW y NVAs de terceros en VPCs/VNets de hub, usados selectivamente en vez de universalmente.
• Política a nivel Kubernetes Ingress controllers, Gateway API, NetworkPolicy y controladores de admisión imponen reglas norte-sur y este-oeste cerca de la carga de trabajo.
• Service mesh mTLS, autorización ligada a identidad y política L7 entre servicios, independientemente de la posición de red.
• Zero Trust y acceso con conciencia de identidad Decisiones de acceso por petición y por identidad para aplicaciones internas, formalizadas para las agencias federales de EE. UU. en NIST SP 800-207 ² y con un camino graduado de adopción en el Zero Trust Maturity Model v2.0 de CISA (abril 2023) ⁶.
• Detección y respuesta nativas de nube CSPM, CNAPP, CWPP, logs de flujo, logs de auditoría y pipelines SIEM administrados aportan visibilidad que la DMZ clásica no proveía por sí sola.

Ninguno de estos elimina los controles de red. Los redistribuyen: algunos pasan al borde, otros a la carga de trabajo y otros a la identidad. Así, ningún cuello de botella tiene que cargar solo con todo el peso, y ninguna zona tiene que multiplicarse solo porque algo necesita más protección.

---

Arquitecturas de referencia

Cinco formas de referencia que cubren la mayoría del territorio. Ninguna es universalmente correcta; cada una es una respuesta razonable a una pregunta diferente.

Escenario 1: DMZ en capas canónica

El caso de referencia contra el cual el resto del artículo se compara. Internet → DMZ Externa → DMZ Interna → Interna, con tres firewalls y un mapeo estable entre componentes de aplicación y zonas de red. Defendible cuando siguen sosteniéndose las condiciones que hicieron dominante el patrón: expectativas del regulador, topología on-prem y equipo de red dedicado. Ver el diagrama en Qué significa realmente “DMZ en capas” más arriba.

Escenario 2: el antipatrón con capas de más

La forma que produce la mayoría de las fallas de DMZ con capas de más: cinco o seis zonas con cinco firewalls, acumuladas a lo largo de años, poseídas por múltiples equipos, sin que se haya quitado ninguna zona. A menudo defendible en el momento de agregar cada capa; rara vez defendible en conjunto. Ver el diagrama en El antipatrón de la DMZ con capas de más más arriba.

Escenario 3: patrón de borde nativo de la nube

Una carga de trabajo web o de API pública que se ejecuta sobre servicios administrados, con el borde, el balanceo y el plano de datos provistos por la plataforma de nube.

La confianza se aplica en el borde (WAF, bot, anti-DDoS), en el balanceador (autenticación, ruteo, TLS), en la carga de trabajo (autorización, validación de entrada) y en los servicios administrados (endpoints privados, política de recurso, IAM). La posición de red es una señal entre varias, no la señal principal. No hay una DMZ tradicional en este cuadro, y los controles que ella habría provisto siguen presentes, solo que redistribuidos.

Escenario 4: empresa híbrida (hub-and-spoke con inspección)

Una empresa regulada que ejecuta cargas en la nube y debe conectarlas con sistemas de registro on-prem, con inspección central por cumplimiento.

Aquí el patrón de DMZ en capas se reproduce deliberadamente en primitivos de nube. La inspección vive en un hub, los spokes son zonas de aplicación, y la integración on-prem usa los circuitos privados existentes. Esta suele ser la forma transicional correcta y también puede ser una forma defendible de largo plazo para infraestructuras reguladas. El costo es real: ancho de banda a través de la inspección, escalamiento de NVA, riesgo de concentración en un solo par y propiedad operativa del hub. El criterio es el mismo que on-prem: agregar zonas de hub solo cuando previenen un compromiso específico que las zonas existentes no previenen.

Escenario 5: patrón orientado a Kubernetes

Un equipo de plataforma que opera Kubernetes multi-tenant con servicios de datos administrados detrás.

La separación clásica de subredes web/app/data no es lo que protege a esta carga de trabajo. Los controles significativos son el WAF y el balanceador en el borde, el límite de ingress y NetworkPolicy en el clúster, mTLS y autorización en el mesh, identidad de carga de trabajo hacia servicios administrados, y observabilidad en tiempo de ejecución. Intentar enrutar cada llamada pod-a-pod por un firewall central adicional normalmente compra poco y cuesta mucho.

---

Matriz de decisión

Esta es una comparación cualitativa. Las calificaciones son deliberadamente gruesas: Bajo / Medio / Alto. La respuesta exacta depende de la carga de trabajo, del regulador y del modelo operativo. La matriz trata al antipatrón con capas de más como su propia fila para que el costo no quede escondido.

Dos patrones destacan:

• La DMZ con capas de más es la única fila donde la fortaleza de seguridad agregada es solo en el papel. Cuesta más en todas las demás dimensiones sin reducir de forma medible la probabilidad de brecha más allá de la forma canónica de dos o tres zonas.
• Zero Trust suele ser un complemento de una de las otras opciones, no un reemplazo. Cambia cómo se decide el acceso, no dónde se ejecutan las cargas de trabajo.

---

Notas de caso: tres ejemplos públicos

Estas no son historias para decir “te pillé”. Son recordatorios de que los modos de fallo dominantes en la seguridad empresarial moderna rara vez son los que resuelve una pila DMZ más profunda.

Capital One (2019)

Una WAF mal configurada permitió un server-side request forgery (SSRF) contra los metadatos de instancia EC2, exponiendo credenciales de un rol IAM con privilegios excesivos; el atacante exfiltró aproximadamente 100 millones de registros desde S3 ⁹. Capital One operaba múltiples zonas de red y capas de inspección. El compromiso avanzó por IAM y una aplicación expuesta, no por un firewall faltante.

Lección neta: el alcance de identidad y la política de recurso eran las restricciones vinculantes. Otra zona DMZ no habría cambiado el resultado.

SolarWinds Orion (2020)

Un compromiso de cadena de suministro de un producto privilegiado de gestión de TI alcanzó a miles de organizaciones, incluyendo algunas con DMZ en capas maduras, porque la carga maliciosa llegó por un canal de actualización confiable y se ejecutó con los privilegios de un componente interno confiable ¹⁰.

Lección neta: una DMZ en capas no restringe a un componente confiable ya dentro de ella. Lo que sí ayuda es la validación de cadena de suministro de software, el control de egreso y la detección por comportamiento.

MOVEit Transfer (2023)

Una vulnerabilidad de inyección SQL en un producto administrado de transferencia de archivos expuesto a internet (CVE-2023-34362) fue explotada en masa por el grupo de ransomware Cl0p, afectando a miles de organizaciones ¹¹. La mayoría de las víctimas tenían una DMZ. El componente vulnerable estaba, correctamente, dentro de ella.

Lección neta: la profundidad de la pila DMZ es independiente de la vulnerabilidad del software expuesto a internet. El inventario de servicios expuestos, la cadencia de parches y el ajuste del WAF importan más que contar zonas.

Cada caso tiene muchos factores contribuyentes. El punto no es que las DMZ causaran estas brechas; no lo hicieron. El punto es que agregar más capas DMZ no las habría prevenido. Las inversiones que sí habrían ayudado estaban en otro lado: IAM acotado, validación de cadena de suministro, inventario de servicios expuestos, cadencia de parches y detección por comportamiento.

---

Guía práctica para arquitectos

Una lista para elegir la profundidad de la DMZ con intención:

1. Parte de la carga de trabajo, no del diagrama de red ¿Qué expone esta carga, a quién, sobre qué protocolo, con qué datos?
2. Nombra el modelo de amenaza en voz alta Atacante drive-by, abuso de credenciales, cadena de suministro, insider, movimiento lateral y exfiltración no son el mismo problema y no se resuelven con el mismo control.
3. Separa “controles en capas” de “subredes en capas” Decide qué controles son requeridos; elige la implementación más barata que los entregue.
4. Dale a la identidad el peso que puede cargar La identidad de carga de trabajo, IAM y mTLS a menudo hacen más que otro salto de firewall, y sobreviven la efimeralidad.
5. Usa el borde del proveedor para lo que es bueno CDN/WAF/anti-DDoS en el borde suele ser más barato, más rápido y más actual que un equivalente autoadministrado en el origen.
6. Reserva la inspección central para tráfico que realmente la necesita Filtrado de egreso, inspección de TLS exigida por política y rutas norte-sur reguladas justifican un hub. La cháchara este-oeste pod-a-pod usualmente no.
7. Haz del cumplimiento un input, no una excusa Pregunta al auditor qué evidencia espera, no si una topología específica es aceptable. El conjunto de topologías aceptables suele ser más amplio de lo que parece.
8. Empareja el patrón al modelo operativo Un patrón estilo DMZ necesita un equipo que pueda operar firewalls a la cadencia a la que el negocio entrega software. Si ese equipo no existe, el patrón se evade en la práctica.
9. Diseña para radio de impacto, no solo para perímetro Asume que una capa fallará. ¿Qué previene realmente la siguiente capa?
10. Escribe el rollback Cualquier patrón que no pueda revertirse parcialmente cuando rompe producción es demasiado rígido para una cadencia operativa de nube.
11. Audita la topología contra el grafo real de tráfico Usa logs de flujo. Si el grafo en vivo no coincide con el diagrama, el diagrama es la fuente de verdad equivocada.
12. Quita zonas, no solo las agregues Cada nueva zona implica una revisión periódica de si las zonas existentes siguen justificando su costo. La mayoría de las infraestructuras “con capas de más” llegaron ahí por nunca quitar.

Preguntas a hacer antes de agregar otra zona DMZ

• ¿Qué amenaza específica reduce esta zona que las zonas existentes no reducen?
• ¿Pueden la identidad, la política de carga de trabajo o los controles de borde entregar la misma reducción más barato?
• ¿Quién es dueño de la nueva zona, en operaciones y en gestión de cambios? ¿Ese equipo está financiado?
• ¿Cuál es la latencia, el throughput y el costo en dólares del nuevo salto de inspección en carga pico?
• ¿Cómo sabrá el siguiente arquitecto, en dos años, para qué es esta zona?
• Si la nueva zona desapareciera mañana, ¿qué compromiso se vuelve plausible que no era plausible ayer? Si la respuesta es “ninguno que pueda nombrar con precisión”, la zona compra tranquilidad de auditoría, no seguridad real.

---

Respuesta final: ¿sigue siendo relevante una DMZ en capas?

Sí, pero de forma acotada. Como principio de diseño de seguridad, los controles en capas siguen siendo fundamentales. Como patrón de implementación, una DMZ canónica de dos o tres zonas, internet, DMZ externa e interna, con firewalls con estado entre ellas, sigue teniendo valor claro para muchas cargas de trabajo on-prem e híbridas, y para entornos regulados donde la historia de auditoría es parte de la arquitectura.

Como patrón apilado en profundidad, vale menos de lo que se suele reclamar. Pasar de dos zonas a cuatro o más no reduce de forma confiable la probabilidad de brecha frente a las amenazas que dominan los datos de hoy; sí aumenta de forma confiable el costo operativo, el tiempo de entrega y la complejidad. Pasado cierto punto, más capas compran tranquilidad de diagrama, no seguridad.

El planteamiento honesto para arquitectos es este: dejar de preguntar dónde va la DMZ y empezar a preguntar dónde tienen que vivir realmente las fronteras de confianza, los puntos de inspección y la aplicación de política para esta carga de trabajo, este modelo de amenaza, este regulador y este modelo operativo. A veces la respuesta seguirá siendo una DMZ en capas. A veces será una forma distinta que entrega los mismos controles a menor costo. La madurez está en elegir con intención y en quitar lo que ya no defiende nada.

Lo que se lleva el arquitecto

• La DMZ en capas es un patrón, no una ley. Conserva el principio; elige la profundidad con criterio.
• Los controles en capas, como borde, red, identidad, carga de trabajo, datos y observabilidad, son la idea que permanece. Las subredes en capas son una forma de aterrizarlos.
• Cada nueva zona después de la segunda compra menos seguridad que la anterior y cuesta más que la anterior. Mide ambos lados.
• La identidad al estilo BeyondCorp, la microsegmentación, mTLS y los controles de borde administrado no reemplazan el pensamiento de seguridad. Son lugares nuevos donde ponerlo.
• Si no puedes nombrar el compromiso específico que una nueva zona previene, todavía no necesitas la nueva zona.

---

Notas de fuentes

• Verizon, 2026 Data Breach Investigations Report. Verizon Business, 2026. verizon.com/business/resources/reports/dbir. ¹
• NIST SP 800-207, Zero Trust Architecture. Rose, S., Borchert, O., Mitchell, S., Connelly, S. National Institute of Standards and Technology, agosto 2020. doi.org/10.6028/NIST.SP.800-207. ²
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy. Scarfone, K., Hoffman, P. National Institute of Standards and Technology, septiembre 2009. doi.org/10.6028/NIST.SP.800-41r1. ³
• NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. Ross, R., et al. National Institute of Standards and Technology, diciembre 2021. ⁴
• Ward, R., Beyer, B. “BeyondCorp: A New Approach to Enterprise Security.” ;login:, Vol. 39, No. 6 (diciembre 2014), pp. 6–11. research.google/pubs/beyondcorp-a-new-approach-to-enterprise-security. ⁵
• CISA, Zero Trust Maturity Model v2.0. Cybersecurity and Infrastructure Security Agency, abril 2023. ⁶
• PCI Security Standards Council, PCI DSS v4.0. PCI SSC, marzo 2022. ⁷
• Schneier, B. “A Plea for Simplicity.” Crypto-Gram, noviembre 1999; reformulado y expandido en Secrets and Lies (Wiley, 2000) y ensayos posteriores. La forma frecuentemente citada es “complexity is the worst enemy of security”. ⁸
• United States v. Paige A. Thompson (W.D. Wash., 2019). Acusación formal de Capital One, con post-mortems posteriores de la industria y la acción de cumplimiento de la Office of the Comptroller of the Currency (ago. 2020). ⁹
• CISA Alert AA20-352A, Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations. Cybersecurity and Infrastructure Security Agency, diciembre 2020 (compromiso de cadena de suministro de SolarWinds Orion). ¹⁰
• Avisos de CISA y Progress Software sobre CVE-2023-34362, vulnerabilidad de inyección SQL en MOVEit Transfer. Junio 2023. ¹¹