Ihren Keyright-Aktivierungs-Endpunkt vor Missbrauch und Schlüsselteilung schützen

Hier ist eine Tatsache über Ihren Lizenzserver, die alarmierend klingt, bis man sie versteht: Der am stärksten frequentierte und wichtigste Endpunkt, den er bereitstellt — jener, den die Software Ihrer Kunden aufruft, um einen Schlüssel in eine laufende Lizenz zu verwandeln — hat überhaupt keine Authentifizierung. /v1/activate und /v1/validate nehmen eine Anfrage an, die einen Lizenzschlüssel trägt und sonst nichts. Kein Admin-Token, kein API-Geheimnis, kein Bearer-Header. Das ist kein Versäumnis. Es ist der einzige Entwurf, der funktionieren kann, und dieser Beitrag handelt davon, wie man einen Endpunkt verteidigt, den man bewusst offen für die Öffentlichkeit gelassen hat.

Kernaussage: Der Laufzeit-Hotpath von Keyright (/v1/activate, /v1/validate) ist per Entwurf nicht authentifiziert — es ist der Pfad, den die Apps Ihrer Kunden mit einem Lizenzschlüssel aufrufen, und sie haben kein Admin-Token vorzuweisen. Sie schützen ihn also nicht mit Authentifizierung. Sie schützen ihn in Schichten: Platzlimits und Node-Locking begrenzen, wie viele Maschinen ein Schlüssel je erleuchten kann, die Erkennung doppelter Aktivierungen bringt geteilte Schlüssel und geklonte VMs ans Licht, der Widerruf tötet einen geleakten Schlüssel, ein Rate-Limit oder eine WAF auf Ihrem eigenen Reverse-Proxy fängt Missbrauch vor /v1/* ab, und strukturierte Protokolle (mit geschwärztem Schlüssel) lassen Sie alles sehen.

Warum der Hotpath keine Authentifizierung hat — und warum das richtig ist

Denken Sie daran, wer /v1/activate aufruft. Es ist eine Kopie Ihrer Software, installiert auf der Maschine eines Kunden, der soeben ein Lizenzschlüssel überreicht wurde, indem ein Benutzer ihn in einen Dialog getippt hat. Diese installierte App hat kein Konto bei Ihnen, keine Admin-Anmeldeinformation, kein Geheimnis außer dem Schlüssel selbst. Der Lizenzschlüssel ist die Anmeldeinformation. Der Server nimmt ihn, verifiziert seine Signatur gegen den Signierschlüssel des Mandanten, schlägt den Aktivierungsdatensatz nach, prüft die Platzzahl und bindet entweder einen Platz und gibt ein signiertes Lease zurück oder lehnt ab. Eine zweite Anmeldeinformation zusätzlich zum Schlüssel zu verlangen hieße, ein gemeinsames Geheimnis in jede Kopie Ihrer App einzubetten — was gar kein Geheimnis mehr ist und eine weit schlimmere Exposition als der offene Endpunkt.

Die Admin-Oberfläche ist das Spiegelbild. /admin/* — Lizenzen ausstellen, Schlüssel widerrufen, die Aktivierungsliste lesen — verlangt sehr wohl das Admin-Token, denn nur Sie rufen es auf, von Ihren eigenen Systemen aus. Die Disziplin, die dies sicher hält, ist einfach und absolut: Exponieren Sie öffentlich nur /v1/*, und halten Sie /admin/* nur aus dem Inneren Ihres Netzes erreichbar. Ihre Kunden brauchen nie einen anderen Pfad als /v1/*. Gelingt Ihnen diese Trennung, ist der „nicht authentifizierte Endpunkt” nur der Aktivierungspfad bei der Arbeit; misslingt sie, haben Sie Ihre Steuerungsebene veröffentlicht.

Das Bedrohungsmodell für /v1/* ist also nicht „jemand ohne Anmeldeinformationen ruft ihn auf” — jeder ruft ihn ohne Anmeldeinformationen auf, das ist der ganze Sinn. Die Bedrohungen sind der Missbrauch des offenen Pfads: ein Schlüssel, über hundert Maschinen geklebt, eine Armee geklonter VMs, ein geleakter Schlüssel in einem Forum oder eine grobe Flut von Anfragen. Jede hat ihre eigene Schicht.

Schicht 1 — Platzlimits und Node-Locking: die Lizenz-Drossel

Die erste und wichtigste Drossel ist gar keine Netzwerkkontrolle; es ist die Lizenzlogik selbst. Ein node-gelockter Schlüssel bindet sich an einen Maschinen-Fingerabdruck, und der Server erzwingt eine Platzzahl: Aktivieren Sie mehr Maschinen, als die Lizenz zulässt, vermerkt der Server, dass die Obergrenze erreicht ist, und lehnt die nächste ab, mit einem Platzlimit-Ergebnis und ohne Lease. Es gibt keinen clientseitigen Zähler zum Patchen — die Zählung lebt auf dem Server.

Das zählt für den offenen Endpunkt enorm, denn es bedeutet, dass der Schaden, den ein Schlüssel anrichten kann, durch die Lizenz begrenzt ist, egal wie der Endpunkt bombardiert wird. Ein als drei Plätze verkaufter Schlüssel kann drei Maschinen aktivieren und nicht mehr, ob er zehnmal oder zehntausendmal aufgerufen wird. Node-Locking und Platzobergrenzen verwandeln „jeder kann /v1/activate aufrufen” in „jeder kann ihn aufrufen, und er erleuchtet dennoch immer nur die Plätze, die der Schlüssel bezahlt hat”. Die vollständige Mechanik — Fingerabdruck-Wechseltoleranz, idempotente Reaktivierung, Platzfreigabe im Selbstbedienungsmodus — steht in Node-Locking und Platzverwaltung, und das weitere Anti-Teilungs-Bild in wie man das Teilen von Lizenzschlüsseln stoppt.

Schicht 2 — geteilte Schlüssel und geklonte VMs erkennen

Platzlimits begrenzen den Explosionsradius; sie sagen Ihnen nicht, dass ein Schlüssel missbraucht wird. Dafür beobachten Sie das Muster. Weil Clients periodisch online revalidieren — indem sie ein kurzlebiges signiertes Lease auffrischen — wird ein geteilter Schlüssel sichtbar: Ein Einzelplatz-Schlüssel, der plötzlich von einem Dutzend Maschinen in drei Ländern pulst, ist nicht mehrdeutig. Geklonte VMs sind subtiler, denn ein Klon kopiert den Maschinen-Fingerabdruck wortwörtlich, sodass Node-Locking allein zwei Kopien nicht auseinanderhalten kann. Keyright trennt sie mit einer Laufzeit-Instanz-ID pro Start, die der Klon nicht sinnvoll kopieren kann: Zwei Kopien einer Aktivierung, die zur selben Zeit pulsen, offenbaren sich als nebenläufig, was ein Fingerabdruck nie könnte. Der vollständige Mechanismus steht in geklonte VMs und doppelte Aktivierungen erkennen.

Wenn Sie es sehen, haben Sie abgestufte Reaktionen statt eines empfindlichen Abzugs. Deaktivieren Sie die verursachende Aktivierung, um den Platz für eine legitime Maschine freizugeben; für einen bestätigten Klon lassen Sie den Server einen Gewinner wählen (newest-wins verdrängt die ältere Kopie bei ihrem nächsten Herzschlag) oder markieren-und-halten, damit er auf Ihrem Dashboard auftaucht. Bei einem wirklich kompromittierten Schlüssel eskalieren Sie zur nächsten Schicht.

Schicht 3 — Widerruf eines geleakten Schlüssels

Wenn ein Schlüssel rundweg leakt — in einem Forum veröffentlicht, erstattet, per Rückbuchung zurückgeholt — töten Sie diesen einen Schlüssel. Widerruf ist eine signierte negative Aussage: Markieren Sie den Schlüssel auf der Admin-Seite als widerrufen (POST /admin/licenses/{id}/revoke, oder ein Klick im Dashboard), und der Client fällt bei seiner nächsten Revalidierung in den unlizenzierten Zustand. Da Leases kurzlebig sind, kommt die „nächste Revalidierung” von selbst, sodass der im Forum veröffentlichte Schlüssel überall, wohin er sich verbreitet hat, aufhört zu funktionieren, ohne dass Sie nach dem Klick einen Finger rühren. Für Offline-Installationen erreicht eine mit einem Update ausgelieferte signierte Widerrufsliste selbst getrennte Clients. Das Expositionsfenster und die Abwägungen zwischen online und offline sind in Strategien zum Lizenzwiderruf dargelegt — kurz gesagt verwandelt der Widerruf einen geleakten Schlüssel von einem dauerhaften Verlust in einen begrenzten, erholbaren.

Schicht 4 — der Edge-Schutz, den Sie vor /v1/* hinzufügen

Alles Obige ist Lizenzlogik. Die letzte Schicht ist Netzwerkhygiene, und sie liegt an Ihnen — Keyright hat keinen eingebauten Rate-Limiter und braucht keinen, weil die App zustandslos hinter einem Load Balancer ist. Die Drosselung gehört an die Edge, die Sie ohnehin betreiben: den Reverse-Proxy, Load Balancer oder das CDN, wo Sie TLS terminieren. Dort setzen Sie ein Rate-Limit, eine Verbindungsobergrenze oder eine vollwertige WAF vor /v1/*.

Ein paar Zeilen nginx begrenzen die Anfragen pro Client-IP und fangen Spitzen ab:

# Drossle den Aktivierungs-Hotpath auf deinem eigenen Reverse-Proxy.
# Die App ist zustandslos dahinter, also lebt das Rate-Limit hier.
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;  # kurze Spitzen abfangen
        limit_conn kr_conn 20;                          # Verbindungen pro IP begrenzen

        proxy_pass         http://keyright_upstream;
        proxy_set_header   X-Forwarded-For   $remote_addr;   # echte Client-IP
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    # Die Admin-Oberfläche ist nie öffentlich. Auf dein Netz beschränken.
    location /admin/ {
        allow 10.0.0.0/8;
        deny  all;
        proxy_pass http://keyright_upstream;
    }
}

Eine verwaltete Cloud-WAF oder ein API-Gateway erledigen dieselbe Aufgabe mit reicheren Regeln — IP-Reputation, Bot-Scoring, Geo-Kontrollen, automatische DDoS-Abwehr — aber das Prinzip ist identisch: Das Limit lebt vor der App, geschlüsselt auf die Client-IP, begrenzt auf /v1/*. Halten Sie die Latenz niedrig, indem Sie das Limit an der echten Arbeitslast bemessen. Aktivierung und Validierung sind keine Aufrufe bei jedem Start; ein Client aktiviert einmal, legt ein signiertes Lease im Cache ab und validiert offline, bis das Lease der Ablaufzeit nahekommt. Eine gegebene Maschine berührt /v1/* daher eine Handvoll Mal pro Tag. Ein Limit pro IP von Dutzenden Anfragen pro Sekunde mit Burst-Spielraum ist für diesen Verkehr unsichtbar und beschneidet nur die IP, die den Endpunkt mit einem geteilten oder geskripteten Schlüssel bombardiert. Der Hotpath selbst ist eine Signaturprüfung plus eine Platzzählung, also ist der Overhead, den Sie hinzufügen, ein paar Millisekunden Proxy-Arbeit, kein Engpass.

Ein Detail, das man richtig machen sollte: Stellen Sie sicher, dass die echte Client-IP Ihren Rate-Limiter erreicht. Sitzt ein weiterer Proxy davor, leiten Sie die echte Client-Adresse weiter (hier via X-Forwarded-For), damit das Limit pro IP auf den Missbraucher geschlüsselt ist, nicht auf Ihren eigenen Edge-Knoten — sonst sieht jede Anfrage so aus, als käme sie von einer einzigen Adresse, und das Limit greift entweder nie oder beschneidet alle.

Schicht 5 — strukturierte Protokolle, die den Schlüssel schwärzen

Sie können nicht drosseln, was Sie nicht sehen, also protokollieren Sie Lizenzereignisse strukturiert — und protokollieren Sie nie den Schlüssel. Ein Lizenzschlüssel ist eine Inhaber-Anmeldeinformation; ihn in ein Protokoll zu schreiben, das zu einem Aggregator verschickt oder in ein Support-Ticket geklebt wird, ist derselbe Fehlerklasse wie das Protokollieren eines Passworts. Geben Sie ein strukturiertes Ereignis pro Aktivierung und Validierung aus — Status, Lizenznehmer, einen kurzen Fingerabdruck des Schlüssels, Platz- und Aktivierungszähler — damit ein Dashboard „diese Woche gesehene unterschiedliche Fingerabdrücke” grafisch darstellen oder bei einem einzelnen Schlüssel alarmieren kann, der sich von Dutzenden IPs aktiviert, alles ohne dass der rohe Schlüssel je den Prozess verlässt. Das vollständige Muster — ein quellgeneriertes Ereignis, durch das der Schlüssel buchstäblich nicht übergebbar ist, abgebildet auf Protokoll-Level, die Ihr Alerting bereits versteht — steht in strukturiertes Protokollieren von Lizenzereignissen. Diese Protokolle sind es, die die anderen vier Schichten von Hoffnung in Beweis verwandeln: So bemerken Sie den geteilten Schlüssel, bestätigen den Klon und entscheiden sich zu widerrufen.

Wo Keyright hineinpasst

Was man verinnerlichen sollte, ist, dass ein nicht authentifizierter Aktivierungs-Endpunkt keine Schwäche ist, für die man sich entschuldigen müsste — er ist die richtige Form für einen Pfad, den die Software Ihrer Kunden mit nichts als einem Schlüssel aufrufen muss. Keyright gibt Ihnen die Lizenzschichten von Haus aus: node-gelockte, serverseitig erzwungene Plätze, Erkennung doppelter Aktivierungen und von Klonen, Ein-Klick-Widerruf, der Online- und Offline-Clients erreicht, und strukturierte Lizenzereignisse, die Sie sicher protokollieren können. Die Edge-Schicht — das Rate-Limit, die WAF, die Abriegelung von /admin/* — liegt an Ihnen, davor zu betreiben, genau so, wie Sie bereits einen Proxy vor jedem zustandslosen Dienst betreiben. Self-hosted Keyright wird pro Deployment über Standard, Pro und Enterprise abgerechnet; sehen Sie die Preise für die aktuellen Stufen. Verteidigen Sie den offenen Pfad so, wie er verteidigt werden soll — mit Lizenzlogik und Edge-Kontrollen, nicht mit einer Anmeldeinformation, die Sie hätten leaken müssen, um ausliefern zu können.