Cloud security guidance
Page 5 of 29
Cloud security shared responsibility model
The cloud security shared responsibility model is commonly used to describe the fundamentals of who looks after the security of your data and services.
As with any outsourcing agreement, there is a joint responsibility for the security and availability of data and workloads in a cloud service that is shared between the cloud provider, and the customer of that service. The amount of responsibility that each party must own will depend on the type of service, and how the service provider has chosen to implement it.
This guidance explores the types and nature of the responsibilities to be shared, and how they are affected by your choice of service and deployment model. It also explains why you should prefer to cede as much security responsibility as possible to your trusted cloud provider, who will be best placed to manage security.
Responsibilities
When you build services in your own data centres ('on-premises'), you are entirely responsible for the security of your service. When you use cloud services, you delegate management of parts of the service and hence some of that security responsibility to the cloud provider. The amount that you are directly responsible for, and the amount of responsibility that you delegate to your service provider will vary, depending on the service that you use.
For example, the cloud provider will almost always be responsible for maintaining the availability and physical protections of their servers. Responsibility for the security of the application running on those servers will depend on the type of service used.
The design of a hyperscale cloud platform makes it much easier to meet security responsibilities effectively than traditional architectures. We have covered some of these architectural benefits in our white paper on the security benefits of a good cloud service. The security benefits in the paper apply to aspects of the service that your provider is responsible for. You should therefore, delegate as much responsibility for security to your hyperscale cloud platform as you can. For example, you should make your cloud provider responsible for applying security updates to all software your organisation did not write.
You will always be responsible for:
- ensuring that the service can meet your security needs
- securely configuring the services that you have chosen to use
- deciding which data you store in the services you use
You must understand exactly what your responsibilities are, if you are to act on them. Penetration testing, configuration checks, and red team exercises will usually focus on the parts of the cloud service that you have taken direct responsibility for.
The 14 Cloud Security Principles will help you choose a cloud provider that can be trusted to fulfil their share of security responsibilities. Principle 14.2 will help you to identify cloud services that make it easier for you to fulfil your security responsibilities too. Our using cloud services securely guidance will give you a list of actions that you will need to take to secure your cloud platform or SaaS.
Cloud service models
The table below breaks down the responsibility allocation options for the four main deployment strategies. It shows which service components the customer and the cloud provider is responsible for (across IaaS, PaaS and SaaS deployment models).
Infrastructure as a Service (IaaS)
It is up to the provider to provision fundamental resources like processing, storage, and networks, on which users can build their applications.
The share of responsibilities within any given machine will vary, from being entirely the responsibility of the customer, to the vendor providing tools to help manage the operating system (OS), or even using those tools on the customer’s behalf.
If you are running an application in IaaS, we recommend that you identify the components in the architecture that could easily be replaced with managed services. This often includes storage, identity and access management, data flow controls, logging, and monitoring.
Platform as a Service (PaaS)
There is a lot of variation in the amount of responsibility shared with the provider in PaaS services. One end of the scale blurs the line with IaaS at the point where the provider helps manage the OS. At the other end, customers provide source code for their application, and the service does the rest.
If you need to build or host an application, we recommend that it is built on PaaS in preference to IaaS.
Software as a Service (SaaS)
We recommend SaaS if you can find a service that meets your needs. This model allows you to delegate the most responsibility to your cloud provider and gain most advantage from the security benefits of the provider working at scale.
Serverless and containers
Serverless components and containers are also widely used service models in the cloud, but where they fit in the shared responsibility model is more nuanced.
Serverless
Serverless blurs the line between PaaS and SaaS. Typically, serverless components are made up of serverless compute (which is at the more managed end of PaaS) and other components running the cloud provider’s software (so essentially SaaS).
Containers
The type of service you use to host and orchestrate your containers will significantly influence how security responsibilities are shared between you and your cloud provider.
A cloud container service can resemble PaaS, by taking full responsibility for building, maintaining, and running an application, only granting the customer indirect access to a shared orchestration platform.
At the other end of the scale, a container service that requires the customer to build and maintain the container image and configure (or even host) the orchestration service will only bring the security benefits associated with IaaS.
Managed service providers
You may need a managed service provider (MSP) to handle cloud services on your behalf. These type of supplier may also be called cloud brokers or cloud resellers, and can include services sold on a cloud provider’s online marketplace.
The use of such a third party can affect the shared responsibility model, as the MSP (and often their suppliers) will need to retain privileged access to the service and hence become a third participant in the model.
The MSP will often be responsible for configuring the service securely, building applications on the cloud platform, and performing effective monitoring. In this situation, you will need to gain at least as much confidence in your MSP as you have identified that you need in your cloud provider. One way to do this is to use the cloud security principles to assess the MSP as if it were your cloud provider. Some of the goals will be achieved natively by the underlying cloud, while others will also need to consider how the MSP operates and configures your instance of the cloud service.
MSPs usually manage several customers' cloud services from a shared management infrastructure. You should ensure that their management infrastructure and their ways of working are in line with NCSC’s secure systems administration guidance, and so meet the goals in Principle 12: secure service administration.
You should ensure that you apply least privilege to the accounts used by the MSP to access your cloud services, and that you have visibility of which specific privileges have been granted to them. You should apply the same standards to your MSP as you do to yourself, including avoiding granting extremely high privileges such as ‘root’ or ‘global administrator’. You should ensure that you can audit the MSP’s interactions with your service as thoroughly as you would your own.
If there is a cyber security incident affecting your cloud service, you will often need the assistance of your MSP during your incident response process. This is separate from the expectations you have on your cloud provider as described in Principle 5.3: incident management. We recommend using contractual clauses so that they (and their supply chain) are obligated to work with your incident response team.
If you use an MSP purely to procure your cloud service, you should review the access control model to ensure that the accounts used by the MSP can only access billing and usage data. They should not retain any highly privileged access to the service itself, or your data stored in the service.
Cloud services run by other organisations
You may need to use cloud services run by other organisations, such as suppliers, regulators, or your customers. As described in approaches to gaining confidence, the other organisation will need to give you confidence that the security features of their application and the underlying platform meet your security needs. This will usually rely on evidence provided by the underlying cloud provider. You will also need to be confident that they have used and configured the underlying cloud platform in a way that meets the security goals detailed in the cloud security principles.
Security benefits of being cloud native
Being ‘cloud native' means focusing on API-centric designs, and making the most of the best native features of the cloud, rather than trying to implement them yourself. This approach will naturally include a preference for SaaS and serverless components over IaaS. This preference for cloud native is reflected in the UK government’s Cloud First Policy.
Solutions already exist
To be cloud native is to avoid re-solving long-solved problems, like operating system management, networking below the application layer, and compute load balancing. By using individual or combinations of commodity services that solve your functional needs, the more fundamental challenges are dealt with on your behalf. This avoids reinventing the wheel and reduces the amount of effort that you will need to put in to keep those services operational.
Economies of scale
It’s easier for a hyperscale cloud provider to meet its security responsibilities when you use SaaS and serverless components, than it is for you to meet them in your own application. This is because the service can be designed to integrate with the provider’s wider systems, abstracting away your use of the service. In contrast, when you use IaaS services, any support the provider gives is constrained and influenced by how you configure the infrastructure and the operating system you use.
Consistent behaviour
A more managed service will have much more consistent behaviour, making it easier to spot unusual patterns. This also means the service provider will have more context of what’s going on, making their protective monitoring more effective.
Using the same set of software throughout the service also makes security updates easier and more predictable to apply. A cloud provider can, for example, apply security updates more quickly and confidently in response to an incident. The bottom line is that cloud security is easier with SaaS and serverless components.
Lock-in
Using cloud native services like SaaS and serverless components will typically mean accepting more technical lock-in, which is described in GDS’s guidance on managing technical lock-in in the cloud. Be aware that building in IaaS or containers will still result in technical lock-in. You should understand the value you get in exchange for the amount of lock-in.
When IaaS is unavoidable
If you have to use IaaS instead of something more managed, you should still delegate as much security responsibility as possible to the cloud provider. For example, use the managed log collection functionality, tooling to help automate security updates, and OS management support made available to you.
Secure by design and by default
As described in Principle 14.1, your service provider should make it easy for you to use their services in a way that is well defended against common attacks. It’s always your responsibility to understand how to configure the service to meet your security needs. A good service will make this easier by using a secure design and default configuration.
