Capítulo 12 · Identidad, arquitectura y regulación

Arquitectura de Seguridad y Zero Trust

Desarrollar criterios de diseño para integrar controles de seguridad desde la arquitectura y reducir confianza implícita entre usuarios, dispositivos, redes, aplicaciones y datos.

Principios de arquitectura segura

La arquitectura segura incorpora protección desde el diseño de un servicio. Defensa en profundidad significa disponer de barreras independientes para que una falla no abra por completo el sistema. El principio de mínimo privilegio limita operaciones y secure by default establece configuraciones inicialmente restrictivas. Las fronteras de confianza delimitan dónde cambian las garantías: entre navegador y servidor, entre redes, entre aplicaciones o entre proveedores. Una arquitectura no se vuelve segura agregando muchas herramientas de manera inconexa. Importa comprender qué se intenta proteger, qué caminos de acceso existen y cómo se comportarán los controles cuando alguno falle.

Conceptos de este apartado

  • Security by design
  • Defensa en profundidad
  • Mínimo privilegio
  • Fail secure y secure defaults
  • Separación de dominios y trust boundaries
  • Reducción de superficie de ataque

Modelado arquitectónico

Para analizar seguridad arquitectónica conviene dibujar componentes y flujos de datos. Un diagrama de contexto muestra actores y sistemas; uno de flujo revela qué información entra, se procesa, se almacena y sale. En cada conexión pueden surgir decisiones de autenticación, cifrado, registro y confianza. Los puntos de entrada expuestos merecen atención, pero los intercambios internos tampoco deben asumirse confiables por encontrarse dentro de la misma organización. Un anti-patrón habitual es conceder amplios permisos a un servicio para evitar complejidad inicial. Documentar estas elecciones permite comprender deuda técnica y evaluar alternativas antes de que la dependencia sea difícil de revertir.

Conceptos de este apartado

  • Diagramas de contexto y flujo de datos
  • Activos, zonas y dependencias
  • Puntos de entrada y salida
  • Fronteras de confianza
  • Patrones y anti-patrones
  • Requisitos de seguridad no funcionales

Zero Trust

Zero Trust no designa un producto concreto ni significa desconfiar de todas las personas. Es una aproximación de arquitectura que evita otorgar confianza duradera por la mera ubicación en una red. El acceso se evalúa mediante identidad, estado del dispositivo, contexto y políticas. La segmentación reduce movimientos laterales entre recursos; la telemetría permite revisar cambios en señales de riesgo. Un usuario autenticado sigue necesitando autorización específica para la operación solicitada. Adoptar Zero Trust requiere comprender procesos y dependencias, porque imponer controles sin considerar tareas legítimas puede bloquear servicios esenciales sin reducir proporcionalmente el riesgo.

Conceptos de este apartado

  • Principios de no confiar y verificar explícitamente
  • Identidad como nuevo perímetro
  • Estado del dispositivo y contexto
  • Segmentación y microsegmentación
  • Acceso a aplicaciones y recursos
  • Telemetría y evaluación continua

Arquitecturas de red seguras

La arquitectura de red combina separación, inspección y control de tráfico. Una DMZ puede aislar servicios expuestos; un firewall filtra comunicaciones según reglas; un WAF analiza determinadas interacciones con aplicaciones web. Un proxy o gateway puede concentrar políticas de salida o acceso. Los mecanismos de acceso remoto deben autenticar identidades y limitar recursos disponibles. Ninguna medida corrige automáticamente una autorización defectuosa dentro de la aplicación. Los puntos únicos de fallo también son relevantes: un dispositivo de seguridad mal dimensionado puede interrumpir todo el servicio. Diseño seguro implica considerar protección y disponibilidad conjuntamente.

Conceptos de este apartado

  • DMZ y segmentación
  • Firewalls, WAF y gateways
  • Proxies y secure web gateways
  • Remote access y ZTNA
  • DNS seguro y controles de salida
  • Alta disponibilidad y resiliencia de componentes de seguridad

Arquitectura de datos y aplicaciones

Las aplicaciones manejan credenciales, secretos, APIs y datos con diferentes sensibilidades. Una arquitectura sólida separa estos elementos cuando resulta útil, protege claves y restringe accesos a bases de datos. Un gateway puede centralizar determinadas reglas, aunque la aplicación debe seguir validando autorizaciones. Los logs permiten observar decisiones, pero pueden convertirse en una fuga si registran contraseñas o datos sensibles. Diseñar sistemas seguros implica decidir qué información conservar, durante cuánto tiempo y quién puede verla. Los patrones de protección deben adaptarse al riesgo y mantenerse durante cambios de arquitectura, no solamente en la versión inicial del proyecto.

Conceptos de este apartado

  • Protección por capas
  • Separación de secretos y configuración
  • APIs y gateways
  • Servicios de claves y certificados
  • Control de acceso a datos
  • Logging y observabilidad incorporados al diseño

Revisión y decisión arquitectónica

Una revisión de arquitectura evalúa alternativas antes de aprobar cambios relevantes. Debe describir requisitos, escenarios de amenaza, controles propuestos y costes asociados. Un registro de decisión arquitectónica, o ADR, conserva el problema, las opciones y los motivos de una elección. Esto es especialmente útil cuando una configuración menos segura se acepta temporalmente por disponibilidad o compatibilidad. Las excepciones requieren plazo, responsable y seguimiento. Las decisiones técnicas generan consecuencias jurídicas y operativas, por lo que un diseño documentado ayuda a explicar después quién consideró un riesgo y qué medidas se estimaron proporcionales.

Conceptos de este apartado

  • Security Architecture Review
  • Análisis de alternativas
  • Threat modeling a nivel de arquitectura
  • Trade-offs entre seguridad, disponibilidad y coste
  • Deuda técnica y excepciones
  • Registro de decisiones arquitectónicas

Un caso para comprenderlo

Una aplicación interna se considera protegida porque solo se accede a través de la red corporativa. Al revisar sus flujos se descubre que cualquier usuario autenticado puede consultar datos de otras áreas. El problema está en una frontera de confianza mal definida. Una arquitectura con autorización contextual y registros adecuados reduce el riesgo de movimientos indebidos.

Cómo aplicar estos conceptos

El punto de partida es describir el sistema o situación con precisión, distinguir hechos de suposiciones y seleccionar qué información permitiría comprobar una conclusión. A partir de ahí se identifican riesgos, controles, responsabilidades y evidencias posibles. La utilidad de estos conocimientos aumenta cuando se relacionan con otras áreas de la ciberseguridad y del Derecho informático.

Lecturas relacionadas