Please refer to the
Use of external security tools
Security in the sense of data protection is gaining more and more importance with SAP R/3 customers. SAP wants to support strong security mechanisms to protect the interests of the user, but has decided not to include cryptographic modules in its own software. Instead, external products can be integrated which have been developed by security professionals.
Secure Store & Forward Mechanisms (SSF) provides the required support to protect R/3 data and documents as independent data units. This is done via:
The standard used for these secure data formats is PKCS#7. When applying these secure formats, the authenticated data is placed in an envelope (security wrapper) before the data is stored or transmitted.
For today’s business application software, it is increasingly important to support electronic authentication mechanisms and secure electronic transactions over public data communication networks. In the course of such electronic transactions, business data, such as electronic payments, or order and account information, leaves the secured realm of an R/3 System to be transmitted over insecure networks or to be stored on data carriers or archives.
The security requirements in the context of electronic business transactions are inherently different from the requirements for securing online communication between system components. The transmission of business data is done by computer systems and software processes, but the actual business transactions are carried out between persons or other subjects with a legal meaning. Therefore, additional security mechanisms at "application level" are required.
The support provided by "Secure Store & Forward (SSF)" enables the protection of R/3 data and documents when saved on external data carriers and when transmitted over possibly insecure communication paths, such as the Internet. To facilitate this, digital signatures and encryption are utilized at the application level. In the process, the data is secured as independent data units, regardless of the type of its contents, and regardless of the selected transport procedure. The protection mechanisms provided with SSF are applied outside the context of an existing online connection.
With the SSF functions, R/3 data and documents are "wrapped" in secure formats - the so-called "security wrapper" - before they are saved on data carriers or transmitted via insecure communication links. A digital signature ensures that the data is not falsified, that the sender (signatory) can be clearly determined, and that proof of award of contract exists. The subsequently assigned digital envelope ensures that the contents of the data are only visible to the intended recipient(s). As a result, no security gaps arise, even if the data is temporarily stored during transport or at its destination.
To construct a digital signature for a given document or message, a hash function is applied, which delivers a so-called "message digest". The "message digest" represents an unambiguous fingerprint for the message, but is usually much shorter. If a cryptographic hash function is used, it should be impossible to compute another meaningful input message which will produce the same digest. The message digest is then transformed into a signed message digest using the signer’s private key. Anybody who has access to the corresponding public key of the signer can reverse the transformation and retrieve the message digest from the signed message digest. To verify the authenticity of the signature, and the integrity of the data, the same hash function is applied to the data and the result is compared with the message digest.
To wrap a document or message to be protected in a digital envelope, the message is first encrypted, so that only the intended recipient(s) are able to decrypt the message. Typically, the data is DES encrypted using a newly generated DES key (message key). Then, the message key is encrypted using the recipient’s public key. Only the owner of the corresponding private key, i.e., the intended recipient, is able to decrypt the message key and then to decrypt the data contained in the digital envelope.
Protecting R/3 data and documents with SSF fulfills the
following basic security requirements:
In addition, the following SSF properties are also extremely relevant for electronic transactions:
These properties are retained even after the data transmission is complete, as long as the data is saved in the secure format.
SNC support state-of-the-art authentication, data integrity, and confidentiality services for the R/3 System by integrating an external security product via welldefined application programming interfaces.
With SNC, protection of the communication links between the distributed components of an R/3 System is achieved. In addition, SNC enables the use of cryptographic mechanisms and smartcards to securely authenticate users.
Several advantages for the customer offered by SNC are:
The frontend SAP Graphical User Interface (SAPgui) is traditionally used to access the R/3 System from or across "open" TCP/IP networks where physical security of the data transmitted over the wire is impossible to maintain. Using the SNC interface, the user can integrate the features of an external security tool with his R/3 System.
SNC provides network communication security between the R/3 clients and application servers. The SNC-protected clients and application servers can exist in either a LAN or WAN, but to provide a higher level of security, the application servers and database servers should exist in a single secured LAN.
Both SSF and SNC make use of external security products to improve the security of R/3. SSF implements the PKCS#7 standard. SNC products which adhere to the GSS-API Version 2 Standard. With 4.0A, SECUDE is the only product that is commercially available to SAP customers.
Please refer to the installation guide.
Please refer to the implementation guide
Maintenance for external security systems.