Cloud security guidance

Software-as-a-Service (SaaS)

The cloud provider runs an application in a way that is shared between its customers. Customers only have to consider how to configure and consume the app so that it meets their needs.

Platform-as-a-Service (PaaS)

The model where the cloud provider manages the underlying platform, upon which customers build and deploy applications.

Serverless

Serverless blurs the line between PaaS and SaaS. What sets serverless apart is that each component solves just one functional problem, so multiple components must be combined to build an application.

Containers

Containers, such as Docker containers, are widely used to deploy applications in the cloud. Services that run customers' containers tend to fit somewhere between IaaS and PaaS (which varies depending on your choice of service).

Infrastructure-as-a-Service (IaaS)

This service model is the most similar to on-premises infrastructure. IaaS typically includes virtual machines (VMs) running on shared servers that are managed by the cloud provider and a virtual IP network. In some circumstances, it may also be achieved by allocating physical hardware to consumers.

The security implications of each of the above service models are discussed in the cloud shared responsibility model. There, we advocate that a cloud provider is likely to be more capable of meeting security goals at scale than an individual customer. Whichever service model you are using, you will need to trust your service provider. We discuss determining levels of trust in the section Choosing a cloud provider.

Public cloud

A public cloud is what most people think of when talking about ‘the cloud’. This is also the model referred to by the UK government’s Cloud First policy. It is a service that is consumable by anyone willing to pay for it, accessible from and managed over the internet, from anywhere. It is from the scale of such services and the service provider themselves, that we associate the security benefits of public cloud services.

Public clouds are usually multi-national services with data centres around the world. Many will allow you to specify the countries or regions that your data is stored and processed in. Choosing to limit those locations may reduce the availability, redundancy and resilience available to you.

When moving services from your own data centres into the public cloud, you should assess the risk of moving management operations to the internet, alongside the change in risk posture associated with your chosen cloud service.

When moving enterprise services from your own data centres into the public cloud, you should consider how the availability of those services to users is affected by the availability of the internet connection used to access them. Moving those services will usually increase your organisation’s internet bandwidth requirements. This should be considered separately from the availability and resilience of the cloud service itself, as discussed in Cloud Security Principle 2.5: Physical resilience and availability.

A public cloud service can only protect data according to the OFFICIAL threat model (including data with the SENSITIVE handling caveat). This is because a public cloud service will not design or operate its services, operations, and software engineering processes according to the UK SECRET threat model. If you are developing a service that handles information classified at SECRET or TOP SECRET, you should seek additional specialist advice about the specific threats you need to consider. There may also be cases where information is not classified as SECRET (or above), but where you need to protect the information to a similar threat model. This might include extremely sensitive bulk personal data or services with very high integrity requirements.

Edge computing

Some public cloud providers offer the ability for you to deploy some of their services in your own data centre, using hardware that is provided to you. This is known as ‘edge computing’.

Edge computing should be treated as a variant of the public cloud since its control plane (and sometimes its data plane) will be shared with the public cloud. You will need to have confidence that you can trust your physical data centre (and the network that you use to host the provided edge devices), as well as the cloud service that provided the device.

It can also be useful to treat edge computing as a variant of hybrid cloud, as discussed below. This includes confirming:

• that data flows are appropriately protected between your data centre and the cloud
• that the connection between them has appropriate bandwidth and redundancy

Edge computing is usually deployed by organisations that require extremely low latency between client and service, to cache data on sites where internet connectivity is unreliable, or to reduce internet bandwidth requirements by pre-processing raw data, prior to sending a subset or derivation to the cloud.

You should have the same security expectations for separation between different instances of edge compute, (and between the edge compute and the environment where it is installed) as you have between customers of a public cloud.

The extra security implications of this model are covered in our technical separation guide.

Private cloud

Private cloud services are usually deployed to support a single organisation and are hosted on a private network. They will usually require new infrastructure that has many of the features of a public cloud, though at a smaller scale.

Our white paper on the security benefits of good cloud services outlines the positive outcomes you should expect from any cloud service. Once you are satisfied that the service you are considering provides these benefits, you can then assess the design and deployment of the proposed service, using the goals described in the cloud security principles.

A private cloud hosted on classified infrastructure is an appropriate solution for organisations wanting to store and process highly sensitive classified data, while still getting many of the benefits of the cloud.

Community cloud is a variant of private cloud. It is shared between partner organisations, or organisations with similar business needs. You should have the same security expectations for separation between different users of a community cloud as you have between customers of a public cloud.

Multi-cloud

A multi-cloud strategy allows you to take advantage of more than one cloud service provider. Different cloud services may better meet the needs of different projects, so it is common for an organisation to choose to use more than one cloud platform to get the benefits of each.

You will need to take responsibility for configuring and operating the underlying platform for each cloud service that you use. You will also need to understand the risks associated with each service and gain enough confidence that you have applied the mitigations appropriate to each. These activities will be necessary even if you are running similar workloads (such as containers) on each platform, or using a cross-cloud abstraction tool.

The added complexity of using several cloud providers within an individual project or service will usually add risk to your deployments. This will include increasing the overall attack surface, such as the interfaces between the clouds. Where a single service relies on more than one cloud, it can also reduce availability.

Consider where you may be able to have a single core component that can be used by all your clouds (eg identity or a SIEM), and where there are benefits to using the separate native functionality of each (such as alerting on anomalous activity).

It is common to have whole projects within a single cloud. This is to be preferred, as it reduces the complexity of the application or service.

Multi-cloud : working with dependencies

If you have a project with dependencies on two or more cloud services, there are some additional considerations when designing the service:

• Determine where your data is stored. Then find any data flows between clouds. Refer to Cloud Security Principle 1: Data in transit protection to determine how different implementations may meet your security needs.
• Where it is necessary for one cloud to listen for connections from another, you should treat that interface as externally facing when determining appropriate architectures and other mitigations.
• Your service design will also need to consider the impact of the link between clouds, or the service running in one of the clouds, being temporarily unavailable.

Abstraction tools for multi-cloud

If you use abstraction tools that provide common functionality across several cloud platforms, you should prefer one that uses the native features of each cloud. This lets you take advantage of the security features built into individual platforms and ensures that the abstraction layer and underlying cloud platform do not undermine the security controls built into the platform. We discuss this in more detail in this GDS blog post.

If you choose a tool that re-implements common functionality on top of each cloud (such as in IaaS), you will separately need to apply good security practice to each underlying cloud platform.

Applying an effective least-privilege administration model will usually include using role-based access control (RBAC) to administer and configure each cloud service. If using a single tool to monitor, manage or orchestrate your clouds from one place, ensure that the integration doesn’t undermine that RBAC model. Multi-cloud abstraction tools will likely require highly privileged access to all cloud environments, making them an attractive target for attack. Ensure such tools and their privileges are well defended.

Hybrid cloud

A hybrid cloud architecture enables connectivity and interactions between cloud services, and those hosted on-premises. It is a variant of multi-cloud.

A hybrid cloud often adds cloud-native features to existing on-premises deployments, such as:

• modernising components such as your SIEM with a single SaaS that works across cloud and on-premises
• enabling secure access to existing on-premises services from devices in a zero-trust architecture that rely on modern identity services and Internet-native protocols
• scaling existing applications to increase availability, or to meet peak demand

As with multi-cloud, you will need to determine where your data is stored. Then find any data flows between your data centre and the cloud. Refer to Cloud Security Principle 1: Data in transit protection to determine how well different implementations meet your security needs.

The connectivity between your data centre and the public cloud will rely on your organisation’s connectivity to the internet. You will need to consider how the increase in load caused by a hybrid deployment will raise your bandwidth and availability requirements.

If a service has both on-premises and cloud aspects to it, you should consider architecting the service so that a temporary outage of the link does not affect the availability of the whole service.

When making the move to hybrid, you will need to adapt your organisation’s role-based access control (RBAC) model to include your cloud services. You should design your RBAC model so that the compromise of your on-premises infrastructure does not allow an attacker to pivot in a bid to gain full privilege over your cloud infrastructure, and vice versa.

You can read more about RBAC in our Secure System Administration guidance, and the relevant features that you should expect from your cloud provider in Principle 9: Secure user management.

NCSC guidance

• Secure System Administration guidance
• Security benefits of a good cloud service
• Choosing a cloud provider
• Cloud security shared responsibility model

NCSC blogs

• Security opportunities that can come with using the GDS cloud lock-in guidance

External resources

• Cloud guide for the public sector
• Managing technical lock-in in the cloud