Berechtigungskonzept nach BSI IT-Grundschutz: Aufbau, Rollenmatrix und Muster

Ein Berechtigungskonzept legt fest, wer in welcher Rolle auf welche Informationen und Systeme zugreifen darf – und wie diese Rechte vergeben, geändert, entzogen und überprüft werden. Kaum ein Dokument wird in Audits so regelmäßig verlangt – und so selten in brauchbarer Form vorgelegt – wie das Berechtigungskonzept. Entweder existiert es gar nicht, oder es besteht aus einem Export der Active-Directory-Gruppen, den niemand interpretieren kann. Dabei ist das Berechtigungskonzept das Bindeglied zwischen Organisation und Technik: Es übersetzt „Wer darf was?“ in nachvollziehbare Regeln, die sich in Systemen umsetzen und prüfen lassen.

Dieser Beitrag erklärt, was das BSI im IT-Grundschutz konkret fordert, wie ein tragfähiges Berechtigungskonzept aufgebaut ist und wie Sie es Schritt für Schritt einführen – mit Rollenmatrix, Freigabeprozess, Eintritt-Wechsel-Austritt-Regelung und regelmäßiger Überprüfung. Am Ende finden Sie ein Muster, das Sie an Ihre Organisation anpassen können.

Was ein Berechtigungskonzept ist – und was nicht

Ein Berechtigungskonzept beschreibt, nach welchen Regeln Zugriffsrechte auf Informationen, Anwendungen und Systeme vergeben werden. Es beantwortet vier Fragen:

• Wer (welche Rolle oder Person) darf
• worauf (welche Daten, Anwendungen, Systeme, Räume)
• wie (lesen, schreiben, löschen, administrieren) zugreifen – und
• wie wird das gesteuert (Beantragung, Freigabe, Einrichtung, Änderung, Entzug, Überprüfung)?

Es ist damit ein organisatorisches Dokument, kein technischer Export. Die Gruppenstruktur im Verzeichnisdienst, die Rollen im ERP-System oder die Zugriffslisten des Dateiservers sind die Umsetzung des Konzepts – sie müssen zu ihm passen, ersetzen es aber nicht. Genau diese Trennung macht das Konzept prüfbar: Ein Auditor vergleicht Soll (Konzept) mit Ist (Systemkonfiguration).

Zwei Grundprinzipien ziehen sich durch jedes Berechtigungskonzept:

• Need-to-know / Minimalprinzip (Least Privilege): Jede Rolle erhält nur die Rechte, die für ihre Aufgaben erforderlich sind – nicht mehr.
• Funktionstrennung (Segregation of Duties): Kritische Vorgänge werden auf mehrere Rollen verteilt, sodass eine Person sie nicht allein auslösen und freigeben kann – etwa Anlegen und Freigeben eines Lieferanten oder Entwickeln und Produktivsetzen von Software.

Was BSI IT-Grundschutz und ISO 27001 verlangen

Im IT-Grundschutz-Kompendium ist das Berechtigungsmanagement vor allem im Baustein ORP.4 „Identitäts- und Berechtigungsmanagement“ geregelt. Die Basis-Anforderungen verlangen unter anderem, dass Berechtigungen nach einem dokumentierten Verfahren vergeben, geändert und entzogen werden, dass jede Berechtigung einer eindeutigen Identität zugeordnet ist, dass Administrationsrechte restriktiv vergeben werden und dass Berechtigungen regelmäßig überprüft werden. Die Standard-Anforderungen ergänzen eine dokumentierte Rollen- und Berechtigungsstruktur sowie die Regelung von Freigaben und Vertretungen. Ergänzende Anforderungen finden sich in OPS.1.1.2 „Ordnungsgemäße IT-Administration“ (privilegierte Zugänge), in ORP.2 „Personal“ (Eintritt, Wechsel, Austritt) und in den systemspezifischen Bausteinen etwa für Verzeichnisdienste und Datenbanken. Die jeweils aktuelle Fassung der Anforderungen finden Sie im IT-Grundschutz-Kompendium des BSI.

ISO/IEC 27001:2022 adressiert dasselbe Thema in den Controls 5.15 (Zugangssteuerung), 5.16 (Identitätsmanagement), 5.18 (Zugangsrechte) und 8.2 (Privilegierte Zugangsrechte). Für NIS-2 gehört die Zugriffskontrolle zu den ausdrücklich geforderten Risikomanagementmaßnahmen (§ 30 BSIG), und die DSGVO verlangt in Art. 32 Zugriffsbeschränkungen als technisch-organisatorische Maßnahme. Ein sauberes Berechtigungskonzept zahlt also gleich auf mehrere Rahmenwerke ein.

Entscheidend ist: Alle genannten Regelwerke verlangen einen dokumentierten Prozess und regelmäßige Überprüfung – nicht nur eine einmalige Liste.

Aufbau eines Berechtigungskonzepts

Ein Berechtigungskonzept, das im Audit trägt und im Alltag funktioniert, hat typischerweise diese Gliederung:

1. Geltungsbereich und Ziele – Welche Systeme, Anwendungen, Standorte und Datenarten sind erfasst? Welche Schutzziele gelten?
2. Grundsätze – Minimalprinzip, Funktionstrennung, personenbezogene Kennungen (keine geteilten Accounts), Trennung von Standard- und Administrationskonten.
3. Rollen und Verantwortlichkeiten – Wer ist Informationseigentümer (fachlich verantwortlich), wer Systemverantwortlicher, wer Berechtigungsadministrator, wer Vorgesetzter/Antragsteller?
4. Rollenmodell und Rollenmatrix – Welche fachlichen Rollen gibt es, und welche Rechte in welchen Systemen gehören dazu?
5. Prozesse – Beantragung, Freigabe, Einrichtung, Änderung (Wechsel), Entzug (Austritt), Notfall- und temporäre Berechtigungen, Vertretungen.
6. Privilegierte Berechtigungen – Sonderregeln für Administratoren: separate Konten, Vier-Augen-Prinzip, Protokollierung, Befristung.
7. Überprüfung (Rezertifizierung) – Intervalle, Verantwortliche, Vorgehen, Umgang mit Abweichungen.
8. Dokumentation und Nachweise – Wo werden Anträge, Freigaben und Prüfprotokolle abgelegt, wie lange werden sie aufbewahrt?

Für kleinere Organisationen genügen dafür 8–15 Seiten. Wichtiger als Umfang ist, dass jede Regel einen Verantwortlichen und einen nachprüfbaren Nachweis hat.

Die Rollenmatrix: Herzstück des Konzepts

Die Rollenmatrix verbindet fachliche Rollen (Was macht jemand im Unternehmen?) mit technischen Berechtigungen (Welche Rechte braucht diese Rolle wo?). Sie wird pro System oder Anwendung geführt und ist das Dokument, das ein Auditor neben die tatsächliche Konfiguration legt.

Ein bewährtes Vorgehen in fünf Schritten:

1. Fachliche Rollen erheben – entlang der Organisation (Vertrieb, Einkauf, Personal, Entwicklung, IT-Betrieb, Geschäftsführung), nicht entlang einzelner Personen. Faustregel: Eine Rolle sollte von mindestens zwei Personen besetzt sein können.
2. Systeme und Berechtigungsstufen festlegen – pro System die möglichen Stufen definieren, z. B. Lesen (L), Schreiben (S), Freigeben (F), Administrieren (A).
3. Matrix befüllen – für jede Rolle und jedes System die erforderliche Stufe eintragen; leere Felder bedeuten „kein Zugriff“.
4. Funktionstrennung prüfen – Konflikte markieren: Keine Rolle darf z. B. zugleich Bestellungen anlegen und freigeben, Code schreiben und produktiv setzen oder Rechte beantragen und selbst einrichten.
5. Informationseigentümer freigeben lassen – jede Spalte (System) wird vom fachlich Verantwortlichen bestätigt und mit Datum versehen.

Beispiel einer Rollenmatrix (vereinfacht, fiktive Organisation – nur zur Veranschaulichung):

L = Lesen · S = Schreiben · F = Freigeben · A = Administrieren · – = kein Zugriff. Funktionstrennung ist hier u. a. dadurch gewahrt, dass „Einkauf“ bestellt, aber erst „Einkaufsleitung“ freigibt, und dass Administrationsrechte ausschließlich beim IT-Betrieb über ein getrenntes Konto liegen.

Freigabeprozess: Wer entscheidet, wer richtet ein?

Das BSI verlangt ein dokumentiertes Verfahren für Vergabe, Änderung und Entzug. In der Praxis hat sich ein dreistufiges Modell bewährt:

• Antrag durch die Führungskraft (nicht durch die betroffene Person selbst), mit Angabe von Rolle, System, Berechtigungsstufe und Begründung – idealerweise als Ticket, damit Datum und Verlauf dokumentiert sind.
• Freigabe durch den Informationseigentümer des jeweiligen Systems oder Datenbestands. Bei Standardrollen aus der Rollenmatrix kann die Freigabe pauschal vorab erfolgen („Rollenpaket Einkauf“); Abweichungen von der Matrix brauchen immer eine Einzelfreigabe.
• Einrichtung durch den Berechtigungsadministrator – strikt getrennt von der Freigabe. Der Vollzug wird im Ticket bestätigt; damit ist der Nachweis „beantragt – freigegeben – eingerichtet“ geschlossen.

Für privilegierte Rechte (Domänenadministration, Datenbank-Root, Cloud-Konsolen) gelten verschärfte Regeln: Vier-Augen-Freigabe, separates Admin-Konto, Befristung, Protokollierung der Nutzung und – wo möglich – zeitlich begrenzte Rechteerhöhung statt dauerhafter Vergabe.

Temporäre und Notfallberechtigungen (etwa für Dienstleister oder in Störungen) werden mit Ablaufdatum vergeben und nach Ablauf automatisch oder nachweislich manuell entzogen. Ein „Notfall-Admin“-Konto gehört in einen versiegelten Umschlag bzw. einen Passworttresor mit Zugriffsprotokoll – nicht in eine E-Mail.

Eintritt, Wechsel, Austritt: der Joiner-Mover-Leaver-Prozess

Die meisten Berechtigungsleichen entstehen nicht bei der Vergabe, sondern bei Wechsel und Austritt. Deshalb muss das Berechtigungskonzept mit dem Personalprozess verzahnt sein:

Eintritt (Joiner): Die Personalabteilung meldet den Eintritt mit Rolle und Startdatum; die IT richtet das Standard-Rollenpaket aus der Matrix ein – nicht mehr. Zusätzliche Rechte laufen über den regulären Antragsprozess. Die Verpflichtung auf Vertraulichkeit und die Datenschutzunterweisung erfolgen vor der Freischaltung.

Wechsel (Mover): Bei einem Rollenwechsel werden die Rechte der alten Rolle entzogen, nicht ergänzt. Das klingt selbstverständlich, ist aber der häufigste Fehler: Nach drei internen Wechseln hat eine Person die Rechte von vier Rollen. Der Wechsel wird wie ein Eintritt behandelt – neues Rollenpaket, alte Rechte weg.

Austritt (Leaver): Konten werden am letzten Arbeitstag gesperrt, nicht Wochen später gelöscht. Dazu gehören auch Nebenzugänge, die gern vergessen werden: VPN, Cloud-Dienste, SaaS-Tools mit eigenem Login, Zutrittskarten, Token, Gruppenpostfächer. Eine Austritts-Checkliste, die Personalabteilung und IT gemeinsam abarbeiten, ist der einfachste und wirksamste Nachweis.

Eine klare Auslöser-Regel verhindert Lücken: Jede Personalmaßnahme (Eintritt, Wechsel, Austritt, Langzeitabwesenheit) erzeugt automatisch ein Ticket an die Berechtigungsadministration.

Regelmäßige Überprüfung (Rezertifizierung)

Berechtigungen altern. Deshalb verlangt das BSI eine regelmäßige Überprüfung – und Auditoren fragen nach dem Nachweis, dass sie stattgefunden hat.

• Intervall: Mindestens jährlich für alle Systeme; halbjährlich oder quartalsweise für privilegierte Rechte und Systeme mit hohem Schutzbedarf.
• Vorgehen: Die Berechtigungsadministration exportiert pro System die Ist-Berechtigungen; der jeweilige Informationseigentümer bestätigt für jede Person und jedes Recht: beibehalten oder entziehen. Vorgesetzte prüfen zusätzlich, ob die zugeordnete Rolle noch zur tatsächlichen Tätigkeit passt.
• Anlassbezogen: Nach Reorganisationen, Systemmigrationen und Sicherheitsvorfällen wird außerplanmäßig geprüft.
• Nachweis: Datum, Prüfer, geprüfter Umfang, festgestellte Abweichungen und deren Erledigung werden protokolliert. Dieses Protokoll ist das Dokument, das im Audit vorgelegt wird.

Wer eine Compliance-Plattform oder ein Identity-Management-System einsetzt, kann Export, Bestätigungsworkflow und Protokoll weitgehend automatisieren – der fachliche Entscheid „beibehalten oder entziehen“ bleibt aber beim Informationseigentümer.

Typische Fehler – und wie Sie sie vermeiden

• Personen statt Rollen: Rechte werden individuell vergeben, die Matrix bleibt leer. Abhilfe: konsequent Rollenpakete definieren, Einzelrechte nur begründet und befristet.
• Konzept ohne Prozess: Ein schönes Dokument, aber niemand beantragt oder genehmigt tatsächlich etwas. Abhilfe: Tickets als Pflichtweg, keine Rechte „auf Zuruf“.
• Admin-Rechte im Alltag: Administratoren arbeiten dauerhaft mit privilegierten Konten. Abhilfe: getrennte Konten, Rechteerhöhung nur bei Bedarf.
• Keine Rezertifizierung: Das Konzept wurde 2022 geschrieben und nie geprüft. Abhilfe: feste Termine im Jahreskalender des ISMS, Verantwortliche benennen.
• Geteilte Konten: „admin“, „buchhaltung“, „info“ – ohne Zuordnung zu Personen. Abhilfe: personenbezogene Kennungen, Funktionspostfächer mit delegierten Rechten.
• Austritt vergessen: Konto bleibt Monate aktiv. Abhilfe: Austritts-Checkliste mit Sperrung am letzten Arbeitstag.

Muster: Gliederung eines Berechtigungskonzepts (Vorlage)

Hinweis: Das folgende Muster ist ein Beispiel und muss an Organisation, Systeme und Schutzbedarf angepasst werden. Es ersetzt keine individuelle Konzeption.

Für die Anlagen genügen zu Beginn einfache Tabellen: die Rollenmatrix (wie oben), eine Eintritts-/Austritts-Checkliste und ein Rezertifizierungsprotokoll mit den Spalten System · Person · Recht · Prüfer · Entscheidung · Datum.

Berechtigungskonzept einführen: so gehen Sie vor

1. Scope klein starten: die drei bis fünf Systeme mit dem höchsten Schutzbedarf zuerst – meist ERP, Personal, Dateiablage, Verzeichnisdienst, E-Mail.
2. Ist-Stand exportieren und mit den Fachbereichen bereinigen: Was ist überflüssig, wer ist längst ausgeschieden?
3. Rollenmatrix erarbeiten und von den Informationseigentümern freigeben lassen.
4. Prozesse festlegen und im Ticketsystem abbilden – Antrag, Freigabe, Einrichtung, Entzug.
5. Konzept verabschieden, Beteiligte schulen, erste Rezertifizierung terminieren.
6. Nach dem ersten Zyklus erweitern auf weitere Systeme und Standorte.

Mit diesem Vorgehen entsteht in wenigen Wochen ein Berechtigungskonzept, das die Anforderungen von BSI IT-Grundschutz, ISO 27001 und NIS-2 erfüllt – und das vor allem im Alltag gelebt wird, weil es an die vorhandenen Personal- und IT-Prozesse anschließt.

Fazit

Ein Berechtigungskonzept ist kein Verzeichnis-Export, sondern die dokumentierte Antwort auf „Wer darf was – und wer hat das entschieden?“. Rollenmatrix, klarer Freigabeprozess, ein verzahnter Eintritt-Wechsel-Austritt-Prozess und eine nachweisbare Rezertifizierung sind die vier Elemente, auf die es ankommt. Wer sie einmal sauber aufsetzt, erfüllt die Anforderungen von ORP.4 und ISO 27001 nicht nur auf dem Papier, sondern reduziert tatsächlich das Risiko, das von verwaisten Konten und übermäßigen Rechten ausgeht.

Wenn Sie Unterstützung bei Strukturanalyse, Schutzbedarfsfeststellung und der Umsetzung der IT-Grundschutz-Bausteine wünschen, finden Sie unser Angebot auf der Seite BSI IT-Grundschutz. Wie das Berechtigungskonzept in ein ISMS nach ISO 27001 eingebettet wird, zeigt unser ISO-27001-Leitfaden.