0800 71 20000
Kontakt
...
Identitäten und Rechte

Berechtigungskonzept: Zuständigkeiten klären, nicht nur Rollen beschreiben

Rechte wachsen in jedem Haus schneller, als sie entzogen werden. Diese Seite ordnet, wer entscheidet, wer umsetzt und woran die Rezertifizierung scheitert.

Passende Kurse ansehen Persönlich beraten lassen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer

Kurz gesagt

Ein Berechtigungskonzept legt fest, nach welchen Regeln Zugriffsrechte in allen Systemen vergeben, geprüft und entzogen werden, und wer dafür geradesteht. Der technische Teil ist dabei der kleinere: Rollen lassen sich in Entra ID, Keycloak oder Active Directory in Tagen bauen. Der größere Teil ist die Entscheidung, wer Eigentümer einer Anwendung ist, wer ein Recht genehmigt, wie Eintritt, Wechsel und Austritt angestoßen werden und wie oft jemand den Bestand mit dem Bedarf abgleicht. Genau diese Festlegungen verlangen der IT-Grundschutz-Baustein ORP.4, die ISO/IEC 27001:2022 und § 30 BSIG.

Stand dieser Seite: 04.10.2026

01 Worum es geht

Rechte werden vergeben, aber nie zurückgenommen

Im Betrieb sieht die Lage meistens so aus: Eine neue Kollegin bekommt die Rechte ihres Vorgängers kopiert, weil das schnell geht. Ein Projektleiter erhält Schreibzugriff auf eine Freigabe, weil ein Audit ansteht, und behält ihn danach. Ein Administrator wechselt in die Entwicklung und nimmt sein Domänenadministratorkonto mit. Nach fünf Jahren hat ein Viertel der Belegschaft Rechte, die niemand mehr begründen kann. Der Preis zeigt sich im Ernstfall: Ein gestohlenes Konto öffnet dann nicht eine Anwendung, sondern zehn, und der Wirtschaftsprüfer vermerkt, dass die Rechtevergabe nicht nachvollziehbar ist.

Die zweite Schwierigkeit ist die Verteilung über viele Systeme. Rechte liegen heute in Active Directory, in Entra ID, in SAP, in der Cloud-Konsole, im Ticketsystem, im Wiki und in Dutzenden Fachanwendungen mit eigener Benutzerverwaltung. Jedes dieser Systeme hat eigene Begriffe für Rolle, Gruppe und Profil. Ein Konzept, das nur das Verzeichnis beschreibt, erfasst einen Bruchteil der tatsächlichen Zugriffe, und genau die Fachanwendung mit den Gehaltsdaten oder den Konstruktionszeichnungen bleibt außen vor.

Die dritte Schwierigkeit ist, dass das Thema zwischen den Stühlen sitzt. Die IT setzt um, will aber nicht entscheiden, ob jemand Zugriff auf Kundendaten braucht. Der Fachbereich will den Zugriff, hält sich aber nicht für zuständig, ihn zu begründen. Der Informationssicherheitsbeauftragte schreibt die Richtlinie, hat aber keine Weisungsbefugnis. Solange niemand festlegt, wer Eigentümer eines Systems ist und wer eine Freigabe erteilt, bleibt jedes Berechtigungskonzept ein Papier ohne Wirkung.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

02 Wer entscheidet was

Wer im Haus was entscheidet

Ein Berechtigungskonzept scheitert nicht an fehlenden Rollen, sondern an der Frage, wer am Tag der Entscheidung zuständig ist. Die folgende Aufteilung ordnet jede wiederkehrende Frage einer Stelle zu und benennt die Falle, in die Häuser an genau dieser Stelle regelmäßig laufen.

Das Rollenmodell und der Zuschnitt der Rollen je System

Wer entscheidet
Der Eigentümer des Systems aus dem Fachbereich, beraten vom Informationssicherheitsbeauftragten, der auf Need-to-know und Funktionstrennung achtet
Wer setzt um
Das IAM-Team oder der IT-Betrieb; die Rollen werden als Gruppen im Verzeichnis, als Realm-Rollen in Keycloak oder als Rollenzuweisungen in der Fachanwendung abgebildet
Stolperfalle
Rollen werden nach Abteilungen statt nach Tätigkeiten geschnitten. Nach zwei Jahren gibt es so viele Rollen wie Beschäftigte, und das Modell erklärt niemandem mehr, warum jemand ein Recht hat.

Die Genehmigung eines einzelnen Zugriffsrechts

Wer entscheidet
Der Eigentümer der betroffenen Anwendung oder Datenablage, nicht die Führungskraft der anfragenden Person, denn die kennt den Bedarf, aber nicht die Daten
Wer setzt um
Der IT-Betrieb über einen dokumentierten Antrag mit Rolle, Begründung, Genehmiger und Datum, am besten über das Ticketsystem oder einen Self-Service, der die Freigabe des Eigentümers einholt
Stolperfalle
Der Antrag lautet, die Rechte eines Kollegen zu kopieren. Damit wandern alle historisch gewachsenen Ausnahmen dieser Person weiter, und der Eigentümer hat nie gesehen, was er genehmigt.

Eintritt, Wechsel und Austritt von Beschäftigten

Wer entscheidet
Die Personalabteilung liefert den Auslöser und das Datum, der aufnehmende Fachbereich wählt die Rolle, beim Austritt entscheidet niemand mehr, denn der Entzug ist die Regel
Wer setzt um
Das IAM-Team über einen Prozess, der aus dem Personalsystem gespeist wird und beim Wechsel die alten Rollen zum Stichtag entfernt, statt die neuen nur hinzuzufügen
Stolperfalle
Der Wechsel wird wie ein Eintritt behandelt. Die Person bekommt die neuen Rechte, behält die alten und wird nach drei Wechseln zum Konto mit dem größten Schadenspotenzial im Haus.

Administrative und sonst privilegierte Rechte

Wer entscheidet
Die IT-Leitung gemeinsam mit dem Informationssicherheitsbeauftragten, mit einer namentlichen Liste der Personen, die administrative Rollen aktivieren dürfen
Wer setzt um
Der IT-Betrieb über getrennte Administratorkonten, Multi-Faktor-Authentifizierung und eine Aktivierung auf Zeit, etwa über Privileged Identity Management in Entra ID, mit Protokollierung jeder Aktivierung
Stolperfalle
Es gibt ein gemeinsam genutztes Administratorkonto, dessen Passwort im Team bekannt ist. Damit lässt sich keine Handlung einer Person zuordnen, und der Austritt eines Teammitglieds erzwingt einen Passwortwechsel, der regelmäßig unterbleibt.

Die Funktionstrennung über Systemgrenzen hinweg

Wer entscheidet
Die Geschäftsführung oder die Interne Revision legt fest, welche Kombinationen von Rechten unvereinbar sind, denn das ist eine Frage der Haftung und der Betrugsprävention, nicht der Technik
Wer setzt um
Die Eigentümer der beteiligten Systeme gemeinsam mit dem IAM-Team, indem sie die Kombinationen in den Rollen ausschließen und verbleibende Konflikte als dokumentierte Ausnahme mit kompensierender Kontrolle führen
Stolperfalle
Funktionstrennung wird nur im ERP-System geprüft. Dass dieselbe Person im Verzeichnis Benutzer anlegen und in der Cloud-Konsole Rechte vergeben darf, sieht niemand, weil keine der beiden Prüfungen über ihr System hinausblickt.

Die Rezertifizierung und ihre Dokumentation

Wer entscheidet
Der Informationssicherheitsbeauftragte legt Takt und Umfang fest, der Eigentümer jedes Systems bestätigt oder widerruft jede einzelne Zuweisung
Wer setzt um
Das IAM-Team stellt die Listen bereit, sammelt die Antworten ein, entzieht nicht bestätigte Rechte nach Fristablauf und archiviert das Ergebnis als Nachweis für Audit und Behörde
Stolperfalle
Der Eigentümer erhält eine Liste mit vierhundert Zeilen und einen Knopf, der alles bestätigt. Die Prüfung findet formal statt, aber inhaltlich nicht, und der Prüfer erkennt das an der Bearbeitungszeit von zwei Minuten.

03 Was du mitnimmst

Sechs Festlegungen, aus denen ein tragfähiges Konzept besteht

Die Reihenfolge ist bewusst gewählt. Erst die Eigentümer, dann das Rollenmodell, dann die Prozesse, dann die Technik. Wer mit dem Rollenbau beginnt, hat am Ende ein sauberes Verzeichnis und weiterhin niemanden, der eine Entscheidung trifft.

Vom Eigentümer bis zur Rezertifizierung

  1. 01 Eigentümer je System benannt
  2. 02 Rollen aus Tätigkeiten gebaut
  3. 03 Unvereinbare Rechte gelistet
  4. 04 Eintritt, Wechsel, Austritt
  5. 05 Admin-Rechte nur auf Zeit
  6. 06 Bestand gegen Bedarf geprüft

Für jedes System einen Eigentümer benennen, der Rechte genehmigt

Jede Anwendung, jede Datenablage und jede Cloud-Umgebung braucht genau eine Person aus dem Fachbereich, die über Zugriffe entscheidet. Nicht die IT, denn sie kennt den fachlichen Bedarf nicht, und nicht die Geschäftsführung, denn sie hat keine Zeit dafür. Der Eigentümer genehmigt Rollenzuweisungen, entscheidet über Ausnahmen und bestätigt in der Rezertifizierung, dass die Zuordnung noch stimmt. Diese Liste der Eigentümer ist das Fundament des Konzepts und gehört an den Anfang des Dokuments.

Rollen aus Tätigkeiten ableiten, nicht aus dem Organigramm

Eine Rolle bündelt die Rechte, die eine wiederkehrende Tätigkeit braucht: Rechnungen freigeben, Tickets bearbeiten, Server patchen. Eine Rolle wird einmal beschrieben, einmal genehmigt und danach vielen Personen zugewiesen. Wer Rollen stattdessen je Abteilung schneidet, landet bei einer Rolle pro Person und hat nichts gewonnen. Bewährt haben sich ein Basisrecht für alle Beschäftigten, eine überschaubare Zahl fachlicher Rollen je Bereich und getrennte administrative Rollen, die niemand dauerhaft hält.

Need-to-know und Funktionstrennung schriftlich festhalten

Need-to-know heißt, dass ein Recht nur vergeben wird, wenn die Tätigkeit es verlangt. Funktionstrennung heißt, dass bestimmte Rechte nicht bei einer Person zusammenfallen dürfen: Lieferanten anlegen und Zahlungen freigeben, Benutzer anlegen und Rechte vergeben, Code schreiben und in die Produktion ausrollen. Der IT-Grundschutz fordert diese Trennung in der Basis-Anforderung ORP.4.A4 ausdrücklich, und die Liste der unvereinbaren Kombinationen gehört als Anlage ins Konzept.

Eintritt, Wechsel und Austritt als einen Prozess mit drei Auslösern bauen

Die Personalabteilung ist die einzige Stelle, die zuverlässig weiß, wann jemand kommt, wechselt oder geht. Deshalb kommt der Auslöser von dort, der Fachbereich wählt die Rolle, und die IT setzt um. Der Wechsel ist der kritischste der drei Fälle, weil hier Rechte entzogen werden müssen, obwohl die Person bleibt. ORP.4.A2 verlangt, dass nicht mehr benötigte Kennungen und Berechtigungen bei personellen Veränderungen entfernt werden, und genau dieser Entzug fehlt in den meisten Häusern.

Privilegierte Rechte getrennt behandeln und zeitlich begrenzen

Administrative Rechte gehören auf eigene Konten, die nur für administrative Tätigkeiten benutzt werden, mit Multi-Faktor-Authentifizierung und einer Protokollierung, die jemand liest. Dauerhafte Mitgliedschaft in Gruppen wie Domain Admins oder Global Administrator ist durch eine Aktivierung auf Zeit mit Begründung zu ersetzen. Die ISO/IEC 27001:2022 widmet diesem Punkt das eigene Control 8.2 zu privilegierten Zugriffsrechten, der IT-Grundschutz fordert in ORP.4.A10 den Schutz von Kennungen mit weitreichenden Berechtigungen.

Rezertifizierung mit Takt, Stichprobe und Konsequenz

Einmal im Jahr, bei kritischen Systemen einmal im Quartal, erhält jeder Eigentümer die Liste der Personen mit Zugriff auf sein System und bestätigt oder widerruft jede Zeile. Was nicht bestätigt wird, wird entzogen, und zwar automatisch nach Ablauf einer Frist. Werkzeuge wie die Zugriffsüberprüfungen in Microsoft Entra ID Governance erledigen das Einsammeln der Antworten und den Entzug, aber die Entscheidung, dass nicht beantwortete Zeilen entfernt werden, muss im Konzept stehen, sonst bestätigt am Ende jeder alles.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Was in das Dokument gehört und was nicht

Ein brauchbares Berechtigungskonzept hat einen Geltungsbereich, der alle Systeme mit schutzbedürftigen Daten nennt, nicht nur das Verzeichnis. Es enthält die Liste der Eigentümer und das Rollenmodell mit einer kurzen Beschreibung je Rolle. Dazu kommen die Grundsätze Need-to-know und Funktionstrennung mit der Liste unvereinbarer Kombinationen, die Prozesse für Eintritt, Wechsel, Austritt und Ausnahmen, die Regeln für privilegierte Konten und der Takt der Rezertifizierung. Der IT-Grundschutz verlangt in ORP.4.A3 genau diese Dokumentation der Kennungen und Rechteprofile und ihre regelmäßige Prüfung auf Aktualität.

Nicht in das Konzept gehören die technischen Details, wie eine Rolle in einem bestimmten System umgesetzt ist. Welche Gruppe in Active Directory welche Rolle trägt, welche Policy in Keycloak welche Anwendung freigibt, steht in der Systemdokumentation und ändert sich mit jeder Version. Das Konzept beschreibt die Regel, die Systemdokumentation die Umsetzung. Wer beides mischt, hat ein Dokument, das nach dem ersten Release veraltet ist und deshalb nie wieder gelesen wird.

Die ISO/IEC 27001:2022 fasst dieselben Inhalte in ihrem Anhang A zusammen. Control 5.15 verlangt Regeln für die Zugriffssteuerung, 5.16 das Management von Identitäten über ihren Lebenszyklus und 5.18 die Vergabe, Prüfung und Entfernung von Zugriffsrechten. Control 8.2 regelt die Behandlung privilegierter Rechte, 8.3 die Beschränkung des Zugriffs auf Informationen. Wer sein Konzept entlang dieser Controls gliedert, beantwortet im Audit jede Frage mit einem Verweis auf ein Kapitel.

Welche Vorgaben das Konzept erfüllen muss

Für Einrichtungen, die unter das BSI-Gesetz fallen, ist das Berechtigungskonzept keine Empfehlung mehr. Das Gesetz ist seit dem 6. Dezember 2025 in Kraft. § 30 Abs. 2 BSIG zählt die Risikomanagementmaßnahmen auf, die besonders wichtige und wichtige Einrichtungen umsetzen müssen; Nummer 9 nennt die Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen, Nummer 10 die Multi-Faktor-Authentifizierung. Absatz 1 verlangt dabei Verhältnismäßigkeit nach Risikoexposition, Größe und Umsetzungskosten. Ein Konzept für ein Haus mit achtzig Beschäftigten darf also schlanker sein als eines für einen Konzern.

Die Datenschutz-Grundverordnung verlangt in Art. 32 Maßnahmen, die dem Risiko angemessen sind, und nennt dabei ausdrücklich die Fähigkeit, Vertraulichkeit und Belastbarkeit der Systeme sicherzustellen. Art. 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Ein Berechtigungskonzept ist die praktische Umsetzung beider Artikel: Es sorgt dafür, dass personenbezogene Daten nur den Personen zugänglich sind, die sie für ihre Aufgabe brauchen. Fehlt es, hat die Aufsichtsbehörde bei einer Datenpanne einen leicht nachweisbaren Verstoß gegen Art. 32 in der Hand.

Beim IT-Grundschutz ist der Baustein ORP.4 Identitäts- und Berechtigungsmanagement der Maßstab, in der Edition 2023 mit Basis-Anforderungen zu Einrichtung und Löschung von Kennungen, zu Einrichtung, Änderung und Entzug von Berechtigungen, zur Dokumentation und zur Funktionstrennung, dazu Standard-Anforderungen wie ORP.4.A16 zu Richtlinien für Zugriffs- und Zugangskontrolle und bei erhöhtem Schutzbedarf ORP.4.A24 zum Vier-Augen-Prinzip für administrative Tätigkeiten. Das BSI stellt den Grundschutz auf Grundschutz++ um: Der Meilensteinplan nennt den 27. Oktober 2026 für die Vorstellung der Methodik auf der it-sa, ab dem 1. Januar 2027 ist eine Zertifizierung danach möglich, und der klassische IT-Grundschutz bleibt bis zum 30. November 2031 zertifizierbar. Wer heute entlang ORP.4 arbeitet, kann die Anforderungen später in den Anwenderkatalog überführen.

Rollen bauen, ohne in der Rollenexplosion zu landen

Das häufigste Scheitern beim Rollenbau ist der Versuch, jede Besonderheit abzubilden. Eine Rolle für die Buchhaltung, eine für die Buchhaltung mit Zahlungsfreigabe, eine für die Buchhaltung mit Zahlungsfreigabe und Zugriff auf das Archiv. Nach einem Jahr gibt es mehr Rollen als Personen, und der Eigentümer kann in der Rezertifizierung nicht mehr sagen, was eine Rolle bedeutet. Der Ausweg ist ein Schnitt in zwei Ebenen: eine kleine Zahl fachlicher Grundrollen, die neunzig Prozent des Bedarfs decken, und einzeln genehmigte Zusatzrechte für den Rest, mit Ablaufdatum.

Rechte werden an Rollen vergeben, Rollen an Gruppen, Personen werden Mitglied von Gruppen. In Active Directory ist das das bekannte Muster aus globalen Gruppen für Personen und domänenlokalen Gruppen für Ressourcen, in Entra ID sind es Sicherheitsgruppen und Rollenzuweisungen, in Keycloak Gruppen mit zugeordneten Rollen und zusammengesetzte Rollen. Das gemeinsame Prinzip: Ein einzelnes Recht wird nie direkt an eine Person gebunden, denn ein direkt vergebenes Recht taucht in keiner Rollenliste auf und übersteht jede Rezertifizierung unbemerkt.

Technische Konten für Dienste, Schnittstellen und Automatisierung brauchen dieselbe Behandlung wie Personen, nur mit anderem Eigentümer. Jedes technische Konto hat einen verantwortlichen Menschen, einen dokumentierten Zweck, die geringstmöglichen Rechte und ein Datum, an dem es überprüft wird. In vielen Häusern sind diese Konten die eigentlichen Hochrisikokonten mit weitreichenden Rechten, einem Passwort, das nie wechselt, und einem Ersteller, der das Unternehmen vor Jahren verlassen hat. Ein Konzept, das sie ausklammert, lässt die größte Lücke offen.

Rezertifizierung, die etwas verändert

Eine Rezertifizierung hat nur dann einen Wert, wenn sie Rechte entfernt. Deshalb braucht sie drei Regeln, die vor dem ersten Durchlauf feststehen: Jede nicht bestätigte Zuweisung wird nach Fristablauf entzogen. Der Eigentümer sieht zu jeder Zeile, wann das Recht vergeben wurde, wer es genehmigt hat und wann es zuletzt genutzt wurde. Und der Prüfende darf nicht die Person sein, deren Rechte geprüft werden. Werkzeuge wie die Zugriffsüberprüfungen in Microsoft Entra ID Governance liefern Empfehlungen auf Basis der letzten Anmeldung und entziehen den Zugriff automatisch, setzen aber eine passende Lizenz voraus.

Der Takt richtet sich nach dem Schutzbedarf. Systeme mit Gehalts-, Gesundheits- oder Finanzdaten und alle privilegierten Rollen werden vierteljährlich geprüft, der Rest jährlich. Wichtig ist, dass die Prüfung nicht nur Personen betrachtet, sondern auch Rollen: Hat sich der Inhalt einer Rolle verändert, weil jemand ein Recht nachträglich hinzugefügt hat, muss der Eigentümer das sehen. Eine Rolle, die still gewachsen ist, verteilt das neue Recht an alle ihre Mitglieder, ohne dass jemand einen Antrag gestellt hat.

Das Ergebnis jeder Rezertifizierung ist ein archivierter Nachweis: Datum, Prüfer, Anzahl der geprüften Zuweisungen, Anzahl der entzogenen Rechte, offene Ausnahmen mit Begründung. Dieser Nachweis ist das, was ein Auditor nach ISO/IEC 27001, ein Prüfer der Aufsichtsbehörde oder der Wirtschaftsprüfer im Rahmen der IT-Prüfung sehen will. Er beweist nicht, dass alle Rechte richtig sind, aber dass das Haus seine Rechte kennt und regelmäßig entscheidet.

Dazu passende Kurse

Wenn bei euch niemand sicher sagen kann, wer ein Recht genehmigt hat, geben dir Kurse zu Rollenmodellen, Need-to-know und Rechteentzug im laufenden Betrieb den Rahmen, um das Konzept von den Eigentümern her aufzubauen.

Weil die Rezertifizierung ohne Werkzeug an der Masse scheitert, lohnen sich Trainings zu Zugriffsüberprüfungen und privilegierten Rollen in Entra ID, sobald der Mandant mehr als eine Handvoll Administratoren hat.

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest Microsoft 365 Grundlagen QuizTeste dein Wissen zu Teams, SharePoint, OneDrive, Outlook und der Zusammenarbeit an Dokumenten. Quiz starten

04 Konkrete Kurse

Wo du genau das übst

Weitere Kurse aus diesem Bereich

Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle IT-Security-Schulungen mit Terminen.

Stimmen aus den Kursen

Was Teilnehmende über die Kurse in diesem Bereich sagen

Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Monitoring mit Prometheus und Grafana - Grundkurs
Super Dozent mit vielen Praxisbeispielen so dass ich mich gleich für den folge Kurs interessiere.
Certified SOC-Analyst (CSA)
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
SELinux Training: Grundlagen und Administration (SEL1)

05 Fragen

Häufige Fragen

Deine Frage ist nicht dabei? Stell sie uns direkt, wir antworten dir persönlich.

Wie fangen wir an, wenn es noch gar kein Berechtigungskonzept gibt?
Mit einer Liste der Systeme, die schutzbedürftige Daten halten, und einem Eigentümer je System. Danach exportierst du für die drei wichtigsten Systeme die aktuellen Zuweisungen und legst sie dem Eigentümer vor. Dieser erste Durchlauf entfernt meist ein Fünftel der Rechte und zeigt dem Haus, wozu das Konzept dient. Das Dokument selbst schreibst du danach, mit dem Wissen aus dieser ersten Bereinigung.
Wer sollte das Berechtigungskonzept unterschreiben?
Die Geschäftsführung, weil sie für die Angemessenheit der Maßnahmen nach Art. 32 DSGVO und, falls das BSI-Gesetz gilt, nach § 30 BSIG verantwortlich ist. Der Informationssicherheitsbeauftragte erstellt und pflegt das Dokument, die Eigentümer der Systeme tragen die Entscheidungen im Alltag. Ohne die Unterschrift der Leitung fehlt dem Konzept die Autorität, einem Fachbereich ein Recht zu verweigern.
Wie viele Rollen sind angemessen?
Eine feste Zahl gibt es nicht, aber ein Prüfstein: Kann der Eigentümer in einem Satz sagen, welche Tätigkeit eine Rolle abbildet? Wenn für eine Rolle mehrere Sätze nötig sind oder sie nur eine Person hat, ist sie keine Rolle, sondern eine Ausnahme. Ausnahmen sind erlaubt, brauchen aber Begründung und Ablaufdatum und werden getrennt gezählt. Gibt es am Ende mehr Ausnahmen als Rollenzuweisungen, ist der Schnitt der Rollen falsch.
Reicht es, die Rechte im Verzeichnis zu regeln?
Nein. Fachanwendungen mit eigener Benutzerverwaltung, Datenbanken, Cloud-Konsolen und SaaS-Dienste halten einen großen Teil der schutzbedürftigen Zugriffe. Das Konzept muss sie alle in den Geltungsbereich nehmen, auch wenn die Umsetzung je System verschieden ist. Wo möglich, bindest du die Anwendung an den zentralen Identitätsdienst an, damit Eintritt und Austritt dort wirken. Wo das nicht geht, braucht die Anwendung einen eigenen Rezertifizierungslauf.
Was tun wir mit Rechten, die niemand mehr begründen kann?
Entziehen, mit einer Beobachtungsfrist. Ein Recht, das in der Rezertifizierung niemand bestätigt, wird nach Ablauf der Frist entfernt und kann über den normalen Antragsweg wieder beantragt werden. Dann liegt die Begründung vor, und der Eigentümer hat sie gesehen. Die Angst, damit einen Prozess zu stören, ist fast immer unbegründet: Die Rückfragen bleiben wenige, und jede davon betrifft ein Recht, das vorher ohne Begründung existierte.
Wie passt das Konzept zu NIS2 und zum IT-Grundschutz?
Beide verlangen dasselbe Dokument. Das BSI-Gesetz nennt in § 30 Abs. 2 BSIG Zugriffskontrolle und Multi-Faktor-Authentifizierung als Pflichtmaßnahmen, der Baustein ORP.4 beschreibt, wie das Konzept dafür aussehen muss, von der Einrichtung und Löschung von Kennungen bis zur Funktionstrennung. Wer sein Berechtigungskonzept entlang ORP.4 gliedert und die Rezertifizierungen archiviert, hat für die Nachweispflichten nach dem BSI-Gesetz und für ein Audit nach ISO/IEC 27001 denselben Beleg in der Hand.

Passt thematisch dazu

Wer die Rolle des Eigentümers aller Identitätsprozesse besetzen will, liest auf der Berufsseite nach, was der Beruf im Identity- und Access-Management im Alltag verlangt.

Für die Cloud gelten dieselben Grundsätze, aber andere Werkzeuge; wie Rollen, Policies und Konten dort zusammenspielen, zeigt die Seite über ein tragfähiges Berechtigungskonzept für AWS IAM.

Die Liste der unvereinbaren Rechte ist im ERP-System am längsten; wie du kritische Rechtekombinationen im SAP-System erkennen und bewerten kannst, steht auf einer eigenen Seite.

Quellen

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem IT-Security-Programm den passenden Kurs für deinen Stand zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

0800 71 20000 E-Mail

Rollen, Freigaben und Rezertifizierung an echten Systemen durchspielen

In den Identitätskursen bei cmt baust du in Keycloak oder Entra ID ein Rollenmodell auf, richtest Genehmigungen und Zugriffsüberprüfungen ein und siehst an einer eigenen Umgebung, wo die Rechtevergabe im Alltag ausfranst. Die Trainer kommen aus dem Betrieb und zeigen, welche Entscheidungen vorher im Haus gefallen sein müssen.

Alle Kurse und Termine Frage stellen

Verwandte Themen

Alle Themen zu IT-Security