Rela AIRela AI Docs
Conectividad VPN

¿Por qué un túnel dedicado?

Las 9 razones técnicas y de cumplimiento por las que Rela AI no usa la VPN corporativa de nuestros clientes — y qué ganan con un peer WireGuard dedicado.

¿Por qué no usamos tu VPN corporativa?

Cuando negociamos el acceso a un cliente nuevo, la propuesta más habitual del equipo de IT es "te damos credenciales de nuestra VPN corporativa". Tiene lógica desde su perspectiva: ya existe, ya está configurada, ya saben cómo gestionarla. Pero si aceptamos, estaríamos creando varios problemas técnicos y de compliance serios. Por eso exigimos un túnel dedicado a la infraestructura OT. Acá van las 9 razones ordenadas por severidad.

¿Para qué sirve un túnel dedicado?

Para que Rela AI pueda llegar al PLC del cliente sin atravesar la red corporativa (IT) ni mezclarse con el tráfico de empleados. El tráfico entra por un punto, toca solo el subnet OT, y sale — con trazabilidad completa y revocable al instante.

¿Cómo funciona?

WireGuard establece un túnel punto a punto con cifrado Curve25519, autenticación por clave asimétrica, y routing controlado por allowed-ips. Nosotros limitamos allowed-ips al subnet OT del cliente; todo lo demás queda fuera del alcance del túnel. La llave privada vive en el router del cliente y nunca sale de ahí.

Los 9 motivos

1. Aísla IT de OT (IEC 62443 / Purdue Model)

La norma industrial de ciberseguridad IEC 62443 (y su ancestro ISA-99 / Purdue Model) exige que el acceso a la capa OT no comparta el camino del acceso a la capa IT. Usar la VPN corporativa colapsa esa separación en cuanto un paquete llega: auditoría muerta, findable para auditores.

2. Mínimo privilegio

Un usuario de VPN corporativa típicamente llega a toda la red: SharePoint, Jira, mail, impresoras, ERP, y la red OT. Nosotros solo necesitamos leer el PLC. Reducir privilegio significa que una credencial robada afecta un subnet, no la empresa entera.

3. Reducir blast radius en caso de brecha

Si Rela AI sufre una brecha con credenciales de tu VPN corporativa, el atacante tiene acceso a toda tu corporación. Con WireGuard aislado y allowed-ips=10.200.X.0/24, el mismo atacante accede solo al subnet OT que ya expusiste a propósito. La asimetría de riesgo es tuya a favor.

4. Cumplimiento CISA / NIST SP 800-82

Las guías oficiales de seguridad industrial de la CISA y del NIST (Special Publication 800-82) recomiendan explícitamente:

"Remote vendor access to OT environments SHALL use dedicated, purpose-specific connections separated from general-purpose corporate remote access."

Traducción: si auditan tu planta, usar la VPN corporativa para un proveedor externo es un findable.

5. MFA máquina-a-máquina es un antipatrón

La VPN corporativa casi seguro requiere MFA (push Duo, TOTP, SAML). Está diseñada para humanos que aprueban. Nosotros somos una máquina que poll cada 5 segundos. Las opciones son todas malas:

  • Almacenar TOTP secret → la credencial MFA se vuelve estática (rompe el propósito del MFA).
  • Usar bypass flags en el IdP → agujero de auditoría para tu SOC.
  • Apagar MFA para ese usuario → tu CISO dice que no.

WireGuard es autenticación por clave asimétrica rotable, pensada para máquinas desde el día 1.

6. Zero Trust alignment

El estándar que reemplaza "VPN corporativa + red de confianza" es Zero Trust (NIST SP 800-207). Filosofía: "never trust the network, always verify". WireGuard con peer explícito + allowed-ips limitados es exactamente microsegmentación. La VPN corporativa es el antipatrón que Zero Trust está empujando al retiro.

7. Custodia de llaves asimétrica

Tu VPN corporativaWireGuard dedicado
¿Quién tiene tu credencial?Nosotros (user/pass en secret)Tu router (llave privada local)
¿Cómo la revocás?Llamás a tu ITBorrás el peer en tu router
Tiempo de revocaciónHoras (si hay ticket)Segundos
¿Expira?Sí, por política de passwordNunca (rotás cuando querés)
¿Podemos acceder si nos echás?Solo si tu IT avisa a tiempoImposible — la llave se queda en tu hardware

8. Trazabilidad y cumplimiento

Cuando tu auditor de SOC 2, ISO 27001 o IEC 62443 pregunta "¿quién puede llegar a tus PLCs?", con VPN corporativa la respuesta es:

"Rela AI tiene un usuario VPN, pero también 400 empleados, 12 consultores y acá está el log de 6 meses mezclado."

Imposible demostrar control.

Con WireGuard dedicado:

"El peer rela-ai con public key abc… y allowed-ips 10.200.7.0/24. Último handshake hace 3 segundos. Acá está el log de handshakes de los últimos 90 días."

Auditor firma y se va.

9. Data leakage por full-tunnel

Si tu VPN corporativa fuerza full-tunnel (todo el tráfico de la estación remota pasa por tu red), nuestro tráfico a MongoDB Atlas, Gemini API, SendGrid, etc., pasaría por tu firewall corporativo. Eso:

  • Te convierte en responsable de datos que no son tuyos (privacy / GDPR).
  • Expone metadata de todos nuestros tenants a tu SOC.
  • Rompe SLAs contractuales con nuestros otros clientes.

Con WireGuard dedicado + allowed-ips limitado, solo el tráfico al subnet OT cruza tu red. El resto sale directo de Cloud Run a internet.

Beneficios

  • Compliance garantizado: IEC 62443 § 6.4, SOC 2 CC6.6, ISO 27001 A.9.2.
  • Zero Trust alineado: cumple con NIST SP 800-207.
  • Costo cero de licenciamiento: WireGuard es open source.
  • Revocación en segundos: sin depender de tickets de IT.
  • Trazabilidad per-peer: el auditor ve exactamente quién puede alcanzar qué.

¿Y si aún así mi IT quiere usar su VPN corporativa?

Por las razones de arriba, no lo soportamos. Si tu IT insiste en un modelo "ustedes conectan como clientes a mi VPN empresarial", eso queda fuera del self-service y cae en deployment custom con precio enterprise — requiere un túnel IPsec IKEv2 site-to-site dedicado (no usuario/pass corporativo), y aun así recomendamos el modelo estándar.

El camino correcto está documentado en Alta y Configuración.

En esta página