Implementar una estrategia Zero Trust: roles, responsabilidades y métricas

Quien hoy quiera implementar una estrategia Zero Trust se da cuenta pronto: el verdadero obstáculo rara vez es la falta de una herramienta, sino la falta de claridad. Zero Trust es un modelo operativo para identidades, dispositivos, redes, datos y aplicaciones. Desplaza las decisiones de „lo interno es de confianza“ a „cada acceso se verifica de forma continua“. Esto incide profundamente en procesos: permisos, gestión de cambios, respuesta a incidentes, evidencias de auditoría y, no menos importante, la experiencia del usuario.

Para que una iniciativa Zero Trust no termine como una colección de medidas de seguridad aisladas, hacen falta tres elementos que a menudo faltan en la práctica: (1) un modelo de roles y responsabilidades que haga vinculantes a TI, Security y las áreas de negocio, (2) políticas aplicables que puedan integrarse en la operación y en los proyectos, y (3) métricas que hagan transparente el progreso y el riesgo, sin generar un monstruo de reporting.

Este artículo ofrece precisamente eso: una estructura de gobernanza práctica, una lógica RACI para los componentes críticos y un conjunto de KPI que resulta fiable tanto para la dirección de TI como para Compliance y Auditoría. Los términos técnicos se contextualizan brevemente para que decisores y responsables de operación hablen el mismo lenguaje.

Implementar una estrategia Zero Trust: qué significa Zero Trust en la práctica (y qué no)

Zero Trust se malinterpreta con frecuencia como „todo está prohibido hasta que se permita explícitamente“. En la práctica no se trata de un grado máximo de RESTricción, sino de confianza controlada con una justificación demostrable. Los principios fundamentales se pueden reducir a tres directrices operativas:

• Verificar explícitamente: el acceso se vincula a la identidad, al estado del dispositivo, al contexto (ubicación, hora, riesgo) y al recurso. Los mecanismos típicos son MFA (autenticación multifactor) y Conditional Access (reglas de acceso basadas en contexto).
• Principio de mínimo privilegio: cada persona recibe únicamente los permisos necesarios para la tarea y solo durante el tiempo imprescindible. Esto afecta tanto a usuarios finales como a cuentas de administrador y cuentas de servicio.
• Asumir la brecha: se planifica como si un atacante ya estuviera dentro de la red. De ello se desprenden la segmentación, el registro exhaustivo y la respuesta rápida.

Lo que Zero Trust no es: un producto único, un proyecto puramente de red o una medida exclusiva de IAM. Una „arquitectura Zero Trust“ es más bien una visión objetivo que se implementa de forma gradual a través de varios dominios: identidad (IAM), cuentas privilegiadas (PAM), endpoints (gestión de endpoints/EDR), acceso a la red (ZTA/Proxy/sustituto de VPN), acceso a los datos (DLP/Clasificación) y observabilidad (registro/SIEM).

Por qué los roles y las responsabilidades determinan el éxito o el estancamiento

Zero Trust genera muchas nuevas “pequeñas decisiones”: ¿Puede una cuenta de servicio acceder a bases de datos de producción sin MFA? ¿Qué requisitos de dispositivo aplican para proveedores externos? ¿Qué excepciones son permisibles, por cuánto tiempo y quién las aprueba? Si estas decisiones no están ancladas en un modelo claro, surgen tres errores típicos:

• Excepciones en la sombra: los equipos eluden las políticas porque los procesos son lentos o no hay nadie responsable. Resultado: el riesgo real aumenta, la capacidad de auditoría disminuye.
• Bloqueo excesivo: Security aplica reglas estrictas sin retroalimentación operativa. Resultado: el trabajo productivo sufre, los proyectos se retrasan y aumenta la presión para desactivar los controles.
• Ceguera de medición: se hace “mucho trabajo”, pero nadie puede decir si el riesgo disminuye o solo aumenta el esfuerzo.

La contramedida es una gobernanza clásica, pero adaptada concretamente a Zero Trust: roles definidos, RACI por bloque de control y un conjunto KPI ágil que provenga directamente de los sistemas (proveedor de identidad, gestión de endpoints, SIEM, sistema de tickets).

Modelo de roles para la implementación de una estrategia Zero Trust

Según el tamaño de la empresa, los roles los ocupan personas o equipos. Lo importante: la responsabilidad no es delegable, las tareas sí. Los siguientes roles han demostrado su eficacia en la práctica:

Executive Sponsor (CIO/dirección de TI o dirección con vínculo en TI)

Asegura presupuesto y prioridad, decide conflictos entre Security y el negocio y asume riesgos de forma consciente (aceptación de riesgo). Sin un patrocinador, las excepciones se convierten en el estado normal.

CISO/Responsable de seguridad de la información

Responsable del objetivo de seguridad, de la lógica de políticas y del modelo de riesgos. Importante: no “operar todo por sí mismo”, sino concretar requisitos y gobernar mediante métricas.

Dirección del programa Zero Trust (Security/IT conjuntamente)

Orquesta la hoja de ruta, las dependencias y las olas de despliegue. Este rol es central para la priorización: qué sistemas primero, qué controles en qué profundidad y qué Quick Wins alivian de inmediato la operación (p. ej., Admin-MFA, cumplimiento de dispositivos).

IAM-Owner (Identity and Access Management)

IAM incluye identidades, roles, grupos, autenticación y aprovisionamiento (Joiner/Mover/Leaver). El IAM-Owner garantiza que los permisos sean trazables y que el acceso no se otorgue “por correo”.

PAM-Owner (Privileged Access Management)

PAM gobierna cuentas privilegiadas: accesos de administrador, cuentas break-glass, almacenamiento seguro de credenciales (credential vaulting) y grabación de sesiones. Este rol es crítico porque los privilegios son la vía de ataque más común.

Responsable de gestión de endpoints/puesto de trabajo

Responsable del estado del dispositivo (nivel de parches, cifrado, agente EDR, Secure Boot) y, por tanto, de la base para Conditional Access. Sin un cumplimiento de dispositivos limpio, Zero Trust se reduce rápidamente a “solo MFA”.

Operaciones de red y plataforma

Implementa segmentación, rutas de acceso y controles de plataforma (p. ej., ZTNA-Gateways, proxy, reglas de firewall, controles de seguridad en la nube). Importante: rutas estándar documentadas en lugar de rutas especiales individuales por aplicación.

Application Owner / Responsables de sistema

Responsables funcional y técnica por aplicaciones y datos. Deciden sobre clasificación de datos, patrones de integración, cuentas de servicio y ventanas de implementación. Sin Application Owner, las reglas de excepción bien definidas son casi imposibles.

Compliance/Protección de datos/Enlace de auditoría

traduce los requisitos regulatorios (p. ej. NIS2 como directiva de la UE para ciberseguridad, ISO 27001 como estándar de sistema de gestión) en requisitos de evidencia verificables: ¿Qué logs, qué autorizaciones, qué versiones de políticas se presentan en la auditoría?

Matriz RACI: ¿Quién decide, quién implementa, quién aporta evidencias?

Una matriz RACI (Responsible, Accountable, Consulted, Informed) evita que “todos estén de alguna forma implicados”. Abajo un recorte práctico para bloques típicos de Zero-Trust. Adapte los nombres de rol a su organización, no la lógica.

RACI (Kurzform, exemplarisch)

Baustein / Entscheidung                     R            A            C                          I
-----------------------------------------------------------------------------------------------------------
Zero-Trust-Policy-Set (Grundregeln)         CISO         Sponsor      IT-Betrieb, Compliance       Fachbereiche
MFA-Standard (wer, wann, Ausnahmen)         IAM-Owner     CISO         Service Desk, Compliance     Alle Nutzer
Conditional Access (Gerät, Standort, Risiko)IAM-Owner     CISO         Endpoint-Owner, SOC          IT-Leitung
PAM-Umfang (Admin, Drittparteien, Notfall)  PAM-Owner     CISO         IT-Betrieb, Audit            Sponsor
Geräte-Compliance-Standards                 Endpoint-OwnerIT-Leitung   CISO, Betriebsrat/HR         Nutzer
Segmentierung / Zugriffspfade               Netzbetrieb   IT-Leitung   CISO, App Owner              SOC
Logging/SIEM-Use-Cases & Retention          SOC/SIEM-OwnerCISO         Datenschutz, IT-Betrieb      Audit
Ausnahmeprozess (Risk Acceptance)           Programmlead  Sponsor      CISO, Compliance, App Owner  Audit
On-/Offboarding (Joiner/Mover/Leaver)       IAM-Owner     IT-Leitung   HR, Fachbereich              CISO
Third-Party-Access (Dienstleister)          PAM-Owner     IT-Leitung   Einkauf, Compliance, App Ow. CISO

Importante para la auditabilidad: para cada bloque debe quedar claro dónde se generan las evidencias (p. ej. tickets, repositorios de políticas, IdP-Logs, PAM-Reports) y quién puede entregarlas de forma reproducible si se solicita.

Gobernanza que funciona en operación: políticas, excepciones y control de cambios

Zero Trust vive de políticas. Una política no es solo un documento, sino una regla legible por máquina (p. ej. una regla de Conditional Access) más la gobernanza asociada: versionado, aprobación, despliegue, monitorización, excepciones.

Capas de política que debería separar con claridad

• Principios: pocas directrices estables (p. ej. “accesos de administrador solo mediante PAM”).
• Estándares: concretos y verificables (p. ej. “MFA para todos los accesos remotos”, “Los dispositivos deben estar cifrados”).
• Aplicación técnica: reglas en sistemas (IdP, Endpoint, red, nube).
• Excepciones: temporales, basadas en riesgo, con propietario y medidas compensatorias (p. ej. segmentación más estrecha, supervisión adicional).

Plantilla: contenido mínimo para un proceso de excepciones (a prueba de auditoría)

Las excepciones son normales, pero deben estar controladas. Un estándar práctico es una plantilla de ticket o workflow con los siguientes campos obligatorios:

• Recurso/aplicación, grupos de usuarios o cuentas afectadas
• política concreta de la que se desvía
• justificación (técnica/organizativa), impacto en el negocio sin la excepción
• evaluación del riesgo (p. ej. bajo/medio/alto) y clasificación de datos
• medidas compensatorias (Logging, segmentación, permisos temporales, monitorización)
• fecha de inicio, fecha de fin (sunset), fecha de revisión
• Aprobador (Accountable) y propietario responsable (Responsible)
• Enlace de evidencia (p. ej. configuración, informe, registro de cambios)

Control de cambios: Por qué Zero Trust no es algo que se configura una vez

Nuevas aplicaciones, nuevas integraciones, M&A, migraciones a la nube, modelos de trabajo cambiantes: todo eso altera las vías de acceso. Por eso Zero Trust debe integrarse en los procesos de cambio existentes. En la práctica eso significa:

• Cada cambio con impacto en identidades o en la red recibe una verificación de impacto de seguridad (cuestionario breve).
• Las políticas se versionan; los despliegues se realizan en oleadas (piloto, grupos controlados, despliegue amplio).
• Se planifica la reversión: si una política bloquea en exceso, debe estar claro con qué rapidez y de forma controlada se restaura, sin generar brechas de seguridad.

Lógica de implementación: Priorizar por riesgo, no por el panorama de sistemas

Muchos programas fracasan porque se organizan por islas tecnológicas („primero red, luego IAM“). Es mejor una secuencia basada en riesgos a lo largo de vectores de ataque típicos y de los cuellos de botella organizativos.

Etapa 1: Estabilizar identidades y accesos privilegiados

Si un atacante toma el control de identidades, el concepto «interior/exterior» resulta irrelevante. Por eso, primero:

• MFA para todos los usuarios, en particular para accesos administrativos y remotos; limitar estrictamente las cuentas Break-Glass y usarlas de forma controlada.
• PAM para administradores y sistemas críticos (vaulting, permisos administrativos temporales, trazabilidad de sesiones).
• Inventariar y rotar las cuentas de servicio; cuando sea posible, migrar a mecanismos más modernos (p. ej., tokens de corta duración).

Etapa 2: Cumplimiento del dispositivo como condición de acceso

Conditional Access solo es tan efectivo como la calidad de los atributos del dispositivo. Defina requisitos mínimos (cifrado, nivel de parches, EDR, bloqueo de pantalla) y vincúelos a los accesos a recursos críticos.

Etapa 3: Unificar rutas de acceso (ZTNA/Proxy, segmentación)

En lugar de accesos amplios a la red (VPN clásico), se establecen rutas de acceso basadas en permisos: los usuarios solo alcanzan las aplicaciones que necesitan. Segmentación aquí no implica necesariamente microsegmentación a nivel de host, sino inicialmente: separar zonas críticas, restringir el tráfico este-oeste y segregar las rutas administrativas.

Etapa 4: Afinar la visibilidad de datos y aplicaciones

A más tardar en esta etapa los responsables de aplicaciones deben aportar: clasificación de datos, transacciones críticas, interfaces, cuentas técnicas. Zero Trust también afecta a las APIs (Application Programming Interface, es decir, interfaces definidas entre sistemas): ¿quién puede obtener qué datos con qué frecuencia y cómo se detecta el uso indebido?

Métricas: Qué debe medir para que Zero Trust sea controlable

Sin métricas, Zero Trust se convierte en una cuestión de fe. Con métricas erróneas surge activismo. Los buenos KPIs tienen tres características: (1) pueden derivarse de sistemas, (2) son útiles para la toma de decisiones, (3) son robustos frente al „maquillaje“ de cifras.

Conjunto de KPI 1: Identity & Access (IAM)

• Cobertura de MFA: proporción de cuentas de usuario activas con MFA, desglosada por usuarios internos/externos y por cuentas privilegiadas.
• Autenticación reforzada según riesgo: proporción de inicios de sesión de riesgo en los que se exigieron factores adicionales (a partir de señales de riesgo del IdP).
• Tiempos Joiner/Mover/Leaver: tiempo hasta la revocación de la cuenta tras la salida o el cambio de rol; importante para auditoría y riesgo interno.
• Cuentas huérfanas: número de cuentas sin acceso desde hace X días o sin asignación de propietario.

Conjunto de KPI 2: Privileged Access (PAM)

• Cobertura PAM de accesos administrativos críticos: proporción de flujos de trabajo administrativos que pasan por PAM (no solo «PAM está instalado»).
• Just-in-Time/Just-Enough-Access: proporción de derechos administrativos concedidos temporalmente frente a privilegios asignados de forma permanente.
• Uso de Break-Glass: frecuencia y calidad de la justificación; cada evento es un disparador de revisión.
• Rotación de credenciales: proporción de credenciales privilegiadas que se han rotado dentro de los plazos definidos.

KPI-Set 3: Device Trust (Endpoint/Workplace)

• Tasa de cumplimiento: proporción de dispositivos gestionados que cumplen los estándares mínimos (cifrado, parches, EDR).
• Dispositivos en la sombra: dispositivos detectados pero no gestionados que intentan acceder.
• Time-to-Patch (crítico): tiempo desde la disponibilidad hasta la instalación de actualizaciones de seguridad críticas (agrupado por criticidad).

KPI-Set 4: Netzwerk- und Applikationskontrollen

• Rutas de acceso reducidas: número/porcentaje de aplicaciones accesibles sin un amplio acceso de red (ZTNA/Proxy en lugar de «red abierta»).
• Violaciones de segmentación: conexiones Este-Oeste no autorizadas detectadas (a partir de telemetría de red).
• Riesgo de cuentas de servicio: número de cuentas de servicio con permisos amplios o sin rotación/propietario.

KPI-Set 5: Detection, Response und Audit-Evidence

• Completitud de registros: proporción de sistemas críticos cuyos registros de autenticación, administración y acceso llegan de forma centralizada (SIEM/plataforma de logs).
• MTTD/MTTR (tendencia): Mean Time To Detect/Respond como tendencia, no como verdad absoluta; lo importante es la consistencia del método de medición.
• Deriva de políticas: desviaciones entre el estándar definido y la configuración real (por ejemplo, reglas desactivadas, excepciones no revisadas).
• Tiempo de obtención de evidencias: tiempo para entregar para una auditoría las evidencias requeridas (tickets, informes, extractos de logs). Este es un indicador de gestión infravalorado.

Ritmo de informes: poco, pero vinculante

Un ritmo sensato es mensual a nivel operativo (Seguridad/Operaciones TI) y trimestral en el Steering (sponsor, CISO, Compliance). Lo decisivo es que cada clúster de KPI responda a una pregunta clara, por ejemplo: «¿Qué probabilidad hay de un account takeover?» o «¿Cuántas excepciones están técnicamente justificadas y son temporales?»

Perspectiva de auditoría y regulación: evidencias en lugar de declaraciones de intención

Sea ISO 27001, auditoría interna o requisitos de NIS2: las revisiones rara vez giran en torno a «¿tienen Zero Trust?», y más bien se centran en controles y su eficacia. Preguntas típicas de auditoría son: ¿cómo aseguran que solo las personas autorizadas acceden a sistemas críticos? ¿cómo se registran las acciones privilegiadas? ¿cómo se aprueban y supervisan las excepciones?

Un programa Zero-Trust preparado para auditoría produce artefactos de evidencia «por diseño»:

• Versiones de políticas con protocolo de aprobación (quién, cuándo, por qué)
• Informes del sistema: cobertura de MFA, uso de PAM, cumplimiento de dispositivos
• Evidencia en tickets: excepciones con fecha de caducidad, revisiones, aceptación de riesgo
• Registros: logs de administración y autenticación, retención central y protección de acceso para los logs (para que los logs no sean manipulables)

Nota práctica: los auditores aceptan excepciones con más facilidad cuando (1) la excepción es temporal, (2) se documenta una medida compensatoria y (3) la organización puede demostrar que reduce activamente las excepciones (métrica: „Excepciones vencidas“).

Costes, esfuerzo y consecuencias operativas: dónde Zero Trust consume recursos reales

Zero Trust tiene costes, pero muchos no aparecen como licencias, sino como esfuerzo operativo y de proyecto. Quien no lo planifique, genera frustración y TI en la sombra. Los principales impulsores de coste:

• Calidad de los datos de identidad: modelos de permisos, mantenimiento de roles, responsabilidad (¿quién es responsable de una cuenta?).
• Retrabajo de aplicaciones: aplicaciones heredadas sin autenticación moderna o con cuentas codificadas de forma fija requieren adaptaciones o gateways intermedios.
• Service Desk y comunicación: restablecimiento de MFA, inscripción de dispositivos, procesos de excepción. Buenos flujos de autoservicio reducen esta carga posteriormente de forma significativa.
• Monitorización y respuesta a incidentes: más señales implican más triage. Sin priorización por casos de uso, el SOC (Centro de Operaciones de Seguridad) se sobrecarga.

Al mismo tiempo surgen ventajas operativas si se implementa correctamente: menos derechos de administrador a largo plazo, rutas de acceso más claras, desprovisionamiento más rápido, mejor trazabilidad en incidentes. Debe considerar estas ventajas explícitamente como criterios de decisión, no esperar que sean un «producto secundario».

Lista de verificación: listo en 30 días (sin grandes debates arquitectónicos)

Los siguientes puntos están seleccionados de modo que aborden mayoritariamente la gobernanza y los fundamentos y produzcan un efecto rápido:

• Nombrar un patrocinador ejecutivo, establecer una serie de reuniones de steering para 6 meses
• Oficializar la dirección del programa Zero Trust y los responsables para IAM, PAM, Endpoint, red/SIEM
• Definir los 10 sistemas y áreas de datos más críticas (puede basarse en listas de necesidades de protección o de riesgo existentes)
• Aprobar un conjunto mínimo de políticas: MFA, acceso de administrador a través de PAM, cumplimiento de dispositivos para accesos críticos, proceso de excepciones con Sunset
• Establecer una línea base inicial de KPI: cobertura de MFA, cuentas huérfanas, uso de Break-Glass, cumplimiento de dispositivos
• Establecer el repositorio de evidencias de auditoría: ¿dónde residen las versiones de las políticas, los informes, los tickets de excepción, las pruebas de logs?

Piedras de tropiezo comunes y cómo evitarlas

«Primero hacemos la arquitectura objetivo perfecta»

Un estado objetivo es importante, pero Zero Trust es un modelo operativo iterativo. Comience con políticas mínimas bien definidas y mida los efectos. La arquitectura madura con los conocimientos obtenidos de las excepciones, los incidentes y los datos operativos.

„MFA en todas partes“ como única estrategia

MFA es necesario, pero no suficiente. Sin PAM, cumplimiento de dispositivos y registro, el riesgo por robo de tokens, malas configuraciones y cuentas con privilegios excesivos sigue siendo alto.

Responsabilidad poco clara para cuentas de servicio e interfaces

Las cuentas de servicio suelen estar «sin dueño». Establezca responsabilidad y rotación; de lo contrario permanecerá una vía de entrada permanente. Esto aplica especialmente a las integraciones entre software de negocio, bases de datos y plataformas de integración.

Demasiadas excepciones sin Sunset

Una excepción sin fecha de caducidad es una sobrescritura oculta de la política. Mida las excepciones vencidas y póngalas visibles en el steering.

Conclusión: Zero Trust es un problema de gestión con palancas técnicas

Una estrategia Zero Trust rara vez fracasa porque «la tecnología no puede», sino porque las decisiones no están bien ancladas: ¿quién establece las políticas, quién asume los riesgos, quién aporta las evidencias? Si define roles (responsables), RACI y un conjunto reducido de métricas, Zero Trust se vuelve planificable: las excepciones se controlan, la operación no se ve desbordada, y los requisitos de auditoría pueden satisfacerse con evidencias sólidas.

Comience con identidad, accesos privilegiados y cumplimiento de dispositivos, establezca un proceso de excepciones estricto con Sunset y construya su conjunto de KPIs de modo que respalde las decisiones. Entonces „Zero Trust“ dejará de ser una palabra de moda y se convertirá en una realidad operativa en su TI.