Inhaltsverzeichnis
Das Wichtigste vorab
Wie werden GxP-Berechtigungen in SAP S/4HANA validiert?
GxP-Berechtigungen in SAP S/4HANA werden anhand der erlaubten und verbotenen Tätigkeiten einer Rolle geprüft. Entscheidend sind nicht allein sichtbare Apps, sondern wirksame Zugriffe auf Objekte, Organisationseinheiten und kritische Statuswechsel. Testen Sie deshalb mit echten Testrollen auch unerlaubte Aktionen, alternative Zugriffswege und die Kombination mehrerer Rollen.
Einordnung und Geltungsbereich
Der Schwerpunkt liegt auf der fachlichen Zugriffskontrolle im freigegebenen S/4HANA-Prozess. Ein allgemeines Sicherheitskonzept oder eine Segregation-of-Duties-Analyse kann dafür wichtige Grundlagen liefern, ersetzt jedoch nicht den Nachweis der konkreten GxP-Anwendung.
Vom Rollennamen zur prüfbaren Tätigkeit
Betrachten Sie die wirksame Gesamtberechtigung. Eine eng begrenzte Fachrolle kann durch eine zusätzliche Supportrolle erweitert werden. Testen Sie besonders Kombinationen, die in der Praxis tatsächlich vergeben werden. Eine fachlich unerlaubte Aktion sollte auch dann verhindert werden, wenn der Nutzer einen anderen Einstieg als die gewöhnliche Fiori-Kachel wählt.
Technische Konten benötigen einen eigenen Prüfpfad. Hier geht es um den erlaubten Schnittstellenumfang, die Zuordnung zur verantwortlichen Stelle und die kontrollierte Verwaltung der Zugangsmittel. Ein Sammelkonto darf nicht als bequemer Ersatz für die persönliche Zuordnung menschlicher Entscheidungen dienen.
Edition, Oberfläche und fachliche Aktion auseinanderhalten
Ein Berechtigungskonzept für S/4HANA muss zur eingesetzten Edition und Architektur passen. On-Premises, Private Edition und Public Edition verwenden nicht in jeder Hinsicht dieselben Verwaltungswege. SAP-Dokumentation zu einer Cloud-Edition darf deshalb nicht ungeprüft als Anleitung für jede Landschaft übernommen werden. Erfassen Sie auch Fiori, Hintergrundverarbeitung und angebundene Systeme.
Beginnen Sie mit der fachlichen Aktion: Wer darf einen qualitätsrelevanten Materialparameter ändern, einen Status setzen oder einen Freigabeschritt ausführen? Ergänzen Sie organisatorische Grenzen wie Werk oder Gesellschaft, soweit sie im Prozess verwendet werden. Erst danach wird die technische Umsetzung beurteilt. Eine sichtbare Kachel oder eine Rolle mit passendem Namen beweist die erlaubte Aktion nicht.
Erfassen Sie tatsächliche Benutzerkombinationen. Ein Mitarbeiter kann über mehrere Rollen, Gruppen oder technische Wege Zugriff erhalten. Das Konzept sollte deshalb zwischen genehmigter Aufgabe, zugewiesener Berechtigung und tatsächlich wirksamer Aktion unterscheiden. Individuelle Ausnahmen und administrative Zugänge werden sichtbar bewertet statt als unbedeutende Sonderfälle ausgeblendet.
Eine Funktionsmatrix mit überprüfbaren Grenzen
Formulieren Sie je kritischer Aktion einen positiven und einen negativen Fall. Ein berechtigter Benutzer soll beispielsweise einen vorgesehenen Status ändern können. Ein nur lesender Benutzer soll denselben Schritt nicht ausführen können. Ergänzen Sie einen unzulässigen organisatorischen Bereich, wenn diese Grenze relevant ist. Prüfen Sie das Geschäftsobjekt und dessen Folgewirkung.
Die folgende Matrix ist ein eigenes Planungsbeispiel. Sie schreibt keine universelle Funktionstrennung für jedes Unternehmen vor. Welche Kombination unzulässig ist, folgt aus Ihrem Prozess und seinen Risiken. Dokumentieren Sie auch akzeptierte Ausnahmen und deren Kontrollen, statt eine technisch nicht umgesetzte Idealtrennung zu behaupten.
| Kritische Aktion | Positiver Fall | Negativer Fall |
|---|---|---|
| Materialparameter ändern | Zuständiger Stammdatenbenutzer im erlaubten Bereich | Produktionsbenutzer ohne Änderungsaufgabe |
| Chargenstatus setzen | Benannte fachliche Rolle | Reine Leseberechtigung |
| Freigabeschritt ausführen | Im Verfahren befugter Entscheider | Nicht befugter Antragsteller |
| Schnittstelle beschreiben | Bezeichnete technische Identität | Zugriff auf nicht benötigte Objekte |
| Rollen pflegen | Autorisierte Administration | Gewöhnlicher Fachbenutzer |
Beispiel: Fiori-Test besteht, Hintergrundzugriff bleibt offen
Das Szenario ist konstruiert. Ein Benutzer darf eine qualitätsrelevante Einstellung in der Fiori-App nicht ändern. Der negative Test in der Oberfläche besteht. Eine zusätzliche technische oder Hintergrundberechtigung ermöglicht jedoch einen anderen Schreibweg. Ob ein solcher Weg existiert, muss in der konkreten Landschaft geprüft werden; der Artikel unterstellt keine bestimmte Standardlücke.
Erfassen Sie alle vorgesehenen und erreichbaren Wege zum kritischen Objekt. Testen Sie repräsentativ Oberfläche, relevante Schnittstelle und gegebenenfalls Hintergrundverarbeitung. Der Nachweis benennt Benutzer, Rolle, Systemstand, Objekt, Aktion und tatsächliches Ergebnis. Ein Testbericht sollte deutlich machen, welche Wege bewusst nicht im Umfang enthalten waren und weshalb.
Wird ein unerwünschter Zugriff gefunden, bewerten Sie dessen Quelle und Verwendung. Die Entfernung einer Rolle kann weitere notwendige Aufgaben beeinflussen. Prüfen Sie nach Korrektur daher sowohl die beabsichtigte Begrenzung als auch den erlaubten Geschäftsprozess. Eine pauschale Sperrung aller Benutzer kann einen Befund technisch beenden, ist aber kein ausreichendes dauerhaftes Betriebsmodell.
| Prüfebene | Eigene Aktion | Erwarteter Nachweis |
|---|---|---|
| Oberfläche | Kritische Änderung mit Lesebenutzer versuchen | Vorgesehene Ablehnung |
| Alternativer Weg | Bezeichneten Import oder Job bewerten | Keine ungeklärte Umgehung der Regel |
| Organisation | Aktion im nicht erlaubten Werk versuchen | Gewählte Bereichsgrenze wirkt |
| Kombination | Reale Mehrfachrollen abbilden | Gesamtrechte entsprechen der Aufgabe |
| Korrektur | Positive und negative Fälle wiederholen | Arbeitsfähigkeit und Begrenzung gemeinsam bestätigt |
Privilegierte Zugänge und Funktionstrennung bewerten
Administratoren benötigen unter Umständen weitreichende technische Möglichkeiten. Benennen Sie Zweck, Vergabe und Kontrolle. Unterscheiden Sie die Einrichtung eines Systems von dessen gewöhnlicher fachlicher Nutzung. Ein administrativer Zugang als dauerhafte Standardrolle für Freigaben erschwert eine nachvollziehbare Trennung von Aufgaben.
Wenn ein Notfallzugang vorgesehen ist, beschreiben Sie Auslöser, Dauer, Aufzeichnung und nachfolgende Bewertung. Eine kurze Gültigkeit allein beweist nicht die Angemessenheit der vorgenommenen Änderungen. Der Review sollte die tatsächlich ausgeführten kritischen Tätigkeiten und ihre fachliche Wirkung berücksichtigen. Welche technische Lösung verwendet wird, bleibt architekturabhängig.
Funktionstrennung wird aus den konkreten Risiken abgeleitet. Ein allgemeiner Konfliktkatalog kann unterstützen, ersetzt aber nicht die Bewertung Ihres Prozesses. Prüfen Sie, ob Erstellung, Änderung, Prüfung und Entscheidung so verbunden sind, dass eine unzulässige Selbstbestätigung verhindert oder angemessen kontrolliert wird. Dokumentierte Ausnahmen brauchen nachvollziehbare Gründe und wirksame Maßnahmen.
Änderungen am Rollenmodell kontrolliert übernehmen
Eine neue App, ein Transport oder eine geänderte Schnittstelle kann den benötigten Rechteumfang verändern. Verbinden Sie Rollenänderungen deshalb mit der Auswirkungsbewertung des Systems. Benennen Sie betroffene Benutzer und kritische Aktionen. Die Prüfung einer einzelnen geänderten Rolle deckt Wechselwirkungen mit bestehenden Zuweisungen nicht automatisch ab.
Erhalten Sie einen verständlichen Standnachweis. Er sollte zeigen, welche Rollen, organisatorischen Einschränkungen und Ausnahmen zum geprüften Zeitpunkt galten. Ein späterer Export kann einen anderen Zustand abbilden. Verknüpfen Sie Testdatum und Konfigurationsstand, damit der Nachweis tatsächlich dem freigegebenen Einsatz zugeordnet werden kann.
Im laufenden Betrieb werden Aufgabenwechsel, Austritt und Vertretung berücksichtigt. Ein periodischer Review sollte reale Berechtigungen und reale Aufgaben zusammenführen. Eine Unterschrift unter einer unverständlichen langen Rollenliste ist schwächer als eine gezielte Prüfung kritischer Kombinationen. Schulung und klare Verantwortlichkeit unterstützen diese Bewertung.
Arbeitsvorlage: kritische Aktion über mehrere Zugangswege prüfen
Definieren Sie ein Geschäftsobjekt und eine kritische Aktion. Im Beispiel darf eine Produktionsrolle einen Materialparameter lesen, aber nicht ändern. Erfassen Sie Oberfläche, relevante Hintergrundverarbeitung und vorhandene Schnittstellen. Für jeden Weg wird geklärt, welche Identität und welche tatsächliche Berechtigung wirken. Die Auswahl folgt der realen Landschaft.
Der negative Test wird vorab als eigene Sollregel beschrieben. Wenn ein alternativer Weg gar nicht vorgesehen ist, prüfen Sie dessen erreichbare Begrenzung angemessen. Wenn er benötigt wird, braucht er eine bewusst definierte Befugnis. Ein bestandener Fiori-Test darf nicht ohne weitere Grundlage als Aussage über sämtliche technischen Wege verwendet werden.
Bewerten Sie gefundene Lücken nach Quelle und Reichweite. Eine gemeinsam verwendete Rolle kann weitere Benutzer betreffen. Eine technische Korrektur darf benötigte Arbeit nicht unbegründet verhindern. Wiederholen Sie deshalb geeignete positive und negative Fälle und dokumentieren Sie die Entscheidung zu verbleibenden Ausnahmen.
| Prüffeld | Konstruierter Eintrag | Akzeptanzfrage |
|---|---|---|
| Fachliche Aufgabe | Lesen eines bezeichneten Materialparameters. | Benötigte Arbeit bleibt möglich. |
| Nicht erlaubte Aktion | Änderung durch reine Produktionsrolle. | Grenze wird tatsächlich durchgesetzt. |
| Oberfläche | Bezeichnete Fiori-App im richtigen Bereich. | Test entspricht späterem Benutzerweg. |
| Alternative | Relevanter Job oder Schnittstellenaufruf. | Kein ungeklärter zusätzlicher Schreibweg. |
| Ausnahme | Privilegierter Wartungszugang mit Zweck. | Nutzung und Datenwirkung nachvollziehbar. |
| Stand | Edition, Release, Rollen und wesentliche Einschränkungen. | Nachweis ist der tatsächlichen Konfiguration zugeordnet. |
Die nächsten Schritte
- Kritische Tätigkeiten und Organisationsgrenzen aus dem Prozess ableiten.
- Reale Rollenkombinationen und technische Nutzer inventarisieren.
- Positive und negative Tests mit definierten Konten ausführen.
- Vergabe, Änderungen, Entzug und regelmäßige Überprüfung in den Betrieb überführen.
Häufige Fragen zu S/4HANA: Berechtigungen
Müssen alle Berechtigungsobjekte einzeln getestet werden?
Ist eine ausgeblendete Kachel ausreichender Zugriffsschutz?
Wer sollte den Test freigeben?
Ist eine erfolgreiche Berechtigungsprüfung im Fiori-Frontend ausreichend?
Sie belegt den geprüften Frontendweg. Weitere relevante Schreib- oder Entscheidungswege müssen im Umfang berücksichtigt werden. Dazu können Schnittstellen, Jobs und administrative Möglichkeiten gehören. Welche tatsächlich vorhanden sind, hängt von Ihrer Architektur ab. Beschreiben Sie die Grenze des Nachweises ausdrücklich, statt aus einem Oberflächentest eine vollständige Zugriffsaussage abzuleiten.
Kann ein standardisierter Konfliktkatalog unser eigenes Rollenreview ersetzen?
Er kann bei der Auswahl kritischer Kombinationen helfen. Die Angemessenheit folgt jedoch aus Ihren Prozessen, Daten und Verantwortlichkeiten. Prüfen Sie auch lokale Erweiterungen und akzeptierte Ausnahmen. Ein formal konfliktfreier Katalog beweist nicht automatisch, dass eine qualitätsrelevante Aktion auf den richtigen Personenkreis begrenzt ist.
Wie wählen wir repräsentative SAP-Benutzer für den Test?
Betrachten Sie tatsächliche Rollen- und Gruppenkombinationen, organisatorische Bereiche und Ausnahmen. Wählen Sie Fälle, die unterschiedliche kritische Befugnisse abdecken. Eine idealisierte Einzelrolle kann die reale Kombination verfehlen. Dokumentieren Sie, welche Benutzergruppen durch welchen Test repräsentiert werden und wo individuelle Bewertung nötig bleibt.
Müssen administrative Möglichkeiten vollständig ausgeschlossen sein?
Nicht jede notwendige Administration lässt sich oder soll sich vollständig ausschließen. Benennen Sie Zweck, Befugnis und geeignete Kontrolle. Entscheidend ist, dass privilegierte Aktionen nicht unbemerkt als gewöhnlicher Fachprozess gelten. Prüfen Sie relevante Datenwirkung und Nachvollziehbarkeit im tatsächlich verwendeten Betriebsmodell.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
- SAP: Authorization Model, S/4HANA Cloud Public Edition
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Damit Ihr Team den nächsten Schritt sicher planen kann.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.