Securing Data in Cloud Computing: Encryption, Access Control, and Compliance
The Capital One data breach of 2019 cost the company over $300 million in fines, remediation, and legal settlements. The breach affected 100 million customers. The cause was not a sophisticated zero-day attack or a nation-state intrusion. A former AWS engineer exploited a misconfigured web application firewall to access an EC2 instance metadata service endpoint and extract temporary IAM credentials. Those credentials had excessive permissions. The attacker used them to access S3 buckets containing years of customer data.
The breach happened on AWS infrastructure that was functioning exactly as designed. AWS did nothing wrong. Capital One misconfigured their network controls and over-provisioned IAM permissions. This is the shared responsibility model in its most instructive and expensive form.
The Shared Responsibility Model in Security Terms
Cloud providers and customers divide security responsibility at the infrastructure-to-application boundary. The provider secures the underlying infrastructure; the customer secures what they deploy on it.
Shared Responsibility: Security Perspective---------------------------------------------CUSTOMER RESPONSIBLE: - Data classification and encryption keys - Identity and access management (IAM policies) - Network controls (security groups, NACLs, WAF) - Application security (code, configurations) - Operating system patches (on IaaS) - Audit logging and monitoring
PROVIDER RESPONSIBLE: - Physical facility security - Hardware (servers, storage, networking) - Hypervisor and virtualisation layer - Managed service availability - Physical network infrastructure - Provider's own IAM and access to infrastructureThe boundary shifts depending on the service model. With IaaS, the customer owns more. With PaaS and SaaS, the provider owns more. But data security — classifying what you have, controlling who can access it, and knowing when it has been accessed — always belongs to the customer.
Encryption at Rest and in Transit
Encryption is the baseline protection for data in the cloud, and it has two distinct contexts.
Encryption at rest protects data stored in cloud services — S3 buckets, EBS volumes, RDS databases, DynamoDB tables — against physical theft or unauthorised access at the storage layer. Most cloud providers encrypt data at rest by default today (AWS encrypts all S3 data at rest since 2023). The meaningful security decision is key management.
Customer-managed keys (CMK) give the customer control over the cryptographic keys. Stored in a managed key service (AWS KMS, Azure Key Vault, GCP Cloud KMS), CMKs allow the customer to rotate keys on schedule, revoke access by disabling keys, and maintain an audit trail of every key usage event. If a cloud provider receives a legal order to produce customer data, they cannot decrypt CMK-protected data because they do not hold the key.
Provider-managed keys are simpler to operate — no key management overhead — but the provider controls the encryption. For most business workloads, provider-managed encryption is sufficient. For classified data, healthcare records, or financial data under strict regulations, CMK is often required.
Encryption in transit protects data moving over networks from interception. TLS 1.2 or 1.3 should be enforced on all endpoints — load balancers, APIs, database connections, inter-service communication. This is not optional. Any endpoint accepting unencrypted HTTP in a production environment is a misconfiguration, not a design choice.
Identity and Access Management
IAM is where most serious cloud security failures originate. The Capital One breach, numerous S3 bucket exposures, and many internal privilege escalation incidents trace back to IAM misconfiguration.
The controlling principle is least privilege: every IAM entity (user, role, service account) should have exactly the permissions needed to perform its function and nothing more. This is simple to state and difficult to implement in practice, because developers instinctively grant broad permissions to avoid friction.
Practical IAM controls that matter:
Avoid long-lived credentials: IAM users with access keys that never rotate are the most common source of cloud credential exposure. When credentials are checked into a public GitHub repository (extremely common), they can be discovered within minutes by automated scanners. Use IAM roles with temporary credentials where possible. On EC2, the metadata service provides temporary role credentials automatically.
Enforce MFA on privileged accounts: Root accounts and any human user with administrative permissions should require multi-factor authentication. An email address and password alone is not sufficient protection for an account with permission to delete production databases.
Separate environments with separate accounts: Development, staging, and production environments should live in separate cloud accounts (or subscriptions on Azure). This prevents a developer credential compromised in a development environment from accessing production data.
Service control policies: At the organisation level, Service Control Policies (SCPs on AWS, Azure Policy on Azure) can enforce guardrails that no account within the organisation can override — preventing anyone from disabling CloudTrail, for example, or from creating resources in unapproved regions.
IAM Access Pattern: Least Privilege in Practice-------------------------------------------------BAD: Application IAM Role --> s3:* on * (all buckets, all actions) Risk: if app is compromised, attacker has full S3 access
GOOD: Application IAM Role --> s3:GetObject on arn:aws:s3:::my-bucket/* s3:PutObject on arn:aws:s3:::my-bucket/uploads/* Risk: compromise only exposes the specific bucket and actions neededNetwork Isolation
Cloud networking defaults — particularly in AWS — are not secure by default. An EC2 instance launched without specific configuration in a default VPC will have a public IP, be reachable from the internet, and use a default security group that allows outbound access to everything.
Network security in cloud environments requires deliberate configuration:
VPC design: Separate public and private subnets. Resources that should not be internet-accessible (databases, internal services, worker processes) belong in private subnets with no direct route to the internet. Resources that must accept public traffic (load balancers, NAT gateways) go in public subnets.
Security groups: Treat security groups as firewalls. Allow only the specific ports and source IP ranges that each resource requires. A database security group should accept connections only from the application tier’s security group, not from 0.0.0.0/0.
Private endpoints: When an application on EC2 needs to talk to S3, it does not need to traverse the public internet. VPC endpoints route traffic from your VPC directly to AWS services over AWS’s internal network, bypassing the internet entirely and reducing both latency and exposure surface.
Compliance and Audit Logging
Compliance frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001, GDPR) share a common requirement: you must know what happened to your data and be able to prove it.
Enable cloud-native audit logging everywhere. AWS CloudTrail records every API call made in an account. Azure Monitor and Activity Logs do the same. Ship these logs to a separate account with write-once storage (S3 Object Lock or Azure immutable storage) so they cannot be deleted by the account under audit.
Collect VPC flow logs to capture all network traffic metadata. Enable database query logging. Configure GuardDuty or Azure Defender to detect anomalous access patterns — unusual API calls, access from new geographies, sudden spikes in data reads that might indicate exfiltration.
Security is not a feature you add to cloud infrastructure. It is a set of configurations, policies, and monitoring systems that must be present from the first day of deployment. Retrofitting security controls onto a running cloud environment is far more expensive and risky than building with security controls in place from the start.