Ein geleaktes VPN-Schlüssel ersetzen: Was der Server tun muss

Ein Laptop mit einem Client-Schlüssel ging verloren, und der erste Schritt ist meistens, die lokale Kopie zu löschen. Das ändert nichts auf dem Server, der weiterhin eine Autorisierung hält, die diesen Schlüssel annimmt, bis jemand sie entfernt. Das Ersetzen sind zwei Vorgänge, und nur der zweite betrifft die alten Anmeldedaten.

Die lokale Kopie ist nicht maßgeblich

VPN-Anmeldedaten werden akzeptiert, weil die serverseitige Konfiguration es so sagt. Bei Zertifikaten heißt das, dass das Zertifikat zu einem vertrauenswürdigen Aussteller hin verkettet und nicht auf einer Sperrliste erscheint, die das Gateway prüft. Bei WireGuard heißt das, dass der öffentliche Schlüssel des Peers in der Interface-Konfiguration erscheint. Das Löschen einer Datei auf einem Client entfernt eine Kopie eines Geheimnisses und lässt die Akzeptanzregel unberührt.

Deshalb funktioniert ein gestohlener Schlüssel nach der naheliegenden Aufräumaktion weiter, und deshalb wirkt der Vorfall ungelöst, selbst wenn die neue Konfiguration installiert ist.

Beginnen Sie bei der Regel des Servers und arbeiten Sie sich dann nach außen zum Client vor.

Zertifikate: Der Server trifft die Entscheidung

Lassen Sie die Ersatzlösung über den eigenen Prozess des Ausstellers ausstellen, damit die neue Identität erfasst wird, und ziehen Sie dann die alte mit einem signierten Widerruf zurück. Das Gateway muss so konfiguriert sein, dass es diese Widerrufsquelle prüft, und es muss sie neu laden, sonst liegt die Datei auf der Platte, während der Tunnel weiterhin die alte Seriennummer akzeptiert. Aktive Sitzungen können zudem bis zur Neuverhandlung überleben, planen Sie also eine erneute Verbindung ein.

Bestätigen Sie, dass die Ersatzlösung für die vorgesehene Anwendung funktioniert, und bestätigen Sie dann über einen genehmigten Prozess, dass das zurückgezogene Zertifikat keinen Zugang mehr herstellt.

Das sind zwei verschiedene Tests, und beide sind nötig. RFC 5280 definiert die Zertifikat- und Widerrufssemantik, auf die sich das Gateway stützt.

WireGuard: Der Peer-Schlüssel ist die Identität

WireGuard hat keine Zertifikatsebene: Der öffentliche Schlüssel des Peers ist die Identität, und der allowed-ips-Eintrag des Servers ist die Autorisierung. Das Entfernen des alten Peers aus der Interface-Konfiguration ist der Widerruf, und er gilt sofort für neue Handshakes.

Bestehende Sitzungen enden, wenn der nächste Handshake fehlschlägt, was normalerweise innerhalb von ein paar Minuten geschieht und nicht sofort.

Verteilen Sie die neue Konfiguration über einen Kanal, dem Sie ein Passwort anvertrauen würden, denn der private Schlüssel ist die Anmeldeinformation. Halten Sie einen Schlüssel pro Gerät, damit ein einzelnes verlorenes Gerät nicht alle Geräte zwingt, zu wechseln.

Was sonst noch in diesem Paket war

Ein Client-Paket trägt oft mehr als den privaten Schlüssel: einen statischen TLS-Schlüssel, einen Benutzernamen und ein Passwort, ein vorab geteiltes Geheimnis oder ein Provisioning-Token. Begrenzen Sie den Vorfall auf das, was tatsächlich offengelegt wurde, und rotieren Sie diese Elemente ebenfalls. Das Zertifikat zu rotieren, während ein geteilter statischer Schlüssel liegen bleibt, schließt eine Tür und lässt eine andere offen.

Wenn das Paket geräteübergreifend geteilt wurde, erbt jedes Gerät, das es trägt, die Offenlegung.

Notieren Sie, was rotiert wurde, denn das nächste Audit wird danach fragen.

Beweisen Sie die Ablehnung und dokumentieren Sie dann den Ersatz

Der Ersatz ist vollständig, wenn zwei Tatsachen gelten: Die neue Identität funktioniert für den vorgesehenen Dienst, und die alte wird abgelehnt. Prüfen Sie die zweite mit den zurückgezogenen Anmeldedaten aus einer Testumgebung oder mit einem kontrollierten Versuch, den die Organisation genehmigt, und lesen Sie die Gateway-Protokolle, um zu bestätigen, dass die Ablehnung aus der Richtlinie kam und nicht aus einem Tippfehler. Dokumentieren Sie dann die alte Kennung, die neue und den Zeitpunkt der Änderung, denn diese drei Werte braucht ein Prüfer, um es zu rekonstruieren. Nichts anderes im Ticket wird die Lücke erklären.

Halten Sie private Schlüssel aus Tickets und Chats heraus, und entfernen Sie veraltete Exporte gemäß Richtlinie aus Speicher und Sicherungen.

Ein Ersatz ohne Ablehnungstest ist eine Annahme und keine Behebung.