Tema 3

3. Arquitecturas defensivas: perímetro, red interna, DMZ, nube y entornos híbridos

Una arquitectura defensiva ordena dónde se ubican los activos, cómo se comunican, qué controles los protegen y qué límites existen entre zonas con distinto nivel de confianza.

Objetivo Comprender modelos defensivos de infraestructura
Enfoque Redes, zonas, nube y controles de seguridad
Resultado Diseñar separaciones claras entre activos y niveles de confianza

3.1 Introducción

Una arquitectura defensiva es la forma en que organizamos una infraestructura para protegerla. No se limita a elegir un firewall o activar un IDS. Incluye decisiones sobre zonas de red, rutas de comunicación, servicios publicados, accesos administrativos, monitoreo, nube, usuarios remotos y sistemas críticos.

El objetivo es evitar una red plana donde todo se comunica con todo. Una buena arquitectura separa funciones, reduce exposición, facilita el monitoreo y limita el impacto cuando ocurre un incidente.

En este tema veremos los modelos más comunes: perímetro, red interna, DMZ, nube y entornos híbridos. También veremos cómo ubicar firewalls, IDS/IPS y controles de hardening dentro de cada diseño.

3.2 Qué es una arquitectura defensiva

Una arquitectura defensiva es un diseño técnico y operativo que define cómo se protegen los activos de una organización. Debe responder preguntas concretas:

  • Qué zonas existen y qué nivel de confianza tiene cada una.
  • Qué activos críticos se ubican en cada zona.
  • Qué comunicaciones están permitidas entre zonas.
  • Dónde se aplican firewalls, IDS/IPS, WAF, VPN y otros controles.
  • Cómo se administran los equipos de forma segura.
  • Qué eventos se registran y dónde se monitorean.
  • Cómo se contiene un incidente para que no alcance toda la infraestructura.
Una arquitectura defensiva no busca complicar la red. Busca que las comunicaciones necesarias sean claras, controladas y verificables.

3.3 Zonas de confianza

Una zona de confianza agrupa activos que comparten un nivel similar de riesgo, función o sensibilidad. Por ejemplo, una red de invitados no debe tener el mismo nivel de confianza que una red de administración.

Separar zonas permite aplicar reglas distintas. Un servidor de base de datos no necesita las mismas reglas que una estación de trabajo. Un servicio publicado en internet no debe tener el mismo tratamiento que una consola administrativa interna.

Zona Ejemplos Tratamiento defensivo
Internet Usuarios externos, proveedores, atacantes potenciales No confiable. Todo acceso debe filtrarse y registrarse.
DMZ Web pública, reverse proxy, gateway VPN Exposición controlada y comunicación limitada hacia redes internas.
Usuarios internos PC, notebooks, telefonía, impresoras Acceso limitado por necesidad y monitoreo de comportamiento.
Servidores Aplicaciones, archivos, bases de datos Segmentación, hardening, parches y acceso restringido.
Administración Consolas, herramientas de gestión, cuentas privilegiadas Alta protección, MFA, registro de acciones y acceso mínimo.
Invitados Wi-Fi de visitantes, dispositivos no gestionados Aislamiento estricto y salida controlada a internet.

3.4 Arquitectura perimetral

El perímetro es el límite entre la organización y redes externas, especialmente internet. Durante mucho tiempo fue el centro de la defensa: se instalaba un firewall en la salida a internet y se intentaba proteger todo desde ese punto.

El perímetro sigue siendo importante, pero ya no alcanza por sí solo. Hoy existen usuarios remotos, servicios en la nube, dispositivos móviles, proveedores conectados y aplicaciones distribuidas. Aun así, controlar el perímetro permite reducir exposición y registrar tráfico relevante.

Controles frecuentes en el perímetro:

  • Firewall de borde o NGFW.
  • VPN para acceso remoto o conexión entre sedes.
  • Protección contra denegación de servicio.
  • Filtrado de salida hacia internet.
  • IDS/IPS en puntos de entrada y salida.
  • Registro centralizado de conexiones permitidas y bloqueadas.

3.5 Limitaciones del modelo perimetral

El error más común es pensar que lo interno es confiable y lo externo es peligroso. Esa idea ya no es suficiente. Un equipo interno puede estar comprometido, una cuenta legítima puede ser robada o un proveedor puede introducir riesgo.

El modelo perimetral falla cuando la red interna queda demasiado abierta. Si un atacante supera el perímetro o ingresa mediante credenciales válidas, puede moverse lateralmente con pocas restricciones.

El perímetro es una capa, no toda la defensa. La seguridad moderna necesita controles internos, segmentación y verificación continua.

3.6 Arquitectura de red interna

La red interna contiene usuarios, servidores, dispositivos, impresoras, sistemas de administración, servicios de autenticación y aplicaciones de negocio. Protegerla exige segmentar y controlar comunicaciones internas.

Una arquitectura interna defensiva evita que todos los equipos compartan el mismo nivel de confianza. Por ejemplo, una notebook de usuario no debería comunicarse libremente con bases de datos, sistemas de backups o consolas de administración.

Buenas prácticas para red interna:

  • Separar usuarios, servidores, administración, invitados y dispositivos especiales.
  • Aplicar reglas entre segmentos según necesidad real.
  • Monitorear tráfico interno, no solo tráfico hacia internet.
  • Usar autenticación fuerte para accesos administrativos.
  • Limitar protocolos inseguros o innecesarios.
  • Registrar cambios en equipos de red, firewalls y servidores.

3.7 DMZ: zona desmilitarizada

Una DMZ, o zona desmilitarizada, es una red intermedia donde se ubican servicios que deben ser accesibles desde redes externas, pero que no deberían estar directamente dentro de la red interna principal.

El objetivo de una DMZ es contener el riesgo. Si un servicio público es comprometido, el atacante no debería tener acceso directo a servidores internos, estaciones de trabajo o sistemas administrativos.

Servicios que suelen ubicarse en una DMZ:

  • Servidores web públicos.
  • Reverse proxies.
  • Gateways VPN.
  • Servidores de correo expuestos.
  • DNS públicos.
  • Balanceadores o puntos de entrada a aplicaciones.

3.8 Reglas típicas en una DMZ

Una DMZ no es una zona libre. Debe tener reglas estrictas. El tráfico desde internet hacia la DMZ se limita a los servicios publicados. El tráfico desde la DMZ hacia la red interna se restringe todavía más.

Comunicación Ejemplo Criterio defensivo
Internet a DMZ Clientes hacia HTTPS del sitio web Permitir solo puertos publicados y registrar intentos.
DMZ a red interna Aplicación web hacia base de datos Permitir solo origen, destino y puerto necesarios.
Red interna a DMZ Administración o despliegue Permitir solo desde redes administrativas autorizadas.
DMZ a internet Actualizaciones o consultas externas Restringir destinos y monitorear conexiones salientes.
Internet a red interna Administración directa Evitar. Usar VPN, bastión o acceso controlado.

3.9 Arquitectura con host bastión

Un host bastión es un equipo especialmente protegido que se usa como punto controlado para administrar otros sistemas. En lugar de permitir administración directa desde muchas redes, se concentra el acceso en un punto endurecido, monitoreado y auditado.

Un bastión puede usarse para SSH, RDP, consolas web, administración de nube o acceso a servidores críticos. Debe tener hardening estricto, autenticación fuerte, registro de sesiones y acceso limitado por origen.

Características esperables de un bastión:

  • Cuentas individuales, no compartidas.
  • Autenticación multifactor.
  • Registro de conexiones y acciones.
  • Acceso solo desde redes o usuarios autorizados.
  • Actualización y hardening permanente.
  • Monitoreo de intentos fallidos y actividad anómala.

3.10 Arquitecturas en la nube

En la nube, la defensa no desaparece: cambia de forma. En lugar de switches físicos y firewalls tradicionales, aparecen redes virtuales, subredes, grupos de seguridad, firewalls administrados, balanceadores, identidades, políticas y servicios gestionados.

Un error frecuente es pensar que el proveedor de nube protege todo. En realidad, la seguridad se comparte. El proveedor protege la infraestructura base, pero el cliente sigue siendo responsable de configurar accesos, identidades, redes, datos, sistemas y aplicaciones de forma segura.

Controles habituales en nube:

  • Redes virtuales y subredes separadas.
  • Grupos de seguridad o reglas equivalentes.
  • Firewall de aplicación web.
  • Control de identidad y roles.
  • Registro de eventos de administración.
  • Cifrado de datos y comunicaciones.
  • Monitoreo de configuración y postura de seguridad.

3.11 Modelo de responsabilidad compartida

El modelo de responsabilidad compartida indica que el proveedor de nube y el cliente tienen responsabilidades diferentes. El detalle cambia según el servicio, pero la idea general es constante: usar nube no elimina la necesidad de administrar seguridad.

Área Responsabilidad típica del proveedor Responsabilidad típica del cliente
Infraestructura física Datacenter, energía, hardware, red física Elegir regiones y servicios adecuados.
Red virtual Plataforma de red disponible Diseñar subredes, rutas, reglas y exposición.
Identidad Servicio de autenticación disponible Configurar MFA, roles, permisos y revisión de accesos.
Máquinas virtuales Hipervisor e infraestructura base Parcheo, hardening, firewall del sistema y monitoreo.
Datos Servicios de almacenamiento confiables Cifrado, clasificación, permisos y respaldo.

3.12 Entornos híbridos

Un entorno híbrido combina infraestructura local con servicios en la nube. Puede incluir datacenters propios, sedes remotas, usuarios móviles, aplicaciones SaaS, máquinas virtuales en nube y conexiones privadas o VPN.

Estos entornos son comunes, pero requieren especial atención porque aumentan la cantidad de rutas, identidades, consolas y puntos de integración. Si no se diseñan bien, pueden aparecer accesos duplicados, reglas inconsistentes y falta de visibilidad.

Riesgos habituales en entornos híbridos:

  • Reglas distintas entre firewalls locales y controles de nube.
  • Usuarios con permisos excesivos en varias plataformas.
  • Logs dispersos y difíciles de correlacionar.
  • Túneles entre sedes o nube con tráfico demasiado amplio.
  • Servicios publicados tanto localmente como en nube sin inventario claro.
  • Dependencias críticas no documentadas.

3.13 Ubicación de IDS/IPS

La ubicación de sensores IDS/IPS depende de lo que se necesita observar o bloquear. No todos los sensores ven lo mismo. Un sensor en el perímetro ve tráfico de entrada y salida, pero puede no ver comunicación lateral entre servidores internos.

Puntos útiles para ubicar sensores:

  • Entre internet y la red perimetral.
  • Entre DMZ y red interna.
  • Entre segmentos críticos internos.
  • En redes de servidores sensibles.
  • En hosts importantes mediante HIDS o agentes.
  • En entornos cloud mediante logs, sensores virtuales o servicios nativos.
Un IDS/IPS debe ubicarse donde aporte visibilidad o prevención real. Instalarlo en un punto ciego o sin proceso de respuesta reduce mucho su valor.

3.14 Administración segura

Una arquitectura defensiva debe proteger especialmente los accesos administrativos. Si un atacante obtiene control de firewalls, routers, servidores o consolas de nube, puede modificar reglas, borrar evidencias o crear accesos persistentes.

Medidas recomendadas:

  • Separar una red o zona de administración.
  • Usar MFA para cuentas privilegiadas.
  • Evitar administración directa desde internet.
  • Usar bastiones o VPN con controles estrictos.
  • Registrar cambios de configuración.
  • Aplicar cuentas individuales y roles mínimos.
  • Respaldar configuraciones de equipos críticos.

3.15 Ejemplo práctico de arquitectura defensiva

Supongamos una empresa con usuarios internos, una aplicación web pública, base de datos, administración remota y servicios en nube. Una arquitectura defensiva básica podría organizarse así:

  1. Internet llega a un firewall perimetral.
  2. El sitio público se ubica en una DMZ o detrás de un reverse proxy.
  3. La base de datos queda en una zona interna de servidores, no expuesta a internet.
  4. La aplicación web solo puede hablar con la base de datos por el puerto necesario.
  5. Los usuarios internos acceden a aplicaciones, pero no a consolas administrativas.
  6. La administración se realiza desde una red separada o mediante bastión.
  7. La nube se conecta por VPN o enlace privado con rutas y reglas específicas.
  8. Los logs de firewall, nube, servidores e IDS/IPS se envían a una plataforma central.

Este diseño no elimina todo riesgo, pero reduce exposición, mejora visibilidad y limita el movimiento lateral.

3.16 Errores frecuentes

  • Red plana: todos los equipos se comunican sin restricciones.
  • DMZ mal diseñada: el servidor expuesto tiene acceso amplio a la red interna.
  • Administración expuesta: consolas, SSH, RDP o paneles accesibles desde internet.
  • Nube sin segmentación: todos los recursos comparten reglas demasiado permisivas.
  • Logs dispersos: cada sistema registra eventos, pero nadie los correlaciona.
  • Excepciones permanentes: reglas temporales quedan activas sin revisión.
  • Confianza excesiva en la red interna: no se monitorea ni se controla tráfico lateral.

3.17 Lista de verificación inicial

  • Identificar zonas de confianza y activos críticos.
  • Separar usuarios, servidores, invitados, administración y servicios publicados.
  • Definir reglas explícitas entre zonas.
  • Evitar accesos administrativos directos desde internet.
  • Ubicar servicios públicos en DMZ o detrás de controles equivalentes.
  • Revisar rutas y reglas entre infraestructura local y nube.
  • Centralizar logs de firewalls, servidores, nube e IDS/IPS.
  • Aplicar hardening a equipos de red, servidores y bastiones.
  • Documentar excepciones, responsables y fecha de revisión.
  • Probar que la segmentación realmente bloquee lo que debe bloquear.

3.18 Ideas clave para recordar

  • Una arquitectura defensiva organiza zonas, activos, reglas y controles.
  • El perímetro sigue siendo importante, pero no alcanza como única defensa.
  • La DMZ reduce el riesgo de exponer servicios directamente en la red interna.
  • La nube requiere diseño seguro de redes, identidades, permisos y registros.
  • Los entornos híbridos necesitan reglas consistentes y visibilidad centralizada.
  • La administración segura es una zona crítica de cualquier arquitectura.

3.19 Conclusión

Las arquitecturas defensivas convierten los principios de defensa en profundidad y reducción de superficie de ataque en diseños concretos. Separar zonas, controlar comunicaciones, proteger accesos administrativos y monitorear eventos permite construir una infraestructura más ordenada y resistente.

En el próximo tema estudiaremos fundamentos de tráfico de red para defensa: TCP/IP, puertos, protocolos y flujos. Ese conocimiento será necesario para diseñar reglas de firewall, interpretar alertas IDS/IPS y entender qué ocurre dentro de una comunicación.