SAP on Google Cloud Platform

Security in Google Cloud Platform.

Security is one of the biggest concerns that hold companies from migrating to the cloud. That’s understandable, especially if we’re talking about mission critical, backend systems that contain a lot of sensitive data. SAP systems definitely fall into this category, so you need to be absolutely confident that your data is cyberthreat-safe before migrating your systems. In fact, security is often the number one determining factor when choosing the target location to migrate your SAP workloads before 2025, which is a magical year for anyone in SAP area.

Google proved multiple times in the recent years that security is its’ absolute priority. In fact, no changes are made nor services or tools released without throughout understanding how this affects overall security of Google Cloud Platform.

Below are some of GCP rules and features that contribute to Google cloud being a suitable location for your SAP environments from security perspective:

General security

TIP: In the end, you’re the one responsible for implementing the rule of the least privilege. Google offers the solution, but the design and execution needs to be done by you!

TIP: Be careful about using additional GCP services to enhance SAP functionalities. They often work in a distributed manner, where data is separated from processing nodes and you might have a limited governance as to where the data is located or how it’s transferred between storage and processing parts.


TIP: There is no single rule here as you may simultaneously use different services from different classes (IaaS, PaaS, SaaS). With each of those services, the border between your and Google’s responsibility may be elsewhere.

Network security

Click here for Cloud NAT deep dive.

TIP: Bear in mind that with Interconnect options, traffic is NOT encrypted. It never leaves Googles’ network, but it’s still a good practice to use a third-party solution to encrypt the flow.

TIP: It’a a good practice to separate resources that don’t need to communicate with each other. You can do it on different levels (VPC, project,…) to protect your resources even if some part of your infrastructure would be compromised.

Compute Engine

TIP: It’s a good practice to shut down Bastion Host when no ssh access is required to internal resources.


TIP: It’s a good practice to put KMS in a separate project and ensure that no single user has all the permissions to execute a malicious action. It helps to enforce Separation of Duties and restrict access to your keys.

Multiple layers of cryptographic key management system. For more details, click here.

TIP: remember that if someone decides to download the content locally and share it with others using other methods than GCS Signed URL, you cannot really prevent it. Share your data with care!

Finally, what about HANA database ifself? Isn’t your HANA database vulnerable to some kinds of attacks? And when exactly it’s located?

HANA runs on a Compute Engine and utilizes Persistence Disks, Google Cloud Storage and Networking, so all security aspects to all of those components mentioned above are fulfilled. But it’s no different than with other applications: part of the responsibility is on your side and Google only delivers building blocks to support you. HANA VMs should have no external IPs, NAT should be set up to fetch OS patches and Bastion Host concept should be always in place. What’s more, you should secure HANA hosts from the network perspective so that only application servers can access it using SAP-specific ports. IAM can be utilized to limit access, custom Service Accounts can be used to run the machines, plus you are free to manage cryptographic keys that encrypt the data by yourself.

TIP: As a reminder, there is a ton of methods supported directly from SAP to make sure your data is secure both in place and in transit (even between HANA and application instances). They can be combined with GCP solutions to best fit your needs. HANA itself has multiple security mechanisms to protect access to your data. For details, see SAP HANA Security Guide.

As you can see, there is nothing extraordinary with HANA boxes, just common sense. Also, it’s you who decides where your database is physically located at. Usually, SAP landscape is limited to one particular region (which always means few datacenters in one country). By deciding where to put you HANA instance(s), their Persistent Disks and SAP application servers, you decide about the physical location of your data.

TIP: Plan HANA Distaster Recovery carefully. You may want to locate DR servers in different regions than your current environment, which means your data may also exists in a different country. Make sure you have no formal constraints in this area!

Secrets Management

Secret is a broad definition of any objects that should be secured from unauthorized access. There are a number of ways you can achieve this goal:

Wow. To be honest, I did not expect this article to be so extensive. But that only showed me how many security-related pieces of technology are being used by Google to protect you and your data from all cyber-security threads. What’s even more impressive, this was not a complete list by all means; I filtered only those features that are related to GCP resources that are usually used by SAP. There is a whole bunch of other mechanisms (such as Cloud Armor, IAP or DLP) which are applicable especially when your applications are facing the Internet. Not to mention, there are a lot of third-party partner security products (eg. Forseti, HashiCorp, Cisco, Palo Alto etc) for different use-cases.

The bottom line is: Google treats security really seriously. It’s at a core of GCP infrastructure and no decision is made without throughout analysis from security perspective. Failing to comply with various legal regulations would mean that the customers just wouldn’t have enough trust to move their systems to GCP. After all, trust is everything in today’s world, isn’t it?

Exit mobile version