Cloud security guidance

This document aims to assist you in configuring and overseeing your cloud platform while ensuring its ongoing security. You must also focus on how to configure the services deployed on the cloud platform.

Each recommended action is accompanied by:

• the security objectives your configuration should achieve
• the rationale behind these objectives
• suggested further reading for detailed configuration guidance

It is crucial to evaluate whether you’ve met the security objectives of each action or employed alternative protective measures.

Important Note:

Upon selecting a cloud service provider, you must verify that the cloud platform is securely configured and utilized. The more security measures your cloud provider implements on your behalf, the less responsibility falls on you, as outlined in Principle 14.2 (Supporting Customers in Meeting Security Responsibilities). Maintaining and refining your security approach over time is particularly vital in a cloud environment.

Security Goals

You should adjust your security approach to align with cloud-native principles, leveraging managed services for common challenges.

• maximize the shared responsibility model, using serverless and PaaS, while minimizing the use of IaaS when feasible
• develop a clear understanding of your responsibilities, as well as those that can be shared with your cloud provider
• utilize managed services for recognized solutions
• identify cloud-native alternatives to conventional tools and processes
• do not choose a cloud service solely based on its availability within your platform if it does not meet your requirements
• reference the lift-and-shift guidance when unable to employ a cloud-native method

Contextual Overview

Utilizing a cloud platform as if it were merely another data center frequently leads to breaches. It is essential to shift your security perspective towards a cloud-native strategy, utilizing managed services for common needs, such as hosting static websites, conducting security monitoring, and implementing access controls including for network traffic.

In platforms with extensive service offerings or variations in service quality and security features, consider employing technical controls to restrict the use of certain services. Ensure the process for enabling new services remains straightforward, preventing users from resorting to unmanaged options, known as shadow IT.

Further Reading

• Guidance on Lift and Shift

Security Goals

Access to your cloud platform should always mandate robust authentication for all users, including your developers, customer administrators, and finance personnel accessing billing information:

• implement single sign-on (SSO) to streamline user account management
• apply modern authentication best practices, such as blocking common passwords, enforcing multi-factor authentication (MFA), ensuring individual identity use, and conducting security monitoring for authentication activities and privilege escalations
• integrate your cloud platform’s authentication process with your onboarding/offboarding procedures
• ensure external users also go through equally rigorous authentication processes
• prioritize the security of administrator accounts
• limit identities with extensive permissions to emergency access scenarios only, as detailed in emergency accesses
• keep user contact information updated for incident response purposes

Security Goals

Confidence in the effective authentication of service identities is crucial for proper access control implementation.

• employ your cloud provider’s service identity features rather than relying on user identities for workloads or automation
• assign distinct service identities for each use case, such as individual microservices, components, or admin functions
• ensure service identity credentials are high-entropy cryptographic secrets instead of simple passwords
• allow your cloud provider to manage the credentials for service identities
• favor managed integrations for connecting your cloud platform with external services, rather than handling authentication directly

Context Overview

Workloads and automation require authentication just like users. Historically, some workloads impersonated a user, including their username and password in the application, limiting MFA application and complicating security monitoring. A dedicated service identity allows for enhanced authentication and provides better context for actions undertaken by the workload.

Using unique service identities for each logical component ensures limited access to only necessary data and services, improving observability efforts. For instance, each microservice should have its own identity, and similarly, every automation task should utilize a distinct service identity.

Favor your cloud provider’s service identity mechanisms for access controls, avoiding primitive methods like API keys or passwords where possible. If necessary, protect such API keys or passwords with secure secrets management as described in action 11. Safeguard Secrets Appropriately.

Your cloud platform may require integration with other cloud services, like code repositories or analytics services. Whenever feasible, opt for managed or brokered integrations via your cloud provider rather than rely on long-term secret authentication.

Security Goals

Establish detailed access controls so that both user and service identities can only access the information and services they require, and only when needed.

• ensure your access control configurations are understandable and assessable
• apply the principle of least privilege to your access controls
• utilize ‘just in time’ admin privileges to lower the standing privileges for your administrative users
• assign permissions to groups of users, rather than individuals
• regularly detect and eliminate unused or unnecessary permissions
• use workspaces to streamline your access control settings
• restrict access to sensitive data and services to customer administrators and automated processes only
• ensure visibility of all external data sharing, modifying policies as needed to meet expectations

Detailed access control principles can be found in the NCSC’s secure system administration guidance.

Context Overview

The principle of least privilege dictates that identities should only have access to the data and services they specifically need. This may require limiting more powerful identities to ‘just in time’ access—guidance on this can be found in our secure system administration guidance.

Initiate access control configurations with simplistic, easily validated settings, leveraging tools to fine-tune as required. Make certain teams possess permissions adequate to perform their roles without granting unrestricted access. Check that your access control aligns with your needs, as emphasized in action 13. Maintain Security Over Time, and harness automation for routine access control verification as outlined in action 5. Use Automation to Enforce Security.

Managing external data sharing is key to avert accidental external disclosure of data and services which could occur from publicly accessible data buckets or sharing resources with partnerships. A blanket prohibition might push users toward shadow IT solutions; a more practical strategy should be adopted.

Further Reading

• Lateral Movement Prevention
• Issues With Resource Sharing
• Security Benefits of Collaborative Cloud Tools

Security Goals

Your security strategy should predominantly rely on automation. Utilise a range of security automation processes to detect, alert, or block unwanted changes, including:

• setting up guardrails to hinder undesirable modifications
• deploying autonomous checks to prevent, detect, alert on, and remediate issues
• employing infrastructure as code for all non-experimental deployments
• conducting automated analyses to assess the correctness and security of code and configurations prior to deployment

Context Overview

Leverage the guardrails provided by your cloud provider and any checks you implement yourself to manage the bulk of your security operations. Maintain low false positive rates and clear communication for policies that take direct actions. If certain actions assume a high false positive rate, consider issuing alerts and investigating before proceeding.

Utilize your cloud provider’s native guardrails for preemptive changes, such as securing data storage, and employ automation for infrequently seen configurations that merit alerting but do not require blocking (e.g., organizational restructuring as discussed in action 6. Establish an organisational structure).

Trigger alerts when resources deviate from your organization’s policies, such as when untagged resources are created, detailing this in action 9. Establish Observability. Automation may be useful for removing resources that remain out of compliance for an extended period.

Prefer native services from your cloud provider for automated code and configuration analysis over third-party options, which can improve robustness against attacks and facilitate intra-defense during analysis. The analysis features are part of your software supply chain security framework.

Security Goals

The architecture of your organization’s cloud resources, inclusive of workspaces, will significantly affect access management.

• organize your structure intuitively to define resource placement and authorized access
• ensure your organizational design secures vital workspaces, particularly production environments
• integrate guardrails consistently within your organizational structure
• utilize automation for continual management of your organizational framework
• consider which security controls are appropriate for either the entire organization or specific sections

Context Overview

Every organization is unique. Therefore, determining the most intuitive structure for your users is essential. The aim is to simplify resource access while ensuring security; for instance, keeping billing separated from engineering resources, internet-facing services distinct from internal applications, or production zones separate from testing areas. Consider variation in workload threat profiles or regulatory conditions that might necessitate a different management approach.

Organizational structures may evolve over time, especially during mergers or acquisitions. Assess whether relocating existing workspaces or establishing new setups with infrastructure as code is preferable while bearing in mind migration tools provided by your cloud provider. Aligning with your provider’s approach enhances effectiveness with its tools.

Security controls may generally apply to the entire organization or specific segments, based on achieving desired outcomes. Broadly applicable monitoring should extend throughout the organization, while stricter controls may be enforced in sensitive areas.

Listen to user feedback; if resource discovery proves difficult or access control raises complications, revising the organizational structure may be necessary.

Security Goals

Workspaces are vital for managing resources and controlling access within cloud platforms. A balance must be struck between creating sufficiently detailed workspaces and the potential confusion caused by excessive numbers. Workspaces should be employed effectively throughout their lifecycle.

• facilitate the self-service and straightforward creation of new workspaces
• apply technical controls (like guardrails) to ensure secure default configuration from sales onboarding
• annotate workspaces to enhance monitoring of access controls, such as data sensitivity
• annotate workspaces designated for external services or data sharing
• limit each workspace’s resources to a singular project, product, or component while balancing security with usability
• identify and remove unused workspaces
• restrict access to sensitive workspaces to only administrators and automated operations
• ensure infrastructure as code is consistently used for deployments in sensitive workspaces

Context Overview

Workspaces exemplify logical separation. Workspace creation must be straightforward as it discourages users from creating resources in inappropriate areas. Each new workspace should initiate with a sensible, secure default setup, such as enabling guardrails and security features.

Utilizing workspaces simplifies access controls, reinforcing the principle of least privilege. Be mindful of granting unnecessary permissions across workspaces that diminish separation. Excessive network connectivity between workspaces can compromise security; adhere to best practices for maintaining clear separations.

Workspaces that handle sensitive information or external services must be appropriately annotated. Monitoring and control can then be heightened through these annotations, either by directly tagging workspaces or by maintaining a written record. Integrate these tags with automated security controls for alerts on unauthorized external sharing.

Testing and experimental workspaces may incur fewer restrictions but should still be equipped to limit their impact on other, more sensitive environments. Watch for signs that these test instances start accepting sensitive workloads over time.

Sensitive workspaces should have deployments strictly noted via infrastructure as code, barring manual access from non-administrators. This enhances predictability and minimizes unforeseen outages while ensuring access during emergencies is treated with utmost care.

Security Goals

As cloud platforms are fundamentally networked infrastructures, it is essential to protect networked services from both external and internal threats.

• control access between services to ensure each service can only reach what it needs
• manage interaction with untrusted networks (including the internet) for both inbound and outbound communications
• implement defenses against common network protocol threats, especially from external sources
• replace outdated management protocols or secure them with modern authentication techniques, treating them as high-risk access points

Context Overview

Network security in cloud environments often pivots between micro-segmentation and zero trust. Micro-segmentation employs numerous small networks for traditional access restrictions, while zero trust relies on identity-based access controls at the application layer. Whichever strategy you adopt, applying the principle of least privilege to service access is vital, as elaborated in action 4. Implement Access Controls.

Protecting networked services requires you to safeguard various attack vectors; some attacks necessitate defensive programming at the application tier, while others are managed lower down. Employ services from your cloud provider designed to mitigate common threats such as denial-of-service or abnormal request behaviors.

Legacy management protocols like RDP and SSH risk exposing your cloud environment due to inadequate modern authentication support and widespread privilege advantages. Where necessary, these should be replaced by cloud-native solutions for better monitoring and control.

In cases where legacy management protocols remain, protect them from untrusted networks (such as the internet), preferably by utilizing an administration proxy service from your cloud provider. If this is impractical, traditional protection methods such as VPNs can be employed. Regardless, although utilizing these protocols should be treated as high-risk actions.

Further Reading

• Core Principles of Zero Trust Architecture
• Employing TLS for Data Protection
• Principles of Cybersecurity Design

Security Goals

Building and maintaining clear visibility over your cloud resources, their configurations, and monitoring for potential issues is essential for effective incident management.

• ensure you can view and track a complete inventory of your cloud resources and their configurations over time
• utilize resource tagging to handle resource metadata effectively
• establish a systematic approach for collecting, aggregating, and retaining activity logs for security purposes
• make certain that security activity logs cannot be disabled, modified, or deleted and that access to them is restricted to necessary personnel
• develop a mechanism for ongoing security monitoring within the platform

Context Overview

Resource tagging remains a popular method for maintaining metadata such as owners, project affiliation, and data sensitivity, providing a foundation for problem exploration and resource decommissioning. Automation should be employed to issue alerts for improper tagging situations as explained in action 5. Use Automation to Enforce Security. This enhancement links tags to automated evaluations, ensuring their values are accurate.

Activity logs are crucial for diverse reasons, and it’s vital to distinguish between operational logs and those intended for security. Operations logs need not have stringent protections as their utility is lower compared to security logs.

Security logs are crucial for investigating incident causes, encompassing raw data necessary for security evaluations, including activity logs from your cloud provider and your applications. Ensure the capability to synthesize all relevant logs for any given resource, irrespective of origin.

Maintain logs for sufficient time to respond effectively during incidents, with a minimum retention period of six months, taking into account storage limitations and the significance of various data types.

Your security monitoring framework must include platform alterations, ongoing usage surveillance, event reporting from your cloud provider, and pinpointing actions back to specific identities. Built-in security monitoring functionality from your cloud vendor will offer data not visible through other means, making it a more robust option compared to solely relying on activity logs. Refer to your provider for the most impactful log types.

For additional insights, consult Transaction Monitoring for Online Services.

Further Reading

• Introduction to Logging for Security
• Clarifying Essential Log Requirements
• Asset Management Framework
• Strategies for Logging and Monitoring

Security Goals

Crafting a response plan for incidents is vital for robust cybersecurity. Incorporate your cloud platform into your incident response strategy.

• ensure you receive and respond to alerts from your cloud provider
• provide accurate emergency contact information to your cloud provider
• confirm backup systems are established for critical data and ‘infrastructure as code’ documents
• pre-establish an account recovery protocol with your cloud provider
• define your incident management goals and how to effectively achieve those objectives within the cloud
• clarify the actions you need to undertake, those your cloud provider will handle, and what instructions you should provide to them

For detailed guidance on incident response planning, see our Incident Management Guidelines.

Context Overview

Your cloud provider is ideally positioned to detect common problems, configuration errors, and attacks. They must promptly inform you when you are affected, and you should have a plan in place for remediating the issue. This encompasses automation-driven alerts as well as manual interventions. Ensure emergency contact details for your cloud provider are current and utilize groups (like a shared mailbox) instead of relying on individual contact points.

Your incident management objectives may differ across cloud environments. For example, you may prioritize forensic detail collection to identify an incident’s root cause or focus on expediting recovery through total environment reset via infrastructure as code. It’s imperative to pre-plan these objectives and document them in suitable playbooks as per our guidance on Incident Management.

Additionally, formulate a disaster recovery blueprint, ensuring recovery mechanisms align with your critical data backups and infrastructure code documents. It is crucial to periodically validate that your backups are recoverable and intact.

Further Reading

• 10 Steps Towards Cybersecurity
• Creating Effective Cyber Exercises

Security Goals

Cloud platforms often manage various secrets, including database passwords, API keys, and intuitive access credentials. A continually robust approach to protecting these secrets is essential, taking full advantage of the cloud’s provided secrets management features.

• minimize secret usage when possible, opting for managed integrations
• establish a clear, documented secrets management process following your cloud provider’s recommendations
• prefer a secrets management tool provided by your cloud supplier
• develop a consistent process for updating secrets and utilize that functionality
• implement strong security monitoring to detect anomalies concerning secrets
• set up alerts for secret disclosures, including cloud credentials, triggering incident response scenarios

Context Overview

Cloud platforms typically feature various secrets management functionalities. Whenever feasible, opt for a managed service designed for secure secret storage and access control, simplifying secret upkeep. Adhere to your cloud provider’s guidelines; the secrets should be safeguarded using the cloud provider’s key management service, as outlined in our guidance on Securing Key Management in the Cloud.

Monitoring secret access must prioritize detection of irregular behaviors. This includes any automated process accessing a secret typically reserved for a human user or repeated access to numerous secrets by the same identity. Responses to suspicious activities should involve changing the compromised secret and invalidating the prior version.

Security Goals

According to Principle 14: Secure Use of the Service, the cloud platform should be engineered to be inherently secure, facilitating your security obligations. Be it requiring your cloud provider to manage security or taking on that responsibility via guardrails and automation, assurance that your cloud data is adequately protected is paramount.

• ensure data protection in transit using your cloud provider’s safeguards
• secure data that’s held at rest properly
• utilize services equipped with appropriate separation technologies
• oversee your cloud provider’s access to your data
• verify that the physical locations of your data storage and processing match your standards
• limit data storage and processing in the cloud strictly to necessary intervals, employing retention protocols to facilitate timely deletion

Context Overview

Confidence in the encryption of all your cloud data during both transit and rest is crucial, as emphasized in our guidance regarding Key Management in the Cloud. Your cloud provider might offer built-in data protection measures for transit and rest automatically, or you may need to activate these through automation as detailed in action 5. Use Automation to Enforce Security. Refer to Cloud Security Principle 2.3 for more encryption details.

Effective separation technologies must protect each workload from interfering activity on the cloud platform. This includes logical divisions, networking, and storage separation types as discussed in our Guidelines on Separation Technologies. Aim for strong service separation to protect your workloads from those of other clients.

While you should avoid backdoor designs towards your cloud provider, managing their access to your data remains vital. All provider access to raw or derived data (like logs or machine-learning models) should ideally receive explicit, time-limited permissions, alongside detailed audit trails. Expect this to necessitate configuration adjustments on your part. Be aware that your provider might utilize your data for machine learning unless you opt out.

Understand where your data resides, who can access it, and any legal ramifications thereof. Set specific guardrails to ensure compliance with requirements pertaining to:

• locations for data storage, processing, and management
• legal jurisdictions applicable to your data
• rights available to your cloud provider concerning your data
• conditions for potential data access without your consent
• implications of your data protection approach on compliance with UK laws

Data breaches often arise from retaining data no longer needed, amplifying compromise impacts. Proactively minimize cloud-stored data that isn’t necessary and implement retention policies to remove data immediately post-requirement.

Security Goals

Once the cloud platform is configured to satisfy your criteria, it’s essential to uphold its security consistently, adapting to platform advancements, industry trends, and evolving threat models. This should include:

• periodic automated assessments confirming configuration accuracy
• regular audits ensuring your security setup remains effective
• ongoing evaluation of platform architecture and controls for continual improvement
• developing and refining best practices and schemes to resolve common challenges
• staying informed about new features, capabilities, and best practices from your cloud provider
• incorporating the configuration of your cloud platform into your penetration testing protocols
• communicating significant changes to your staff (including customer administrators)

Context Overview

Due to their complexity, cloud platforms necessitate a commitment to maintaining accurate configurations over time. This monitoring should include ongoing collection of activity logs that can be effectively queried for security-related inquiries. For guidance on addressing security-centric questions, see the NCSC blog entry on Essential Logging Practices. Additionally, verify that your security measures respond appropriately to significant events, such as emergency accesses, through routine testing.

Confirm your settings suit your needs, ensuring your organizational structure enables effective access control management, as mentioned in action 6. Create an Organizational Framework. Identify workspaces missing vital security features that newly established workspaces would typically include and apply those enhancements as feasible.

Consider how security guardrails will change as time goes on. With frequent guardrail updates, ensure that older resources align with any new capabilities. If not, employ automation to pinpoint and remediate these outdated resources as necessary.

When conducting penetration tests on applications built on the cloud, pay attention to poor configurations, a frequent cause of cloud-associated data breaches. Usually, such configurations are straightforward to discover during tests. Note the limited value in executing penetration tests against the cloud service itself, as restrictions imposed by the provider’s service agreement may apply.

Cloud services constantly evolve and improve, making it easy to overlook important new security features and advancements; dedicating time to keeping abreast of these developments and evaluating how to integrate them into your security framework is vital.

Further Reading

• Steps for Effective Cyber Exercises