Implementation of your user and security management
SAP Remote Managed Services
The security of an SAP system requires protection against unauthorised access, e.g. through the secinfo and reginfo files. A cleanly implemented authorisation concept protects against attacks within the SAP system. However, it is also possible to attack your SAP system via the network. Through the RFC Gateway Server, your system communicates with external servers and programmes. One particularly effective way to protect against this are so-called Access Control Lists (ACL). Find out what this is and how you can use it to better protect your SAP system. The SAP Standard offers different approaches for gate protection. All methods combined can provide even greater safety. For example, it is possible to use Access Control Lists (ACL) to monitor exactly which external programmes and which hosts can communicate with the gateway. Another option is to configure the gateway to support Secure Network Communication (SNC). Finally, there are various security parameters for the gateway. This article focuses on the use of ACL files such as secinfo and reginfo files. What is an ACL? Access control lists are files in which permitted or prohibited communication partners can be recorded. For the gateway to use these ACL files, parameters must be set in the default profile of the SAP system and of course the files must be maintained accordingly. With the help of logs and traces, which can be configured for this purpose, a precise investigation can be made in advance of the activation, which connections currently run via the gateway. This allows them to prevent important applications with which your system communicates from being blocked by the ACL files. The rules in the ACL files are read from top to bottom of the gateway to decide whether to allow a communication request. If none of the rules matches the requesting programme, it will be blocked. Network-based ACL The network-based ACL file contains permitted and prohibited subnets or specific clients.
SAP's client concept enables a SAP system to be split into several logical sub-systems - clients. These subsystems can be used independently and in isolation as separate systems. But how should non-client transactions be treated? How can you prevent one client from accessing the other and why should you want to prevent that? In this blog post, I will answer these questions and discuss some negative examples. Why is it important to consider independent transactions separately? Imagine that every one of your employees is allowed to create or change a client in the production system, or worse, both. Creating and modifying a client in the production system is authorised and documented - you wonder what could possibly go wrong? The risk in this case is a loss of integrity of system and data, loss of confidentiality: With each new client, Superuser SAP* lives up to its comprehensive, cross-client rights and the assigned standard password.
Implementation and operation
Following the recommendation of dividing the SAP basis into an application-orientated and infrastructure-related SAP basis [A4], Figure 3 shows a possible presentation form. The SAP-Basis interface function is structured into a SAP basis, which is close to the application and is responsible for coordination and communication with vertical and higher IT specialist and business areas, and a SAP basis close to the infrastructure. The infrastructure-related SAP basis in turn serves as the link between the application-orientated SAP basis and the infrastructure levels. Subject Matter Experts will perform the link task again. In the application-orientated SAP basis, in turn, technology architects are more likely to be placed. The innovation activity or innovation team aspect of the SAP basis is placed at the level of the SAP basis, which is close to the application, because the existing capabilities allow it to assume a leading, also coordinating role and acquire expertise both by adding the SAP basis near the infrastructure and the downstream IT departments. Figure 3: SAP basis as a cross-sectional function SAP basis (near application) SAP basis (near infrastructure) SAP basis (innovation / test laboratory) Application development Databases Virtualisation ....
Basis comprises a number of middleware programs and tools from SAP. Basis is responsible for the smooth operation of the SAP Basis system and thus for R/3 and SAP ERP, for example. SAP thus provides the underlying basis (hence the name) that enables various SAP applications to be interoperable and portable across operating systems and databases.
"Shortcut for SAP Systems" makes many tasks in the area of the SAP basis much easier.
The print jobs are multi-tenant, which means that the authorisation award should also be well thought through at the point.
Some useful tips about SAP basis can be found on www.sap-corner.de.
In particular, the implementation, set-up and configuration of the systems and security concepts must be harmonised or returned to the SAP standard.