La VPN corporativa no falló porque estuviera mal implementada. Fracasó porque se construyó sobre una premisa que ya no es cierta: que estar dentro de la red de la empresa es suficiente para confiar en alguien. Cuando un empleado se conecta desde casa, la red de un hotel o una cafetería con la misma VPN que el equipo de la oficina, el perímetro de red como concepto de seguridad ya no existe. Lo que queda es una ilusión de control sostenida por la inercia operativa.
Cloudflare Zero Trust parte de una premisa diferente: la identidad, el dispositivo y el contexto de la solicitud determinan el acceso, no la dirección IP de origen. La implementación concreta de esto involucra tres componentes que tienen roles distintos y a menudo son confundidos incluso por aquellos que ya los han puesto en producción.
Acceso, Túnel y WARP: qué hace cada uno
Cloudflare Access es una puerta de enlace de identidad para aplicaciones. Cuando llega una solicitud al dominio interno publicado a través de Cloudflare, Access la intercepta antes de que la solicitud llegue al origen. El usuario se autentica con el proveedor de identidad configurado: Okta, Azure AD, Google Workspace o cualquier proveedor SAML 2.0 y OIDC. Sólo después de la autenticación y la evaluación de la política el tráfico continúa hasta el origen. La aplicación nunca recibe una solicitud no autenticada.
Cloudflare Tunnel, ejecutado por el demonio cloudflared, opera en el lado del servidor. Crea una conexión saliente cifrada desde el servidor al borde de Cloudflare, sin abrir puertos de firewall entrantes. El flujo completo: el usuario se autentica a través de Access → el borde de Cloudflare valida → el tráfico llega a través del túnel al servicio interno. El servidor interno no necesita una IP pública, no necesita una regla de entrada al grupo de seguridad y no está expuesto directamente a Internet.
WARP es el cliente del dispositivo. En el modo Zero Trust, enruta el tráfico del dispositivo a través del borde de Cloudflare a través del protocolo WireGuard. Esto permite realizar comprobaciones de postura (cifrado de disco, versión del sistema operativo, agente de seguridad instalado) y permite que las políticas de acceso incluyan el estado del dispositivo como condición. Para las aplicaciones web a las que se accede a través del navegador, WARP a menudo no es necesario. Para protocolos que no son HTTP, como SSH y RDP, enrutados a través del túnel, es obligatorio.
Cómo funciona el flujo de autenticación
La secuencia concreta para que un desarrollador acceda a un servicio interno: el usuario accede a app.empresa.com. Access detecta que no hay una sesión válida y redirecciona al proveedor de identidad. El usuario se autentica: con MFA si la política así lo requiere. El IdP regresa a Access con atributos de grupo e identidad confirmados. Access evalúa la política: ¿Este usuario pertenece al grupo con permisos para esta aplicación? Si se aprueba, emite una sesión JWT y la solicitud va al borde, bajando por el túnel hasta el servicio en la red interna.
Para protocolos que no son HTTP (SSH, por ejemplo), la transmisión pasa por WARP. El cliente establece el túnel WireGuard, se verifica la política de postura y el tráfico SSH se enruta a través de Cloudflare hasta el destino a través del túnel.
Identidad y proveedores admitidos
Access admite múltiples proveedores de identidad simultáneamente en la misma organización. Una aplicación puede permitir la autenticación mediante Google Workspace para empleados y mediante GitHub para colaboradores externos. Otro podría requerir exclusivamente Okta con MFA obligatorio. Los grupos de IdP sincronizados (equipos de ingeniería, equipos específicos, departamentos) alimentan las políticas de acceso directamente, sin sincronización manual de listas.
Además de los humanos, Access gestiona el acceso de máquina a máquina mediante tokens de servicio. A una canalización de CI/CD que necesita llegar a un punto final interno autenticado se le asigna un ID de cliente y un secreto, que reemplazan el flujo de SSO humano. Cada acceso, humano o automatizado, genera un evento de auditoría con identidad, marca de tiempo, IP, dispositivo y decisión tomada, exportable a través de Logpush a SIEM, Splunk o Datadog.
Lo que Zero Trust no hace
Cloudflare Zero Trust controla quién llega a qué, pero no es una solución para cifrar datos en tránsito dentro de la aplicación; esto sigue siendo responsabilidad de la aplicación a través de HTTPS. Access tampoco reemplaza un firewall para el tráfico de este a oeste entre servicios dentro del centro de datos o VPC. Para la comunicación interna entre microservicios, mTLS o malla de servicios sigue siendo el mecanismo apropiado.
Un punto que se pasa por alto en las implementaciones iniciales: el túnel protege la ruta entre el borde de Cloudflare y el servidor de origen, pero el servidor todavía solo necesita confiar en las conexiones que llegan a través de cloudflared. Si el puerto 443 está abierto a Internet fuera del túnel, se puede omitir el acceso. La práctica correcta es bloquear todo el tráfico entrante al servidor excepto el generado por el demonio del túnel local.
Qué cambia la adopción operativamente
El cambio más significativo no es técnico: es el modelo mental de quien gestiona el acceso. Con VPN, el equipo de red configura rutas y divide túneles; Con Zero Trust, el equipo de identidad configura políticas por aplicación. La gestión de acceso sale del nivel de red y entra en el nivel de identidad. Para las organizaciones con equipos de red y seguridad separados, esto implica negociar la responsabilidad.
El nivel gratuito (hasta 50 usuarios con Access, Tunnel, WARP y Gateway básico) es suficiente para la validación de producción. El plan Team cuesta $7 por usuario por mes y agrega registros de auditoría y Gateway con filtrado HTTP. Enterprise agrega aislamiento de navegador, DLP y seguridad de correo electrónico, con precios negociados. Para equipos con más de 50 usuarios que ya tienen Okta o Azure AD consolidados, el esfuerzo de implementación rara vez supera las cuatro semanas de trabajo real.
Qué evaluar antes de migrar
La decisión de pasar a Zero Trust no tiene que ver con la tecnología, sino con dónde se encuentra el mayor riesgo de seguridad en la actualidad. Si su VPN actual otorga acceso amplio a la red después de la autenticación, una credencial comprometida expone toda la red interna. Zero Trust limita el radio de explosión: el acceso comprometido alcanza solo el conjunto de aplicaciones permitidas explícitamente para esa identidad, con la postura del dispositivo como control adicional.
Comience con la aplicación con mayor riesgo de exposición y mayor costo en caso de fuga. Migrarlo primero, con una política de grupo restringido y una postura de dispositivo obligatoria, valida el modelo completo en producción con un impacto controlable. El patrón probado allí se replica en el resto de la cartera.