Dieser Beitrag behandelt Risikothemen, die vom Entwicklungssystem ausgehen und sich auf die nachgelagerten Systeme bis hin zum Produktivsystem auswirken. Neben Änderungen im Entwicklungs- und Customizing-Umfeld sind dies auch die systemspezifischen Transportprozess-Schritte und vorhandenen Schnittstellen.
Entwicklung
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.
Abbildung 1: Anzeige der Tabelle DEVACCES
Weiterhin sind die vorhandenen Entwicklerberechtigungen zu prüfen. Die wesentlichen Berechtigungen sind in der nachfolgenden Tabelle aufgelistet:
Berechtigungsobjekt | Feld | Wert |
Pflegeberechtigungen in der Entwicklungsumgebung allgemein | ||
S_DEVELOP | ACTVT Aktivität | 01 (Anlegen) oder 02 (Ändern) oder 06 (Löschen) |
Entwicklerberechtigung, SAP-Namensraum | ||
S_DEVELOP | ACTVT Aktivität | 01 (Anlegen) oder 02 (Ändern) oder 06 (Löschen) |
OBJNAME Objektname | Alles außerhalb des Kundennamensraums (y*, z*, /*) | |
Customizing
Customizing wird in den meisten Fällen über die Transaktion SPRO durchgeführt. Dies ist jedoch nur die Einstiegstransaktion für eine sehr umfassende Baumstruktur weiterer Pflegetransaktionen. Die meisten Customizing-Aktivitäten bestehen aber in der indirekten oder direkten Pflege von Tabellen. Daher kann eine stichprobenartige Überprüfung der Berechtigungsstruktur in diesem Umfeld auf Tabellenberechtigungen reduziert werden. Bei abgegrenzten Zuständigkeiten innerhalb des Customizings (z.B. FI, MM, SD etc.) ist hier also auf eine entsprechende Abgrenzung innerhalb der Tabellenberechtigungen zu achten. Unabhängig von vergebenen Transaktionsberechtigungen innerhalb des Customizings entspricht eine Vollberechtigung auf Tabellenebene kombiniert mit einer Tabellenpflegetransaktion wie etwa SM30 praktisch einer Vollberechtigung im Customizing.
Normales Customizing der Fachbereiche bezieht sich im Allgemeinen auf mandantenabhängige Tabellen. Der Zugriff auf Systemtabellen sollte also möglichst auf die Basisadministration beschränkt werden.
Wesentliche Berechtigungskonstellationen:
Berechtigungsobjekt | Feld | Wert |
Ändern aller Tabellen | ||
S_TABU_DIS | ACTVT Aktivität | 02 (Ändern) |
DICBERCLS Berechtigungsgruppe | * (alle) | |
oder | ||
S_TABU_NAM | ACTVT Aktivität | 02 (Ändern) |
TABLE Tabelle | * (alle) | |
Pflegezugriff auf Systemtabellen | ||
S_TABU_CLI | CLIIDMAINT Tabellenpflege mandantenunabhängiger Tabellen | X |
Transporte
Grundsätzlich ist innerhalb des kompletten Entwicklungs- bzw. Customizing- und Transport-Prozesses ein technisches 4-Augen Prinzip zu implementieren. Ohne zusätzliche Tools ist dies im SAP-Standard nur über entsprechend vergebene Berechtigungen innerhalb der Transportlandschaft zu erreichen. Abhängig von den eingesetzten Strategien sollen also evtl. nur bestimmte Transportschritte innerhalb des Entwicklungssystems an die Benutzer vergeben sein. Beim Einsatz des SAP-Solution-Managers („ChaRM“) für die Transportsteuerung sollen hier beispielsweise normalerweise nur die Berechtigungen zur Freigabe von Transport-Aufgaben vergeben werden. Die vollständige Abwicklung eines Transportes im Entwicklungssystems besteht aus vier Schritten: Anlegen und Freigeben eines Transportauftrags (der eigentliche Transportcontainer), Anlegen und Freigeben einer Transportaufgabe (die Berechtigung für einzelne Benutzer, Objekte an den jeweiligen Transportauftrag zu hängen).
Wesentliche Berechtigungskonfigurationen werden in der folgenden Tabelle aufgelistet:
|
Berechtigungsobjekt |
Feld |
Wert |
|
Worbench- oder Customizing-Aufträge anlegen oder freigeben |
||
|
S_TRANSPRT |
ACTVT Aktivität |
01 (Anlegen) oder 43 (Freigeben) |
|
TTYPE Auftragstyp |
DTRA (Workbench) oder CUST (Customizing) |
|
|
oder |
||
|
S_SYS_RWBO |
ACTVT Aktivität |
01 (Anlegen) oder 43 (Freigeben) |
|
TTYPE Auftragstyp |
DTRA (Workbench) oder CUST (Customizing) |
|
|
Aufgaben anlegen oder freigeben |
||
|
S_TRANSPRT |
ACTVT Aktivität |
01 (Anlegen) oder 43 (Freigeben) |
|
TTYPE Auftragstyp |
TASK (Aufgabe) |
|
|
oder |
||
|
S_SYS_RWBO |
ACTVT Aktivität |
01 (Anlegen) oder 43 (Freigeben) |
|
TTYPE Auftragstyp |
TASK (Aufgabe) |
|
RFC-Schnittstellen
Eine Möglichkeit, einen direkten Zugriff auf die nachgelagerten Systeme vom Entwicklungssystem aus zu erhalten und dort evtl. unautorisierte Aktivitäten durchzuführen, besteht in der Nutzung fehlerhaft konfigurierter Schnittstellen. Grundsätzlich sollten Schnittstellen innerhalb einer Transportlandschaft bezüglich der Kritikalität der Systeme „bergauf“, also von einem „unsicheren“ auf ein „sicheres“ System (z.B. E-System auf Q- oder P-System) vermieden werden. Dies lässt sich allerdings nicht immer umsetzen, beispielsweise werden innerhalb des Transportwesens solche Schnittstellen benötigt. Ohne zu tief in die Thematik einzusteigen, lassen sich jedoch kritische Schnittstellen über folgende Eigenschaften charakterisieren, kritische Schnittstellen
- verweisen auf ein kritisches System und einen kritischen Mandanten
- beinhalten einen Schnittstellenbenutzer mit kritischen Berechtigungen im Zielmandanten
- beinhalten dessen hinterlegtes Kennwort
Da zumindest Entwickler im Entwicklungssystem wie erwähnt quasi über Vollberechtigungen verfügen, kann der konkrete Zugriff auf eine kritische RFC-Verbindung also auch nicht entzogen werden. Da RFC-Schnittstellen für das gesamte System definiert werden, können diese aus jedem Mandanten des Startsystems heraus genutzt werden. Vorhandenen Schnittstellen lassen sich über die Tabelle RFCDES im Start- (Entwicklungs-) System auslesen. Die oben aufgeführten Eigenschaften sind im Tabellenfeld RFCOPTIONS mit den folgenden Kürzeln aufgeführt:
H= <Zielsystem>
M= <Zielmandant>
U= <Schnittstellenbenutzer>
v= ein Kennwort ist hinterlegt
Abbildung 2: Anzeige der Tabelle RFCDES
Fazit
Entwickler- und Customizing-Berechtigungen stellen in produktiven SAP-Systemen ein großes Gefahrenpotential dar. Hier sind die Berechtigungen sehr restriktiv zu vergeben, z.B. nur an Notfallbenutzer. Dasselbe betrifft auch RFC-Verbindungen von einem Entwicklungssystem zu produktiven Systemen. Solche Verbindungen sind nur in sehr eingeschränkten Umfang zu nutzen.