CLOUDFLARE ONE - ZERO TRUST

🛡️ CONTROL DEL TRÁFICO CORPORATIVO con CLOUDFLARE ONE | POLÍTICAS DNS, RED y HTTP en WINDOWS 11

Durante décadas el control del tráfico de una empresa se ha resuelto colocando un cortafuegos o un proxy en la salida de la oficina. Ese modelo funciona mientras los equipos están dentro de la oficina, y deja de funcionar en el momento exacto en que un portátil sale por la puerta: desde una red doméstica, un hotel o la conexión de un cliente, ese equipo navega sin ninguna de las políticas de la organización. El problema no es de configuración sino de arquitectura, porque el punto de control está atado a un lugar físico mientras que los usuarios ya no lo están.

En esta práctica invertimos el planteamiento. En lugar de llevar los equipos hasta el filtro, llevamos el filtro hasta los equipos mediante un agente instalado en cada uno. Desplegaremos el cliente de Cloudflare One sobre un Windows 11, lo registraremos en una organización de Zero Trust y haremos que todo su tráfico atraviese Cloudflare Gateway con independencia de la red a la que esté conectado. Sobre ese punto de paso definiremos políticas en tres capas distintas —nombres, red y contenido—, entenderemos qué ve exactamente cada una y en qué orden se aplican, activaremos la inspección TLS que hace posible el control de aplicaciones modernas, y lo demostraremos todo con un caso muy actual: permitir una única herramienta de inteligencia artificial aprobada y bloquear todas las demás.

🧰 Tecnologías empleadas

• Cloudflare One (anteriormente Zero Trust) como plataforma donde se definen las políticas y se gestionan los dispositivos.
• Cloudflare One Client (anteriormente WARP) como agente instalado en el endpoint, responsable de encaminar el tráfico hacia la plataforma.
• Cloudflare Gateway como punto de aplicación de las políticas de nombres, red y contenido.
• MASQUE sobre HTTP/3 y QUIC como protocolo del túnel, con WireGuard como alternativa.
• Windows 11 como equipo corporativo, con instalación desatendida mediante los parámetros del paquete.
• PowerShell para la instalación, el despliegue del certificado raíz y la verificación de cada capa.
• Inspección TLS y certificado raíz propio para habilitar el control a nivel de aplicación.

🎯 Objetivos de la práctica

• Comprender la diferencia entre la plataforma de gestión y el agente que se instala en los equipos, dos elementos que suelen confundirse por el cambio de nombre del producto.
• Desplegar el agente en un equipo Windows con la organización preconfigurada, sin intervención del usuario.
• Entender qué observa cada una de las tres capas de políticas, en qué momento actúa y cuál es su límite real.
• Conocer el orden de aplicación entre capas y dentro de cada capa, y por qué una política correcta puede no ejecutarse nunca.
• Activar la inspección de tráfico cifrado y desplegar el certificado raíz en el orden correcto.
• Construir políticas de ejemplo en las tres capas, eligiendo en cada caso la adecuada al objetivo.
• Resolver el control de la inteligencia artificial generativa permitiendo una herramienta aprobada y bloqueando el resto.
• Verificar cada capa por separado para poder diagnosticar con criterio en lugar de por descarte.

🧩 Desarrollo de la práctica

Comenzaremos preparando la organización en la plataforma: el nombre de equipo, el método de autenticación y, sobre todo, la regla que autoriza qué usuarios pueden registrar dispositivos, que es el requisito cuyo olvido produce el síntoma más desconcertante de todo el despliegue.

Instalaremos después el agente en el equipo Windows mediante una instalación desatendida, analizando qué hace cada parámetro y por qué convierten una instalación de escritorio en un despliegue corporativo: el registro automático en la organización, el modo que encamina tanto el tráfico como las consultas de nombres, la reconexión automática y el bloqueo del interruptor que impide al usuario desactivar el control. Comprobaremos el estado desde la línea de comandos y veremos cómo detectar el caso engañoso en el que el agente aparece conectado pero el equipo está usando el servicio público en lugar del corporativo, con lo que ninguna política se aplica.

Nos detendremos en la elección del protocolo del túnel, comparando MASQUE y WireGuard en puertos, resistencia a redes restrictivas, comportamiento en movilidad y conformidad normativa, para entender por qué el primero es hoy la opción por defecto y en qué casos concretos tendría sentido el segundo.

Llegaremos entonces al núcleo conceptual de la práctica: las tres capas de políticas. Veremos que la capa de nombres actúa antes de que exista la conexión y es la más eficiente pero solo conoce el dominio; que la capa de red decide sobre dirección, puerto y protocolo y es la adecuada para todo lo que no es navegación web; y que la capa de contenido es la única capaz de distinguir aplicaciones concretas y acciones dentro de ellas, a cambio de exigir inspección del tráfico cifrado. Analizaremos el orden de aplicación entre capas y dentro de cada una, incluida la excepción que rompe ese orden y que provoca que políticas aparentemente correctas no lleguen a ejecutarse nunca.

Activaremos la inspección TLS y desplegaremos el certificado raíz, prestando atención al orden de esas dos operaciones porque invertirlo deja la navegación inservible. Construiremos políticas de ejemplo en las tres capas y remataremos con el caso práctico completo: dos reglas de contenido cuyo orden relativo es exactamente lo que hace que la excepción funcione, permitiendo la herramienta corporativa aprobada y bloqueando cualquier otro asistente, incluidos los que aparezcan después del despliegue.

Cerraremos yendo un paso más allá del bloqueo, planteando el control granular que en un entorno real resulta más útil: permitir el uso de la herramienta aprobada, restringir la subida de documentos e impedir el envío de información sensible, en lugar de una prohibición general que empuja a los usuarios hacia sus dispositivos personales.

🔍 ¿Por qué es importante esta práctica?

Porque el perímetro de red, como concepto, ha dejado de existir. Un modelo de seguridad que asume que los equipos están detrás de un cortafuegos corporativo describe una realidad que ya no se corresponde con la forma de trabajar de la mayoría de las organizaciones. Trasladar el punto de control al propio dispositivo no es una moda: es la única manera de que las políticas sigan siendo efectivas cuando el equipo cambia de red varias veces al día.

También porque la confusión entre las tres capas de filtrado es una de las causas más frecuentes de configuraciones que parecen correctas y no protegen nada. Intentar controlar aplicaciones desde la capa de nombres, o creer que unas políticas de contenido están funcionando sin haber activado la inspección del tráfico cifrado, son errores que no producen ningún mensaje de error: simplemente el filtro no actúa, y la organización opera con una falsa sensación de control que es peor que no tener ninguno.

Y porque el caso concreto de la inteligencia artificial generativa es hoy un problema real y sin resolver en la mayoría de las empresas. Los empleados utilizan asistentes conversacionales con información corporativa —código, documentos, datos de clientes— sin que exista visibilidad sobre qué se está enviando ni a dónde. La respuesta habitual, prohibirlo todo, tiene un efecto contraproducente bien conocido: el uso se desplaza al teléfono personal, donde no hay ninguna trazabilidad. Encauzar el uso hacia una herramienta contratada y controlada es una solución mucho más defendible que una prohibición que nadie puede hacer cumplir.

✅ Resultados esperados

Al finalizar dispondremos de un equipo Windows cuyo tráfico atraviesa la plataforma de seguridad con independencia de la red a la que se conecte, con políticas activas en las tres capas y con inspección del tráfico cifrado habilitada mediante un certificado propio desplegado en el almacén del equipo.

Habremos verificado cada capa por separado, comprobando que el filtrado de dominios impide la resolución, que el filtrado de red discrimina por puerto sin cortar la navegación, y que el filtrado de contenido distingue entre aplicaciones concretas. Y habremos demostrado el caso completo: la herramienta de inteligencia artificial aprobada carga con normalidad mientras cualquier otro asistente muestra la página de bloqueo, con los registros de la plataforma confirmando qué política intervino en cada caso.

🏢 Propuesta empresarial

📌 Escenario propuesto

Una organización con la mayor parte de su plantilla en modalidad híbrida constata que sus controles de navegación solo se aplican cuando los equipos están en la oficina. La revisión interna añade un segundo hallazgo más incómodo: no existe ninguna visibilidad sobre el uso de asistentes de inteligencia artificial, y varios departamentos reconocen haber introducido en ellos documentación interna, fragmentos de código y datos de clientes.

La dirección plantea un doble objetivo. Por un lado, que las políticas de navegación se apliquen a los equipos corporativos en cualquier ubicación. Por otro, adoptar formalmente una herramienta de inteligencia artificial corporativa y garantizar que el resto de servicios equivalentes queda bloqueado, evitando la prohibición general que ya se ha demostrado ineficaz en otras organizaciones.

🎯 Requisitos técnicos solicitados por la empresa

• Las políticas deben aplicarse con independencia de la red desde la que se conecte el equipo, sin depender de encaminar el tráfico hacia la sede.
• El control debe ser efectivo sobre tráfico cifrado, que es la práctica totalidad del tráfico web actual.
• El agente no debe poder ser desactivado por el usuario en equipos corporativos gestionados.
• Debe existir una única herramienta de IA autorizada y quedar bloqueado el resto, incluidos los servicios que aparezcan con posterioridad.
• Los servicios de administración remota no deben poder iniciarse hacia Internet desde los puestos de trabajo, salvo para los perfiles técnicos que lo requieran.
• Debe existir registro de la actividad que permita justificar la aplicación de las políticas y analizar incidentes.
• El despliegue debe ser centralizado y reproducible, sin configuración manual equipo por equipo.

🔐 Justificación técnica y de seguridad

El diseño desplaza el punto de control desde la red hacia el dispositivo, con lo que la protección deja de depender de la ubicación física del equipo. Esa propiedad es la que resuelve el problema de fondo: un portátil en casa de un empleado queda sujeto exactamente a las mismas reglas que en la oficina, sin que el usuario tenga que activar nada.

La separación en tres capas permite aplicar cada control en el nivel donde es más eficiente. Las amenazas conocidas se detienen en la capa de nombres, antes incluso de que se establezca la conexión y con un coste mínimo en recursos. Los servicios de administración se restringen en la capa de red, sin necesidad de inspeccionar contenido. Y la inspección profunda, que es la costosa, se reserva para lo que realmente la necesita: el control de aplicaciones y la protección de la información.

El bloqueo de la resolución de nombres hacia servidores externos merece mención aparte, porque es lo que convierte el filtrado por dominio en una medida efectiva: sin esa restricción, cualquier usuario con conocimientos básicos puede configurar un resolutor alternativo y anular esa capa por completo.

Respecto al control de la inteligencia artificial, la aproximación de permitir una herramienta y bloquear la categoría completa tiene una ventaja de mantenimiento decisiva: la lista de servicios bloqueados la mantiene el proveedor y se actualiza sola, mientras que una lista de dominios gestionada internamente queda desactualizada en semanas.

Debe señalarse con honestidad el contrapeso del modelo: la organización delega en un proveedor externo la capacidad de inspeccionar el tráfico de sus equipos. Es la misma cesión que se realiza con cualquier proxy corporativo, pero debe constar en el análisis de riesgos, revisarse contractualmente y comunicarse a la plantilla, que es además un requisito habitual de la normativa de protección de datos.

🧪 Validación esperada

La validación se realizará capa por capa y en el orden en que se aplican, de modo que cada prueba descarte una causa concreta. Se comprobará que el equipo encamina realmente su tráfico por el servicio corporativo y no por el público, que un dominio bloqueado no llega a resolverse, que un puerto de administración restringido no establece conexión mientras la navegación sigue operativa, y que la cadena de confianza de los sitios seguros termina en la autoridad de la organización, lo que confirma que la inspección está activa.

La validación funcional consistirá en abrir la herramienta de inteligencia artificial aprobada, que debe cargar con normalidad, y a continuación otros asistentes, que deben mostrar la página de bloqueo, contrastando en cada caso el registro de la plataforma para identificar la política que intervino.

✅ Resultado empresarial esperado

La organización obtiene un control de navegación que ya no depende de dónde estén sus equipos, y una postura defendible en materia de inteligencia artificial: no prohíbe una tecnología que mejora la productividad, sino que la canaliza hacia una herramienta contratada sobre la que existe control, contrato y responsabilidad, con capacidad de impedir la salida de documentación y de detectar los intentos de envío de información sensible.

Además, la sustitución progresiva del acceso remoto tradicional por accesos publicados individualmente sobre esta misma plataforma abre la puerta a reducir la conectividad completa a la red interna, que es una de las mayores fuentes de movimiento lateral en un incidente.

🎬 Descripción del vídeo

En esta práctica configuraremos Cloudflare One en un equipo Windows 11 para controlar todo el tráfico corporativo con independencia de la red a la que esté conectado, sustituyendo el modelo de cortafuegos perimetral por un agente instalado en el propio dispositivo. Para ello prepararemos la organización en la plataforma, definiendo el método de autenticación y la regla que autoriza el registro de dispositivos, e instalaremos el cliente de forma desatendida con la organización preconfigurada, el modo de tráfico y consultas de nombres, la reconexión automática y el bloqueo del interruptor para que el usuario no pueda desactivarlo. También compararemos los dos protocolos de túnel disponibles, MASQUE y WireGuard, analizando sus puertos, su resistencia frente a redes restrictivas y su conformidad normativa para entender por qué el primero es hoy la opción recomendada. A continuación explicaremos en detalle las tres capas de políticas que aplica Gateway —DNS, red y HTTP—, qué información observa cada una, en qué momento actúa, cuál es su límite real y en qué orden se evalúan, incluida la excepción que rompe ese orden y hace que políticas aparentemente correctas no lleguen a ejecutarse nunca. Además activaremos la inspección del tráfico cifrado y desplegaremos el certificado raíz en el almacén del equipo, prestando atención al orden de esas dos operaciones porque invertirlo deja la navegación inservible. Posteriormente construiremos políticas de ejemplo en cada capa y resolveremos un caso muy actual en cualquier empresa: permitir una única herramienta de inteligencia artificial aprobada y bloquear todas las demás, incluidas las que aparezcan después, con dos reglas cuyo orden relativo es exactamente lo que hace que la excepción funcione. Finalmente verificaremos cada capa por separado y veremos cómo pasar del bloqueo total a un control granular que permita el uso de la herramienta corporativa mientras impide la subida de documentos y el envío de información sensible.

🔗 Enlaces de interés

DOCUMENTACIÓN