Zero Trust arquitectura

Resumen breve

El Zero Trust (ZT) es un modelo de seguridad en el que el perímetro de red ya no se considera una zona de confianza. Cada solicitud (user→app, service→service, device→network) pasa por una autenticación, autorización y cifrado explícitos, teniendo en cuenta las señales contextuales (identidad, estado del dispositivo, ubicación, riesgo, comportamiento). El objetivo es minimizar el blast radius, reducir el riesgo de movimiento lateral y simplificar el cumplimiento.

Principios básicos de Zero Trust

1. Falta una confianza clara: la confianza no se hereda de la red/VPN/ASN.
2. El acceso es el mínimo necesario: una política de «proporcionar solo lo que se necesita ahora».
3. Verificación continua: las sesiones y tokens se revalorizan regularmente por riesgo y contexto.
4. Suposición de compromiso: segmentación, observabilidad, contenido rápido y rotación de claves.
5. Cifrado en todas partes: TLS 1. 2+/1. 3 y mTLS dentro de los planes de datos, DNS protegido, secretos en KMS/HSM.

Paisajes de destino y dominios de control

Identidad: personas (IdP: SSO, MFA, passkeys/FIDO2), máquinas (SPIFFE/SVID, x509/mTLS).
Dispositivos: cumplimiento de directivas (MDM/EDR, disco cifrado, parches, jailbreak/root - prohibido).
Red: microsegmentación de L3/L7, ZTNA/puertas de enlace SDP, servicio de mesh (Envoy/Istio/Linkerd).
Aplicaciones/API: mTLS, OIDC/JWT, firmas de consulta (HMAC), rate limits, DLP/enmascaramiento.
Datos: clasificación (Público/Confidencial/Restringido), tokenización/cifrado a nivel de campo.
Observabilidad: registros centralizados de autenticación/autorización, análisis de comportamiento, SLO/SLA.

Arquitectura de referencia (en el corte de planos)

Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), directorios de políticas, PKI/CA, certificación de dispositivos.
Plan de datos: acceso proxy (ZTNA), proxy sidecar (Envoy) para mTLS y política L7, gateways de servicio/API GW.
Plan de gestión: directorio de servicios, CMDB, CI/CD, gestión secreta (Vault/KMS), auditoría centralizada.

1. Identificación (SSO + phishing-resistant MFA) → 2) Evaluación del dispositivo (MDM posture) → 3) El proxy ZTNA establece mTLS a la aplicación → 4) PDP (políticas) toma una decisión basada en atributos (ABAS) C/RBAC) → 5) reevaluación continua del riesgo (tiempo, geo, anomalías).

Identidad y autorización

IdP/SSO: OIDC/SAML, MFA por defecto, preferiblemente FIDO2 (passkeys).
RBAC/ABAC: roles + atributos de contexto (estado del dispositivo, departamento, perfil de riesgo).
Acceso Just-In-Time (JIT): privilegios temporales con revocación automática; break-glass - estrictamente regulado.
mTLS para máquinas: SPIFFE/SVID o PKI interno con certificados de breve duración; liberación rotativa automática.

Dispositivos y contexto

Verificación de conformidad (posture): versión OS/EDR, cifrado de disco incluido, firewall; no compliant → acceso mínimo o unidad.
Certificación: device identity + signed attestations (MDM/Endpoint).
Restricciones de red: bloque de túneles de terceros, DNS corporativo forzado, protección contra fugas DNS/WebRTC.

Red y microsegmentación

Rechazar VLAN 'planas': en cambio, son segmentos/VRF y una política en L7.
Mesh de servicio: los proxy sidecar proporcionan mTLS, autorización de políticas (OPA/EnvoyFilter), telemetría.
ZTNA/SDP: acceso a una aplicación específica, no a una red; kliyent↔broker↔app, política en PDP.
Acceso remoto: reemplaza una VPN «gruesa» por un proxy app; los túneles fallback están restringidos por rutas/puertos.

Políticas y motor de soluciones

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Modelo de política: reglas declarativas (Rego/Cedar), atributos estáticos y contextuales, evaluación de riesgos.

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

Seguimiento de soluciones: lógica 'input '/' nat '/' explain' para auditar.

Cifrado y confianza predeterminados

TLS 1. 2+/1. 3 en todas partes, cifrado estricto, HSTS, OCSP stapling.
mTLS internamente: servis↔servis sólo por certificados mutuos; las claves son breves (horas/días).
Secretos: KMS/HSM, secrets dinámicos (Vault), TTL cortos, least-privilege para aplicaciones.

Observabilidad, SLO y respuesta

• Éxito de autenticación y autorización (%), p95 tiempo de decisión PDP, p95 TLS-handshake.
• Porcentaje de solicitudes bloqueadas por la política (anomalías/falsas).
• Disponibilidad de los brókeres ZTNA y el controlador Mesh.
• La proporción de dispositivos compliant y tendencias.

• "Disponibilidad de ZTNA ≥ 99. 95 %/mes; p95 authZ decision ≤ 50 мс».
• "Porcentaje de consultas con mTLS ≥ 99. 9%».
• "No más de 0. 1% falsas denegaciones de acceso/día".

Alarting: picos de deny, degradación de p95 apretones de manos, cadenas inválidas, caída de la proporción de dispositivos compliant, anomalías geográficas/ASN.

Transición del perímetro al Fideicomiso Cero: hoja de ruta

1. Inventario: aplicaciones, flujos de datos, consumidores, sensibilidad (PII/tarjetas/pagos).
2. Identidad y MFA: SSO y phishing-resistant MFA para todos.
3. Contexto de dispositivos: MDM/EDR, políticas básicas de conformidad, bloque no complejo.
4. Microsegmentación de vías prioritarias: pagos, back office, administración; entrada mTLS.
5. ZTNA para acceso personalizado: publicar aplicaciones a través de proxy, borrar «VPN ancho».
6. Políticas ABAC: PDP centralizado, normas declarativas, auditoría.
7. Extensión al servicio de mesh: S2S mTLS, política L7, telemetría.
8. Automatización y SLO: alerting, pruebas de políticas (CI política), días de juego "¿qué pasa si IdP no está disponible? ».

Especificidad para iGaming/fintech

Segmentación rígida de dominios: pagos/PII/antifraude/contenido - perímetros y políticas separados; accesos sólo por ZTNA.
Interacciones con PSP/bancos: allow-list por ASN/rangos, mTLS a endpoints PSP, monitoreo de Time-to-Wallet y fallas en authZ.
Proveedores de contenido y socios: acceso temporal de JIT a API, tokens de TTL cortos, auditoría de integraciones.
Cumplimiento: PCI DSS/GDPR - minimización de datos, DLP/seudonimización, registro de accesos a tablas sensibles.

Seguridad de las cadenas de suministro y CI/CD

Firmas de artefactos (SLSA/Provenance): firmas de contenedores (cosign), política Admission en K8s.
SBOM y vulnerabilidades: generación de SBOM (CycloneDX), policy-gate en paipline.
Secretos en CI: Federación OIDC a KMS en la nube; prohibición de las llaves estáticas.
Rotaciones: frecuentes, automáticas; revoke forzado en incidentes.

Errores y anti-patrones típicos

«ZTNA = una nueva VPN»: publicar una red en lugar de aplicaciones no es Zero Trust.
No hay verificación de dispositivos: hay MFAs, pero los dispositivos infectados/rotados obtienen acceso.
Un único superusuario: sin JIT y roles separados.
Políticas en el código de servicios: no es posible realizar una auditoría/actualización centralizada.
mTLS parcial: parte de los servicios sin mTLS → un circuito «fusible».
UX cero: solicitudes de MFA redundantes, sin SSO; el resultado es resistencia a los equipos.

Mini Hyde para la selección de tecnologías

Acceso del usuario: ZTNA/SDP broker + IdP (OIDC, FIDO2 MFA).
Seguridad intra-servicio: servicio mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID o Vault PKI con TTL cortos.
Políticas: OPA/Rego o Cedar; almacenar en Git, comprobar en CI (policy-tests).
Registros y telemetría: OpenTelemetry → análisis centralizado, detonante de anomalías.

Ejemplos de configuración (fragmentos)

Envoy (mutual-TLS entre servicios)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego: acceso a los informes sólo desde «finance», desde dispositivos compliant, en horario de oficina

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

Lista de comprobación de la implementación de Zero Trust

1. Habilitar SSO y FIDO2 MFA para todos los usuarios y el almirante.
2. Escriba device posture (MDM/EDR) con bloqueo no completo.
3. Transferir acceso personalizado a ZTNA (per-app), dejar una VPN sólo para canales S2S estrechos.
4. Dentro de - mTLS por defecto + certificados de vida corta.
5. Centralizar políticas (PDP/OPA), almacenar en Git, probar en CI.
6. Segmentar los dominios sensibles (pagos/PII/back office) y limitar el este-oeste.
7. Configurar telemetría, SLO y alerting en auth/authZ, mTLS-share, señales de postura.
8. Realizar «días de juego» (fallo de IdP, fuga de claves, caída del bróker) y fijar SOP/retrocesos.

FAQ

¿Zero Trust reemplaza completamente la VPN?
Para el acceso personalizado - sí, a favor de ZTNA. Para las autopistas S2S, VPN/IPsec puede permanecer, pero con mTLS encima y políticas estrictas.

¿Puede ZT empeorar UX?
Si es irreflexivo. Con SSO + FIDO2, MFA adaptable y acceso per-app, el acceso UX suele mejorar.

¿Es obligatorio implementar un servicio de mesh?
No siempre. Pero para un gran entorno de microservicios, mesh simplifica radicalmente mTLS/política/telemetría.

Resultado

Zero Trust no es un producto, sino una disciplina arquitectónica: identidad como nuevo perímetro, contexto de dispositivos, acceso de aplicaciones (ZTNA), microsegmentación y mTLS en todas partes, políticas centralizadas y fiabilidad medible. Al seguir la hoja de ruta y la lista de verificación, reducirá la superficie de ataque, acelerará la auditoría y obtendrá una seguridad sostenible sin «confianza predeterminada».