Упорядкування прав доступу: прагматичний підхід до ролей, груп і рецертифікації

Freitag, 16:40 Uhr. Ein Ticket ploppt hoch: „Ich komme nicht mehr in die Freigabe-Maske.“ Der Fachbereich hängt eine Screenshot-Beschreibung an, der Service Desk findet drei alte Berechtigungsanträge und eine Projektgruppe von vor zwei Jahren. Im Verzeichnisdienst sieht alles „irgendwie plausibel“ aus – nur: Niemand kann sagen, ob diese Gruppe noch gebraucht wird. Gleichzeitig fragt die Revision nach Nachweisen für das kommende Audit. Der entscheidende Moment ist nicht die Fehlermeldung. Es ist die Frage, die danach kommt: „Wollen wir jetzt wieder nur reparieren – oder Berechtigungen aufräumen, so dass solche Fälle künftig planbar werden?“

Die weniger hilfreiche Reaktion ist schnell und vertraut: Eine zusätzliche Gruppenmitgliedschaft wird gesetzt, das Ticket wird geschlossen, die Woche ist gerettet. Der Preis kommt später: mehr Ausnahmegruppen, mehr indirekte Rechte, weniger Überblick, höhere Angst vor Entzug. Die bessere Reaktion wirkt auf den ersten Blick langsamer, ist aber die einzige, die dauerhaft Zeit spart: Der akute Zugriff wird wiederhergestellt – und gleichzeitig wird festgehalten, welche Rolle eigentlich gemeint war, welche Gruppe das technisch abbildet, wer fachlich verantwortet und wie dieser Zugriff bei der nächsten Rezertifizierung geprüft wird.

Warum das Thema genau dann brennt, wenn es „eigentlich nur ein Ticket“ ist

Berechtigungen bleiben oft unsichtbar, solange alles funktioniert. Sichtbar werden sie in vier Situationen: wenn der Zugriff fehlt, wenn Daten zu breit sichtbar sind, wenn ein Stellenwechsel Rollen nicht sauber nachzieht oder wenn Audits und Kundenanforderungen Nachvollziehbarkeit verlangen. Technisch steckt dahinter Zugriffskontrolle: Authentifizierung (wer ist es?) und Autorisierung (darf die Person diese Aktion oder diese Daten?). Organisatorisch steckt dahinter Ownership: Wer entscheidet über Rollen, Ausnahmen und Entzug?

Das BSI verankert das Need-to-know- bzw. Least-Privilege-Prinzip: Rechte sollen nur nach tatsächlichem Bedarf vergeben werden, nicht „für später“ oder als pauschale Absicherung^[Quelle]. Die praktische Folgerung ist unbequem, aber hilfreich: Jede unklare Gruppe und jede „temporäre“ Ausnahme ohne Enddatum ist ein Prozessproblem, kein reines AD-Problem. NIST SP 800-171 r3 geht einen Schritt weiter und fordert ausdrücklich, Privilegien, die Rollen oder Benutzerklassen zugewiesen sind, in organisationsdefinierter Frequenz zu überprüfen, um die Notwendigkeit zu validieren^[Quelle]. Daraus folgt: Rezertifizierung ist nicht „nice to have“, sondern die Mechanik, die aus einem einmaligen Aufräumen eine dauerhaft prüfbare Steuerung macht.

Szenarioanalyse: Zwei Reaktionsmuster – und was sie in drei Monaten auslösen

Reaktion A: „Hauptsache, es läuft wieder“

Akut ist diese Variante oft die schnellste. IT setzt eine zusätzliche Gruppenmitgliedschaft, manchmal direkt im Verzeichnisdienst, manchmal in der Anwendung. Dokumentiert wird höchstens der Gruppenname. Die Nebenwirkungen zeigen sich schleichend: Rollen werden zu Sammelbecken, Gruppen zu historischen Artefakten, Genehmigungen zu Ticket-Notizen. Beim nächsten Audit entsteht der Nachweis aus Excel-Listen und manuellen Erklärungen. Und im Betrieb wird Entzug zum Tabu, weil niemand den Impact vorhersagen kann.

Reaktion B: „Wir lösen den Fall so, dass Entzug planbar bleibt“

Hier wird ebenfalls schnell geholfen, aber mit Leitplanken. IT fragt gezielt: Welche Aufgabe wird gebraucht? Gibt es dafür eine Rolle? Welche Gruppe bildet sie ab? Wer verantwortet fachlich? Wenn es eine Ausnahme ist: bis wann, und was ist der Standardweg? Der Aufwand ist im Ticket vielleicht fünf bis zehn Minuten höher, verhindert aber Folgefälle. Vor allem entsteht ein wiederholbares Muster, das Rezertifizierung möglich macht: Entscheidungen werden nicht nur getroffen, sondern so abgelegt, dass sie später prüfbar sind.

Berechtigungen aufräumen in der Praxis: Rolle, Gruppe, RBAC und Rezertifizierung sauber trennen

Viele Diskussionen scheitern nicht an Technik, sondern an unscharfen Begriffen. Vier Bausteine sollten im selben Atemzug geklärt werden:

• Rolle: fachliche Beschreibung eines Aufgabenpakets, z. B. „Einkauf: Bestellanforderungen bearbeiten, keine Stammdaten ändern“.
• Gruppe: technisches Konstrukt (z. B. Active Directory- oder Entra-ID-Gruppe), über das Rechte zugewiesen werden. Gruppen sind häufig die „Transportebene“ für mehrere Systeme.
• RBAC (Role Based Access Control): Rollenbasierte Zugriffskontrolle: Rechte werden über Rollen gebündelt statt als Einzelrechte pro Nutzer verteilt. NIST beschreibt RBAC als Modell, das Verwaltung und Überprüfung vereinfacht, weil Zugriffe strukturierter und dadurch besser reviewbar werden^[Quelle]. Grenze: RBAC macht nur dann das Leben leichter, wenn Rollen verständlich und stabil geschnitten sind.
• Rezertifizierung / Access Review: regelmäßige, dokumentierte Bestätigung, dass Zugriff weiterhin erforderlich ist. Der Kern ist die Entscheidung (behalten/entziehen/befristen/ersetzen), nicht der Export.

Warum „einmal konsolidieren“ fast immer wieder auseinanderläuft

Ein einmaliges Aufräumen kann sinnvoll sein, aber es löst den Lebenszyklus nicht. In der Praxis kippen Berechtigungen aus drei Gründen:

• Joiner/Mover/Leaver läuft nebenher: Onboarding ist schnell, Stellenwechsel sind unvollständig, Offboarding entzieht nur das Hauptkonto, nicht alle indirekten Zugriffe über Gruppen oder Applikationsrollen.
• Ausnahmen werden nicht zurückgebaut: „Nur für das Projekt“ wird zum Dauerzustand, weil niemand ein Ablaufdatum setzt oder eine Wiedervorlage hat.
• Systeme pflegen Parallelwelten: Anwendungen haben eigene Rollenlisten, die nicht an einen zentralen Identity Provider (IdP, zentrale Instanz für Anmeldung und Identitäten) oder das Verzeichnis gekoppelt sind.

Das Ergebnis ist nicht nur Sicherheitsrisiko. Es ist operativer Aufwand: Jeder Sonderfall erzeugt Tickets, Abstimmungen und Unsicherheit. Genau deshalb sollte Rezertifizierung als Rhythmus betrachtet werden: Sie verhindert, dass sich das System stillschweigend wieder aufbläht.

Ein pragmatisches Vorgehen in 7 Schritten (ohne Big-Bang)

Das folgende Vorgehen ist bewusst so geschnitten, dass es im Tagesgeschäft startbar ist. Es liefert früh Effekte, ohne die Organisation mit einem Großprojekt zu blockieren.

1. Scope festlegen: Starten Sie mit 1–3 Systemen, die entweder sensible Daten führen oder viele Folgeanwendungen beeinflussen (typisch: IdP/AD, ein zentrales Portal, ein ERP-nahes System).
2. Inventar der Berechtigungsobjekte ziehen: Rollen, Gruppen, Applikationsrechte, privilegierte Konten, Service-Accounts. Notieren Sie pro System: Woher kommt die Liste, wie wird sie wiederholbar exportiert, wer kann sie interpretieren?
3. Owner erzwingen: Für jede Rolle/Gruppe muss eine verantwortliche Stelle existieren (Team/Funktion, nicht nur „Max Mustermann“). Objekte ohne Owner landen auf einer Klärungsliste mit Frist und definierter Default-Entscheidung.
4. Risikoklassen definieren: Mindestens „privilegiert“, „standard“, „lesend“. Ergänzen Sie eine einfache Datenklassifizierung (z. B. personenbezogen, vertraulich, intern). Daraus leiten Sie Review-Frequenzen ab.
5. Quick Wins umsetzen: Leaver-Prozess härten, privilegierte Gruppen bereinigen, „Jeder“-Zugriffe reduzieren, alte Projektgruppen mit Enddatum schließen oder in Betriebsrollen überführen.
6. Rollen konsolidieren und Gruppenstruktur stabilisieren: Doppelte Rollen zusammenführen, Ausnahmen befristen, Namens- und Lebenszyklusregeln einführen, die auch nach einem Jahr noch verstanden werden.
7. Rezertifizierung operationalisieren: Rhythmus, Entscheidungsformat, Eskalation und Nachweisablage festlegen. Ohne diesen Schritt ist Aufräumen nur Kosmetik.

Vergleichstabelle: Was Sie pro System mindestens festziehen sollten

Konstruierte Beispielsituation: Rezertifizierung so schneiden, dass sie nicht stecken bleibt

Rollen konsolidieren: Weniger Rollen sind nicht automatisch weniger Risiko

Der Impuls „Wir reduzieren Rollen drastisch, dann wird alles übersichtlich“ klingt vernünftig. In der Praxis kann er zwei gegenteilige Effekte erzeugen:

• Zu grobe Rollen führen zu breiten Rechten. Das erhöht den Schaden bei kompromittierten Accounts und macht Need-to-know faktisch unmöglich.
• Zu feine Rollen führen zu Rollenkombinationen, die niemand mehr reviewen kann. Der Alltag wird dann nicht sicherer, sondern nur administrativer.

Pragmatisch ist eine Dreiteilung, die sich rezertifizieren lässt:

• Basisrollen für den Großteil der Nutzer: wenige Varianten, stabil, sauber beschrieben.
• Erweiterungsrollen als additive Pakete für zusätzliche Aufgaben.
• Ausnahmen als bewusst befristete Abweichungen: begründet, mit Owner, mit Ablauf.

Ein guter Prüfpunkt für IT-Leitung und Projektverantwortliche: Wie hoch ist der Anteil rollenbasierter Zuweisungen gegenüber Einzelzuweisungen? Einzelzuweisungen können in Legacy-Systemen unvermeidbar sein, aber sie sind der teuerste Modus für Reviews und Audits, weil jede Zuweisung eine individuelle Geschichte braucht.

Gruppen aufräumen in Active Directory & Co.: Nachvollziehbarkeit zuerst, Perfektion später

In vielen Umgebungen ist das Verzeichnis (klassisch Active Directory, heute oft ergänzt um cloudbasierte Verzeichnisdienste) der zentrale Hebel. Gruppen sind schnell erstellt, aber schwer wieder zu entfernen, weil die Auswirkungen nicht transparent sind. Genau deshalb betonen Umsetzungshinweise zum BSI-Baustein ORP.4 die Nachvollziehbarkeit von Gruppenmitgliedschaften: Für jede Gruppenkennung soll eindeutig nachweisbar sein, welche Personen dazugehören^[Quelle]. Die Grenze dieser Quelle ist offen benannt: Es ist eine wiederveröffentlichte Fassung, nicht die primäre Publikation. Für die Praxis bleibt die Aussage trotzdem nützlich, weil sie genau den Kern des Problems trifft: Ohne nachvollziehbare Mitgliedschaften gibt es keine belastbare Rezertifizierung.

Zusätzlich lohnt ein Blick auf Strukturprinzipien statt auf Einzelfallpflege. Der BSI-Grundschutz nennt für Active Directory Domain Services eine geschichtete Berechtigungsstruktur nach Schutzbedarf als Architekturprinzip, um Angriffspfade über weitreichende Berechtigungen zu reduzieren^[Quelle]. Die Folgerung für das Aufräumen: Privilegierte Gruppen (Administration, Delegationen, hochkritische Applikationsrollen) gehören sichtbar getrennt und in einen häufigeren Review-Zyklus – statt zwischen Fachgruppen „unterzugehen“.

Was „Gruppen aufräumen“ konkret bedeutet

• Verwaiste Gruppen identifizieren: keine Owner, keine Beschreibung, unklarer Zweck.
• Projektgruppen schließen oder überführen: Enddatum setzen; falls eine Gruppe dauerhaft gebraucht wird, muss sie in eine Betriebsrolle mit Owner überführt werden.
• Namens- und Lebenszyklusregeln: Gruppenname und Metadaten (Beschreibung/Owner) so pflegen, dass Zweck und Systembezug erkennbar sind, ohne sensible Details zu verraten.
• Mitgliedschaften normalisieren: Wo möglich über Rollen/Jobfunktionen statt über „handgeschriebene“ Personenlisten.
• Privilegien separieren: Admin-nahe Gruppen restriktiv halten und häufiger rezertifizieren.

Rezertifizierung als Prozess: Entscheidungen erzeugen, nicht Listen erzeugen

Viele Organisationen scheitern nicht am Datenexport, sondern an der Entscheidung. Rezertifizierung wird dann zur „Listenübung“: Man verteilt Tabellen, sammelt Rückfragen, am Ende bleibt alles wie es ist. Das lässt sich vermeiden, wenn das Review-Format konsequent auf Entscheiden optimiert wird:

• Eine einheitliche Prüffrage: „Braucht Person X Rolle Y für Aufgabe Z?“ (Aufgabe Z muss in der Rollenbeschreibung stehen, nicht im Kopf einzelner Personen.)
• Vier Entscheidungstypen: behalten / entziehen / befristen / ersetzen durch Rolle A.
• Fixe Konsequenzen: Jede Entscheidung hat einen Folge-Workflow: Ticket, Change, Wiedervorlage, Eskalation.
• Eskalationsregel: Was passiert bei Nicht-Reaktion? Gerade für privilegierte Rechte ist eine klare Frist mit definierter Konsequenz oft besser als „wir erinnern noch dreimal“.

NIST SP 800-171 r3 liefert dabei eine klare Priorität: Die regelmäßige Prüfung von Rollenprivilegien ist gefordert, die Frequenz definiert die Organisation selbst. Praktisch heißt das: Starten Sie mit privilegierten Rollen (hoher Schaden bei Missbrauch, hoher Audit-Fokus) und erweitern Sie dann auf Standardrollen. So entsteht schneller eine sichtbar belastbare Kontrolle, ohne die Fachbereiche mit einem Vollreview zu überrollen.

Grenzen und Sonderfälle: Wo Pragmatismus endet

„Pragmatisch“ darf bei Berechtigungen nicht „lässig“ bedeuten. Es gibt Bereiche, in denen Änderungen ohne saubere Planung realen Schaden verursachen können:

• Produktionsnahe Admin-Rechte: Entzug ohne Rückfallplan kann Betriebsstörungen auslösen. Hier sind Change-Fenster, klare Ansprechpartner und eine Rückfalloption Pflicht.
• Service-Accounts und technische Identitäten: Sie hängen an Schnittstellen, geplanten Jobs und Integrationsflüssen. Änderungen müssen mit Monitoring und Runbooks (Betriebsanleitungen für wiederkehrende Aufgaben und Störungen) abgestimmt werden.
• Funktionstrennung (SoD): Kritische Kombinationen (z. B. Anlegen und Freigeben) sind oft prozessual geregelt und müssen im Rollenmodell bewusst verhindert oder kontrolliert werden.
• Legacy-Anwendungen: Manche Systeme können Rechte nur grob abbilden oder schlecht exportieren. Dann braucht es Kompensationskontrollen (z. B. restriktivere Zugänge, stärkere Protokollierung, kürzere Review-Zyklen) statt „wir bauen RBAC durch“.

Was sich nach dem Aufräumen im Alltag konkret verändert

Der Nutzen zeigt sich nicht in PowerPoint, sondern in Routinefällen:

• Service Desk: Weniger Tickets à la „Bitte freischalten“, mehr standardisierte Anträge mit klaren Genehmigern und nachvollziehbarer Rollenwahl.
• Fachbereiche: Onboarding wird schneller, weil Basisrollen existieren; Ausnahmen werden weniger, weil Erweiterungsrollen sauber verfügbar sind.
• IT-Betrieb: Änderungen werden kalkulierbarer, weil Entzugpfade dokumentiert sind und privilegierte Rechte sichtbar getrennt laufen.
• Projekte und Modernisierung: Neue Portale, REST-Schnittstellen oder Integrationen können Rollenlogik übernehmen, statt eine neue Parallelwelt an Einzelrechten zu erzeugen. Das reduziert spätere Reibung bei SSO (Single Sign-On, zentrale Anmeldung) und Audit-Nachweisen.

Der letzte Prüfpunkt: Aufräumen ist nur der Start, der Gewinn kommt aus dem Rhythmus

Wer Berechtigungen aufräumt, gewinnt nicht durch die perfekte Struktur am Stichtag. Der Gewinn entsteht, wenn Entscheidungen wiederholbar werden: Owner sind benannt, Rollen sind verständlich, Gruppen sind nachvollziehbar, Rezertifizierung läuft in einem festen Takt – und Entzug ist kein Drama, sondern ein planbarer Schritt. Dann werden Audits ruhiger, Störungen seltener und Veränderungen an Business-Software und digitalen Unternehmenslösungen deutlich leichter zu verantworten.

Für dieses Thema sind auch Active Directory Gruppen und Least Privilege wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.