Ich habe den Zugriff entzogen und sie sind immer noch drin: Sitzung und Berechtigung sind nicht dasselbe

Sie haben die Berechtigung entfernt, sogar das Konto deaktiviert, und die Person kann weiterhin etwas tun. Nichts ist kaputt: Zugriff entziehen und eine Sitzung beenden sind zwei getrennte Handlungen.

AtlasPVE ·

Dieser Eintrag beantwortet

  • proxmox benutzer gelöscht kann sich noch anmelden
  • proxmox berechtigung entfernt hat noch zugriff
  • proxmox meldet mich ständig ab
  • wie lange dauert eine proxmox sitzung
  • proxmox api token widerrufen

Sie haben einem Benutzer die Berechtigung entzogen. Vielleicht haben Sie das Konto ganz deaktiviert. Dann bemerken Sie, dass diese Person immer noch etwas tun kann.

Nichts ist kaputt. Anmelden und berechtigt sein sind zwei getrennte Augenblicke, und dazwischen liegt eine Lücke.

Die Anmeldung geschieht einmal, die Berechtigung wird jedes Mal erfragt

Wenn Sie sich anmelden, reicht Ihnen das System ein Ticket. Das Ticket sagt: diese Person hat nachgewiesen, wer sie ist, und dieses Ticket gilt bis zu dieser Uhrzeit.

Die Berechtigung ist eine eigene Frage und wird bei jeder Anfrage erneut gestellt. In der Praxis nehmen viele Systeme aber aus Geschwindigkeitsgründen bei der Anmeldung eine Kopie der Berechtigungskarte und benutzen diese Kopie eine Weile.

Daraus entstehen zwei Verzögerungen.

Die erste: entziehen Sie eine Berechtigung, kann eine offene Sitzung jene Kopie weiter mit sich führen. Die Änderung erreicht sie erst, wenn die Sitzung erneuert wird.

Die zweite und wichtigere: einen Benutzer zu löschen oder zu deaktivieren zerreißt nicht das Ticket, das er in der Hand hält. Das Ticket ist in sich abgeschlossen und bleibt gültig, bis es abläuft.

Die Regel: Zugriff entziehen ist nicht Sitzung beenden

Das sind zwei getrennte Handlungen, und nur die erste zu tun lässt hinter Ihnen ein Fenster offen.

Das Fenster ist nicht unendlich; ein Ticket gilt keinen ganzen Tag. Aber null ist es auch nicht, und in einem dringenden Fall ist "es schließt sich gleich" keine ausreichende Antwort.

Wenn jemand geht oder ein Passwort verdächtig ist

Tun Sie drei Dinge, der Reihe nach.

Entziehen Sie die Berechtigung. Deaktivieren Sie auch das Konto, wenn das angebracht ist.

Ändern Sie das Passwort. Das schließt den Weg, sich ein frisches Ticket als Ersatz zu holen. Eine Berechtigung zu entziehen tut das allein nicht.

Entfernen Sie die Zugriffstoken gesondert. Das ist der am häufigsten übersprungene Schritt. Ein Token ist keine Sitzung: es läuft nicht von selbst ab, es lebt, bis Sie es löschen. Das Passwort eines Benutzers zu ändern macht seine Token nicht ungültig. Prüfen Sie beim Entfernen eines Benutzers gesondert, was aus seinen Token wurde.

Und räumen wir ein Missverständnis aus: Zwei-Faktor-Authentifizierung hilft Ihnen hier nicht. Sie schützt den Augenblick der Anmeldung. Zu einer bereits offenen Sitzung hat sie nichts zu sagen.

Die Gegenrichtung: warum werde ich ständig abgemeldet

Das ist die andere Seite desselben Mechanismus.

Das Ticket hat eine begrenzte Lebensdauer, und die Oberfläche erneuert es regelmäßig, solange Sie im Tab sind. Schließen Sie den Tab und kommen Stunden später wieder, hat keine Erneuerung stattgefunden, das Ticket ist tot, und Sie werden zur erneuten Anmeldung aufgefordert. Das ist keine Störung.

Die zweite, weniger bekannte Ursache ist interessanter: die Uhr der Maschine. Ein Ticket trägt einen Zeitstempel. Läuft die Uhr des Servers aus dem Takt, kann ein soeben ausgestelltes Ticket so aussehen, als käme es aus der Zukunft oder sei längst abgelaufen. Das Symptom verwirrt: das Passwort stimmt, die Anmeldung scheint angenommen, und gleich danach fällt die Sitzung. Auf der Identitätsseite nach einem Uhrproblem zu suchen fällt niemandem ein, aber suchen Sie.

Was Atlas macht

Bei Atlas ist das Cookie, das an den Browser geht, nicht das echte Ticket. Der Browser trägt nur eine bedeutungslose Zufallskennung; das eigentliche Ticket bleibt auf dem Server.

Der Unterschied ist konkret: selbst wenn eine Browserlücke das Cookie liest, kommt sie nicht an das Ticket selbst und kann es also nicht anderswohin tragen und dort benutzen. Das Einzige, was sie tun kann, ist aus diesem Browser heraus zu handeln, solange jene Sitzung lebt. Das ist kein Nullrisiko, aber es verengt den Umfang der Bedrohung.

Offene Sitzungen werden auf die Platte geschrieben, sodass bei einer Aktualisierung des Produkts niemand hinausgeworfen wird. Das Schreiben geschieht bewusst in einem Schritt: wäre die Datei halb geschrieben geblieben, dann wären, obwohl die Leseseite das verträgt, alle offenen Sitzungen gefallen.

Erzählenswert ist eigentlich ein Fehler, der hier durch Messen gefunden wurde.

Abgelaufene Sitzungseinträge wurden nur aus dem Speicher entfernt, nicht aus der Datei. Eine laufende Maschine wurde nachgesehen: in der Datei lagen fünf abgelaufene Einträge, in jedem ein Ticket. Sie wären dort bis zur nächsten Anmeldung geblieben, denn nichts anderes schrieb jemals in diese Datei.

Die Absicht des Codes war ohnehin, sie nicht zu behalten. Das Einzige, was fehlte, war der Schreibschritt.

Die Lehre gilt für jeden, der Sicherheitscode schreibt: Vergessen hat zwei Orte. Was aus dem Speicher entfernt wurde, ist nicht von der Platte entfernt, und von beiden lebt das auf der Platte immer länger. Wenn Sie entscheiden, dass etwas nicht aufbewahrt werden darf, lautet die zweite Frage immer gleich: wo wird es aufbewahrt?

Quellen

Die eigene Dokumentation von Proxmox. Auf Englisch, und sie hat in dieser Sache das letzte Wort.

Verwandte Einträge

Wie sieht das in Atlas aus?

Zur Produktseite