Cloud security guidance
Pages
Page 6 of 29
Technically enforced separation in the cloud
The practical goals behind separating shared cloud resources.
The public cloud can be thought of as rentable computing power. You pay for what you need, when you need it, and for someone else to take care of all the maintenance.
To make this economically viable, cloud providers do not usually provide each customer with dedicated compute resources. Instead, resources such as compute power, networks, storage, and identity management are shared between multiple clients.
In this scenario, the separation implemented within each of those shared resources will affect the security of your deployed workloads and data. This makes it imperative that you choose a cloud service provider whose separation techniques match your security needs.
The next section looks at the practical goals which separation should achieve.
Note:
Separation techniques are only effective when the underlying technical mechanisms have been designed and implemented robustly. This relies on the components described in this guidance being developed according to the secure development practices described in Principle 7: Secure development.
The practical objectives of separation
Security-enforcing separation in the cloud has three main roles:
- defending against direct attacks from an external attacker, such as malicious use of an internet-connected API, or an attack from a malicious customer of the cloud service
- defending against lateral movement by an internal attacker, such as stopping the compromise of one of your services from affecting your other services, as described in our Preventing Lateral Movement guidance
- enforcing correct behaviour in the absence of an attack, such as ensuring someone is only able to access the resources that they have been authorised to use
Judging the effectiveness of separation
A more robust separation mechanism is one that makes it harder for an attacker to access something that they should not be able to. The degree to which a separation mechanism succeeds in preventing unauthorised access is affected by:
- The complexity of the security-enforcing interface
A low-complexity interface is better. This can be determined by taking into account things such as the number of system calls into the underlying operating system, the number of system components involved in the separation, and the complexity of the data passed to those system calls. This is often described as ‘reducing the attack-surface.’ - The number of layered mitigations applied to the interface
Additional layers of protection on the interface make it stronger. Measures might include such things as disabling unnecessary parts of the interface, or adding a filter that blocks common attacks. This is a type of ‘defence-in-depth.’ - Configuration
The effectiveness of a separation mechanism will also depend on the likelihood that it is configured correctly. An attacker could circumvent poorly configured protections. The complexity of of a system’s configuration will be an important factor. For example, the number of features that must be configured, and how well those features are configured by default. Principle 14: Secure use of the service will help you determine how easy a cloud service makes it for you to configure the service well.
Types of separation
While compute, network, and storage are the key building blocks upon which functional cloud deployments are built, there are other factors that affect how work is separated in the cloud.
This section explores the various types of separation, highlighting pros and cons along the way.
Logical separation
These logical separation methods are designed to ensure correct behaviour in the absence of an attack, rather than defending against direct attacks. Despite this, they are often crucial security boundaries that you will need to trust.
Per-customer separation
The most definitive claim that cloud providers make in their terms and conditions is that they will ensure your data cannot be accessed or influenced by other customers of the service (unless it is intentionally configured to allow that). This type of separation is given different names by different cloud providers, but is reflected in the service structure that is created when you originally sign up. You may see this referred to as a ‘tenancy’, ‘subscription’, or ‘organisation’.
In some cloud services, separation between customers may be identified by use of a per-customer instance of the platform’s user identity service, a domain being directly associated with a customer, or the level at which the service is billed. This per-customer level of separation is strong since it is hard to casually misconfigure and hard to attack as it undermines a fundamental promise made to each customer by the service provider.
Per-workspace separation
Within a given tenancy, some cloud providers may allow levels of separation similar to those of per-customer strength. This may be described as an account, resource group or project. Separated workspaces such as these can be an effective separation method where you have defined multiple tiers or “security domains” in your service architecture. Examples include:
- placing log aggregation in its own separated workspace, so that the logs are protected for forensic analysis if another part of the system is compromised
- separating development and test environments from the production environment
- separating Tier 0 from the other tiers when following our secure systems administration guidance
Control and data planes
Cloud services have a control plane used by the service provider to operate and maintain the service, and a data plane that hosts customer data and workloads. You should be confident that there is strong separation between the two, whatever type of cloud service you are using.
Appropriate controls to look for are described in Principle 4: Governance framework, Principle 5: Operational security, and Principle 12: Secure service administration.
Identity and access management
Effective separation relies on a robust, definitive, and trustworthy source of identity for users and resources, against which policies and separation rules can be applied.
Effective identity and access management (IAM) is usually necessary to enforce separation between customer-facing services, within underlying supporting fabric, and within the administrative interfaces accessed by the cloud vendor and their staff.
Appropriate controls to look for are described in Principle 9: Secure user management, and Principle 10: Identity and authentication.
In-application separation
Separation enforced within an application relies on carefully designed logic and data tagging within the application itself, to map the permissions of a user to the data they are allowed to access and process. SaaS is often implemented this way.
A vulnerability in the application will circumvent the separation, so it is important to minimise the ability for an attacker to run code.
This type of separation is appropriate between cloud services that have been specifically designed to be multi-tenanted, as long as they do not execute customer-provided code or scripts in the service.
Compute separation
Compute separation is used when two applications execute on the same physical server or host. This helps defend against direct attacks from other customers sharing the same host and lateral movement when you have multiple apps on the same host.
Services that execute customer code will need effective compute separation to defend against direct attacks by malicious customers. This means that IaaS and PaaS products will need strong compute separation, whereas most SaaS products will not, because they don’t offer to run code.
The security boundary implemented in a compute service will be more robust if the security enforcement mechanism has simple configuration (low configuration complexity), a small attack surface (low interface complexity) and implements defence in depth.
A simpler configuration and smaller attack surface makes vulnerabilities less likely, and defence in depth increases the number of vulnerabilities needed for a successful attack. Those goals are best achieved when they implement a hardware-backed security boundary.
If multiple customers execute code on shared hosts, compute separation will be needed to keep customers separate from one another. Even when customers don’t share hosts with other customers, compute separation can help them limit lateral movement if one of their deployments is compromised.
Kernel-enforced separation
Applications that are not designed to be multi-tenanted may be run side by side inside an operating system (OS), with each customer’s copy of the app relying on the software separation provided by the underlying OS kernel.
A common use of kernel-enforced separation is hosting several Docker containers on a single node.
An OS kernel is a complex system, so kernel-enforced separation usually has significant complexity in both its configuration and its interface. This means the separation is likely to be configured in a way that limits its effectiveness, and the implementation will be prone to exploitable vulnerabilities. This makes it a poor compute separation mechanism, by default.
This type of separation is not usually considered to be a strong enough security boundary for cloud services where the customer can execute their own code or scripts. It is, however, appropriate for use within SaaS services to defend against lateral movement, as long as customers are not allowed to execute any of their own code or scripts in the service.
Hypervisor-enforced separation
Virtualisation using a modern hardware-backed hypervisor is an effective way of implementing compute separation where customers can run their own code, such as PaaS and IaaS.
Examples include:
- reinforcing containers, by ensuring that the containers belonging to different customers are kept in separate virtual machines
- reinforcing fully managed serverless components such as Functions-as-a-Service, by ensuring that the workloads of two customers are processed in separate virtual machines
- hosting virtual machines
A good hypervisor will have much lower complexity in its configuration and interface than a standard operating system, making it a robust security separation mechanism. The complexity of the interface can be reduced even further if your cloud vendor customises their hypervisor to remove unused functionality, making it even more resistant to attack.
Such a hypervisor will need to use hardware virtualisation extensions and should be as simple as possible (that is, it only contains the functions necessary to run and orchestrate virtual machines). You may hear terms like type 1 or bare metal hypervisor used to describe hypervisors that use hardware virtualisation extensions.
The NCSC’s Virtualisation Security Design Principles discuss the security benefits of virtualisation in more detail.
Confidential computing
Cloud platforms built on supporting hardware can apply defence-in-depth measures to a customer’s service running in the cloud. Some will reduce the attack surface area, others will mitigate specific attacks.
Depending on the service you are using, implementations will be designed to either apply additional defences to an entire virtual machine, or a secure enclave within a virtual machine that can only be accessed using tightly defined interfaces.
The benefits of services described as implementing enclaves or confidential compute can include:
- securely decrypting data in an isolated environment by closely integrating with key management services and using the hypervisor as a root of trust
- heavily reducing the attack surface of an application by removing unnecessary functionality, such as device drivers
- increasing isolation between a workload and its compromised host machine
- increasing isolation between a workload and a malicious administrator logged into its host machine
- verifying that your workload is running on a specific type of server with a known hardware profile, including whether it is hosted by a specific cloud provider
- verifying the integrity of the underlying hardware and its firmware
- verifying that a workload has not changed from a known-good baseline
- enforcing a code signing policy so that only code that you have authorised and signed can run
- encrypting all of the memory used by your workload inside the host’s processor, so that it cannot be accessed by the hypervisor, or an administrator that has physical or programmatic access to the hypervisor
- implementing a virtual hardware security module (such as a virtual TPM) that is cryptographically bound to the workload, and can generate and store keys, secrets and boot measurements in a way that is not accessible by the hypervisor
- attesting any of the above to a remote service
The exact benefits and amount of extra defence-in-depth that you get will depend on your choice of cloud service, the underlying hardware that it relies on, and how you write the application to run on your chosen service.
It may also be necessary to write a bespoke application to get the benefits described above. You should therefore only look for confidential computing if the extra complexity is justified by the specific needs identified in your threat model, and you are able to achieve that benefit with your application model and choice of service.
Weaknesses in your applications can undermine the benefits provided by confidential computing technologies. You will therefore need to ensure that the code running inside of an enclave or virtual machine is architected in line with good practice for your choice of confidential computing technology, as well as following good practice for secure development and deployment.
NIST discusses the specific benefits and suggested uses cases of confidential computing in more detail in a whitepaper – Hardware-Enabled Security for Server Platforms.
Dedicated hosts
Some cloud providers allow you to buy compute services where they guarantee that only one customer is using the physical host at any one time. This removes the need for compute separation, for the purpose of defending against direct attacks from an external attacker.
If you choose to host several of your workloads on a single dedicated host, you may need to include your own defences against lateral movement between those workloads. For example, you may use virtualisation to host several virtual machines on a single host. In this scenario, the hypervisor could be vendor-managed, or if necessary, you could configure one yourself.
You will still be sharing all other components of the cloud platform with other customers, including the management plane, Software Defined Network, Identity and Access Management (IAM) and storage. Relatively speaking, the reduction in overall attack surface by not relying on compute separation is small compared with the attack surface exposed by those other security-enforcing components. It is therefore only usually beneficial to use dedicated hosts when your workload cannot be virtualised on a hypervisor.
The security benefits of sharing more security responsibility with the cloud provider will normally outweigh the benefits of using a dedicated host. As a result, you should not avoid a service that shares more responsibility with the provider just because it doesn't have a dedicated host option.
Edge computing
Edge computing is a variant of a dedicated host, where the customer runs hardware provided by the cloud service, on their own premises. It is most commonly used to maintain uptime when an organisation’s internet connection drops, or when very low-latency is required. It can also provide a platform to pre-process data before sending it over the Internet and so reduce the bandwidth required to the Internet.
The model still relies on connectivity to the cloud’s management plane, and like a dedicated host, it depends on the integrity of the security separation of those other cloud components.
From a compute separation perspective, edge computing should be considered to have similar security properties to a dedicated host. This includes the reliance of another separation mechanism such as a hypervisor to implement security boundaries between workloads hosted on the edge device.
However, edge computing will usually only have a subset of the security benefits associated with the cloud, for example there is often a reduced logging and monitoring capability to reduce the bandwidth requirements between your data centre and the public cloud.
Network separation
Cloud services should have a software defined network (SDN), which allows a single set of physical networking equipment to host an arbitrary number of cloud networks. This means that multiple customers can have cloud networks with overlapping IP address spaces, without interfering with one another. The SDN separates cloud networks unless configured to join specific networks together. You should identify whether the default configuration for a cloud network allows access to or from the internet.
If you configure a cloud network to block external access (to prevent data exfiltration), that will typically prevent access to shared cloud services. If the SDN can be configured to provide private access to these cloud services, make sure this only provides the network access to your tenancy of those services. This prevents an attacker from exfiltrating data from the network by passing it to their tenancy in the shared service, then extracting the data from the service via the internet.
You can gain confidence in a service if you can build on an application-layer network (ALN), such as a service mesh. ALNs enforce network flow controls between applications or microservices, rather than network locations like IP addresses. This is just as effective as traditional controls applied at the IP layer, but is less prone to error and behaves more predictably. Using an ALN also gives you defence in depth on top of the benefits of a standard SDN. An ALN may also provide additional security features, such as automatic authentication and encryption of network traffic, improved logging and monitoring of network traffic, and continuous network mapping.
Principle 1: data in transit protection presents the two primary approaches to protecting data in transit: encryption and network protection. An SDN provides network protection by separating your cloud networks from other networks. An ALN inherits and builds on the underlying SDN’s network protection and may also provide encryption.
Network separation should defend against direct attacks from external networks and lateral movement within the network. Defending against external attacks will typically involve network flow controls on inbound traffic and application-layer firewalls to block malicious traffic, such as SQL injection attacks in inbound requests. Defending against lateral movement within the network will involve network flow controls within the network and encryption of internal traffic.
Storage separation
There are two primary ways to enforce separation of data storage: encryption and access control policies. Both methods usually rely on the cloud provider's Identity and Access Management (IAM) polices and rules, with access checks either enforcing access to the decryption key or the data object itself.
Encryption for the purposes of separation will usually also meet the requirement described in Principle 2.3: data encryption to ensure that that no data is written to disk in an unencrypted form.
A combination of the two types of separation can add defence in depth, although this will usually rely on access control policies being applied separately to data access and key access. For example, if your data is encrypted using a key that can only be accessed by a resource belonging to your account, then this should also prevent another customer from being able to decrypt the data, even if they have been accidentally granted permission to access the raw data. This can also be useful within a SaaS, if the data decryption key can only be accessed by your users, as it could reduce the impact of a vulnerability within the service.
Access controls are commonly applied to data storage using access control lists (ACLs). Care should be taken to ensure that the ACLs used do not make data available more widely than desired. In cloud platforms with a central access control mechanism, there may also be a separate mechanism for controlling access to the platform’s bulk data storage services. Where possible, use the central access control mechanism for managing access to stored data so that only one mechanism needs to be understood and configured correctly for the entire platform.
