Very good IT skills - especially SAP solutions
SAP Basis in the overall system
In order to guarantee an optimal operation process a permanent operation is recommended. We are ready to take over the monitoring including on-call service for you at any time.
Parameters in the SAP create a high degree of flexibility. Profiles can be used to configure the system for almost any purpose. But with such a large number of parameters one quickly loses an overview of the influence of each parameter. For storage management alone, there are 20 different parameters that can be changed at different points in the SAP system. This article brings order to the mess and explains the most important parameters. There are three types of memory in the SAP system for a work process: ・ Roll Area - Local Memory Area for a Work Process ・ Extended Memory - Global Memory Area for All Work Processes ・ Private Storage /Dynamic Memory (Private Memory/Heap Memory) - Private Memory Overview of SAP System Memory Regions Parameters for the Rolling Range When a user starts a programme, a role area is created for that programme instance through a workprocess. The user context is stored in this memory area. The size of the roll area for a work process is determined by the ztta/roll_first parameter. If the storage area is not sufficient, a portion of the Advanced Memory will be allocated for the user context, the size of which will be determined by ztta/roll_extension, ztta/roll_extension_dia, and ztta/roll_extension_nondia. The latter two override ztta/roll_extension if used and offer the possibility to set different quotas for dialogue and non-dialogue work processes.
Implementation of security updates, patches and enhancement packages
For example, many customer ABAP programs work by uploading or downloading data. There are potentially large security gaps here that allow access to server data. In addition, the widespread direct invocation of operating system commands that are not covered by a self-programmed authorization check is a major problem. Even though classic SQL injection, i.e., the entry of extended SQL commands, is a potential security vulnerability, it occurs rather rarely in SAP systems. More widespread is the unintentional dynamization of SQL calls because input parameters are not sufficiently checked. The need to check all in-house developments internally for such security vulnerabilities before they are delivered in SAP's own code has led to the development of the SAP Code Vulnerability Analyzer tool.
An important area of SAP Security is the analysis of the customer's own SAP programs, which are classically written in the proprietary SAP language ABAP. Here, too, as in all programming languages, security vulnerabilities can be programmed - whether consciously or unconsciously. However, the patterns of security vulnerabilities in ABAP code differ from those in Java stacks or Windows programs. The goal of these conventional programs is usually to either crash the program (buffer overflow) or to artificially execute the program's own code (code injection). Both is not possible in ABAP, since a crash of a process causes nothing else than the creation of an entry in the log database (Dump ST22) and a subsequent termination of the report with return to the menu starting point. So a direct manipulation as in other high level languages or servers is not possible. However, there are other manipulation possibilities.
"Shortcut for SAP Systems" makes many tasks in the area of the SAP basis much easier.
Some useful tips about SAP basis can be found on www.sap-corner.de.
Innovation without IT is unimaginable.
Although you always make sure that authorization roles are generated when administering them, it happens again and again that there are red lights in the user assignment in the production systems.