3 Cloud Security Architecture

Assign cloud security responsibilities

Cloud security is shared between the provider and the customer. The provider protects the underlying cloud infrastructure; the customer remains responsible for securing the data, identities, and cloud settings they control. A sound design makes this Shared responsibility explicit and assigns an owner to every remaining control.

Understand responsibility by service model

The division of duties depends on the service and deployment model. These are typical patterns, not a substitute for reviewing the provider’s responsibility guidance for each service:

• IaaS: Customers typically manage operating systems, applications, identities, data, and virtual network controls. Providers typically manage physical facilities, hardware, and underlying infrastructure.

• PaaS: Customers typically manage data, identities, application code, and service configuration. Providers typically manage infrastructure and much of the operating system or runtime.

• SaaS: Customers typically manage data, user access, and tenant settings. Providers typically manage the application platform and underlying infrastructure.

A managed database, for example, can transfer some patching duties to the provider. Customers still need to configure access, protect data, and meet their own compliance requirements.

Set workload and account boundaries

Organize resources in a hierarchy that supports ownership, policy enforcement, and isolation. Provider terms differ: examples include AWS Organizations and accounts, Azure management groups and subscriptions, and Google Cloud organizations, folders, and projects.

Separate workloads when their environments, sensitivity, compliance obligations, ownership, or required controls differ. Keep production apart from development and testing. Where appropriate, use dedicated areas for shared security, logging, identity, or network services. Apply broad guardrails higher in the hierarchy, then give workload teams only the access they need within their own boundaries.

An Account or subscription boundary can help limit access, simplify billing, and reduce the potential scope of an incident. It does not automatically isolate every network path, identity, or shared service; design those controls explicitly through permissions, network rules, and service configuration. Avoid creating more boundaries than teams can reliably govern, and choose them according to risk and operational capacity.

Apply boundaries in practice

A company could place production and nonproduction applications in separate workload accounts or subscriptions, with centralized security monitoring in a dedicated area. Production data access would be limited to its application team and approved operators. Development would use separate test data and would not inherit production permissions. Organization-level policies could prevent prohibited configurations across both environments.

Enforce consistent secure configurations

Start with a documented baseline for each service type and environment. Apply least-privilege access, strong authentication for administrators, secure network defaults, encryption appropriate to the data, and audit logging. Disable or restrict unnecessary public access and services. Maintain software and managed-service settings, and review changes against the baseline.

Automate configuration where practical with reviewed templates, policy controls, and deployment pipelines. Automation makes approved settings repeatable and helps detect Configuration drift. Test policies before broad rollout, monitor exceptions, and give approved exceptions owners and expiration dates. Centralize security findings and logs so teams can investigate activity across boundaries.

Protect data and limit incident impact

Classify data before selecting storage and access controls. Restrict access by identity and purpose, encrypt data in transit and at rest, and manage encryption keys according to organizational needs. Keep sensitive information out of resource names, tags, and other broadly visible fields. Separate sensitive data stores or workloads when stronger access or policy boundaries are needed.

Use Network segmentation to control communication between environments, applications, and data services. Permit only necessary flows; do not treat internal cloud networks as automatically trusted. Combine segmentation with account-level separation and identity controls. Together, these layers reduce reliance on any single barrier and can limit the impact of compromised credentials or misconfiguration.

Integrate the architecture controls

A secure cloud architecture reflects each workload’s sensitivity, regulatory obligations, operational needs, and recovery requirements. It documents the provider-customer responsibility division, separates workloads according to risk, and applies repeatable configuration guardrails.

Account or subscription boundaries support isolation but must be combined with controls inside and between those boundaries. Explicit identity, network, logging, and data-protection controls help limit the scope of mistakes or compromises.

• Least privilege