Cloud security guidance

Goals

You should adapt your approach to security to be cloud-native, using managed services to solve common problems.

• take full advantage of the shared responsibility model, preferring serverless and PaaS, and avoiding IaaS wherever possible
• build a clear understanding of your responsibilities, and those you can share with your cloud provider
• use managed services for solved problems
• identify cloud native alternatives to traditional tools and practices
• do not use a cloud service that fails to meet your needs just because it is part of the cloud platform you have chosen
• use the lift-and-shift guidance when you cannot take a cloud-native approach

Context

Using a cloud platform like another data centre is a common cause of breaches. You should adapt your approach to security, using managed services to solve common problems, such as hosting static websites, performing security monitoring, and applying access controls, including for network traffic. This is often described as a cloud-native approach. You should identify cloud-native solutions, rather than defaulting to the traditional solution to a problem.

If your cloud platform has many services, or if the quality or security characteristics varies between services, you may wish to use technical controls to limit which services in the platform can be used. If you do, make sure that the process for allowing new services is usable and does not drive users to unmanaged alternatives, such as shadow IT.

Further reading

• Lift and shift guidance

Goals

Access to your cloud platform should require strong authentication. This applies to all users, including your developers, customer administrators, and finance personnel who are accessing billing data:

• use single sign-on (SSO) to simplify account and credential management
• apply appropriate modern authentication best practices, including blocking common passwords, requiring multi-factor authentication (MFA), ensuring identities are not shared between multiple people, and performing security monitoring of authentication events and escalations of privilege
• integrate the authentication mechanism for your cloud platform with your joiners/movers/leavers process
• ensure users outside your organisation require authentication that’s equally robust
• invest particular effort in securing your administrator users' accounts
• ensure identities with all-powerful permissions can only be used for emergency accesses
• ensure you have contact details for each user to enable your incident response process

Goals

You should be confident that service identities are authenticated effectively so you can apply access controls.

• use your cloud provider’s functionality for service identity, rather than using user identities for workloads or automation
• use a different service identity for each use case, such as a single microservice, component, or administrative function
• ensure any credentials for a service identity are a randomly generated high-entropy cryptographic secret, not a password
• let your cloud provider manage the credentials for service identities
• prefer managed integrations when connecting your cloud platform to external services, rather than managing the authentication yourself

Context

Just as users need to be authenticated, so do workloads and pieces of automation. Historically, some workloads have acted as a user, including their username and password in the application or configuration. Not only does this prevent the use of effective MFA, but it makes security monitoring difficult, as the monitoring may not be able to differentiate between manual and automated actions. Using a service identity instead enables more robust authentication and gives more context to the actions taken by the workload.

You should use a unique service identity for each logical component. This ensures that each component can be given access to only the data and services that it needs, independent of other components. This approach will also help your observability efforts, as each action should be annotated with the acting service identity. For example, if you use a microservices architecture, each microservice should use a different service identity. Similarly, when you use automation to enforce security, each piece of automation should have a unique service identity.

When you configure access controls between services built on the cloud platform, you should prefer the cloud provider’s functionality for service identity, rather than using more primitive methods like API keys or passwords. If this isn’t possible, protect API keys and password using secure secrets management, as described in action 11. Protect secrets carefully.

You may need to connect your cloud platform with other cloud services, such as source code repositories, log analytics services, and threat intelligence feeds. Where possible, you should use an integration with the external service that is managed or brokered by your cloud provider, rather than authenticating using long-lived secrets.

Goals

You should apply granular access controls so that user and service identities can only access the data and services they need, when they need to. This should include balancing the principle of least privilege with the need to keep your access control configuration usable.

• ensure your access control configuration is easy to understand and analyse
• apply the principle of least privilege to your access controls
• use ‘just in time’ administration to reduce the standing privileges of your administrator users
• apply permissions for user identities to named groups, not individuals
• detect and remove unused and unnecessary permissions over time
• use workspaces to simplify your access control configuration
• only allow customer administrators and automation to access sensitive data and services
• ensure you have visibility of all external data sharing, and that the policies applied continue to meet your expectations over time

Access control concepts are described in more detail in the NCSC’s secure system administration guidance.

Context

The principle of least privilege means that an identity can only access the data and services it needs to, when it needs to. For most use cases, this means ensuring the identity only has the permissions it needs. For identities with more powerful permissions, you may also need to limit privileges to ‘just in time’ access, as described in our secure system administration guidance.

When setting your access control configuration, you should start with something simple and easy to validate, then use tooling to make it more granular if necessary. Ensure your teams have the permissions they need to fulfil their role, without giving them unlimited power. You should ensure that your access control configuration is appropriate for your needs (as described in action 13. Maintain security over time). You should also use automation to check the access control configuration (as described in action 5. Use automation to enforce security).

It’s important to manage external data sharing carefully, so that data and services are not shared externally by mistake. This might include making data buckets public, sharing cloud resources with other organisations, or integrating with external services, such as third-party CI/CD services. A blanket ban on external sharing may force users to use unmanaged shadow IT, so take a pragmatic approach.

Further reading

• Preventing lateral movement
• There’s a hole in my bucket
• The security benefits of modern collaboration in the cloud

Goals

The bulk of your security approach should be implemented using automation. You should use a wide variety of security automation to detect and alert, or block unwanted changes, including:

• configuring guardrails to prevent undesirable changes
• deploying autonomous checks to prevent, detect, alert on, and remediate issues
• using infrastructure as code for all non-experimental deployments
• performing automated analysis to check the correctness and security of code and configuration before deployment

Context

Guardrails provided by your cloud provider and checks you write yourself should perform the bulk of your security operations. You should ensure that policies taking direct action have a low false positive rate and clear messaging. Where a significant false positive rate is unavoidable, you should instead trigger alerts and investigate before acting.

You should use your cloud provider’s native guardrails to prevent undesirable changes before they are taken, such as exposing data storage to the internet. You should also use automation to alert on less common configurations, which should not be stopped by guardrails but happen infrequently, such as changes to the organisational structure (see action 6. Establish an organisational structure below).

Use automation to trigger alerts when resources do not follow your organisation’s policies, such as resources being created without tags. See action 9. Establish observability for more details on resource tagging. You may also want to use automation to delete resources that remain out of policy for an unacceptable amount of time.

You should prefer your cloud provider’s managed services for automated analysis of code and configuration over deploying a third-party product in IaaS. This will likely be more robust to attack and more able to defend deployments from one another during analysis. The analysis functionality forms part of your software supply chain, so its security is a foundational requirement for your applications’ security.

Goals

The way you structure your organisation’s cloud resources, including workspaces, will have a significant impact on how easy it is to manage access to those resources.

• design your organisational structure to make it intuitive where resources should exist and who should have access to which resources
• ensure your organisational structure helps you protect access to important workspaces, such as your production environments
• integrate your guardrails with your organisational structure to apply controls consistently
• use automation to manage your organisational structure over time
• consider whether each security control should be applied to the entire organisation, or just parts of the organisational structure

Context

Each organisation’s structure is unique, so you should think about the structure that would be the most intuitive to your users. You should tailor your approach to make access to resources obvious and easy to manage. For example, you may want to keep billing resources separate from engineering resources, internet-facing services separate from internal services, or production environments separate from testing environments. You should also consider whether some of your workloads are subject to a different threat profile or set of regulations, which may be easier to manage using your organisational structure. Mirroring the structure of your reporting chains or cost centres may not be the best approach.

You may need to change your organisational structure over time, such as in response to a merger or acquisition. Consider whether you would choose to move workspaces or recreate them from scratch, using infrastructure as code. You should also consider the migration and restructuring tools available from your cloud provider. You should also tailor your approach to fit the approach preferred by your cloud provider, so that you can use its tools effectively.

Often, you can apply security controls to the entire organisation, or just one part. In each case, you should consider what the control is trying to achieve, and whether it should be applied universally. For example, security monitoring should be applied across the entire organisation, but you may wish to apply more strict controls to particularly sensitive parts of the organisational structure than others. As described below, you may also want to apply some controls to each workspace by default, using automation, rather than to the entire organisation. This will allow you to remove the control from individual workspaces, where appropriate.

Listen to your users; if they are telling you that resources are hard to find, often created in the wrong place, or access control becomes difficult, you may need to change your organisational structure.

Goals

Workspaces are a central tool for resource management and access control in cloud platforms. There is an important balance between making workspaces sufficiently granular and creating too many workspaces. You should use workspaces effectively throughout their lifecycle.

• make the creation of new workspaces self-service and straightforward
• use technical controls (such as guardrails) to make workspace configuration secure by default, from when the workspace is created
• annotate workspaces to ensure better monitoring access controls, such as whether they store or process sensitive data
• annotate workspaces that should have externally facing services or share data externally
• limit the resources in each workspace to one project, product, or component, balancing security with ease of use and management
• identify and delete unused workspaces
• only allow your administrators and automation to access sensitive workspaces
• always deploy to sensitive workspaces using infrastructure as code

Context

Workspaces are an important kind of logical separation. It’s important to make workspace creation simple and self-service to discourage new resources being created in existing workspaces where they do not belong. When a workspace is created, it should have a sensible and secure default configuration. This should include the configuration of default guardrails, security monitoring, the collection of activity logs, and enabling important security features. It may be necessary to change some of this configuration on a per-workspaces basis, but every workspace should start with a good configuration. For example, you may want to enable external sharing in certain workspaces, but it should be disabled by default. Your cloud provider may offer a mechanism to automate this process, which may be referred to as templates, blueprints, or landing zones.

You should use workspaces to simplify your access controls, making it easier to apply the principle of least privilege. It’s important to ensure that this separation is not undermined by giving workloads in one workspace unnecessarily broad privileges over other workspaces. You should also be wary of joining workspaces by connecting their networks together without granular controls. Follow your cloud provider’s best practices for keeping workspaces separate and applying the principle of least privilege when connecting resources in different workspaces.

You should annotate workspaces that store or process sensitive data, or that have externally facing services or external sharing enabled. This will allow you to monitor and control access to these workspaces more carefully than for most workspaces. This might be achieved by tagging the workspace directly, or by maintaining a list of workspaces with each annotation yourself. You should integrate these annotations with your automated security controls, such as by alerting when external sharing is enabled in a workspace without the corresponding annotation. You should check periodically that annotations are still necessary and remove annotations (and any accompanying permissions or exceptions) that are no longer needed.

It’s common to create workspaces for experimentation and testing. You may want to place fewer limits on what can be done within such a workspace but limit how it can interact with other workspaces. For example, you may want to prevent external sharing from being enabled or block access to workspaces annotated as storing sensitive data. You should try to strike a balance between providing opportunities to experiment and avoiding unnecessary risk to sensitive data and services. Make sure that these test workspaces do not start to be used for sensitive work as time goes on.

To protect access to sensitive data and services, you should deploy sensitive workspaces using infrastructure as code and prevent manual access by non-administrators. Not only will this make it harder to interfere with sensitive data, but your deployments will be more predictable and less prone to unexpected outages. You should ensure your operations personnel have sufficient tooling and monitoring to identify, diagnose, and remediate issues in sensitive workspaces without needing manual access. Make sure you can access sensitive workspaces in an emergency, such as if the deployment pipeline is unavailable, but treat this as emergency access.

Goals

Cloud platforms are inherently networked systems. You should defend your networked services from attacks, both from external and internal networks.

• manage access between networked services so that each service can only access the services and data it needs to
• manage access to untrusted networks (including the internet) for both inbound and outbound traffic
• apply protections against common network protocol attacks, particularly from untrusted networks
• replace legacy management protocols or protect them using modern authentication mechanisms, treating their use as high-risk accesses

Context

There are two common approaches to network security in the cloud; micro-segmentation and zero trust. Micro-segmentation works by using lots of small networks and traditional network controls to limit access between networks. Zero trust networking uses authentication and identity-based access controls at the application layer. Whichever approach you take, ensure that you apply the principle of least privilege to access to networked services, as described in action 4. Apply access controls.

While protecting networked services, some attacks must be prevented at the application layer, while others will be prevented at lower layers. This will affect whether you or your cloud provider can prevent each attack. Your cloud provider may offer services to defend against common attacks, such as denial of service or HTTP request smuggling. You should use the services available to you to defend against common attacks.

Legacy management protocols like RDP and SSH are a common source of cloud breaches. This is largely due to a lack of support for modern authentication practices and the excessively broad privileges often provided by these protocols. They also provide limited observability of the actions taken. You should replace legacy management protocols with cloud-native alternatives.

When legacy management protocols cannot be replaced, they should be protected from untrusted networks, such as the internet. Preferably, this should be done using an administration proxy service built into the cloud platform. If this is not possible, traditional protections like a VPN can be used instead. Whichever method you choose, treat the use of legacy management protocols as high-risk accesses.

Further reading

• Zero Trust architecture principles
• Using TLS to protect data
• Cyber security design principles

Goals

You should build and maintain visibility of your cloud resources, how they change over time, and monitor for issues, consuming security-related events in the platform. This will enable you to detect and respond to incidents effectively.

• make sure you can view and analyse a complete inventory of your cloud resources and their configuration over time
• use resource tagging to track resource metadata
• establish a mechanism for the collection, aggregation, and retention of activity logs for security purposes
• ensure activity logs for security purposes cannot be disabled, deleted, or modified, and that access to activity logs is restricted to those who need it
• establish a mechanism for security monitoring of the platform

Context

Resource tagging is a common approach for recording metadata like the owner, project, and data sensitivity of a resource. This can then be used for investigating issues and removing unwanted resources. As described in action 5. Use automation to enforce security, you should use automation to ensure that alerts are triggered when resources are created without appropriate tags or modified to remove tags. You can then use tags to add contextual information for other automated checks. If you use tag values to make automated decisions, you should consider how to verify that the tag value is correct.

Activity logs are collected for multiple reasons. You should understand which logs are collected for operations purposes and which are collected for security purposes. Operations logs do not need to be protected as rigorously as security logs and doing so would limit their utility.

Activity logs for security purposes are used to investigate the causes of an incident and include the raw information used to perform security monitoring. This should include signals and activity logs from your cloud provider, from all services in use, and from your own applications. You should ensure that you can combine all activity logs for any resource, irrespective of the logs’ origin.

Ensure logs are held for long enough to be able to answer the questions you'll be asked during an incident. It can be months before incidents are detected, so you should store your most important logs for at least 6 months. The amount of time you keep log data may vary for each source depending on factors like cost and availability of storage, and the volume and usefulness of different data types.

Your security monitoring will need to include changes made to the platform, ongoing monitoring of how the platform is used, getting and acting on events from your cloud provider, and attributing actions back to specific identities. The security monitoring functionality built into the cloud platform will typically have access to information not made available to you via other means, so this will be more effective than deriving your security monitoring purely from activity logs. You should refer to your cloud provider for guidance on which kinds of logs have the most security impact.

You should refer to Transaction monitoring for online services for further guidance on effective protective monitoring.

Further reading

• Introduction to logging for security purposes
• What exactly should we be logging?
• Asset management
• Logging and monitoring

Goals

An incident response plan is a crucial part of effective cyber security. You should include your cloud platform in your incident response planning.

• ensure you receive and act on alerts from your cloud provider
• ensure your cloud provider has the right emergency contact details for you
• ensure you have backups in place for critical data and ‘infrastructure as code’ documents
• establish an account recovery process with your cloud provider up front
• consider your incident management objectives, and how to achieve those objectives most effectively in the cloud
• plan which actions you will have to take, which your cloud provider will have to take, and what you might need to tell them to do on your behalf

Incident response planning is covered in more detail in our Incident management guidance.

Context

Your cloud provider will be well-placed to spot common issues, misconfigurations, and attacks. It’s important that they can notify you promptly when you are affected, and that you take action to remediate the issue. This will include alerts that can be handled by automation, and those that require manual intervention. Make sure the emergency contact details you give to your cloud provider are kept up to date. Use groups (for example a shared mailbox for emergency contacts) rather than specifying individuals.

Your incident management objectives may vary between cloud environments. For example, you might prioritise the collection of forensics details to identify the cause of the incident, or prioritise speed of recovery by destroying the environment so it can be replaced from infrastructure as code. You should consider ahead of time what your objectives should be, and document them with instructions in playbooks, as described in our Incident management guidance.

As part of your incident planning, you should prepare a disaster recovery plan. This should include ensuring you are able to recover critical data from backups and to be able to recreate your cloud environment from backed up infrastructure as code documents. Ensure that you test periodically that backed up data is recoverable and complete.

Further reading

• 10 steps to cyber security
• Effective steps to cyber exercise creation

Goals

Cloud platforms often handle various secrets, such as database passwords, API keys for external services, and credentials for legacy applications. You should take a consistent approach to protecting secrets, taking full advantage of the secrets management functionality in your cloud platform.

• avoid the use of secrets where possible, using managed integrations instead
• use a well-documented, consistent process for secrets management, following your cloud provider’s best practices
• prefer a secrets management service operated by your cloud provider
• choose a process that makes it easy to change secrets over time, and make sure you use that functionality
• apply robust security monitoring to secrets, alerting on anomalous activity
• use automated alerts to detect the disclosure of secrets, including cloud credentials, and to trigger your incident response plan

Context

Cloud platforms include various functionality for managing secrets. Where possible, you should use a managed service that stores and protects access to secrets, giving easy functionality to change secrets over time. If such functionality is not available, follow your cloud provider’s best practices for secrets management. Whichever approach you take, you should ensure that the secrets are protected using your cloud provider’s key management service, as described in our guidance on Choosing and configuring a KMS for secure key management.

Your security monitoring of access to secrets should focus on anomalous activity. This could include a user accessing a secret normally accessed by automation, or any one identity accessing many different secrets. Your response to suspicious activity with a secret should include changing the secret and invalidating the previous version.

Goals

As described in Principle 14: Secure use of the service, the cloud platform should be secure by default and by design, helping you to fulfil your security responsibilities. Whether your cloud provider does most of the work, or you have to use guardrails and automation yourself, you should be confident that the data stored and processed in the cloud platform is protected.

• protect data at rest, using your cloud provider’s data protection systems
• protect data in transit
• use services with appropriate separation technologies
• manage your cloud provider’s access to your data
• ensure the locations in which your data is stored and processed meet your needs
• only store and process data in the cloud while necessary, using retention policies to ensure data is deleted once no longer needed

Context

You should be confident that all data in the cloud platform is encrypted at rest and in transit, as described in our guidance on Choosing and configuring a KMS for secure key management. Your cloud provider may enforce data protection at rest and in transit by default, or you may need to enable the use of encryption using automation, as described in action 5. Use automation to enforce security. For more details on encryption at rest, please refer to Cloud security principle 2.3.

It is important that effective separation technologies are used to protect each workload from other activity taking place on the cloud platform. This should include logical, compute, networking, and storage separation, as described in our Technically enforced separation in the cloud guidance. You should choose services so that you have strong separation between your workloads and other customers' and prefer strong separation between your own workloads.

As described in the introduction, you should avoid trying to design your systems to defend against your cloud provider. However, it’s still useful to manage how individuals working for your cloud provider have access to your data. This should include both access to raw data and to derivations of your data, such as activity logs or machine learning models trained on your data. As described in Principle 6.2: technical controls for service administration, access to your data by your cloud provider should require explicit time-bound permission from you on a case-by-case basis, along with authoritative audit information. You may need to make a configuration change to enable this functionality. Your cloud provider may be training machine learning models on your data unless you opt out.

As described in Principle 2.1: physical location and legal jurisdiction, you should be confident that you know where your data is, and who can access it. You should configure guardrails to ensure that your needs are met for:

• the countries in which your data will be stored, processed and managed
• the legal jurisdiction(s) to which your data will be subject
• the rights that your cloud provider will have to access and use your data
• the legal circumstances under which your data could be accessed without your consent
• how your data protection approach affects your compliance with UK legislation

Data breaches often include the loss of data that did not need to be stored in the breached system in the first place, making the impact of compromise unnecessarily large. You should avoid storing data in the cloud that is not required, and you should use retention policies to ensure data is deleted once no longer needed.

Goals

Having configured the cloud platform to meet your needs, you should maintain its security over time, adapting to changes in the platform, the industry, and your threat model. This should include:

• periodic automated tests that your configuration is correct
• periodic checks that your configuration meets your needs
• periodically reassessing the security of the platform’s architecture and controls, evolving your approach over time
• establishing and evolving best practices and patterns for solving common problems
• keeping up to date with new security features, capabilities, and best practices from your cloud provider
• ensuring your penetration testing regime includes the configuration of your cloud platform
• communicating to your personnel (including customer administrators) about important changes, including changes to best practices

Context

Cloud platforms can be large, complex systems, so it’s important to ensure that your configuration of the platform remains correct over time. This should include checking that activity logs continue to be collected and can be queried effectively to answer security-relevant questions For more information on answering security-relevant questions, see the NCSC blog post on What exactly should we be logging? You should also test that your security monitoring detects and responds appropriately to important events and attacks, such as the use of emergency accesses. You should also test your disaster recovery plans work effectively, including testing that you can deploy to a fresh environment using your infrastructure as code, and can restore your data from backups.

You also need to ensure that your configuration meets your needs, such as by checking that your organisational structure helps you to apply effective access controls, as described in action 6. Establish an organisational structure. You should also identify workspaces missing important security features that would be enabled in newly-created workspaces, and apply those features where possible.

You should consider how your guardrails change over time. New guardrail capabilities will be released and should be considered. You should identify whether changes to guardrails affect resources that have already been created. If they don’t, you should use automation to identify such resources and take appropriate action.

It is important to consider the configuration of your cloud platform when performing penetration testing on the applications built on the cloud. Poor configuration is a common cause of cloud-related data breaches and is often easily detected in penetration tests. Note that there is rarely any benefit to performing a penetration test on the cloud service itself, and any such test may be constrained by the cloud service’s terms of service.

Cloud platforms tend to receive new features continuously, making it easy to miss important new security features and capabilities. You should invest effort in keeping up to date with these new developments, and deciding how to integrate them into your deployment to improve the security of your cloud platform.

Further reading

• Effective steps to cyber exercise creation