Alle Blogartikel

Berechtigungskonzept erstellen: So wird aus dem Dokument ein gelebtes Regelwerk im IAM

Berechtigungskonzept
Tim Lipphardt, Head of Consulting
LinkedIn

Tim Lipphardt
Head of Consulting

Das Wichtigste in Kürze

Regeln pro Rolle

Ein gutes Berechtigungskonzept beschreibt, wer was warum darf, und orientiert sich dabei an Rollen und Geschäftsprozessen.

Umsetzung im System

Die meisten Konzepte sind ein halbes Jahr nach dem Audit veraltet. Wirksam werden sie erst, wenn das IGA-Tool die Regeln durchsetzt.

Funktionstrennung automatisieren

SoD-Konflikte entstehen oft über mehrere Anwendungen hinweg. Ein IGA-Tool erkennt sie schon beim Antrag.

Grundlagen

Was ist ein Berechtigungskonzept?

Ein Berechtigungskonzept ist das verbindliche Regelwerk eines Unternehmens, das festlegt, wer auf welche Systeme, Daten und Funktionen zugreifen darf, unter welchen Bedingungen und mit welcher Begründung. Es beschreibt außerdem, wie Rechte beantragt, genehmigt, überprüft und wieder entzogen werden.

Leitlinie ist das Least Privilege Prinzip: Jede Person bekommt genau die Rechte, die sie für ihre Aufgabe braucht.

Berechtigungskonzept, Rollenmodell und IGA-Tool hängen eng zusammen, haben aber unterschiedliche Aufgaben:

  • Das Berechtigungskonzept legt die Regeln fest, zum Beispiel: „Lieferantenstammdaten ändert nur die Kreditorenbuchhaltung, und wer eine Zahlung anlegt, darf sie nicht selbst freigeben.“
  • Das Rollenmodell übersetzt diese Regeln in Rollen wie „Kreditorenbuchhalter“ mit einem festen Bündel an Rechten. Wie das mit rollenbasierter Zugriffskontrolle funktioniert, erklären wir in unserem Artikel zu RBAC im IAM.
  • Das IGA-Tool setzt beides durch. Es vergibt Rollen automatisch, blockiert verbotene Kombinationen und dokumentiert jede Änderung.

Praxis

Warum die meisten Berechtigungskonzepte in der Schublade landen

Die meisten Berechtigungskonzepte veralten, weil nach dem Audit niemand mehr daran arbeitet. In unseren Projekten begegnen uns dafür immer wieder drei Gründe.

Rechte pro System statt Regeln pro Rolle

Viele Konzepte sind im Kern eine Inventur: SAP hat diese Profile, das Active Directory diese Gruppen, das CRM diese Rollen. Warum jemand ein Recht hat, steht nirgends.

Ändert sich ein Geschäftsprozess, weiß deshalb niemand, welche Einträge angepasst werden müssen.

Kein Owner nach dem Audit

Für die Audit-Vorbereitung gibt es ein Projektteam. Danach löst es sich auf und das Dokument hat keinen Verantwortlichen mehr. Neue Rechte landen direkt im System, das Konzept bleibt, wie es ist.

Neue Systeme, altes Dokument

Neue SaaS-Anwendungen, der Umzug in die Cloud, ein zugekauftes Tochterunternehmen: Mit jeder Veränderung kommen neue Rechte dazu. Das Konzept bildet trotzdem weiter den Stand von vor zwei Jahren ab.

Vorlage

Was gehört in ein Berechtigungskonzept?

Ein vollständiges Berechtigungskonzept besteht aus neun Bausteinen. Nutze die Liste als Vorlage und Checkliste für dein eigenes Konzept.

  1. Geltungsbereich und Systeme: Welche Anwendungen, Datenbestände und Standorte das Konzept abdeckt und welche bewusst ausgenommen sind.
  2. Rollen und Verantwortlichkeiten: Wer Owner einer Anwendung oder Rolle ist, wer Anträge genehmigt und wer sie technisch umsetzt.
  3. Rollenmodell und Vergaberegeln: Welche Rollen es gibt, welche Rechte darin stecken und welche Rollen jemand automatisch über Abteilung oder Funktion erhält.
  4. Beantragungs- und Genehmigungswege: Wie zusätzliche Rechte beantragt werden und wer in welcher Reihenfolge zustimmt.
  5. Regeln zur Funktionstrennung (SoD): Welche Rechte eine Person nie gleichzeitig haben darf und wer Ausnahmen genehmigen kann.
  6. Privilegierte Zugänge und Notfallzugang: Wie Admin-Konten vergeben, abgesichert und überwacht werden und wie ein Notfallzugriff („Break Glass“) protokolliert wird. Mehr dazu in unserem Artikel zu Privileged Access Management.
  7. Joiner, Mover und Leaver: Was mit den Rechten beim Eintritt, beim Abteilungswechsel und beim Austritt passiert. Details findest du im Artikel zum Identity Lifecycle Management.
  8. Rezertifizierungsintervalle: Wie oft Führungskräfte oder Owner vergebene Rechte prüfen. Kritische und privilegierte Rechte kommen dabei häufiger dran als Standardrechte.
  9. Protokollierung und Nachweise: Welche Änderungen wie lange aufgezeichnet werden, damit du im Audit belegen kannst, dass die Regeln eingehalten wurden.
Berechtigungskonzept

Funktionstrennung

Funktionstrennung: Wo SoD-Konflikte im Alltag entstehen

Funktionstrennung (Segregation of Duties, kurz SoD) verteilt kritische Schritte eines Prozesses auf verschiedene Personen. So kann niemand allein Schaden anrichten oder Fehler vertuschen.

Typische SoD-Konflikte

  • Kreditor anlegen und Zahlung freigeben: Wer beides darf, kann einen fiktiven Lieferanten anlegen und ihm Geld überweisen.
  • Berechtigung beantragen und selbst genehmigen: Damit ist der Genehmigungsprozess ausgehebelt.
  • Buchung erfassen und Buchung prüfen: Aus dem Vier-Augen-Prinzip werden zwei Augen.
  • Benutzerkonten verwalten und Protokolle löschen: Wer Spuren beseitigen kann, macht jede Kontrolle wirkungslos.

Warum du dafür ein System brauchst

Ein Beispiel: Eine Mitarbeiterin bekommt im ERP die Rolle „Lieferantenpflege“. Ein Jahr später wechselt sie ins Controlling und erhält zusätzlich eine Rolle im Zahlungsverkehrssystem. Jede Rolle ist für sich unkritisch, zusammen ergeben sie genau den Konflikt, den dein Konzept verbietet.

Solche Kombinationen entstehen über verschiedene Systeme, verschachtelte Gruppen und lange Zeiträume. In einer Excel-Liste steht die Regel, wer sie gerade verletzt, zeigt sie dir nicht.

Das kann nur ein System, das alle Rechte aller Identitäten kennt und jede neue Zuweisung gegen die SoD-Regeln prüft.

Umsetzung

Vom Dokument zum System: So setzt dein IAM das Berechtigungskonzept durch

Damit dein IGA-Tool das Berechtigungskonzept durchsetzen kann, übersetzt du die Regeln in Rollen, Policies und Workflows.

1. Regeln in Rollen und Policies übersetzen

Aus „Die Kreditorenbuchhaltung pflegt Lieferanten“ wird eine Rolle mit festen Rechten plus eine Regel, wer sie automatisch bekommt. Lässt sich eine Regel nicht eindeutig formulieren, ist das Konzept an dieser Stelle noch zu vage.

2. Die Datenbasis prüfen

Automatische Rollenvergabe braucht saubere Stammdaten. Das HR-System sollte deshalb die autoritative Quelle für Abteilung, Funktion, Eintritt und Austritt sein. Sind die Daten dort falsch, vergibt das IGA-Tool falsche Rechte, und zwar zuverlässig. Mehr dazu in unserem Artikel zur Datenqualität im IAM.

3. Genehmigungswege als Workflow abbilden

Die Genehmigungswege aus dem Konzept werden zu Workflows. Anträge landen automatisch beim richtigen Genehmiger, bei Abwesenheit greift eine Vertretung und jede Entscheidung ist dokumentiert.

4. SoD-Regeln im System hinterlegen

Hinterlege die Konfliktpaare als Regeln im IGA-Tool. Ein Konflikt fällt dann schon beim Antrag auf. Ausnahmen bleiben möglich, brauchen aber eine dokumentierte Begründung und Zustimmung.

5. Rezertifizierung auf die Regeln ausrichten

Kritische Rollen und SoD-Ausnahmen kommen häufiger auf den Prüfstand, Standardrollen seltener. Führungskräfte prüfen damit gezielt die Rechte, die ein echtes Risiko darstellen. Wie das in der Praxis aussieht, liest du in unserem Artikel zur Rezertifizierung von Berechtigungen.

Unser Expertenrat: Fang mit den zwei oder drei Anwendungen an, in denen die kritischsten Daten liegen. Bring dort Konzept und System in Einklang und erweitere dann Schritt für Schritt.

Checkliste

Woran du merkst, dass dein Berechtigungskonzept gelebt wird

Ein gelebtes Berechtigungskonzept erkennst du daran, dass Abweichungen im laufenden Betrieb auffallen. Diese fünf Fragen zeigen dir, wo du stehst:

  • Wer entdeckt zu viele Rechte zuerst, dein System oder der Prüfer?
  • Hat jede Rolle einen Owner? Rollen ohne Verantwortlichen wachsen unkontrolliert.
  • Werden Rechte beim Abteilungswechsel automatisch entzogen? Mover sind die häufigste Ursache für angehäufte Rechte.
  • Erkennt dein System SoD-Konflikte schon beim Antrag?
  • Findest du jede Regel aus dem Dokument auch im System wieder? Falls nicht, ist eins von beiden veraltet.

FAQ

Häufige Fragen zum Berechtigungskonzept

Ist ein Berechtigungskonzept Pflicht?

 Ein Gesetz, das wörtlich ein „Berechtigungskonzept“ vorschreibt, gibt es nicht. DSGVO, NIS2 und DORA verlangen aber, dass Zugriffe kontrolliert und nachweisbar begrenzt werden, und das belegst du am einfachsten mit einem dokumentierten Konzept. Welche Pflichten konkret für dich gelten, hängt von Branche und Unternehmensgröße ab.

Wer ist für das Berechtigungskonzept verantwortlich?

 Die Gesamtverantwortung liegt bei der Unternehmensleitung, die sie meist an die IT-Sicherheit oder das IAM–Team delegiert. Für einzelne Anwendungen und Rollen braucht es zusätzlich fachliche Owner, weil nur sie beurteilen können, wer welche Rechte braucht. 

Wie oft sollte man es überprüfen?

 Das Konzept selbst prüfst du mindestens einmal im Jahr und immer dann, wenn neue Systeme, Prozesse oder Organisationsänderungen dazukommen. Die vergebenen Rechte kontrollierst du über regelmäßige Rezertifizierungen, kritische Rechte häufiger. 

Was ist der Unterschied zwischen Berechtigungskonzept und Rollenkonzept?

 Das Berechtigungskonzept legt fest, wer was darf, wer genehmigt und welche Kombinationen verboten sind. Das Rollenkonzept bündelt diese Regeln in konkrete Rollen und ist damit ein Teil des Berechtigungskonzepts. 

Brauche ich für ein Berechtigungskonzept ein IGA-Tool?

 Schreiben kannst du ein Berechtigungskonzept auch ohne IGA-Tool. Durchsetzen und nachweisen lässt es sich ab einer gewissen Zahl an Mitarbeitenden und Anwendungen kaum noch von Hand, spätestens bei Funktionstrennung über mehrere Systeme. 

Fazit

Ein Berechtigungskonzept wirkt erst im System

Ein Berechtigungskonzept, das nur als Dokument existiert, hilft dir im Audit und sonst wenig. Schutz bringt es erst, wenn dein IGA-Tool die Regeln bei jedem Antrag, Wechsel und Austritt automatisch anwendet.

Wie nah ist dein Konzept an deinem IGA-Tool?

Wir prüfen mit dir, welche Regeln aus deinem Berechtigungskonzept dein IGA-Tool heute schon durchsetzt und wo die Lücken liegen.

Dieser Beitrag entstand mit KI-Unterstützung. Veröffentlicht von amiconsult GmbH, fachlich geprüft von Sina Ruland.

Weitere Artikel