Existe una confusión recurrente entre los equipos que están adoptando Cloudflare Zero Trust: tratar Access y Tunnel como partes intercambiables del mismo sistema, cuando en la práctica son productos con responsabilidades completamente diferentes. Un ingeniero que configura el túnel y asume que la autenticación está resuelta está publicando un servicio privado sin puertas de identidad. Comprender qué hace cada pieza (y cuándo vale la pena usar una sin la otra) es lo que separa una implementación bien diseñada de una laguna que espera ser explotada.
¿Qué hace Cloudflare Access?
El acceso es un proxy de identidad. Se ubica frente a un nombre de host (app.empresa.com, por ejemplo) e intercepta cada solicitud antes de que llegue al origen. Cuando el usuario no tiene una sesión válida, Access redirige al proveedor de identidad configurado. Después de una autenticación exitosa, Access evalúa la política asociada con esa aplicación: ¿el usuario pertenece al grupo permitido? ¿La autenticación utilizó MFA? ¿El dispositivo es compatible? Si se cumplen todas las condiciones, Access emite una sesión JWT y la solicitud va al origen.
La fuente puede ser cualquier cosa: un servidor con una IP pública, un servicio interno, un túnel. A Access no le importa dónde está la fuente; le importa quienquiera que esté tratando de llegar allí. Esta distinción es importante porque significa que Access funciona frente a aplicaciones que ya tienen una IP pública, sin necesidad de un Túnel. Si tienes una aplicación con IP pública que necesita control de acceso basado en identidad corporativa, Access soluciona esto sin mover la aplicación ni instalar cloudflared.
Qué hace el túnel Cloudflare
Tunnel resuelve un problema diferente: cómo hacer que un servidor privado sea accesible a través de Internet sin abrir puertas de enlace en el firewall. El demonio cloudflared, instalado en el servidor o en un contenedor en la misma red, establece una conexión saliente cifrada al borde de Cloudflare. A partir de ahí, Cloudflare actúa como intermediario: el tráfico entrante llega al borde y viaja por el túnel ya establecido hasta el servicio interno.
El resultado es que el servidor interno no tiene una IP pública, no tiene el puerto 80 o 443 abierto a Internet y no necesita una regla de entrada en el grupo de seguridad o firewall. El único tráfico que ingresa es el que proviene del propio proceso cloudflared que se ejecuta localmente. Los usuarios autorizados ahora pueden acceder a un servidor completamente aislado del acceso externo directo a través del borde de Cloudflare.
cloudflared se puede configurar como un servicio systemd, un contenedor Docker o una implementación de Kubernetes. La configuración moderna utiliza el panel de Cloudflare para administrar el túnel: no hay un archivo YAML local, con la configuración propagada a través de API. Un solo proceso cloudflared puede exponer múltiples servicios en diferentes nombres de host: app1.empresa.com va al puerto 3000 localmente, app2.empresa.com va al puerto 4000, db-admin.empresa.com va a pgAdmin en el puerto 5050.
Cuándo utilizar Túnel sin Acceso
La creación de túneles sin acceso es un escenario válido y común: desea enrutar el tráfico desde una aplicación pública a través del borde de Cloudflare para protección DDoS y CDN, sin autenticación adicional. El servicio es de acceso público, pero el tráfico llega al servidor sólo a través de Cloudflare, sin exposición directa de la IP de origen. Cloudflare protege contra ataques volumétricos y el servidor está oculto.
Otro uso: desarrollo local compartido. Un desarrollador quiere mostrar un prototipo que se ejecuta localmente a alguien fuera de la red. cloudflared tunnel --url localhost:3000 crea una URL temporal de acceso público sin configuración de DNS o firewall. Sin acceso, sin autenticación, pero útil para el caso específico.
El riesgo es asumir que Túnel implica protección. No implica. El túnel es conectividad. Sin Acceso al frente, cualquier solicitud que llegue al nombre de host configurado en Cloudflare llega a su servicio interno.
Cuándo utilizar Acceso sin Túnel
El acceso sin túnel tiene sentido cuando la fuente ya tiene una IP pública: un servidor en EC2 con una IP elástica, una aplicación en un PaaS, un punto final API con una dirección pública. Access actúa como proxy de identidad frente a esta dirección pública, sin necesidad de cloudflared.
El detalle operativo crítico en este escenario: el origen debe aceptar tráfico solo desde el borde de Cloudflare. Si el servidor continúa aceptando solicitudes de cualquier IP, se puede omitir el acceso simplemente accediendo a la IP directamente. La práctica correcta es configurar el servidor para que acepte tráfico solo de los rangos de IP de Cloudflare, o usar un encabezado autenticado que Access inyecta y la aplicación verifica.
La combinación que realmente ofrece Zero Trust
La combinación de los dos es lo que implementa el modelo Zero Trust completo: Tunnel hace que el servidor privado sea accesible a través de Cloudflare; El acceso requiere autenticación y evaluación de políticas antes de permitir que cualquier solicitud pase por el túnel. El servidor interno nunca tiene exposición directa a Internet y nunca recibe solicitudes no autenticadas.
El flujo: el usuario accede al nombre de host → Access comprueba la sesión, redirige al IdP si es necesario → después de la autenticación y la verificación de políticas, Access reenvía la solicitud al borde → el borde baja por el túnel → cloudflared la entrega al proceso local. El servidor interno sólo ve el tráfico ya autorizado por Access.
Para el acceso de máquina a máquina (canalizaciones de CI/CD, agentes de monitoreo, integraciones), el acceso emite tokens de servicio: una identificación de cliente y un secreto que reemplaza el flujo de SSO humano. El servicio automatizado incluye estos tokens en el encabezado de la solicitud y Access los reconoce como una identidad de servicio confiable y aplica la política asociada. Cada acceso mediante token de servicio también genera un evento de auditoría.
La visión de quienes diseñan el sistema
Un punto que se pasó por alto durante la fase de diseño: el túnel no tiene costo de salida en Cloudflare. Al tráfico que pasa por cloudflared no se le cobra por el ancho de banda en el plan Team. Esto tiene implicaciones de costos reales en comparación con alternativas que cobran por GB transferido e influye en la decisión de utilizar Cloudflare Tunnel frente a soluciones de túneles similares.
La decisión arquitectónica central al adoptar ambos componentes es: ¿dónde están las políticas de acceso? El acceso le permite crear políticas granulares por aplicación: un grupo tiene acceso al panel de administración, otro tiene acceso de solo lectura al monitoreo y los colaboradores externos solo acceden al portal de documentación. Esta granularidad no existe en la VPN tradicional. El costo de mantener esta granularidad es la gestión continua de las políticas a medida que los equipos cambian y las aplicaciones evolucionan. Automatizar esto a través de Terraform o la API de Cloudflare es el paso que transforma la gestión de acceso de una tarea manual a un proceso controlado.