Security in development systems

Security in development systems

Bei der Sicherheitsbetrachtung von SAP-Transportlandschaften ist nicht nur das Produktivsystem prüfungsrelevant. Auch die anderen Systeme, einschließlich der Entwicklungssysteme, sind in die Risikobetrachtungen einzubeziehen. Noch immer wird dort häufig das Profil SAP_ALL genutzt, anstelle konkreter Rollen. Dieser Beitrag zeigt hier die wesentlichen Risikofelder auf.

1. Allgemeine Betrachtungen

Ein wesentlicher Aspekt in der Risikobewertung eines Entwicklungssystems ist die Art der dort vorhandenen Daten. Normalerweise wird mindestens eine 3-System-Landschaft eingesetzt (Entwicklungs-, Test- und Produktivsystem). Dies dient u.a. dazu, dass (evtl. externe) Entwickler keinen Zugriff auf produktive bzw. produktionsnahe Daten haben. Da Entwickler mit den benötigten Entwicklerberechtigungen Zugriff auf alle Daten aller Mandanten des betroffenen Systems haben, sollten in einem Entwicklungssystem keine produktionsnahen Daten vorhanden sein. Auch eine Aufteilung in einen Entwicklungs- und einen Testmandanten (mit den sensiblen Daten) innerhalb des Systems schützt aus den oben genannten Gründen nicht vor unautorisierten Datenzugriffen.

Nachfolgend wird davon ausgegangen, dass keine produktionsnahen Daten auf dem Entwicklungssystem existieren. Andernfalls müssen erweiterte Berechtigungsprüfungen in den Modulen durchgeführt und zuvor die Zugriffe auf produktionsnahe Daten gegenüber dem Produktivsystem durch die jeweiligen Dateneigentümer genehmigt werden. Stichproben bezüglich vorhandener Daten sind anhand folgender Tabellen möglich:

 

Tabellen

Bezeichnung

Modul

LF*, z.B. LFA1

Lieferantenstamm (allgemeiner Teil)

FI

KN*, z.B. KNA1

Kundenstamm (allgemeiner Teil)

FI

BUT*, z.B. BUT000

GP: Allgemeine Daten I

Übergreifend

PA*, z.B. PA0008

Personal-Stammsatz Infotyp 0008 (Basisbezuege)

HR

Da Entwickler wie beschrieben durch ihre Entwicklerrechte quasi über eine Vollberechtigung verfügen, kann der Entzug der nachfolgend aufgeführten Berechtigungen zwar die Hemmschwelle zur Ausführung unautorisierter Tätigkeiten erhöhen, letztendlich aber nicht verhindern.

2. Sicherheit innerhalb des Entwicklungssystems

In diesem Kapitel werden die Risikothemen beleuchtet, die sich auf das Entwicklungssystem selbst beziehen, wie etwa ein Ausfall des Systems durch unautorisierte administrative Tätigkeiten, Zuordnung von Berechtigungen oder Unterwanderung der Nachvollziehbarkeit von Änderungen.

2.1 Gesetzeskritische Berechtigungen

Üblicherweise werden hierzu die Berechtigungen gezählt, mit denen Änderungsaufzeichnungen im System gelöscht werden können oder elektronisch radiert werden kann. Auch im Entwicklungssystem ist die Nachvollziehbarkeit von Änderungen wichtig, deshalb sind die nachfolgend aufgeführten Berechtigungen nur sehr restriktiv bzw. nur an Notfallbenutzer zu vergeben.

Löschen von Änderungsbelegen

Verschiedene Tätigkeiten, wie etwa die inhaltliche Änderung oder die Zuordnung von Rollen werden über Änderungsbelege nachvollziehbar gemacht. Diese Berechtigung sollte nur an einen Notfallbenutzer vergeben werden.

Löschen von Tabellenänderungsprotokollen

Änderungen im Customizing und verschiedene sicherheitsrelevante Änderungen, wie etwa die Pflege von RFC-Schnittstellen sind über Tabellenänderungsprotokolle einsehbar. Diese Berechtigung sollte nur an einen Notfallbenutzer vergeben werden.

Löschen von Versionen

Versionen sind die Änderungsbelege innerhalb der Entwicklungsumgebung, beispielsweise für Änderungen an ABAP-Quelltexten oder den technischen Eigenschaften von Tabellen. Diese Berechtigung sollte nur an einen Notfallbenutzer vergeben werden.

 

ABAP-Quelltexte über RFC installieren und ausführen

Über diese Berechtigungen kann unabhängig von den eigentlichen Entwicklerberechtigungen beliebiger Quellcode ausgeführt und somit eine beliebige Aktion im System ausgeführt werden. Diese Berechtigung sollte nur an einen Notfallbenutzer vergeben werden.

 

ABAP-Programme debuggen mit Replace

Diese sehr kritische Berechtigung kann genutzt werden, um elektronisch zu radieren, bzw. Programmabläufe inklusive der Berechtigungsabfragen auf vielfältige Weise zu manipulieren. Diese Berechtigung sollte nur sehr restriktiv vergeben werden, beispielsweise Entwickler benötigen die Berechtigung aber für ihre tägliche Arbeit.

Die nachfolgende Tabelle zeigt die Berechtigungen, die nicht oder nur restriktiv zu vergeben sind.

 

Berechtigungsobjekt

Feld

Wert

Debuggen mit Replace (§239 HGB Führung der Handelsbücher)

S_DEVELOP

ACTVT

Aktivität

02 (Ändern)

OBJTYPE

Objekttyp

DEBUG

Löschen von Tabellenänderungsprotokollen (S_TABU_DIS)

($257 Aufbewahrung von Unterlagen)

S_TABU_DIS

ACTVT

Aktivität

02 (Ändern)

DICBERCLS

Berechtigungsgruppe

SA

S_TABU_CLI

CLIIDMAINT

Kennzeichen

X

oder

S_TABU_NAM

ACTVT

Aktivität

02 (Ändern)

TABLE

Tabelle

DBTABLOG

S_TABU_CLI

CLIIDMAINT

Kennzeichen

X

Löschen von Änderungsbelegen ($257 Aufbewahrung von Unterlagen)

S_SCD0 oder

S_SCD0_OBJ

ACTVT

Aktivität

06 (Löschen)

ABAP-Quelltexte über RFC installieren und ausführen

(§239 HGB Führung der Handelsbücher)

S_RFCRAIAR

RFC_RAIAR

Aktivität

16 (Ausführen)

2.2 Basisadministration

Über administrative Tätigkeiten werden das Systemverhalten gesteuert und diverse sicherheitsrelevante Einstellungen vorgenommen. Um das Risiko eines Systemausfalls oder der Entstehung einer Sicherheitslücke zu minimieren, sollten administrative Rechte nur an Mitarbeiter der Basisadministration vergeben werden. Die nachfolgende Liste kann evtl. noch durch Vorschläge der unternehmenseigenen Administration ergänzt werden. Sie enthält jeweils nur die wesentlichen Berechtigungsobjekte je Themengebiet.

Berechtigungsobjekt

Feld

Wert

ALE Administration

B_ALE_LSYS

 

Objekt allgemein

oder

B_ALE_MODL

ACTVT

Aktivität

01 (Anlegen) oder

02(Ändern)

Archivierung

S_ARCHIVE

ACTVT

Aktivität

01 (Anlegen) oder

02(Ändern)

Systemadministration

S_ADMI_FCD

 

Objekt allgemein

oder

S_RZL_ADM

ACTVT

Aktivität

01 (Anlegen)

SOAP

S_SRT_ADM

ACTVT

Aktivität

02 (Ändern) oder

06 (Löschen) oder

43 (Freig. Web Services) oder

70 (Änderungen für Web Services)

oder

S_SRT_CA

ACTVT

Aktivität

02(Ändern)

oder

S_SRT_CF_C

ACTVT

Aktivität

01 (Anlegen) oder

02 (Ändern) oder

06 (Löschen)

oder

S_SRT_CF_P

ACTVT

Aktivität

01 (Anlegen) oder

02 (Ändern) oder

06 (Löschen)

Switch Framwork

S_SWITCH

ACTVT

Aktivität

02 (Pflege) oder

07 (Aktivieren)

Datenbankadministration

S_DBCON

ACTVT

Aktivität

23 (Pflege) oder

36 (Erweiterte Pflege) oder

71 (Analyse)

Change & Transport System

S_CTS_ADMI

 

Objekt allgemein

oder

S_CTS_SADM

 

Objekt allgemein

RFC

S_RFC_ADM

ACTVT

01 (Anlegen) oder

02 (Ändern) oder

06 (Löschen) oder

36 (Erweiterte Pflege)

oder

S_RFC_TT

ACTVT

01 (Anlegen) oder

02 (Ändern) oder

06 (Löschen)

oder

S_RFC_TTAC

ACTVT

02 (Ändern) oder

36 (Erweiterte Pflege) oder

51 (Initialbefüllung der Zugangskontrolltabelle) oder

63 (Änderung der Zugangskontrollmethode)

2.3 Anzeigen sensibler Daten

Wie bereits erwähnt, wird davon ausgegangen, dass keine produktionsnahen Daten im Entwicklungssystem vorgehalten werden, somit werden die nachfolgend aufgeführten Daten als die sensibelste angesehen.

 

Hashwerte der Benutzerkennwörter

Der Zugriff auf diese Daten, ist kritisch, da über Tools die Hashwerte evtl. entschlüsselt werden können und somit eine unautorisierte Anmeldung an das SAP-System möglich ist. Da oftmals identische Kennwörter für verschiedene Systeme verwendet werden, ist das ermittelte Kennwort somit evtl. auch für nachgelagerte Systeme nutzbar. Die aktuellen bzw. ehemaligen Hashwerte der Kennwörter werden in den Tabellen USR02, USH02, USRPWDHISTORY, USH02_ARC_TMP, VUSER001 und VUSR02_PWD vorgehalten.

Auf diese Tabellen kann entweder über klassische Tabellenzugriffs-Transaktionen wie z.B. SE16 oder aber über Datenbankadministrartions-Transaktionen wie DBACOCKPIT zugegriffen werden. Die benötigten Berechtigungen für Tabellenzugriffe über Datenbankwerkzeuge sind abhängig von der jeweiligen Systemkonfiguration und sollten ggf. über einen Berechtigungs-Trace (Transaktion STAUTHTRACE) verifiziert werden.

Statistikdaten anderer Benutzer

Weiterhin sind die Statistikdaten anderer Benutzer (Benutzeraktivitäten, wie z.B. ausgeführte Reports und Transaktionen) als sensibel einzuordnen, da über diese Daten evtl. Rückschlüsse auf das Arbeitsverhalten gezogen werden können. Diese Daten lassen sich beispielsweise über die Transaktion ST03N anzeigen.

Die Zugriffsberechtigungen auf die beiden oben genannten Datenarten sind nur sehr restriktiv zu vergeben.

Die nachfolgende Liste enthält jeweils nur die wesentlichen Berechtigungsobjekte je Themengebiet.

Berechtigungsobjekt

Feld

Wert

Lesen der Tabellen der Benutzeranmeldedaten

S_TABU_DIS

ACTVT

Aktivität

03 (Anzeigen)

DICBERCLS

Berechtigungsgruppe

SPWD

oder

S_TABU_NAM

ACTVT

Aktivität

03 (Anzeigen)

TABLE

Tabelle

USR02 oder

USH02 oder

USRPWDHISTORY oder

USH02_ARC_TMP oder

VUSER001 oder

VUSR02_PWD

Zugriff auf Datenbanktabellen vom SAP-System aus

S_TABU_SQL

ACTVT

Aktivität

33 (Lesen)

TABLE

Tabelle

<Tabellenname>

oder

S_DBCON

ACTVT

Aktivität

36 (Erweiterte Pflege)

Benutzeraktivitäten

S_TOOLS_EX

AUTH

Berechtigungsname in Benutzerstammpflege

S_TOOLS_EX_A

2.4 Benutzer-und Berechtigungsverwaltung

Wie in anderen Systemen auch, ist die Benutzerpflege und Rollen-/Profilzuordnung auf den Kreis der Benutzeradministratoren einzugrenzen. Im Gegensatz zu den Vorsystemen werden hier jedoch die Rollen und Profile gepflegt, so dass entsprechende Rechte an die Rollen-/Profiladministratoren zu vergeben sind. Die wichtigsten Berechtigungskonstellationen sind nachfolgend aufgeführt:

Berechtigungsobjekt

Feld

Wert

Benutzerpflege

S_USER_GRP

ACTVT

Aktivität

01 (Anlegen) oder

02 (Ändern) oder

05 (Kennwort ändern) oder

06 (Löschen)

Rollenpflege

S_USER_AGR

ACTVT

Aktivität

01 (Anlegen) oder

02 (Ändern) oder

06 (Löschen)

Rollenzuordnung

S_USER_AGR

ACTVT

Aktivität

22 (Zuordnen)

oder (falls in Tabelle PRGN_CUST aktiviert)

S_USER_SAS

ACTVT

Aktivität

22 (Zuordnen)

Profilpflege

S_USER_PRO

ACTVT

Aktivität

01 (Anlegen) oder

02 (Ändern) oder

06 (Löschen)

Profilzuordnung

S_USER_PRO

ACTVT

Aktivität

22 (Zuordnen)

oder (falls in Tabelle PRGN_CUST aktiviert)

S_USER_SAS

ACTVT

Aktivität

22 (Zuordnen)

2.5 Hintergrundverarbeitung

Bei der Einplanung eines Jobs kann ein anderer Benutzer als ausführender Benutzer hinterlegt werden. Somit werden die einzelnen Verarbeitungsschritte des Jobs technisch durch den hinterlegten Benutzer mit seinen Berechtigungen durchgeführt. Es könnten also Aktivitäten angestoßen werden, die mit den eigenen Berechtigungen nicht ausführbar wären.

Die Berechtigung, andere Benutzer in Jobs hinterlegen zu können, ist nur restriktiv zu vergeben.

Berechtigungsobjekt

Feld

Wert

Benutzerpflege

S_BTCH_NAM

BTCUNAME

Hintergrundbenutzername für Berechtigungsüberprüfung

<nur restriktiv>

Fazit

Die Sicherheit eines SAP-Systems ist nicht nur von der Absicherung des Produktivsystems abhängig. Die Entwicklungssysteme sollten ebenfalls betrachtet werden, da hier über zu transportierende Änderungen in der Entwicklungsumgebung und im Customizing oder über mangelhaft konfigurierte Schnittstellen Einfluss auf das Produktivsystem genommen werden kann. Abhängig von der konzeptionellen Granularität der Zuständigkeiten im Entwicklungs- und Customizing-Umfeld sind evtl. genauere Berechtigungsprüfungen durchzuführen.

Sie haben Fragen?