Wer hat Zugriff auf was: Benutzer und Berechtigungen in einer Geschäftsanwendung

„Wir teilen uns einfach das Passwort“

Ein gemeinsamer Account ist keine bewusste Entscheidung, sondern das, was übrig bleibt, wenn das Tool nichts anderes bietet. Er funktioniert einige Monate lang problemlos – doch dann kommt die Rechnung, und zwar immer zum ungünstigsten Zeitpunkt.

Drei mechanische Folgen: Um einer einzelnen Person den Zugriff zu entziehen, müssen Sie das Passwort ALLER ändern – und so das gesamte Team am Tag des Ausscheidens neu einweisen. Genau dann, wenn Sie am wenigsten Lust haben, sich darum zu kümmern. Zudem kann niemand mehr beantworten: „Wer hat diese Zeile geändert?“, denn aus Sicht der Anwendung sind alle dieselbe Person. Schließlich lässt sich kein eingeschränkter Zugriff gewähren: Wer nur eine Zahl ablesen möchte, erhält exakt dieselben Rechte wie die Person, die Rechnungen stellt.

Es geht also nicht um Sicherheit im spektakulären Sinne – niemand greift eine Anwendung mit fünfzehn Nutzern an. Es geht um Irreversibilität: Ein gemeinsamer Account lässt sich nicht entwirren, sondern nur ersetzen – und je länger Sie warten, desto aufwendiger wird dieser Ersatz.

• Zugriff für eine Person entziehen = Passwort aller ändern.
• Keine Antwort auf „Wer hat das gemacht?“: ein Account, eine Identität.
• Kein eingeschränkter Lesezugriff: Lesen und Bearbeiten sind stets mit denselben Rechten verbunden.

Drei Rollen – und die genaue Grenze zwischen ihnen

Sobald die Anwendung zur Anmeldung auffordert, enthält sie echte, voneinander getrennte Accounts und drei Rollen. Die geringe Anzahl ist bewusst gewählt: Ein Berechtigungssystem, das man auf einen Blick nicht versteht, ist ein System, das man falsch konfiguriert.

Der Administrator darf alles und verwaltet allein die Accounts: Er erstellt sie, deaktiviert sie und setzt Passwörter zurück. Der Nutzer arbeitet innerhalb der Anwendung – er erstellt, bearbeitet und löscht Daten – sieht aber niemals die Accountverwaltung. Die Rolle „Nur lesen“ dient ausschließlich der Ansicht: Sie navigiert frei durch alle Bereiche, öffnet Datensätze, liest Dashboards – und darf nichts schreiben.

Entscheidend ist nicht die Liste selbst, sondern der Punkt, an dem die Ablehnung erfolgt. Bei der Rolle „Nur lesen“ ist die Sperrung kein versteckter Button auf dem Bildschirm: Jede Schreibanfrage wird bereits durch den Middleware abgelehnt, bevor sie die Route erreicht – mit dem HTTP-Statuscode 403. Ein ausgeblendeter Button lässt sich über Tastatur oder Entwicklertools umgehen; eine vorgelagerte Ablehnung nicht. Das ist der Unterschied zwischen einer Oberfläche, die lediglich vorschlägt – und einer Anwendung, die wirklich hält.

Die Rolle wird im signierten Session-Cookie übertragen, sodass diese Prüfung ohne Datenbankabfrage bei jeder Anfrage möglich ist. Ein Besucher ohne Session gelangt zu nichts: Seiten leiten ihn zur Login-Seite weiter – unter Beibehaltung der Ziel-URL – und API-Aufrufe erhalten den Statuscode 401.

• Administrator – volle Rechte plus Accountverwaltung.
• Nutzer – erstellt, bearbeitet und löscht Daten; kein Zugriff auf Accounts.
• Nur lesen – navigiert und liest; jede Schreibanfrage wird mit 403 vor der Route abgelehnt.
• Keine Session – 401 bei API-Aufrufen, Weiterleitung zur Login-Seite bei Seitenaufrufen.

Einen Zugang eröffnen: Benutzername, Rolle, temporäres Passwort

Die Erstellung eines Accounts erfordert drei Angaben – und keine davon ist eine E-Mail-Adresse. Der Administrator gibt einen Benutzernamen ein (2 bis 31 Zeichen: Buchstaben, Ziffern, Punkt, Bindestrich, Unterstrich), wählt die Rolle aus – und die Anwendung generiert selbstständig ein temporäres Passwort.

Dieses Passwort wird nur einmal angezeigt – genau in diesem Moment. Danach ist es nicht mehr einsehbar – weder in der Accountliste noch sonstwo: Nur der Hash wird gespeichert. Falls es verloren geht, bevor es weitergegeben wurde, generiert der Administrator binnen zehn Sekunden ein neues. Der Account ist zudem als „Passwortänderung erforderlich“ markiert: Bei der ersten Anmeldung muss die betreffende Person ihr eigenes Passwort wählen – der Administrator kennt also nie das Passwort seiner Kolleginnen und Kollegen.

Es wird keine E-Mail versandt – und das ist wichtig zu wissen, bevor Sie Ihre Prozesse darauf ausrichten: Die Anwendung verfügt über keinen E-Mail-Dienst. Der Administrator muss Benutzernamen und temporäres Passwort eigenständig übermitteln. Die praktische Konsequenz ist sogar ärgerlicher als das Fehlen der E-Mail selbst: Es gibt keine Selbstbedienungsoption „Passwort vergessen“. Wer sein Passwort verliert, muss sich an den Administrator wenden – der setzt es zurück.

Der allererste Account wird zusammen mit der Anwendung angelegt: Benutzername „admin“, Passwort „admin“ – und dieselbe obligatorische Änderung bei der ersten Anmeldung. Das ist ein Startpasswort, kein echtes Passwort – und die Anwendung lässt Sie nicht dabei belassen.

• Benutzername + Rolle: das ist alles, was der Administrator eingibt.
• Temporäres Passwort wird von der Anwendung generiert und NUR EINMAL angezeigt.
• Obligatorische Änderung bei der ersten Anmeldung – danach kennt der Administrator das Passwort nicht mehr.
• Keine E-Mails: Übermittlung und Zurücksetzen erfolgen ausschließlich über den Administrator.

Einen Zugang sperren – ohne Löcher in die Historie zu reißen

Ein Account wird nicht gelöscht, sondern deaktiviert – und kann jederzeit wieder aktiviert werden. Das ist kein technischer Kompromiss, sondern dieselbe Abwägung wie bei der Papierkorb-Funktion für Daten: Ein endgültig gelöschter Datensatz nimmt alles mit, was daran hängt – und Sie bemerken es erst Monate später, wenn Sie nach etwas suchen, das nicht mehr existiert.

Im Code sind zwei explizite Verbote verankert – sie verhindern, dass Sie sich selbst aussperren. Sie können Ihren eigenen Account nicht deaktivieren – das wäre zu leicht bei der Aufräumarbeit in einer Liste versehentlich passiert. Und Sie können den letzten aktiven Administrator nicht deaktivieren: Eine Anwendung ohne Administrator ist eine Anwendung, bei der niemand mehr einen Zugang öffnen kann – auch nicht für sich selbst. Die Ablehnung ist klar formuliert, sie führt nicht einfach zum Fehler.

Ein Ausscheiden wird daher mit einem einzigen Handgriff behandelt – ohne die Passwörter anderer zu beeinträchtigen und ohne Spuren zu löschen. Ein Ersatz benötigt zwei Schritte: deaktivieren, dann neu anlegen.

• Reversible Deaktivierung statt Löschung.
• Eigenen Account kann man nicht deaktivieren.
• Letzten aktiven Administrator kann man nicht deaktivieren.
• Passwortrücksetzung durch den Administrator jederzeit möglich.

Was die Anwendung nicht leistet – und was Sie besser vorher wissen sollten

Die Berechtigungen gelten global für die gesamte Anwendung. Ein Account trägt eine Rolle – und diese Rolle ist weder einer Entität, noch einem Abschnitt, noch einem Feld zugeordnet. Es gibt also keinerlei Möglichkeit, Ausdrücke wie „Dieser Verkäufer sieht nur seine eigenen Kunden“, „Diese Person darf auf Einsätze zugreifen, aber nicht auf die Rechnungsstellung“ oder „Dieses Feld ist für Nicht-Führungskräfte ausgeblendet“ abzubilden. Drei Rollen decken die Frage „Ansehen oder Bearbeiten?“ gut ab – aber die Frage „Welcher Teil?“ gar nicht.

Die Anwendung protokolliert, WANN sich ein Datensatz geändert hat – niemals, WER ihn geändert hat. Jeder Datensatz enthält automatisch Datum der Erstellung und Datum der letzten Änderung, aber keine Spalte speichert den Autor. Getrennte Accounts beantworten daher die Frage „Wer darf hereinkommen?“, nicht jedoch „Wer hat diese Zeile geschrieben?“. Das sind zwei unterschiedliche Fragen – und nur die erste wird behandelt. Dies ist die Grenze, die am leichtesten mit einer tatsächlich vorhandenen Funktion verwechselt wird, denn benannte Accounts erwecken den Eindruck einer vollständigen Nachvollziehbarkeit.

Die Anmeldung erfolgt ausschließlich über Benutzername und Passwort – nichts anderes. Kein Einloggen über Google- oder Microsoft-Konto, keine Unternehmens-SSO-Lösung, kein Zwei-Faktor-Verfahren. Für ein Team, das seine Identitäten bereits anderswo verwaltet, bedeutet das eine weitere Liste von Accounts, die gepflegt werden muss.

Diese vier Grenzen sind keine Versäumnisse, die man umgehen müsste: Sie definieren präzise den Umfang dessen, was geliefert wird – und sie schriftlich festzuhalten ist sinnvoller, als sie erst im Betrieb zu entdecken. Sie alle haben dieselbe Lösungsmöglichkeit – und diese ist der eigentliche Grund für das Produkt: Der Quellcode der Anwendung gehört Ihnen. Es handelt sich um ein Standard-Next.js- und Prisma-Projekt, das Sie als ZIP exportieren oder in Ihr eigenes Repository pushen können. Eine Autorenspalte hinzuzufügen, die Daten nach Teams zu trennen oder Unternehmensauthentifizierung einzubauen – das ist ganz normale Entwicklungsaufgabe auf Code, den Sie besitzen und den Ihnen kein Anbieter verweigern kann. Und wenn die Trennung strukturell für Ihr Geschäft entscheidend ist, beschreiben Sie sie gleich zu Beginn – denn Ihr Text legt die Entitäten und ihre Beziehungen fest.

• Globale Berechtigungen: keine Trennung nach Entität, Abschnitt oder Feld.
• Änderungsdatum wird protokolliert, Autor nicht.
• Nur Benutzername und Passwort: keine SSO-, keine Drittanbieter-Login- und keine Zwei-Faktor-Option.
• Gemeinsame Lösung: Der Code gehört Ihnen – diese Erweiterungen sind Standardentwicklung.