Warum Server-Schlüssel und Benutzer-Zugangsdaten getrennte Eigentümer brauchen

Der Schlüssel, der beweist, dass Ihr Gateway es selbst ist, und der Nachweis, dass eine Person beitreten darf, sind beide Geheimnisse, und dort endet die Ähnlichkeit. Das eine identifiziert einen Dienst gegenüber jedem Client; das andere identifiziert einen Benutzer gegenüber diesem Dienst. Sie zu vermischen spart einen Schritt beim Einrichten und kostet einen Nachmittag während eines Vorfalls, weil die Wiederherstellung für jedes nicht derselbe Vorgang ist. Die Trennung ist langweilig einzurichten und einprägsam, wenn man sie auslässt.

Zwei Geheimnisse, zwei verschiedene Eigentümer

Das Gateway hält einen privaten Schlüssel oder ein Zertifikat, dessen einzige Aufgabe es ist, seine Identität während des Handshakes zu beweisen. Clients brauchen das passende öffentliche Material zur Prüfung, und sie brauchen nie die private Hälfte. Diese Asymmetrie ermöglicht die Serverauthentifizierung, ohne jedem Benutzer die Fähigkeit zu geben, den Server zu imitieren.

Benutzermaterial geht in die andere Richtung. Ein privater Client-Schlüssel, ein Client-Zertifikat oder ein Passwort zeigt, dass genau diese Person oder dieses Gerät Zugriff erhalten hat. Es wird erwartet, dass es verteilt, zwischen Geräten kopiert und schließlich widerrufen wird.

WireGuard macht die Trennung offensichtlich, weil jeder Teilnehmer ein Schlüsselpaar hat: Der private Schlüssel des Servers bleibt auf dem Server, und eine Konfigurationsdatei, die Sie einem Benutzer geben, enthält dessen eigenen privaten Schlüssel plus den öffentlichen Schlüssel des Servers. Ein Profil, das den privaten Schlüssel des Servers enthält, ist keine Abkürzung, sondern eine Kompromittierung, die auf eine Dateifreigabe wartet.

Drei Fragen, die die Trennung entscheiden

Fragen Sie, wer das Geheimnis lesen können muss, was eine Offenlegung einen Angreifer tun ließe und ob die Behebung ein Widerruf oder ein Neuaufbau des Dienstes ist.

Kann ein Benutzer es lesen und beweist es die Gateway-Identität, lautet die Antwort auf die zweite Frage, dass der Angreifer Ihren Server gegenüber jedem Client imitieren kann — das schlechteste Ergebnis, weil Clients darauf ausgelegt sind, dieser Identität zu vertrauen. Beweist es nur einen Benutzer, gewährt die Offenlegung diesem Benutzer Zugriff auf einen Peer, und der Widerruf ist ein Routinevorgang. Ist es ein Schlüssel einer Zertifizierungsstelle, ist die Offenlegung schlimmer als beides, da der Angreifer Identitäten ausstellen kann, denen jeder Endpunkt vertraut.

Diese drei Antworten ergeben die Speicherregel: Der CA-Schlüssel lebt offline oder in einem Tresor, der Gateway-Schlüssel lebt auf dem Gateway, und Benutzerschlüssel leben bei den Benutzern. Jede Anordnung, die alle drei aus Bequemlichkeit in ein Verzeichnis legt, hat eine Entscheidung in einen Unfall verwandelt.

Was ein Client wirklich braucht

Ein Client braucht das öffentliche Zertifikat oder den öffentlichen Peer-Schlüssel, das CA-Material oder den Fingerabdruck, dem er vertrauen soll, seinen eigenen privaten Schlüssel und die Endpunktdetails. Diese Liste enthält nichts, was zur privaten Identität des Gateways gehört.

In der Dokumentation leckt dies. Eine Anleitung, die sagt, kopieren Sie das Serververzeichnis und löschen Sie, was Sie nicht brauchen, hat bereits das falsche Modell gelehrt, weil die Datei, die nach dem Löschschritt übrig bleibt, selten von jemandem geprüft wird.

Widerrufen Sie einen Benutzer, ohne das Gateway anzufassen

Weil Benutzeridentitäten getrennt ausgegeben werden, können sie getrennt zurückgezogen werden. Eine zertifikatsbasierte Bereitstellung widerruft das Client-Zertifikat und veröffentlicht eine aktualisierte Widerrufsliste; eine WireGuard-Bereitstellung entfernt den Peer-Eintrag aus der Serverkonfiguration. Keiner dieser Vorgänge ändert den eigenen Schlüssel des Gateways.

Bewahren Sie das Ausstellungsregister auf, sonst wissen Sie nicht, welche Identität zurückzuziehen ist. Eine Tabellenkalkulation reicht, sofern sie die Person, das Gerät, die Seriennummer oder den öffentlichen Schlüssel und das Datum nennt und sofern jemand sie pflegt, nachdem die Person, die sie aufgebaut hat, gegangen ist.

Die folgenden Befehle prüfen ein Client-Zertifikat und widerrufen es dann über eine Behörde im OpenSSL-Stil, was der Ablauf ist, den easy-rsa verpackt:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Veröffentlichen Sie die neue Liste dort, wo Clients sie prüfen, sonst ist der Widerruf eine Notiz in einer Datei, die nichts ändert. Wenn Ihr Gateway Client-Zertifikate akzeptiert, ohne eine Widerrufsliste zu konsultieren, sagen Sie das ausdrücklich, statt anzudeuten, dass der Widerruf funktioniert.

Halten Sie Sicherungen so getrennt wie die Geheimnisse

Ein Wiederaufbau-Archiv enthält zu Recht den Gateway-Schlüssel und das CA-Material, denn ohne sie kann eine Wiederherstellung den Dienst nicht reproduzieren. Ein Client-Setup-Paket darf das nicht, und beide dürfen nicht zusammen gespeichert werden. Beschriften Sie jedes Archiv danach, wer es halten darf, nicht nach dem Datum der Erstellung. Dieses Etikett liest ein müder Administrator um zwei Uhr morgens.

Diese Unterscheidung legt auch fest, wer welches abrufen darf. Das Gateway verwalten, Benutzeridentitäten ausstellen und Sicherungen lesen sind drei verschiedene Befugnisse, und wer eines braucht, braucht nicht automatisch die anderen. Schreiben Sie diese Berechtigungen auf und prüfen Sie sie dann gegen das, was Ihr Speicher tatsächlich erlaubt, denn Verzeichnisvererbung gewährt stillschweigend mehr, als die Richtlinie beabsichtigt.