Berechtigungskonzepte

Kurzantwort

Ein Berechtigungskonzept leitet jede Berechtigung aus einer dokumentierten Aufgabe ab. Es beschreibt Rollen und Verantwortliche, dazu Vergabewege und Kontrollen. Der Aufbau folgt dem Minimalprinzip und dem Prinzip der Funktionstrennung. Diese beiden Grundsätze fordert das BSI im Baustein APP.4.2. Rollen werden in Berechtigungsrollen gepflegt, im Entwicklungssystem geändert und transportiert. Technische Konten für Schnittstellen und Hintergrundverarbeitung erhalten einen eigenen Satz restriktiver Rollen. Dauerhaft hält ein solches Konzept nur mit Rezertifizierung, klaren Vertretungsregeln und befristeten Notfallberechtigungen.

Einordnung

In einem Utilities-System hängen an einer Berechtigung schnell Geld und Personendaten. Wer Zählerstände korrigiert, beeinflusst die Abrechnung. Wer Vertragskonten anlegt, entscheidet über Zahlungsströme. Wer im Marktprozess Nachrichten anstoßt, löst Zahlungen zwischen Marktpartnern aus. Ein Berechtigungskonzept ist deshalb ein betriebliches Steuerungsmittel, keine reine Systemadministration.

Die Anforderung ist nicht freiwillig. Das BSI verlangt für SAP-ERP-Systeme ausdrücklich, dass ein Konten- und Berechtigungskonzept ausgearbeitet und umgesetzt wird. Es muss Identitätsprinzip, Minimalprinzip, Stellenprinzip, Funktionstrennungsprinzip (Segregation of Duties, SoD), Genehmigungsprinzip und Schriftformprinzip berücksichtigen. Zusätzlich sind gesetzliche Vorgaben wie die Grundsätze ordnungsgemäßer Buchführung zu beachten (IT-Grundschutz-Kompendium, Baustein APP.4.2, Anforderung APP.4.2.A6). Auf der Datenschutzseite tritt die Datenminimierung hinzu: personenbezogene Daten sind auf das für den Zweck notwendige Maß zu beschränken (DSGVO, Artikel 5 Absatz 1 Buchstabe c). Für die Umsetzung verlangt Artikel 32 ein dem Risiko angemessenes Schutzniveau und eine regelmäßige Überprüfung der Wirksamkeit der Maßnahmen (DSGVO, Artikel 32 Absatz 1 Buchstabe d).

Aufbau einer SAP-Berechtigung

Eine Berechtigung besteht aus einem Berechtigungsobjekt und dessen Feldern. Das Objekt benennt den Prüfbereich, etwa Vertragskonto oder Fakturierung. Die Felder begrenzen den Zugriff, etwa auf eine Buchungsart, eine Sparte oder eine Organisationseinheit. Erst die konkrete Feldbelegung erlaubt eine Handlung.

Das BSI empfiehlt ein rollenbasiertes Berechtigungskonzept: Berechtigungen sollen in Berechtigungsrollen (PFCG-Rollen) angelegt, gespeichert und den Konten zugeordnet werden (IT-Grundschutz-Kompendium, APP.4.2.A6). In der Praxis unterscheiden Sie dabei drei Rollenarten. Eine Einzelrolle bündelt Berechtigungen für eine klar umrissene Aufgabe. Eine Sammelrolle fasst mehrere Einzelrollen zu einer Personalaufgabe zusammen. Eine technische Rolle trägt keine fachliche Aufgabe, sondern die Berechtigungen für Schnittstellen und Hintergrundjobs. Aus der Rolle entsteht beim Generieren das Berechtigungsprofil, das der Benutzerstammsatz erhält. Bei jedem Zugriff prüft das System die Feldbelegung.

Rollen sollen nur im Entwicklungssystem gepflegt und über das Transport-Management-System transportiert werden. Kritische Einzelaktionen, die sich in einer Rolle kaum vermeiden lassen, sollen durch kompensierende Kontrollen abgedeckt werden (IT-Grundschutz-Kompendium, APP.4.2.A6).

Trennen Sie drei Aufgaben strikt: Kontoadministration, Berechtigungsadministration und Profiladministration. Das BSI verlangt dafür getrennte Verantwortlichkeiten und damit getrennte Berechtigungen. Ohne diese Trennung kann sich eine Person eigene Rechte verschaffen.

Ableitung aus der Aufgabe

Arbeiten Sie von der Aufgabe zur Rolle, nie umgekehrt. Ein belastbarer Ablauf sieht fünf Schritte vor.

1. Aufgabe beschreiben. Erfassen Sie je Stelle die Tätigkeiten, die Datenobjekte und die Organisationseinheiten.
2. Rolle schneiden. Eine Rolle trägt genau die Berechtigungen dieser Aufgabe, keine Reserven.
3. Verantwortliche benennen. Die Fachabteilung legt Inhalt und Umfang der Rolle fest.
4. Antrag und Genehmigung regeln. Das Konzept beschreibt, wer beantragt, wer genehmigt, wer zuordnet.
5. Rezertifizieren. Prüfen Sie in festen Abständen, ob Rolle und Aufgabenprofil noch zusammenpassen.

Für das Design empfehlen die BSI-Anforderungen ein rollenbasiertes Berechtigungskonzept mit Namenskonventionen für Benutzerkennungen und technische Rollennamen. Vorschlagswerte und Prüfkennzeichen sollen in der Transaktion SU24 gepflegt werden. Die Gesamtberechtigung * und Intervalle in Objektausprägungen sind zu vermeiden (IT-Grundschutz-Kompendium, APP.4.2.A12). Diese Regel gilt auch für Utilities: Eine Rolle, die auf Organisationsebene mit * arbeitet, öffnet jedes Mandantenobjekt in der Sparte.

Ablauf im Betrieb

Der folgende Ablauf zeigt den Lebenszyklus einer Berechtigung. Er gilt für Neueintritt, Aufgabenwechsel, Vertretung und Austritt gleichermaßen.

Für den Notfall gilt eine eigene Regel. Notfallkonten sollen angelegt, stark kontrolliert und genau dokumentiert werden; alle Aktivitäten sind zu protokollieren (IT-Grundschutz-Kompendium, APP.4.2.A29). Die Berichtigung folgt unmittelbar nach dem Einsatz: Berechtigung entziehen, Protokoll auswerten, Vorfall dokumentieren.

Beispiel: Aufgabenwechsel und Notfall im Vertrieb

Vereinfachtes Beispiel für einen Energieversorger mit rund 200 SAP-Nutzern.

Eine Mitarbeiterin wechselt von der Marktkommunikation in die Fakturierung. In der Marktkommunikation trug sie eine Rolle für Nachrichtenverarbeitung, Prozessdokumente und IDoc-Monitoring. In der Fakturierung braucht sie Anlage und Pflege von Abrechnungsbelegen sowie Nachbearbeitung fehlerhafter Abrechnungen. Das Konzept schreibt vor, dass beide Rollen nicht gleichzeitig aktiv sind. Die alte Rolle wird am Tag des Wechsels entzogen, nicht am Monatsende.

Am Monatsabschluss fällt ein Kollege aus. Die Vertretung erhält die Fakturierungsrolle für vier Wochen, befristet im Benutzerstammsatz hinterlegt. Der Rollenverantwortliche dokumentiert Anlass und Enddatum. Nach Ablauf entfällt die Zuordnung automatisch.

Am dritten Wochenende scheitert ein Massenlauf. Die Bereitschaft nutzt daraufhin ein Notfallkonto mit erweiterten Rechten für die Hintergrundverarbeitung. Alle Aktivitäten landen im Protokoll. Am Montag prüft die Konto-Administration den Vorgang und setzt die Berechtigung zurück.

Funktionstrennung und kritische Kombinationen

Das BSI unterscheidet zwischen kritischen Einzelberechtigungen und kritischen Kombinationen. Kritische Berechtigungen, Rollen und Profile sollen restriktiv vergeben werden. Das gilt auch für kritische Rollenkombinationen und additive Effekte wie Kreuzberechtigungen. Kritische Berechtigungen sollen regelmäßig identifiziert, überprüft und bewertet werden. Die Profile SAP_ALL und SAP_NEW* sowie das Berechtigungsobjekt S_DEVELOP mit Änderungsberechtigungen sollen im Produktivsystem nicht vergeben werden (IT-Grundschutz-Kompendium, APP.4.2.A14).

Für den Utilities-Betrieb ergeben sich daraus typische Trennungslinien:

• Stammdaten und Zahlungsverkehr. Wer Geschäftspartner und Bankverbindung pflegt, darf keine Zahlungen auslösen.
• Abrechnung und Fakturierung. Wer Abrechnungsbelege erzeugt, darf sie nicht allein freigeben.
• Marktkommunikation und Kundenstammdaten. Wer Nachrichten anstoßt, darf die zugehörigen Stammdaten nicht unbemerkt ändern.
• Rollenpflege und Rollenzuordnung. Die Konto-, Berechtigungs- und Profiladministration bleiben getrennt.

Prüfen Sie solche Kombinationen nicht nur auf Rollenebene. Entscheidend ist die Summe der Rollen eines Benutzers. Zwei einzeln unkritische Rollen können gemeinsam genau die Kombination ergeben, die Sie ausschließen wollten.

Technische Benutzer und Schnittstellen

Schnittstellen und Hintergrundverarbeitung brauchen eigene Konten. Das Konzept muss technische Konten ausdrücklich abdecken, also auch Hintergrund- und Schnittstellenkonten (IT-Grundschutz-Kompendium, APP.4.2.A6). Für Batch-Jobs sollen mehrere Systemkonten nach Funktionsbereichen angelegt werden; der Benutzertyp Dialog soll dafür nicht verwendet werden (IT-Grundschutz-Kompendium, APP.4.2.A23).

Im Utilities-Betrieb betrifft das vor allem drei Fälle:

• IDoc-Eingang für Marktnachrichten, getrennt nach Nachrichtenart.
• Nachrichtenausgang mit Zugriff auf Prozessdokumente und Partnervereinbarungen.
• Periodische Läufe für Abrechnung, Fakturierung und Zahlungslauf.

Diese Konten erhalten keine Dialoganmeldung, keine persönliche Zuordnung und einen eigenen Namensraum. Halten Sie die Zahl der technischen Konten klein und je Konto den Zweck fest. Ein Sammelkonto für alle Schnittstellen macht jede Fehlersuche und jede Trennung unmöglich.

Folgen und Fehlerfälle

Die häufigsten Betriebsfehler haben ein Muster: Die Berechtigung entsteht aus einem konkreten Anlass und wird danach nicht mehr angefasst.

• Der Aufgabenwechsel wird nur fachlich vollzogen. Die alte Rolle bleibt jahrelang bestehen.
• Der Austritt wird im Personalsystem gebucht, das SAP-Konto bleibt aktiv.
• Die Vertretung erhält eine Dauerzuordnung statt einer Befristung.
• Das Notfallkonto wird zum Arbeitskonto, weil die Anmeldung bequem ist.
• Die Rezertifizierung prüft nur, ob das Konto existiert, nicht ob die Aufgabe noch passt.

Nachvollziehbarkeit ist die zweite Fehlerquelle. Änderungen an Rollen und Zuordnungen sollen über ein Änderungsmanagement laufen und überwacht werden. Das BSI fordert für Sicherheitsaufzeichnungen ein kontinuierliches Monitoring; bei verdächtigen Vorgängen sollen die zuständigen Mitarbeitenden alarmiert werden (IT-Grundschutz-Kompendium, APP.4.2.A32). Für Datenschutzfälle tritt Artikel 32 Absatz 4 hinzu: Beschäftigte mit Zugang zu personenbezogenen Daten dürfen diese nur auf Anweisung des Verantwortlichen verarbeiten (DSGVO, Artikel 32 Absatz 4).

Ein dritter Fehlerfall betrifft die Rolle selbst. Wird eine Rolle zur Sammelstelle für Sonderwünsche, verliert sie ihre Aussagekraft. Nach zwei Jahren hat niemand mehr einen Überblick, welche Aufgabe hinter der Rolle steht. Prüfen Sie deshalb vor jeder Rollenänderung, ob die Aufgabe geändert wurde oder nur ein Einzelfall gelöst werden soll.

Typische Missverständnisse

„Einmal konzipiert, gilt dauerhaft.” Das Konzept beschreibt einen Zustand, den es herstellen soll. Ohne Rezertifizierung driftet der Ist-Zustand davon ab.

„Die Rolle ist unkritisch, deshalb ist die Vergabe unkritisch.” Kritisch wird es in der Kombination. Bewerten Sie immer das gesamte Berechtigungsprofil eines Benutzers.

„Technische Konten brauchen keine Pflege.” Gerade sie tragen weitreichende Berechtigungen und werden selten geprüft. Das BSI verlangt ausdrücklich, sie im Konzept zu führen.

„Berechtigungsprüfung passiert beim Anmelden.” Die Prüfung erfolgt bei jedem Zugriff auf ein Objekt. Eine falsch belegte Rollenänderung wirkt sofort, ohne neue Anmeldung.

„Der Datenschutz verlangt andere Berechtigungen als die IT-Sicherheit.” Beide Anforderungen zeigen in dieselbe Richtung: Datenminimierung auf der einen Seite, Minimalprinzip und Rezertifizierung auf der anderen.

Quellen und Pflegehinweis

Tragende Grundlage ist der BSI-Baustein APP.4.2 SAP-ERP-System, Edition 2023 des IT-Grundschutz-Kompendiums. Die Anforderungen A6, A12, A14, A23 und A29 tragen die Aussagen zu Konzept, Rollenentwicklung, kritischen Berechtigungen, technischen Konten und Notfallkonten. Für die Datenschutzpflichten gilt die DSGVO in der konsolidierten Fassung, Artikel 5 und Artikel 32.

Eine neue Edition des IT-Grundschutz-Kompendiums erscheint jährlich. Prüfen Sie die Anforderungsnummern nach jedem Editionswechsel, weil sich Nummern und Schärfegrade ändern können. Im eigenen Haus ändern sich Rollenverantwortliche und Aufgabenprofile schneller. Legen Sie deshalb ein festes Rezertifizierungsintervall im Konzept fest und halten Sie es ein.