Important Audit Aspects of the SAP Change and Transport System (CTS)
Introduction
Changes to an SAP production system are often applied via the transactions and tools of the SAP Change and Transport System (CTS). Country and industry-specific regulations define which of these changes have to be logged and how long this information must be kept. These regulations are often augmented by company-specific audit requirements. This blog is to provide a list of different technical areas in SAP CTS that need to be taken into consideration in order to fulfill all of these requirements.
Table Logging
General aspects of table change logging in SAP and how to enable it are described here. The activation via profile parameter rec/client activates the recording of all local changes to tables that are flagged for table logging. This includes all manual changes for example, transactions SM30/SM31, as well as all changes that are applied via transactions and reports. Changes to these tables that are applied via transport requests are not covered by the profile parameter! In order to close this gap, the corresponding TMS parameter RECCLIENT must be maintained. It should match with the value that is set for the profile parameter rec/client. Possible values for RECCLIENT are:
|
Parameter Value |
Description |
|
OFF |
Default: Table changes applied via transports are not logged |
|
ALL |
Table changes applied via transports are logged for all clients |
|
<Client1>, <Client2>… |
Table changes applied via transports are logged for the specified clients |
Object Versioning Before Import
Audit requirements not only demand the tracking and persistent storage of data changes–they also are expected to answer questions such as “Was the authorization for the data change technically validated?” and “Which specific authorization was checked when the data was changed?” In order to answer these questions, it is not enough to check the transaction or report that initiated the data changes. The version of that transaction, or the report that was active on production when the changes were applied, must also be checked. By default, this information is not easy to retrieve.
Although most of the SAP workbench objects, including reports, are versionable, the target system of an import does not store information about previous versions of the objects that have been imported. The old active object version is just replaced by a new one. This default behavior can be changed by setting the TMS parameter VERS_AT_IMP. Possible values are:
|
Parameter Value |
Description |
|
NEVER |
Default: No permanent versions are tracked in the system, if the object is changed by an import |
|
ALWAYS |
Every time an object is going to be overwritten by an import with a version that differs from the current active version of that object, the current version is stored permanently before it is replaced by the new one |
|
C_ONLY |
The same as ALWAYS, except that versioning is only executed for relocation transports. Basically, when moving the development of an object to another system. |
Note: The activation of the versioning of objects before import has a negative impact on the import performance. Especially for large release rollouts, including hundreds or thousands of transport requests, you should be sure to allow extra time for the planned time window.
As of S/4HANA 2021, SAP has changed the default values for RECCLIENT and VERS_AT_IMP. In accordance with the secure-by-default initiative, the new default values are RECCLIENT = ALL and VERS_AT_IMP = ALWAYS. This does not apply for upgrades from older S/4HANA releases to S/4HANA 2021. Details can be found in SAP note #2926224.
Object Versioning Before Export
Theoretically, the above audit requirements could also be fulfilled without activating VERS_AT_IMP in production systems since versioning is enabled on the development systems by default. Every time a versionable object is exported from the development system, a permanent version is stored. This behavior is controlled by the TMS parameter VERS_AT_EXP whose default is TRUE. Possible values are:
|
Parameter Value |
Description |
|
FALSE |
This value is taken into account only as of Basis Release 7.51 for transports that are exported with the Transport Organizer. |
|
TRUE |
Default: Every time a transport request is exported, a version is written for each versionable object. |
|
NO_T |
Every time a transport request that is not a transport of copies (TOC), is exported, a version is written for each versionable object. |
The value NO_T was introduced in 2016 as some scenarios in SAP (for example: Retrofit) generate a lot of transport of copies with objects that do not change. In order to avoid generating a large number of identical versions, the parameter VERS_AT_EXP can be set to NO_T.
There is no doubt that versioning of objects before export has a lot of benefits for developers, too. They can use the version database to compare different versions to better identify what has been changed prior to a specific version or date. They can even very easily retrieve an old version to start planned changes from scratch, based on a validated object version. From an audit perspective, relying only on versions that are written on the development system, represents a risk. The reasons for this are:
- Authorizations on development systems are less restrictive and can even be bypassed with developer authorizations. Thus, version information on development systems can easily be manipulated.
- Development systems may be refreshed. There is an option to backup and restore the version database, but the restored data will not align to the system history.
- The timestamps of the versions, in the version database on the development system, reflect the export timestamps. In order to check when each of the versions were active in production, it needs to analyze additional logs, such as the import logs of the corresponding transport requests (which may have been deleted or archived).
Note: Report RSVCDI00 provides a complete list of all versionable objects for the SAP NetWeaver version of a specific system.
SAP Transport Files
There are three different types of files generated during the transport process. Each transport includes the following files:
|
File Type |
Description |
|
datafile |
Created during the export of a transport request. It is the most important file since it contains the complete information about the transported objects and data. Thus, it can be seen as a backup file of all exported object versions |
|
cofile |
Created during the export of a transport request and extended during each import. It contains control information for the transport tools and export/import return codes for each export/import step |
|
log files |
Multiple export/import step-specific log files containing process information of the individual steps |
Transport files are stored in the transport directory which is often shared by several SAP landscapes.
Depending on the size of a customer’s system landscape and the amount of custom development, this directory and its sub directories can grow very fast. This can have a negative impact on the performance of the transport processes. Just deleting these files is not an option since they may still be needed for future imports. Audit regulations could also require these files to be kept for a defined period of time.
SAP provides built-in functionalities on an operating system level that support an administrator in identifying transport files that are not needed anymore for imports into other systems. The SAP kernel provides some OS commands that help administrators to reorganize the transport files:
|
OS Command |
Log File in usr/sap/trans/tmp |
Description |
|
tp check all |
check.log |
This command identifies all transport requests that are no longer marked for import into any of the systems (not waiting for an import in any import queue). These requests are written to check.log |
|
tp testold all |
testold.log |
This command simulates the results of the tp clearold all command (see next row) |
|
tp clearold all |
clearold.log |
Based on the list that is generated with the tp check all command and based on the corresponding TMS parameters (see next table), files are either deleted or, in the case of datafiles, moved to from usr/sap/trans/data to usr/sap/trans/olddata |
There are several TMS parameters that control which of the transport files are taken into account by the above tp commands:
|
TMS Parameter |
Default Value |
Description |
|
cofilelifetime |
365 |
Minimum age in days of a cofile before it is deleted by the combination of the commands tp check all and tp clearold all. Another prerequisite is that the corresponding transport request is not marked for import anymore for any of the systems. |
|
datalifetime |
200 |
Minimum age in days of a data file before it is moved to the olddata subdirectory by the combination of the commands tp check all and tp clearold all. Another prerequisite is that the corresponding transport request is no longer marked for import for any of the systems. |
|
loglifetime |
200 |
Minimum age in days of a log file before it is deleted by the combination of the commands tp check all and tp clearold all. Another prerequisite is that the corresponding transport request is no longer marked for import for any of the systems. |
|
olddatalifetime |
365 |
Minimum age in days of a data file before it is deleted from the olddata subdirectory by the combination of the commands tp check all and tp clearold all. Another prerequisite is that the corresponding transport request is no longer marked for import for any of the systems. |
Note: Depending on the specific regulations that need to be fulfilled, the SAP default values might be too low. It is strongly recommended to archive the transport files on a regular basis instead of deleting them completely. Use the result of the tp check all command to determine which files are ready for archiving.
Conclusion
A significant part of audit relevant changes is applied to a production system via transport requests. Fortunately, the SAP CTS provides the appropriate features to cover all aspects like traceability, monitoring and reporting. Customers must ensure that the relevant parameters are set correctly to activate these features. A permanent monitoring of these parameters is also recommended to prevent unwanted changes–by accident or on purpose.
Onapsis Assess supports Onapsis customers in automated checking for the correct values of the TMS parameters RECCLIENT, VERS_AT_IMP and currently working to cover VERS_AT_EXP. Learn more about the Onapsis Platform for SAP security and how we’re supporting SAP customers in monitoring all important aspects of SAP CTS settings.