Skip to content
← Todas las publicaciones
· Delta1 Labs LicenciamientoSeguridadGuía

Licenciamiento para entornos aislados (air-gapped) y sin conexión

Cómo funciona la activación de licencias en entornos aislados (air-gapped): archivos de licencia offline firmados, flujos de activación manual, caducidad y gracia sin conexión, y revocación sin red.

La pregunta de licenciamiento más angustiosa que me han hecho vino de un contratista de defensa: “Nuestra red de producción no tiene internet, nunca, y nunca lo tendrá. ¿Puede funcionar ahí dentro tu licenciamiento?”. Es una pregunta justa que hace tropezar a un número sorprendente de productos de licenciamiento, porque muchos de ellos asumen en silencio que una máquina puede llamar a casa. En un entorno verdaderamente aislado (air-gapped) —una red clasificada, un sistema de control industrial aislado, una instalación segura— no hay llamada a casa. Hay un pendrive USB y un oficial de seguridad que inspecciona lo que hay en él.

La respuesta tranquilizadora es que el licenciamiento sin conexión no es un modo degradado; bien hecho, es uno plenamente legítimo, construido sobre la misma criptografía que todo lo demás. Este artículo explica cómo funciona de verdad la activación aislada y sin conexión: blobs de licencia firmados, el baile de la activación manual, la caducidad y la gracia sin un servidor de reloj, y la revocación sin red.

Conclusión clave: El licenciamiento aislado (air-gapped) funciona porque la confianza viene de la criptografía, no de la conectividad. Un blob de licencia firmado se verifica localmente contra una clave pública embebida con cero llamadas de red, así que una máquina totalmente desconectada puede probar que una licencia es auténtica, inalterada, vinculada a ella y no caducada, y rechazar una revocada mediante una lista firmada que envías fuera de banda.

Por qué la validación sin conexión es posible en absoluto

Si has leído la validación de licencias sin conexión explicada, conoces la asimetría central, así que seré breve y construiré sobre ella hacia el caso aislado. Tu servidor tiene una clave privada que puede crear firmas; el cliente embebe solo la clave pública correspondiente, que puede verificar una firma pero nunca falsificarla. Verificar una firma es pura matemática sobre datos que la aplicación ya tiene, así que el cliente puede confirmar que una licencia fue firmada por ti —y que no ha sido alterada ni en un solo byte— sin un servidor en vivo. Esa única propiedad es lo que hace real el licenciamiento aislado en lugar de un compromiso.

Todo en este artículo es una aplicación de esa idea al despliegue más duro: una máquina que nunca verá la red, ni una sola vez.

El blob de licencia firmado

La unidad de una licencia sin conexión es un blob firmado: una pequeña carga útil de hechos con una firma sobre ella. Conceptualmente:

{
  "licensee": "Acme Defense Systems",
  "product": "acme-analyzer",
  "tier": "enterprise",
  "seats": 5,
  "expiryUtc": "2027-09-29T00:00:00Z",
  "machineFingerprint": "b3f1…c9a2",
  "entitlements": { "export": "true", "max-projects": "50" },
  "signature": "MEUCIQ…"   // over every field above, made with the vendor's private key
}

El cliente verifica la firma contra su clave pública embebida, y solo entonces lee los campos ahora de confianza. Cambia tier de enterprise a cualquier otra cosa, o edita expiryUtc, y la firma ya no coincide: la validación falla. El campo machineFingerprint es lo que bloquea por equipo el blob a una máquina, de modo que el mismo archivo no se puede copiar por toda una flota aislada (los detalles de huella y tolerancia al cambio están en bloqueo por equipo y gestión de puestos).

El flujo de activación manual

Aquí está la parte única de la operación aislada: ¿cómo obtiene un blob firmado vinculado a su huella una máquina que no puede hacer una solicitud? Mediante un intercambio de archivos: el baile de la activación sin conexión:

  1. Genera una solicitud en la máquina sin conexión. La aplicación produce un pequeño archivo de solicitud que contiene la huella de la máquina (y la clave de licencia o referencia de pedido). No interviene ninguna red; simplemente escribe un archivo.
  2. Sácalo. Un pendrive USB, un canal de transferencia de archivos aprobado, lo que permita la instalación. La solicitud va a una máquina conectada.
  3. Envíalo al servicio de emisión. Desde la máquina conectada —un navegador en el portal del proveedor, o una consola de administración— se envía la solicitud. El servicio la valida, consume un puesto si corresponde y devuelve un archivo de activación firmado vinculado a esa huella exacta.
  4. Llévalo de vuelta e impórtalo. El archivo firmado vuelve a la máquina sin conexión por el mismo canal y se importa. La aplicación verifica la firma localmente y se activa.

A partir de ahí la máquina valida enteramente sin conexión, para siempre si hace falta. El paso conectado ocurrió una vez, en una máquina diferente, y solo movió archivos firmados: nunca existió una conexión en vivo desde el host seguro. Eso es lo que satisface a un oficial de seguridad: la postura de red de la máquina aislada nunca cambió.

Para despliegues donde incluso ese ida y vuelta es impracticable, la variante más simple es saltarse la solicitud/respuesta y emitir un archivo previnculado: el proveedor emite un blob firmado para una huella conocida (o un archivo sin vincular, no bloqueado por equipo, para un número fijo de instalaciones) y lo envía con el software. Menos preciso, pero a veces es el único flujo viable.

La caducidad y el problema de la manipulación del reloj

Una suscripción o prueba lleva un expiryUtc, y la validación sin conexión simplemente lo compara con la hora actual: fácil. El ataque obvio es igual de fácil: retrasa el reloj del sistema y una prueba nunca termina, o una licencia caducada vuelve a la vida. Una máquina aislada no tiene un servidor de hora al que apelar, así que la defensa tiene que ser local.

El enfoque estándar es el seguimiento de tiempo monotónico: la aplicación recuerda la última hora que ha visto legítimamente y trata un reloj que salta significativamente hacia atrás como manipulación, negándose a validar hasta que se corrija la hora. Una pequeña ventana de tolerancia (un día más o menos) absorbe los ajustes de reloj honestos y las rarezas de zona horaria sin marcarlos. Las licencias perpetuas, al no tener caducidad, no están sujetas a la comprobación en absoluto. No es a prueba de balas —nada del lado del cliente lo es—, pero convierte “simplemente cambia la fecha” de una evasión trivial en algo que rompe la licencia de forma visible.

Ventanas de gracia en configuraciones desconectadas

La gracia suele discutirse para clientes intermitentemente conectados —almacena en caché un lease, sobrevive a un corte breve— y cubrí ese patrón en el artículo de validación sin conexión. En un despliegue totalmente aislado el concepto cambia: no hay lease que refrescar, así que la “gracia” pasa a ser cómo gestionas la transición en torno a la caducidad.

Dos prácticas humanas importan aquí. Primera, avisa pronto: como no hay servidor que envíe un recordatorio de renovación por correo, el propio cliente debería mostrar “tu licencia caduca en 14 días” con bastante antelación, ya que reemitir una licencia aislada es un proceso físico de varios días, no una renovación de un solo clic. Segunda, considera un periodo de gracia corto, de solo lectura o de función reducida, tras la caducidad en lugar de una parada dura instantánea, para que una licencia vencida en una instalación segura no detenga trabajo crítico mientras el papeleo de un nuevo archivo firmado avanza. Ambas tratan de respetar que, en estos entornos, la renovación tiene una latencia real.

Revocación sin red

Lo único que la modalidad sin conexión genuinamente no puede hacer al instante es revocar. Un blob firmado el año pasado no sabe nada de un reembolso o una filtración de la semana pasada; su carga útil es fija en el momento de emisión. La respuesta sin conexión es una lista de revocación firmada: una lista de ids de licencia revocados, ella misma firmada por tu clave privada para que el cliente confíe en ella, distribuida con una actualización de software o como un archivo fuera de banda que la instalación importa. El cliente comprueba las licencias entrantes contra la lista y descarta las revocadas.

Se mueve a la velocidad de tu distribución —días o semanas, no segundos— pero significa que una instalación aislada no está indefensa ante una clave que se sabe mala. Para la mayoría de clientes aislados, cuya cadencia de actualización es deliberada de todos modos, es un compromiso aceptable.

Siendo honestos sobre los límites

La validación sin conexión prueba la autenticidad, la integridad, la vinculación y la caducidad de maravilla, y es la herramienta adecuada para despliegues aislados y empresariales, pero no es magia. La comprobación se ejecuta en la máquina del cliente, así que un atacante decidido con un decompilador puede eliminarla con un parche, y la revocación sin conexión nunca es instantánea. Eso no es una razón para evitar el licenciamiento sin conexión; es una razón para ser preciso sobre su función y para combinar la comprobación del cliente con ofuscación de modo que parchear cueste esfuerzo real (consulta proteger tus comprobaciones de licenciamiento). Y recuerda la distinción de licenciamiento autoalojado frente a en la nube: servir a clientes aislados solo necesita archivos offline firmados de tu servicio de emisión; autoalojas el servicio solo cuando el propio servicio de emisión debe ejecutarse desconectado.

Haciendo esto con Keyright

Keyright es offline-first por diseño, así que los despliegues aislados son una ruta soportada, no una ocurrencia tardía. Emite archivos de licencia offline firmados que se verifican localmente contra una clave pública que embebes en el momento de compilar —sin llamada de red, así que funcionan en máquinas totalmente desconectadas—, los bloquea por equipo con tolerancia, se defiende de la manipulación del reloj y envía listas de revocación firmadas que distribuyes fuera de banda. Cada tenant obtiene su propia clave de firma aislada cuya mitad privada nunca sale del servidor, y los SDK para .NET, Node, Python y Java fallan hacia el estado bloqueado en todo momento. Cuando el propio servicio de emisión debe vivir dentro de una red aislada, Keyright se autoaloja: la compilación idéntica, totalmente aislada, en tu propia base de datos.

Empieza en el plan gestionado gratuito para cablear la validación sin conexión antes de pagar un céntimo —consulta los planes— o, si tu despliegue es totalmente aislado de principio a fin, lee cómo funciona el autoalojamiento y habla con nosotros sobre una instancia on-premise.

Prueba Nebula.NET

Endurece tu código .NET en minutos — empieza con la edición gratuita.