Selbstgehostetes Keyright vollständig air-gapped betreiben, ohne ausgehendes Internet

Manche Netze berühren das Internet nie, aus Grundsatz und von Entwurf her — eine klassifizierte Enklave, ein isoliertes Steuerungssystem, die abgeschottete Produktionszone einer Bank, eine Hochsicherheitsanlage, in der ein Sicherheitsbeauftragter jedes Byte prüft, das auf einem USB-Stick die Lücke quert. Wer Software in solche Umgebungen lizenziert, für den ist „unsere Lizenzierung ruft nach Hause” von vornherein ein Ausschlusskriterium. Die beruhigende Nachricht: Selbstgehostetes Keyright wurde genau dafür gebaut — nichts auf seinem Laufzeitpfad braucht das Internet. Dieser Beitrag ist die konkrete Anleitung — was air-gapped für jedes bewegliche Teil bedeutet, wie Sie die Selbstlizenz als Datei installieren und erneuern, wie Sie das Einzige stoppen, das nach außen ginge, und wie nutzungsbasierte Lizenzierung über die Lücke funktioniert.

Kernaussage: Selbstgehostetes Keyright braucht zur Laufzeit kein ausgehendes Internet. Es prüft seine eigene Selbstlizenz offline gegen Delta1s eingebetteten öffentlichen Schlüssel (kein Phone-home, fail-closed bei Manipulation), die Apps Ihrer Kunden validieren offline zwischen Aktivierungen, und für nutzungsbasierte Lizenzierung bewegen Sie signierte air-gapped Credit-Blöcke per Datei hinein und hinaus. Der offline Kernbetrieb funktioniert auf Standard und Pro; air-gapped Credit-Blöcke sind eine Enterprise-Funktion.

Was „air-gapped” für die drei Parteien bedeutet

Es gibt drei Teile zu betrachten, und jeder ist unabhängig offline.

Die Keyright-Instanz. Sie ist das Image ghcr.io/delta1-labs/keyright — ein zustandsloser ASP.NET-Core-Dienst auf Port 8080, ohne Datenbank darin. Beim Start und bei jedem Scan prüft sie ihre eigene Lizenz, und diese Prüfung ist reine lokale Kryptografie gegen einen in die Build eingebackenen öffentlichen Schlüssel. Kein Aufruf an einen Delta1-Lizenzserver, kein Aktivierungs-Handshake, keine Telemetrie, die die Laufzeit steuert. Sind Image und Schlüssel einmal in Ihrem Netz, muss die Instanz nie wieder nach außen greifen.

Ihr PostgreSQL. Der gesamte Zustand — Lizenzen, Aktivierungen, Plätze, Guthabenstände und ihr Hauptbuch, das Audit-Log, Ihre im Ruhezustand verschlüsselten Signierschlüssel — liegt in einer Datenbank, die Sie betreiben, angesprochen über die Verbindungszeichenfolge KEYRIGHT_DB. Das ist ein netzinternes Postgres auf Ihrer eigenen Infrastruktur. Kein von uns verwalteter Datenspeicher ist beteiligt; die Daten verlassen Ihren Perimeter nie.

Die Apps Ihrer Kunden. Wie in Offline-Lizenzvalidierung erklärt dargelegt, prüft sich eine signierte Lizenz lokal gegen den öffentlichen Schlüssel, den Sie zur Build-Zeit einbetten, und eine Online-Aktivierung liefert ein kurzlebiges signiertes Lease zurück, das die App zwischenspeichert und offline neu prüft. Ihre Kunden validieren also offline zwischen Aktivierungen — und in einer vollständig getrennten Flotte geben Sie signierte Offline-Dateien aus und überspringen den Aktivierungs-Rundlauf ganz, genau wie in Lizenzierung für air-gapped Umgebungen beschrieben.

Zusammengenommen: Die Instanz lizenziert sich offline selbst, sie spricht nur mit einer Datenbank, die Sie hosten, und die Apps Ihrer Kunden müssen sie nicht erreichen, um weiterzulaufen. Nichts auf diesem Pfad quert die Luftlücke.

Die Instanz lizenziert sich offline selbst und fällt in den gesperrten Zustand

Keyright lizenziert sich mit einer gewöhnlichen Keyright-Offline-Lizenz, und Ihre Instanz prüft sie offline gegen Delta1s eingebetteten öffentlichen Schlüssel — ohne Phone-home. Dieselbe Asymmetrie, die Ihre Kunden schützt, schützt Ihr Deployment: Der öffentliche Schlüssel kann die signierte Selbstlizenz prüfen, aber nie fälschen, die Prüfung ist also lokale Mathematik, und die Manipulation eines beliebigen Felds bricht die Signatur.

Sie ist fail-closed. Ohne Schlüssel, mit einem ungültigen Schlüssel, einer abgelaufenen Testphase oder einer bezahlten Lizenz jenseits ihres Kulanzfensters ist die Instanz gesperrt (gated): Jede Kundenanfrage liefert 402. Eine Handvoll Endpunkte bleibt erreichbar, damit Sie den Stopp stets ohne Internet diagnostizieren können — /health, /health/ready, /admin/self-license, /admin/self-diagnostics, /branding und das Dashboard — aber die Laufzeit ist aus, bis ein gültiger Schlüssel vorliegt. In einem air-gapped Netz heißt das: Das Einzige, was Sie nicht verfehlen dürfen, ist der Schlüssel — behandeln Sie ihn mit derselben Sorgfalt wie die Sicherung und Wiederherstellung Ihrer Datenbank.

Die Selbstlizenz als Datei installieren und erneuern

Hier stolpert, wer einen Web-Upload erwartet: Es gibt keinen „Lizenz hochladen”-Endpunkt. Sie stellen den Schlüssel über die Konfiguration bereit und starten (neu). Das ist in einem air-gapped Netz ein Vorteil — der Schlüssel kommt wie alles andere herein, als Datei auf Ihrem freigegebenen Transferkanal.

Zwei Wege, ihn bereitzustellen:

• Als Datei (die air-gapped Vorgabe): Setzen Sie KEYRIGHT_SELF_LICENSE_FILE auf einen Pfad innerhalb des Containers und mounten Sie dort das Lizenz-JSON. Auf Kubernetes ist das ein Secret via --set-file secrets.selfLicense=license.json.
• Inline: Setzen Sie KEYRIGHT_SELF_LICENSE auf das Lizenz-JSON in einer einzigen Zeile (verdichten Sie es, falls Ihre Kopie Zeilenumbrüche hat) — am einfachsten für einen einzelnen Compose-Host.

Eine Erneuerung oder ein Editionswechsel ist derselbe Handgriff: Datei austauschen und neu starten. Kein Redeploy, keine Migration, kein Endpunkt zum Aufrufen. Bestätigen Sie anschließend die Übernahme:

curl -H "X-Admin-Token: $KEYRIGHT_ADMIN_TOKEN" http://localhost:8080/admin/self-license

/admin/self-license meldet Ihre edition, isTrial, phase (active / expiring / grace / gated), daysUntilExpiry und ob die Laufzeit blockiert ist — und es ist einer der wenigen Endpunkte, die selbst bei gesperrter Instanz antworten. Binden Sie seinen Ablauf-Countdown in Ihre eigene Überwachung ein, denn in einem getrennten Netz findet Sie keine Erneuerungs-E-Mail; die Instanz warnt im Dashboard, aber die Phase sollten Sie selbst im Blick behalten. Der vollständige Lebenszyklus des Schlüsselzustands steht in der Lizenzierungsreferenz.

Deaktivieren Sie den einzigen ausgehenden Aufruf: GeoIP

Das Dashboard hat eine optionale Maschinen-Standortabfrage, die Aktivierungs-IPs einem groben Standort zuordnet. Das ist das Einzige in einer Werkskonfiguration, das eine ausgehende Anfrage versuchen würde. Deaktivieren Sie es für einen air-gapped Betrieb, indem Sie es leer lassen:

KEYRIGHT_GEOIP_URL=

Ist das nicht gesetzt, lässt das Dashboard die Standortspalte einfach weg und versucht nichts nach außen. Alles andere — Aktivierung, Validierung, Plätze, Guthaben, das Portal — war ohnehin lokal.

Das Image in Ihre private Registry holen

Das Image liegt in einer öffentlichen Registry, die Sie von innerhalb der Lücke nicht erreichen — bewegen Sie es also wie jedes Artefakt: auf einem verbundenen Host ziehen, exportieren und auf der anderen Seite laden.

# Auf einem verbundenen Host:
docker save ghcr.io/delta1-labs/keyright:2.2.2 -o keyright-2.2.2.tar
# (speichern Sie auch postgres:16, falls Sie die mitgelieferte DB für eine kleine Installation nutzen)

# Tragen Sie das Tarball über Ihren freigegebenen Kanal hinein, dann innerhalb des Netzes:
docker load -i keyright-2.2.2.tar

Taggen Sie neu und pushen Sie in Ihre eigene netzinterne Registry, falls Sie eine betreiben, und pinnen Sie die Version (image.tag=2.2.2 auf Helm) für reproduzierbare Deployments. Richten Sie KEYRIGHT_DB auf Ihr netzinternes PostgreSQL aus — eine Datenbank auf Ihrer eigenen Infrastruktur, TLS vorausgesetzt — und die Instanz erstellt und migriert ihr Schema beim ersten Start, ohne von Hand auszuführendes SQL. Upgrades sind dasselbe Importieren-und-Neustarten, wobei die Migrationen beim Start automatisch angewandt werden.

Nutzungsbasierte Lizenzierung über die Lücke: air-gapped Credit-Blöcke

Wer nach Guthaben oder Nutzung verkauft, gleicht den Verbrauch üblicherweise über Konnektivität ab — und genau das kann ein air-gapped Netz nicht bieten. Air-gapped Credit-Blöcke lösen das mit derselben Signaturvertrauenslogik wie eine Lizenz. Sie geben einen signierten Block Guthaben für eine getrennte Maschine aus, er wird dort offline eingelöst, und Sie gleichen die Nutzung ab, wenn der Block über die Lücke zurückkommt. Da jeder Block mit dem Schlüssel Ihrer Instanz signiert und lokal geprüft wird, braucht kein Schritt das Netz — Guthaben-Lizenzierung funktioniert ganz durch das Hinein- und Hinausbewegen von Dateien.

Air-gapped Credit-Blöcke sind eine Enterprise-Funktion. Der Rest dieses Beitrags — Selbstlizenz-Prüfung, offline Client-Validierung, Betrieb ohne ausgehenden Verkehr — funktioniert auf Standard und Pro ebenso gut; nur die Credit-Block-Fähigkeit ist auf Enterprise beschränkt.

Welche Edition, und wo das hineinpasst

Selbstgehostetes Keyright wird pro Deployment über Standard, Pro und Enterprise abgerechnet. Der hier beschriebene vollständig offline Betrieb ist keine Editionsfunktion — so arbeitet das Produkt auf jeder Stufe. Standard deckt einen einzelnen Produktionsknoten ab; Pro und Enterprise decken bis zu drei ab (nützlich, wenn Ihr isoliertes Netz auch Hochverfügbarkeit möchte); und Enterprise ergänzt SSO, White-Label-Branding und die obigen air-gapped Credit-Blöcke. Die aktuellen Zahlen finden Sie in den Preisen.

Da Keyright in beiden Deployment-Modi ein einziges Produkt ist, ändert sich an Ihrer Integration nichts zwischen einer Laptop-Evaluierung und einer versiegelten Produktionsenklave. Wenn Sie bereit sind, eine hinter der Lücke aufzustellen, enthält der Betriebsleitfaden die air-gapped Checkliste, die Image-Transferbefehle und die Sicherungsdisziplin, die eine laufende Instanz in eine verwandeln, auf die Sie sich verlassen können, ganz ohne Möglichkeit, nach außen zu rufen.