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
- All the resources you provision within GCP are encapsulated in a specific structure. Resource Manager allows you to create a hierarchy of Organization, Folders and Projects that help you isolate single resources and limit access to unauthorized users.
- Google’s Identity and Access Management (IAM) adds another layer of security by allowing you to restrict the access and privileges to different projects or resources.
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!
- If you’re already using Active Directory (or other LDAP-based solution) in your company, you may want to keep using it instead of managing another one. Having a central user/privilege management systems helps to reduce human error and other mistakes that affect the rule of least privilege. Google has a tool called Google Cloud Directory Sync (GCDS) that let’s you synchronize all the AD data to Cloud Identity, Google’s tool for handling users in enterprise environments.
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.
- Each resource in GCP has an associated quota, which may be different for each customer. Quotas act like a circuit breaker if your Google account gets compromised or you have misconfigured automation tools for provisioning resources.
- Google provides you with default, not-modifiable Admin Activity Logs, which tell you who did what and when. Also, administrative actions triggered by Google support (eg. executed due to incidents you create) are stored by default. Both of those cannot be tempered with and are stored for 400 days.
- Also, you can turn on optional audit for the data being accessed (Data Access Logs) that store API calls that create, modify or read data. They are disabled by default.
- Physical security of Google data centers is just as important as protecting from all cyber attacks. If you’re interested to read about this multi-layer and multi-dimension system, this is a good place to start.
Compliance
- Google makes use of so-called Shared Responsibility Model. In a nutshell, it means that Google is responsible for the security OF the cloud, while you (as a customer) are responsible for the security IN the cloud. This way the overall responsibility is shared, which has big implications when planning your migration to public cloud.
- In IaaS and other model of utilizing GCP resources, Google is responsible for some bottom layers of IT infrastructure, which usually was handled by you with on-premise approach.
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.
- Hardware that is used in data centers is custom designed by Google.
- Only a handful of Google employees have access to actual data centers. Plus, biometrics, metal detection and laser-based intrusion detection systems all add next security layers to the stack.
- All inter-service communication is encrypted by default, plus services perform automatic mutual authentication.
- Bucket Locks help make you sure that data in GCS cannot be removed before your policy allows it to. It’s often used to satisfy compliance requirements.
- Additional information (besides username and password) is required from users when there are risk factors (logging from new device, different location etc) detected during login process. OAuth tokens are used to limit the need to provide user credentials during subsequent calls.
- Google regularly passes third-party verification for compliance with international standards and certificates like:
Network security
- When using GCP, you get firewall functionality by default, without provisioning any special resources to perform this task. Firewall Rules let you allow or deny traffic to and from VMs.
- Resources within a VPC network can communicate with each other using internal IPs, thus limiting the traffic that leaves the VPC.
- NAT gateway / Cloud NAT is a mechanism to securely reach external resources (like OS patches or Google’s monitoring agent) while still disallowing any access to a Virtual Machine from the outside world.
- Hybrid Connectivity is a set of options (Interconnect, peering, VPN) to securely connect your infrastructure (with special emphasis on on-premise) to Virtual Private Network. Depending on your choice, different features are used to make the connection as secure as possible. It ranges from encrypting the traffic (Cloud VPN) to using Googles’ fiber-network only, without traversing the Internet.
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.
- Premium networking tier (which is actually a default mode) is a feature that favors Google internal global network where possible. That means that your data (encrypted by default) does not traverse the Internet unless you request it to do so.
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.
- Shared VPCs is an interesting option to connect resources from multiple projects to a common VPC network. In a nutshell, you can improve security and standardize networking by allowing only selected employees (most probably: network admins) to manage network-related GCP resources in a single, so-called Host Project. Next, each of the other projects just uses network components from Host Project.
- VPC Flow logs are sampled network flows sent from / received by VMs. They are enabled/disabled per VPC Subnetwork and can be viewed by Stackdriver Logging.
- Because of huge Google’s network scale and additional mechanisms (such as Cloud Armor, Load Balancers or scalable VM groups) most of DoS attacks are just absorbed without visible effects to end customers.
Compute Engine
- Each of the Virtual Machines has it’s cryptographic signature to ensure it boots with the correct software
- There is a whole bunch of ways to securely connect to a Virtual Machine. To name just a few, you have firewalls, port forwarding over ssh, Bastion Hosts, NAT, VPN, serial console and proxy load balancers. Isn’t that impressive?
- Service Accounts, which are a special kind of accounts that are not associated with an individual or group, but – instead – are used only by your VMs to communicate and utilize various GCP services. It’s best to use your own, custom service accounts instead of default ones. This way, you can limit their privileges and access to selected Google APIs.
- Virtual Machines with no external IPs can utilize different APIs and services (eg. accessing Google Cloud Storage) when Private Google Access is enabled.
- Bastion hosts, also known as Jump Hosts, which are a special type of Virtual Machines that help you isolate internal traffic from external world. The idea is that internal VMs don’t have external IPs and – as such – cannot be accessed from the Internet. In order to reach them, you first need to login to a Bastion Host (using its external IP), which allows for further connections to your HANA and ABAP VMs based on Firewall Rules you define.
TIP: It’s a good practice to shut down Bastion Host when no ssh access is required to internal resources.
- You can enable or disable connections to Virtual Machines via serial console, which can be useful to securely connect to a faulty instance that has booting issues.
- Operating System image management was built with security in mind. The simple approach is: restrict usage to only approved images (Trusted Image GCP feature) and/or utilize Custom Images that are available to your project only.
- Updating and patching of your VMs can be automated via a pipeline and done at image level, which adds another layer of security, making sure OS is not tempered with.
- Google limits rate of requests that you can make to Compute Engine API. Limits are enforced per project and per different categories and they help to prevent from exhausting your resources, potentially after access to those was compromised.
Data
- Data is encrypted by design, both in place and in transit. Key Management Service is used to manage all the cryptographic keys for every service within GCP. It supports both symmetric and asymmetric keys (these however need to be managed manually).
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.
- Process of data encryption uses envelope encryption (data is encrypted with Data Encryption Key, which in turn is encrypted with another one, called Key Encryption Key). KEKs, a they’re called are stored in KMS, from where you cannot export them by design.
- Keys inside KMS service are rotated automatically every 90 days, but you can do it manually at will if you choose to.
- Data encrypted by KMS is not stored in KMS itself! KMS is only used to store encryption keys. It decouples locations of data and keys, which adds another security layer to the mechanism.
- Access to KMS keys is audited by Cloud Audit Logging. You always know who did what!
- There is a separate mechanism to handle permissions to KMS, called ACLs (Access Control Lists). They work on per-key basis.
- Alternatively to KMS, you can use Cloud HSM (Hardware Security Module) to manage cryptographic keys. Cloud HSM is fully integrated with KMS.
- You can additionally encrypt the data yourself, before it even touches the cloud!
- Data Custodian is a great governance, risk and compliance tool that helps you visualize how and where your data in the cloud was accessed.
- Google Cloud Storage. This is where you store backups, installation media and other more or less sensitive data. TLS (link) is used when data is in transit to to Google Cloud Storage. Plus, data at rest is encrypted by default, no matter if you push it manually, via a synchronization mechanism like rsync (eg. to migrate filesystem-based backups to GCS) or by a separate tools (eg. backint client for HANA backups that can be directly done to a GCS bucket).
- If you decide to share some data located in Google Cloud Storage with someone from outside of your organization, Google helps you to secure this content by usage of so called “Signed URLs“. It allows you to limit time of content availability, so even if it’s shared more openly than you wish for, access to the source is locked after specified time.
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!
- Bucket Lock is a feature of Google Cloud Storage used for compliance reasons. It allows you to configure data retention policy for a bucket to govern how long objects must be retained. You can lock data retention policy, thus permanently preventing the policy from being reduced or removed. In other words, you can ensure your data is not removed too early.
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:
- Key Management Service can be utilized to encrypt secrets that reside somewhere in GCP. With KMS, you can take over management of keys and keep then away from anyone, including Google.
- Keys that you manage and secrets you store can be rotated regularly.
- You should use IAM to limit access to secrets.
- Another way to protect your secrets is usage of separate projects for KMS and secrets themselves.
- You can place each secret (or groups of secrets) in its own GCS bucket.
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?