SAP Business ByDesign: GxP-Zugriffsrechte testen

Einordnung und Geltungsbereich

Dieser Beitrag vertieft die Rollenprüfung in ByDesign. Welche Einschränkungen in einer View möglich sind, muss anhand ihrer Produktdokumentation und der tatsächlichen Konfiguration festgestellt werden; identische Möglichkeiten für alle Views werden nicht vorausgesetzt.

Quellen: [1] [2]

Zugriff auf eine Funktion und Zugriff auf Daten gemeinsam betrachten

Die Rollenprüfung sollte auch zusätzliche Zuordnungen erfassen. Ein während des Projekts vergebener breiter Zugriff kann nach dem Go-live bestehen bleiben und die geplante Einschränkung aufheben. Vergleichen Sie deshalb die freigegebene Sollmatrix mit dem tatsächlich nutzbaren Zugang.

Nach einer Änderung ist nicht nur die erfolgreiche Vergabe interessant. Prüfen Sie ebenso den Entzug einer zuvor erlaubten Tätigkeit. Dokumentieren Sie den relevanten Benutzerstand und den Zeitpunkt des Tests, damit eine spätere Rollenänderung nicht fälschlich mit dem älteren Test als abgedeckt gilt.

Quellen: [1] [2]

Kritische Geschäftsaktionen als Ausgangspunkt

Definieren Sie zuerst, welche Aktionen das Unternehmen kontrollieren will. Dazu können Änderungen an Chargeninformationen, Materialstämmen, qualitätsrelevanten Parametern und Freigabeschritten gehören. Ergänzen Sie organisatorische Grenzen: Standort, Gesellschaft, Bereich oder andere tatsächlich verwendete Einschränkungen. Der Name einer Business Role beantwortet diese fachlichen Fragen noch nicht.

In ByDesign werden Rollen, Work Centers, Sichten und Zugriffsbeschränkungen konfiguriert. Die geeignete Bewertung betrachtet deren tatsächliche Kombination beim Benutzer. Prüfen Sie den eingesetzten Tenant und Release sowie Partnererweiterungen. Dieser Artikel beschreibt keine universelle Rollenbibliothek, die für jeden Life-Science-Betrieb unverändert geeignet wäre.

Erfassen Sie auch Ausnahmen, Vertretungen und zeitweilige Projektzugänge. Ein Benutzer kann seine gewöhnliche Aufgabe korrekt ausführen und durch eine weitere Rolle dennoch unerwünschte Änderungsrechte besitzen. Die wirksame Berechtigung sollte deshalb aus realen Zuweisungen und tatsächlichen Aktionen nachvollzogen werden, nicht nur aus einer genehmigten Rollenliste.

Quellen: [1] [2]

Eine Rollenmatrix auf die tatsächliche Arbeit beziehen

Beschreiben Sie je kritischer Funktion erlaubte Tätigkeit, betroffene Daten und erwartete Grenze. Ein Mitarbeiter darf beispielsweise Informationen zu einem identifizierten Bestand sehen, aber eine qualitätsrelevante Angabe nicht selbst verändern. Der positive Fall zeigt benötigte Arbeitsfähigkeit; der negative Fall zeigt die beabsichtigte Begrenzung.

Wenn eine Trennung zwischen Erstellung und Freigabe vorgesehen ist, prüfen Sie beide Schritte mit den dafür benannten Rollen. Ein ausgeblendeter Button allein ist kein ausreichender Nachweis. Berücksichtigen Sie vorhandene Importschnittstellen oder Erweiterungen, soweit sie dieselben Daten verändern können. Die Testauswahl richtet sich nach Ihrem konkreten Berechtigungsmodell.

Quellen: [1] [2]

Beispiel: zwei einzeln plausible Rollen ergeben zu viele Rechte

Das Szenario ist konstruiert. Ein Mitarbeiter besitzt eine Produktionsrolle und übernimmt vorübergehend Stammdatenvertretung. Beide Zuweisungen sind einzeln nachvollziehbar. Zusammen ermöglichen sie jedoch eine Änderung und anschließende Nutzung desselben kritischen Parameters, obwohl das interne Verfahren eine zusätzliche fachliche Entscheidung vorsieht. Die Bewertung muss daher die Kombination betrachten.

Bilden Sie diese Kombination mit kontrollierten Testdaten nach. Prüfen Sie Anzeige, Änderung, nachfolgende Verwendung und den vorgesehenen Entscheidungsweg. Stellen Sie die Sollreaktion vorab fest. Wenn das System keine gewünschte technische Trennung umsetzt, ist zu bewerten, ob ein anderer geeigneter Kontrollweg möglich ist oder die Rollenstruktur angepasst werden muss. Eine bloße Arbeitsanweisung ist nicht automatisch ausreichend.

Nach Ende der Vertretung wird die zusätzliche Zuweisung entfernt. Prüfen Sie den tatsächlichen Rechteentzug und erhalten Sie einen nachvollziehbaren Nachweis. Eine genehmigte E-Mail zur Entfernung beweist noch nicht die Umsetzung. Bewerten Sie außerdem, ob zwischenzeitlich vorgenommene kritische Änderungen entsprechend dem Verfahren behandelt wurden.

Quellen: [1] [2]

Zugriff und Änderungshistorie nicht verwechseln

Eine wirksame Berechtigung begrenzt, wer etwas tun darf. Eine Änderungshistorie hilft zu erklären, was getan wurde. Beide Funktionen ergänzen sich, ersetzen einander aber nicht. Ein vollständig protokollierter unzulässiger Zugriff bleibt ein Zugriffsbefund. Eine starke Zugriffsbeschränkung beantwortet wiederum nicht jede Frage zur späteren Nachvollziehbarkeit erlaubter Änderungen.

Prüfen Sie am konkreten Geschäftsobjekt, welche Historie tatsächlich verfügbar ist. Eine Konfigurationshistorie ist nicht automatisch eine vollständige Historie aller Geschäftsdaten. Benötigte Angaben, Zugriff und Aufbewahrung werden aus dem jeweiligen Prozess abgeleitet. Stellen Sie im Test eine konkrete Änderung her und versuchen Sie, sie später mit berechtigtem Zugriff nachvollzuziehen.

Halten Sie fest, welche Rollen Auditdaten oder Änderungsinformationen sehen dürfen und wer auffällige Änderungen bewertet. Ein vorhandener Report ohne zuständigen Reviewer bleibt im Alltag möglicherweise ungenutzt. Die erforderliche Prüfung ist risikobasiert zu planen; der Artikel unterstellt weder eine universelle Frequenz noch eine identische Protokollabdeckung aller ByDesign-Objekte.

Quellen: [1] [2]

Rollenwechsel, Releases und Partnerzugänge steuern

Verbinden Sie Personal- und Aufgabenänderungen mit einer Bewertung vorhandener Zugriffe. Alte Rollen sollten nicht ungeprüft bestehen bleiben, wenn ein Mitarbeiter einen neuen Bereich übernimmt. Erhalten Sie eine verständliche Übersicht über begründete Ausnahmen und ihre Dauer. Das erleichtert spätere Überprüfungen und verhindert, dass Projektzugänge zum dauerhaften Standard werden.

Bei Releases oder Änderungen an Erweiterungen ist zu beurteilen, ob neue Sichten, Aktionen oder Datenwege betroffen sind. Wiederholen Sie passende kritische Zugriffsfälle. Ein vollständiger Test jeder Bildschirmseite ist nicht automatisch erforderlich; eine begründete Auswahl muss jedoch die relevanten Auswirkungen abdecken. Bewahren Sie den Bezug zwischen Teststand und produktivem Tenant.

Übergeben Sie dem internen Team nicht nur Rollenexporte, sondern deren fachliche Bedeutung. Ein Systemverantwortlicher sollte erklären können, welche Aufgabe eine Zuweisung rechtfertigt und welcher Test die Grenze belegt. Damit wird die Rollenpflege auch nach Ende des Implementierungsprojekts nachvollziehbar.

Quellen: [1] [2]

Arbeitsvorlage: Vertretung und Zugriffsbeschränkung nachvollziehbar prüfen

Beschreiben Sie Vertretung als bezeichneten Aufgabenwechsel. Welche zusätzliche Tätigkeit wird benötigt, für welchen Zeitraum und in welchem organisatorischen Bereich? Übernehmen Sie nicht automatisch alle Rechte des vertretenen Mitarbeiters. Die passende Zuweisung folgt der tatsächlich übernommenen Arbeit und den kritischen Kombinationen.

Prüfen Sie Beginn und Ende der Vertretung praktisch. Der Benutzer muss die neue Aufgabe ausführen können, während andere Grenzen erhalten bleiben. Nach Ende ist die tatsächliche Entfernung zu bestätigen. Die Kontrollakte sollte ursprüngliche Rolle, Ergänzung und späteren Stand verbinden, damit ein historischer Zugriff erklärt werden kann.

Wenn der Test eine unerwünschte Kombination zeigt, klären Sie alternative Rollen oder einen geeigneten zusätzlichen Kontrollweg. Eine formal dokumentierte Ausnahme ist nicht automatisch wirksam. Prüfen Sie deren praktische Durchführung mit einem konkreten Vorgang und benennen Sie, wann die Ausnahme endet oder erneut bewertet wird.

Quellen: [1] [2]

Die nächsten Schritte

• Tätigkeiten und zulässige Datenbereiche festlegen.
• Work Center, Views und tatsächliche Rechtekombination zuordnen.
• Erlaubte und unerlaubte Vorgänge mit Testkonten prüfen.
• Vergabe, Entzug und Betriebsreview dokumentieren.