Im ersten Teil dieser Artikelreihe habe ich Ihnen das Konzept der SAP Fiori-Apps vorgestellt. Für die Nutzung dieser Apps ist eine erweiterte Systemarchitektur erforderlich. Transaktionen werden direkt im System ausgeführt. Zur Ausführung von Apps ist das SAP Fiori Launchpad erforderlich. Hier werden dem Benutzer die ihm über Rollen zur Verfügung gestellten Apps angezeigt. Die Anmeldung eines Benutzers über das SAP Fiori Launchpad erfolgt nicht an S/4HANA, sondern an ein vorgelagertes Gateway, dem Frontend-Server. Dieses kommuniziert mit der S/4HANA über Trusted RFC. Hierbei sind dann natürlich insbesondere die RFC-Berechtigungen der Benutzer relevant.
1. Technische Sicherheit in SAP S/4HANA
Die technische Basis von SAP S/4HANA ist der SAP NetWeaver. Es gelten somit dieselben Sicherheitsanforderungen wie in allen anderen SAP-Systemen, die auf dem SAP NetWeaver basieren, wie z.B. SAP ERP.
SAP Fiori Apps werden über das SAP Fiori Launchpad aufgerufen. Die Anmeldung des Benutzers erfolgt direkt über das Launchpad. Auf dem Launchpad werden den Benutzern die ihnen zugeteilten Apps als Kacheln dargestellt. Abbildung 1 zeigt die Oberfläche des Launchpad. Im linken Bereich hat der Benutzer die Möglichkeit, das Launchpad individuell für sich zu gestalten. So kann z.B. das Layout und die App-Anordnung geändert werden.
Vom SAP Fiori Launchpad greift der Benutzer nicht auf das SAP S/4HANA-System zu. Die SAP Fiori Systemlandschaft ist so aufgebaut, dass vor dem SAP S/4HANA-System ein Frontend-Server aufgebaut wird. Dies ist ein SAP NetWeaver, der auf einer beliebigen Datenbank basiert. Das SAP Fiori Launchpad greift auf diesen Frontend-Server zu. Hier sind die Benutzer eingerichtet und es findet die Authentifizierung statt. Auf dem Frontend-Server werden dem Benutzer die Berechtigungen für die Apps zugeordnet. Die eigentlichen Geschäftsprozesse laufen in der S/4HANA, die als Backend-System fungiert. Auch im Backend-System sind die Benutzerkonten angelegt, mit identischem Namen wie im Frontend. Beide Systeme sind über Trusted RFC miteinander verbunden. Eine explizite Authentifizierung des Benutzers an das S/4HANA Backend ist nicht erforderlich.
Abbildung 2 zeigt den Aufbau einer SAP Fiori Systemlandschaft.
Die Trennung von Frontend- und Backend-Server bringt Sicherheitsaspekte bzgl. der Absicherung der RFC-Berechtigungen und des Trusted RFC mit sich. Trusted Systems sind SAP-Systeme, die sich gegenseitig vertrauen. Dies bedeutet, dass Zugriffe von einem System auf das andere ohne explizite Authentifizierung möglich sind.
In Abbildung 3 bedeutet dies: vom SAP Fiori Frontend können Aktionen im S/4HANA Backend ausgeführt werden ohne explizite Anmeldung (notwendige Berechtigungen vorausgesetzt).
Damit ein Benutzer aus einem anderen System heraus über die Trusted-Funktionalität genutzt werden kann, muss er über eine Berechtigung auf dem Objekt S_RFCACL verfügen. Diese Berechtigung ist standardmäßig nicht im sonst sehr umfassenden Sammelprofil SAP_ALL enthalten. Ob dieses Objekt in SAP_ALL automatisch generiert wird, wird über den Schalter ADD_S_RFCACL in der Tabelle PRGN_CUST gesetzt. Der Schalter kann zwei Werte enthalten:
- NO S_RFCACL wird nicht automatisch in SAP_ALL mit generiert (Default)
- YES S_RFCACL wird automatisch in SAP_ALL mit generiert
Aus Sicherheitsgründen sollte dieser Schalter den Wert NO enthalten bzw. nicht in der Tabelle PRGN_CUST enthalten sein (in dem Fall ist der Default-Wert NO gesetzt). Die in Abbildung 4 abgebildete Berechtigung zeigt folgendes an:
- Nur Aufrufe aus dem System IE1 sind gültig (Feld
System-Id= IE1) - Eine Nutzung ist nur jeweils mit derselben Benutzerkennung möglich (Feld
RFC gleiche Benutzerkennung= Y)
Diese Berechtigung wird im S/4HANA Backend-System angelegt, das Frontend-System ist in diesem Fall IE1. Verfügt ein Benutzer im Backend über diese Berechtigung, so kann aus dem Frontend die Trusted Verbindung nur von demselben Benutzer mit identischer Kennung aufgerufen werden.
Bei der Berechtigung in Abbildung 5 kann der Benutzer, dem diese Berechtigung im Backend zugeordnet ist, grundsätzlich durch jeden Benutzer aus dem Frontend (IE1) genutzt werden, wodurch diese Berechtigung als äußerst kritisch einzustufen ist. Wenn eine kritische Berechtigung dieser Art vorliegt, so könnte im Backend eine RFC-Verbindung definiert werden, in welcher z.B. der Benutzername TOMTIEDE fest hinterlegt wird. Somit könnte jeder Benutzer im Frontend, der diese RFC-Verbindung nutzen kann, unter der Benutzerkennung TOMTIEDE im Backend arbeiten, somit also anonym. Die Berechtigungen auf dem Objekt S_RFCACL sind im S/4HANA Backend somit auszuprägen, wie in Tabelle aufgeführt.
Neben der Trennung von Frontend und Backend ist es auch möglich, die Frontend-Komponenten auf dem Backend-System zu installieren. Das hat den Vorteil, dass kein zusätzliches SAP-System erforderlich ist und damit sowohl die Benutzerverwaltung und auch die Absicherung erleichtert wird. Allerdings hat diese Variante eine Vielzahl von Nachteilen:
- Upgrades von Add-ons, die auf dem Frontend-Server in kurzen Abständen installiert werden können, müssen auf einem Backend in größeren Abständen eingeplant werden.
- Für Änderungen am UI sind Entwicklungsberechtigungen auf dem Backend erforderlich.
- Die Sicherheit des Backend wird verbessert, wenn keine direkten Zugriffe darauf erfolgen. Bei einem integriertem Frontend / Backend-System erfolgen Benutzeranmeldungen direkt auf dem System.
- Für den Einsatz mehrere Backend-Systeme muss auf jedem System das SAP Gateway individuell konfiguriert werden.
- Die Berechtigungsrollen sollten trotzdem in Frontend- und Backend-Rollen aufgeteilt werden, um eine spätere Systemtrennung zu ermöglichen.
2. Fragestellungen zur SAP S/4HANA Systemsicherheit
Wird das Berechtigungsobjekt S_RFCACL automatisch mit einer vollen Berechtigung in SAP_ALL aufgenommen?
Das Berechtigungsobjekt S_RFCACL ist nicht in SAP_ALL aufzunehmen. Hier besteht das Risiko, dass von anderen Systemen aus ein uneingeschränkter Zugriff möglich ist.
Rufen Sie die Transaktion SE16 auf und lassen Sie sich die Tabelle PRGN_CUST anzeigen. Überprüfen Sie ob der Eintrag ADD_S_RFCACL existiert. Falls der Eintrag existiert darf er nicht den Wert YES enthalten. Existiert dieser nicht so steht er auf dem Wert NO.
Ist im S/4HANA Backend-System das Objekt S_RFCACL korrekt ausgeprägt?
Berechtigungen für Trusted-Zugriffe dürfen nur sehr restriktiv vergeben werden. Hier besteht das Risiko, dass durch falsch vergebene Berechtigungen ein vollständiger Zugriff vom Frontend auf das Backend-System ermöglicht wird.
Rufen Sie die Transaktion SUIM auf, Eintrag Benutzer – Benutzer nach komplexen Selektionskriterien – Benutzer nach komplexen Selektionskriterien. Tragen Sie dort im Register Berechtigungen im Block Selektion nach Werten die Werte gem. Tabelle 2 ein.
Fazit
Der Umstieg von SAP ERP zu SAP S/4HANA bedeutet auch einen Technologiewechsel. Bedingt durch das Konzept des Frontend- und Backend-Servers kommen neue Sicherheitsaspekte hinzu, die zu beachten sind. Diese sind von vornherein in das Sicherheitskonzept aufzunehmen.
Im dritten Teil dieser Artikelreihe, der hier sowie in der Zeitschrift Revisionspraxis PRev erscheint, beschreibe ich, wie Berechtigungen auf SAP Fiori-Apps vergeben und analysiert werden können.
Thomas Tiede ist seit Anfang des Jahres 2000 Geschäftsführer der IBS Schreiber GmbH. Seine umfangreichen Erfahrungen im Bereich der Unternehmensprüfung fließen in seine langjährige Seminartätigkeit ein. Er gilt als anerkannter Experte der Zugriffs- und Sicherheitsphilosophien von Betriebssystemen, Datenbanken und SAP. An der Entwicklung des Prüfungstools CheckAud® war und ist Thomas Tiede maßgeblich beteiligt. Er ist Autor des Standardwerkes „Sicherheit und Prüfung von SAP-Systemen“ sowie des im Juli 2019 erscheinenden „SAP HANA – Sicherheit und Berechtigungen“.