Zugriffe und Berechtigungen für interne Tools

Ein internes Tool wirkt schnell privat: Es hat eine Anmeldung und nur Kollegen kennen die Adresse. Dieses Gefühl ersetzt kein Berechtigungsmodell. Die Anmeldung stellt fest, welches Konto zugreift. Die Autorisierung entscheidet, was dieses Konto lesen, ändern, freigeben, exportieren oder löschen darf. Ein hilfreicher Review betrachtet beides.

Der Ausgangspunkt ist normale Geschäftssprache. Wer soll welche Datensätze sehen? Wer darf sie bearbeiten? Wer kann anderen Zugang geben? Was passiert beim Teamwechsel oder beim Ausscheiden? Wenn diese Fragen offen sind, löst eine zusätzliche Softwarebibliothek das eigentliche Problem nicht. Zuerst muss das gewünschte Verhalten feststehen.

Identität und Berechtigung unterscheiden

Authentifizierung beantwortet etwa: „Welches Konto stellt diese Anfrage?“ Dafür kommen Passwort, Google-Anmeldung oder ein Identitätsanbieter infrage. Autorisierung beantwortet: „Darf dieses Konto diese Handlung an diesem Datensatz ausführen?“ Eine erfolgreiche Anmeldung darf nicht automatisch Zugriff auf alle Daten bedeuten.

Ein Dashboard kann den Namen eines Nutzers korrekt anzeigen und trotzdem sämtliche Kundendaten von einer Schnittstelle abrufen. Werden diese erst im Browser gefiltert, sind sie bereits dort angekommen. Die wirksame Prüfung muss an der Stelle stattfinden, an der der Zugriff gewährt wird – etwa bei Serverabfragen und beim Ausliefern von Dateien.

Manche Anwendungen haben ein eigenes Backend. Andere greifen direkt auf einen verwalteten Datenbankdienst zu. In beiden Fällen braucht es eine wirksame Kontrollgrenze. Dazu können korrekt konfigurierte Zeilenrichtlinien gehören. Dass eine Schutzfunktion eingeschaltet ist, beweist noch nicht, dass ihre Regeln zum gewünschten Verhalten passen.

Eine kleine Berechtigungsmatrix erstellen

Beschreibe Handlungen und Datensätze statt pauschaler Begriffe wie „Vollzugriff“. Bei einem Ausgabentool könnten die Zeilen Antrag erstellen, eigenen Antrag lesen, Teamantrag lesen, Antrag genehmigen, genehmigten Betrag ändern, Daten exportieren und Nutzer einladen heißen. Als Spalten dienen Antragsteller, Teamleitung und Administration.

Kennzeichne jede Kombination als erlaubt oder untersagt und ergänze Bedingungen. Eine Teamleitung darf vielleicht nur Anträge der eigenen Gruppe genehmigen. Antragsteller dürfen nur Entwürfe ändern. Ein Administrator verwaltet Mitglieder, besitzt aber nicht automatisch die fachliche Freigabeberechtigung. Solche Unterschiede lassen sich in einer Tabelle gut besprechen.

Vergiss technische Akteure nicht. Ein regelmäßiger Import, ein Webhook oder ein Integrationskonto kann mehr erreichen als ein normaler Nutzer. Kläre notwendige Rechte und den Umgang mit Zugangsdaten. Ein Hintergrundprozess ist kein Grund, seine Befugnisse unklar zu lassen.

Datensätze prüfen, nicht nur Seiten

Der Zugriff auf eine Seite ist nur eine Ebene. Ein normaler Nutzer darf vielleicht keine Verwaltungsseite öffnen, kann aber deren Schnittstelle aufrufen. Eine ausgeblendete Datei lässt sich möglicherweise über einen gespeicherten Link herunterladen. Eine Datensatzkennung kann in einer Anfrage ausgetauscht werden. Diese Wege verdienen entsprechend ihrer Bedeutung Aufmerksamkeit.

Erstelle getrennte Testkonten mit künstlichen Daten. Prüfe zunächst eine erlaubte Handlung. Versuche dieselbe Handlung anschließend mit einem Konto, das sie nicht ausführen darf. Rufe einen fremden Datensatz ab, ändere einen Antrag außerhalb des eigenen Teams, fordere einen Export an und öffne einen geschützten Anhang.

Kontrolliere die tatsächliche Wirkung. Eine Fehlermeldung in der Oberfläche reicht nicht, wenn die Daten trotzdem geändert wurden. Ebenso kann eine freundliche Erfolgsmeldung erscheinen, obwohl der Server die Aktion abgelehnt hat. Entscheidend sind Antwort und gespeicherter Zustand.

Teste auch fehlende oder nicht mehr gültige Identität: ausgeloggte Anfragen, abgelaufene Sitzungen und gesperrte Konten. Ein Browser kann nach der Abmeldung noch alte Inhalte anzeigen. Unterscheide deshalb zwischen einer zwischengespeicherten Ansicht und der Möglichkeit, neue geschützte Daten abzurufen oder Änderungen vorzunehmen.

Teamgrenzen ausdrücklich festhalten

Viele kleine Tools beginnen mit einem Team und bekommen später ein zweites. Wenn das Datenmodell keine Teamgrenze kennt, schafft ein Auswahlfeld allein keine Isolation. Datenabfragen, Hintergrundjobs, Exporte und Integrationen müssen ebenfalls im richtigen Bereich arbeiten.

Gehe nicht davon aus, dass die E-Mail-Domain eine ausreichende Mitgliedschaftsregel ist. Externe Mitarbeiter, geteilte Adressen und Personen mit mehreren Organisationen können diese Annahme widerlegen. Mitgliedschaft sollte über den vorgesehenen Einladungs- oder Verwaltungsprozess entstehen. Prüfe auch, wer sie ändern darf.

Wenn das Tool tatsächlich nur einer Firma dient, darf es einfach bleiben. Eine komplexe Plattform für viele Mandanten ist dann nicht automatisch sinnvoll. Dokumentiere diese Annahme aber und überprüfe sie, bevor du dieselbe Installation mit einem Kunden oder einer weiteren Organisation teilst. Eine geschäftliche Erweiterung kann die Schutzgrenze verändern, ohne dass die Oberfläche anders aussieht.

Veränderungen über die Zeit berücksichtigen

Ein Mitarbeiter geht, ein Team wird neu organisiert, ein Dokument wird vertraulich oder ein Entwurf wird genehmigt. Lege fest, wann veränderte Rechte gelten müssen und ob alte Sitzungen weiterhin frühere Befugnisse ermöglichen können.

Besonders wichtig sind privilegierte Aktionen: Mitgliedschaften ändern, Integrationszugänge ersetzen oder sämtliche Datensätze exportieren. Ein nachvollziehbares Protokoll sollte Akteur, Handlung und betroffenes Objekt benennen. Vertrauliche Inhalte und Passwörter gehören nicht unüberlegt in solche Protokolle. Außerdem muss klar sein, wer die Einträge auswertet und vor Änderungen schützt.

Auch Notfallzugriff braucht einen Plan. Ist der einzige Administrator nicht erreichbar, benötigt das Unternehmen einen kontrollierten Wiederherstellungsweg. Ein undokumentiertes gemeinsames Passwort, das irgendwann jeder kennt, ist dafür keine gute Grundlage.

Welche Rolle Platform93 spielen kann

Platform93 ist die Open-Source-Grundlage von Supaapps für Identität und App-Verwaltung. Wenn sie zum Projekt passt, liefert sie Bausteine, statt jede Kontofunktion neu entwickeln zu müssen. Daraus folgt jedoch nicht automatisch die richtige Berechtigung auf Geschäftsdatensätze deiner Anwendung.

Das Tool muss Identität korrekt prüfen und seine fachlichen Regeln an der richtigen Stelle durchsetzen. Ein zentraler Identitätsdienst weiß nicht von selbst, ob eine Ausgabe innerhalb der Freigabegrenze eines Managers liegt. Diese Regel muss im System abgebildet und geprüft werden. Die Integration gehört deshalb in einen Test mit echten fachlichen Szenarien und künstlichen Daten.

Du musst nicht auf Platform93 wechseln, um Unterstützung von Launch a Tool zu erhalten. Ein Review kann deinen bestehenden Anmeldedienst, Datenbankrichtlinien und Hosting-Aufbau betrachten. Entscheidend ist, ob die Lösung die vereinbarten Regeln wirksam umsetzt und für dein Team beherrschbar bleibt.

Ein sinnvoller erster Prüfumfang

Beginne bei einem kleinen Tool mit dem Hauptablauf, zwei unterschiedlichen Rollen, einer privilegierten Handlung und gegebenenfalls geschützten Dateien. Schreibe erwartete Ergebnisse auf, prüfe mit Testdaten und dokumentiere die Beobachtungen. Das sagt mehr aus als die Aussage „Authentifizierung ist eingebaut“.

Eine begrenzte Prüfung benennt zugleich ihre Grenzen. Weitere Rollen, externe Freigaben, Schnittstellen oder historische Datenwege können zusätzliche Arbeit erfordern. Das Ergebnis soll eine konkrete Entscheidung ermöglichen: Zugang begrenzen, einen nachgewiesenen Fehler beheben, die Prüfung vertiefen oder einen kontrollierten Pilotbetrieb starten.

Quellen

• OWASP ASVS — Rahmenwerk für technische Sicherheitsanforderungen.
• Platform93-Quellcode — Implementierung und Release-Dokumentation als Grundlage für eine konkrete Integrationsprüfung.