Für viele SAP ERP Kunden steht mit dem Umstieg auf die neue S/4HANA Suite der größte Umbruch der Landschaftsarchitektur seit dem Jahr 2003 an. In diesem Jahr führte der Walldorfer Softwarekonzern die als R/3 bezeichnete dritte Generation Ihrer ERP Produktlinie ein. Seitdem konnten die Kunden Ihre Landschaft fast unverändert nutzen – der Zugriff erfolgte hauptsächlich mit der SAPGUI. Mit SAP S/4HANA ändert sich das – die Zukunft liegt im Browser!
Vom starren zum flexiblen Netzwerk
Das Stichwort lautet hier FIORI. Immer mehr klassische SAPGUI Transaktionen überführt die SAP in das FIORI Launchpad, den Zentralen Einstiegspunkt für alle SAP-Anwender. Immer weiter gestiegene Mobilitätsanforderungen an die eigenen Mitarbeiter und die Möglichkeit Lieferanten und Endkunden unkompliziert Tätigkeiten auf dem eigenen System durchführen zu lassen, sorgen außerdem dafür, dass es neue Zugriffswege auf die Applikationsserver gibt. Wo früher ausschließlich innerhalb des eigenen Netzwerkes mit dem SAPGUI gearbeitet wurde, muss der Zugriff auf Apps und wichtige Daten heutzutage von überall und jederzeit möglich sein.
Der WebDispatcher – Was leistet er?
Damit der Web-basierte Zugriff sicher gestaltet werden kann, muss die Architektur der SAP-Systemlandschaft angepasst werden. Die SAP empfiehlt den Einsatz des WebDispatchers, der in den letzten Jahren massiv weiterentwickelt wurde. Er dient als Single Point of Entry für alle HTTP basierten Zugriffe, also FIORI Apps, WebDynpro etc..
Durch Einsatz des WebDispatchers in der DMZ werden direkte Zugriffe auf das S/4HANA System unterbunden. Durch diese erste Isolationsschicht wird die Sicherheit der Systeme erheblich verbessert. Doch der WebDispatcher dient nicht nur als Reverse Proxy – er kann auch auf Viren und Malware scannen, vor diversen Web basierten Attacken (Slowloris, DDOS, usw.) schützen, eine sichere Verschlüsselung garantieren, sowie alle Zugriffe protokollieren und an Ihr SIEM System weitergeben.
Um die Sicherheit weiter zu erhöhen, vor allem wenn der Zugriff auf den WebDispatcher aus dem Internet ermöglicht werden muss, können weitere Systeme sinnvoll sein. Möchte man nur User auf die Systeme lassen, die sich vorher in der Azure AD angemeldet haben, könnte ein Microsoft Azure AD App-Proxy sinnvoll sein. Auch der Einsatz einer Web Application Firewall kann sinnvoll sein – je nachdem wie Ihr Zugriffsszenario aussieht.
Berechtigungskonzepte neu gedacht
Neben den neuen Zugriffswegen hat SAP zudem die Möglichkeiten in Bezug auf Berechtigungen angepasst. Hierbei gibt es alte Bekannte, als auch spannende Neuerungen, mit denen sich jeder SAP-Kunde auseinandersetzen muss.
Ob Übernahme alter Berechtigungen oder ein komplett neues Berechtigungskonzept, Greenfield, Brownfield oder doch die häufig gewählte Hybridlösung – stets müssen die neuen Möglichkeiten in Betracht gezogen werden. Plant man die Übernahme einer alten Rolle, so muss diese teils stark durch Änderungen in Transaktionen und Selektionen angepasst werden. Hierzu gibt es entsprechende Listen von SAP, die einen Überblick gewähren in welchen Bereichen konkret Änderungen anstehen und wie diese aussehen. Einerseits fallen Transaktionen weg, werden anders gestaltet oder zusammengefasst. Andererseits sind einige Funktionen nur noch über eine FIORI Anwendung verfügbar. Meist wird in Projekten eine hybride Migrationsstrategie verwendet, denn ganz sollte man die meist über Jahre gewachsenen Informationen, Prozesse und Strukturen, die in eine Rolle geflossen sind, nicht ignorieren. Sie können ein wertvoller Informationspool beim Erstellen eines neuen Konzepts sein.
FIORI-Anwendungen werden bei vielen Kunden mit S4 das erste Mal im System angewendet. Da teils essenzielle Funktionen nur noch hierrüber angeboten werden, kommt man um deren Verwendung nicht herum.
Erneuerung oder Erweiterung der Berechtigungen – was ist nötig?
Die Berechtigungen müssen nun, je nachdem ob ein Central Hub oder Embedded Deployment verwendet wird, gestaltet werden. Im Falle des Central Hub (eigener Frontend Server) wird sowohl auf dem Frontend Server als auch im Backend System eine passende Rolle benötigt. Wie sich die Oberfläche für die User gestaltet, kann hierbei entweder mit der Definition von Gruppen und Katalogen bestimmt werden oder die neue noch vielseitiger konfigurierbare Variante der Spaces und Pages verwenden. Hier bietet sich dann die Möglichkeit Funktionen in den jeweiligen Spaces und Pages, zusätzlich zu Gruppen und Kacheln, sinnvoll zusammenzufassen, um somit eine bestmögliche Übersicht zu erhalten.
Auf dem Frontend Server wird eine Rolle benötigt, die sowohl die Gruppe und die damit verbundenen Kacheln und evtl. Spaces enthält wie auch den passenden OData Service vom Typ IWSG für die zu verwendende UI5 App. Im Backendsystem benötigt der User zusätzlich eine Rolle mit dem jeweiligen Katalog, den OData Services vom Typ IWSV und die Transaktions- oder Web Dynpro Berechtigungen.
Somit ist im S4 Umfeld keine komplett neue Handhabung von Berechtigungen nötig, eine Erweiterung des bisherigen Rollenkonzepts um FIORI Anwendungen allerdings schon. Welche Daten ein User am Ende sehen kann, wird wie bisher auch über die zugewiesenen Berechtigungen im Backend System reguliert.
