Plantilla de diagrama de arquitectura de red zero trust

Muchos diagramas con la etiqueta “zero trust” son diagramas de perímetro con un título nuevo: un firewall en el borde, una DMZ y un interior de confianza. Un diagrama de arquitectura zero trust útil responde tres preguntas de un vistazo: ¿dónde se toma cada decisión de acceso, qué señales alimentan esa decisión y dónde se aplica? Si la imagen no responde a eso, describe una ubicación en la red, no confianza.

A continuación: el modelo lógico de NIST SP 800-207, reglas de dibujo que un revisor puede comprobar, errores comunes y una plantilla gratuita para copiar en Archboard.

El modelo de NIST SP 800-207

NIST SP 800-207 define la arquitectura zero trust (ZTA) en torno a una idea: no hay confianza implícita basada en la ubicación de red ni en la propiedad de un activo. El acceso a cada recurso se concede por sesión, se decide con una política dinámica y se aplica antes de que el sujeto llegue al recurso.

Los tres componentes lógicos

Juntos, el PE y el PA forman el Policy Decision Point (PDP). En sistemas reales, el PE puede vivir dentro de un proxy consciente de la identidad o del plano de control de un service mesh, y los PEP son gateways, sidecars, agentes o proxies. Aun así, el diagrama debe hacer visible cada rol, aunque un mismo producto cumpla dos.

Las fuentes de datos detrás de la decisión

SP 800-207 enumera las entradas que puede usar un PE. Las que deberían aparecer en casi cualquier diagrama:

• Proveedor de identidad / gestión de identidades: usuarios, identidades de servicio, grupos, nivel de autenticación.
• Postura del dispositivo (CDM): datos de diagnóstico y mitigación continuos: ¿el dispositivo es conocido, está gestionado, tiene parches?
• Threat intelligence: fuentes sobre ataques nuevos, cuentas comprometidas y vulnerabilidades.
• Logs de actividad y SIEM: actividad de red y de sistemas recopilada y analizada; aquí empieza el bucle de retroalimentación.
• PKI empresarial: certificados para usuarios, dispositivos y workloads.

El estándar también menciona políticas de acceso a datos y requisitos de cumplimiento; dibújalos si influyen en decisiones reales.

Cómo dibujar un diagrama de arquitectura zero trust

1. Pon un PEP en cada ruta de acceso

Sigue cada flecha desde un sujeto (usuario, dispositivo, servicio) hasta un recurso. Cada una debe pasar primero por un punto de aplicación. Si una flecha se salta el PEP, o el diagrama está mal o la arquitectura tiene un hueco. Incluye las rutas de administración, de CI/CD y de acceso de emergencia (break-glass), no solo la del usuario.

2. Muestra cómo las señales de identidad y dispositivo alimentan la decisión

Dibuja el proveedor de identidad, la postura del dispositivo, la threat intel y el SIEM como nodos con conexiones hacia el Policy Engine. Etiqueta las conexiones con lo que fluye: “usuario + grupos (OIDC)”, “cumplimiento del dispositivo”, “señales de riesgo”.

3. Haz explícitas la authN y la authZ por sesión

NIST describe el acceso como concedido por sesión; muchas implementaciones vuelven a evaluar en cada petición. En ambos casos, muestra la secuencia: el sujeto solicita acceso, el PEP consulta al PDP, el PE evalúa, el PA configura el PEP y el PEP permite o bloquea la sesión. Bastan etiquetas numeradas en las conexiones; añade un pequeño diagrama de secuencia si necesitas más detalle.

4. Separa el plano de control del plano de datos

Coloca el PE, el PA y las fuentes de datos en una región, y los sujetos, los PEP y los recursos en otra. Entre ambas solo cruzan el canal de control del PA al PEP, los flujos de señales y el flujo de logs.

5. Muestra la microsegmentación y el tráfico este-oeste

Zero trust no trata solo de usuarios que llegan a aplicaciones. Para el tráfico entre servicios, dibuja:

• la identidad del workload (por ejemplo, certificados vinculados a una service account),
• mTLS entre servicios y la CA o PKI que emite esos certificados,
• la política de segmentación entre workloads, como una NetworkPolicy de Kubernetes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

Una NetworkPolicy actúa en las capas 3 y 4 y solo tiene efecto si tu plugin CNI la aplica. Es segmentación, no autenticación, así que acompáñala en el diagrama de mTLS y de autorización en un PEP.

6. Dibuja los secretos y certificados como piezas de primera clase

Muestra el vault (gestor de secretos) y la PKI como nodos separados. Dibuja qué workloads obtienen qué secretos y con qué identidad. En el modelo de NIST, las credenciales específicas de sesión vienen del PA, así que conéctalas al flujo de decisión.

7. Mantén el WAF y los firewalls, en su sitio

Zero trust no elimina el WAF ni los firewalls. Siguen filtrando en el borde y entre segmentos, pero no toman la decisión de confianza. Dibújalos como filtros en la ruta, no como el muro alrededor de una zona de confianza.

8. Cierra el bucle con logging

Cada PEP y cada firewall debería enviar logs al SIEM, y el análisis debería volver al Policy Engine. Sin esa conexión, al diagrama le falta lo “continuo” de la verificación continua.

Errores comunes

• Castillo y foso, con otra etiqueta. Un firewall exterior grueso, una “red interna de confianza” y ningún control entre servicios internos.
• Sin flujo de decisión. El IdP y un gateway están en el lienzo, pero nada muestra dónde se decide ni qué consume esa decisión.
• Sin bucle de retroalimentación. Los logs no van a ninguna parte, o el SIEM es un callejón sin salida sin conexión de vuelta a la política.
• Solo norte-sur. Está cubierto el acceso de usuarios a aplicaciones; las rutas entre servicios y de administración hacia la infraestructura, no.
• Zonas dibujadas como confianza. Usar Frames para segmentos está bien, pero llámalos segmentos o dominios de aplicación, no “de confianza”.

Constrúyelo en Archboard

Los packs integrados cubren todas las piezas. El pack Security tiene nodos para el proveedor de identidad, WAF, firewall, gateway zero trust, vault y certificados. El pack Network ofrece Internet, DNS, balanceador de carga, y VPC y subnet como frames. El pack Kubernetes añade Namespace (dibujado como frame), Service, Pod y NetworkPolicy. Los nodos tienen puertos, así que cada conexión se engancha a un lado concreto del nodo en lugar de flotar sobre una forma.

1. Organiza los planos con Frames. Añade dos Frames del pack Core, “Control plane” y “Data plane”. Dentro del plano de datos, añade un Frame por segmento, por ejemplo “Edge”, “App segment” y “Data segment”. Para workloads de Kubernetes, usa el nodo Namespace.
2. Añade los sujetos y el borde. Coloca un nodo Internet del pack Network para los usuarios, luego un nodo WAF del pack Security y después el nodo de gateway zero trust como PEP del acceso de usuarios.
3. Añade la decisión y sus entradas. En el frame del plano de control, coloca el nodo de proveedor de identidad y nodos Box del pack Core con las etiquetas “Policy Engine”, “Policy Administrator”, “Device posture (CDM)”, “Threat intel” y “SIEM”.
4. Conecta el flujo de decisión. Une las fuentes de señales al Policy Engine, el Policy Engine al Policy Administrator y el Policy Administrator a cada PEP. Etiqueta las conexiones.
5. Añade las rutas este-oeste. Dentro de cada Namespace, añade nodos Service y Pod y un nodo NetworkPolicy. Añade un nodo de certificado para el emisor mTLS y un nodo vault para los secretos, conectados a los workloads que los usan.
6. Pon firewalls entre segmentos. Usa el nodo firewall del pack Security donde el tráfico cruza frames de segmento.
7. Cierra el bucle. Traza conexiones de cada PEP y firewall al SIEM, y del SIEM de vuelta al Policy Engine.
8. Escribe los supuestos en el lienzo. Usa un bloque Markdown para las reglas de política y la duración de las sesiones, con un bloque de código YAML delimitado dentro de él para la NetworkPolicy.

Un diagrama tan completo puede superar el límite del plan Free de 15 nodos de diagrama por diagrama; las notas y los textos cuentan aparte, hasta 150. En Free, divídelo en una vista general y un diagrama de detalle de Kubernetes; Pro elimina el límite de nodos. Puedes exportar SVG o PNG (con marca de agua en Free), compartir un enlace público y exportar el JSON estructurado para guardarlo junto a tu código de infraestructura.

La plantilla gratuita

El ejemplo Zero Trust Perimeter muestra usuarios que entran por un WAF en el borde, un nodo IdP / SSO conectado por OIDC, un gateway zero trust, un firewall de segmento, un vault de secretos y una PKI mTLS alrededor de una aplicación privada. Ábrelo y cópialo en tu espacio de trabajo con Usar este ejemplo. Después amplíalo con el frame del plano de control, las fuentes de señales y el bucle de logging de este artículo. Para la red de debajo, consulta el ejemplo de red de centro de datos y el caso de uso de diagramas de red.

Checklist y preguntas frecuentes

Antes de compartir el diagrama, comprueba que:

• cada ruta de sujeto a recurso cruza un PEP,
• las señales de identidad, dispositivo, amenazas y logs alimentan el Policy Engine,
• el plano de control y el de datos están visiblemente separados,
• el tráfico este-oeste muestra mTLS y segmentación,
• los secretos y la PKI muestran quién obtiene qué,
• los logs de PEP y firewalls van al SIEM y vuelven a la política.

¿Un diagrama de arquitectura zero trust es solo un diagrama de red? No. Un diagrama de red muestra adónde van los paquetes. Un diagrama ZTA añade dónde se decide el acceso, con qué señales y dónde se aplica.

¿Sigo necesitando firewalls en un diseño zero trust? Sí. Los firewalls y los WAF siguen reduciendo la exposición; simplemente dejan de ser la razón por la que algo se considera de confianza.

¿Una NetworkPolicy de Kubernetes me da zero trust? No por sí sola. Te da segmentación L3/L4. Sigues necesitando identidad de workload, mTLS, autorización en un PEP y logging.

Empieza gratis — un asiento, sin tarjeta de crédito.