RFC-Schnittstellen
Pflege der Berechtigungsobjekte (Transaktion SU21)
Da Entwicklerberechtigungen einer Vollberechtigung entsprechen, sollten diese nur restriktiv vergeben werden. Dies gilt vor allen Dingen für die Berechtigung zum „Debugging mit Replace“ (siehe „Gesetzes kritische Berechtigungen“). Das Risiko durch falsch vergebene Entwicklerberechtigungen ist auch durch das Wegfallen des Zusatz-Schutzes über Entwickler- und Objektschlüssel in S/4 HANA Systemen gestiegen (siehe u.a. SAP-Hinweis 2309060). Entwicklerberechtigungen für originale SAP-Objekte sollten hier also nur noch auf Antrag vergeben werden, um unautorisierte Modifikationen zu vermeiden. Falls Entwicklerschlüssel in dem vorhandenen SAP-Release also noch relevant sind, sollten zunächst die vorhandenen Entwicklerschlüssel in der Tabelle DEVACCESS überprüft und mit den für die Entwicklung vorgesehenen Benutzern abgeglichen werden.
Das Berechtigungsobjekt S_RFCACL wird durch das Einspielen des SAP-Hinweises 1416085 aus dem Profil SAP_ALL entfernt. Dieser Hinweis ist in allen neueren Support Packages für die Basiskomponente enthalten; dies betrifft also alle Systeme bis herunter zum Basisrelease 4.6C. Grund für diese Änderung ist, dass das Berechtigungsobjekt S_RFCACL und vor allem die Ausprägung Gesamtberechtigung (*) für dessen Felder RFC_SYSID, RFC_CLIENT und RFC_USER als besonders kritisch eingestuft wird. Diese Felder legen fest, aus welchen Systemen und Mandanten bzw. für welche Benutzerkennungen Anmeldungen am Zielsystem erlaubt sein sollen. Die Gesamtberechtigung für diese Felder erlaubt also die Anmeldung aus beliebigen Systemen und Mandanten bzw. für beliebige Benutzer und erzeugt dadurch erhebliche Sicherheitsrisiken.
Verwendung von Vorschlagswerten und Vorgehen beim Upgrade
Das Security Audit Log (SAL) verfügt in den aktuellen Releases über zehn verschiedene Filter, über die gesteuert wird, welche Ereignisse protokolliert werden. Diese Filter können Sie über die Transaktion SM19 konfigurieren. Die Ereignisse sind als unkritisch, schwerwiegend oder kritisch kategorisiert.
Sie führen SAP HANA in Ihrem Unternehmen ein und brauchen für Zugriffe auf die Datenbank auch eine Benutzerverwaltung für SAP HANA? Wir zeigen Ihnen die verschiedenen Möglichkeiten der Benutzersynchronisation zwischen ABAP-System und HANA-Datenbank. Die HANA-Datenbank dient ebenso wie die klassischen Datenbanken als Persistenz für das ABAP-System und liegt damit in der Datenbankschicht. In einem solchen Szenario steuern Sie die Berechtigungen der Benutzer über die Applikationsschicht im SAP NetWeaver Application Server ABAP (SAP NetWeaver AS ABAP). Datenbankseitig, d. h. in SAP HANA sind nur technische Benutzer erforderlich. Darüber hinaus gibt es aber auch Anwendungsszenarien, die es erforderlich machen, dass Ihre Anwender Benutzer und Berechtigungen direkt in der HANA-Datenbank erhalten. Im Business-Intelligence-Umfeld (BI-Umfeld) kann dies z. B. bei direkten Zugriffen auf Data Marts in der Datenbank der Fall sein. Zusätzlich hat die HANA-Datenbank eine eigene Anwendungsschicht (SAP HANA Extended Application Services, SAP HANA XS), die Sie auch ohne ABAP-System nutzen können, z. B. für Webzugriffe, die von mobilen Endgeräten ausgehen.
Für die Zuweisung vorhandener Rollen erfordern die regulären Berechtigungs-Workflows ein gewisses Minimum an Durchlaufzeiten, und nicht jeder Genehmiger steht zu jeder Zeit bei jedem Go-Live zur Verfügung. Mit "Shortcut for SAP systems" stehen Ihnen Möglichkeiten zur Verfügung, dringend benötigte Berechtigungen dennoch zuzuweisen und Ihren Go-Live zusätzlich abzusichern.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Berechtigungen.
Dabei müssen Sie berücksichtigen, dass alle Einstellungen in den Tabellen SSM_CUST, SSM_COL und PRGN_CUST mandantenunabhängig sind; nur die Einstellungen der Tabelle USR_CUST sind mandantenabhängig.
Speziell Änderungen an Tabellen, in denen das Customizing vorgenommen wird, werden nicht in den Änderungsbelegen festgehalten.