The Shared Responsibility Model in Practice
The cloud security concept that most confuses organisations new to cloud infrastructure: the shared responsibility model, which divides security responsibilities between the cloud provider and the cloud customer in a way that is not always intuitive. The cloud provider is responsible for security of the cloud — the physical security of data centres, the hypervisor that isolates virtual machines, the global network infrastructure, and the security of the managed services the provider operates. The customer is responsible for security in the cloud — the security of what they deploy and configure on the cloud infrastructure, including the operating systems they run on virtual machines, the applications they deploy, the data they store, the identity and access management controls they configure, and the network security groups and firewall rules they set.
The shared responsibility model misunderstanding that most commonly leads to cloud data exposure: the assumption that because the cloud provider is responsible for the infrastructure’s security, the data stored on that infrastructure is automatically protected. The S3 bucket that contains customer personal data is stored on AWS infrastructure that AWS secures against physical intrusion, hardware failure, and hypervisor attacks — but the access controls that determine who can read the bucket’s contents are the customer’s responsibility. The S3 bucket with public read access enabled by the customer is a customer configuration error, not an AWS security failure — and the data in publicly accessible cloud storage buckets has been the most common source of cloud data exposure incidents since cloud storage became widespread.
Identity and Access Management in the Cloud
The cloud security control that most consistently appears in post-incident analysis of cloud breaches as the control whose absence or misconfiguration enabled the breach: Identity and Access Management (IAM). The cloud IAM system — the policy-based access control that determines which identities (users, roles, services, and machines) can perform which actions on which cloud resources — is the primary security boundary in the cloud environment. The cloud service that can be accessed by anyone with a valid credential, regardless of the principle of least privilege, provides an attacker who obtains any valid credential with the access scope of that credential.
The cloud IAM misconfiguration that most commonly enables privilege escalation by attackers who have obtained limited initial access: the overprivileged IAM role that grants more permissions than the service or user that assumes it requires. The Lambda function that is granted full administrative access to the AWS account in order to read a single S3 bucket has been granted a permission scope that an attacker who compromises the function can use to access every resource in the account. The least privilege principle applied to cloud IAM — granting each identity only the specific permissions required for its specific function — limits the damage that a compromised identity can cause, regardless of how the compromise occurred.
Cloud Configuration and Compliance
The cloud security challenge that is unique to cloud environments relative to on-premises infrastructure: the speed and ease with which misconfigured resources can be created and the scale at which misconfigurations can accumulate across large cloud environments. The on-premises security team that reviews every firewall rule change through a change management process provides a human check on misconfigurations; the cloud team where developers can create new resources with a few API calls or console clicks without the same review process can accumulate hundreds of misconfigured resources before any of them is identified.
The cloud security posture management (CSPM) tool function that most efficiently identifies cloud misconfigurations at scale: the continuous scanning of cloud resources against a defined security standard, comparing the current state of every resource against the expected configuration and flagging deviations for remediation. The CSPM scan that identifies all publicly accessible S3 buckets, all security groups with 0.0.0.0/0 inbound rules on sensitive ports, all encryption-at-rest configurations that are not enabled, and all IAM policies that violate least privilege provides the inventory of misconfigurations that manual review cannot maintain at the scale of a large cloud environment. The CSPM finding that is automatically remediated through infrastructure-as-code is more reliably corrected than the one that requires a human operator to manually change a configuration.
Network Security in the Cloud
The cloud network security controls that most effectively protect cloud workloads from network-based attacks: the security group and network access control list (NACL) rules that restrict inbound and outbound traffic to only the protocols and ports required for legitimate communication (replacing the implicit allow-all default that exposes every port and protocol to the network), the private subnet configuration that places sensitive workloads (databases, internal services, backend systems) on subnets with no direct internet route and accessible only from specific other subnets within the VPC, and the VPC flow logs that capture metadata about all network traffic within the VPC and enable the detection of anomalous communication patterns that might indicate lateral movement or data exfiltration.
The cloud network security architecture decision that most affects the blast radius of a successful intrusion: the VPC segmentation that divides the cloud environment into isolated network segments for different workload types and sensitivity levels. The cloud environment where all workloads share a single VPC with full network visibility between them provides an attacker who compromises any workload with network access to every other workload. The environment segmented into separate VPCs for production, staging, and development, with separate VPC segments for different application tiers within production, and with explicit VPC peering and transit gateway rules for the specific cross-segment communication that is required, limits the lateral movement available to an attacker who compromises any single workload.
Cloud Security Monitoring and Incident Response
The cloud security monitoring approach that most effectively detects security incidents in cloud environments: the integration of cloud-native security services (AWS GuardDuty, Azure Defender, GCP Security Command Center) that apply machine learning to cloud service logs to detect anomalous patterns (unusual API calls, access from unexpected geographic locations, credential use from non-standard clients, data access patterns consistent with exfiltration) into a centralised SIEM that correlates cloud security findings with other security signals across the environment.
The cloud incident response capability that most differs from on-premises incident response: the forensic evidence availability and ephemeral resource challenge. The cloud environment where resources are created and destroyed dynamically may not retain the forensic evidence of an incident if the compromised instance has been terminated before analysis. The cloud incident response programme that enables forensic evidence preservation — through automated snapshot and log retention triggered by security alerts, through the configuration of enhanced logging that captures more detailed evidence than the default cloud logging, and through the automation of instance isolation that preserves the compromised instance for forensic analysis while preventing further malicious activity — maintains the forensic capability that the ephemeral nature of cloud resources would otherwise eliminate.