Need-to-know?

HMDATA Datenschutz-Newsletter 10/2025, Autor: Dipl.-Ing. (FH) Harald Müller-Delius, MBA, ©HMD 2025

Es gibt einige zentrale Prinzipien aus dem Datenschutz und der IT-Sicherheit, die einer Architektur von IT-Systemen immer ganz voran gestellt werden sollten: frei nach Art. 25 DSGVO Privacy-by-Design und Privacy-by-Default. Das ist letztlich auch für Nicht-Techniker ganz leicht zu verstehen, es geht darum Netzwerke, Server, Applikationen, Dateien und Datenbanken so zu planen, dass diese den risikogerechten Schutz der verarbeiteten Daten nachkommen können und die Verarbeitungszwecke eingehalten werden.
Da kann man bei Auswahl und Planung von Komponenten schon viel richtig machen, wenn dann auch noch Datenminimierung (bezogen auf den Verarbeitungszweck) und Löschfristen eingehalten werden.
Letztlich erwirbt man bei modernen Devices, Diensten, Applikationen und IT- und Software-Komponenten immer einen Werkzeugsatz, mit dem die jeweilige Funktion nach Stand der Technik zur Verfügung gestellt werden kann.
"Werkzeugsatz" heißt in dem Fall aber auch, dass der jeweilige Administrator wissen sollte, wie man damit umgeht, denn mit einem Hammer kann man zwar Nägel einschlagen aber auch viel anderweitigen Unsinn anrichten, die meistens in einer höheren Entropie der Sache enden.
Es kommt also darauf an, was man aus den zur Verfügung gestellten Systemen mit deren Werkzeugen macht.

Need-to-know & least Privilege

Wenn denn die Hardware dem Schutzbedürfnis der Verarbeitung sicher genug installiert ist, kommen langsam die "weichen" Komponenten in's Spiel und hier im ganz Besonderen: das Berechtigungssystem.
Es gibt also für nahezu jede konfigurierbare IT- und App-Komponente eine Möglichkeit, Personen oder Gruppen nach Authentifizierung Zugriff auf bestimmte Funktionen oder Daten zu gewähren. Zugriff wird dann nur Personen erteilt, die sich erfolgreich gegenüber der Komponenten oder dem Dienst identifiziert haben (idealerweise mit Multi-Faktor-Authentifizierung!) und dann nur entsprechend ihrer Tätigkeit Funktionen nutzen oder Daten einsehen können - also jeder sieht nur das, was er zur Erfüllung seiner Aufgabe unbedingt und dringend braucht: need to know bei least privilege.

Nun haben es Berechtigungssystem aber leider in sich. Manch ein System kennt nur Vollzugriff, andere haben nicht dokumentierte Rechte als Default vorgegeben und vererben diese an untergeordnete Gruppen, manche können Rechte nur einzelnen Personen zuordnen und keine Gruppenrechte verwalten.

Insofern wäre es also durchaus ein sinnvolles Auswahlkriterium einer Komponenten, einer Funktion oder eines Dienstes, ob dieser ein geeignetes Berechtigungssystem für die geforderte Sicherheit zur Verfügung stellen kann.
Idealerweise gibt es aber auch ein zentrales Berechtigungssystems einer übergeordneten Benutzerverwaltung, an dem sich alle Dienste, Funktionen und Datenzugriffe orientieren. Mit beispielsweise LDAP generell oder Active-Directory in Microsoft-Umgebungen stehen solche zentralen Dienste bereit und jedes andere moderne Betriebssystem bietet funktional gleich- oder höherwertiges an.

Was tun?

Berechtigungssystem neigen dazu, mit der Zeit in Wildwuchs auszuufern. Meistens, weil "mal auf die Schnelle" einem Benutzer ein Recht zugewiesen bekommt, das nicht einer Gruppe zugeordnet wird sondern an der Person hängt oder auf Grund mangelnder Planung die Struktur nicht den Erfordernissen entspricht. Falsche Rechte werden meistens nicht mehr zurückgenommen und schlummern lange Zeit vor sich als tickende Zeitbombe hin.
Weitere praktische Fehler sind, zum Prüfen einer Funktion oder eines Dienste nicht den langwierigen Weg ("alles dicht und so lange öffnen bis es gerade funktioniert") zu gehen, sondern mal administrativen Vollzugriff zu gewähren, dann funktioniert es gewiss. Manch Administrator, dessen Ergebnis nach Funktion bewertet werden, hat sich so schon eine Nachtschicht und früheren Feierabend erspart.
Ob nach Test dann wieder die Rechte entfernt werden, ist dann meist nicht dokumentiert.

Insofern gibt es also Ansatzpunkte, die gerne innerbetrieblich geprüft werden können:

• Prüfen, ob alle Berechtigungen an einem zentralen Dienst gekoppelt und verwaltet werden können
• Prüfen, ob eine aktuelle Dokumentation vorliegt und diese auch laufend angepasst wird
• Prüfen, ob die Struktur des Berechtigungssystems den betrieblichen Anforderungen angepasst ist (bspw. gleiche Tätigkeiten werden einer Gruppe zugeordnet, unterschiedliche Anforderungen in verschiedenen Gruppenrechten verwaltet) und diese abbildet
• Prüfen, ob Rechte nicht einzelnen Benutzern zugeordnet sind
• Prüfen, welche Nutzer ("Administratoren") Berechtigungen vergeben und entziehen können
• Prüfen, ob die Administratoren des Berechtigungssystem auch entsprechende Qualifikation haben
• Prüfen, ob ein Gruppenrecht nicht andere Rechte aushebelt
• Aufstellen von Richtlinien zur Erweiterung des Berechtigungssystems
• Automatisierung / Scripting bei Zuweisung komplexer Rechte
• Funktionieren einer Stellvertreterregelung über das Berechtigungssystem prüfen
• 6Trennen von Berechtigungssystemen von Test- und Produktivsystemen
• Automatisierte Tests zum Prüfen des Berechtigungssystem
• Auch unscheinbare Hardware (Drucker, Switches, VoIP-Telefone, IP-Kameras, Mobile Devices, …) haben i.d.R. ein Betriebssystem mit Berechtigungen. Default-Einstellungen und fehldende Updates sind ein hohes Sicherheitsrisiko!
• Auch ein einzelner Benutzer wird über eine Gruppe verwaltet
• Prüfen, ob Offboarding eines Benutzers auch vollkommen alle dessen Rechte entzieht

Dabei kann ein Benutzer auch verschiedene Berechtigungen über Gruppenzugehörigkeiten erhalten, je nachdem, was zugeordnet werden soll (Dienste, Hardware, Daten) oder welche Rolle im sein Arbeitsplatz zuschreibt.
Gerade bei Online-Diensten die von überall aus erreicht werden können ist neben einer ausreichenden Benutzerauthentifizierung ein passendes Berechtigungssystem unbedingt notwendig!
Und noch ganz wichtig: kein sinnvolles Berechtigungssystem verlangt von irgendeinem Benutzer irgendjemandem Drittem sein Passwort preiszugeben, ein Stellvertreterzugriff erfolgt einzig und allein über das Berechtigungssystem.
Passwortänderungen werden – je nach Umfang – idealerweise gescriptet über Self-Service-Portale durchgeführt, damit auch unterschiedliche Systeme von der Änderung in Kenntnis gesetzt werden - sonst droht Funktionsstopp und Aussperrung.

Fazit

Egal wie gut die eingesetzten Komponenten sind, ein falsches Berechtigungssystem zerstört jede Sicherheitsarchitektur, ein gut konzeptioniertes System hingegen ist Voraussetzung jeglicher IT- und Datenschutz-Sicherheit – und vor allem alternativlos.
Und auch wenn man nun wachgerüttelt den Aufwand für ein Redesign eines historisch gewachsenen Berechtigungssystems scheut: langfristig ist ein umgehendes Neudesign immer billiger und natürlich viel sicherer als das "Weiterwurschteln" wie bisher. Kapitulation vor Komplexität ist letztlich nur ein Beweis für mangelnde Planung zu Beginn.