Müssen Entwicklungssysteme eigentlich geprüft werden? Worin liegt denn das Risiko eines solchen Systems?
Oftmals lässt ein prall gefüllter Prüfplan kaum die Zeit, auch solche eher unscheinbaren Systeme zu analysieren. Kann man das Risiko ungeprüfter E-Systeme tragen, oder grenzt das schon an Fahrlässigkeit?
Der folgende Artikel beleuchtet die Risiko-Felder eines Entwicklungssystems und stellt konkrete Anregungen für Prüfungen zur Verfügung.
1.1 Risiken innerhalb des Entwicklungssystems
Da das Entwicklungssystem als Einstiegspunkt für systemübergreifende Zugriffe innerhalb des SAP-Systemverbunds genutzt werden könnte, ist hier grundsätzlich auch eine grundlegende Systemhärtung analog zu den anderen SAP-Systemen vorzunehmen, dazu gehören etwa die Anmeldesicherheit und die Absicherung der Standardbenutzer.
Über die TA (Transaktion) RSPFPAR können die Anmeldeparameter, im Allgemeinen im Namensraum login/* angezeigt werden. In dem Umfeld sind auch die den Benutzern zugeordneten Sicherheitsrichtlinien zu berücksichtigen, die benutzerspezifisch die Anmeldeparameter überschreiben können, inhaltlich über die Tabelle SEC_POLICY_RT und bezogen auf die Benutzerzuordnung über die Transaktion SUIM auswertbar.
Die System- und Mandantenänderbarkeit sind hier grundsätzlich anders als im Q- und P-System zu konfigurieren. Zwar muss das System grundsätzlich offen sein, in der Systemänderbarkeit sollten aber nicht alle Softwarekomponenten und Namensräume für Änderungen freigegeben werden, dies gilt umso mehr für SAP S/4HANA® Systeme, in denen keine Entwicklerschlüssel für Änderungen in der Entwicklungsumgebung und keine Objektschlüssel für Modifikationen von originalen SAP-Objekten mehr benötigt werden (liegt vor, falls über das Menü SYSTEM – STATUS – in den Produktversions-Details die Softwarekomponente S4CORE zu finden ist). Auch sollten evtl. einzelne Mandanten für das Customizing oder den Zugriff auf die Systemobjekte gesperrt werden.
Neben der allgemeinen Systemänderbarkeit über die TA RSWBO004 lassen sich die einzelnen Softwarekomponenten und Namensräume umfassend über die Tabellen DLV_SYSTC und TRNSPACE (bzw. TRNSPACETT) auswerten. Die Mandantenänderbarkeit und die Systemänderbarkeit pro Mandant werden in der allgemeinen Tabelle der Mandanten T000 abgespeichert.
Wie in den nachgelagerten Systemen muss auch im Entwicklungssystem die Nachvollziehbarkeit der Änderung von Objekten sichergestellt sein. Änderungsbelege für Stamm- und Bewegungsdaten, Tabellenänderungsprotokolle für das Customizing und Versionen für die Entwicklungsumgebung werden in dem System erzeugt, in dem die Änderungen vorgenommen werden, also überwiegend im Entwicklungssystem (zumindest für Customizing- und Entwicklertätigkeiten). Dem entsprechend muss auch hier die Tabellenprotokollierung aktiviert werden.
Die Aktivierung der Tabellenprotokollierung findet über den Systemparameter rec/client (TA RSPFPAR) statt. Hier sollten mindestens die Mandanten 000 und die Mandanten, aus denen heraus transportiert wird, eingetragen sein. Diese Eigenschaft lässt sich dem Feld CCCORACTIV der Tabelle T000 entnehmen.
Gesetzeskritische Berechtigungen u. a. zum Löschen der genannten Änderungsaufzeichnungen sind ebenfalls zu entziehen, um der Aufbewahrungspflicht dieser Protokolle nachzukommen. Allerdings ist an dieser Stelle zu erwähnen, dass ein Entwickler mit Entwicklerberechtigungen ein „Gott“ im System ist, der jederzeit in beliebiger Form auf alle Daten aller Mandanten des Systems zugreifen kann, dass ein Entzug von Berechtigungen bei dieser Anwendergruppe also höchstens die Hemmschwelle für unautorisierte Aktivitäten erhöhen kann. Im Gegensatz zu den P-Systemen kann man hier leider die Entwicklerberechtigungen, also auch zum Debugging mit Replace nicht allen Benutzern entziehen, sondern kann sie nur möglichst restriktiv vergeben.
Ansonsten sind hier die gesetzeskritischen Berechtigungen analog zum P-System zu sehen, also solche, mit denen die Nachvollziehbarkeit von Änderungen unterwandert werde kann, wie etwa das Löschen von Tabellenänderungsprotokollen, Änderungsbelegen und Versionen. Die Berechtigungen können wie gewohnt über die Transaktion SUIM (Benutzer nach komplexen Selektionskriterien) analysiert werden.
Durch die Tatsache, dass Entwicklerrechte vergeben sind, dürfen nach Möglichkeit keine sensiblen Daten im System existieren, um dem Thema Datenschutz nachzukommen. Dies lässt sich nicht vollständig vermeiden, so können beispielsweise auch hier die gehashten Kennwörter ausgelesen oder die Benutzerstatistik für eine Auswertung des Arbeitsverhaltens genutzt werden. Zumindest sollten keine Kopien sensibler Fachbereichsdaten für Testzwecke vorliegen, was durch Stichprobenprüfungen nachvollzogen werden muss. Hier können über entsprechende Transaktionen zur Tabellenanzeige (z. B. SE16) typische Tabellen-Namensräume ausgewertet werden, also beispielsweise Geschäftspartnerdaten (Tabellen BUT*), Kundendaten (Tabellen KN*), Lieferantendaten (Tabellen LF*) oder Personaldaten (Tabellen PA0*).
Berechtigungen zur Benutzer- und Berechtigungsverwaltung dürfen nur in der Hand der vorgesehenen Administratoren liegen, da sich ansonsten Benutzer selbst die Berechtigungen für unautorisierte Aktivitäten zuordnen könnten.
Auch hier sind die Berechtigungen über die TA SUIM auswertbar, die wesentlichen Berechtigungsobjekte für das Benutzer- und Berechtigungs-Umfeld liegen im Namensraum S_USER*.
Wie in den P-Systemen sollten auch hier die Benutzer keine Berechtigungen zum Einplanen von Jobs mit beliebigen anderen Benutzern in der Hintergrundverarbeitung besitzen, da hier ein hochberechtigter Benutzer hinterlegt werden könnte, in dessen Namen unautorisierte Aktivitäten durchführbar wären.
Über die TA SUIM sind hier die Berechtigungsobjekte S_BTCH_NAM und/ oder S_BTCH_NA1 auszuwerten.
Ein weiteres Risiko besteht in unautorisierten Aktivitäten in der Basisadministration, wodurch beispielsweise die Systemverfügbarkeit gefährdet werden könnte. Oftmals werden in Entwicklungssystemen die Berechtigungen für alle Anwender über eine Rolle mit einer Vollberechtigung aufgebaut, aus der lediglich die kritischen Berechtigungen entfernt und für ausgewählte Anwendergruppen in separaten Rollen zugeordnet werden. Die startbaren Anwendungen (Transaktionen etc.) werden hier sehr großzügig bis vollumfänglich vergeben. Somit gibt es für die Anwender also viele Zugriffmöglichkeiten. Daher bietet es sich an, z. B. im Umfeld der Basisadministration nur auf die kritischen Berechtigungsobjekte ohne zugehörige Transaktionsberechtigung zu prüfen.
Typische administrative Berechtigungsobjekte sind beispielsweise S_RZL_ADM, S_ADMI_FCD oder Objekte aus dem RFC-Umfeld S_RFC_ADM, S_RFC_TT oder S_RFC_TTAC
1.2 Risiken für nachgelagerte Systeme
Über Transporte gelangen Änderungen in der Entwicklungsumgebung und im Customizing (im weitesten Sinne, also z. B. auch Rollenänderungen) in die nachgelagerten Systeme.
Insbesondere in SAP S/4HANA® basierten Systemen sollten Berechtigungen in der Entwicklung nur restriktiv vergeben werden, weil hier – wie bereits beschrieben – keine Entwickler- und Objektschlüssel benötigt werden. So sollten nach Möglichkeit Entwicklerberechtigungen auf original SAP-Objekte nur nach Antrag vergeben werden (Berechtigungsobjekt S_DEVELOP, Feld DEVCLASS (Paket) oder OBJNAME (Objektname)).
Das Prüfen der Customizing-Berechtigungen ist abhängig von dem vorliegenden Konzept zu diesem Thema und von der genauen Definition des Begriffs Customizing. Der Zugriff auf den gesamten Einführungsleitfaden, in dem die Customizing-Aktivitäten themenbasiert durchgeführt werden können, ist über die Transaktion SPRO möglich. In der hierarchischen Auflistung der möglichen Customizing-Funktionen befinden sich mehrere zig-tausend Einträge. Darunter befinden sich beispielsweise auch Transaktionen für die Benutzerpflege (SU01) oder für die Schnittstellenadministration (SM59). Customizing im engeren Sinne bedeutet eigentlich, die Unternehmensstruktur in Tabellen abzubilden. Customizing-Berechtigungen würden hier also in Form von Tabellenberechtigungen, basierend auf den Objekten S_TABU_DIS und S_TABU_NAM (evtl. zusätzlich S_TABU_CLI für die Pflege von Systemtabellen) durchgeführt werden. Wird das Customizing konzeptionell modulabhängig durchgeführt, so könnte beispielsweise geprüft werden, ob Benutzer umfassende Tabellenänderungsrechte besitzen. Ansonsten wären Stichprobenprüfungen auf ausgewählte Customizing-Tabellen verschiedener Module möglich.
Für den Entwicklungs- bzw. Customizing- und Transportprozess gilt, dass für den gesamten Prozess über die gesamte Transportlandschaft (normalerweise E-, Q- und P-System) hinweg ein 4-Augen Prinzip umgesetzt sein sollte. Abhängig von den genutzten Prozessen sollte also im Entwicklungssystem geprüft werden, wer dort welchen Transportschritt durchführen darf. Oftmals dürfen Entwickler und Customizer dort nur ihre eigenen Aufgaben freigeben (Berechtigungsobjekt S_TRANSPRT bzw. S_SYS_RWBO).
Als SAP-System mit dem potenziell niedrigsten Sicherheitsniveau aller SAP-Systeme und diversen maximal berechtigten und evtl. unternehmensfremden Benutzern besteht das Risiko, dass durch schlecht konfigurierte RFC-Verbindungen ein Übergriff auf andere SAP-Systeme in und außerhalb der Transportlandschaft möglich ist. So muss geprüft werden, ob Definitionen von RFC-Verbindungen auf kritische Systeme bzw. Mandanten mit einem im Zielmandanten hoch berechtigten Benutzer mit hinterlegtem Kennwort vorhanden sind (Tabelle RFCDES).
Über das Verfahren Trusted RFC können spezielle Trusted RFC-Verbindungen ohne ein hinterlegtes Kennwort definiert werden. Hier sollte vor allen Dingen auch geprüft werden, ob kritische Systeme (P- oder Q-Systeme mit sensiblen Daten) dem Entwicklungssystem vertrauen, was nicht der Fall sein sollte (Tabelle RFCTRUST).
2. Prüfen eines Entwicklungssystems mit CheckAud®
In CheckAud® gibt es seit dem letzten Release-Wechsel einen eigenen Vorlage-Prüfbaum speziell für Entwicklungssysteme (siehe Abb.1).
Hier sind sämtlich behandelten Risiko-Felder mit den benötigten Prüfpunkten hinterlegt, so dass eine schnelle und einfache Prüfung eines Entwicklungssystems vorgenommen werden kann (siehe Abb.2).
Es ist auch zu erkennen, dass die Abfragen teilweise ohne Transaktionsberechtigungen definiert sind, da diese erwartungsgemäß sehr umfangreich vergeben sein können.
Da momentan mit CheckAud® keine Tabellen mit den potenziell produktionsnahen und somit sensiblen Daten ausgelesen werden, müsste die Stichprobenprüfung auf kopierte Daten aus der Produktivumgebung nach wie vor manuell im E-System durchgeführt werden, während alle weiteren Prüfpunkte gewohnheitsgemäß mit einem Knopfdruck durchführbar sind.
Sollten wider Erwarten produktionsnahe Daten im E-System vorliegen, so müssten die Zugriffsrechte dort aus Datenschutzgründen theoretisch ähnlich restriktiv wie im Q- oder P-System vergeben werden. Hier könnten dann die entsprechenden Prüfbäume aus den Modulen verwendet werden, im Prüfbaum für E-Systeme sind keine modulspezifischen Abfragen vordefiniert Da Entwickler aber immer Zugriff auf alle Daten haben, schließt sich dieses Konstrukt jedoch datenschutztechnisch grundsätzlich aus. Auch eine Lösung über separate Entwicklungs- und Testumgebungen mit sensiblen Testdaten über getrennte Mandanten innerhalb des Entwicklungssystems ändert an der Allmacht der Entwickler mit umfassenden Datenzugriffsmöglichkeiten nichts.
