Security and Compliance Blogs
Security & compliance of business operations are critical in this age of rising cyber threats, increasing compliance regulations, and rapid technological change. SAP customers, partners and SAP employees put great effort in to meet those risks and work towards effective security outcomes and cyber resilient systems. We benefit from each others' challenges and successes to protect the business processes and services we all depend on. Join us here for blog posts and thought leadership regarding the security and compliance of SAP software and cloud services, as well as secure development, deployment, and operational practices, whether on-premise or cloud.
cancel
Showing results for 
Search instead for 
Did you mean: 
JayThvV
Product and Topic Expert
Product and Topic Expert
1,313

cloud-someone-elses-computer-title.png

By Jay Thoden van Velzen, Technical Advisor, Office of the CSO

People say that “cloud is just someone else’s computer”. That obscures significant differences between data centers and enterprise IT on one side, and cloud services on the other. Security professionals must be aware of those differences, as you can only secure what you understand. Even when lifting-and-shifting environments, the changes are profound. In pure Software-as-a-Service (SaaS) models, security controls and processes are often completely different, following a different logic than in data centers.

I often have the privilege of engaging with sophisticated customer cybersecurity teams. These are seasoned professionals, running mature cybersecurity programs, many of them in regulated industries. It is always a delight to learn from each other. However, their organizations have sometimes been cautious in moving to the cloud and their security teams may not have had much prior exposure. That can lead to surprises when we answer their questions.

Undoubtedly, moving to the cloud adds new security risks. However, it also helps security professionals address old security risks easier than we were used to. It also changes the area of greatest risk. This blog aims to build a bridge for security professionals from the data center to the cloud, so we can get on common ground for deeper discussions.

 

Beyond the Shared Responsibility Model

The respective responsibilities for security in the cloud between cloud service providers and their customers are outlined in the Shared Responsibility Model. SAP’s three-party Shared Responsibility model is described in the Securing SAP Cloud Environments white paper on SAP Trust Center. To fully understand the implications of the model, we must go beyond separation of responsibilities, though. The cloud is more than a data center managed by someone else. It is a different paradigm of computing.  

For instance, a very common customer question is whether our hyperscaler partners can access their data. The idea behind it is that if the cloud provider runs the infrastructure that it will have access to encryption keys. A customer asked me once whether a hyperscaler had a separate room with operators dedicated to managing SAP keys.

Hyperscalers work hard to design their systems so they don’t have access to customers’ landscapes. In this article, for instance, we describe how the design of the AWS Nitro system and the way encryption keys work keep AWS operators from accessing customer data. Similarly, SAP strives to keep SAP operators from accessing customer systems as much as possible. Ideally, customers manage their own keys.

The way the cloud works makes such separation of responsibilities and isolation by privacy boundaries possible.

 

Scale and Velocity

The scale of SAP’s cloud operations is hard to comprehend. Tens of millions of cloud assets run across over 20,000 public cloud accounts and SAP-managed data centers. Much of the landscape uses autoscaling for virtual servers or container-based workloads, creating velocity in the landscape. Teams can deploy and redeploy resources at will, adding to the constant rate of change. SAP cycles through 10,000s of virtual machines daily.

That makes the lifespan of a server much shorter than in data centers. Autoscaling landscapes renew themselves continuously from images stored in image registries, by launching new resources based on demand and deleting them when the load no longer requires it. For container-based workloads this can be seconds. Persistence for adversaries is therefore more complex than in data centers where servers may have a lifetime of months and years.

 

Everything Is a Service

The most difficult and abstract part of infrastructure-as-a-service (IaaS) in cloud landscapes is that everything is a service, exposed through an API. What used to be connected through cables is now a series of API calls to services requiring authentication.

A physical server has a motherboard with a CPU installed, as well as memory modules. The motherboard is connected to storage drives. Over the network, it connects to domain controllers or identity providers to provide access to other available resources.

Cloud solutions operate almost exclusively through authenticated API calls over HTTPS. For Software-as-a-Service solutions, that includes customer end user activity via the UI, service accounts or automation within the context of the application. This is similar to running web applications within your data centers.

But orchestration and operation of the system infrastructure of network, compute and storage service configurations in the cloud is done via the hyperscaler API. Instructions sent to this API tell the hyperscaler cloud orchestration services to create or modify a landscape's configuration, based on server images contained in a registry service and deployment scripts. None of those cloud API calls require network access to the solution infrastructure resources directly.

cloud-orchestration.png

For SAP cloud solutions, the orchestration and management of cloud infrastructure through the cloud API is performed by SAP, so is not visible to customers. However, it does determine the logic behind why SAP cloud solutions operate the way they do.

 

From Primacy of Network to Primacy of IAM

Network security is still important. But it is very different from large corporate networks with subnets, proxies, VPNs and gateways that may provide access to any resources in the landscape over a variety of network ports. In data centers, users can access the solution over one network port, whereas system administrators and management solutions connect to the same infrastructure resources over another. In cloud landscapes, the user network traffic and infrastructure management are separate.

Each cloud account is its own separate, isolated data center island, with no network path to resources deployed in another. Virtual Private Clouds (VPCs) within cloud accounts provide a further level of network isolation. Cloud resources can be grouped in a VPC to keep them separate from other VPCs in the same account. SAP also has controls in place that block common admin ports from being publicly exposed, and landscapes typically only expose a web and API interface over HTTPS.

The cloud, therefore, provides a high degree of network segmentation and isolation. Instead, identify and access management (IAM) for human administrators and non-human service accounts plays a large role. Every API call requires an identity with the correct authorizations, and resources can only be called on when the user- or service accounts has the appropriate role to do so. Access to encrypted data storage requires access to the encryption key as well as the storage object, for instance.

Machine identities combined with secrets management allow workloads to be configured with only the privileges they need for operation. Meanwhile, all human administrators of SAP’s cloud landscapes are required to use Multi Factor Authentication (MFA) for privileged access.

We can contrast the approach of establishing persistence and subsequent lateral movement by adversaries in data centers with cloud landscapes. In data centers, they gain a foothold on an initial host, followed by movement progressively over the network to other resources. In public cloud, adversaries may instead gain access to credentials and create new malicious virtual machines or containers. Then from these they move laterally through the cloud control plane to other resources via the cloud or Kubernetes API.

 

Different Cloud Deployment Models

SAP provides cloud solutions in different deployment models. These are:

  • RISE with SAP Private Edition
  • SaaS Single Tenant
  • SaaS Multi Tenant

The diagram below illustrates the differences. In RISE, each customer gets their own unique system – of its own version and patch level – with its own separate database in an SAP-provisioned network, with their own machine identities, isolated from other customers. This is closest to data center scenarios, but with infrastructure and systems managed by SAP.

In SaaS Single Tenant deployments, each customer still gets its own landscape isolated from others, but the network configuration and solution versions are the same across instances. Updates are rolled out to all customer instances. This allows such instances to always be on the latest version of the solution.

In SaaS Multi Tenant deployments, customers share the solution infrastructure, and isolation is through separate database partitions. Since there is only one system (using many compute resources deployed globally) shared by everybody, any updates to the system apply immediately for everyone.

rise-single-multi-saas.png

These different deployment models also come with different degrees of options customers can choose. In RISE, customers can add several optional services to their environment based on their requirements. In SaaS Single Tenant, the options are largely reduced to additional resiliency (disaster recovery and high availability). In Multi Tenant SaaS, the choice is further reduced.

The Business Transformation Platform (BTP) has both single tenant components within the context of a BTP provider account to keep applications and data private, but also exposes multitenant PaaS services, such as the AI Foundation services.

 

Automation and Verification

The cloud is designed for automation, and at SAP’s scale is a necessity. Since management of resources, configurations, identities and secrets are all API calls, they can be expressed as code. This is called Infrastructure as Code (IaC) and just like any other code are subject to SAP’s SDOL product security standards, policies and hardening procedures. Like other code, it is included into code branches and pull request processes.

These processes are supported by Continuous Integration/Continuous Delivery (CI/CD) pipelines, so that landscapes get built, code scanned, and deployment tested as part of the pull request process. Such build and deployment checks ensure only commits that pass are included in the development branch for a subsequent version release.

CI/CD pipelines build VM and container images that are stored in image registries. CI/CD automation then deploys new releases across the landscape. Automation ensures that what passed all prior tests is what is deployed.

SAP cloud accounts are further protected by cloud guardrails, which change the default behavior of these accounts and enforce baseline security controls. Having placed these cloud accounts in SAP organizations or tenants, we can apply these policies across the public cloud landscape centrally. When developers try to deploy resources that violate those guardrails, these resources configurations are blocked or auto remediated.

The same organizational structure allowed SAP to centrally deploy an agent-less Cloud Native Application Protection Platform (CNAPP). This gives broad visibility across the public cloud landscape only by making cloud API calls. Other security tooling may require the collaboration of developer teams but is still deployed through IaC automation.

More automation takes the results of landscape scans and runs them through a data enrichment pipeline for distribution to responsible teams and support internal reporting and governance processes. Remediation of findings by the teams follows the secure development processes.

This automation and verification also explain the degree of choice discussed earlier with regard to cloud deployment models. Variation and customization break CI/CD and scan automation.

 

Running on Someone Else’s Service

The cloud is more accurately described as running on someone else’s service. That makes it clear that the cloud is a collection of APIs, where the computer is abstracted away into different services configured together. “Computer” conjures up the mental model of networked servers. Services are authenticated API calls acting on your behalf.

How to best secure these services is an ongoing debate among cloud security practitioners in a cycle of continuous innovation, improvement and exchange of experience and practice. Let’s focus here, instead of trying to address the security risks of the new with the approaches of the old.

 

More information