Zum Inhalt

Rollen & Permissions

Vesana nutzt rollenbasierte Zugriffssteuerung (RBAC). Jede Rolle ist eine Menge von Permissions — ein Permission ist ein einzelnes Recht-Bit wie hosts.create, alert_rules.edit, ai.query.

Deny-by-default: Eine neue Custom-Rolle startet mit einer leeren Permission-Liste — nichts ist automatisch erlaubt. Jedes Recht muss explizit vergeben werden. Nur der Super-Admin ist eine Ausnahme: er umgeht die Permission-Prüfung komplett.

Rollen gelten instanzweit — dieselbe Rolle kann Konten in jedem Tenant zugewiesen sein. In welchem Tenant sie für wen gilt, regeln Tenant-Zugriff und Zuweisungen.

Default-Rollen

Mitgeliefert, vier Stück:

Rolle Wer Wofür
Super Admin dein Setup-Team Vollzugriff auf alle Tenants und alle Funktionen — auch die, die keine eigene Permission haben (Benutzer, Teams, Tenants und Tenant-Gruppen verwalten, Backup-Restore, Vorschau-Funktionen, instanzweite Einstellungen)
Admin Tenant-Verantwortlicher Alles in seinen Tenants außer: Rollen bearbeiten (users.edit_role), endgültig löschen (trash.purge), Backup herunterladen (backup.export), die globalen Sichtstufen von Papierkorb/Audit-Log/Diagnose-Log und instanzweite Icons/MIBs
Operator NOC, Support-Team Lesen + Alerts bearbeiten (ACK/close), Downtimes anlegen und ändern, „Jetzt prüfen", Updates verschieben, Standorte, Dashboards/Wiki/Icons bearbeiten, KI nutzen, Diagnose-Log des Tenants — keine Admin-Operationen
Viewer Endkunde, Stakeholder Reine Lesesicht, plus eigene Saved-Filters. Kein ACK, keine Downtimes, kein „Jetzt prüfen" — wer das braucht, bekommt Operator oder eine Custom-Rolle

Änderungen an den Standardrollen

Seit v1.9.350 verlangen Quittieren (alerts.acknowledge) und Wartungsfenster (downtimes.create/.edit) ihre Berechtigung wirklich — Viewer konnten das vorher trotz fehlendem Recht. Ab v1.9.437 gilt dasselbe für „Jetzt prüfen" (check_results.reschedule), für Sammel-Löschen von Checks (services.delete) und für Anomalie-Einstellungen (hosts.edit); Geräte- und Check-Daten lesen setzt hosts.view bzw. services.view voraus (in allen Standardrollen enthalten). Die eingebaute Admin-Rolle bekommt neue Berechtigungs-Bereiche beim Start automatisch nachgereicht; bewusst entfernte Einzelrechte bleiben weg.

Admin, Operator und Viewer lassen sich bearbeiten, Super Admin nicht. Löschen lässt sich keine der vier eingebauten Rollen (Kennzeichen „System").

Custom Roles

Admin → Benutzer & Rechte → Rollen → Neue Rolle:

Feld Bedeutung
Name beliebig
Beschreibung optional
Permissions Multi-Select aus der Liste, leer startend (deny-by-default). Anlegen/Bearbeiten/Löschen braucht ein Recht (*.create/.edit/.delete) zusammen mit dem passenden *.view

Wer Rollen anlegen, ändern oder löschen will, braucht users.edit_role in allen Tenants (weil eine Rolle instanzweit wirkt) und bestätigt seine Identität. Er kann keine Rechte vergeben, die er selbst nicht in allen Tenants hat. Eine Rolle, die noch einem Benutzer als Grundrolle oder in einer Zuweisung vergeben ist, lässt sich nicht löschen.

Beispiele für sinnvolle Custom-Rollen:

  • Auditor — nur audit_log.view_tenant, sonst nichts
  • Read-Only Manager — alle *.view-Permissions plus reports.view, dashboards.view
  • Push-Tester — nur notifications.view + notifications.create, sonst nichts

Permission-Kategorien (Auswahl)

Permissions folgen dem Muster ressource.aktion. Auswahl der wichtigsten Kategorien:

Kategorie Permissions Bedeutung
Hosts hosts.view / .create / .edit / .delete Hosts anlegen/bearbeiten
Services services.view / .create / .edit / .delete Host-Services (Checks)
Dashboards dashboards.view / .create / .edit / .delete Dashboards + Status-Pages (die eingebaute Übersicht sieht jeder)
Sites sites.view / .manage Standorte (physische Karten)
Alert Rules alert_rules.view / .create / .edit / .delete Alert-Regeln
Notifications notifications.view / .create / .edit / .delete Notification-Channels
Downtimes downtimes.view / .create / .edit / .delete Wartungsfenster
Alerts alerts.view / .acknowledge / .close Laufende Probleme bearbeiten
Check-Ergebnisse check_results.view / .reschedule Historie + „Jetzt prüfen" / „Agent jetzt erheben"
Updates updates.defer / .decline / .install_now Automatische Updates verschieben (Operator), ablehnen bzw. sofort installieren (Admin)
Gespeicherte Filter saved_filters.view / .create / .edit / .delete Eigene Filter in Listen
Tenant-Einstellungen tenant_settings.view / .edit Alert-Gruppierung und Notizen des Tenants
Zugangsdaten credentials.manage Zugangsdaten-Sets des Tenants anlegen/ändern (lesen reicht hosts.view)
Collectors / Agents collectors.*, agents.view / .manage Erfassungs-Infrastruktur
Profile profiles.view / .create / .edit / .delete Geräteprofile
Monitoring-Scripts monitoring_scripts.view / .create / .edit / .delete Custom-Scripts
Reports reports.view / .export / .delete Reporting
Audit-Log audit_log.view (Alias) / .view_own / .view_tenant / .view_global Wer sieht wie viel vom Änderungsverlauf
System-Log system_log.view (Alias) / .view_own / .view_tenant / .view_global Diagnose-Log-Sichtbarkeit
Users users.view / .edit_role Benutzer- und Rollenliste sehen bzw. Rollen bearbeiten (in allen Tenants nötig). Benutzer anlegen und ändern bleibt Super-Admins vorbehalten
Papierkorb trash.view (Alias) / .view_own / .view_tenant / .view_global / .restore / .purge Papierkorb-Sichtbarkeit + Aktionen
Backup backup.export Backup herunterladen (Restore bleibt hart Super-Admin-only)
Wiki wiki.view / .create / .edit / .delete Knowledge-Base
AI ai.query / .analyze KI-Features
Icons icons.view / .upload / .assign / … Icon-Verwaltung (*_global = instanzweit)
MIBs mibs.view / .upload / .delete / .upload_global MIB-Ablage; upload_global lädt instanzweit hoch
Discovery discovery.manage_settings Auto-Discovery-Plattform-Defaults

Die vollständige, aktuelle Liste zeigt dir der Rollen-Editor selbst beim Anlegen einer Custom-Rolle.

Fein-granulare Sichtbarkeits-Stufen (Audit-Log, System-Log, Papierkorb)

Diese drei Bereiche kennen jeweils drei Sichtbarkeits-Stufen statt nur Ja/Nein:

  • .view_own — nur eigene Aktionen/Einträge
  • .view_tenant — alles im eigenen Tenant
  • .view_global — tenant-übergreifend inklusive instanzweiter Einträge; wirkt nur in einer Zuweisung mit Bereich „Alle Tenants". Aus einer Zuweisung für einzelne Tenants zählt sie wie .view_tenant.

Der alte, gröbere Alias (z. B. trash.view) funktioniert für bestehende Custom-Rollen weiterhin und verhält sich wie .view_own — neue Rollen legst du direkt mit der passenden Stufe an.

Feature-Sichtbarkeit

Permissions steuern nicht nur API-Zugriff, sondern auch UI-Sichtbarkeit. Beispiele:

  • Ohne ai.query: Chat-Widget unsichtbar
  • Ohne alert_rules.view: Menüpunkt „Alert-Rules" weg
  • Ohne reports.view: Reports-Sektion weg

Rollen-Zuweisung

Der einfache Weg: Jeder User hat eine Grundrolle und einen Tenant-Zugriff (alle oder eine Auswahl) — beides im Dialog „Benutzer bearbeiten". Die Rolle gilt dann in allen Tenants des Users. Für kleine Umgebungen reicht das.

Verschiedene Rechte in verschiedenen Tenants (z. B. Admin bei Kunde A, nur lesen bei Kunde B): über Zuweisungen. Eine Zuweisung ist Rolle × Bereich, der Bereich ist ein Tenant, eine Tenant-Gruppe oder „Alle Tenants" (auch künftige). Zuweisen kannst du

  • einem Team — Admin → Benutzer & Rechte → Teams (nur Super-Admins). Ein Team hat Name, Beschreibung, Mitglieder und Zuweisungen; wer ins Team kommt, hat sofort dessen Rechte. Das ist der Weg für viele Benutzer: Rollen einmal anlegen, Teams einmal einrichten, danach nur noch Leute ins Team nehmen.
  • einem einzelnen User — in der Benutzerliste Zeilen-Aktion Rechte & Teams, Abschnitt „Weitere Rechte nur für dieses Konto".

Regeln:

  • Rechte addieren sich. In jedem Tenant gilt alles, was die Grundrolle, eine Team- oder eine direkte Zuweisung dort erlaubt. Es gibt kein „Verbieten".
  • Aktionen ohne Tenant-Bezug (z. B. ein Profil anlegen) erlaubt jede Zuweisung, die das Recht enthält.
  • Super-Admin ist keine Zuweisung, sondern eine Eigenschaft des Kontos — Teams und Zuweisungen haben dort keine Wirkung.
  • Änderungen wirken sofort — angemeldete User bekommen beim nächsten Klick die neuen Rechte.
  • Sichtbar, aber nicht erlaubt: Wer einen Tenant sieht, dort aber ein Recht nicht hat, bekommt eine klare Meldung „Keine Berechtigung … in diesem Tenant".

Den Überblick behalten: „Rechte & Teams" zeigt unter Wirksame Rechte je Tenant, welche Rollen gelten und woher (Grundrolle, direkt, über Team X, über Gruppe Y). Mit SSO bzw. Active Directory lassen sich Teams aus Gruppen des Identity-Providers bzw. Verzeichnisses setzen — siehe SSO und Active Directory.

Eine Zuweisung kann mehrere Tenants auf einmal für dieselbe Rolle wählen. Wird ein Team gelöscht, verlieren seine Mitglieder die Rechte, die sie nur über dieses Team hatten. Eine Rolle, die noch in einer Zuweisung steckt, lässt sich nicht löschen — Vesana nennt die Zahl der Zuweisungen.

Audit-Trail

Permission-Änderungen sind im Audit-Log mit Diff sichtbar. „Wer hat dem User X welche Permission gegeben?" — im Audit-Log nach dem betroffenen Ziel filtern.

Permission-Engineering — Tipps

  • Wenig ist mehr — überlege pro Rolle, was wirklich gebraucht wird, und lass den Rest weg
  • *.view von *.create/*.edit/*.delete trennen — viele User brauchen nur Lesen
  • AI-Permissions selektiv — ai.query für wenige Pilot-User aktivieren, dann ausweiten
  • audit_log.view_tenant / system_log.view_tenant nur für Audit-Funktion — viel Detail, nicht für jeden interessant
  • .view_global-Stufen sparsam vergeben — sie zeigen tenant-übergreifende und instanzweite Einträge

Anschluss