Grundschutz-Berechtigungsmanagement in der Praxis: Eintritt, Wechsel und Austritt

Eigene Auszählung im Anwenderkatalog Grundschutz++, Build 2026-10-29, rekursiv über alle Verschachtelungsebenen:

88 der 122 Anforderungen beider Praktiken haben keine Zielobjektkategorie. Nach Kapitel 3.4.1 von BSI-Standard 300-1 sind solche Anforderungen verpflichtend in das Anforderungspaket aufzunehmen, unabhängig von der Modellierung; anzuwenden sind bei normalem Schutzbedarf davon 83 auf normal-SdT, die 5 KANN-Anforderungen auf „erhöht“ sind nach Kapitel 3.4.2 optional. Für Berechtigungen und Personal entscheidet die Modellierung also wenig; die Arbeit liegt im Status und in den Belegen. Die übrigen Anforderungen hängen an Personengruppen und Systemen. Anhang 1 definiert Nutzende als „Alle natürlichen Personen, welche regelmäßig die Assets im Informationsverbund für die Institution benutzen können, unabhängig davon ob sie aus Sicht der Institution intern oder extern sind.“ Mitarbeitende sind Nutzende, die von der Institution beschäftigt werden, Administrierende sind Mitarbeitende mit Administrationsauftrag. Das ist für den Austritt wichtig: PERS.6.1 und PERS.6.1.1 hängen an Nutzenden und gelten damit auch für externe Beraterinnen und Berater.

Viele Anforderungen in BER und PERS lassen den eigentlichen Wert offen. Nach Kapitel 3.5 von 300-1 konkretisiert die Institution diese Parameter bei oder nach der Erstellung des Anforderungspakets. Ohne festgelegten Wert lässt sich kein Status vergeben, weil offen bleibt, wogegen geprüft wird. Die LSM legt fest (fiktiv):

Fiktives Beispiel. Anforderungen aus dem Anwenderkatalog Grundschutz++ (Build 2026-10-29), als Infinitiv gekürzt, Modalverb und Zielobjektkategorie in Klammern („ohne“ = ohne Zielobjektkategorie). Prüffragen, Belege und Rollen sind erfunden; die Tabelle ist eine Auswahl entlang der drei Ereignisse.

Zur Löschung lohnt ein Blick in die Erläuterung zu BER.2.5: Die Anforderung ist auch durch Löschen der Identität erfüllt, „Empfehlenswert ist die Löschung jedoch erst nach Ablauf längerer Löschfristen, um die Nachvollziehbarkeit von Aktionen im Audit Log zu erhalten.“ Deaktivieren am letzten Arbeitstag und Löschen nach Fristablauf sind daher zwei getrennte Schritte mit zwei Belegen.

BER.4.4.1 verlangt, dokumentierte und tatsächlich vergebene Berechtigungen regelmäßig auf Übereinstimmung zu überprüfen, BER.1.4 ein Inventar der Berechtigungen mit Personen, Identitäten, Zugangskonten, Berechtigungen und ihrer Zuordnung. Erst der Abgleich zeigt, ob die Ereignisse oben wirken. Abgleichprotokoll der LSM, fiktive Zahlen:

Befund 1: Externe fallen durch. Das Personalsystem kennt nur Mitarbeitende. Der Austritt von Externen kommt aus dem Vertragsende beim Dienstleister, und dafür gibt es keinen Auslöser. Die LSM setzt BER.2.5 und PERS.6.1.1 auf „nicht erfüllt“ und ordnet die Nichterfüllung als temporär ein: Die Vertragsliste der Dienstleistersteuerung wird bis zum nächsten Quartal als zweite Quelle an den Identitätsdienst angebunden. Das passt zu DLS.4.1.2, nach der die für einen Vertrag benötigten Berechtigungen bei Vertragsende unverzüglich zu deaktivieren sind; den Beschaffungsteil zeigt Beschaffung und Dienstleister. Die sieben Konten werden sofort gesperrt; ob über sie nach Vertragsende zugegriffen wurde, klärt eine Auswertung der Anmeldeprotokolle (siehe Detektion und Vorfallsbearbeitung).

Für die temporäre Nichterfüllung nennt 300-1 zwei Stellen, die sich nicht ohne Weiteres decken: Nach Kapitel 4.1.2 löst sie keine Risikobetrachtung aus, nach Kapitel 2.11 ist für SOLLTE-Anforderungen in der Umsetzungsplanung eine Restrisikobetrachtung durchzuführen und das Risiko von der Institutionsleitung freizugeben; Kapitel 4.1.1 verlangt, das Risiko zu identifizieren und der Leitung mitzuteilen. Das ist eine offene Auslegungsfrage. Die LSM beschreibt das Restrisiko, teilt es mit und lässt es befristet freigeben.

Befund 2: Wechsel ohne Entzug. Der Wechsel von Herrn W. lief als zwei Tickets, Neuvergabe und Entzug, und das zweite blieb liegen. Die Vorgehensweise nach BER.4.8 ist vorhanden, wirkt aber im Wechselfall nicht zuverlässig. Die LSM setzt BER.4.8 und PERS.2.3.1 auf „nicht erfüllt“ und ordnet die Nichterfüllung als temporär ein. Die LSM ändert die Vorgehensweise so, dass der Wechsel ein einziger Vorgang ist, der die alte Rolle entzieht, bevor die neue freigegeben wird. Ob über die doppelte Rolle Stammdaten geändert wurden, zeigt das Protokoll der Stammdatenänderungen nach BER.2.4. Die Frist für die Umstellung steht im Umsetzungsplan.

Ein MUSS-Befund wäre hier anders zu behandeln: Fehlten etwa die Verfahren und Regelungen zum Identitäts- und Berechtigungsmanagement (BER.1.1, MUSS), müsste die LSM sie festlegen; eine Risikobetrachtung ersetzt nach Kapitel 4.1.2 keine MUSS-Anforderung, und eine Risikoakzeptanz ist nicht möglich.

• Personalsystem → Identitätsdienst: Eintritt, Wechsel und Austritt als Ereignis mit Datum. Ohne diese Übergabe gibt es für BER.3.9 (ereignisgesteuerte Deaktivierung) kein Ereignis.
• Dienstleistersteuerung → Identitätsdienst: Vertragsbeginn und Vertragsende für externe Nutzende. Im Fall fehlte genau diese Übergabe.
• Führungskraft → Berechtigungsverwaltung: Freigabe und Begründung jeder Rolle (BER.3.2, BER.4.2, BER.4.3) und die Bestätigung im Quartalsabgleich (BER.4.4).
• Berechtigungsverwaltung → ISB: der Export der tatsächlich vergebenen Berechtigungen. Den Abgleich nach BER.4.4.1 führt im Fall der ISB durch; die Berechtigungsverwaltung vergibt die Berechtigungen und prüft sich so nicht selbst. Das Protokoll ist der Nachweis für BER.4.4 und BER.4.4.1. Die Trennung lässt sich aus PERS.2.3.3 ableiten, die zwischen Implementierung von Sicherheitsanforderungen und deren Überprüfung eine Rollentrennung verlangt; denselben Gedanken enthält Kapitel 4.5 von 300-1 für die Fortschrittsverfolgung des Umsetzungsplans.
• Austritt → Detektion: gesperrte Konten bleiben im Monitoring. Eine Anmeldung an einem deaktivierten Konto ist ein Ereignis, das bewertet werden muss.

Wie Sie die Belege mit Datum und prüfender Person nach Kapitel 4.3 ordnen, zeigt der Nachweisplan. Ein Export der Konteneinstellungen aus dem Identitätsdienst ist ein automatisierter Nachweis; was dazu festzuhalten ist, beschreibt Automatisierte Nachweise.

1. Sind alle Parameter in BER und PERS festgelegt, insbesondere die autorisierenden Rollen (BER.3.2, BER.4.2) und die Turnusse (BER.2.3, BER.4.4, BER.4.4.1)?
2. Entsteht jede Identität aus einer Quelle, die auch den Austritt kennt, für Mitarbeitende und für Externe?
3. Ist jedem Zugangskonto genau eine Identität zugeordnet, und sind technische Konten mit verantwortlicher Person im Inventar (BER.3.5, BER.1.4)?
4. Werden Berechtigungen über Rollen vergeben, mit Freigabe und Begründung (BER.4.1.1, BER.4.2, BER.4.3)?
5. Entzieht ein Wechsel die alte Rolle, bevor die neue gilt, und ist die Rollentrennung geprüft (BER.4.8, PERS.2.3)?
6. Haben Administrierende getrennte Administrationskonten mit MFA (BER.3.6, BER.5.9)?
7. Werden bei einem Austritt auch Gruppenkonten, Notfallzugänge und Authentifizierungsmittel behandelt (BER.3.19, BER.3.18, BER.5.3)?
8. Sind Deaktivierung und Löschung getrennte Schritte mit eigenem Termin (BER.2.5, BER.2.6, BER.3.15)?
9. Zeigt der regelmäßige Abgleich, dass das alles wirkt, und wer prüft ihn (BER.4.4.1, PERS.2.3.3)?

Blackfort Technology unterstützt Sie dabei mit Paket C der Umsetzung nach Grundschutz++: Statusermittlung je Anforderung, darunter BER und PERS, Festlegung der Parameter mit Ihnen und ein Nachweisplan, der Personalereignisse, Identitätsdienst und Abgleich verbindet.

• Status und Abweichungen vergeben Sie wie unter Anforderungen bewerten, Abweichungen dokumentieren beschrieben. „Nicht anwendbar“ ist nach Kapitel 4.1.1 nur zulässig, wenn die Komponente im Informationsverbund nicht existiert oder die Anforderung funktional nicht erfüllt werden kann. Gibt es keine Gruppenkonten, nennt die Erläuterung zu BER.3.18 die Anforderung entbehrlich; im Status lässt sich das dem ersten Grund zuordnen, mit Begründung.
• Bleibt eine SOLLTE-Anforderung dauerhaft unerfüllt, etwa weil ein Altsystem keine getrennten Administrationskonten kennt, folgt eine Risikobetrachtung; siehe Risikoanalyse.
• Wie Zugangsrechte auf Systemen technisch eingeschränkt werden, gehört zur Praktik KONF; den Abgleich von Soll und Ist zeigt Konfiguration und Assets.
• Wie Sie die Unterweisungen nach PERS.4.2 planen und ihre Wirkung prüfen, zeigt Sensibilisierung.
• Arbeitsrechtliche Fragen, etwa zum Umfang einer Überprüfung der Vertrauenswürdigkeit nach PERS.3.6 oder PERS.5.3, klären Sie mit Ihrer Rechtsabteilung und der Personalvertretung.