Incluso con «salir de la VPN», la IP fija no se puede abandonar: una solución realista para la transición a Zero Trust en pequeñas empresas

Hola, soy Otsuka, CTO de Liberogic.

"La VPN ya nos queda pequeña"

Seguro que más de uno de quienes en una pequeña empresa llevan también el departamento de sistemas lo ha pensado alguna vez.
En nuestro caso era exactamente así.

Zero Trust, SASE, dejar la VPN...
Son términos que se ven con frecuencia, pero suenan a algo pensado para grandes corporaciones, y cuesta saber por dónde empezar.

En ese contexto, Liberogic, una empresa de desarrollo web de unos diez empleados, pasó de una VPN a una configuración de tipo Zero Trust.
En este artículo les contamos, tal como lo vivimos, por qué hicimos el cambio, qué cambió y también los puntos débiles.

La VPN como señal de que ya "no da más"

Durante mucho tiempo usamos la función VPN del router de la oficina.
Es una configuración habitual: desde casa o desde fuera te conectas primero a la red de la empresa y luego sales a Internet desde allí.
Sin embargo, en los últimos años nos preocupaban algunas cosas.

• La norma "fuera de la oficina, conéctate a la VPN antes de trabajar" se quedaba en una simple petición
• Es posible que la VPN no funcione en Wi-Fi de cafeterías, lugares de trabajo fuera de la oficina o las oficinas de clientes.
• Las videollamadas y la sincronización de archivos en la nube pasaban todas por la red de la empresa, y eso las hacía lentas
• Un router se limita a transmitir el tráfico; no bloquea sitios peligrosos.

Si se cumple al menos uno de estos puntos, quizá sea buen momento para replantearse la configuración.

Un punto que nos preocupaba especialmente era que no podíamos obligar a usar la VPN.
La VPN estándar de macOS requiere que cada persona la conecte manualmente cada vez que enciende el equipo. Si un dispositivo se olvida de conectarse, su tráfico sale directamente a través de la red local sin ninguna protección.

El riesgo de las redes no confiables está aumentando

También quiero comentar otro hecho reciente.

En octubre de 2026 se descubrió que las claves privadas de ocho certificados intermedios de eMudhra, una autoridad de certificación de India, habían sido comprometidas.
Según la explicación de Cloudflare, las claves eran débiles y permitían crear certificados falsos para cualquier dominio.
Cabe destacar que estos certificados eran ampliamente confiables para los navegadores y los sistemas operativos.

Al evaluar los riesgos de conectarse a una red Wi-Fi desconocida, pensaba que, como hoy en día se usa HTTPS en lugar de HTTP, el riesgo era relativamente bajo. Sin embargo, creo que debo replantearme este punto con más detenimiento.

Zero Trust / SASE / ZTNA: diferencias en pocas palabras

Al empezar a investigar, aquí es donde suele surgir la confusión. Para una pequeña empresa, creo que con esto basta para entender lo esencial.

Zero Trust es el nombre del enfoque, mientras que ZTNA y SWG son formas de servicio que lo hacen realidad, y SASE es el panorama completo que los agrupa.

En lugar de plantearse "hay que implantar SASE", creo que para una empresa pequeña es más adecuado partir de qué problemas tiene con la VPN y qué quiere resolver.

En nuestro caso, casi no teníamos sistemas de gestión internos.

El uso habitual de una VPN suele ser acceder desde fuera de la empresa a los sistemas de gestión internos o a los servidores de archivos.

Sin embargo, nosotros apenas contamos con este tipo de infraestructura interna. Casi todas las herramientas que usamos en el trabajo son servicios en la nube. Por eso, no teníamos la preocupación de "cómo sustituir el punto de entrada a los sistemas internos".

Si su empresa tiene sistemas de gestión internos, probablemente este sea el punto central de la evaluación.

Lo que suele complicar la migración es la "IP fija".

En el caso de las agencias de desarrollo, es habitual que los paneles de administración de los servidores de los clientes y el acceso por SSH tengan una restricción del tipo "solo se puede acceder desde esta dirección IP". Es una medida de seguridad y una práctica operativa muy acertada.

Además, durante años hemos pedido a muchísimos clientes que "permitan nuestra IP fija". Esta configuración es, en cierto modo, un activo que hemos ido acumulando.

Los servicios de Zero Trust también ofrecen la posibilidad de que el tráfico salga desde una IP determinada.
Cloudflare tiene una función llamada "egress IP dedicada", pero es un complemento del plan Enterprise y está pensada para grandes empresas.
Para una empresa pequeña como la nuestra, era difícil de usar.

Además, si cambia la IP de salida, tendríamos que pedir de nuevo a todos los clientes que modifiquen su configuración.
Esto no es realista.

En resumen, lo que queríamos eran estas tres cosas.

1. Proteger a todo el equipo desde cualquier lugar, sin olvidar ninguna conexión
2. Que el tráfico normal no tenga que pasar innecesariamente por la empresa
3. Pero que, hacia los destinos que lo requieran, se siga saliendo desde la IP fija de la empresa, como hasta ahora

Nuestra elección: la protección pasa a la nube y solo la salida se mantiene con la IP fija actual

Elegimos Cloudflare One.

• Se instala en cada PC un software llamado WARP: al iniciarse, la conexión se activa, así que es menos probable que alguien olvide conectarse.
• Gateway bloquea el acceso a sitios peligrosos: las conexiones relacionadas con sitios de malware o phishing se bloquean según reglas aplicadas a toda la empresa.
• El tráfico habitual sale directamente de Cloudflare hacia Internet: no pasa por la red de la empresa.
• Solo los servidores de los clientes salen con la IP fija de la empresa: se coloca un pequeño equipo en la oficina y se conecta con la empresa mediante un canal llamado Cloudflare Tunnel.

El último punto fue decisivo para nosotros: permite definir destino por destino que «este destino siempre pase por la red de la empresa».
Para los clientes, los accesos siguen llegando desde la misma IP fija de siempre, así que no hace falta cambiar nada en su configuración.

Además, los equipos internos se conectan de forma saliente a Cloudflare, por lo que no hace falta abrir puertos en el router y no se añaden nuevos puntos de entrada a la red desde el exterior.

Por supuesto, también es una gran ventaja no depender solo de la atención de las personas cuando surge un problema como el del certificado intermedio.
En el caso de eMudhra, Cloudflare nos indicó que, si se usan Gateway y el cliente más reciente, la protección es automática.

Qué cambió

WARP se inicia automáticamente al arrancar el Mac y se conecta por sí solo. El personal no necesita recordar cómo conectarse a la VPN ni preocuparse por configuraciones detalladas. Reforzar la seguridad suele aumentar el trabajo en el terreno, pero en este caso ha reducido las tareas. La facilidad de uso ha sido lo que más nos ha sorprendido al implementarlo.

También se pueden crear aplicaciones internas accesibles solo a través de WARP

Cloudflare One incluye una función llamada Access, que permite limitar qué personas y dispositivos pueden abrir una aplicación web. Con ella, se pueden crear aplicaciones que solo se pueden abrir desde dispositivos conectados a Cloudflare One de la empresa a través de WARP.

Por ejemplo, puede permitir el acceso solo cuando se cumplan ambas condiciones siguientes.

• Ha iniciado sesión con su correo electrónico corporativo
• Está conectado a Cloudflare One de la empresa mediante WARP

Aunque la URL sea conocida, no se puede abrir desde dispositivos que no cumplan las condiciones. Es una forma similar a "colocar el sistema interno dentro de la VPN", pero creada sin VPN.

Las aplicaciones que se ejecutan en servidores internos también pueden protegerse de la misma manera, conectándolas con Cloudflare Tunnel y sin abrir puertos.

Las aplicaciones de administración que presentamos a continuación también están protegidas con este método.

Con espíritu DIY, también creamos pequeñas aplicaciones de administración

Quedó un problema. Cada vez que aumentan los servidores de los clientes, es necesario registrar que "este destino sale con una IP fija", pero el panel de administración de Cloudflare utiliza muchos términos técnicos y un error de configuración afecta a la comunicación de todos. Tampoco podemos dar permisos de administrador a todo el equipo.

Por eso creamos una aplicación interna con la que el personal puede registrar los destinos simplemente seleccionando el objetivo.

• Queda registro de quién lo añadió y con qué fin.
• No se pueden registrar servicios de uso en toda la empresa ni ámbitos demasiado amplios.
• Tras el registro, puedes comprobar al momento que los cambios se han aplicado correctamente.

Cloudflare permite configurar sus ajustes mediante API, por lo que también podemos crear herramientas internas como estas. Como desarrollamos aplicaciones web con regularidad, este es un terreno en el que tenemos mucha experiencia.

Sobre los costes

Cloudflare One incluye un plan gratuito de hasta 50 usuarios.
Como es el mismo límite de usuarios que Cloudflare Access, que se usa para gestionar el inicio de sesión de herramientas internas, quienes ya utilizan Access podrán probarlo aún más fácilmente.
Si superas los 50 usuarios, pasas a un plan de pago, cuyo precio público es de 7 dólares al mes por usuario.

Seguimos usando la línea con IP fija que ya tenemos.
Lo único que se necesita además es un equipo que esté siempre encendido dentro de la oficina.
Nosotros hemos preparado un ordenador pequeño y dedicado para ello.

Para ser sinceros, no lo resuelve todo

No tendría sentido contar solo lo bueno, así que también mencionamos los puntos a tener en cuenta.

• Si el túnel se detiene, no se podrá salir con la IP fija: si el ordenador pequeño de la oficina o la línea dejan de funcionar, no se podrá acceder a los servidores de los clientes. La web normal seguirá funcionando, pero es imprescindible contar con notificaciones que avisen cuando algo se detiene.
• Mayor dependencia de Cloudflare: la autenticación y las rutas de acceso se concentran en un solo proveedor. Es el precio de la comodidad.
• Hay que instalarlo en cada PC: WARP y el certificado se configuran una vez por dispositivo. En los smartphones hay más trabajo manual.
• Hay que verificar el uso junto con una VPN del cliente: según la configuración de rutas y DNS, la protección de Gateway puede dejar de funcionar. Nosotros explicamos los pasos en el manual de conexión.
• No inspecciona el contenido de las comunicaciones: no realizamos descifrado TLS. Si quiere inspeccionar en detalle todo el tráfico, necesitará considerar otra solución.
• El plan gratuito no ofrece soporte extenso: en general, los problemas deberá investigarlos usted mismo. Además, en el plan gratuito los registros se conservan como máximo 24 horas.

Empresas adecuadas y no adecuadas

Creemos que esta solución es adecuada para empresas como estas.

• Empresas con entre unos pocos y varias decenas de empleados, con personas que trabajan fuera de la oficina o en remoto
• Empresas que no pueden renunciar al control de acceso por IP fija
• Empresas que utilizan principalmente servicios en la nube y tienen pocos servidores internos
• Al menos una persona con experiencia puede participar y probarlo mientras investiga.

Por otro lado, en los siguientes casos creo que conviene considerar otros productos o consultar con empresas especializadas.

• Las normas del sector exigen conservar los registros a largo plazo y realizar inspecciones detalladas de las comunicaciones.
• Muchos dispositivos no son gestionados por la empresa, por lo que no es posible instalar software en ellos.
• No hay nadie que pueda responder cuando el túnel se detiene.

Conclusión

Hasta ahora, solo pedíamos que se instalara un antivirus en los Mac, sin especificar los ajustes detallados. Esta vez, junto con la implementación de Cloudflare One, configuramos internamente los distintos ajustes de macOS y también los del antivirus.

Sin embargo, con los ataques dirigidos a creadores y desarrolladores cada vez más intensos, lo que hay que proteger no se limita a eso. En Liberogic también trabajamos en lo siguiente.

Gestión de dependencias
Ante el aumento de los ataques a la cadena de suministro dirigidos a desarrolladores, revisamos el modo de incorporar y verificar los paquetes, en lugar de limitarnos a actualizarlos a la última versión sin más.

Gestión de información secreta
Las claves de API y las claves SSH se gestionan con reglas definidas en 1Password, y en la medida de lo posible evitamos dejarlas en texto plano en los entornos de desarrollo.

Mínimo privilegio y revisión periódica
Limitamos las cuentas, claves y permisos de los entornos de clientes y de los distintos servicios al alcance necesario, y no los dejamos activos una vez finalizado el proyecto.

Compartir aprendizajes
Usamos incidentes que se han hecho públicos como material para nuestras sesiones de estudio internas, y los analizamos preguntándonos si nos afectarían a nosotros y cómo se aplicaría a nuestro entorno.

Por supuesto, debemos tener cuidado de no provocar incidentes graves, pero, dado el tamaño de nuestra empresa, trabajamos con muchos clientes de gran envergadura, por lo que debemos mantener un nivel constante de estándares de seguridad.
Ninguna de estas medidas es espectacular, pero vamos acumulando, paso a paso, lo que está en nuestra mano.

Esperamos que sirva de referencia a otras empresas que enfrentan los mismos desafíos.