OpenZiti en cooperativas: acceso por servicio y corte
Un caso anonimizado muestra cómo publicar soporte remoto por identidad, servicio y política, con corte probado antes de abrir puertos de red.
Una clave de VPN sobrevivió a dos bajas de proveedor. En una cooperativa de servicios de Cuyo, ese incidente bastó para revisar accesos remotos a facturación, monitoreo y mesa de ayuda. OpenZiti permite publicar servicios por identidad y política, con túneles salientes y autorización por uso. Este caso anonimizado muestra qué se instala, cómo se corta y cómo se prueba la salida.
Dónde aparece el acceso que sigue vivo
La escena es conocida: un proveedor necesita entrar al servidor de facturación para revisar un error y alguien busca una clave vieja en una planilla. El objeto que delata el desorden es una etiqueta blanca pegada al rack con nombre de VPN, usuario genérico y una fecha que ya nadie defiende. El acceso compartido siempre dura más que el contrato. La introducción de OpenZiti lo describe como una plataforma abierta de red zero trust para hacer invisibles los servicios ante usuarios sin autorización. En una cooperativa, esa promesa se traduce en algo concreto: el proveedor ve solo el servicio autorizado, durante el período autorizado, desde una identidad registrada. El repositorio openziti/ziti publica el proyecto con licencia Apache 2.0 y describe una red programable zero trust. La versión más reciente verificada por API fue v2.0.3, publicada el 20 de agosto de 2026. La fecha importa porque el piloto debe fijar versión, respaldo y procedimiento de actualización antes de abrir soporte externo.
Cómo funciona por dentro
El flujo mínimo tiene siete piezas. Primero, un controlador guarda identidades, servicios y políticas. Segundo, uno o más edge routers transportan el tráfico autorizado. Tercero, cada persona, equipo o servicio recibe una identidad. Cuarto, el administrador define un servicio, por ejemplo SSH a un servidor de monitoreo o HTTPS a una aplicación interna. Quinto, una política Dial indica qué identidades pueden usar ese servicio. Sexto, una política Bind indica qué identidad puede ofrecerlo desde el lado interno. Séptimo, el tunneler levanta una conexión saliente y evita publicar un puerto directo hacia internet. La documentación de políticas separa autorización de servicio y acceso a routers, lo que obliga a declarar permisos en más de una capa. La parte más útil para una pyme es la revocación. Si un proveedor termina contrato, se deshabilita su identidad y la política deja de autorizar sesiones nuevas. Si un servidor cambia, se actualiza el servicio y queda registro. Si un equipo de soporte necesita acceso temporal, se agrega una identidad con vencimiento operativo y revisión posterior.
Qué se instala o configura primero
El piloto comienza con un entorno chico. La guía local con Docker Compose alcanza para aprender piezas y validar conceptos, aunque producción pide persistencia, copias, dominio, certificados y monitoreo. La primera meta no es migrar toda la red; la primera meta es publicar un servicio real con identidad propia y corte probado. La configuración inicial incluye controlador, edge router, identidad de administrador, identidad de proveedor, identidad del servicio, política Dial, política Bind, backup del controlador, registro de cambios y prueba de baja. La documentación de identidades permite pensar cada acceso como persona, dispositivo o servicio, con atributos usados por políticas. El registro de cambios tiene que quedar fuera de la memoria del administrador. Cada alta de identidad necesita responsable, motivo, servicio autorizado y fecha de revisión. Cada baja necesita comprobante, intento de sesión y captura del rechazo. Para una cooperativa con guardias rotativas, ese detalle evita discusiones cuando soporte atiende de noche y nadie recuerda si el proveedor debía conservar acceso al sistema de monitoreo. El costo mensual de un piloto local puede ubicarse entre USD 25 y USD 90, equivalentes a ARS 38.375 y ARS 138.150 con dólar oficial vendedor de ARS 1.535 publicado por DolarAPI. La implementación inicial suele ocupar entre 16 y 28 horas si existen dominios, responsables y servicios definidos. La limpieza de contratos, revisión legal y cambios de arquitectura quedan afuera de ese rango. UMSA suele pedir una salida medible. El proveedor entra a un solo servicio, ejecuta una tarea controlada, deja evento, pierde acceso al deshabilitar la identidad y el servicio interno queda fuera de escucha pública. El entregable no es un diagrama; es una sesión, una baja y una verificación repetible.
Dónde se rompe y cómo probarlo Primer riesgo: identidad genérica.
La señal aparece cuando dos personas usan el mismo enrolamiento. La prueba crea una identidad por usuario, ejecuta dos accesos y verifica registros separados. Segundo riesgo: servicio demasiado amplio. La señal aparece cuando una política da acceso a una subred completa en vez de una aplicación. La prueba publica un servicio único y confirma que los demás puertos quedan cerrados. Tercer riesgo: edge router sin política correcta. La señal aparece cuando la identidad existe, el servicio existe y la conexión falla. La prueba usa el asesor de políticas y documenta qué identidad puede llegar a qué router. Cuarto riesgo: baja incompleta. La señal aparece cuando el proveedor pierde usuario en una aplicación pero mantiene túnel. La prueba deshabilita identidad, conserva servicio, intenta sesión nueva y guarda resultado. Quinto riesgo: respaldo que olvida certificados o base del controlador. La prueba restaura en otro host y confirma que identidades, políticas y servicios sigan consultables. El caso cierra cuando soporte puede entrar, trabajar y salir sin dejar una puerta heredada.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.