SAP Cloud Security: A strong defense is the first step

Securing an SAP environment is critical to any organization and as the use of public clouds grows for these environments, so does the concern of SAP cloud security. 

These hyperscalers all have teams of people working around the clock to ensure their solutions are impenetrable. Third party cybersecurity solutions are often used as well to make sure these environments are safe and secure. A strong defense for your network or cloud environment is just the first step in properly keeping your SAP systems inaccessible to intruders.

Proper migration techniques for SAP cloud security

It’s important to note that many of the below security topics may be set and secure in your on premise environment. However, when the migration takes place, there are certain security aspects of the environment that need to be opened/unlocked/exposed to complete the migration. If you’re starting off with a greenfield or brand new installation into the cloud, it’s critical to understand these components as well. 

Most of these SAP technical security measures that happen beyond cybersecurity get exposed at the time of installation or during migration projects. As such, they can go unnoticed or forgotten until it’s too late. A good technical SAP audit should help in catching these exposures, but as we all know, waiting for an audit to tell you about your security vulnerabilities is not best practice in the first place.

Understanding SAP database security

The database is the heart of the SAP system. All data of the environment is held within those tables, along with all other system components. If the database is exposed, it’s exposed to those who know how to remove, alter or destroy it.

But what’s really interesting about SAP databases, is that there are very few database users required. Where a non SAP database may have hundreds of users with access, an SAP environment only has a handful of users, as the protocol is to keep extra access to the database on lockdown.

There is a primary database user that connects to the actual SAP application, plus only a few support users created for the technical support team. That’s it. No other users should be defined. Day to day users do not need to have access to the database. 

Security tip

If a random user is created at the database layer, all extreme measures should be put in place to notify, report and remediate that users. If an individual with malicious intent somehow makes it past any cloud security, cyber security and OS level security, make sure they are unable to get into the database. 

Exposure at the SAP application layer

Access to the database is not the only way to reach secure data. If proper security is set at the database layer, there are still ways to maneuver through the application layer to get to the data. Similar to the database layer, there are certain ways to keep the application layer locked down and secured should anyone penetrate past initial network and OS level security. 

Security tip

The application layer may need to be secured properly after your migration or installation into the public cloud.

Common SAP cloud security loopholes

The best practice is to verify your security prior to releasing to the business and monitor continuously. Here are the most common security loopholes.

Profile parameters:

Profile parameters within SAP are various settings that impact security, health, and performance. These can be modified at either the operating system or SAP application layer. There are various security settings within these parameters that can easily expose someone with a malicious intent to all data or the ability to execute in the system (think: creating payments to themselves, collecting personal data, creating sales orders, etc.) Changes to profile parameters should be monitored and watched 24/7 for any changes to settings that expose the environment.

Client settings:

Within the SAP system, there are various ‘clients’ that are, for simplicity sake, used to separate information. Ability to make changes in different systems, for example a production system, is locked down. Typically any changes need to be created in development, tested in a quality assurance environment and then finally moved into production. By locking down production systems to ensure changes cannot be made directly in production ensures the proper testing that could lead to exposure of the system. There are rare times that these settings need to be opened for a brief moment to make a quick change, but these client settings should be immediately locked back down. If forgotten, anyone with access to your cloud environment, who is aware of these opened client settings in a production system, could take full advantage of putting a change in place that could provide more access and would go completely unnoticed

Software components:

Each SAP system consists of various software components. Each of these components has its own support pack level, which are possibly open to different vulnerabilities. When it is found that one of these components at a specific patch level opens up a security concern, SAP immediately pushes out a ‘HotNews ‘ update to alert it’s customer base. This is not just limited to on premise environments, but also directly impacts systems running on the public clouds as well. There is a scale of 1-10, with 10 being the most critical of patching required, and it’s vital you have monitoring in place that identifies these important HotNews vulnerabilities and notifies you of which of your systems this particular HotNews is relevant for.

Kernels:

SAP also has its own kernel with it’s own patch level. Similar to the software components, security vulnerabilities are found for the kernels and immediately need to be patched. It is often mistaken that since your environment is in the public cloud, that the kernel will not be impacted, when in fact it definitely can be. It is best practice to not only have a mechanism in place to identify ‘out of date kernels’ but also to have a solution in place to manage automatic updates of those kernels in a quick and efficient manner.

Improve SAP cloud security

SAP security in the public cloud does not necessarily mean your system is exempt from vulnerabilities or attacks on your environment. The hyperscalers and third party solutions are always updating their toolsets to make sure systems are impenetrable.

It’s important not to rely on the hyperscalers and cybersecurity solutions to be the only stop gap for security threats. The SAP environment and database needs to be continuously monitored and updated, similar to how they would be managed on premise, and Avantra can help. Read about our SAP managed services. Feeling on edge about SAP solution security? Avantra next generation platform spots and resolves problems before they hit, so you can lean into a better business experience, safe in the knowledge that your SAP landscape is sound, steady and secure. See how.