Absicherung der Entwicklung für produktive Umgebungen

Absicherung der Entwicklung für produktive Umgebungen

| Autor/in:hokomedia

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.

Sie haben Fragen?