insiderBOOKS Articles and Insights

Security / Cloud


Chapter 6 Excerpt – SAP in the Cloud: Security Essentials

The previous chapters discussed how cloud providers can prevent an attacker from accessing your data. But what happens if an attacker does gain access? Does this mean it’s game over, data’s stolen, start running damage control? Not necessarily. This is where encryption can help you . . .

Encryption Within SAP

The SAP family of products includes some default encryption. In a software package that handles business-critical information across multiple verticals, encryption is a must. SAP recognized that and built in standard cryptographic measures for both at-rest and in-transit data. Many customers find that these measures provide enough security for their cloud environments; others may want to implement additional controls.  Refer to the security manual for your specific SAP product for more details. Encryption security in SAP operates the same in the cloud and on premise. 

While many of the SAP technology platforms support encryption, you’ll probably centralize it through SAP HANA. Information about encryption for SAP HANA comes from The SAP HANA Security Guide, currently available at Other products, such as SAP NetWeaver and SAP ERP, have built in encryption, but SAP HANA provides the most thorough controls.

While SAP HANA uses an in-memory database, it still saves some of that data to a persistent storage area on disk. SAP HANA can automatically encrypt that stored data using the AES-256-CBC algorithm. That means it uses AES encryption algorithms—which we discussed earlier in this chapter—with a 256-bit key in cipher block chaining (CBC) mode. All pages written to the disk area will be encrypted, then transparently decrypted when loaded back into memory. The keys used only remain valid for a certain number of savepoints, then are automatically changed. The in-memory database portion will not be encrypted to maintain smooth performance.

In addition to the persistent storage area, SAP HANA maintains redo logs that track and record any database changes. These logs can also be automatically encrypted with the AES-256-CBC algorithm. You should protect these logs as much as your data storage; they contain a repeatable list of every action taken to affect the SAP HANA database so that, in the event of a sudden system crash, unsaved changes can be reapplied without data losses. That means an attacker could reassemble some of the database from these logs.

Each of these encryption mechanisms uses a different root key, so that an attacker with one key cannot reconstruct your entire database. These keys are held in the instance secure store in the file system (SSFS), which is in turn encrypted using the instance SSFS master key. These root keys can be changed at any time using an SQL call. For data in transit, SAP HANA supports the following protocols:

  • HTTP-based clients use TLS/SSL as protection
  • RFC connections can be protected using SNC
  • Simple Object Access Protocol (SOAP) connections are protected with web services security

To enable this, you’ll need to have the SAP Cryptographic Library CommonCryptoLib on the server. Both this library and OpenSSL are installed by default, but SAP recommends that you migrate to CommonCryptoLib. See SAP Note 2093286 for more information.

Note: We strongly recommend using secure protocols such as TLS or SNC whenever possible. For more information on enabling the protocols above, see the respective chapters in the SAP NetWeaver Security Guide.

You’ll also need to get a certificate for each virtual machine (VM) that will use TLS to transport secure data. If you’ll remember from earlier in this chapter, TLS uses an asymmetric key based on a certificate stored on the server. If your SAP system is divided into individual VMs for the client, application, and database servers, then each one needs its own certificate. And if your development life cycle includes multiple SAP environments—development, test, and production—then you may need sets of certificates for those if they have TLS enabled.

Once you have all of these certificates, you need to create a certificate collection in the database that contains your server’s public and private keys, as well as the public keys of the servers that you want it to communicate with securely. These keys will then be stored in the public key infrastructure (PKI) SSFS, which will be encrypted using the PKI SSFS master key.

All these keys, the root and master keys, are generated automatically when your SAP system is first installed. Like any other encryption key, you need to manage their life cycles and expire them on a regular basis according to your key management policies.

If your SAP system was pre-installed and configured by a third party, you might want to change those keys once you take over the system. The less opportunity for exposure your keys have, the better. Always back up keys when you generate a new one. If you lose your key, your data will become unreadable.

Note: Please note that keys change on reinstallation as well. If you or your provider need to reinstall your SAP system, back up old keys to prevent being locked out.

Passwords on the servers are stored securely using the standard SHA-256 algorithm, and are both hashed and salted. This is pretty standard operating procedure for password-protected servers. An internal application encryption service stores any credentials needed for outgoing connections, from things like smart data sources or HTTP destination calls from SAP HANA Extended Application Services (XS) classic applications.

On the client side, your trusted connection information is stored in the hdbuserstore. This is a securely encrypted tool that allows client applications, usually custom scripts, to connect to SAP HANA without forcing the user to manually enter password information. But you need to change the default key immediately; some versions of SAP, like ABAP, use a default key for all installations. If an attacker knows the key— say, because they read the manual—they can get access to all your log-on information.

Not everything is available to be encrypted. SAP products do not encrypt backups and database traces, as well as some log files. You can apply encryption to these files using other programs, but SAP will not do that for you.

To continue reading, please visit the full publication SAP in the Cloud: Security Essentials

Popular Chapters

View More
  • Chapter 7: Phase Four: Transition

    In the final phase, transition, we go through what you can expect at go-live, followed by lengthy discussions regarding service level agreements, operations process training, and transition to cloud operations. We talk about intricacies of system stabilization and monitoring. Finally, we explore the options for business continuity and security

    Read More
  • Chapter 6: Phase Three: Build

    In the third phase, build, we walk through developing proofs of concept for your project. The chapter discusses how to take advantage of a provision-shared infrastructure, as well as strategies for building and testing that infrastructure. There is an examination on how to build and mitigate databases and applications, as well as planning the phase cutover. It also looks at automated provisioning and automated services.

    Read More
  • Chapter 5: Phase Two: Model

    The second phase of moving SAP to the cloud, model, contains an overview of the second half of onboarding to the cloud. It examples infrastructure requirements and design and walks the reader through the process of developing a workload analysis. The chapter discusses application and business process discovery as well as operational run books and migration strategy.

    Read More
View More