Jeder sieht genau das, was er sehen soll, auch die KI.
Feingranulare Berechtigungen, frei definierbare Rollen, Rechte je Marke und objektbezogener Zugriffsschutz auf jeder einzelnen Operation, durchgesetzt in Oberfläche, API, Automation und KI nach exakt denselben Regeln. Dazu MFA, SSO und ein Audit-Trail, der jede Rechteänderung festhält.
Rollen, Rechte und SSO im laufenden System. Im Grundpaket enthalten, nicht zubuchbar.
Auf einen Blick
- Was es ist
- Objektbezogene Rechte, Mehr-Faktor-Anmeldung, OIDC und OAuth2
- Zuordnung
- Im Grundpaket enthalten
- Buchbar
- nicht einzeln. Jede Instanz bringt sie mit
- Für wen
- alle Betriebe, unabhängig davon, ob der Zusatz Handel gebucht ist
- Betrieb
- Auf dem eigenen Server des Kunden oder von uns in Deutschland betrieben. Eine isolierte Instanz je Kunde, eigene Datenbank.
Kommt dir das bekannt vor?
Admin für alle
Weil das Rechtesystem des alten Tools zu grob ist, haben am Ende alle Vollzugriff: die Praktikantin sieht die Deckungsbeiträge, der Freelancer die Gehälter. Nicht aus Absicht, aus Bequemlichkeit.
Rechte-Wildwuchs über fünf Tools
Je System ein eigenes Rollenmodell, ein eigener Admin, ein eigenes Offboarding. Wer nach dem Ausscheiden eines Mitarbeiters wirklich alle Zugänge gesperrt hat, weiß niemand sicher.
Die API als Hintertür
Die Oberfläche prüft Rechte, der API-Schlüssel darf alles. Genau die Lücke, die bei einer Prüfung als Erstes auffällt.
Im Fundament
Was Rollen, Rechte und SSO leistet
Die wichtigsten 6 von 8 Bereichen. Die vollständige Liste steht darunter zum Aufklappen.
Feingranulare Berechtigungen: auf Aktions-Ebene
Rechte sind bei Octibiz keine groben Schalter ("Modul an/aus"), sondern präzise Berechtigungen je Objekt und Aktion: Angebote sehen ist etwas anderes als Angebote anlegen, ändern oder löschen. Aus diesen Bausteinen setzt du exakt die Sicht zusammen, die eine Funktion im Unternehmen braucht.
Rollen frei definierbar: Systemrollen mitgeliefert
Octibiz liefert praxiserprobte Systemrollen mit (z. B. Geschäftsführung, Projektleitung, Buchhaltung, Support), und du baust beliebige eigene: Rechte bündeln, benennen, zuweisen, fertig. Systemrollen sind gegen versehentliches Zerkonfigurieren geschützt; gegen Rechte-Selbst-Erhöhung ist das System abgesichert.
Rechte je Marke: das Zuordnungs-Modell
Eine Person kann mehrere Rollen haben, jede davon auf eine Marke begrenzt oder markenübergreifend. Rechte addieren sich über alle Zuordnungen: Buchhaltung für Marke A plus Support für alle Marken, präzise abbildbar, jederzeit änderbar. So trennst du Sichten in Gruppen- und Multi-Brand-Strukturen, ohne Nutzer doppelt anzulegen.
Objektbezogener Zugriffsschutz: auf jeder einzelnen Operation
Rechte enden nicht bei "darf das Modul sehen": Jede einzelne Operation prüft zusätzlich am konkreten Datensatz, ob dieser Nutzer genau dieses Objekt sehen oder ändern darf: Marke, Kontext, Vertraulichkeit. Das direkte Aufrufen fremder Datensätze über geratene Adressen scheitert kontrolliert.
Ein Regelwerk für Mensch, Automation und KI
Automationen und KI sind in Octibiz eigene Akteure mit eigener Identität und Rolle, und damit denselben Grenzen wie jeder Mitarbeiter. Es gibt keinen Sonderpfad: Was eine Regel oder die KI tut, hätte auch der zugehörige Nutzer tun dürfen, und alles steht im Audit-Trail, nach Akteur-Typ unterscheidbar.
SSO & Provisionierung: Anschluss an deine Identitäts-Welt
Dein Team meldet sich per Single Sign-on an, über den offenen OIDC/OAuth2-Standard mit Google, Microsoft oder deinem eigenen Identitätsanbieter. Neue Teammitglieder werden anhand erlaubter Domains automatisch angelegt und starten ohne Rechte, bis ein Admin Rollen zuweist. Die automatische Nutzerbereitstellung per SCIM ist in Arbeit: bis dahin legst du Konten manuell oder per API an. Den Anschluss an deinen Identitätsanbieter richten wir gemeinsam mit dir ein.
Alle Funktionen im Überblick
30 Einzelfunktionen, nach Bereichen sortiert. Aufklappen, was dich interessiert.
Berechtigungen (3 Funktionen)
- Feingranulare Rechte
- Berechtigung je Objekt und Aktion, einheitlich über alle Module.
- Automatische Erweiterung
- Neue Module/Plugins registrieren ihre Rechte selbst.
- Wirkung überall
- Listen, Details, Suche, Berichte, Exporte, konsistent gefiltert.
Rollen (4 Funktionen)
- Systemrollen
- Praxiserprobte Startrollen, geschützt gegen Löschen.
- Eigene Rollen
- Frei definierbar über die Rollen-Matrix.
- Eskalations-Schutz
- Rechtevergabe nur im Rahmen eigener Rechte.
- Rollen-Ereignisse
- Änderungen an Rollen/Rechten lösen auditierte Ereignisse aus (Automation-fähig).
Marken-Zuordnung (3 Funktionen)
- Nutzer × Rolle × Marke
- Mehrere Zuordnungen je Person, additiv.
- "Alle Marken"-Zuordnung
- Für Geschäftsführung/zentrale Funktionen.
- Befristung
- Zuordnungen mit Gültigkeit von/bis.
Objekt-Schutz (3 Funktionen)
- Prüfung am Einzelobjekt
- Jede Operation prüft das konkrete Objekt (IDOR-sicher).
- Vertrauliche Vorgänge
- Explizite Zugriffsliste über Rollen/Marken hinaus; Suche respektiert sie.
- Rechte-gefilterte Suche
- Nur berechtigte Treffer, systemweit.
Ein Regelwerk für alle Akteure (3 Funktionen)
- UI = API = Automation = KI
- Identische Prüfungen auf jedem Zugriffspfad.
- KI-Identität mit Rolle
- KI-Rechte wie Mitarbeiter-Rechte vergeben und begrenzt.
- Audit nach Akteur-Typ
- Mensch/Automation/KI je Änderung unterscheidbar.
Anmeldung & Konto (7 Funktionen)
- MFA (TOTP + Recovery)
- Optional aktivierbar, empfohlen für sensible Rollen.
- Kurzlebige Tokens + Refresh
- Moderne Token-Sicherheit für alle Clients.
- Rate-Limit & Konto-Sperre
- Schutz vor Brute-Force.
- Nutzer-Lebenszyklus
- Eingeladen → aktiv → gesperrt; Start ohne Rechte.
- Einladungs-Flow
- Sichere Einladung neuer Teammitglieder.
- Passwort-Fallback
- Moderne Hash-Verfahren, je Nutzer aktivierbar.
- Sitzungs-Verwaltung
- Aktive Sitzungen einsehen/beenden.
SSO & Provisionierung (4 Funktionen)
- OIDC/OAuth2-SSO
- Google, Microsoft, eigener Identitätsanbieter.
- Domain-Allowlist
- Automatische Anlage nur für erlaubte Domains.
- Übernahme-Schutz
- Abgesicherte Verknüpfung SSO ↔ bestehendes Konto.
- SCIM-Provisionierung (in Arbeit)
- Automatisches On-/Offboarding aus dem Verzeichnis ist in Arbeit; heute per API oder von Hand.
Bereiche (3 Funktionen)
- Drei getrennte Bereiche
- Internes Team, Kundenportal, Systemverwaltung, eigene Anmeldekontexte.
- Portal-Rechte separat
- Kundenrechte je Bereich/Aktion (siehe Kundenportal).
- Verwaltung per API
- Nutzer, Rollen, Zuordnungen als API-Ressourcen, skriptbar.
Was darauf steht
Welche Module Rollen, Rechte und SSO tragen
Diese Fähigkeit arbeitet nicht für sich, sondern in jedem Modul, das du benutzt, ohne sie nachzubauen.
Multi-Brand
Das Zuordnungs-Modell trägt die Marken-Abgrenzung. Rechte je Marke sind kein Aufsatz, sondern Kern des Rechtemodells.
Audit & DSGVO
Jede Rechteänderung, jede Anmeldung und jede Änderung durch jeden Akteur landet im Audit-Trail mit Vorher/Nachher.
KI & MCP
Die KI-Identität bekommt Rolle und Marken-Scope aus diesem Rechtesystem, inklusive Guardrails für schreibende Aktionen.
API
Tokens erben exakt die Rechte ihres Nutzers; objektbezogene Prüfungen greifen auf jeder Operation.
Mehr dazuKundenportal
Kunden leben in einem eigenen Anmelde-Bereich mit eigenem Rechte-Modell je Bereich und Aktion, vollständig getrennt vom internen Team.
Personal/HR
Ein-/Austritte aus dem Personalprozess münden in den Nutzer-Lebenszyklus. Offboarding heißt: ein Konto sperren, fertig.
Mehr dazuKlare Kante
Wofür du etwas anderes brauchst
Die Grenzen des Fundaments, bevor du sie im Betrieb findest.
Rechte-Modell ist rollenbasiert, nicht attributbasiert
Rollen × Marken plus objektbezogene Prüfungen und Vertraulichkeits-Listen decken die Praxis ab; ein frei programmierbares Policy-Regelwerk (ABAC) ist bewusst nicht das Ziel. Verständlichkeit und Auditierbarkeit gehen vor.
"Anmelden als" (Impersonation)
Ein vollständig auditiertes "Admin meldet sich als Nutzer an" für Support-Zwecke ist als Ausbau vorgesehen. Heute hilft die Rechte-Matrix plus Audit-Trail bei der Diagnose.
SSO für Portal-Kunden
SSO gilt für dein internes Team; Kundenzugänge im Portal laufen bewusst über Passwort/Magic-Link (siehe Kundenportal), Anbindung von Kunden-Identitätsanbietern ist eine spätere Ausbaustufe.
SCIM-Provisionierung ist in Arbeit
Die automatische Nutzerbereitstellung aus deinem Verzeichnis fehlt noch. Bis dahin legst du Konten manuell oder per API an; die SSO-Anmeldung mit automatischer Nutzer-Anlage über erlaubte Domains funktioniert heute schon.
Häufige Fragen zu Rollen, Rechte und SSO
Wie feingranular sind die Rechte wirklich?
Berechtigungen existieren je Objekt und Aktion (z. B. Angebote sehen ≠ anlegen ≠ ändern ≠ löschen) und zusätzlich prüft jede Operation am konkreten Datensatz, ob genau dieses Objekt zugänglich ist, inklusive Marken-Kontext und Vertraulichkeits-Listen. Das Schema dahinter liegt offen: Jede Berechtigung folgt dem Muster modul.objekt.aktion.
Können wir eigene Rollen bauen, oder sind wir an Vorgaben gebunden?
Beides: Mitgelieferte Systemrollen decken die üblichen Funktionen ab und sind gegen Zerkonfigurieren geschützt; daneben definierst du beliebige eigene Rollen über die Rechte-Matrix. Rechtevergabe ist gegen Selbst-Eskalation abgesichert. Niemand verteilt Rechte, die er nicht selbst hat.
Wie schnell ist ein ausscheidender Mitarbeiter wirklich überall raus?
Ein Klick: Konto sperren. Da CRM, Projekte, Zeiten, Faktura, Dateien und Portal ein System sind, gibt es keine vergessenen Einzel-Zugänge. Die automatische Sperrung aus deinem Verzeichnis per SCIM ist in Arbeit; bis dahin bleibt es bei diesem einen Klick oder einem API-Aufruf. Bestehende Sitzungen laufen über kurzlebige Tokens ohnehin binnen Minuten aus.
Welche SSO-Anbieter werden unterstützt?
SSO läuft über den offenen OIDC/OAuth2-Standard und funktioniert damit u. a. mit Google Workspace, Microsoft Entra ID und eigenen Identitätsanbietern. SSO und die Passwort-Anmeldung mit MFA gehören zur Plattform-Basis und stecken damit im Grundpaket, nichts davon ist eine eigene Stufe. Die automatische Nutzerbereitstellung per SCIM ist in Arbeit; bis dahin legst du Konten manuell oder per API an. Den ersten Lauf gegen deinen Identitätsanbieter machen wir gemeinsam mit dir (siehe Preise).
Gelten die Rechte auch für API-Zugriffe, Automationen und die KI?
Ja, ausnahmslos. Das ist ein Architektur-Prinzip, kein Feature: Alle Zugriffspfade laufen durch dieselbe Rechteprüfung in der API. Ein API-Token kann nie mehr als sein Nutzer, Automationen laufen unter geprüften Rechten, und die KI hat eine eigene Identität mit eigener Rolle (siehe KI und MCP).
Ist MFA Pflicht?
MFA (Authenticator-App + Wiederherstellungs-Codes) ist optional aktivierbar und für sensible Rollen empfohlen; bei SSO greift zusätzlich die MFA-Politik deines Identitätsanbieters (z. B. Google Workspace). So bleibt die Hürde für dein Team angemessen, ohne Sicherheit zu opfern.
Wie behalten wir den Überblick, wer was darf?
Über die Rollen-Matrix (Rolle × Berechtigung, nach Modulen gruppiert) und die Nutzer-Detailsicht mit allen Marken-Zuordnungen. Jede Änderung an Rollen und Zuordnungen ist auditiert und kann per Automation gemeldet werden. Rechte-Reviews lassen sich zudem per API skripten.
Ein Rechtesystem, das UI, API, Automation und KI gleich behandelt, ist der Unterschied zwischen "Berechtigungskonzept auf Papier" und gelebter Zugriffskontrolle. Überzeug dich im Live-System.
Dreißig Minuten am laufenden System, mit Prüfprotokoll statt Folien. Was dich an diesem Dienst interessiert, schauen wir uns zuerst an.
