Was ist ein Berechtigungskonzept?
Es ist die schriftliche Antwort auf drei Fragen: Wer darf was, wer hat das entschieden, und wann wurde es zuletzt geprüft? Das BSI beschreibt das Ziel im IT-Grundschutz so: Benutzende sollen nur auf die IT-Ressourcen und Informationen zugreifen können, die sie für ihre Arbeit brauchen und für die sie autorisiert sind.
Der BSI-Baustein ORP.4 trennt drei Ebenen, die Sie auch im Konzept auseinanderhalten sollten: Zutritt zu Räumen, Zugang zu Systemen und Zugriff auf Daten. Im Alltag geht es meist um die dritte Ebene. Chipkarten und Schlüssel gehören beim Austritt aber genauso dazu.
Ist ein Berechtigungskonzept Pflicht?
Eine allgemeine gesetzliche Pflicht, die dieses Wort nennt, habe ich nicht gefunden. Die Inhalte werden trotzdem verlangt. Die DSGVO fordert in Art. 5 Abs. 1 Buchst. f den Schutz vor unbefugter Verarbeitung und in Art. 32 geeignete technische und organisatorische Maßnahmen. Nach Art. 25 Abs. 2 dürfen Daten durch Voreinstellungen nicht ohne Eingreifen der Person einer unbestimmten Zahl von Personen zugänglich werden. Wie Sie das belegen, lässt die DSGVO offen. Ein Konzept ist aus meiner Sicht der einfachste Beleg.
Wer nach IT-Grundschutz arbeitet, muss laut Baustein ORP.4 festlegen, welche Zugriffsrechte an welche Personen im Rahmen ihrer Funktion vergeben und entzogen werden, und das dokumentieren. Bei TISAX sind Zugriffsrechte eine eigene Anforderung im Katalog VDA ISA (4.2.1), auch ISO/IEC 27001 behandelt die Zugangssteuerung. Prüfen Sie im Einzelfall, ob für Ihre Branche oder Ihre Kunden weitere Vorgaben gelten.
Was gehört in ein Berechtigungskonzept?
Diese neun Bausteine empfehle ich. Die Gliederung ist meine, die Angaben in Klammern verweisen auf die Anforderungen im BSI-Baustein ORP.4.
- Geltungsbereich: welche Systeme, Datenablagen und Standorte erfasst sind und welche bewusst nicht
- Grundsätze: geringste Rechte, Vergabe nur nach Erforderlichkeit, Trennung unvereinbarer Aufgaben (A2, A4)
- Verantwortliche: wer je System oder Datenbereich entscheidet, wer beantragt, wer genehmigt und wer technisch umsetzt
- Rollen: Standard-Rechteprofile, die den Funktionen und Aufgaben entsprechen, samt Rollenmatrix (A16)
- Eintritt, Wechsel, Austritt: Auslöser, Zuständige und Fristen, denn nicht mehr benötigte Kennungen und Rechte müssen entfernt werden (A2)
- Besondere Konten: Administratoren, Gäste, Dienstleister, Sammel- und Funktionskonten. Jede Kennung muss eindeutig einer Person zuzuordnen sein (A1), Ausnahmen brauchen einen benannten Verantwortlichen
- Ausnahmen: Rechte über den Standard hinaus nur nach Begründung und Prüfung (A2), aus meiner Sicht auch mit Ablaufdatum
- Überprüfung: wer was wie oft prüft und wo der Nachweis liegt (A3)
- Schutz des Konzepts: Die Dokumentation selbst muss vor unberechtigtem Zugriff geschützt sein (A3)
Wie gehen Sie beim Erstellen vor?
Diese Reihenfolge schlage ich vor. Sie verhindert, dass am Schreibtisch ein Rollenmodell entsteht, das mit dem Betrieb nichts zu tun hat.
- Bestand erfassen: Konten, Gruppen, Rollen und Freigaben aus den Systemen auslesen, nur lesend, dazu die aktuelle Personalliste mit den Austritten der letzten zwölf Monate.
- Befund schreiben: verwaiste Konten, Sammelkonten, breite Schreibrechte, Administratorrollen auf Alltagskonten, Gäste ohne Verantwortliche.
- Gespräche führen: Personal, Fachabteilungen und IT fragen, wer was für seine Arbeit braucht. Über Daten entscheidet der Fachbereich, nicht die IT.
- Rollen ableiten: mit wenigen Rollen je Abteilung beginnen und sie in einer Matrix gegen die Datenbereiche legen.
- Prozess festlegen: Antrag, Genehmigung, Umsetzung, Austritt und Überprüfung, zugeordnet zu Funktionen statt zu Namen.
- Umsetzen lassen: Ihre IT oder Ihr IT-Dienstleister ändert die Rechte nach Plan, zuerst die Zugänge, die niemand mehr haben dürfte.
Wie sieht eine Rollenmatrix aus?
Eine Zeile je Rolle, eine Spalte je Datenbereich, in jeder Zelle das Recht. Dieses Schema ist ausgedacht und zeigt nur die Form. Eine Rolle beschreibt eine Funktion und keine Person. Braucht jemand mehr, ist das eine befristete Ausnahme oder ein Hinweis, dass die Rolle nicht passt. Notieren Sie je Datenbereich zusätzlich, wem er gehört.
- Vertrieb: Kundenablage lesen und schreiben, Angebote lesen und schreiben, Buchhaltung kein Zugriff, Personal kein Zugriff
- Buchhaltung: Kundenablage nur lesen, Angebote nur lesen, Buchhaltung lesen und schreiben, Personal kein Zugriff
- Personal: Kundenablage kein Zugriff, Angebote kein Zugriff, Buchhaltung kein Zugriff, Personal lesen und schreiben
Wie oft sollten Sie Berechtigungen überprüfen?
Das BSI verlangt, regelmäßig zu prüfen, ob die Dokumentation dem tatsächlichen Stand entspricht und die Rechte noch zu den Aufgaben passen. Eine feste Frist nennt der Baustein ORP.4 nicht. Ich schlage diesen Takt vor und passe ihn an den Betrieb an:
- Vierteljährlich: alle Konten gegen die Personalliste, dazu Konten ohne Anmeldung seit 90 Tagen
- Halbjährlich: Administrator- und Notfallkonten, Gäste und Externe
- Jährlich: Rollen, Gruppen und Rechte in den Ablagen durch die jeweiligen Eigentümer
Woran sehen Sie, ob das Konzept wirkt?
An der Dauer vom Austritt bis zum Entzug aller Zugänge. Diese Kennzahl ist meine Empfehlung und keine Normvorgabe. Sie ist leicht zu messen: Das Personal liefert den letzten Arbeitstag, die IT den Zeitpunkt der Sperre, die Differenz ist der Wert. Legen Sie vorab fest, welche Systeme zählen, denn ein gesperrtes Hauptkonto beendet noch keinen Zugang zu einer Fachanwendung mit eigener Anmeldung.
Was gilt für Datenschutz und Betriebsrat?
Listen mit Konten, Abteilungen und letzter Anmeldung sind personenbezogene Daten. Klären Sie vorab mit Ihrem Datenschutzbeauftragten, wer sie sieht und wann sie gelöscht werden. Gibt es einen Betriebsrat, binden Sie ihn früh ein: § 87 Abs. 1 Nr. 6 BetrVG gibt ihm ein Mitbestimmungsrecht bei technischen Einrichtungen zur Überwachung von Verhalten oder Leistung. Ob das auf Ihre Auswertung zutrifft, ist eine Rechtsfrage. Dieser Artikel ist keine Rechtsberatung.
Was leistet ein Konzept nicht?
Ein Konzept entzieht selbst keinen Zugang. Ob Rechte am Austrittstag enden, hängt an der Umsetzung und daran, dass Personal und IT den Prozess leben. Ob ein Prüfer, Versicherer oder Kunde das Dokument anerkennt, kann niemand vorab zusagen.