The S3 Bucket That Made Headlines
A startup made the news—and not in a good way. A misconfigured S3 bucket exposed millions of customer records. The fix took 5 minutes. The damage took years to repair. The bucket had been public since deployment. Nobody checked.
Cloud infrastructure is powerful but unforgiving. Misconfiguration is the #1 cause of cloud breaches. Unlike on-premises systems where mistakes are hidden behind a firewall, cloud mistakes are exposed to the internet instantly.
This guide covers cloud security essentials for AWS, GCP, and Azure—the configurations that prevent the breaches you read about in the news.
The Shared Responsibility Model
AWS/GCP/Azure secure the cloud. You secure what you put IN the cloud. Misconfigured services, excessive permissions, and exposed data are your responsibility—not theirs.
Identity and Access Management
The Foundation
IAM misconfigurations are the most common cloud security failure:
- Principle of Least Privilege — Users and services get minimum permissions needed
- No Root/Owner Account Usage — Root accounts for emergencies only, with MFA
- MFA Everywhere — All human accounts, especially privileged ones
- Service Accounts — Dedicated accounts for services, not shared credentials
- Regular Access Reviews — Quarterly review of who has what access
IAM Do's:
- Use IAM roles, not long-lived credentials
- Enable CloudTrail/Activity Logs
- Implement SCPs/Organization policies
- Use groups/roles, not direct user permissions
- Rotate credentials regularly
IAM Don'ts:
- Give admin access by default
- Use root account for daily operations
- Share credentials between people
- Leave unused accounts active
- Embed credentials in code
Storage Security
S3/GCS/Blob Storage
- Default Private — No public buckets unless absolutely necessary
- Block Public Access — Enable account-level block public access
- Encryption — Enable server-side encryption (SSE-S3/SSE-KMS minimum)
- Access Logging — Enable access logs for sensitive buckets
- Versioning — Enable versioning for critical data (ransomware protection)
- Lifecycle Policies — Automatically delete/archive old data
Public S3 buckets cause more breaches than any other cloud misconfiguration. Enable "Block Public Access" at the account level. If you need a public bucket (rare), it should require explicit exception and review.
Database Security
- No Public Endpoints — Databases should not be internet-accessible
- Encryption at Rest — Enable for all database instances
- Encryption in Transit — Require TLS for all connections
- Authentication — Use IAM database authentication where possible
- Automated Backups — Enable with appropriate retention
- Security Groups — Restrict to specific IP ranges/security groups
Network Security
VPC/Network Configuration
- Private Subnets — Databases and internal services in private subnets
- Security Groups — Restrictive rules, specific ports and sources
- No 0.0.0.0/0 Ingress — Avoid open-to-internet rules except load balancers
- VPC Flow Logs — Enable for traffic visibility and forensics
- NAT Gateways — For private subnet internet access (outbound only)
- Network ACLs — Additional layer of network filtering
Compute Security
EC2/VM Security
- No SSH Keys in Code — Use Systems Manager Session Manager instead
- IMDSv2 — Require IMDSv2 to prevent SSRF credential theft
- Patching — Automated patching or patch management process
- Hardened AMIs — Start from secure base images
- No Long-Running Instances — Treat instances as disposable
Containers (EKS/GKE/AKS)
- Image Scanning — Scan container images for vulnerabilities
- Non-Root Containers — Run containers as non-root user
- Pod Security — Enable Pod Security Admission/Standards
- Network Policies — Restrict pod-to-pod communication
- Secrets Management — Use external secrets, not Kubernetes secrets
Serverless (Lambda/Functions)
- Least Privilege Roles — Functions should have minimal permissions
- No Secrets in Environment Variables — Use Secrets Manager
- VPC When Needed — If accessing VPC resources, configure properly
- Concurrency Limits — Prevent runaway execution
Logging and Monitoring
- CloudTrail/Activity Logs — Enable for all regions, all events
- Log Centralization — Send logs to central location (CloudWatch, SIEM)
- Log Retention — Retain for at least 90 days (SOC 2 requirement)
- Alerting — Alerts on suspicious activity (root login, new admin)
- GuardDuty/Security Command Center — Enable threat detection services
Average time to detect cloud breach: 277 days (IBM). Enable cloud-native threat detection (GuardDuty, Security Command Center, Defender). These services catch misconfigurations and threats you'd otherwise miss.
Secrets Management
- No Secrets in Code — Use Secrets Manager, Parameter Store, or Vault
- Rotation — Automate credential rotation where possible
- Access Control — Restrict who/what can access secrets
- Audit Logging — Log all secret access
- Environment-Specific — Separate secrets per environment
Cloud Security Checklist
Identity
MFA on all accounts. No root account usage. Least privilege. Regular access reviews.
Storage
Block public access by default. Encryption enabled. Access logging on sensitive buckets.
Network
Private subnets for databases. Security groups restrictive. VPC flow logs enabled.
Compute
No SSH keys in code. Patching automated. Container scanning. Least privilege roles.
Logging
CloudTrail enabled all regions. Logs centralized. Threat detection enabled.
Secrets
No secrets in code. Using managed secrets service. Rotation automated.
Quick Start: Your First Week
Day 1: Block Public S3
Enable 'Block Public Access' at the account level. Check for existing public buckets.
Day 2: Audit IAM
List all users. Check for MFA. Identify unused accounts and excessive permissions.
Day 3: Enable Logging
Ensure CloudTrail/Activity Logs are enabled for all regions. Set up log retention.
Day 4: Network Review
Review security groups. Look for 0.0.0.0/0 rules. Verify databases aren't public.
Day 5-7: Enable Detection
Turn on GuardDuty/Security Command Center. Configure alerts for critical events.
Next Steps
Cloud security isn't about checking boxes—it's about understanding the shared responsibility model and configuring your environment correctly. The cloud provider secures their infrastructure; you secure your configuration.
Start with the big risks: public storage, excessive IAM permissions, missing logging. These are the misconfigurations that cause breaches. Fix them first.
Securing your cloud environment? vCISO Lite helps you track cloud security controls, monitor configuration compliance, and demonstrate cloud security posture to customers and auditors.