Identidad, contexto, políticas, enforcement, prueba de posesión, microsegmentación y decisiones adaptativas por solicitud
Edición detallada - material de estudio y consulta profesional
Por João Ricardo Dutra••Material completo
Zero Trust para las : verifique y decida explícitamente según cada solicitud
Figura de apertura: el acceso a una es una decisión dinámica basada en el tema, el recurso, el contexto y la política actual.
Principio central
Ninguna ubicación otorga confianza implícita; cada acceso debe ser autenticado, autorizado, limitado y evaluado continuamente.
Edición en profundidad: material de estudio y consulta profesional.
Presentación del capítulo
La arquitectura de seguridad tradicional se construyó alrededor de los límites de la red. Los usuarios, servidores y aplicaciones ubicados dentro de una red corporativa recibieron, explícita o implícitamente, un mayor nivel de confianza. Este modelo perdió efectividad cuando las comenzaron a conectar nubes, socios, dispositivos móviles, proveedores, aplicaciones SaaS, centros de datos y cargas de trabajo efímeras. El origen de una conexión sigue siendo relevante como señal, pero ya no es suficiente para decidir si se debe autorizar una operación.
Zero Trust es un conjunto de principios y una estrategia arquitectónica basada en la eliminación de la confianza implícita. Los recursos se protegen individualmente o en pequeños grupos; se identifican sujetos y dispositivos; las decisiones de acceso utilizan políticas e información actuales; las comunicaciones están protegidas; y la telemetría se utiliza para mejorar continuamente la postura. El objetivo no es desconfiar de las personas de forma genérica, sino evitar que la ubicación, la propiedad o la autenticación pasada produzcan una autorización amplia y permanente.
Las son un punto natural para aplicar Zero Trust porque ya materializan operaciones, identidades, datos y políticas. Una puede actuar como un Policy Enforcement Point en el borde, mientras que las mallas de servicios aplican controles entre cargas de trabajo. Los proveedores de identidad emiten credenciales y ; los mecanismos posturales proporcionan contexto; los impulsores de políticas toman decisiones; y la observabilidad registra lo que sucedió. Sin embargo, comprar una , habilitar o requerir no crea por sí solo una arquitectura Zero Trust.
Este capítulo conecta los fundamentos de identidad, , , , políticas, malla de servicios, Kubernetes y observabilidad estudiados anteriormente. El enfoque es técnico y operativo: cómo modelar sujetos y recursos, cómo evaluar cada solicitud, cómo limitar privilegios, cómo reducir el movimiento lateral, cómo manejar fallas en los componentes de decisión y cómo evolucionar la implementación sin interrumpir las integraciones críticas.
Cómo estudiar este capítulo
Para cada flujo, identifique: sujeto, recurso, acción, contexto, fuente de identidad, motor de decisión, punto de cumplimiento y evidencia registrada. Esta descomposición transforma el término Zero Trust en arquitectura verificable.
Objetivos de aprendizaje
Explique Zero Trust sin reducirlo a producto, , o autenticación multifactor.
Relacionar los principios de SP 800-207 con el diseño de corporativas.
Distinga motor de políticas, administrador de políticas, Policy Enforcement Point, , y PAP.
Modele identidades humanas, aplicaciones, cargas de trabajo, dispositivos y sesiones.
Aplique autorización contextual y least privilege a las operaciones y datos de .
Comprenda los al portador, los vinculados, y en el contexto de la reducción de repeticiones.
Diseñar controles Zero Trust en , mallas de servicios y Kubernetes.
Combine , salida controlada, protección de datos y observabilidad.
Defina estrategias de disponibilidad, , apertura y cierre ante fallos para decisiones políticas.
Planifique un viaje de madurez con métricas, pruebas, gobernanza y respuesta adaptativa.
Estructura del capítulo
34.1 Qué es y qué no es Zero Trust
34.2 Principios y componentes lógicos
34.3 Recursos, sujetos y superficies protegidos
34.4 Decisión por solicitud y confianza dinámica
34.5 Identidad humana, aplicación, carga de trabajo y dispositivo
34.6 , y proof-of-possession
34.7 Autorización granular y arquitectura de políticas
34.8 como puntos de cumplimiento
34.9 Malla de servicios, Kubernetes y tráfico este-oeste
34.10 , salida y protección de datos
34.11 Telemetría, riesgo y respuesta adaptativa
34.12 Disponibilidad, gobernanza, madurez y retroubleshooting
Resumen, lista de verificación, ejercicios, glosario y referencias.
34.1 Qué es y qué no es Zero Trust
Zero Trust es un modelo de seguridad, un conjunto de principios de diseño y una estrategia de gestión coordinada. Su premisa es que las amenazas pueden existir dentro y fuera de los límites tradicionales y que no se debe otorgar confianza implícita a ningún elemento únicamente por su ubicación, propiedad o relación organizacional. La protección pasa de amplios segmentos de red a usuarios, dispositivos, cargas de trabajo, aplicaciones, datos y recursos específicos.
El término no significa bloquear todo, volver a autenticar manualmente al usuario con cada clic o eliminar por completo las redes privadas. Significa que cada acceso debe estar respaldado por una identidad, una política y un contexto suficientes para el riesgo de esa acción. Una solicitud para leer datos públicos y una transacción financiera irreversible no requieren necesariamente la misma fuerza de autenticación, el mismo conjunto de señales o el mismo tiempo de validez de autorización.
Tampoco existe un producto único llamado Zero Trust. En la arquitectura pueden participar proveedores de identidad, , mallas de servicios, EDR, motores de políticas, catálogos de datos, SIEM y plataformas de observabilidad. El valor surge de la integración coherente entre estos componentes, la calidad de las políticas, la cobertura de los recursos y la capacidad de medir y reaccionar ante las desviaciones.
Una red interna aún puede reducir la exposición y un firewall sigue siendo útil. El error es transformar la presencia en esta red en prueba suficiente de identidad y autorización. De manera similar, autentica los extremos de un canal, pero no define por sí mismo si el servicio A puede realizar la operación X en el recurso Y on-behalf-ofl usuario Z.
Tabla 1 - Zero Trust debe entenderse como una arquitectura y un proceso, no como una marca de producto.
Afirmación
Evaluación
Explicación
Zero Trust es la ausencia total de confianza.
Incorrecto.
La confianza ya no es implícita y pasa a ser explícitamente evaluada y limitada.
VPN implementa Zero Trust.
Incompleto.
VPN crea conectividad; no garantiza autorización granular ni evaluación continua.
mTLS es suficiente.
Incorrecto.
Autentica a sus pares, pero necesita políticas, identidad empresarial y controles de datos.
Cada solicitud debe ser evaluada.
Correcto como principio.
La evaluación puede utilizar decisiones locales, cache seguro y señales actuales según el riesgo.
34.2 Principios y componentes lógicos
SP 800-207 describe principios que se pueden aplicar directamente a las : los recursos y servicios se tratan como activos; toda comunicación está protegida independientemente de su ubicación; el acceso se otorga por sesión y con el mínimo privilegio; las decisiones consideran la identidad, el estado de los activos, el comportamiento y el contexto; y la organización recopila información para mejorar continuamente la postura.
En la arquitectura lógica del , el motor de políticas toma la decisión de otorgar, denegar o revocar el acceso. El administrador de políticas ejecuta esta decisión, por ejemplo configurando o finalizando una sesión. El Policy Enforcement Point habilita, monitorea y finaliza la conexión entre el sujeto y el recurso. En una plataforma , la , un de malla, un o el propio pueden desempeñar el papel de cumplimiento.
La terminología de autorización utilizada en las arquitecturas de software suele complementar este modelo con , , y PAP. El Policy Decision Point evalúa la política; el Punto de Información sobre Políticas proporciona atributos; el Punto de Administración de Políticas administra las políticas; y el Policy Enforcement Point hace cumplir la decisión. Los nombres varían según el producto, pero las responsabilidades deben permanecer claras para evitar puntos ciegos y decisiones contradictorias.
Una decisión puede ser binaria, pero las arquitecturas avanzadas también generan obligaciones: exigir un paso adelante, enmascarar campos, reducir el límite transaccional, activar el registro reforzado, imponer un límite de tasa específico o reenviar la operación para su aprobación. Estas obligaciones deben estar respaldadas por medidas de cumplimiento y auditadas como parte del resultado.
Figura 1: La toma de decisiones y su aplicación son funciones distintas, alimentadas por múltiples fuentes de señales.
34.3 Recursos, sujetos y superficies protegidos
Zero Trust comienza identificando los recursos que realmente necesitan protección. En las , el recurso no es solo el nombre de host o el . Puede ser una operación, un registro, un campo confidencial, un conjunto de datos, una cola, un secreto, una clave de firma o una función administrativa. Cuanto más precisa sea la clasificación, más granular puede ser la política.
El tema también necesita ser modelado correctamente. La misma solicitud puede llevar la identidad del usuario final, la aplicación cliente y la carga de trabajo intermedia. En los flujos delegados, el debe distinguir quién actúa y on-behalf-of quién. Perder esta distinción produce genéricos, registros incompletos y privilegios excesivos.
La superficie protegida incluye interfaces públicas, integraciones B2B, internas, administrativos, canales de mensajería y dependencias externas. El inventario debe enumerar el propietario, los datos procesados, el método de autenticación, la exposición, los consumidores, la criticidad y las políticas. Es difícil incorporar desconocidas, antiguas o de prueba a una estrategia de Zero Trust porque no tienen un contexto de riesgo ni un ciclo de vida gobernado.
La clasificación de los datos influye en la decisión. Un consumidor autenticado puede recibir campos básicos pero no datos financieros completos. Es posible que una carga de trabajo autorizada para leer un registro no tenga permiso para exportar miles de registros. El principio de privilegio mínimo debe cubrir el volumen, el propósito, el tiempo, el contexto y las propiedades del objeto.
Diferentes identidades participan en una misma convocatoria
Figura 2: La identidad efectiva de una llamada se compone de varias capas, no solo del usuario.
34.4 Decisión por solicitud y confianza dinámica
En una , la unidad de decisión práctica suele ser la solicitud o una sesión corta asociada con un conjunto limitado de operaciones. La identifica al sujeto, valida la credencial, extrae , consulta atributos cuando es necesario y evalúa la política aplicable al método, ruta, recurso y contexto. La autorización no debe inferirse simplemente porque se aceptó una conexión anterior.
La confianza dinámica significa que el resultado puede cambiar cuando cambian las señales. Un usuario autenticado con puede perder el acceso si el dispositivo se ve comprometido, la ubicación se vuelve incompatible, se revoca el o aumenta el riesgo de la sesión. En aplicaciones críticas, las acciones sensibles pueden requerir una nueva autenticación, pruebas adicionales o confirmación fuera de banda.
La evaluación continua no implica que cada llamada dependa de decenas de servicios remotos. Las políticas se pueden compilar y distribuir a las locales; los atributos pueden tener cortos; las decisiones de bajo riesgo se pueden almacenar en caché; y los eventos de revocación pueden invalidar el estado. El desafío es equilibrar la puntualidad, la disponibilidad, la latencia y la seguridad.
El diseño debe especificar el comportamiento cuando las señales no están disponibles. Una de consulta pública puede funcionar de forma degradada, mientras que una transferencia de alto valor debe denegar el acceso si no se puede consultar el , el servicio antifraude o la confirmación de postura. La apertura y el cierre ante fallos son decisiones por clase de operación, no opciones globales.
Figura 3: La autorización es una secuencia de identificación, evaluación contextual, decisión y ejecución.
34.5 Identidad humana, aplicación, carga de trabajo y dispositivo
La identidad humana normalmente la establece un proveedor de identidad con autenticación multifactor y políticas de riesgo. El resultante debe tener un issuer, un tema, una audience, un , una hora y un nivel de autenticación adecuados. Los grupos corporativos son útiles, pero a menudo demasiado amplios para una autorización detallada; Los atributos de función, unidad, relación y contexto pueden complementar la decisión.
La aplicación del cliente también es un tema. En 2.0, client_id identifica el software registrado y el tipo de cliente influye en los controles disponibles. Los clientes confidenciales se autentican en el ; Los clientes públicos dependen de y de la protección del medio ambiente. En las integraciones B2B, la identidad de la organización y el sistema asociado deben estar separadas de la identidad del usuario final.
La identidad de la carga de trabajo evita credenciales estáticas compartidas entre servicios. Los certificados de corta duración, los ID de SPIFFE, las identidades administradas y los diseñados para cuentas de servicio le permiten vincular la llamada a la instancia o servicio en ejecución. En Kubernetes, las ServiceAccounts y la federación de identidades con la nube reducen la necesidad de secretos permanentes en los Pods.
El dispositivo proporciona señales adicionales: registro, integridad, control de versiones, cifrado, postura EDR y cumplimiento. Estas señales no deben confundirse con la identidad del usuario. A una persona válida en un dispositivo no administrado se le puede otorgar acceso limitado; una carga de trabajo válida en un nodo comprometido puede requerir cuarentena. Las políticas maduras combinan las dimensiones sin transformar ninguna de ellas en confianza absoluta.
Tabla 2: Zero Trust combina identidades y señales sin asumir que un solo atributo sea suficiente.
Identidad
Ejemplos de evidencia
Uso en política
Usuario
sub, acr, amr, grupos, riesgo.
Acciones permitidas, intensificación y segregación de funciones.
Solicitud
ID de cliente, certificado, declaración de software.
Consumidor, canal, cuotas y scopes.
Carga de trabajo
ID de SPIFFE, identidad administrada, ServiceAccount.
Llamadas entre servicios y acceso a backends.
Dispositivo
registro, postura, EDR, versión.
Acceso adaptativo y reducción de privilegios.
34.6 , y proof-of-possession
Los al portador los utiliza quien los posee. Si se copian de registros, memoria, navegador o canal comprometidos, se pueden reutilizar hasta que caduquen o sean revocados. Por lo tanto, necesitan transporte protegido, almacenamiento seguro, audience restringida, mínimos y una vida útil corta. Zero Trust no elimina los al portador, pero reduce su y asume que las filtraciones son posibles.
Los sender-constrained vinculan el uso del a una clave criptográfica. En , puede vincular el al certificado del cliente, mientras que utiliza una prueba firmada a nivel de aplicación y vincula el a una clave pública. El resource server valida no sólo el , sino también la demostración de posesión de la clave correspondiente.
es especialmente adecuado para integraciones de servidor a servidor, cargas de trabajo y entornos con operativa. puede ser utilizado por clientes que no pueden presentar certificados de manera conveniente. Ambos reducen el valor de un robado, pero no evitan el uso indebido por parte de un cliente legítimo comprometido ni reemplazan la autorización y la protección de de la operación en sí.
En de alto riesgo se debe combinar la proof-of-possession con idempotencia, firma de mensajes cuando sea necesario, audience específica y detección de anomalías. Los amplios, la larga duración y la propagación indiscriminada entre microservicios contradicen el privilegio mínimo, incluso si están vinculados criptográficamente.
Figura 4: Vincular el a una clave agrega una condición criptográfica para su uso.
Tabla 3: La proof-of-possession mejora la resistencia a la replay de tokens, pero requiere una validación y operación correctas.
Mecanismo
Evidencia presentada
Uso típico
Precaución
Bearer
Sólo la token.
API generales y flujos OAuth comunes.
Estricta protección contra fugas.
mTLS de OAuth
Certificado de cliente en TLS.
B2B y cargas de trabajo con PKI.
Ciclo de vida del certificado y terminación TLS.
DPoP
Prueba JWT firmada por solicitud.
Clientes de aplicaciones y API HTTP.
Validación de htm, htu, iat, jti y nonce cuando se utilizan.
34.7 Autorización granular y arquitectura de políticas
es útil para responsabilidades estables, pero rara vez es suficiente por sí solo para complejas. permite combinar atributos del sujeto, recurso, acción y entorno. ReBAC representa relaciones, como director, representante o miembro de una organización. Las políticas pueden combinar estos modelos siempre que sigan siendo comprensibles, comprobables y auditables.
La arquitectura necesita definir dónde ocurre la decisión. Una puede consultar un central, utilizar políticas locales como código o combinar decisiones. El sigue siendo responsable de las reglas que dependen del estado del negocio y de evitar el acceso directo que pasa por alto la . En una malla de servicios, la autorización entre cargas de trabajo puede ocurrir en el , mientras que la autorización de objetos permanece en la aplicación.
Los proporcionan atributos de directorio, CMDB, inventario de dispositivos, clasificadores de datos, riesgo y contexto. El PAP gestiona las políticas y su ciclo de vida. Para la producción, las políticas necesitan control de versiones, revisión, pruebas unitarias, simulaciones con tráfico histórico, aprobación, implementación y reversión gradual.
El resultado de la decisión debe ser explicable. No es necesario que los registros expongan la política completa, pero deben registrar el identificador de la decisión, la versión de la política, el tema, el recurso, la acción, el resultado y el motivo principal. Esta evidencia es esencial para la auditoría, la retroubleshooting y la investigación de incidentes.
Figura 5: La autorización depende de una aplicación no eludida y de una cadena gobernada de políticas y atributos.
es un natural para el tráfico norte-sur. Puede terminar , validar , verificar certificados, consultar , aplicar límites de velocidad, eliminar credenciales externas, propagar identidades controladas y registrar decisiones. Su posición central facilita la coherencia, pero no permite convertir la pasarela en el único elemento de seguridad.
La debe validar el issuer, la audience, la firma, la hora, el type y los obligatorios. Las políticas genéricas basadas únicamente en la presencia de generan una falsa sensación de protección. La ruta debe estar asociada con una política de autorización explícita y los administrativos deben tener controles aún más restrictivos.
La identidad propagada al debe protegerse contra la suplantación de identidad. Los internos deben eliminarse de la solicitud externa y la debe volver a crearlos; el canal hacia el debe estar autenticado; y el servicio debe aceptar estos solo de fuentes autorizadas. Como alternativa, la puede intercambiar el por un de audience específico o utilizar credenciales de carga de trabajo.
La alta disponibilidad requiere evaluar las dependencias de las : introspección, , , KPS, directorios y servicios de riesgo. Los cachés deben respetar la caducidad, la revocación y el control de versiones. Las métricas deben separar los errores de autenticación, las denegaciones de políticas, la indisponibilidad de , los errores de y los bloqueos de umbral.
Tabla 4: La API Gateway debe producir diagnósticos por paso, sin devolver detalles confidenciales al consumidor.
Paso en la puerta de entrada
Control de Zero Trust
Falta que debe diferenciarse
TLS/mTLS
Canal protegido e identidad de pares.
Certificado, SNI, CA o revocación no válidos.
token
Emisor, audience, firma, hora y cnf.
Token no válido, caducado o desvinculado.
politica
Sujeto + acción + recurso + contexto.
Denegación legítima o PDP no disponible.
Propagación
Cabeceras o token interno controlado.
Spoofing, audience equivocada o claims excesivas.
34.9 Malla de servicios, Kubernetes y tráfico este-oeste
La seguridad perimetral no impide el movimiento lateral si los servicios internos confían en cualquier fuente de la red. Una malla de servicios puede proporcionar automático, y autorización L4/L7 entre servicios. Cada llamada se asocia con la identidad de la carga de trabajo, independientemente de la efímera o del nodo en el que se ejecuta el Pod.
En Kubernetes, la identidad puede provenir de ServiceAccounts y estar federada con proveedores de nube. Los pods no deben compartir credenciales estáticas de larga duración. controla las acciones en la del clúster, mientras que las políticas de malla y NetworkPolicies controlan las comunicaciones de la carga de trabajo. Estos mecanismos actúan en diferentes planos y deben diseñarse juntos.
La política de malla puede restringir qué cargas de trabajo llaman a qué servicio, puerto, método o ruta. Para la autorización on-behalf-ofl usuario, el puede evaluar las propagadas, pero se deben garantizar el origen y la integridad. El sigue siendo necesario para decisiones basadas en objetos, saldos, relaciones o estado comercial.
La adopción gradual debería evitar la creencia de que el modo permisivo es un estado final. Primero, se inventariaría el tráfico; luego, se habilitan y la identidad; entonces las políticas explícitas reemplazan los permisos amplios. La telemetría ayuda a detectar dependencias ocultas antes del bloqueo.
Figura 6: La malla reduce la confianza implícita entre cargas de trabajo y permite la aplicación cerca del servicio.
34.10 , salida y protección de datos
La limita las vías de comunicación para reducir la superficie de ataque y el radio de impacto. En las , la segmentación puede utilizar la identidad de la carga de trabajo, el espacio de nombres, el dominio, la sensibilidad y el propósito, en lugar de depender únicamente de las direcciones . Las políticas de red, las políticas de malla, los firewalls y las internas pueden cooperar, siempre que se definan la propiedad y la precedencia.
La salida controlada es una parte importante del modelo. Una carga de trabajo comprometida no debe poder acceder a ningún destino de Internet, metadata de la nube o servicio interno. Las de salida, las listas permitidas de nombres e identidades, el controlado, los servidores y la supervisión ayudan a limitar la exfiltración y la . Las reglas deben considerar resolución, redirecciones, privadas, protocolos y cambios de destino.
Zero Trust se basa en recursos y datos. El cifrado en tránsito y en reposo es necesario, pero las políticas también deben controlar la minimización, el enmascaramiento, la finalización, la retención y la exportación. Una que devuelve campos innecesarios o permite una paginación ilimitada puede violar el privilegio mínimo incluso con una autenticación sólida.
Los secretos, claves y certificados deben tener , rotación y seguimiento de uso. El acceso puede estar mediado por servidores con reconocimiento de identidad, almacenes secretos e identidades administradas. Las credenciales compartidas entre servicios evitan la asignación y revocación selectivas, lo que aumenta el radio de impacto de un compromiso.
Tabla 5: La microsegmentación es solo una capa de una estrategia orientada a los recursos.
capa
Objetivo
Ejemplo de control
Red
Reducir posibles caminos.
NetworkPolicy, firewall y puerta de salida.
Identidad
Vincular llamada a asunto verificable.
mTLS, identidad de carga de trabajo y token.
Solicitud
Restringir acción y objeto.
ABAC, ReBAC y autorización de recursos.
Datos
Minimizar la exposición y el impacto.
Enmascaramiento, clasificación y límites de exportación.
34.11 Telemetría, riesgo y respuesta adaptativa
Las decisiones adaptativas dependen de una telemetría confiable. , , malla, , , SIEM y aplicación producen señales que pueden indicar anomalías: cambios de ubicación, volumen inusual, enumeración de objetos, fallas repetidas, postura degradada del dispositivo, nuevo certificado o acceso no estándar. Estas señales deben normalizarse, correlacionarse y evaluarse con una latencia compatible con el caso de uso.
La respuesta no tiene por qué ser simplemente bloquear. La arquitectura puede requerir , reducir , limitar tasas, deshabilitar la exportación, marcar la sesión para revisión o revocar credenciales. La elección debe considerar el impacto y la confiabilidad del detector. Los controles demasiado agresivos sin retroalimentación crean indisponibilidad y fomentan excepciones permanentes.
Zero Trust Observability necesita registrar decisiones, no solo tráfico. Las métricas útiles incluyen la proporción de permiso/denegación por política, latencia de , aciertos de caché, decisiones sin atributos, fallas de propagación, uso de credenciales obsoletas, cobertura , flujos no inventariados y tiempo de revocación. Los seguimientos ayudan a identificar qué o tomó la decisión final.
Es necesario considerar la privacidad y seguridad de las señales mismas. Los registros de autorización pueden contener identificadores, grupos, riesgos y contexto. La recopilación debe minimizarse, protegerse mediante acceso y retención, y nunca incluir completos, claves privadas o datos confidenciales innecesarios.
El escaneo continuo no es vigilancia indiscriminada
La recaudación debe ser proporcional, finalista y protegida. Zero Trust requiere señales suficientes para las decisiones y la investigación, pero no justifica el registro de credenciales, cargas útiles sensibles o atributos sin necesidad operativa.
34.12 Disponibilidad y fallas de los componentes de confianza
Una arquitectura Zero Trust agrega componentes críticos al camino: , , introspección, , , servicio de riesgo e infraestructura de certificados. Cada dependencia necesita , redundancia, tiempo de espera, caché, respaldo y runbook. Una política segura que haga que todas las no estén disponibles debido a una simple falla está operativamente incompleta.
El de claves públicas suele ser seguro cuando se respeta la rotación y los identificadores. El de decisiones es más delicado porque los atributos y el riesgo pueden cambiar. La caché debe incluir asunto, recurso, acción, contexto relevante, versión de política y . Los eventos de revocación pueden invalidar las decisiones antes de su vencimiento.
La puede ser aceptable para operaciones públicas o de bajo impacto, siempre que el modo degradado sea explícito y monitoreado. El cierre de fallas es apropiado para operaciones financieras, administrativas o de datos confidenciales. Entre los extremos, la organización puede ofrecer lecturas limitadas, congelar cambios o requerir un canal alternativo.
Es necesario probar la recuperación. La rotación de certificados, la indisponibilidad del , la reversión de políticas, la pérdida de caché y el cambio de issuer son escenarios de continuidad. Los ejercicios controlados muestran si el equipo puede distinguir una negación legítima de una falla de infraestructura.
Tabla 6: La disponibilidad y la seguridad deben modelarse juntas.
dependencia
Riesgo
Estrategia
JWKS/PKI
Clave no disponible o rotación incorrecta.
Cache, transferencia de claves y monitoreo.
PDP
Latencia o indisponibilidad.
Instancias locales, política de tiempo de espera y degradación.
PIP/riesgo
Atributo faltante o desactualizado.
TTL, calidad de señal y decisión conservadora.
IdP
Error al iniciar sesión o emitir.
Redundancia, sesiones cortas existentes y plan de continuidad.
34.13 Gobernanza y viaje de madurez
Adoptar Zero Trust es un viaje de transformación, no un proyecto único. Un punto de partida práctico es inventariar recursos, identidades, flujos y políticas; eliminar credenciales compartidas; centralizar la identidad; comunicaciones seguras; tomar decisiones explícitas; y ampliar la observabilidad. El orden exacto depende del riesgo y la capacidad de la organización.
Los modelos de madurez ayudan a organizar el trabajo en pilares. CISA Zero Trust Maturity Model 2.0 funciona con identidad, dispositivos, redes, aplicaciones y cargas de trabajo, datos, visibilidad/análisis y automatización/orquestación. Para las , estos pilares se traducen en identidad, postura, , políticas de , protección de datos, telemetría y respuesta automática sólidas.
Las excepciones necesitan titular, justificación, , plazo y compensación. Las políticas y atributos deben contar con catálogo, versionado y evidencia de prueba. Las métricas de madurez deben medir la cobertura y los resultados: porcentaje de inventariadas, de audience restringida, cargas de trabajo sin credenciales estáticas, tráfico , políticas explícitas, tiempo de revocación e incidentes de acceso inadecuado.
La estrategia debe evitar el big bang. Un modo de observación identifica flujos; las políticas se aplican a grupos controlados; se analizan las negaciones; y la cobertura crece por dominio. Los resultados de seguridad deben combinarse con métricas de latencia, disponibilidad y experiencia del cliente.
Evolución de la madurez: de controles aislados a decisiones adaptativas
Figura 7 - La madurez crece a través de la coordinación entre pilares, no a través de la optimización aislada de un producto.
34.14 Retroubleshooting e investigación
Se puede crear una denegación de Zero Trust en varias capas: certificado, , postura, política, límite de tasa, malla o regla comercial. La retroubleshooting comienza identificando la que respondió, el decision_id y la etapa de la falla. El consumidor debe recibir una respuesta segura; Los detalles permanecen en registros protegidos.
En la autenticación, verifique la cadena del certificado, el issuer, la audience, la firma, la hora, el y la vinculación. En autorización, compare asunto, acción, recurso, contexto, atributos proporcionados y versión de política. En malla, confirme la identidad de la carga de trabajo, el modo y la regla aplicada. En Kubernetes, valide ServiceAccount, etiquetas, espacio de nombres y NetworkPolicy.
Relojes incorrectos, cachés antiguos, rotación incompleta, eliminados, audiences incorrectas y atributos faltantes producen incidentes intermitentes. Los seguimientos distribuidos deben preservar la correlación sin propagar . Cuando participa un externo, su latencia y resultado deben aparecer como lapso o evento.
La investigación debe evitar desactivar controles amplios en un primer intento. Una derivación temporal debe ser mínima, aprobada, monitoreada y eliminada. De lo contrario, la organización convierte la retroubleshooting en la creación de deuda de seguridad.
Figura 8: La investigación sigue la cadena de identidad, contexto, política, aplicación y recurso.
Tabla 7: la respuesta HTTP es solo el síntoma final; la evidencia necesita localizar la decisión.
Síntoma
Hipótesis iniciales
evidencia
401 después de la rotación
JWKS antiguos, aire acondicionado incorrecto o desviación del reloj.
registros infantiles, cadenas, caché, fechas y IdP.
403 solo en una ruta
Política/scope/audience u autorización de objeto.
ID de decisión, ID de política, claims y recursos.
falla intermitente
PDP regional, caché, señal de riesgo o propagación.
Latencia por instancia y seguimiento completo.
Servicio interno bloqueado
Identidad de carga de trabajo o política de malla.
ID SPIFFE, certificado, etiquetas y regla L7.
34.15 Estudios de casos y laboratorios
Caso 1: integración B2B: un socio utiliza Client Credentials con . El tiene una audience específica y mínimos; la valida el certificado y el enlace del ; el recibe una identidad interna controlada. La rotación se produce con certificados superpuestos y la telemetría identifica a los consumidores que todavía se quedan con el material antiguo.
Caso 2: microservicios en Kubernetes: las cargas de trabajo reciben identidades cortas y se comunican a través de una malla de servicios con . Las políticas permiten solo los flujos necesarios y las NetworkPolicies limitan las rutas de red. La identidad del usuario final se propaga de forma verificable sólo cuando sea necesario; Las decisiones sobre objetos permanecen en el servicio de dominio.
Caso 3: transacción financiera adaptable: se autoriza una transferencia común con una sesión válida, un dispositivo compatible y un límite diario. Cuando el riesgo aumenta, el requiere un aumento y reduce el valor máximo. El resultado, las señales y la versión de la política se auditan sin registrar el ni la carga útil completa.
Laboratorios sugeridos
1) Modelar tema, recurso, acción y contexto para tres . 2) Implementar una política de en un entorno de prueba. 3) Compare el al portador y / . 4) Configurar la autorización de la carga de trabajo en la malla de servicios. 5) Simular la indisponibilidad de y validar el modo degradado. 6) Cree un panel de cobertura, decisiones y latencia.
Resumen del capítulo
Zero Trust elimina la confianza implícita basada únicamente en la red, la propiedad o la autenticación anterior. La protección se centra en recursos y decisiones explícitos. En las , esto significa identificar sujetos, clasificar datos, validar credenciales, evaluar el contexto, aplicar autorización por acción y objeto y observar continuamente el resultado.
Las , las mallas de servicios y los desempeñan funciones de cumplimiento complementarias. autentica a sus pares; los vinculados reducen la ; Políticas expresas , y ReBAC; la identidad de la carga de trabajo reemplaza los secretos estáticos; la reduce el movimiento lateral; y la telemetría apoya la respuesta adaptativa. Ningún control único implementa Zero Trust.
La arquitectura debe estar disponible, gobernable y explicable. Las políticas, atributos y cachés tienen un ciclo de vida; las dependencias críticas requieren y respaldo; las denegaciones deben ser investigables; y la adopción debe avanzar gradualmente según el riesgo y la propiedad. La madurez se mide por la cobertura y la reducción efectiva de privilegios y el radio de impacto.
Siguiente paso del curso
El siguiente capítulo aplica los fundamentos de las , la identidad, la seguridad y la gobernanza al ecosistema de Open Finance y Open Banking Brasil, en el que la confianza federada, el consentimiento, los certificados, los estándares de seguridad y la alta disponibilidad son requisitos centrales.
Lista de verificación de Zero Trust para
Se inventarian y clasifican las , las operaciones, los datos, los propietarios y los consumidores.
Ninguna ubicación de red se utiliza como prueba suficiente de autorización.
Usuario, cliente, carga de trabajo y dispositivo son identidades separadas y correlacionables.
Los tienen una audience, y vida útil mínimos; Las credenciales estáticas son excepciones controladas.
Se aplica o cuando la reducción de la reproducción justifica el costo operativo.
Las políticas evalúan el tema, la acción, el recurso y el contexto y tienen cuando corresponde.
Los no se pueden eludir y los mantienen la autorización comercial y de objetos.
Las cargas de trabajo utilizan identidades cortas; La malla de servicio y las NetworkPolicies reducen el movimiento lateral.
La salida, los secretos, los datos y las exportaciones están controlados por un propósito y un privilegio mínimo.
Las decisiones, el ID_política, la versión, la latencia y los motivos se pueden observar sin registrar secretos.
Las fallas de , , , y tienen modo de degradación y runbook probados.
El recorrido de madurez tiene métricas de cobertura, fecha límite, propietario y eliminación de excepciones.
Ejercicios
Explique por qué una red privada no debería otorgar autorización automática a una .
Asigne el motor de políticas, el administrador de políticas y el a una arquitectura de y malla de servicios.
Diferenciar identidad de usuario, aplicación, carga de trabajo y dispositivo en una sola llamada.
Compare el de portador, y desde el punto de vista de reproducción y operación.
Diseñar una política de consulta y modificación de datos financieros.
Defina el comportamiento de falla de apertura, falla de cierre y degradado para tres clases de operación.
Proponer y salida controlada para una en Kubernetes.
Describir qué señales deben registrarse para explicar una decisión de acceso.
Cree un plan de migración de credenciales estáticas a .
Defina indicadores de madurez Zero Trust para una plataforma empresarial.
Glosario
Tabla 8 - Vocabulario esencial del capítulo.
Término
Definición
Verificación continua
Uso recurrente de señales actuales para mantener, limitar o revocar el acceso.
Denegación por defecto
Postura en la que se deniega el acceso no permitido explícitamente.
DPoP
Mecanismo de proof-of-possession de OAuth a nivel de aplicación.
cerrado por falla
Comportamiento que niega el acceso cuando no se puede obtener la decisión segura.
Apertura fallida
Comportamiento que permite el acceso en caso de fallo, aplicable sólo a riesgos explícitamente aceptados.
Microsegmentación
Restricción granular de las vías de comunicación para reducir el movimiento lateral.
papa
Punto responsable de la administración y ciclo de vida de las políticas.
PDP
Componente que evalúa la política y produce una decisión de autorización.
PEP
Componente que aplica la decisión de acceso al tráfico o recurso.
PIP
Fuente de atributos y contexto utilizado por la decisión.
Policy Administrator
Componente que ejecuta la decisión del motor de políticas y establece o finaliza el acceso.
Policy Engine
Componente lógico que decide conceder, denegar o revocar el acceso.
Sender-constrained token
Token cuyo uso requiere acreditar la posesión de una clave vinculada.
Autenticación mejorada
Requisito de autenticación más estricto para acciones o alto riesgo.
Identidad de carga de trabajo
Identidad asignada al software, servicio o instancia de ejecución.
Arquitectura de Zero Trust
Arquitectura que elimina la confianza implícita y protege los recursos con decisiones explícitas.
Referencias técnicas
SP 800-207: . 2020.
SP 800-207A: un modelo de arquitectura Zero Trust para control de acceso en aplicaciones nativas de la nube en entornos de múltiples ubicaciones. 2023.
CISA - Modelo de Madurez Zero Trust, Versión 2.0. 2023.
SP 800-204B: control de acceso basado en atributos para aplicaciones basadas en microservicios que utilizan una malla de servicios. 2021.
SP 800-204C: Implementación de DevSecOps para una aplicación basada en microservicios con una malla de servicios. 2022.
6750: uso de de portador 2.0.
8705: vinculados a certificados y autenticación de cliente Mutual- de 2.0.
9449: 2.0 que demuestra proof-of-possession en la capa de aplicación ( ).
OpenID Foundation: OpenID Connect Core y especificaciones relacionadas.
Proyecto SPIFFE - Especificaciones y documentación SPIFFE y SPIRE.
Documentación de Kubernetes: cuentas de servicio, , políticas de red y seguridad de pod.
Documentación de Istio: seguridad, autenticación de pares y política de autorización.
Nota de actualización
Zero Trust es una estrategia evolutiva y depende de la versión del producto, el modelo de amenaza y el contexto regulatorio. Antes de aplicar los ejemplos, valide las especificaciones oficiales, la , la estructura, el proveedor de identidad y el soporte de la plataforma implementada.
