Zum Inhalt

Login-Sitzungen & Identität bestätigen

Vesana hält Anmeldungen bewusst lang und macht sie dafür jederzeit widerrufbar: Jede Browser-Anmeldung ist eine serverseitige Sitzung, die du im Konto sehen und beenden kannst. Was heikle Aktionen schützt, ist nicht eine kurze Sitzung, sondern die Identitätsbestätigung direkt davor.

Angemeldet bleiben

Das Häkchen „Angemeldet bleiben" auf der Login-Seite ist vorausgewählt. Damit überlebt die Anmeldung Browser-, PC- und Geräteneustarts — auch als installierte App auf dem Smartphone. Wer es abwählt, wird abgemeldet, sobald der Browser geschlossen wird; das gilt auch für Konten mit 2FA (ab v1.9.437).

Betreiber können die Option instanzweit ausschalten (siehe unten) — dann endet jede Anmeldung mit dem Schließen des Browsers, etwa im Terminal-Betrieb.

Fristen

Zwei Fristen begrenzen jede Sitzung; beide gelten instanzweit und lassen sich unter Admin → Anmeldung & Sicherheit → 2FA & Sitzungen → Login-Sitzungen ändern:

Einstellung Standard Bedeutung
Abmelden nach Inaktivität 30 Tage Solange du Vesana nutzt, verlängert sich die Sitzung automatisch. Erst nach dieser Zeit ohne Nutzung ist eine neue Anmeldung nötig. Wählbar von 1 Stunde bis 90 Tage
Absolute Obergrenze (auch bei Aktivität) 90 Tage Spätestens dann ist eine neue Anmeldung fällig — unabhängig davon, wie aktiv das Konto war. Wählbar bis 1 Jahr, nie kürzer als die Inaktivitätsfrist
Bei Neustart alle abmelden aus Ein Neustart von Vesana oder der Vesana-Maschine meldet alle Benutzer ab. Updates zählen nicht als Neustart — ein angekündigtes Update übernimmt die laufenden Sitzungen
„Angemeldet bleiben" anbieten an Ob das Häkchen auf der Login-Seite erscheint
Script-Änderungen verlangen Identitätsbestätigung an Siehe Script-Änderungen bestätigen

Verlängert ein Admin eine Frist, gilt das sofort auch für laufende Sitzungen. Die Fristen gelten ebenso für Anmeldungen per API-Token (Bearer): Auch eine Token-Kette, die sich per Refresh immer wieder verlängert, endet spätestens an der absoluten Obergrenze.

Eigene Geräte sehen und abmelden

Einstellungen → Sitzungen listet alle aktiven Anmeldungen des eigenen Kontos: Browser/Gerät, IP-Adresse, angemeldet seit, zuletzt genutzt. Die aktuelle Sitzung ist markiert.

  • Eine fremde Sitzung einzeln abmelden (Knopf in der Zeile)
  • Überall sonst abmelden — beendet alle anderen Geräte und Browser, auch Anmeldungen über die API; die aktuelle Sitzung bleibt. Mit dem Haken Auch API- und KI-Zugänge widerrufen (Standard aus) werden zusätzlich alle API-Zugänge des Kontos und seines KI-Kontos widerrufen
  • Die aktuelle Sitzung endet über das normale Abmelden

Abmelden wirkt serverseitig und innerhalb von Sekunden: Ein beendetes oder widerrufenes Login-Cookie funktioniert danach auf keinem Gerät mehr, auch nicht innerhalb der Restlaufzeit des Tokens. Ein bereits verbrauchter Anmelde-Token, der erneut auftaucht (Hinweis auf Diebstahl), beendet die ganze Sitzung sofort.

Was andere Sitzungen beendet

Ereignis Wirkung
Passwort ändern (Einstellungen → Profil) Alle anderen Sitzungen werden abgemeldet, auch API-Anmeldungen ohne Browser; die aktuelle bleibt. Die Antwort nennt, wie viele es waren. Mit dem Haken Auch API- und KI-Zugänge widerrufen (Standard aus) enden zusätzlich alle API-Zugänge des Kontos und seines KI-Kontos; ohne Haken bleiben sie gültig
Konto deaktivieren oder löschen Alle Sitzungen und API-Zugriffe des Kontos enden sofort
Admin → Benutzer → „Passwort setzen" Alle Sitzungen des Benutzers enden, auch Anmeldungen über die API und die App
SSO-Provider oder Verzeichnis abschalten/löschen Alle Sitzungen seiner Benutzer enden sofort; im Active Directory deaktivierte oder aus der Gruppe genommene Konten spätestens nach 15 Minuten
Admin → Benutzer → „Alle Sitzungen abmelden" Notbremse bei kompromittierten Konten: alle Sitzungen des Benutzers auf jedem Gerät; Passwort und 2FA bleiben unverändert. Nach Rückfrage, mit Rückmeldung der Anzahl (ab v1.9.437 auch als Knopf in der Benutzerzeile)
Admin → Benutzer → „2FA zurücksetzen" Entfernt den zweiten Faktor und meldet alle Sitzungen ab — siehe 2FA
Neustart der Instanz nur, wenn „Bei Neustart alle abmelden" eingeschaltet ist

Abmelde-Grund auf der Login-Seite

Wer abgemeldet wurde, sieht auf der Login-Seite, warum — zum Beispiel: länger nicht aktiv, maximale Dauer erreicht, anderswo abgemeldet (Überall-sonst-abmelden oder Administrator), Passwort geändert, Konto deaktiviert, Vesana neu gestartet, oder Sitzung aus Sicherheitsgründen beendet (wiederverwendeter Token). Das hilft beim Unterscheiden zwischen „normal abgelaufen" und „jemand hat eingegriffen".

Identität bestätigen (Step-Up)

Vor Aktionen, die das Sicherheitsniveau eines Kontos oder der Instanz verändern, verlangt Vesana eine frische Bestätigung der Identität — unabhängig davon, wie lange die Sitzung schon läuft. Der Dialog „Identität bestätigen" öffnet sich automatisch; nach der Bestätigung wird die Aktion ausgeführt.

Gilt 15 Minuten, pro Sitzung. Ein frischer Login zählt selbst als Bestätigung. Ein zweites Gerät desselben Kontos muss sich eigenständig bestätigen.

Welche Aktionen

  • Eigene 2FA einrichten/abschalten, Passkeys hinzufügen/entfernen, Backup-Codes neu erzeugen (das eigene Passwort ändern verlangt stattdessen das aktuelle Passwort)
  • Benutzer anlegen, ändern, löschen, Passwort setzen, 2FA zurücksetzen, Script-Rechte und „Rechte & Teams" ändern
  • Rollen anlegen, ändern, löschen; Teams anlegen, ändern, löschen; Tenant in eine Tenant-Gruppe verschieben
  • Tenant löschen, Tenant-API-Key erzeugen
  • Sicherheitseinstellungen: Sitzungsfristen, 2FA-Pflichtregeln und Ausnahmen, Admin-Zugriff, Portal-Layout, Split-Container-Umstellung (auch Abbrechen und Zurücknehmen)
  • SSO-Provider und Verzeichnisse (Active Directory / LDAP) anlegen, ändern, löschen
  • SMTP-Einstellungen und Testversand, Lizenzschlüssel ändern, KI-Konfiguration und KI-Verbindungstest
  • Collector-Schlüssel neu erzeugen; Aktive Collectors einrichten, hinzufügen, entfernen, primär machen und ihre Ausführungsfreigaben ändern
  • Agents oder Collectors auf eine andere Server-URL umziehen
  • Zertifikat der Instanz: jede ändernde Aktion (Einstellungen, Zugang prüfen, Probelauf, Ausstellen, Einsetzen, Erneuern, Hochladen, Zurück)
  • Geänderten SSH-Schlüssel eines Geräts übernehmen
  • Agent-Gateway umschalten, Offline-Update einspielen, Speicher-Aufbewahrung ändern
  • Support-Bundle ansehen/senden/herunterladen; Backup herunterladen, wiederherstellen, löschen, Backup-Aufbewahrung ändern, Aufräumlauf starten
  • Papierkorb: einzelnen Eintrag endgültig löschen und Papierkorb komplett leeren
  • Script- und Kommando-Änderungen (abschaltbar, siehe Script-Änderungen bestätigen)

Script-Änderungen bestätigen

Scripts und eigene Kommandos laufen auf den überwachten Rechnern — über den Agent als SYSTEM bzw. root, über den Collector mit den Zugangsdaten des Geräts. Wer diesen Code ändert, bestätigt deshalb vorher seine Identität. Das gilt für jedes Konto, auch für Super-Admins: die Berechtigung legt fest, wer Scripts ändern darf; die Bestätigung stellt sicher, dass wirklich diese Person vor dem Bildschirm sitzt und nicht jemand mit einer übernommenen Sitzung.

Eine Bestätigung ist 15 Minuten gültig, gerechnet ab dem Moment der Bestätigung. Sie gilt nur für die Sitzung, in der bestätigt wurde. In diesen 15 Minuten kannst du beliebig viele Scripts und Kommandos ändern, ohne erneut gefragt zu werden. Danach fragt die nächste Script-Änderung wieder. Die Frist verlängert sich durch Arbeiten nicht. Ein frischer Login zählt ebenfalls als Bestätigung, auch hier für 15 Minuten. Es ist dieselbe Bestätigung wie bei den anderen Aktionen oben: Wer sich für eine davon bestätigt hat, wird innerhalb der 15 Minuten auch bei Script-Änderungen nicht erneut gefragt.

Eine Bestätigung wird verlangt, wenn sich ändert, welcher Code läuft:

  • Script in der Script-Bibliothek anlegen, auch „als eigenes Script" beim Bearbeiten eines Checks
  • Inhalt oder Interpreter eines bestehenden Scripts ändern (auch über „einstellbare Werte", die als Kopfzeile im Script stehen)
  • Eigenen Script-Inhalt „nur für dieses Gerät" an einem Check setzen oder ändern
  • Ein eigenes Kommando setzen oder ändern (Check-Typen mit Feld „Kommando", z. B. Agent-Kommando, SSH-Kommando): beim Anlegen oder Bearbeiten eines Checks, beim Anlegen eines Hosts mit solchen Checks und im Profil
  • Programm oder Argumente eines Plugin-Checks („Plugin (Nagios)") sowie den Inline-Rumpf eines Agent-Script-Checks setzen oder ändern
  • Profile aus einer Datei importieren, wenn das Profil Scripts oder Kommandos mitbringt

Keine Bestätigung verlangen: ein vorhandenes Script einem Check zuweisen, Werte eines Scripts am Check einstellen, Name, Beschreibung oder Ausgabeformat eines Scripts ändern, Scripts löschen, Intervalle und Schwellwerte ändern und Profile aus der Vesana-Bibliothek installieren oder aktualisieren (nur von Vesana signierte Versionen). Beim Speichern eines Checks schickt die Oberfläche oft die ganze Konfiguration mit; gefragt wird nur, wenn sich Code tatsächlich ändert.

Abschalten: unter Admin → Anmeldung & Sicherheit → 2FA & Sitzungen → Login-Sitzungen, Schalter „Script-Änderungen verlangen Identitätsbestätigung" (Standard: an, auch nach einem Update). Das Umschalten ist selbst eine Sicherheitseinstellung und verlangt eine Bestätigung. Es wird im Audit-Log festgehalten (session_settings_update). Wir empfehlen, den Schalter eingeschaltet zu lassen. Zusätzlich schützt die Agent Lock auf wichtigen Servern: dort laufen geänderte Scripts erst, wenn sie am Server selbst freigegeben wurden.

Für Automationen über die API gilt dasselbe wie oben: Der Login zählt 15 Minuten als Bestätigung. Ein Skript, das länger läuft und danach Scripts ändert, bekommt 403 mit code: STEP_UP_REQUIRED (reason: script_change). Es muss sich dann über POST /api/v1/auth/step-up erneut bestätigen oder neu anmelden.

Womit bestätigen

Der Dialog bietet die Wege an, die für das Konto eingerichtet sind — in dieser Reihenfolge: Passkey/Sicherheitsschlüssel, Code aus der Authenticator-App, Passwort, Backup-Code. SSO-Konten ohne lokalen Faktor bestätigen sich durch eine erneute Anmeldung beim Identity-Provider und kommen danach zurück. Hat ein Konto keinen Bestätigungsweg (kein Passwort, kein zweiter Faktor), muss ein Administrator einen setzen.

Ein TOTP-Code gilt genau einmal — derselbe Code bestätigt keine zweite Anmeldung und keine weitere Sicherheitsabfrage (ab v1.9.437).

Tokens nie in Adressen

Anmelde-Tokens tauchen weder in Web-Adressen noch in Server-Logs auf — auch nicht bei Live-Logs oder im TV-Modus. Für Skripte und API-Clients gilt der Bearer-Weg, siehe Auth-Flow.

Anschluss