Bloqueo por equipo y gestión de puestos para licencias de software

El bloqueo por equipo vincula una licencia a un equipo concreto para que una sola clave no se pueda copiar por todas partes, y la gestión de puestos te permite decir “esta clave se ejecuta en N máquinas a la vez” y hacerlo cumplir de verdad — pero lo segundo solo funciona con un servidor de activación en línea, porque una máquina por sí sola no puede contar cuántas otras comparten su clave. Este artículo recorre ambas mecánicas con honestidad: cómo una huella de equipo con tolerancia a cambios evita que los usuarios honestos queden bloqueados, cómo un servidor impone un tope de puestos, cómo los clientes mueven sus propios puestos y por qué la activación en línea es la pieza que convierte “3 puestos” de una promesa en una regla.

Qué es realmente el bloqueo por equipo

Un bloqueo por equipo ata una licencia a una huella de equipo — un valor que el SDK deriva de atributos estables de hardware y del sistema operativo del dispositivo. Cuando activas una clave, esa huella se registra contra la licencia. Cada validación posterior vuelve a calcular la huella localmente y comprueba que coincide. Copia la misma clave a un segundo equipo y la huella no coincidirá, así que la licencia simplemente no se aplica allí.

Esa es toda la idea, y es genuinamente útil: significa que una clave entregada a un cliente no desbloquea mil instalaciones. Pero la versión ingenua tiene un modo de fallo bien conocido, y superarlo es la diferencia entre un bloqueo que los clientes toleran y un bloqueo que llena tu cola de soporte.

El problema de la tolerancia a cambios

Si tu huella usa el hash de demasiados atributos de hardware, el bloqueo es frágil. Un cliente cambia una tarjeta de red, actualiza un SSD o actualiza un controlador, la huella se altera, y un usuario que paga queda de repente bloqueado fuera del software que posee — seguido de inmediato por un ticket enfadado. Usa el hash de demasiado pocos atributos y el bloqueo es trivial de falsear.

La solución es la tolerancia: permitir una pequeña deriva antes de considerar que el equipo es otro distinto. El SDK de .NET de Keyright deriva una huella estable y aplica una NodeLockTolerance configurable (por defecto 1), de modo que un cambio corriente de un solo componente — una NIC nueva, un disco sustituido — no dispara el bloqueo, mientras que los cambios masivos siguen leyéndose como un equipo distinto. Para entornos poco habituales como VM, contenedores o ejecutores de CI, puedes controlar exactamente qué componentes identifican a una máquina implementando IMachineComponents y estableciendo MachineComponents en las opciones del SDK. Consulta la guía de integración del SDK de .NET para la superficie exacta.

Puestos: N máquinas, una clave

Un número de puestos es una promesa — “esta licencia se ejecuta en hasta 3 máquinas” — y en el momento en que la haces, has entrado en un territorio que una comprobación del lado del cliente no puede manejar. Una sola máquina que valida una licencia sin conexión no tiene ni idea de cuántas otras máquinas están ejecutando la misma clave en este momento. Contar puestos es una decisión compartida y con estado, y el estado compartido vive en un servidor.

Este es el flujo cuando se hace correctamente:

• La activación registra un puesto. Cuando una máquina activa una clave, el servidor registra la activación (la huella y los metadatos de la máquina) contra la licencia y devuelve un lease firmado de corta duración vinculado a esa máquina.
• El tope se impone en el servidor. Activa más máquinas de las que permite la licencia y el servidor lo rechaza — devuelve un resultado de límite de puestos y ningún lease, así que la máquina extra permanece en el estado gratuito/sin licencia. No hay ningún contador del lado del cliente que parchear.
• La reactivación es idempotente. Una máquina que ya está vinculada puede reactivarse sin consumir un segundo puesto. Reiniciar la aplicación o refrescar el lease no va mermando poco a poco tu asignación de puestos.

En Keyright, la activación es un POST al endpoint /v1/activate del runtime que lleva la clave y el id de la máquina; el servidor consume un puesto y devuelve el lease. Desde el cliente nunca tocas ese endpoint directamente — llamas a ActivateAsync(key) e inspeccionas el LicenseInfo devuelto. Si los puestos están agotados, vuelve en estado fail-closed con un mensaje como “All seats for this license are in use,” no con una excepción.

Dejar que los clientes muevan un puesto por sí mismos

Los puestos crean un problema de soporte al día siguiente de lanzarlos: un cliente jubila un portátil, compra uno nuevo y no puede activar porque todos sus puestos están ocupados por máquinas que ya no usa. Si mover un puesto implica escribirte, cada renovación de hardware es un ticket.

La respuesta es la desactivación de autoservicio — dejar que el cliente libere un puesto sin involucrarte:

• Tu aplicación puede liberar el puesto que ocupa la máquina actual llamando al endpoint /v1/free-seat del runtime, de modo que un botón “desactivar este dispositivo” en tu propia interfaz simplemente funciona.
• El portal de cliente alojado de Keyright permite a un licenciatario ver sus activaciones y liberar un puesto en un dispositivo que ya no usa, y luego activar el nuevo — sin ningún ticket para ti.
• Por tu parte, un administrador puede desactivar una máquina concreta desde la vista de activaciones por licencia del panel, que también muestra los metadatos del dispositivo para que puedas ver dónde se están usando realmente los puestos.

Revocación: la otra cosa que solo un servidor puede hacer

Los puestos no son la única imposición que necesita un servidor. Una clave reembolsada, con contracargo o filtrada tiene que morir, y un archivo de licencia firmado emitido el año pasado no sabe nada de un reembolso de la semana pasada — su carga útil queda fijada en el momento de la emisión. La activación en línea cierra esa brecha: revoca una clave (POST /admin/licenses/{id}/revoke, o un clic en el panel) y el cliente baja a la edición gratuita en su próximo refresco de lease. Como el lease es de corta duración, el “próximo refresco” llega por sí solo.

Para instalaciones puramente sin conexión, Keyright también puede generar y distribuir una lista de revocación firmada que tu aplicación respeta sin una llamada de red — más lenta, moviéndose al ritmo de tus versiones, pero significa que incluso un cliente desconectado no está indefenso frente a una clave que se sabe comprometida.

Primero sin conexión, en línea donde importa

Nada de esto significa abandonar la validación sin conexión — significa combinar las dos. Keyright es de tipo “primero sin conexión”: tu aplicación verifica una licencia firmada o un lease en caché localmente, contra una clave pública embebida, con cero red. La activación ocurre una vez; después, el lease en caché mantiene la aplicación funcionando sin conexión durante toda la vida del lease, y solo cerca de la caducidad vuelve a contactar con el servidor para reconciliar puestos y revocaciones. Si el servidor está brevemente inaccesible, un lease en caché todavía válido cubre el hueco — una ventana de gracia — para que una caída no deje fuera a un usuario que paga.

Sé honesto con el límite, eso sí. El bloqueo por equipo y las comprobaciones sin conexión se ejecutan en la máquina del usuario, así que un atacante decidido con un decompilador puede parchearlos y eliminarlos — la misma verdad que se aplica a cualquier protección del lado del cliente. Por eso la imposición que importa — los topes de puestos y la revocación — vive en un servidor que el atacante no controla, y por eso combinas la comprobación del cliente con ofuscación para encarecer el parcheo. La comprobación del cliente es una puerta rápida y honesta; el servidor es donde las reglas son reales.

Conectándolo con Keyright

Keyright te da bloqueo por equipo con tolerancia a cambios, puestos impuestos en el servidor, desactivación de autoservicio y revocación instantánea como un solo sistema, con un SDK de .NET (más Node, Python y Java) que falla de forma cerrada por diseño. La mitad del cliente son unas pocas líneas — inicializa una vez, llama a ActivateAsync cuando un cliente introduce una clave, y lee el resultado. Consulta la guía de integración del SDK de .NET para el código exacto, o la página del producto Keyright para el panorama completo. El plan gratuito es suficiente para conectar una imposición de puestos real de principio a fin antes de pagar nada.