1. Introducción
El control del tráfico corporativo se ha resuelto durante décadas 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 cuanto un portátil sale por la puerta: desde una red doméstica, un hotel o una cafetería, ese equipo navega sin ninguna de las políticas de la empresa. El planteamiento del perímetro definido por software invierte el orden: en lugar de llevar los equipos al filtro, se lleva el filtro a los equipos mediante un agente instalado en cada uno.
Esta guía implementa ese modelo con Cloudflare One. En el equipo se instala el Cloudflare One Client —el agente antes conocido como WARP—, que establece un túnel cifrado hacia la red de Cloudflare y hace que todo el tráfico del dispositivo atraviese Cloudflare Gateway con independencia de dónde esté conectado. Sobre ese punto de paso se definen políticas en tres capas distintas, y comprender qué puede hacer cada una es el objetivo central del documento.
Conviene aclarar la nomenclatura desde el principio porque genera bastante confusión: Cloudflare One —también llamado Zero Trust— es la plataforma donde se definen las políticas desde el navegador, mientras que el Cloudflare One Client es el agente que se instala en cada equipo y hace que esas políticas se apliquen a su tráfico. La documentación oficial lo identifica como Cloudflare One Client (anteriormente WARP), y los componentes internos del servicio conservan todavía la denominación antigua.
El caso práctico elegido para demostrar las tres capas es el control de la inteligencia artificial generativa, un problema muy actual en cualquier organización: los empleados utilizan asistentes de IA con información corporativa sin que la empresa tenga visibilidad ni control sobre qué se está enviando. Es además un ejemplo especialmente didáctico, porque solo puede resolverse correctamente en la capa adecuada y falla de forma silenciosa si se intenta en la equivocada.
2. Variables de esta guía
Todos los bloques usan los siguientes marcadores en MAYÚSCULAS. Sustitúyelos por los valores reales del entorno donde se aplique esta guía.
| Marcador | Qué es | Dónde se obtiene |
|---|---|---|
NOMBRE_ORGANIZACION | Nombre de equipo de la organización, el identificador corto que se elige al crear la cuenta | Panel de Cloudflare One (sección 5) |
DOMINIO_CORPORATIVO | Dominio de correo de la empresa, usado para autorizar qué usuarios pueden registrar dispositivos | El dominio de correo de la organización |
URL_SOPORTE | Dirección interna de soporte que el agente muestra a los usuarios | La mesa de ayuda de la organización |
FICHERO_INSTALADOR | Nombre exacto del paquete de instalación descargado, que incluye el número de versión | La página de descargas del cliente (sección 6) |
APP_IA_APROBADA | Aplicación de inteligencia artificial autorizada por la organización, la única que quedará permitida | La decisión corporativa (sección 14) |
El nombre de equipo es más importante de lo que parece: identifica a la organización en el registro de cada dispositivo y forma parte del dominio de acceso de la plataforma. Conviene elegirlo con criterio desde el principio, porque cambiarlo más adelante obliga a volver a registrar todos los equipos ya desplegados.
3. Arquitectura y flujo
El agente instalado en el equipo captura todo el tráfico y lo envía por un túnel cifrado hasta el punto de presencia de Cloudflare más cercano. Allí se aplican las políticas en tres momentos distintos del recorrido, y solo lo que las supera continúa hacia su destino.
Resumen visual
[ WINDOWS 11 - EQUIPO CORPORATIVO ]
Cloudflare One Client
|
| tunel cifrado (MASQUE / HTTP3 sobre QUIC)
| funciona en cualquier red: oficina, casa, hotel
v
+------------------------------------------------+
| CLOUDFLARE GATEWAY |
| |
| 1. Politicas DNS -> " a que dominio vas? " |
| 2. Politicas de RED -> " a que IP y puerto? " |
| 3. Politicas HTTP -> " que haces dentro? " |
| |
| inspeccion TLS + antivirus + DLP |
+------------------------------------------------+
|
v
Internet
La diferencia esencial con un cortafuegos perimetral clásico es que este punto de control viaja con el equipo. Un portátil conectado a la red de un hotel sigue aplicando exactamente las mismas políticas que en la oficina, sin necesidad de que el usuario active nada ni de encaminar el tráfico hacia la sede central. Para una plantilla con movilidad, esa propiedad es la que hace viable el control real.
Que el tráfico atraviese la infraestructura del proveedor tiene una implicación que conviene asumir de forma consciente: la organización delega en él la capacidad de inspeccionar ese tráfico. Es la misma cesión que se hace con cualquier proxy corporativo, pero merece constar en el análisis de riesgos y, en muchos casos, en la información que se traslada a los empleados.
4. Requisitos
- Una cuenta de Cloudflare con una organización de Cloudflare One creada. El plan gratuito cubre un número reducido de usuarios y es suficiente para esta práctica.
- Un equipo con Windows 11 y permisos de administrador local para instalar el agente.
- Un método de identidad configurado para autorizar el registro de dispositivos, ya sea un proveedor externo o el envío de un código de un solo uso al correo.
- Salida a Internet desde el equipo, sin restricciones sobre los puertos que utiliza el túnel.
- Para un despliegue real, una herramienta de gestión centralizada con la que distribuir el agente y el certificado raíz sin pasar equipo por equipo.
5. Preparar la organización
Antes de tocar el equipo hay que dejar preparada la organización, porque el agente pedirá el nombre de equipo durante el registro y comprobará que el usuario está autorizado.
- Acceder al panel de Cloudflare y entrar en la sección de Cloudflare One, también identificada como Zero Trust.
- Definir el nombre de equipo de la organización si es la primera vez, anotándolo como
NOMBRE_ORGANIZACION. - Configurar al menos un método de autenticación. Para una prueba, el código de un solo uso enviado por correo evita depender de un proveedor de identidad externo.
- Crear una regla de registro de dispositivos que autorice a los usuarios cuyo correo pertenezca a
DOMINIO_CORPORATIVO. Sin esta regla, ningún equipo consigue registrarse.
La regla de registro es el requisito que más veces se olvida, y su síntoma despista: el agente se instala correctamente, abre el navegador para autenticarse, el usuario introduce sus credenciales sin ningún error, y aun así el dispositivo nunca llega a aparecer como registrado. No se trata de un problema de credenciales sino de autorización: el usuario existe, pero no está permitido que inscriba equipos.
En un despliegue corporativo esta regla es también la primera línea de control de acceso, porque determina qué identidades pueden incorporar dispositivos a la organización. Conviene restringirla a lo estrictamente necesario —un dominio de correo concreto, un grupo del proveedor de identidad— en lugar de dejarla abierta.
6. Instalar el cliente en Windows 11
El agente se descarga desde la propia plataforma. La instalación interactiva sirve para una prueba, pero en un parque real interesa la instalación desatendida, que además permite dejar el equipo preconfigurado y evitar que el usuario tenga que introducir el nombre de la organización.
Instalación desatendida con la organización preconfigurada
msiexec /i "FICHERO_INSTALADOR" /qn ^ ORGANIZATION="NOMBRE_ORGANIZACION" ^ SERVICE_MODE="warp" ^ AUTO_CONNECT="1" ^ ONBOARDING="false" ^ SUPPORT_URL="URL_SOPORTE" ^ /l*v "%TEMP%\cloudflare-one-install.log"
Merece la pena entender qué hace cada parámetro, porque son los que convierten una instalación de escritorio en un despliegue corporativo.
ORGANIZATION registra el equipo directamente en la organización sin preguntar nada al usuario. SERVICE_MODE con el valor warp selecciona el modo que encamina tanto el tráfico como las consultas de nombres, que es el único que permite aplicar las tres capas de políticas. AUTO_CONNECT hace que el agente vuelva a conectarse solo si alguien lo desactiva. ONBOARDING en falso suprime las pantallas de bienvenida.Existe un parámetro adicional,
SWITCH_LOCKED, que impide al usuario desconectar el agente. En equipos corporativos gestionados es lo razonable, porque un control que el propio usuario puede apagar con dos clics no es un control. Conviene reservarlo para cuando el despliegue esté validado: si se activa antes de tiempo y algo falla, el equipo puede quedarse sin conectividad y sin forma sencilla de recuperarla.Terminada la instalación, se comprueba el estado del agente desde la línea de comandos:
Comprobar el estado del agente
warp-cli --version warp-cli status warp-cli registration show
El estado debe indicar que el agente está conectado, y el registro debe mostrar la organización correcta. Si aparece conectado pero sin organización, el equipo está usando el servicio público de Cloudflare en lugar del corporativo, y por tanto no se le está aplicando ninguna política: es una situación especialmente engañosa porque el usuario ve el agente activo y todo funciona con normalidad.
Las herramientas de línea de comandos conservan la denominación anterior del producto, de modo que la orden sigue llamándose
warp-cli pese al cambio de nombre comercial. Lo mismo ocurre con el nombre del servicio del sistema y con varias rutas de instalación.7. MASQUE frente a WireGuard
El agente puede establecer el túnel con dos protocolos distintos, y la elección tiene consecuencias prácticas que conviene conocer. La configuración se encuentra en el perfil de dispositivo dentro de la plataforma, no en el propio equipo.
| MASQUE | WireGuard | |
|---|---|---|
| Base técnica | HTTP/3 sobre QUIC | Protocolo WireGuard |
| Puerto principal | UDP 443 | UDP 2408 |
| Alternativas si se bloquea | Otros puertos e incluso TCP 443 | UDP 500, 1701 y 4500 |
| Cifrado | TLS 1.3 con TLS_AES_256_GCM_SHA384 | TLS_CHACHA20_POLY1305_SHA256 |
| Conformidad FIPS 140-3 | Sí | No |
| Redes restrictivas | Muy resistente | Puede quedar bloqueado |
| Movilidad y pérdida de paquetes | Mejor comportamiento | Bueno |
La opción por defecto es MASQUE, y para un parque de portátiles que cambia de red constantemente es la recomendable. El motivo es sencillo: al viajar sobre HTTP/3 y normalmente por el puerto UDP 443, su tráfico se parece mucho al de una navegación web cualquiera, de modo que las redes de hoteles, aeropuertos o clientes rara vez lo bloquean. Además dispone de alternativas de reserva, incluida una sobre TCP 443, que es prácticamente imposible de filtrar sin romper toda la navegación.
WireGuard sigue siendo un protocolo excelente y muy eficiente, pero utiliza un puerto poco habitual que algunas redes restrictivas descartan, y su conjunto de algoritmos no está clasificado como conforme con FIPS 140-3. En organizaciones sujetas a esa normativa, ese detalle por sí solo decide la elección. La razón para mantener WireGuard sería tener una infraestructura ya validada sobre él o detectar algún problema concreto de compatibilidad con la alternativa.
8. Las tres capas de políticas
Este es el concepto central de la práctica. Cloudflare Gateway no aplica un único filtro sino tres, y cada uno actúa en un momento distinto de la conexión y ve una información diferente. Entender qué observa cada capa evita el error más común: intentar resolver en la capa equivocada un control que ahí es imposible.
Políticas DNS: el dominio
Actúan sobre la consulta de nombres, antes de que llegue a establecerse ninguna conexión. Cuando el equipo pregunta por la dirección de un dominio, Gateway puede sencillamente no responder con ella, de modo que la conexión nunca comienza.
Es la capa más rápida y la más barata en recursos, y no necesita ningún tipo de descifrado porque la consulta de nombres no va cifrada respecto del propio resolutor. Su límite es evidente en cuanto se piensa: solo conoce el nombre. No distingue una página de otra dentro del mismo dominio, ni sabe qué se está haciendo dentro de la aplicación.
Políticas de red: la conexión
Actúan sobre los paquetes de transporte, examinando dirección de destino, puerto y protocolo. Es la capa adecuada para todo lo que no es navegación web: acceso remoto por consola, escritorio remoto, comparticiones de ficheros, bases de datos o cualquier servicio propio.
Tampoco requiere descifrado, y permite decisiones del tipo "ningún equipo debe abrir conexiones de escritorio remoto hacia Internet" o "el tráfico hacia este rango de direcciones queda prohibido". No analiza el contenido: controla la conexión, no lo que viaja por ella.
Políticas HTTP: el contenido
Actúan sobre el tráfico web ya interpretado, y pueden examinar direcciones completas, cabeceras, ficheros subidos o descargados y el contenido de las peticiones. Es la única capa capaz de distinguir aplicaciones concretas, acciones dentro de ellas y datos sensibles.
Y es también la única que exige inspección TLS. Como prácticamente toda la web viaja cifrada, sin descifrado Gateway solo ve un flujo opaco hacia un servidor y no puede aplicar ninguna decisión basada en contenido. Este es el punto donde encalla la mayoría de configuraciones: las políticas se crean, quedan activas, y no bloquean nada porque el tráfico que pretenden controlar va por HTTPS.
| DNS | Red | HTTP | |
|---|---|---|---|
| Qué observa | El nombre de dominio | Dirección, puerto y protocolo | Direcciones completas, ficheros y contenido |
| Momento | Antes de conectar | Al establecer la conexión | Con la conexión ya establecida |
| Necesita inspección TLS | No | No | Sí |
| Coste en recursos | Muy bajo | Bajo | Alto |
| Distingue rutas dentro de un sitio | No | No | Sí |
| Sirve para tráfico no web | Parcialmente | Sí | No |
| Uso recomendado | Malware, suplantación, contenido para adultos, dominios peligrosos | Puertos y servicios de administración, direcciones concretas | Aplicaciones, subidas y descargas, prevención de fuga de datos |
La conclusión práctica es que no son alternativas sino complementos. Una configuración corporativa sensata bloquea las amenazas conocidas en la capa de nombres, porque es la más eficiente y detiene el tráfico antes de que exista; endurece los servicios de administración en la capa de red; y reserva la capa de contenido para lo que de verdad requiere ver dentro del tráfico, que es donde está el control de aplicaciones y de datos.
9. Orden de aplicación de las políticas
Las tres capas no se evalúan simultáneamente sino en una secuencia fija, y ese orden explica muchos comportamientos que de otro modo parecen contradictorios.
Secuencia de evaluación
El equipo intenta acceder a un servicio
|
v
1. Politicas DNS --> si bloquea aqui, se acabo
|
v
2. Politicas de RED --> si bloquea aqui, se acabo
|
v
3. Politicas HTTP --> ultimo control
|
+-- Do Not Inspect (se evaluan SIEMPRE primero)
+-- Aislamiento
+-- Permitir / Bloquear
+-- Inspeccion de contenido (DLP, antivirus)
|
v
Internet
De esta secuencia se derivan dos consecuencias que conviene tener muy presentes. La primera: si una capa anterior bloquea, las posteriores no llegan a evaluarse, de modo que una política de contenido cuidadosamente construida puede no ejecutarse nunca porque un filtro de nombres más amplio ya cortó el tráfico. La segunda: dentro de cada capa, las políticas se recorren de arriba abajo y gana la primera que coincide, así que el orden en la lista no es cosmético sino funcional.
Hay además una excepción que rompe el orden y que da bastantes disgustos: las reglas de no inspeccionar se evalúan antes que todas las demás políticas de contenido, con independencia de la posición que ocupen en la lista. Si existe una de esas reglas demasiado amplia —por ejemplo, excluyendo de la inspección todo un conjunto de servicios en la nube—, ese tráfico se salta por completo el resto de controles de contenido aunque haya políticas de bloqueo por encima. Revisar esas exclusiones es obligatorio antes de dar por buena cualquier configuración.
Las reglas de no inspeccionar existen por buenas razones: hay aplicaciones que utilizan fijación de certificados y dejan de funcionar si alguien se interpone en su cifrado. El criterio correcto es mantenerlas al mínimo imprescindible y documentar por qué está cada una, no acumularlas para resolver incidencias puntuales.
10. Inspección HTTPS y certificado raíz
Para que las políticas de contenido puedan actuar sobre tráfico cifrado hay que activar la inspección TLS. El mecanismo consiste en que Gateway termina la conexión cifrada, examina su contenido conforme a las políticas y vuelve a cifrarla hacia el destino, presentando al equipo un certificado emitido por la autoridad de la organización.
- En la plataforma, dentro de la configuración de tráfico, localizar la sección de proxy e inspección.
- Activar la opción de inspeccionar peticiones HTTPS mediante descifrado TLS.
- Comprobar que el proxy está habilitado para los protocolos que se van a controlar.
Activar la inspección sin haber desplegado antes el certificado raíz en los equipos deja la navegación inservible: cada sitio muestra un aviso de certificado no confiable, porque el equipo recibe un certificado emitido por una autoridad que desconoce. El orden correcto es siempre primero el certificado en los dispositivos, después la inspección en la plataforma, nunca al revés.
El certificado se descarga desde la propia plataforma y se instala en el almacén de entidades de certificación raíz de confianza del equipo:
Instalar el certificado raíz en Windows
Import-Certificate -FilePath "$env:USERPROFILE\Downloads\Cloudflare_CA.crt" -CertStoreLocation Cert:\LocalMachine\Root
Comprobar que el certificado está instalado
Get-ChildItem Cert:\LocalMachine\Root |
Where-Object { $_.Subject -like "*Cloudflare*" } |
Select-Object Subject, NotAfter, Thumbprint
Debe instalarse en el almacén del equipo y no en el del usuario, para que lo utilicen también los servicios y las aplicaciones que no se ejecutan en la sesión interactiva. En un parque real esta distribución se realiza con la herramienta de gestión de dispositivos o mediante directivas de grupo, nunca de forma manual: hacerlo equipo por equipo no escala y garantiza que alguno se quede fuera.
Algunas aplicaciones mantienen su propio almacén de certificados independiente del sistema, entre ellas ciertos navegadores y muchas herramientas de desarrollo. Si tras instalar el certificado una aplicación concreta sigue rechazando las conexiones, lo habitual es que esté usando su propio almacén y necesite el certificado también ahí, o bien que deba añadirse a las excepciones de inspección.
11. Políticas DNS
Es la capa donde conviene concentrar los bloqueos amplios y bien definidos, porque detiene el tráfico antes de que llegue a existir y no consume prácticamente recursos. Las políticas se construyen combinando un selector, un operador y un valor, y una acción.
| Objetivo | Selector | Valor | Acción |
|---|---|---|---|
| Programas maliciosos | Categorías de seguridad | Malware, Command and Control, Spyware | Bloquear |
| Suplantación de identidad | Categorías de seguridad | Phishing | Bloquear |
| Dominios recién creados | Categorías de seguridad | New Domains, Newly Seen Domains | Bloquear |
| Contenido inapropiado | Categorías de contenido | Adult Themes, Gambling | Bloquear |
| Minado de criptomonedas | Categorías de contenido | Cryptomining | Bloquear |
| Dominio concreto | Dominio | El nombre a bloquear | Bloquear |
El bloqueo de dominios recién registrados es una de las medidas con mejor relación entre esfuerzo y resultado, y suele pasar desapercibida. Buena parte de las campañas de suplantación utilizan dominios creados pocas horas antes del envío, precisamente para que ninguna lista de reputación los haya clasificado todavía. Bloquear por antigüedad no depende de que alguien haya identificado la amenaza.
Conviene tener presente que este filtrado se apoya en el resolutor del agente. Si una aplicación resuelve nombres por su cuenta usando mecanismos cifrados propios, puede eludir esta capa; es una de las razones por las que el control no debe descansar únicamente en ella y por las que interesa restringir esos mecanismos alternativos desde la capa de red.
12. Políticas de red
Esta capa es la que endurece el equipo frente a todo lo que no es navegación, y en un entorno corporativo su utilidad es más grande de lo que sugiere su simplicidad: la mayoría de los puestos de trabajo no necesitan iniciar hacia Internet ninguna conexión de administración, y sin embargo pueden hacerlo.
| Objetivo | Selector | Valor | Acción |
|---|---|---|---|
| Impedir el acceso remoto por consola hacia Internet | Puerto de destino | 22 | Bloquear |
| Impedir el escritorio remoto hacia Internet | Puerto de destino | 3389 | Bloquear |
| Impedir la compartición de ficheros hacia Internet | Puerto de destino | 445 | Bloquear |
| Forzar el uso del resolutor corporativo | Puerto de destino | 53 | Bloquear |
| Bloquear un rango de direcciones | IP de destino | El rango a bloquear | Bloquear |
El bloqueo del puerto de resolución de nombres hacia el exterior es especialmente valioso porque cierra la vía de escape más habitual: sin él, cualquier aplicación —o cualquier usuario con conocimientos— puede configurar un resolutor externo y saltarse por completo las políticas de la capa de nombres. Cerrar esa salida es lo que convierte el filtrado por dominio en una medida efectiva y no en una recomendación.
Antes de bloquear un puerto conviene comprobar quién lo utiliza legítimamente en la organización. El acceso remoto por consola, por ejemplo, es imprescindible para los perfiles técnicos, de modo que la política razonable no suele ser un bloqueo general sino uno con excepción para el grupo que lo necesita. Aplicar estos bloqueos sin ese análisis previo genera incidencias inmediatas y desconfianza hacia el despliegue.
13. Políticas HTTP
Es la capa más potente y la única capaz de distinguir qué se está haciendo, no solo dónde. Requiere la inspección TLS de la sección 10 y consume más recursos, así que su uso adecuado es el control de aplicaciones y de datos, dejando los bloqueos amplios en las capas anteriores.
| Objetivo | Selector | Comentario |
|---|---|---|
| Controlar una aplicación concreta | Aplicación | Reconoce el servicio aunque utilice varios dominios distintos |
| Controlar una familia de servicios | Tipo de aplicación | Agrupa aplicaciones por categoría y se actualiza con el catálogo del proveedor |
| Controlar una ruta concreta | Dirección completa | Permite distinguir secciones dentro de un mismo sitio |
| Limitar subidas de ficheros | Tipo de descarga o subida | Distingue el sentido de la transferencia |
| Evitar la fuga de información | Perfil de prevención de pérdida de datos | Examina el contenido en busca de patrones definidos |
| Detectar código malicioso | Antivirus | Analiza los ficheros transferidos |
La diferencia entre seleccionar por aplicación y hacerlo por dominio es más relevante de lo que parece. Un servicio web moderno reparte su funcionamiento entre varios nombres —el portal, la interfaz de programación, el almacenamiento de ficheros, la red de distribución de contenidos—, de modo que bloquear el dominio principal deja abiertos los demás y produce comportamientos parciales muy difíciles de diagnosticar. El selector de aplicación agrupa todos esos nombres bajo una única entrada mantenida por el proveedor.
14. Bloquear la IA salvo la herramienta aprobada
Este caso resume por qué merece la pena entender las tres capas. El objetivo corporativo típico no es prohibir la inteligencia artificial —eso solo consigue que se use desde el móvil personal, sin ninguna trazabilidad— sino canalizarla hacia una herramienta aprobada sobre la que sí existe control, contrato y responsabilidad.
Este control debe hacerse en la capa de contenido. Intentarlo solo en la capa de nombres tiene dos problemas: no distingue entre acciones dentro del servicio, y obliga a mantener a mano una lista de dominios que queda desactualizada cada pocas semanas, porque aparecen asistentes nuevos continuamente. El selector de aplicación se apoya en un catálogo mantenido por el proveedor y recoge los servicios nuevos sin intervención.
La configuración son dos políticas, y el orden entre ellas es lo que hace que funcione:
Estructura de las dos políticas
POLITICAS HTTP (se evaluan de arriba abajo, gana la primera coincidencia)
1) Permitir - IA aprobada
Aplicacion es APP_IA_APROBADA
Accion Permitir
2) Bloquear - Resto de IA
Tipo de aplicacion esta en Artificial Intelligence
Accion Bloquear
El mecanismo es directo: cuando un usuario abre la herramienta aprobada, coincide con la primera política, se permite y la evaluación se detiene sin llegar a la segunda. Cuando abre cualquier otro asistente, no coincide con la primera, cae en la segunda y queda bloqueado. Invertir el orden anula por completo la excepción, porque la herramienta aprobada también pertenece a la categoría y sería bloqueada antes de que la regla que la permite llegara a evaluarse.
| Servicio | Resultado | Por qué |
|---|---|---|
| La herramienta aprobada por la organización | Permitido | Coincide con la primera política |
| Cualquier otro asistente conversacional | Bloqueado | Pertenece a la categoría y no coincide con la excepción |
| Asistentes aparecidos después del despliegue | Bloqueado | El catálogo de la categoría se actualiza sin intervención |
Antes de dar por buena esta configuración hay que revisar las reglas de no inspeccionar descritas en la sección 9. Si existe una exclusión amplia que abarque el conjunto de servicios en el que se encuentra la herramienta aprobada, ese tráfico se saltará las políticas de contenido y el bloqueo no se aplicará como se espera. Es la causa más frecuente de que estas dos reglas parezcan no funcionar.
Conviene acompañar el bloqueo de una página de aviso personalizada en lugar de dejar un error genérico. Explicar en ella qué herramienta está aprobada y por qué convierte una prohibición opaca —que el usuario intentará esquivar— en una indicación comprensible. La adopción de una política de este tipo depende tanto de la comunicación como de la técnica.
15. Del bloqueo al control granular
Bloquear es la respuesta más sencilla, pero rara vez la mejor en una organización. El riesgo real de los asistentes de inteligencia artificial no es que se utilicen, sino qué información se introduce en ellos: código propietario, datos personales, documentos contractuales o credenciales. Ese matiz permite plantear políticas mucho más útiles que un simple corte.
Modelo de control por capas sobre la herramienta aprobada
APP_IA_APROBADA
|
+-- uso general ....................... PERMITIR
+-- subida de ficheros ................ BLOQUEAR o REGISTRAR
+-- contenido con datos sensibles ..... BLOQUEAR (prevencion de fuga de datos)
Resto de asistentes de IA ................. BLOQUEAR
Las políticas de contenido permiten distinguir el sentido de la transferencia, de modo que se puede autorizar la consulta y bloquear la subida de documentos. Y los perfiles de prevención de pérdida de datos permiten ir un paso más allá, examinando lo que se envía en busca de patrones definidos por la organización.
El resultado es una postura defendible ante un comité de dirección: la empresa no prohíbe una tecnología que mejora la productividad, sino que la encauza hacia una herramienta contratada, impide que salgan documentos por ella y detecta los intentos de enviar información sensible. Prohibir sin alternativa, en cambio, empuja el uso hacia dispositivos personales, que es precisamente el escenario sin control ni trazabilidad que se quería evitar.
Este mismo planteamiento se aplica a cualquier otra familia de servicios en la nube: almacenamiento, mensajería, transferencia de ficheros o repositorios de código. La pregunta útil no suele ser si se permite el servicio, sino qué acciones concretas dentro de él son aceptables y cuáles no.
16. Verificación
La verificación debe hacerse en el mismo orden en el que se aplican las políticas, porque así cada prueba descarta una causa distinta y el diagnóstico deja de ser adivinanza.
Comprobar que el equipo pasa por el servicio
warp-cli status warp-cli registration show Invoke-RestMethod -Uri "https://www.cloudflare.com/cdn-cgi/trace/"
La última orden devuelve un resumen del estado de la conexión visto desde el otro extremo. El indicador de advertencia debe reflejar que el tráfico está pasando por el servicio corporativo; si indica lo contrario, el agente no está encaminando el tráfico y ninguna política se está aplicando, por mucho que aparezcan como activas en la plataforma.
Comprobar la capa de nombres
Resolve-DnsName -Name UN_DOMINIO_BLOQUEADO
Comprobar la capa de red
Test-NetConnection -ComputerName UN_SERVIDOR_EXTERNO -Port 22 Test-NetConnection -ComputerName UN_SERVIDOR_EXTERNO -Port 443
La conexión al puerto de administración debe fallar y la de navegación debe funcionar. Esa pareja de resultados demuestra que la capa de red discrimina por puerto y no está simplemente cortando todo el tráfico.
Comprobar el certificado que presenta el servicio
$conexion = Test-NetConnection -ComputerName "www.example.com" -Port 443 Invoke-WebRequest -Uri "https://www.example.com" -UseBasicParsing | Select-Object StatusCode
La comprobación definitiva de la inspección TLS se hace en el navegador: al abrir cualquier sitio seguro y examinar el certificado, la cadena de confianza debe terminar en la autoridad de la organización y no en la autoridad pública habitual del sitio. Ese detalle confirma que el tráfico está siendo descifrado y, por tanto, que las políticas de contenido pueden actuar.
La prueba final es funcional: abrir la herramienta de inteligencia artificial aprobada, que debe cargar con normalidad, y a continuación cualquier otro asistente, que debe mostrar la página de bloqueo. Los registros de la plataforma permiten confirmar qué política concreta ha intervenido en cada caso, que es la forma correcta de validar una configuración en lugar de deducirla del comportamiento.
17. Puertos y componentes
| Puerto | Componente | Sentido | Para qué sirve |
|---|---|---|---|
| UDP 443 | Túnel MASQUE | Equipo → Cloudflare | Transporte principal del tráfico. Se confunde con navegación normal, difícil de bloquear |
| TCP 443 | Alternativa del túnel | Equipo → Cloudflare | Reserva cuando la red bloquea el transporte por UDP |
| UDP 2408 | Túnel WireGuard | Equipo → Cloudflare | Solo si se elige este protocolo. Algunas redes lo descartan |
| UDP 500, 1701, 4500 | Alternativas de WireGuard | Equipo → Cloudflare | Puertos de reserva del protocolo alternativo |
| — | Cloudflare Gateway | Servicio en la nube | Donde se aplican las tres capas de políticas |
| — | Certificado raíz de la organización | Almacén del equipo | Requisito para que la inspección de contenido funcione sin avisos |
En redes propias donde exista un cortafuegos perimetral restrictivo conviene permitir explícitamente la salida por estos puertos. Es un escenario habitual en entornos con filtrado de salida estricto, donde el agente se instala correctamente pero nunca llega a conectar.
18. Errores comunes y cómo resolverlos
| Problema | Causa probable | Solución |
|---|---|---|
| Las políticas están activas pero no bloquean casi nada, y el panel avisa de que se aplican al tráfico sin cifrar pero no al cifrado | La inspección TLS no está activada, y prácticamente todos los servicios web viajan cifrados | Desplegar el certificado raíz en los equipos y activar después la inspección (sección 10) |
| Tras activar la inspección, todos los sitios muestran avisos de certificado no confiable | Se activó la inspección antes de distribuir el certificado raíz | Instalar el certificado en el almacén del equipo; el orden correcto es certificado primero, inspección después (sección 10) |
| El agente se instala y el usuario se autentica sin errores, pero el dispositivo nunca aparece registrado | No existe una regla de registro de dispositivos que autorice a ese usuario | Crear la regla que permita al dominio de correo corporativo inscribir equipos (sección 5) |
| El agente aparece conectado pero no se aplica ninguna política | El equipo está usando el servicio público en lugar del corporativo, por no haberse registrado en la organización | Comprobarlo con warp-cli registration show y reinstalar indicando la organización (sección 6) |
| Una política de contenido no se aplica pese a estar bien construida y por encima de las demás | Existe una regla de no inspeccionar que abarca ese tráfico, y esas reglas se evalúan antes que todas las demás | Revisar y acotar las exclusiones de inspección (sección 9) |
| Se crean varias políticas correctas pero solo actúa una de ellas | Dentro de cada capa gana la primera coincidencia y la evaluación se detiene ahí | Revisar el orden: las excepciones deben ir por encima de los bloqueos generales (secciones 9 y 14) |
| La excepción de la herramienta aprobada no funciona y queda bloqueada como el resto | La política de bloqueo general está por encima de la que permite la excepción | Colocar la política que permite en primer lugar (sección 14) |
| El bloqueo de una aplicación funciona a medias: unas funciones se cortan y otras siguen operativas | Se bloqueó un dominio concreto en lugar de la aplicación, y el servicio utiliza varios nombres distintos | Usar el selector de aplicación, que agrupa todos los nombres del servicio (sección 13) |
| Un usuario elude el filtrado de dominios configurando otro resolutor de nombres | La salida hacia resolutores externos no está restringida en la capa de red | Bloquear el puerto de resolución de nombres hacia el exterior (sección 12) |
| El agente no llega a conectar desde una red concreta | Esa red bloquea el puerto que utiliza el protocolo del túnel | Verificar que el perfil usa el protocolo por defecto, que resiste mejor las redes restrictivas (sección 7) |
| Una aplicación específica deja de funcionar tras activar la inspección | Utiliza fijación de certificados o mantiene un almacén de certificados propio | Añadir esa aplicación a las excepciones de inspección, acotándola lo máximo posible (secciones 9 y 10) |
| Bloquear un puerto en la capa de red deja sin trabajar a parte de la plantilla | La política se aplicó de forma general sin excepción para los perfiles que sí lo necesitan | Acotar la política por grupo de identidad en lugar de aplicarla a toda la organización (sección 12) |
19. Notas de ampliación
El montaje de esta guía cubre el control del tráfico de salida de un equipo corporativo. Para un despliegue completo conviene ampliar con:
- Distribución centralizada del agente y del certificado mediante la herramienta de gestión de dispositivos de la organización, que es lo único que hace viable el despliegue en un parque real y garantiza que ningún equipo se quede sin la configuración.
- Integración con el proveedor de identidad corporativo, de forma que las políticas puedan distinguir por usuario o por grupo en lugar de aplicarse por igual a todos, y que el registro de dispositivos herede las altas y bajas de personal.
- Perfiles de prevención de pérdida de datos ajustados a la información que realmente maneja la organización, en lugar de los patrones genéricos, que producen demasiados avisos irrelevantes y acaban ignorándose.
- Comprobación del estado del dispositivo antes de conceder acceso, verificando cifrado de disco, antivirus activo o versión mínima del sistema, de modo que un equipo desactualizado quede limitado automáticamente.
- Acceso a aplicaciones internas a través de la misma plataforma, sustituyendo la VPN tradicional por accesos publicados individualmente, con lo que un usuario deja de tener conectividad completa a la red interna por el hecho de estar conectado.
- Envío de los registros al sistema de monitorización de la organización, para conservar el histórico más allá de la retención de la plataforma y correlacionar estos eventos con los del resto de la infraestructura.
- Comunicación a la plantilla de qué se está inspeccionando y con qué finalidad, requisito habitual en la normativa de protección de datos y, en la práctica, la diferencia entre una medida aceptada y una que se intenta esquivar.