Warum SAP S/4HANA Cloud Public Edition Ihr Berechtigungskonzept verändert

Executive Summary

Für Führungskräfte mit Verantwortung für Cloud-Transformation, Risikomanagement und Technologie sind Berechtigungen in SAP S/4HANA Cloud Public Edition keine rein technische Designfrage. Sie entscheiden mit darüber, wie gut sich Risiken beherrschen lassen, ob das Projekt im Zeitplan bleibt und ob sich die Cloud-Investition rechnet.

• Risiko: Wer bestehende Zugriffskonzepte weiterverwendet oder SAP-Standardrollen unangepasst zuweist, riskiert überhöhte Berechtigungen, Konflikte in der Funktionstrennung, eine geschwächte Governance und Feststellungen im Audit.
• Projektumsetzung: Ein früh festgelegtes Rollen- und Berechtigungskonzept senkt spätere Nacharbeiten, beschleunigt die Benutzerprovisionierung und hält die Umsetzung nah am SAP-Standard.
• ROI: Das Least-Privilege-Prinzip und ein auf die Aufgabe des Benutzers zugeschnittener Zugriff vermeiden überflüssige Berechtigungen und Lizenzrisiken und sichern damit den Business Case für den Cloud-Umstieg.

Einführung

In SAP S/4HANA Cloud Public Edition greift das gewohnte Berechtigungs-Toolkit aus On-Premise-Umgebungen nicht mehr. Die klassischen Werkzeuge für die Rollenerstellung und die Pflege der Berechtigungsvorschlagswerte, insbesondere die Transaktionen PFCG und SU24, stehen nicht länger in gewohnter Form zur Verfügung, und Abkürzungen über das Backend fallen weg. Geht ein Security Team die Public Cloud mit der Denkweise aus On-Premise- oder Private-Cloud-Projekten an, werden die Implementierung des Berechtigungskonzepts und auch der spätere Betrieb unnötig aufwendig.

Die jüngsten Releases der S/4HANA Cloud Public Edition erlauben ein feingranulareres Berechtigungsdesign. Diese Granularität schafft Spielraum für das Least-Privilege-Prinzip, legt aber auch Schwächen in bestehenden Rollenkonzepten, SoD-Regelwerken, Betriebsmodellen und der Lizenzvermessung offen. Für SAP-Verantwortliche ist eine «set-and-forget»-Strategie damit keine Option.

Dieser Beitrag beschreibt die wesentlichen Änderungen im Berechtigungsdesign der S/4HANA Cloud Public Edition, ihre Folgen für die Compliance in der Funktionstrennung (Segregation of Duties, SoD) und Schritte zu einem auditfähigen Sicherheitsmodell.

«Shared Responsibility» in der Praxis umsetzen

Manche Organisationen wechseln in die Cloud in der Annahme, SaaS verlagere die Verantwortung für Security weitgehend zu SAP. Genau daraus entsteht in der Praxis eine Governance-Lücke. Das Cloud Shared Responsibility Model zieht die Grenze klar:

• SAP betreibt den Cloud-Service und die Plattform und liefert die Standardinhalte, etwa Rollen-Templates und Anwendungskataloge.
• Beim Kunden bleiben die Rollenzuweisung, die Gestaltung kundeneigener Anwendungsrollen und organisatorischer Berechtigungen, die Freigabeprozesse und die Durchsetzung der Funktionstrennung.

Wer SAP-Standardrollen unverändert an produktive Benutzer zuweist, geht erhebliche Risiken im Audit und in der Funktionstrennung ein. SAP legt diese Rollen bewusst breit an und im Fit-to-Standard-Assessment sind sie nützlich, weil sie den verfügbaren funktionalen Umfang zeigen. Ihr Katalogumfang deckt sich jedoch nicht mit dem tatsächlichen Aufgabenzuschnitt der Anwender. Ohne Anpassung entstehen überhöhte Berechtigungen und SoD-Risiken.

Für den produktiven Einsatz sollten die Standardrollen in jedem Fall angepasst werden. Sie können dabei am Standardprozessdesign von SAP ausgerichtet bleiben, statt eine losgelöste, parallele Rollenarchitektur aufzubauen, was die Upgrade-Stabilität erhält. Praxisbewährt ist folgender Ansatz: SAP-Standardrollen als funktionale Ausgangsbasis nutzen und nicht benötigte Kataloge oder Apps entfernen.

Wer Cloud-Sicherheit wirksam steuern will, muss verstehen, wie sich die Grundstruktur der Berechtigungsarchitektur verändert hat. SAP S/4HANA Cloud Public Edition verschiebt den Schwerpunkt von der technischen Rollenpflege zu einem funktional orientierten Modell aus Anwendungsrollen, Anwendungskatalogen und IAM-Apps, Zugriffskategorien und Einschränkungen:

Drei Dimensionen bestimmen in diesem Modell den Zugriff: die Apps, die ein Benutzer verwenden darf, die gewährte Zugriffsstufe und die geltenden Einschränkungen. Organisatorische Grenzen wie Werke, Buchungskreise, Vertriebsorganisationen oder Einkaufsorganisationen werden als Einschränkungen (Restrictions) auf der Anwendungsrolle gepflegt.

1. Direkte App-Zuweisung dort nutzen, wo sie zusätzliche Kontrolle schafft

Sofern im Release des Systems verfügbar, lassen sich einzelne IAM-Apps unmittelbar einer Anwendungsrolle zuordnen, ohne den Umweg über Anwendungskataloge, die jeweils eine Vielzahl von Apps bündeln.

Die direkte App-Zuweisung lohnt sich dort, wo Anwendungskataloge mehr Zugriff gewähren, als die Aufgabe des Benutzers erfordert. Sie stützt ein saubereres Least-Privilege-Design, weil unnötige Berechtigungen aus breit gefassten Katalogen wegfallen.

Für jede App, jede Abhängigkeit und jeden Prozess ist die direkte Zuweisung allerdings nicht die richtige (oder überhaupt eine technisch verfügbare) Option. Die Zuweisung über Anwendungskataloge bleibt deshalb vorerst notwendiger Bestandteil des Designs. Das Berechtigungskonzept sollte klare Entscheidungsregeln festhalten: wann direkt zugewiesen wird, wann über Anwendungskataloge, und wie beide Wege über Ownership, Genehmigungsverfahren und Dokumentation gesteuert werden.

2. Rollen für einen nachhaltigen Betrieb konzipieren

In S/4HANA Cloud Public Edition haben Kunden keinen vergleichbaren Backend-Zugriff, keine kundeneigenen ABAP-Hilfsprogramme und keine Abkürzungen auf Datenbankebene mehr wie in On-Premise-Landschaften. Die Rollenpflege läuft über die von SAP bereitgestellten Anwendungen und Lifecycle-Mechanismen. Damit gewinnen die initiale Rollenarchitektur und das Governance-Modell deutlich an Gewicht.

Weil weniger Raum für eigene Automatisierung bleibt als On-Premise, werden wiederkehrende Rollenänderungen betrieblich schnell aufwendig, wenn das Design nicht von Anfang an sauber strukturiert ist. Ein Beispiel ist das Master-Derived-Rollenkonzept: Es senkt den Pflegeaufwand deutlich, sofern der Rolleninhalt einheitlich ist und sich nur die organisatorischen Einschränkungen unterscheiden. Die Strategie für diese Einschränkungen muss dafür sorgfältig ausgearbeitet sein.

Masterrollen enthalten die gemeinsamen funktionalen Inhalte, also Anwendungskataloge, IAM-Apps, Spaces, Pages und gemeinsame, in der Regel funktionale Berechtigungseinschränkungen. Abgeleitete Rollen erben diese Inhalte und werden um die spezifischen organisatorischen Einschränkungswerte ergänzt.

3. Berechtigungen als finanzieller Hebel: Lizenzrisiken

Das Berechtigungsdesign kann sich auf Lizenzkosten und Compliance auswirken. Je nach Vertrag und SAP-Servicebeschreibung bestimmen die zugewiesenen Berechtigungen die Benutzerkategorie und damit die Kosten. Das Rollendesign gehört deshalb mit dem Lizenzierungsteam abgestimmt: Benutzer erhalten den für ihre Aufgabe erforderlichen Zugriff, aber keine weitergehenden Berechtigungen, die vermeidbare Kosten oder Governance-Risiken verursachen.

Die Flexibilität des Cloud-Berechtigungsmodells bringt eine erhebliche Compliance-Herausforderung mit sich: Klassische SoD-Regelwerke, die auf Transaktionscodes oder allein auf Katalogzuweisungen aufbauen, greifen für S/4HANA Cloud Public Edition zu kurz.

Viele traditionelle GRC-Regelwerke sind rund um Transaktionscodes oder Katalogzuweisungen entstanden. In der neuen Cloud-Architektur gilt:

• Regelwerke, die ausschliesslich auf Katalogebene prüfen, übersehen Risiken aus direkten IAM-App-Zuweisungen, sofern diese genutzt werden.
• Dieselben Regelwerke erzeugen zudem False Positives, wenn sie den effektiv gewährten Zugriff auf Ebene der IAM-App, der Zugriffskategorie und der Berechtigungswerte nicht auswerten können.

Ein cloudfähiges Regelwerk stärkt das SoD-Reporting, weil es zugewiesene Anwendungskataloge, Apps, Zugriffskategorien und Einschränkungen zusammen betrachtet. Das Unternehmen erhält ein verlässlicheres Bild der effektiven Berechtigungen, macht Risiken sichtbar und trifft Entscheidungen zum SoD-Clean-up auf fundierter Basis.

Zusammenfassend kennzeichnen vier Faktoren eine belastbare Berechtigungsimplementierung in SAP S/4HANA Cloud Public Edition: ein Rollendesign, das die Möglichkeiten und technischen Grenzen der Public Cloud berücksichtigt, klare Verantwortlichkeiten für Rollen und Einschränkungen, ein cloudfähiges SoD-Regelwerk und eine operative Governance für Betrieb und Lizenzierung. Zusammen machen sie das Berechtigungsdesign steuerbar und skalierbar: SAP-Standardinhalte werden in bedarfsgerechte Rollen überführt, Einschränkungen konsistent angewendet, SoD-Risiken sichtbar gemacht und Verantwortlichkeiten von der Projektumsetzung bis in den Betrieb nach dem Go-live klar gehalten.

PwC Schweiz unterstützt Organisationen dabei,

• ein übersichtliches Berechtigungskonzept für Master-Derived-Rollen mit dokumentierter Governance für Design und Betrieb zu entwerfen;
• die Lücken im SoD-Regelwerk mit einem cloudfähigen Regelsatz zu schliessen;
• die Lizenzkosten zu senken, indem das Rollendesign dem Least-Privilege-Prinzip folgt und die Lizenzparameter berücksichtigt.

Ob Sie eine Implementierung von SAP S/4HANA Cloud Public Edition vorbereiten oder Ihr Berechtigungsmodell nach dem Go-live nachschärfen: PwC Schweiz begleitet Sie beim Design einer sicheren, wartbaren und kostenbewussten Zugriffsarchitektur.

Erfahren Sie mehr über die SAP Access Management Services von PwC Schweiz: pwc.ch – SAP Access Management as a Service