Protéger votre endpoint d'activation Keyright contre les abus et le partage de clés

Voici un fait sur votre serveur de licences qui semble alarmant jusqu’à ce qu’on le comprenne : l’endpoint le plus sollicité et le plus important qu’il expose — celui que le logiciel de vos clients appelle pour transformer une clé en licence active — n’a aucune authentification. /v1/activate et /v1/validate acceptent une requête portant une clé de licence et rien d’autre. Pas de jeton d’administration, pas de secret d’API, pas d’en-tête porteur. Ce n’est pas un oubli. C’est le seul schéma qui puisse fonctionner, et cet article explique comment défendre un endpoint que vous avez délibérément laissé ouvert au public.

À retenir : le chemin critique d’exécution de Keyright (/v1/activate, /v1/validate) n’est pas authentifié par conception — c’est le chemin que les applications de vos clients appellent avec une clé de licence, et ils n’ont aucun jeton d’administration à présenter. Vous ne le protégez donc pas par authentification. Vous le protégez en couches : les plafonds de postes et le verrouillage machine limitent le nombre de machines qu’une clé peut allumer, la détection des activations en double met au jour les clés partagées et les VM clonées, la révocation tue une clé fuitée, une limite de débit ou un WAF sur votre propre proxy inverse absorbe l’abus devant /v1/*, et des journaux structurés (clé masquée) vous laissent tout voir.

Pourquoi le chemin critique n’a pas d’authentification — et pourquoi c’est correct

Pensez à qui appelle /v1/activate. C’est une copie de votre logiciel, installée sur la machine d’un client, à qui un utilisateur vient de remettre une clé de licence en la saisissant dans une boîte de dialogue. Cette application installée n’a pas de compte chez vous, pas d’identifiant d’administration, pas d’autre secret que la clé elle-même. La clé de licence est l’identifiant. Le serveur la prend, vérifie sa signature contre la clé de signature du locataire, retrouve l’enregistrement d’activation, vérifie le nombre de postes et, soit lie un poste et renvoie un bail signé, soit refuse. Exiger un second identifiant par-dessus la clé reviendrait à embarquer un secret partagé dans chaque copie de votre application — ce qui n’est plus un secret du tout, et une exposition bien pire que l’endpoint ouvert.

La surface d’administration en est l’image inversée. /admin/* — émettre des licences, révoquer des clés, lire la liste des activations — exige bel et bien le jeton d’administration, parce que vous seul l’appelez, depuis vos propres systèmes. La discipline qui garde tout cela sûr est simple et absolue : n’exposez publiquement que /v1/*, et gardez /admin/* joignable uniquement depuis l’intérieur de votre réseau. Vos clients n’ont jamais besoin d’un autre chemin que /v1/*. Réussissez cette séparation et l’« endpoint non authentifié » n’est que le chemin d’activation faisant son travail ; ratez-la et vous avez publié votre plan de contrôle.

Le modèle de menace de /v1/* n’est donc pas « quelqu’un sans identifiants l’appelle » — tout le monde l’appelle sans identifiants, c’est tout le propos. Les menaces sont l’abus du chemin ouvert : une clé collée sur cent machines, une armée de VM clonées, une clé fuitée sur un forum, ou un déluge grossier de requêtes. Chacune a sa propre couche.

Couche 1 — plafonds de postes et verrouillage machine : le régulateur de licence

Le premier et plus important régulateur n’est pas du tout un contrôle réseau ; c’est la logique de licence elle-même. Une clé verrouillée sur machine se lie à l’empreinte d’une machine, et le serveur impose un nombre de postes : activez plus de machines que la licence ne le permet et le serveur enregistre que le plafond est atteint et refuse la suivante, en renvoyant un résultat de limite de postes et aucun bail. Il n’y a pas de compteur côté client à corriger — le comptage vit sur le serveur.

Cela compte énormément pour l’endpoint ouvert, car cela signifie que le dégât qu’une clé peut causer est borné par la licence, quelle que soit la façon dont l’endpoint est martelé. Une clé vendue pour trois postes peut activer trois machines et pas plus, qu’on l’appelle dix fois ou dix mille. Le verrouillage machine et les plafonds de postes transforment « n’importe qui peut appeler /v1/activate » en « n’importe qui peut l’appeler, et cela n’allumera toujours que les postes que la clé a payés ». La mécanique complète — tolérance au changement d’empreinte, réactivation idempotente, libération de poste en libre-service — est dans verrouillage machine et gestion des postes, et le panorama anti-partage plus large est dans comment arrêter le partage de clés de licence.

Couche 2 — détecter les clés partagées et les VM clonées

Les plafonds de postes bornent le rayon de l’explosion ; ils ne vous disent pas qu’une clé est abusée. Pour cela, vous surveillez le motif. Comme les clients revalident en ligne périodiquement — en rafraîchissant un bail signé de courte durée — une clé partagée devient visible : une clé mono-poste qui bat soudain depuis une douzaine de machines dans trois pays n’a rien d’ambigu. Les VM clonées sont plus subtiles, car un clone copie l’empreinte machine à l’identique, donc le verrouillage machine seul ne peut distinguer deux copies. Keyright les sépare avec un identifiant d’instance d’exécution par démarrage que le clone ne peut pas copier de manière significative : deux copies d’une activation qui battent en même temps se révèlent concurrentes, ce qu’une empreinte ne pourrait jamais faire. Le mécanisme complet est dans détecter les VM clonées et les activations en double.

Quand vous le voyez, vous disposez de réponses graduées plutôt que d’une gâchette sensible. Désactivez l’activation fautive pour libérer le poste au profit d’une machine légitime ; pour un clone confirmé, laissez le serveur choisir un gagnant (newest-wins expulse la copie la plus ancienne à son prochain battement) ou marquez-et-retenez pour qu’il remonte sur votre tableau de bord. Pour une clé véritablement compromise, vous passez à la couche suivante.

Couche 3 — révocation d’une clé fuitée

Quand une clé fuite pour de bon — publiée sur un forum, remboursée, contestée par rejet de débit — vous tuez cette clé précise. La révocation est une déclaration négative signée : marquez la clé comme révoquée côté administration (POST /admin/licenses/{id}/revoke, ou un clic dans le tableau de bord) et le client retombe à l’état sans licence à sa prochaine revalidation. Comme les baux sont de courte durée, la « prochaine revalidation » arrive d’elle-même, donc la clé publiée sur le forum cesse de fonctionner partout où elle s’est propagée sans que vous leviez le petit doigt après le clic. Pour les installations hors ligne, une liste de révocation signée distribuée avec une mise à jour atteint même les clients déconnectés. La fenêtre d’exposition et les arbitrages entre en ligne et hors ligne sont exposés dans stratégies de révocation de licence — en bref, la révocation transforme une clé fuitée d’une perte permanente en une perte bornée et récupérable.

Couche 4 — la protection en périphérie que vous ajoutez devant /v1/*

Tout ce qui précède est de la logique de licence. La dernière couche est de l’hygiène réseau, et c’est à vous de l’ajouter — Keyright n’a pas de limiteur de débit intégré, et il n’en a pas besoin, parce que l’application est sans état derrière un répartiteur de charge. La régulation a sa place en périphérie, là où vous opérez déjà : le proxy inverse, le répartiteur de charge ou le CDN où vous terminez le TLS. C’est là que vous placez une limite de débit, un plafond de connexions ou un WAF complet devant /v1/*.

Quelques lignes de nginx plafonnent les requêtes par IP cliente et absorbent les rafales :

# Régule le chemin critique d'activation sur votre propre proxy inverse.
# L'application est sans état derrière, donc la limite de débit vit ici.
limit_req_zone  $binary_remote_addr  zone=kr_activate:10m  rate=10r/s;
limit_conn_zone $binary_remote_addr  zone=kr_conn:10m;

server {
    listen 443 ssl;
    server_name licensing.example.com;

    location /v1/ {
        limit_req  zone=kr_activate burst=20 nodelay;  # absorbe les courtes rafales
        limit_conn kr_conn 20;                          # plafonne les connexions par IP

        proxy_pass         http://keyright_upstream;
        proxy_set_header   X-Forwarded-For   $remote_addr;   # IP réelle du client
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    # La surface d'administration n'est jamais publique. Restreignez-la à votre réseau.
    location /admin/ {
        allow 10.0.0.0/8;
        deny  all;
        proxy_pass http://keyright_upstream;
    }
}

Un WAF cloud géré ou une passerelle d’API font le même travail avec des règles plus riches — réputation d’IP, scoring de bots, contrôles géographiques, atténuation automatique des DDoS — mais le principe est identique : la limite vit devant l’application, clée sur l’IP cliente, cantonnée à /v1/*. Gardez une faible latence en dimensionnant la limite à partir de la charge de travail réelle. L’activation et la validation ne sont pas des appels à chaque lancement ; un client s’active une fois, met en cache un bail signé et valide hors ligne jusqu’à ce que le bail approche de l’expiration. Une machine donnée touche donc /v1/* une poignée de fois par jour. Une limite par IP de dizaines de requêtes par seconde avec une marge de rafale est invisible pour ce trafic et ne rogne que l’IP qui martèle l’endpoint avec une clé partagée ou scriptée. Le chemin critique lui-même est une vérification de signature plus un comptage de postes, donc la surcharge que vous ajoutez est de quelques millisecondes de travail de proxy, pas un goulet d’étranglement.

Un détail à bien régler : assurez-vous que l’IP réelle du client atteigne votre limiteur de débit. Si un autre proxy se trouve devant, transmettez l’adresse cliente authentique (ici via X-Forwarded-For) pour que la limite par IP soit clée sur l’abuseur, et non sur votre propre nœud de périphérie — sinon chaque requête semble venir d’une seule adresse et la limite soit ne se déclenche jamais, soit les rogne toutes.

Couche 5 — des journaux structurés qui masquent la clé

Vous ne pouvez pas réguler ce que vous ne voyez pas, alors journalisez les événements de licence de façon structurée — et ne journalisez jamais la clé. Une clé de licence est un identifiant porteur ; l’écrire dans un journal qui sera expédié vers un agrégateur ou collé dans un ticket de support est la même classe d’erreur que journaliser un mot de passe. Émettez un événement structuré par activation et par validation — statut, titulaire, une courte empreinte de la clé, compteurs de postes et d’activations — pour qu’un tableau de bord puisse grapher « empreintes distinctes vues cette semaine » ou alerter sur une seule clé s’activant depuis des dizaines d’IP, le tout sans que la clé brute ne quitte jamais le processus. Le motif complet — un événement généré à la compilation par lequel la clé est littéralement impassable, mappé sur des niveaux de journal que votre alerting comprend déjà — est dans journalisation structurée des événements de licence. Ces journaux sont ce qui transforme les quatre autres couches, de l’espoir en preuve : c’est ainsi que vous remarquez la clé partagée, confirmez le clone et décidez de révoquer.

Où Keyright s’inscrit

Ce qu’il faut intérioriser, c’est qu’un endpoint d’activation non authentifié n’est pas une faiblesse dont s’excuser — c’est la forme correcte pour un chemin que le logiciel de vos clients doit appeler avec rien d’autre qu’une clé. Keyright vous donne les couches de licence d’emblée : des postes verrouillés sur machine imposés côté serveur, la détection des activations en double et des clones, la révocation en un clic qui atteint les clients en ligne et hors ligne, et des événements de licence structurés que vous pouvez journaliser en toute sûreté. La couche de périphérie — la limite de débit, le WAF, le verrouillage de /admin/* — est à vous de l’exploiter devant, exactement comme vous exploitez déjà un proxy devant n’importe quel service sans état. Keyright auto-hébergé est facturé par déploiement entre Standard, Pro et Enterprise ; consultez les tarifs pour les paliers actuels. Défendez le chemin ouvert comme il est censé l’être — avec de la logique de licence et des contrôles en périphérie, pas avec un identifiant que vous auriez dû faire fuiter pour pouvoir livrer.