Zero Trust

Contenido complementario

Este tema no está en las notas de tus cursos que tengo (la lección de Zero Trust del curso Network Security Engineering está pendiente de ver); está completado con conocimiento general. Es un tema de diseño y de estrategia, más que de comandos: úsalo como mapa y compáralo con lo que veas en la lección.

Resumen

El modelo tradicional de seguridad era como un castillo con foso: todo lo que está dentro de la red se considera de confianza y todo lo de fuera no. El problema es que, si un atacante o un equipo infectado entra, puede moverse libremente por dentro (movimiento lateral). Zero Trust parte de la idea opuesta: nunca confiar, siempre verificar. Ningún usuario, equipo ni conexión es de confianza solo por estar en la red interna; cada acceso se autentica, se autoriza con el mínimo privilegio necesario y se inspecciona, y se asume que una brecha puede ocurrir.
Un firewall de nueva generación es una pieza central de este modelo, porque puede aplicar política por aplicación, usuario y contenido (no solo por IP y puerto), segmentar la red en zonas pequeñas y descifrar e inspeccionar el tráfico. Esta nota explica los principios de Zero Trust, cómo se traducen en funciones concretas del firewall, una guía de implementación por fases y los errores típicos al adoptarlo. Todas las funciones que se mencionan tienen su propia nota en este vault.

Requisitos previos

• Entender cómo se evalúa el tráfico: zonas, Security Policy, App-ID y User-ID (ver Security Policy Fundamentals, App-ID y Policy Optimization y User-ID)
• Tener un inventario de aplicaciones, servidores, usuarios y flujos de tráfico (no se protege lo que no se conoce)
• Visibilidad previa: logs y ACC funcionando (ver Logging, Monitoring y SIEM)
• Apoyo del negocio: Zero Trust cambia hábitos y puede romper flujos no documentados
• Un plan por fases, con ventanas de cambio y plan de reversa (ver CLI y Config Management)

Principios

Principio	Qué significa
Nunca confiar, siempre verificar	La ubicación en la red no da confianza; cada acceso se verifica
Mínimo privilegio	Cada usuario, aplicación o servidor solo accede a lo que necesita
Asumir la brecha	Diseñar para limitar el daño si algo se compromete
Verificación continua	La autenticación y la inspección no son de una sola vez
Visibilidad total	No se puede proteger lo que no se ve: logs, telemetría, inspección

Cómo se traduce en el firewall

graph TD
    ZT["Zero Trust"] --> SEG["Microsegmentación:<br/>zonas pequeñas por función"]
    ZT --> ID["Identidad:<br/>User-ID, MFA, GlobalProtect + HIP"]
    ZT --> APP["Aplicaciones:<br/>App-ID, reglas específicas"]
    ZT --> CONT["Contenido:<br/>perfiles, WildFire, URL, decryption"]
    ZT --> VIS["Visibilidad y respuesta:<br/>logs, tags dinámicos, automatización"]

Pilar de Zero Trust	Funciones del firewall	Nota
Segmentación	Zonas por función (usuarios, servidores, DMZ, IoT, administración), reglas entre zonas, Zone Protection	Zones, Zone Protection y DoS Protection
Identidad	User-ID, Authentication Portal, MFA, Dynamic User Groups	User-ID, Authentication Portal y MFA
Acceso remoto seguro	GlobalProtect con HIP y política por usuario y estado del equipo	GlobalProtect Remote Access
Aplicaciones	App-ID, application-default, bloqueo de aplicaciones no deseadas, Policy Optimizer	App-ID y Policy Optimization
Inspección de contenido	Antivirus, Anti-Spyware, Vulnerability Protection, WildFire, URL Filtering, DNS Security	Security Profiles y Profile Groups, WildFire, URL Filtering y DNS Security
Tráfico cifrado	Decryption (Forward Proxy e Inbound)	Decryption Forward Proxy, SSL Inbound Inspection
Respuesta automática	Dynamic Address Groups, tagging por logs, API	Dynamic Address Groups y Tagging, Automatización y API
Gobierno de la administración	RBAC, autenticación centralizada, hardening del plano de gestión	Admin Authentication y RBAC, Hardening del Management Plane
Gestión centralizada y consistente	Panorama o Strata Cloud Manager	Panorama Fundamentals, Strata Cloud Manager

Guía de implementación por fases

Zero Trust es un camino, no un interruptor

No se implementa de un día para otro. Cada fase deja la red más segura que la anterior y aporta información para la siguiente.

Fase 1: Ver

1. Activa logging en todas las reglas y envía los logs a un lugar central (ver Logging, Monitoring y SIEM).
2. Revisa ACC y Monitor > Logs: qué aplicaciones, usuarios y flujos existen realmente.
3. Identifica reglas demasiado abiertas (any en aplicación o servicio) con Policy Optimizer (Policies > Security > Policy Optimizer > Rules Without App Controls / Unused Apps).

Fase 2: Identificar

1. Habilita User-ID en las zonas de usuarios (ver User-ID).
2. Pon Authentication Portal para lo que no se identifica, y MFA para accesos sensibles (ver Authentication Portal y MFA).
3. Revisa que los logs muestren usuario y aplicación, no solo IP.

Fase 3: Segmentar

1. Divide las zonas grandes en zonas por función (usuarios, servidores de aplicaciones, bases de datos, administración, IoT, invitados).
2. Crea reglas entre zonas con las aplicaciones y usuarios necesarios, en vez de permitir todo (ver Security Policy Fundamentals).
3. Sustituye reglas amplias por reglas específicas, una a una, vigilando el hit count y los logs antes de eliminar la regla vieja.

Fase 4: Inspeccionar

1. Aplica perfiles de seguridad a todas las reglas Allow (ver Security Profiles y Profile Groups).
2. Activa decryption para el tráfico saliente, con excepciones por privacidad y compatibilidad (ver Decryption Forward Proxy).
3. Protege los servidores publicados con Inbound Inspection (ver SSL Inbound Inspection).

Fase 5: Automatizar y mantener

1. Aísla automáticamente hosts comprometidos con tags dinámicos (ver Dynamic Address Groups y Tagging).
2. Revisa periódicamente reglas sin uso, objetos obsoletos y aplicaciones nuevas.
3. Mantén el sistema actualizado y las licencias vigentes (ver Updates y Upgrades y Licensing y Subscriptions).

Verificación

Dónde	Qué debes ver	Si no lo ves
Policies > Security > Policy Optimizer	Pocas reglas con any en aplicación y pocas sin uso	Si hay muchas, reduce reglas abiertas
Monitor > Logs > Traffic	Usuario y aplicación identificados en la mayoría de sesiones	Si faltan, completa User-ID y App-ID
Columna Profile de las reglas Allow	Perfil o grupo de perfiles en todas	Aplica perfiles a las que no lo tengan
Monitor > Logs > Traffic: columna Decrypted	yes en el tráfico objetivo	Revisa las reglas de Decryption
ACC > Network Activity	Flujos entre zonas coherentes con el diseño	Si hay tráfico inesperado entre zonas, revisa las reglas
show running security-policy o Policies > Security	Reglas ordenadas de lo específico a lo general, con application-default	Si hay reglas muy amplias arriba, reordénalas

Errores comunes

Intentar aplicar todo de golpe

• Causa: pasar de reglas abiertas a reglas estrictas sin observar.
• Solución: empieza por visibilidad, usa alert antes de block y migra regla por regla.

Reglas basadas solo en IP y puerto

• Causa: se sigue pensando en el modelo antiguo.
• Solución: escribe reglas con aplicación y usuario y usa application-default como servicio (ver App-ID y Policy Optimization).

Segmentar sin conocer los flujos

• Causa: no hay inventario de aplicaciones y dependencias.
• Solución: usa logs y ACC para documentar flujos antes de cerrar.

Dejar excepciones permanentes

• Causa: reglas “temporales” que nunca se eliminan.
• Solución: asigna fecha de revisión (con descripción y tags) y revisa los hit counts.

No inspeccionar el tráfico cifrado

• Causa: decryption desactivado por complejidad.
• Solución: despliega decryption por fases, con No Decrypt para categorías sensibles.

Olvidar la administración

• Causa: se protege el tráfico de usuarios pero la gestión sigue abierta.
• Solución: aplica el hardening del plano de gestión (ver Hardening del Management Plane).

Creer que Zero Trust es un producto

• Causa: se compra una herramienta y se da por terminado.
• Solución: es una estrategia continua de diseño, identidad, segmentación, inspección y revisión.