Audit finding: productive system is modifiable!
It is a standard check done by many auditors to have a look into the system change options. And even if the admins did not open the system changeability or any component, sometimes there is at least one component open for modifications! How could this happen?
The reason for this often is in implementing a new component with the SAINT transaction, which leaves the freshly installed component with status 'modifiable'. Also a 3rd party transport request (or from SAP) could cause this situation.
This likely becomes a finding.
This finding can be easily avoided by implementing an automatic closing of the global setting, the components and the namespaces.
Unfortunately there is no SAP standard program available that can be scheduled daily. In that cases, this is where usually the idea comes into play of developing an ABAP program for this purpose, distributing it to all systems and scheduling it as a periodic batch job in all productive systems.
It can be shorter, faster and consequently cheaper. "Shortcut for SAP systems" comes with a 'Update table data' function, and with the command line tool we can automate it.
First let's have a look at the SAP function for setting the system changeability (SE03) and determine which tables are to be updated:
These are the tables behind the 3 categories of the system changeability:
The changeability of the "Global Setting" (1) is stored in a single TADIR table entry:
The changeability of the Software Components (2) is stored in the table DLV_SYSTC:
And finally the changeability of the namespaces is stored in table TRNSPACE:
As usually for this kind of tasks, the command line tool of "Shortcut for SAP systems" is useful. It runs outside the GUI application on OS level. This gives us the possibility to execute it periodically via an automation solution. This can be a simple (and free) solution like the Windows Task Scheduler or a more sophisticated (and more expensive) product like Automic Automation or others.
There are 2 options to use the command line tool:
- using a Variant (a Variant in "Shortcut for SAP systems")
- using an XML file
As it is here about an update of 3 tables, the 2nd option - using an XML file - is more suitable. The 1st option would require 3 variants and 3 single calls of the command line tool. With the XML file we can use a single XML file with 3 update tasks and a single call of the command line tool.
An XML file for updating the table entries would look like this:
For each of the settings (Global Setting, Software components, Namespaces) we update the records in case they do not already have the right setting (that is where the <WhereCond> tag is specified for).
In front of scheduling this periodically we call it directly on the console:
A verification in the system (SE03) showed that it worked as intended. In case the settings are already correct, the return code would be 4 - a warning, because the update did not apply on any record.
Now let's implement this in a periodic task. For this have a look into this article (which is about a very similar issue).
With the implementation of a periodic run you can be sure, that system changeability in next year's auditing will not be an issue anymore. We did not have to develop an ABAP program and distribute it into every system line, followed by a job scheduling. Adding a new system for this task is quite simple via copying the lines and just use another connection for the copied lines.
Es gibt noch keine Rezension.