Wichtige Prüfungsaspekte des SAP Change and Transport System (CTS)

Einleitung

Änderungen an einem SAP-Produktivsystem werden häufig über die Transaktionen und Werkzeuge des SAP Change and Transport System (CTS) vorgenommen. Länder- und branchenspezifische Vorschriften legen fest, welche dieser Änderungen protokolliert werden müssen und wie lange diese Informationen aufzubewahren sind. Diese Vorschriften werden oft durch unternehmensspezifische Audit-Anforderungen ergänzt. Dieser Blogbeitrag soll eine Übersicht über verschiedene technische Bereiche im SAP CTS geben, die berücksichtigt werden müssen, um all diese Anforderungen zu erfüllen. 

Tabellenprotokollierung

Hier werden allgemeine Aspekte der Tabellenänderungsprotokollierung in SAP sowie deren Aktivierung beschrieben. Die Aktivierung über den Profilparameter rec/client aktiviert die Aufzeichnung aller lokalen Änderungen an Tabellen, die für die Tabellenprotokollierung gekennzeichnet sind. Dies umfasst alle manuellen Änderungen, beispielsweise über die Transaktionen SM30/SM31, sowie alle Änderungen, die über Transaktionen und Reports vorgenommen werden. Änderungen an diesen Tabellen, die über Transportaufträge durchgeführt werden, fallen nicht unter diesen Profilparameter! Um diese Lücke zu schließen, muss der entsprechende TMS-Parameter RECCLIENT gepflegt werden. Er sollte mit dem Wert übereinstimmen, der für den Profilparameter rec/client gesetzt ist. Mögliche Werte für RECCLIENT sind:

 

Parameterwert

Beschreibung

AUS

Standard: Über Transporte vorgenommene Tabellenänderungen werden nicht protokolliert

ALLE

Tabellenänderungen, die über Transporte vorgenommen werden, werden für alle Mandanten protokolliert

<Client1>, <Client2>…

Tabellenänderungen, die über Transporte vorgenommen wurden, werden für die angegebenen Mandanten protokolliert 

Objektversionierung vor dem Import

Audit-Anforderungen verlangen nicht nur die Nachverfolgung und dauerhafte Speicherung von Datenänderungen – sie sollen auch Fragen beantworten wie „Wurde die Berechtigung für die Datenänderung technisch validiert?“ und„Welche konkrete Berechtigung wurde bei der Datenänderung geprüft?“ Um diese Fragen zu beantworten, reicht es nicht aus, die Transaktion oder den Bericht zu prüfen, die bzw. der die Datenänderungen ausgelöst hat. Es muss auch die Version dieser Transaktion oder des Berichts überprüft werden, die zum Zeitpunkt der Änderungen in der Produktionsumgebung aktiv war. Standardmäßig sind diese Informationen nicht leicht abzurufen. 

Obwohl die meisten Objekte der SAP-Workbench, einschließlich Berichte, versionsverwaltbar sind, speichert das Zielsystem eines Imports keine Informationen über frühere Versionen der importierten Objekte. Die alte aktive Objektversion wird einfach durch eine neue ersetzt. Dieses Standardverhalten kann durch Setzen des TMS-Parameters VERS_AT_IMP geändert werden. Mögliche Werte sind:

Parameterwert

Beschreibung

NIEMALS

Standard: Im System werden keine permanenten Versionen nachverfolgt, wenn das Objekt durch einen Import geändert wird

IMMER

Jedes Mal, wenn ein Objekt durch einen Import mit einer Version überschrieben werden soll, die von der aktuell aktiven Version dieses Objekts abweicht, wird die aktuelle Version dauerhaft gespeichert, bevor sie durch die neue ersetzt wird 

C_ONLY

Genau wie IMMER, mit dem Unterschied, dass die Versionierung nur bei Umzugs-Transporten durchgeführt wird. Im Grunde genommen also dann, wenn die Entwicklung eines Objekts auf ein anderes System verlagert wird.

Hinweis: Die Aktivierung der Versionierung von Objekten vor dem Import wirkt sich negativ auf die Importleistung aus. Insbesondere bei großen Release-Rollouts mit Hunderten oder Tausenden von Transportaufträgen sollten Sie unbedingt zusätzliche Zeit für das geplante Zeitfenster einplanen.

Ab S/4HANA 2021 hat SAP die Standardwerte für RECCLIENT und VERS_AT_IMP geändert. Im Einklang mit der „Secure-by-Default“-Initiative lauten die neuen Standardwerte RECCLIENT = ALL und VERS_AT_IMP = ALWAYS. Dies gilt nicht für Upgrades von älteren S/4HANA-Releases auf S/4HANA 2021. Einzelheiten finden Sie im SAP-Hinweis Nr . 2926224.

Versionsverwaltung von Objekten vor dem Export

Theoretisch könnten die oben genannten Prüfungsanforderungen auch erfüllt werden, ohne VERS_AT_IMP in den Produktivsystemen zu aktivieren, da die Versionierung auf den Entwicklungssystemen standardmäßig aktiviert ist. Jedes Mal, wenn ein versionierbares Objekt aus dem Entwicklungssystem exportiert wird, wird eine permanente Version gespeichert. Dieses Verhalten wird durch den TMS-Parameter VERS_AT_EXP gesteuert, dessen Standardwert TRUE ist. Mögliche Werte sind:

Parameterwert

Beschreibung

FALSCH

Dieser Wert wird erst ab Basis-Release 7.51 für Transporte berücksichtigt, die mit dem Transport Organizer exportiert werden.

WAHR

Standard: Bei jedem Export eines Transportauftrags wird für jedes versionierbare Objekt eine Version erstellt.

NEIN_T

Jedes Mal, wenn ein Transportauftrag, bei dem es sich nicht um einen Kopientransport (TOC) handelt, exportiert wird, wird für jedes versionsfähige Objekt eine Version erstellt.

Der Wert NO_T wurde 2016 eingeführt, da bestimmte Szenarien in SAP (z. B. Retrofit) eine große Anzahl von Transporten mit Kopien von Objekten erzeugen, die sich nicht ändern. Um die Erzeugung einer großen Anzahl identischer Versionen zu vermeiden, kann der Parameter VERS_AT_EXP auf NO_T gesetzt werden. 

Es besteht kein Zweifel daran, dass die Versionierung von Objekten vor dem Export auch für Entwickler zahlreiche Vorteile bietet. Sie können die Versionsdatenbank nutzen, um verschiedene Versionen zu vergleichen und so besser zu erkennen, was vor einer bestimmten Version oder einem bestimmten Datum geändert wurde. Sie können sogar ganz einfach eine alte Version abrufen, um geplante Änderungen auf der Grundlage einer validierten Objektversion von Grund auf neu zu beginnen. Aus Sicht der Revision stellt es ein Risiko dar, sich ausschließlich auf die im Entwicklungssystem gespeicherten Versionen zu verlassen. Die Gründe dafür sind:

  • Die Zugriffsberechtigungen auf Entwicklungssystemen sind weniger restriktiv und können mit Entwicklerberechtigungen sogar umgangen werden. Daher lassen sich Versionsinformationen auf Entwicklungssystemen leicht manipulieren.
  • Entwicklungssysteme können aktualisiert werden. Es besteht die Möglichkeit, die Versionsdatenbank zu sichern und wiederherzustellen, allerdings stimmen die wiederhergestellten Daten nicht mit dem Systemverlauf überein.
  • Die Zeitstempel der Versionen in der Versionsdatenbank auf dem Entwicklungssystem entsprechen den Export-Zeitstempeln. Um zu überprüfen, wann die einzelnen Versionen in der Produktion aktiv waren, müssen zusätzliche Protokolle analysiert werden, beispielsweise die Importprotokolle der entsprechenden Transportaufträge (die möglicherweise gelöscht oder archiviert wurden).
     

Hinweis: Der Report RSVCDI00 liefert eine vollständige Liste aller versionierbaren Objekte für die SAP-NetWeaver-Version eines bestimmten Systems.

SAP-Transportdateien

Während des Transportvorgangs werden drei verschiedene Dateitypen erstellt. Jeder Transport umfasst die folgenden Dateien:

Dateityp

Beschreibung

Datendatei

Wird beim Export eines Transportauftrags erstellt. Es handelt sich um die wichtigste Datei, da sie alle Informationen zu den transportierten Objekten und Daten enthält. Somit kann sie als Sicherungsdatei aller exportierten Objektversionen betrachtet werden.

gemeinsam einreichen

Wird beim Export eines Transportauftrags erstellt und bei jedem Import erweitert. Es enthält control für die Transportwerkzeuge sowie Export-/Import-Rückgabecodes für jeden Export-/Importschritt

Protokolldateien

Mehrere export-/importschrittbezogene Protokolldateien, die Prozessinformationen zu den einzelnen Schritten enthalten

Transportdateien werden im Transportverzeichnis gespeichert, das häufig von mehreren SAP-Landschaften gemeinsam genutzt wird.

Je nach Umfang der Systemlandschaft eines Kunden und dem Ausmaß der kundenspezifischen Entwicklung können dieses Verzeichnis und seine Unterverzeichnisse sehr schnell anwachsen. Dies kann sich negativ auf die Leistung der Transportprozesse auswirken. Ein einfaches Löschen dieser Dateien ist keine Option, da sie möglicherweise für zukünftige Importe noch benötigt werden. Auch aufgrund von Prüfungsvorschriften kann es erforderlich sein, diese Dateien für einen bestimmten Zeitraum aufzubewahren.

SAP bietet auf Betriebssystemebene integrierte Funktionen, die Administratoren dabei unterstützen, Transportdateien zu identifizieren, die für den Import in andere Systeme nicht mehr benötigt werden. Der SAP-Kernel stellt einige Betriebssystembefehle bereit, die Administratoren bei der Neuordnung der Transportdateien helfen:

OS-Befehl

Protokolldatei unter „usr/sap/trans/tmp“

Beschreibung

tp alles überprüfen

check.log

Dieser Befehl ermittelt alle Transportaufträge, die nicht mehr für den Import in eines der Systeme vorgemerkt sind (und in keiner Importwarteschlange auf einen Import warten). Diese Aufträge werden in die Datei „check.log“ geschrieben.

tp testold alle

testold.log

Dieser Befehl simuliert die Ergebnisse des Befehls „tp clearold all“ (siehe nächste Zeile)

tp clearold all

clearold.log

Auf der Grundlage der Liste, die mit dem Befehl „tp check all“ erstellt wird, und unter Berücksichtigung der entsprechenden TMS-Parameter (siehe folgende Tabelle) werden Dateien entweder gelöscht oder – im Falle von Datendateien – von „usr/sap/trans/data“ nach „usr/sap/trans/olddata“ verschoben. 

Es gibt mehrere TMS-Parameter, die control der Transportdateien von den oben genannten tp-Befehlen berücksichtigt werden:

TMS-Parameter

Standardwert

Beschreibung

cofilelifetime

365

Das Mindestalter einer Co-Datei in Tagen, bevor sie durch die Kombination der Befehle`tp check all ` und `tp clearold all ` gelöscht wird . Eine weitere Voraussetzung ist, dass der entsprechende Transportauftrag für keines der Systeme mehr zum Import vorgemerkt ist.

Datenlebensdauer

200

Das Mindestalter einer Datendatei in Tagen, bevor sie durch die Kombination der Befehle „tp check all“ und „tp clearold all“ in das Unterverzeichnis „olddata“ verschoben wird. Eine weitere Voraussetzung ist, dass der entsprechende Transportauftrag für keines der Systeme mehr zum Import vorgemerkt ist. 

Log-Lebensdauer

200

Das Mindestalter einer Protokolldatei in Tagen, bevor sie durch die Kombination der Befehle `tp check all ` und `tp clearold all` gelöscht wird. Eine weitere Voraussetzung ist, dass der entsprechende Transportauftrag für keines der Systeme mehr zum Import vorgemerkt ist.

Lebensdauer alter Daten

365

Das Mindestalter einer Datendatei in Tagen, bevor sie durch die Kombination der Befehle `tp check all` und `tp clearold all` aus dem Unterverzeichnis „olddata“ gelöscht wird. Eine weitere Voraussetzung ist, dass der entsprechende Transportauftrag für keines der Systeme mehr zum Import vorgemerkt ist.

Hinweis: Je nach den geltenden Vorschriften können die SAP-Standardwerte zu niedrig sein. Es wird dringend empfohlen, die Transportdateien regelmäßig zu archivieren, anstatt sie vollständig zu löschen. Verwenden Sie das Ergebnis des Befehls „tp check all“, um festzustellen, welche Dateien zur Archivierung bereit sind. 

Fazit

Ein Großteil der auditrelevanten Änderungen wird über Transportaufträge in ein Produktivsystem übernommen. Glücklicherweise bietet SAP CTS die entsprechenden Funktionen, um alle Aspekte wie Rückverfolgbarkeit, Überwachung und Berichterstellung abzudecken. Kunden müssen sicherstellen, dass die entsprechenden Parameter korrekt eingestellt sind, um diese Funktionen zu aktivieren. Eine permanente Überwachung dieser Parameter wird ebenfalls empfohlen, um unerwünschte Änderungen – sei es versehentlich oder absichtlich – zu verhindern.

Onapsis Assess Onapsis-Kunden bei der automatisierten Überprüfung der korrekten Werte der TMS-Parameter RECCLIENT und VERS_AT_IMP und arbeitet derzeit daran, auch VERS_AT_EXP abzudecken. Erfahren Sie mehr über die Platform SAP-Sicherheit und darüber, wie wir SAP-Kunden bei der Überwachung aller wichtigen Aspekte der SAP-CTS-Einstellungen unterstützen.