Zero Trust y las videollamadas: qué esperar

Zero Trust ya no es una idea nueva, y en muchos sitios tampoco es opcional. El NIST lo formalizó en la Special Publication 800-207 allá por agosto de 2020. Al año siguiente, la Executive Order 14028 de EE. UU. ordenó a las agencias federales adoptarlo como arquitectura de base, y en enero de 2022 el Memorando M-22-09 de la OMB lo convirtió en un plazo firme: implementación completa de Zero Trust en las agencias federales antes de que terminara el año fiscal 2024. A estas alturas es doctrina de arquitectura asentada, no una tendencia emergente, y tampoco es solo una historia de EE. UU., lo que hace que merezca la pena preguntarse qué significa realmente cuando llega en concreto a las comunicaciones de vídeo en tiempo real.

Zero Trust en una frase

Deja de confiar en una solicitud por de dónde viene, y empieza a verificarla por sus propios méritos, cada vez. El propio modelo del NIST lo concreta en unos pocos principios: el acceso se concede por sesión, no por red; la identidad y la postura de seguridad de cada activo se comprueban de forma continua, no solo al iniciar sesión; y las decisiones de política sopesan identidad, estado del dispositivo y comportamiento de forma conjunta y dinámica, en lugar de apoyarse en un perímetro fijo.

Qué significa esto realmente para una videollamada

Varios de estos principios encajan con las comunicaciones de vídeo más directamente de lo que podría parecer:

• El acceso por sesión ya es terreno conocido. Un token de corta duración que da acceso a una llamada concreta, en lugar de una cuenta permanente con acceso amplio, es exactamente el modelo que ya usan la mayoría de las plataformas WebRTC para unirse a una sesión. Zero Trust no introduce esta idea en las videollamadas, valida un enfoque hacia el que el sector ya había convergido.
• El cifrado por defecto es una ventaja real de partida (con una salvedad). WebRTC protege cada salto con DTLS-SRTP como requisito base, no como opción adicional; la telefonía y los sistemas de vídeo heredados tuvieron que añadir el cifrado después. Pero "cada salto" no es lo mismo que de extremo a extremo: en una llamada multiparticipante típica, el servidor de medios (el SFU) se sitúa entre los participantes precisamente para poder descifrar, inspeccionar y enrutar, lo que lo convierte en una parte de confianza por defecto, no en un mensajero ciego. Una lectura estricta de Zero Trust tiene que lidiar con eso.
• El dispositivo y la identidad pasan a formar parte de unirse a una llamada, no solo de iniciar sesión en una app. Un modelo Zero Trust no se detiene en "es esta la persona correcta", también pregunta si el dispositivo desde el que se conecta cumple los requisitos de seguridad de la organización antes de conceder el acceso, igual que haría con cualquier otro recurso.
• La verificación no termina cuando empieza la llamada. La monitorización continua es uno de los principios básicos del NIST, no una comprobación única en la puerta. Para una videollamada, eso significa que la plataforma sigue evaluando la sesión mientras dura, no solo en el momento en que alguien se une.

Llevando el cifrado más lejos: sacar también al servidor de medios

Si nada en la ruta de red debería gozar de confianza implícita, eso tiene que incluir al propio servidor de medios, no solo a la red entre él y los participantes. El WebRTC estándar basado en SFU no hace esto: DTLS-SRTP se negocia por separado entre cada participante y el servidor, así que el servidor tiene las claves y puede ver el medio en claro por diseño, así es como hace el trabajo de reenviar, adaptar y enrutar los streams.

Sacar al servidor de medios de ese perímetro de confianza exige dos cosas: una forma de cifrar los frames de medios con una clave que el servidor nunca tenga, y una forma de que los participantes acuerden esa clave como grupo, para empezar.

• Cifrado a nivel de frame. Los navegadores exponen un punto de enganche para esto a través de la WebRTC Encoded Transform API, conocida habitualmente como Insertable Streams: un punto de la tubería, después de codificar y antes de empaquetar, donde una aplicación puede añadir su propia capa de cifrado. SFrame (RFC 9605, agosto de 2024) estandariza exactamente esto, cada frame se cifra antes de envolverlo en RTP/SRTP, con una clave que el SFU nunca ve. El SFU sigue leyendo las cabeceras SRTP que necesita para enrutar y controlar la congestión; simplemente ya no puede descifrar el contenido.
• Acuerdo de clave de grupo. Cifrar los frames solo ayuda si cada participante puede obtener la clave correcta, de forma eficiente, a medida que la gente se une o abandona una llamada. Para eso existe MLS (Messaging Layer Security, RFC 9420, julio de 2023): un protocolo estandarizado para que un grupo acuerde y rote una clave compartida sin que el coste crezca de forma lineal con el tamaño del grupo. Ya está funcionando en producción exactamente para esto, Cisco Webex usa MLS para sus llamadas de conferencia cifradas de extremo a extremo, y Discord lo usa para el cifrado E2EE de voz y vídeo.

Junta las dos cosas y el SFU se convierte de verdad en lo que pide el propio modelo del NIST: infraestructura que mueve paquetes sin que se confíe implícitamente en su contenido. Y como MLS se diseñó para mensajería en primer lugar, la misma clave de grupo que gestiona puede proteger el chat de una llamada junto con su medio (una única capa de acuerdo de claves, no dos añadidas por separado).

Aquí es donde Zero Trust y el vídeo se vuelven especialmente interesantes: la parte a nivel de red (acceso por sesión, postura del dispositivo, verificación continua) es en gran medida terreno ya resuelto. El problema del servidor de medios como parte de confianza es el que todavía se está resolviendo activamente.

El lado europeo: NIS2 y protección de datos

El mandato federal de EE. UU. no es la única presión regulatoria que empuja hacia este modelo. La UE no tiene una única orden de "adoptar Zero Trust" como sí tiene EE. UU. con el M-22-09 de la OMB para sus agencias federales, pero la Directiva NIS2 (que los Estados miembros de la UE tenían que transponer a su legislación nacional antes del 17 de octubre de 2024) exige exactamente la misma categoría de medidas de seguridad continuas y basadas en riesgo sobre las que se construye Zero Trust: evaluación de riesgos permanente, control de acceso y detección de incidentes, no una comprobación única de perímetro.

Zero Trust también choca con una tensión real con la normativa europea de protección de datos que merece la pena nombrar con honestidad, no pasar por alto. Uno de los propios principios del NIST pide recopilar toda la información posible sobre el estado de los activos y las comunicaciones, para mejorar continuamente la postura de seguridad. El principio de minimización de datos del RGPD (artículo 5.1.c) tira por defecto en la dirección contraria: los datos personales tienen que ser "adecuados, pertinentes y limitados a lo necesario" en relación con su finalidad. La monitorización y el registro continuos (el mismo mecanismo que hace que la verificación por sesión y el rastro de auditoría de Zero Trust tengan sentido en primer lugar) hay que acotarlos de forma deliberada: proporcionados a una finalidad de seguridad real, no maximalistas por defecto solo porque más datos parezcan más seguros.

Una forma práctica de cuadrar ese círculo: pseudonimizar el propio rastro de auditoría. El RGPD define la seudonimización (artículo 4.5) como el tratamiento de datos de forma que ya no puedan atribuirse a una persona concreta sin usar información adicional, y merece la pena ser precisos sobre lo que eso hace y lo que no hace. Los datos seudonimizados siguen siendo datos personales bajo el RGPD si la reidentificación es razonablemente posible por parte de cualquiera (considerando 26); la seudonimización no saca a un rastro de auditoría del ámbito del RGPD. Lo que cambia es quién puede llegar a realizar esa reidentificación.

En la práctica, eso significa que el rastro de auditoría que mantiene un servidor de medios (quién se unió, cuándo, desde dónde) puede referirse a los participantes mediante un ID opaco e imposible de rastrear en lugar de una identidad real, con la relación entre ese ID y la persona real generada y guardada en el lado del cliente, cifrada con una clave que el proveedor del servicio nunca tiene. El servidor acaba con un rastro de auditoría completo y registrado de forma continua (exactamente lo que pide el principio de monitorización de Zero Trust) sin llegar a tener nunca la información necesaria para identificar a nadie en él. El responsable del tratamiento (la organización que gestiona la llamada, no el proveedor de infraestructura) mantiene el control exclusivo sobre cuándo, o si, una entrada llega a vincularse de nuevo con una identidad real. Esa es la forma que permite que el instinto de registro de Zero Trust y el principio de minimización del RGPD convivan en lugar de enfrentarse: la visibilidad que necesita un equipo de seguridad y la identificabilidad que restringe el RGPD resultan ser cosas separables.

Qué implica esto para la grabación y la auditoría

Ese último punto conecta directamente con algo que ya hemos tratado antes: por qué la observación silenciosa en un call center exige más auditoría, no menos. El propio principio de Zero Trust (monitorizar y registrar de forma continua el estado de cada sesión) es el mismo argumento, solo que llega desde el lado de la arquitectura de seguridad en lugar del lado del cumplimiento normativo. En cuanto una organización tiene que registrar y evaluar la actividad de forma continua como cuestión de política, una plataforma de vídeo que trate el registro como un añadido de última hora deja de ser una opción viable.

Qué esperar a partir de ahora

Ni el plazo federal de EE. UU. ni la NIS2 se aplican directamente a todas las organizaciones, pero requisitos como estos tienden a trasladarse de todos modos, a través de obligaciones con proveedores y cadenas de suministro, a contratistas y sectores regulados mucho más allá de quién está técnicamente dentro del alcance, y muchos equipos de seguridad del sector privado ya han adoptado el mismo modelo por su cuenta. El efecto práctico para las comunicaciones de vídeo: cada vez se esperará más de las plataformas que se integren con el proveedor de identidad y las herramientas de verificación de dispositivos que la organización ya tiene, en lugar de funcionar como su propio silo de confianza aparte, con su propio inicio de sesión y sus propias reglas. Para quien construye o evalúa infraestructura de vídeo en tiempo real, ese es el cambio sobre el que merece la pena planificar (no si Zero Trust va a llegar, sino cómo encaja una plataforma de vídeo en él cuando lo haga).