Cloud Security Strategy: IAM, Network Segmentation, Encryption, and CSPM [2026]

Most cloud security breaches are not caused by sophisticated zero-day attacks. They are caused by misconfiguration: an S3 bucket left publicly accessible, an IAM role with administrator permissions attached to a compute instance, a security group with port 22 open to the world. The 2023 Verizon Data Breach Investigations Report found that misconfiguration accounted for over 80% of cloud-related data breaches. Cloud providers secure the infrastructure; you secure everything you deploy on it.

This guide covers the full cloud security strategy: the shared responsibility model, IAM architecture, network segmentation, encryption at rest and in transit, security monitoring, Cloud Security Posture Management (CSPM), and the phased roadmap for building a mature cloud security program. By the end, you will have a framework applicable across AWS, Azure, and GCP.

Cloud Security Strategy: The Shared Responsibility Model

Every major cloud provider operates on a shared responsibility model that divides security obligations between the provider and the customer. Understanding this division is the foundation of cloud security strategy — misunderstanding it is the root cause of most cloud security failures.

Provider responsibility (the cloud provider handles this):

• Physical data center security
• Network infrastructure
• Hardware and hypervisor
• Managed service engines (e.g., the RDS database engine, the Lambda runtime)

Customer responsibility (you handle this):

• Operating system patching (for IaaS services like EC2)
• Application code and dependencies
• Data encryption and key management
• Identity and access management configuration
• Network access controls (security groups, NACLs, VPC configuration)
• Backup and recovery
• Compliance configuration

The boundary shifts by service type. For IaaS (EC2, VMs): you own the OS, applications, and data. For PaaS (managed databases, container platforms): the provider manages the OS and runtime; you own the data and access controls. For SaaS: the provider owns almost everything; you own user access management and data input.

The critical insight: moving to the cloud does not reduce your security responsibilities — it shifts them. The physical security work disappears; the configuration security work remains fully yours, and it is now codified in API calls rather than physical access controls.

Identity and Access Management

IAM is the single most impactful security control in cloud environments. A correctly configured IAM posture limits the blast radius of any compromise — a breached service account can only access what it needs to access, not the entire cloud environment.

Principle of least privilege: grant the minimum permissions required for the task. Not "write access to S3" — "write access to this specific S3 bucket prefix." Not "EC2 full access" — "permission to start and stop this specific instance." Every permission beyond what is needed is a permission that can be exploited.

No root/administrator accounts in day-to-day operations: the root account (AWS), Global Administrator (Azure), or Project Owner (GCP) should be locked away with MFA and rarely used. Create role-specific accounts for all normal operations.

Roles over long-lived credentials: applications running on cloud infrastructure should use IAM roles (which issue temporary credentials automatically rotated) rather than hardcoded API keys or access key IDs. A hardcoded access key that leaks in a Git commit is permanently compromised; a temporary role credential expires within hours.

Service accounts with scoped permissions: every service should have its own identity with precisely the permissions it needs. An API service that reads from one database should not have permissions to write to other databases, delete infrastructure, or manage IAM.

Regular access reviews: quarterly reviews of who has access to what, with immediate revocation for departing employees and contractors. Stale permissions accumulate silently — a developer who changed roles six months ago may still have production database access they no longer need.

MFA enforcement: require MFA for all human identities, especially for any account with administrative permissions. Hardware security keys (YubiKey) provide stronger protection than TOTP apps, which are themselves stronger than SMS. Enforce MFA at the policy level — do not rely on individual compliance.

Network Security Architecture

Cloud network security is defined in software. The upside: you can describe it precisely, version-control it, and audit it. The downside: a single misconfigured rule can expose a service to the internet.

VPC (Virtual Private Cloud) design: deploy workloads in a VPC with explicit network isolation. Separate public-facing components (load balancers, NAT gateways) into public subnets, and backend components (application servers, databases) into private subnets with no direct internet access.

Security groups as stateful per-instance firewalls: security groups control inbound and outbound traffic at the individual resource level. Default to deny-all and add explicit allow rules. Keep rules minimal — a database server should accept connections only from the application servers, not from the entire VPC.

Network ACLs as stateless subnet-level controls: NACLs provide a second layer of network control at the subnet boundary. Use them to enforce coarse-grained isolation between VPC segments — block all traffic between the data tier subnet and the internet, regardless of what security groups say.

Zero Trust network model: do not assume that traffic from within the VPC is safe. Implement mutual TLS (mTLS) for service-to-service communication — every service must authenticate its identity to every other service it calls. Service meshes (Istio, AWS App Mesh, Linkerd) can enforce mTLS transparently.

VPN and Direct Connect for on-premises connectivity: site-to-site VPN provides encrypted tunnels over the public internet. AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect provide dedicated private circuits with higher bandwidth and more predictable latency — appropriate for workloads that require consistent connectivity to on-premises systems.

Encryption Strategy

Encryption at rest: encrypt all persistent storage. Cloud providers make this straightforward:

• AWS: S3 SSE-KMS, EBS encryption, RDS encrypted instances
• Azure: Azure Disk Encryption, Azure Blob Storage encryption, SQL Database Transparent Data Encryption
• GCP: Default encryption for all GCS objects, Cloud SQL disk encryption

For maximum control, use customer-managed encryption keys (CMEK) — keys stored in AWS KMS, Azure Key Vault, or GCP Cloud KMS that you control and can rotate or revoke. Provider-managed keys are acceptable for most workloads; CMEK is required when regulations mandate that the organization controls key lifecycle.

Encryption in transit: enforce TLS for all API calls, database connections, and inter-service communication. Reject unencrypted connections at the load balancer or application layer — do not rely on encryption being "usually configured."

For databases: require TLS connections (disable plaintext connections in the database configuration). For S3/Blob/GCS: bucket policies that deny requests that are not HTTPS. For inter-service communication: mTLS where possible.

Key management: secrets (API keys, database passwords, encryption keys, certificates) must never be hardcoded in application code, committed to version control, or stored in environment variables in production. Use dedicated secrets management services:

• AWS Secrets Manager: automatic rotation, fine-grained IAM policies, cross-account access
• Azure Key Vault: key, secret, and certificate management with HSM-backed storage
• GCP Secret Manager: simple API, IAM-based access control
• HashiCorp Vault: self-managed, multi-cloud, advanced rotation workflows

Audit secret access — every access to a secret should be logged with who accessed it and when.

Cloud Security Monitoring and Logging

Centralized audit logging: every cloud provider offers audit logging that records all API calls to the control plane:

• AWS CloudTrail: records all AWS API calls with user identity, timestamp, and source IP
• Azure Activity Log: records all resource management operations
• GCP Cloud Audit Logs: data access logs, admin activity logs, system event logs

Configure audit logs to write to an append-only storage location that the workload accounts cannot modify — a separate "security" account with restricted access prevents attackers who compromise a workload from covering their tracks by deleting logs.

Security event detection: audit logs are only useful if someone is monitoring them. Implement detection rules for high-signal events:

• IAM changes (new high-privilege roles, policy modifications, MFA disablement)
• Unusual access patterns (access from unexpected geographies, unusual access times)
• Public exposure events (S3 bucket made public, security group opened to 0.0.0.0/0)
• Secrets access (unexpected secrets reads)

AWS Security Hub, Azure Defender for Cloud, and GCP Security Command Center aggregate findings from multiple detection sources and provide prioritized alerts. For multi-cloud environments, Wiz, Lacework, and Orca Security provide unified visibility.

Cloud Security Posture Management (CSPM)

CSPM tools continuously scan your cloud environment for configuration drift — resources deployed or modified in ways that violate your security policies. The category exists because cloud environments change constantly and manual configuration review cannot keep up.

CSPM provides:

• Automated scanning against compliance frameworks (CIS Benchmarks, SOC 2, PCI-DSS, HIPAA)
• Real-time detection of high-risk configurations (public S3 buckets, unrestricted security groups, unencrypted databases)
• Inventory of all resources across accounts and regions
• Risk scoring to prioritize remediation by severity

Leading CSPM tools: Wiz (agentless, comprehensive, strong multi-cloud support), Orca Security (agentless side-scanning, no agents required), Prisma Cloud (Palo Alto's offering, broad CSPM+CWPP capabilities), Prowler (open-source, strong AWS coverage), CloudSploit (open-source, multi-cloud).

Integrate CSPM findings into your engineering workflow: route critical findings to the team that owns the affected resource via Slack or Jira, not just a security team queue. Security findings that engineers never see are findings that never get fixed.

Multi-Cloud Security Challenges

Organizations using multiple cloud providers face compounded complexity: different IAM models, different network constructs, different compliance tooling, and audit logs spread across multiple systems.

Centralized identity: federate identity from a central IdP (Okta, Azure AD, Google Workspace) to all cloud providers. Single sign-on prevents the proliferation of separate credentials per cloud, reduces the attack surface from compromised accounts, and ensures that offboarding an employee revokes access to all clouds simultaneously.

Consistent security policies across clouds: define security policies in a provider-agnostic language (Rego/OPA, HashiCorp Sentinel) and enforce them across all clouds. This prevents security controls from drifting as different teams configure different cloud accounts.

Unified monitoring: aggregate audit logs, security findings, and vulnerability data from all cloud providers into a central SIEM (Splunk, Elastic, Chronicle). Cross-cloud correlation is only possible when data from all environments is in one place.

Implementation Roadmap

Foundation (months 1-2): enable MFA for all accounts, configure IAM with least privilege, establish VPC network isolation, enable audit logging, and configure basic CSPM scanning. These controls address the most common misconfiguration patterns.

Hardening (months 2-4): implement encryption at rest for all data stores, enforce TLS for all connections, deploy secrets management for all application credentials, configure security event detection and alerting, and establish a regular access review cadence.

Advanced (months 4+): deploy CSPM tooling with compliance reporting, implement mTLS for inter-service communication, establish infrastructure-as-code scanning in CI/CD pipelines, and conduct penetration testing.

Continuous: quarterly access reviews, annual security assessment, compliance audit preparation, incident response tabletop exercises.

Cloud security is not a project with an end state — it is an operational practice that must evolve as the environment changes. The organizations that maintain strong cloud security postures are those that treat security as a continuous process, not a certification checkpoint.