Benutzerverwaltung mit Rollen und Rechten

Ein Zugriff muss jede Ebene passieren, von der gröbsten bis zur genauesten.

Datensatzweise Sichtbarkeit ist mehr als ein Filter in der Liste. Die Einschränkung wird in die Datenbankabfrage geschrieben, bevor sie läuft: Die fremden Datensätze verlassen die Datenbank gar nicht. Ein Filter, der erst im Browser greift, lässt sich dort aushebeln, eine Einschränkung in der Abfrage nicht.

Feldweise Sichtbarkeit hat eine oft übersehene zweite Seite. Ein Wert, den ein Bearbeiter nicht sehen darf, wird ihm beim Lesen entfernt und beim Speichern wieder eingesetzt. Sonst leert er das verborgene Gehalt beim nächsten Speichern unbemerkt. Das ist die häufigste Falle selbst gebauter Feldrechte.

Treffen mehrere Zuständigkeiten zusammen, muss entschieden werden, welche gewinnt: Wer im Vertrieb Deutschland und im Support arbeitet, sähe sonst nur die Schnittmenge. Raten kann das System das nicht, aber es macht die Entscheidung sichtbar.

Rollen hängen nicht am einzelnen Benutzer, sondern an Gruppen: Die Gruppe entscheidet, wer dazugehört, die Rolle, was erlaubt ist. Eine Standardgruppe fängt alle auf, die noch keiner anderen angehören. So sieht ein neuer Mitarbeiter am ersten Tag etwas Sinnvolles.

Interessanter sind bedingte Gruppen: Ihre Mitgliedschaft ergibt sich aus Eigenschaften des Benutzers, etwa alle einer Niederlassung oder alle eines Fachbereichs. Dafür lassen sich am Benutzer eigene Felder ergänzen, ohne das Datenmodell zu ändern. Wer versetzt wird, wechselt die Gruppe von selbst.

Gruppen bilden außerdem eine Organisationshierarchie ab, von Land über Geschäftsbereich und Gesellschaft bis zur Niederlassung. Dabei können sie Verzeichnisgruppen aus dem Active Directory referenzieren, statt Mitarbeiter zweimal zu pflegen. Soll der Fachbereich seine Anwender selbst verwalten, bekommt er dafür eine eigene Berechtigung.

Bei der Anmeldung redet die IT-Abteilung mit, meist mit dem Wunsch, dass niemand ein weiteres Passwort bekommt. Deshalb stehen mehrere Wege gleichzeitig zur Verfügung: Verzeichnisdienst, Windows-Anmeldung, Cloud-Konto, Passwort, passwortloser Passkey.

Der zweite Faktor ist nicht auf den Anmeldevorgang beschränkt. Er lässt sich mitten in der Anwendung verlangen, bevor jemand etwas Heikles tut, etwa ein hinterlegtes Zugangsdatum sichtbar macht. Der Alltag bleibt bequem, und die wenigen kritischen Handgriffe werden streng.

Die Anmeldewege laufen nebeneinander, und wir bauen sie nicht für jede Fachanwendung neu.

Ein Anmeldedienst ist ein Angriffsziel, deshalb steht seine Absicherung nicht zur Auswahl. Wir halten uns dabei an den BSI-Standard für sichere Webanwendungen; geprüft oder zertifiziert sind wir danach nicht. Anfragen, die von einer fremden Seite untergeschoben werden, wehrt ein Sitzungsmerkmal je Anwendung ab; es verfällt nach dreißig Minuten und trägt nach dem Einlösen nur noch fünf.

Dazu kommen die Schutzregeln, die der Browser durchsetzt, sofern die Auslieferung sie mitgibt: eine Inhaltsrichtlinie, die fremde Skripte ausschließt, eine Herkunftsangabe, die beim Sprung auf fremde Seiten schweigt, und außerhalb der Entwicklung der Zwang zur verschlüsselten Verbindung. Zu viele Fehlversuche sperren das Konto, ab welcher Zahl steht in der Konfiguration. Ein neues Gerät lässt sich sperren, bevor es zum ersten Mal hereinkommt, statt es hinterher zu entdecken.

Eine Frage steht in Ausschreibungen fast nie und wird im Betrieb fast immer wichtig: In wessen Rechtekontext läuft eine automatische Auswertung? Die Voreinstellung ist die vorsichtige. Was eine Anwendung nach einer Benutzeraktion selbsttätig nachlädt, sieht nicht mehr als der auslösende Benutzer. Soll eine Automatik über Benutzergrenzen hinweg arbeiten, wird das eigens freigeschaltet.

Im Namen eines anderen zu arbeiten ist heute dem Support vorbehalten: Berechtigte übernehmen vorübergehend eine Sitzung, ohne das Passwort zu kennen, um einen Fehler dort zu sehen, wo er auftritt. Wer wen ab wann übernommen hat, bleibt festgehalten. Eine geplante Urlaubsvertretung ist das nicht; wo eine gebraucht wird, ist sie eine eigene Aufgabe.

Scheidet jemand aus, stellt sich die Frage nach Aufbewahrung und Löschung. Das Framework kann beides: archivieren statt löschen, und festgelegte Felder durch Ersatzwerte ersetzen, etwa für Schulungskopien oder für Daten, die bleiben, aber nicht mehr personenbezogen sein dürfen. In der Benutzerverwaltung läuft davon ab Werk nichts. Welche Frist für welchen Datensatz gilt, legt Ihr Haus fest, und eingerichtet wird sie als Lauf im SOLUTIONS.transformer. Art. 32 DSGVO verlangt solche Maßnahmen. Mehr dazu steht unter On-Premise und DSGVO.

Die ehrliche Grenze steht am Anfang, nicht am Ende: Kein Rechtesystem entscheidet, wer was sehen soll. Diese Festlegung fällt zwischen Fachbereich, Datenschutz und Mitbestimmung, sie braucht Termine und ist meist die größere Position als die technische Umsetzung. Wer sie überspringt, bekommt entweder ein System, in dem alle alles sehen, oder eines, in dem täglich jemand nach einer Freischaltung fragt.

Zwei Punkte gehören dazu: Feldweise Einschränkungen wirken für alle Rollen eines Datenbereichs und gehören geplant, nicht nachträglich eingestreut. Und je feiner die Regeln, desto sorgfältiger muss belegt sein, warum jemand etwas nicht sieht.

Weiterlesen

• Active Directory anbinden
• Low-Code im eigenen Rechenzentrum: DSGVO und Betrieb
• Woraus eine Fachanwendung besteht
• Fertige Dienste statt Nachbau

Häufige Fragen

Was gehört in ein Berechtigungskonzept?

Vier Ebenen: Wer darf die Anwendung öffnen, wer einen Datenbereich lesen oder ändern, wer einen einzelnen Datensatz, wer ein einzelnes Feld. Dazu: wer Benutzer pflegt und was protokolliert wird.

Reichen Rollen für die Rechtevergabe aus?

Ja. Die Rolle bleibt der Träger jeder Regel, auch der feinsten. Die eigentliche Frage ist eine andere: Bekommt eine Rolle ein pauschales Recht auf einen Datenbereich, oder bekommt dasselbe Recht eine Bedingung, etwa auf den eigenen Standort. Wer stattdessen je Standort eine eigene Rolle anlegt, hat bald eine Liste, die mit jedem Standort wächst.

Können Benutzer aus dem Active Directory übernommen werden?

Ja, Benutzer und Verzeichnisgruppen, statt sie zweimal zu pflegen. Die Anmeldung erfolgt per LDAP oder als Windows-Anmeldung ohne erneute Eingabe. Auch der Betrieb ohne Verzeichnisdienst ist möglich.

Was unterscheidet Single Sign-on von der Zwei-Faktor-Anmeldung?

Single Sign-on erspart die zweite Eingabe: Wer am Arbeitsplatz angemeldet ist, ist auch in der Anwendung angemeldet. Der zweite Faktor verlangt umgekehrt einen zusätzlichen Nachweis. Beides ist kombinierbar.

Kann ich sehen, wer sich wann angemeldet hat?

Ja. Sicherheitsrelevante Ereignisse werden festgehalten, nicht allein die geglückte Anmeldung: auch der Fehlversuch, das Verfahren, über das jemand hereinkam, das Gerät, seine Adresse und wie oft von dort schon angemeldet wurde. Im Bedarfsfall lässt sich damit nachvollziehen, wer wann und auf welchem Weg gekommen ist und woran ein Versuch gescheitert ist. Das Änderungsprotokoll auf einzelnen Datensätzen ist etwas anderes und Sache des Frameworks.

Wie ist der Anmeldedienst selbst abgesichert?

Er folgt dem BSI-Standard für sichere Webanwendungen, ohne dass wir dafür geprüft oder zertifiziert wären. Umgesetzt sind unter anderem ein Sitzungsmerkmal je Anwendung gegen untergeschobene Anfragen, die Schutzregeln, die der Browser durchsetzt, eine Kontosperre nach zu vielen Fehlversuchen und eine Geräteliste, auf der ein neues Gerät gesperrt werden kann, bevor es zum ersten Mal hereinkommt.

Was kostet ein Rechtekonzept?

Die Umsetzung ist Konfiguration und damit überschaubar. Der Aufwand liegt davor: zu entscheiden, wer was sehen darf. Diese Abstimmung kostet Termine.