A Zero Trust strategy governs access to business services and data through explicit, least-privilege decisions that are reassessed as risk and context change. Cloud platforms provide many of the capabilities needed to implement it, including identity and access management, isolation between environments, encryption, policy enforcement and logging. Under the shared responsibility model, the provider secures the platform itself, and the organisation decides how those capabilities are configured and governed. Those decisions should follow business priorities, with the strongest controls applied where unauthorised access would cause the greatest harm.
Protecting administrative and service access
Administrative identities can change other controls. The people and automated processes that hold those permissions can open network paths, alter logging or grant access across environments, so a compromised administrative identity can reach well beyond its owner's role. Protecting them is a priority alongside access to sensitive data, with the weight given to each depending on the business and the permissions involved.
Privileged access should be granted for a defined task and a limited period, with multi-factor authentication for human administrators. High-impact changes should require independent approval. Dedicated emergency administrator identities should provide access if normal administration fails, with their use monitored and reviewed and their availability tested. Services that connect to one another automatically should receive only the permissions they need, for a limited time.
Boundaries that limit reach
Separate accounts or subscriptions can limit the spread of an incident when cross-boundary access and shared dependencies are tightly governed. Giving a service its own environment is a design choice, made according to its criticality and dependencies. Each cloud platform separates environments in its own way, and the design reflects the platform in use.
Keeping production apart from development and testing reduces the paths into live systems and data, provided access between them is controlled explicitly. Within each environment, network rules should deny traffic by default and permit defined paths between named services. Those paths rest on evidence of how each service communicates and what access it needs, which a discovery exercise establishes. A permitted network path provides connectivity. Access to the service still requires authentication and authorisation, with permissions reassessed when the user, device or circumstances change.
Central guardrails under continuous testing
Central guardrails enforce common requirements within a defined scope. They can restrict which regions may be used, protect logging configuration and require encryption for data at rest and in transit. Their reach differs by platform, and each platform documents what its guardrails do not cover. Leadership needs evidence of their coverage, significant exceptions and any changes that weaken enforcement. Defining guardrails in a form that can be reviewed and tested lets the organisation apply them consistently across every cloud platform it uses.
Keeping the design true over time
A cloud estate can change daily. Each new integration, supplier connection or platform update can widen access that was precisely defined, and the effect can accumulate unless each change is checked. Changes to access and network rules should be reviewed against the approved target design before they are made, and access reassessed as services and risks change.
Protected logs, policy test results and records of approved exceptions give leadership evidence of how access is governed and where controls need attention. Monitoring for gaps in logging, policies that no longer match the approved design, and unauthorised changes helps establish whether the design continues to operate as intended.
What the board should expect to see
Oversight of Zero Trust in the cloud rests on a few questions with evidenced answers.
- How is privileged access to the cloud estate limited and monitored?
- Which critical services sit in separate environments, and how is access across their boundaries governed?
- What do the central guardrails cover, and who accepted any significant exceptions?
- What evidence shows changes to access are checked against the approved design?
- Do our controls limit unauthorised access to critical services, and how do we know?
- Which material gaps require investment or explicit risk acceptance?
Continuous governance at scale shows centralised guardrails and a controlled network design applied to a media group's cloud estate across three countries. A Cloud Security Governance Review establishes whether your cloud governance operates as designed.
References
- National Institute of Standards and Technology, Special Publication 800-207, Zero Trust Architecture, August 2020.
- Amazon Web Services, Zero Trust on AWS.
- Amazon Web Services, AWS Organizations service control policies.
- Microsoft, Azure Policy overview.
- Amazon Web Services, Shared Responsibility Model.
- Microsoft, Shared responsibility in the cloud.