Session-Store im Durchgang: opake IDs, zwei Ablaufzeiten, Widerruf und Verhalten bei Ausfall

Ziel

Serverseitige Sitzungen in einem dedizierten Store mit vorhersehbarem Ablauf, Auflistung und Widerruf pro Benutzer sowie einem definierten Verhalten bei Nichtverfügbarkeit des Stores führen.

Voraussetzungen

Die Anwendung vergibt bereits eine opake, zufällige Session-ID in einem Cookie mit den richtigen Attributen; dieser Durchgang behandelt den Store hinter dieser ID.

Schritte

1. Randbedingungen: Ein Nachschlagen bei jeder Anfrage muss schnell sein; eine Sitzung endet bei einer Inaktivitätsgrenze und bei einer absoluten Grenze; „Überall abmelden" muss funktionieren; die Session-ID darf aus einer Kopie des Stores nicht wiederherstellbar sein.
2. Komponenten: der Store (ein Key-Value-Store mit TTL pro Schlüssel oder eine Datenbanktabelle mit einem Index auf das Ablaufdatum); eine von allen Instanzen gemeinsam genutzte Session-Bibliothek; ein Aufräum-Job für die Tabellenvariante; ein Admin-Pfad für den Widerruf.
3. Datenmodell: session(id_hash primary, user_id, created_at, last_seen_at, idle_expires_at, absolute_expires_at, revoked_at, client_summary) mit einem Index auf user_id. Einen Hash der ID speichern, damit ein geleakter Dump keine verwendbaren Cookies liefert. Das OWASP Session Management Cheat Sheet beschreibt Inaktivitäts- und absolute Timeouts und hält fest, dass beide Werte stark davon abhängen, wie kritisch die Anwendung und ihre Daten sind; beide als Konfiguration führen.
4. Lesen und Schreiben: pro Anfrage anhand des Hashes nachschlagen, beide Ablaufzeiten sowie revoked_at prüfen, und last_seen_at nur aktualisieren, wenn es sich um mehr als einen Schwellenwert verschoben hat, um einen Schreibvorgang pro Anfrage zu vermeiden; bei einer Rechteänderung eine neue ID vergeben und die alte Zeile löschen.
5. Widerruf: „Überall abmelden" listet Zeilen nach user_id auf und setzt revoked_at; eine Passwortänderung oder eine Admin-Aktion tut dasselbe. In einem reinen TTL-Key-Value-Store ist der Benutzerindex eine Menge von ID-Hashes, die zusätzlich zu den Zeilen gepflegt wird.
6. Fehlerfälle: Ausfall des Stores (Fail-Closed: die Anfrage mit einer klaren Fehlermeldung als nicht authentifiziert behandeln, niemals ersatzweise dem Cookie vertrauen); Uhrenabweichung zwischen Instanzen (Ablauf anhand der Uhr des Stores berechnen oder dessen TTL verwenden); ein Benutzer mit Tausenden von Sitzungen (Obergrenze pro Benutzer, älteste verdrängen); Replikationsverzögerung direkt nach der Anmeldung in einem Multi-Node-Store (auf dem Anmeldepfad den eigenen Schreibvorgang lesen); in der Tabellenvariante nie gelöschte abgelaufene Zeilen (Stapelbereinigung anhand des Ablaufindex).
7. Messen: Nachschlage-Latenz, Sitzungen pro Benutzer, Zeit vom Widerruf bis zur Wirkung, ausstehende abgelaufene Zeilen, Fehlerrate des Stores und die dadurch verursachten erzwungenen Abmeldungen.
8. Nicht zuerst: aktiv-aktive Replikation über mehrere Regionen, zustandslose Tokens, eine Oberfläche zur Geräteverwaltung, Sitzungsdaten über die Identität hinaus.

Erwartetes Ergebnis

Jede Anfrage kostet einen Lesevorgang und gelegentlich einen Schreibvorgang, der Widerruf wirkt ab der nächsten Anfrage, und ein Ausfall des Stores führt zu Abmeldungen statt stillschweigendem Vertrauen.

Grenzen und Prüfbasis

Vorgeschlagener Entwurf, keine Messungen. Cookie-Attribute und ID-Rotation werden in den Artikeln zu Session-Management und Cookie-Attributen behandelt.

Ein begrenzter lokaler Cache für Store-Ausfälle

Fail-Closed schützt davor, dem Cookie zu vertrauen, führt bei einem nur Sekunden dauernden Ausfall des Stores aber dazu, dass alle Benutzer gleichzeitig abgemeldet werden. Jede Instanz kann einen kurzen In-Memory-Cache der Sitzungen führen, die sie selbst gegen den Store validiert hat, indexiert über den ID-Hash, mit einer TTL von einigen Dutzend Sekunden. Solange der Store nicht erreichbar ist, wird eine Anfrage bedient, deren Sitzung sich in diesem Cache befindet; eine Anfrage ohne zwischengespeicherten Eintrag scheitert weiterhin nach Fail-Closed. Privilegierte Aktionen (Passwortänderung, Zahlung, Administration) erfordern stets einen frischen Lesevorgang aus dem Store und werden nie aus dem Cache bedient. Die TTL des Caches ist die Obergrenze für die Widerrufslatenz und wird zusammen mit der Messung der Zeit vom Widerruf bis zur Wirkung festgehalten.