Drei Telefone, ein Router und eine Überwachungsprüfung halten noch immer das alte Passwort, und eines davon verbindet sich alle neunzig Sekunden neu. Das Kontopasswort wurde vor zehn Minuten geändert, also übermittelt jeder dieser Clients jetzt einen Wert, den der Server ablehnt. Das ist der Moment, in dem der Mythos bricht: Eine Passwortänderung betrifft das Konto, nicht die Kopien des alten Werts auf jedem Gerät. Was folgt, ist die Arbeit, die die Änderung nicht erledigt hat.

Der Mythos: eine Änderung, überall gleichzeitig

Die Annahme ist, dass eine Passwortänderung alles abmeldet und eine saubere neue Anmeldung erzwingt. Das tut sie nicht, denn der Server verfolgt nur, welche Anmeldedaten er zuletzt akzeptiert hat, während die Clients behalten, was sie gespeichert haben. Ein Gerät mit gespeichertem Passwort versucht es nach seinem eigenen Zeitplan erneut und scheitert still, bis jemand merkt, dass das Konto gesperrt ist. Sobald man akzeptiert, dass die Kopien außerhalb des Kontos leben, sieht die Rotation nicht mehr wie eine einzelne Aktion aus.

Nichts davon spricht gegen die Rotation. Es spricht dafür, die gespeicherten Kopien als Teil der Änderung zu behandeln statt als Nachgedanken. Eine Sperre entsteht meist aus parallelen Wiederholungen: Jedes Gerät übermittelt weiterhin den alten Wert nach seinem eigenen Zeitplan, bis der Zähler auslöst. Dann wirkt das Konto angegriffen, obwohl ihm nur Anmeldedaten angeboten werden, die niemand ersetzt hat. Diese Unterscheidung zählt, denn die Lösung ist eine Geräteliste und keine strengere Sperrrichtlinie.

Erfassen Sie die Kopien, bevor Sie rotieren

Schreiben Sie die Bestandsliste, bevor Sie das Passwortformular öffnen. Listen Sie jeden Client, jedes Skript, jede Automatisierung und jedes verwaltete Profil auf, das sich als dieses Konto authentifiziert: das Telefon, das sich selbst verbindet, der vor zwei Jahren konfigurierte Router, das Notebook, das nur montags aufwacht, und die Überwachungsprüfung, die es jede Minute versucht. Notieren Sie für jedes, wo die Anmeldedaten gespeichert sind, ob das Gerät während der Änderung erreichbar ist und welcher Wiederherstellungsweg existiert, wenn es sich nicht neu verbinden kann. Diese Liste macht aus einer riskanten Änderung eine geplante, und sie muss existieren, bevor das alte Passwort aufhört zu funktionieren.

Offline-Geräte sind der klassische Fehlgriff. Ein Notebook in einer Schublade kehrt drei Wochen später zurück und präsentiert den veralteten Wert im ungünstigsten Moment. Notieren Sie auch seinen Standort und seinen Zeitplan, denn Sie werden ihm nachjagen müssen, statt auf es zu warten.

In einer Linux-Flotte ist die Suche mechanisch statt clever. Suchen Sie nach Profilen, die auf eine Anmeldedatendatei verweisen, dann nach den Anmeldedatendateien selbst, denn die zweite Liste ist die, die neu geschrieben werden muss. Wiederholen Sie die Übung für Desktop-Clients und Telefone, wo der Speicher ein Profil oder ein Schlüsselbund-Eintrag statt eines Pfads ist. Das Ziel ist eine Liste, die Sie abarbeiten können, kein Scan, der behauptet, jede Kopie zu finden.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Messen Sie die Kopien an den Menschen, denen sie gehören. Ein Gerät, das niemand beansprucht, ist ein Gerät, das niemand aktualisiert, und es ist auch das, das am wahrscheinlichsten weiter versucht.

Welches Geheimnis Sie tatsächlich rotieren

Ein Kontopasswort ist nur eine Anmeldeinformation in einer VPN-Bereitstellung. Eine Schlüsselpassphrase, eine Zertifikatsidentität und ein optionales Peer-Geheimnis haben jeweils ihren eigenen Ersetzungsweg und ihren eigenen Eigentümer. Das Kontopasswort zu ändern, bewirkt nichts für ein Gerät, das sich mit einem Zertifikat authentifiziert, und ein Zertifikat neu auszustellen, bewirkt nichts für einen Client mit gespeichertem Passwort. Benennen Sie das Geheimnis, bevor Sie die Lösung benennen.

Wenn die Rotation von Verdacht statt von Richtlinie getrieben ist, hat der Incident-Prozess Vorrang vor dem Bequemlichkeitsplan. Widerrufen Sie, was die Beweise verlangen, und akzeptieren Sie die Mehrarbeit an der Geräteliste. Diese Entscheidung gehört dem Incident-Verantwortlichen, nicht demjenigen, der zufällig das Formular zum Zurücksetzen des Passworts hält.

Ersetzen Sie den gespeicherten Wert dort, wo er lebt

Ändern Sie die Anmeldedaten über den Mechanismus, den der Dienst dokumentiert, und aktualisieren Sie dann die gespeicherte Kopie oder führen Sie den Anmeldeablauf auf jedem Gerät aus, das Sie behalten wollen. Bearbeiten Sie keine generierte Konfiguration hinter einem Manager, der sie neu schreibt, denn der Manager stellt beim nächsten Lauf den älteren Wert wieder her, und die Bearbeitung wird zu einem verzögerten Ausfall. Aktualisieren Sie die Quelle, die der Manager liest, oder nutzen Sie den eigenen Anmeldedatenspeicher des Clients. So oder so muss das Gerät am Ende den neuen Wert an der Stelle haben, die der Client tatsächlich liest.

Ein Client, der eine Passwortdatei speichert, braucht die neu geschriebene Datei, während ein Client, der nachfragt, eine abgeschlossene Anmeldung braucht. NetworkManager hält das Geheimnis im Verbindungsprofil, also läuft die Änderung über nmcli statt über einen Texteditor:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Ein Profil, das eine Anmeldedatendatei liest, ist ein dritter Fall. Ersetzen Sie den Inhalt dieser Datei, halten Sie ihre Berechtigungen geschlossen und laden Sie den Client neu, statt das Profil zu bearbeiten, das darauf verweist. Das Profil hat sich nicht geändert; nur das Geheimnis, das es liest.

Verbinden Sie jedes vorgesehene Gerät einmal bewusst neu und beobachten Sie, welche scheitern. Wenn ein Gerät weiter scheitert, prüfen Sie das Konto, auf das es zeigt, und den Speicher, den es liest, bevor Sie das Passwort erneut ändern, denn eine zweite Änderung vervielfacht die Kopien, die aktualisiert werden müssen. Ein Gerät, das zweimal scheitert, zeigt meist auf das falsche Konto oder liest einen Speicher, den Sie noch nicht gefunden haben. Beheben Sie das und verbinden Sie dann neu.

Sitzungen und Token überleben das Passwort

Eine Passwortänderung beweist nicht, dass bestehende Sitzungen oder separate Zertifikate widerrufen wurden. Manche Dienste halten eine Sitzung am Leben, bis sie abläuft oder ausdrücklich beendet wird, und ausgegebene Token tragen ihre eigenen Laufzeiten. Prüfen Sie, was der Dienst tatsächlich tut, statt anzunehmen, die Änderung sei global gewesen. Wenn die Änderung von Verdacht getrieben war, beenden Sie die Sitzungen ausdrücklich und bestätigen Sie das Ergebnis.

Die Leitlinie zum Lebenszyklus von Anmeldedaten in NIST SP 800-63B hält Authentifikatoren und Sitzungen in getrennten Kategorien, weshalb eine Passwortänderung und eine globale Abmeldung verschiedene Vorgänge sind. Behandeln Sie sie als zwei Aufgaben mit zwei Abschlusskriterien. Die erste ist erledigt, wenn der neue Wert funktioniert, und die zweite, wenn die alten Sitzungen weg sind.

Halten Sie den Abschluss fest, ohne das neue Passwort in den Eintrag zu schreiben. Ein Rotationsprotokoll, das die Anmeldedaten enthält, ist ein neuer Vorfall, der auf einem freigegebenen Laufwerk wartet. Notieren Sie das Datum, die aktualisierten Geräte und die Geräte, die noch ausstehen.

Ähnliche Artikel