Berechtigungskonzept für interne Tools richtig planen

Ein Berechtigungskonzept für interne Tools ist nötig, sobald nicht alle Mitarbeitenden dieselben Daten sehen oder dieselben Vorgänge verändern dürfen. Es sollte Geschäftsaufgaben abbilden, nicht Organigramme oder technische Einzelheiten. Für viele mittelständische Anwendungen reichen wenige klar beschriebene Rollen; komplizierte Rechte auf Feldebene sind erst dann sinnvoll, wenn ein konkretes Risiko oder ein verbindlicher Prozess sie erfordert.

Die entscheidende Frage: Was darf bei falschem Zugriff passieren?

Der Ausgangspunkt ist nicht die Auswahl einer technischen Rechteverwaltung, sondern eine fachliche Risikofrage: Welche Folgen hätte es, wenn jemand Daten einsieht, ändert, löscht oder einen Vorgang verbindlich auslöst? Davon hängt ab, welche Zugriffe getrennt werden müssen. Bei einer einfachen internen Wissensdatenbank genügt häufig ein Unterschied zwischen Lesen und Bearbeiten. Bei einem Tool für Rechnungen, Vertragsdaten, Personalvorgänge oder Freigaben sind die Folgen einer falschen Änderung deutlich größer.

Besonders genau sollten Teams auf irreversible oder außenwirksame Aktionen schauen. Dazu zählen etwa das Versenden von E-Mails im Namen des Unternehmens, der Export umfangreicher Datensätze, das Anpassen von Bank- oder Stammdaten sowie das Auslösen einer Rechnung oder Bestellung. Solche Aktionen müssen nicht zwingend nur einer Person vorbehalten sein. Sie sollten aber bewusst einer Rolle zugeordnet, nachvollziehbar gestaltet und bei Bedarf durch eine zusätzliche Freigabe abgesichert werden.

Nicht jede Information muss für jede Rolle verborgen werden. Ein überzogenes Berechtigungskonzept erzeugt Rückfragen, Umgehungsprozesse und administrativen Aufwand. Wenn Mitarbeitende regelmäßig Zugriffe beantragen müssen, um ihre Kernaufgabe zu erledigen, ist meist entweder die Rollenabgrenzung falsch oder der Arbeitsprozess noch nicht sauber beschrieben. Gute Zugriffskontrolle reduziert unnötige Möglichkeiten, ohne die tägliche Arbeit künstlich zu verlangsamen.

Rollen vor Einzelrechten: ein belastbares Grundmodell

Für die meisten internen Anwendungen ist ein rollenbasiertes Modell der beste Start. Statt einzelnen Personen immer neue Sonderrechte zuzuweisen, erhalten sie eine Rolle mit einem nachvollziehbaren Aufgabenpaket. Typische Rollen können Sachbearbeitung, Teamleitung, Fachadministration und technische Administration sein. Die Namen sind weniger wichtig als die fachliche Trennung: Wer erfasst, wer prüft, wer entscheidet und wer das System betreibt?

• Lesen: Informationen und Vorgänge ansehen, ohne ihren Zustand zu verändern.
• Bearbeiten: Daten erfassen oder innerhalb eines zugewiesenen Arbeitsbereichs ändern.
• Freigeben: fachlich verbindliche Entscheidungen treffen oder Statuswechsel auslösen.
• Administrieren: Rollen verwalten, Grundeinstellungen ändern oder Schnittstellen konfigurieren.
• Prüfen: Vorgänge und Historien einsehen, ohne selbst operative Änderungen vorzunehmen.

Diese Rechtearten sind ein Gesprächsgerüst, keine universelle Vorlage. Ein Team kann beispielsweise Vorgänge bearbeiten dürfen, aber keine abgeschlossenen Fälle nachträglich verändern. Eine Teamleitung kann Freigaben erteilen, ohne technische Einstellungen zu sehen. Die technische Administration benötigt Zugriff auf den Betrieb, muss aber nicht zwangsläufig alle fachlichen Inhalte lesen können. Gerade diese Trennung verhindert, dass weitreichende Rechte nur aus Bequemlichkeit vergeben werden.

Warum personenbezogene Ausnahmen sparsam bleiben sollten

Einzelrechte wirken zunächst praktisch: Eine erfahrene Person bekommt schnell eine zusätzliche Funktion. Mit der Zeit wird jedoch unklar, warum genau sie diese Berechtigung hat, wer sie vertreten kann und ob sie nach einem Rollenwechsel noch angemessen ist. Ausnahmen sind sinnvoll, wenn sie zeitlich begrenzt, begründet und überprüfbar sind. Dauerhafte Ausnahmen sind oft ein Hinweis darauf, dass eine reguläre Rolle fehlt oder eine Aufgabe organisatorisch nicht eindeutig zugeordnet ist.

Praxisbeispiel: internes Rechnungsprogramm

Stellen wir uns ein internes Rechnungsprogramm vor, das Artikel verwaltet, PDFs erzeugt und Rechnungen per E-Mail versendet. Die Sachbearbeitung erstellt Rechnungsentwürfe und pflegt Positionen. Eine verantwortliche Rolle prüft und gibt den Versand frei. Die Buchhaltung kann versendete Rechnungen, Nummernkreise und Zahlungsinformationen einsehen, benötigt aber nicht zwingend Zugriff auf die gesamte Artikelpflege. Die technische Administration betreut Nutzerkonten und Schnittstellen, ohne Rechnungen im Tagesgeschäft zu bearbeiten.

Entscheidend ist hier nicht, jede mögliche Schaltfläche separat abzusichern. Wichtiger sind die fachlichen Zustandswechsel: Entwurf erstellen, prüfen, freigeben, versenden, stornieren oder korrigieren. Für jeden Wechsel sollte klar sein, welche Rolle ihn ausführen darf und welche Informationen dazu festgehalten werden müssen. So wird aus einer technischen Rechtefrage ein verständlicher und prüfbarer Geschäftsprozess.

Wenn in der Praxis dieselbe kleine Gruppe Entwürfe erstellt und freigibt, kann eine getrennte Freigaberolle unnötig sein. Dann sollte das Unternehmen die Entscheidung bewusst dokumentieren, statt eine formale Trennung ohne tatsächlichen Nutzen einzubauen. Wächst das Team später oder steigen die Risiken, lässt sich der Prozess gezielt erweitern. Das ist meist besser, als von Anfang an einen komplizierten Freigabemechanismus für seltene Sonderfälle zu bauen.

Was vor der technischen Umsetzung geklärt sein muss

1. Schreiben Sie die geschützten Objekte auf: zum Beispiel Kundenakten, Rechnungen, Dokumente, Einstellungen oder Exportdateien.
2. Benennen Sie die kritischen Aktionen: ansehen, ändern, löschen, exportieren, freigeben, versenden und administrieren.
3. Ordnen Sie jede Aktion einer fachlichen Rolle zu. Vermeiden Sie dabei zunächst Namen einzelner Mitarbeitender.
4. Definieren Sie die wenigen Fälle, in denen eine zweite Prüfung, eine zeitliche Begrenzung oder eine Protokollierung erforderlich ist.
5. Klären Sie, wer Rollen vergibt, wer Änderungen an Berechtigungen veranlasst und wie Austritte oder Aufgabenwechsel behandelt werden.
6. Prüfen Sie das Modell mit realistischen Alltagsszenarien, einschließlich Vertretung, Urlaubsfall und Fehlerkorrektur.

Diese Vorarbeit lässt sich gut in einem Workshop mit Fachverantwortlichen, Betrieb und gegebenenfalls IT bündeln. Das Ergebnis sollte keine abstrakte Sicherheitsrichtlinie sein, sondern eine verständliche Matrix aus Rollen, Objekten und erlaubten Aktionen. Sie ist zugleich eine belastbare Grundlage für die Entwicklung, für Tests und für spätere Erweiterungen. Werden Rechte erst während der Umsetzung nebenbei entschieden, entstehen häufig widersprüchliche Regeln und schwer nachvollziehbare Sonderfälle.

Typische Fehlentscheidungen und ihre Folgen

Ein häufiger Fehler ist die Rolle „Admin für alles“. Sie wird vergeben, weil sie kurzfristig Probleme löst, führt aber dazu, dass operative, fachliche und technische Verantwortung verschwimmen. Ein anderer Fehler besteht darin, Berechtigungen nur nach Abteilungen zu vergeben. Zwei Personen derselben Abteilung können unterschiedliche Aufgaben und damit unterschiedliche Zugriffsbedarfe haben. Abteilungsnamen eignen sich daher höchstens als Hinweis, nicht als vollständiges Modell.

Ebenso problematisch ist es, Zugriffsrechte mit Sichtbarkeit zu verwechseln. Nicht jede Rolle, die einen Vorgang sehen darf, soll ihn auch verändern können. Umgekehrt kann eine Person Daten bearbeiten müssen, ohne alle historischen oder angrenzenden Informationen zu benötigen. Diese Unterscheidung wird besonders wichtig, wenn mehrere Teams in einem gemeinsamen Tool arbeiten und ihre Arbeitsschritte aufeinander aufbauen.

Technisch sollte das Konzept außerdem nicht allein in der Benutzeroberfläche stecken. Wenn eine Funktion nur ausgeblendet wird, aber ein dahinterliegender Zugriff weiterhin möglich ist, entspricht die Umsetzung nicht der fachlichen Regel. Rechte gehören deshalb an die Stellen geprüft, an denen das System tatsächlich Daten liefert oder Änderungen verarbeitet. Bei Integrationen ist zusätzlich zu klären, welche Systemidentität welche Aktionen ausführen darf.

Wann der richtige Zeitpunkt für mehr Detailtiefe ist

Starten Sie mit einem einfachen Modell, wenn Rollen stabil sind, der Kreis der Nutzenden überschaubar bleibt und nur wenige kritische Aktionen existieren. Mehr Detailtiefe lohnt sich, wenn Teams mandantenübergreifend arbeiten, verschiedene Kundengruppen strikt getrennt sein müssen, sensible Dokumente verarbeitet werden oder viele Ausnahmen auftreten. Auch bei einer geplanten Anbindung weiterer Systeme sollte geprüft werden, ob die bisherigen Rollen für automatisierte Zugriffe noch ausreichen.

Ein Berechtigungskonzept ist damit kein einmaliges Technikdokument. Es ist eine fachliche Vereinbarung darüber, wer Verantwortung übernimmt und wie das Tool diese Verantwortung unterstützt. OnLouis kann diese Klärung mit Prozessanalyse und einer wartbaren technischen Umsetzung verbinden, damit Rechte weder zum Sicherheitsrisiko noch zur täglichen Arbeitsbremse werden.