Cloud Hardening
Cloud environments introduced a fundamentally different security model. In a traditional data center, you control the physical hardware, the network, and the OS. In the cloud, you share that responsibility with the provider. Understanding where the provider’s responsibility ends and yours begins, the Shared Responsibility Model, is the starting point for everything else. The biggest difference between cloud security failures and traditional ones? Most cloud breaches aren’t sophisticated attacks. They’re misconfigurations: an S3 bucket left public, an IAM role with* permissions, a security group with 0.0.0.0/0 on port 22, a root account with no MFA. The tools attackers use to find these things are the same ones you can use to find and fix them first.
The Shared Responsibility Model
Before hardening anything, understand what you’re responsible for:
“The provider secures the cloud, you secure what’s in the cloud.” In practice, most cloud breaches fall squarely in your column.
Identity and Access Management (IAM)
IAM is where most cloud security starts - and where most cloud breaches originate.AWS IAM
Principles to Enforce
No root account usage for daily work:- Enable MFA on the root account immediately
- Create individual IAM users or use SSO
- Never generate root access keys - if they exist, delete them
- Use root only for tasks that explicitly require it (billing, account closure)
- EC2 instances should use IAM roles to access AWS services - not access keys baked into config files
- Lambda functions should use execution roles with minimal permissions
- If you must use access keys (CI/CD, external systems), rotate them regularly and use short-lived credentials where possible
Azure RBAC
GCP IAM
Storage Security
Publicly accessible storage buckets containing sensitive data is one of the most commonly exploited cloud misconfigurations.AWS S3
Azure Blob Storage
Compute Security
Security Groups and Firewall Rules
The most common compute misconfiguration: security groups that allow0.0.0.0/0 on SSH, RDP, or other management ports.
Instance Metadata Service (IMDS)
The instance metadata service is a common target for SSRF attacks - an attacker who can make the instance make HTTP requests to169.254.169.254 can steal instance credentials.
Network Controls in the Cloud
AWS VPC
- Separate public, private, and database subnets
- Put internet-facing resources (load balancers) in public subnets, application servers in private
- Databases should never be in public subnets
- Use PrivateLink or VPC Endpoints for AWS service access - keeps traffic off the public internet
- Enable VPC Flow Logs - essential for network forensics and anomaly detection
Security Group Best Practices
Logging and Monitoring
Without logging, you’re flying blind. These are the foundational logging services in each major cloud:AWS CloudTrail
AWS GuardDuty
GuardDuty is AWS’s managed threat detection service - it analyzes CloudTrail, VPC Flow Logs, and DNS logs for threats. It’s low-friction and high-value:AWS Security Hub
Aggregates findings from GuardDuty, Inspector, Macie, Config, and third-party tools into a single pane:Azure Equivalents
GCP Equivalents
Encryption
Data at Rest
Data in Transit
- Enforce TLS on all endpoints - no HTTP
- Use ACM (AWS Certificate Manager), Azure Key Vault, or GCP Certificate Manager for certificate management
- Set minimum TLS version to 1.2, prefer 1.3
- Disable weak cipher suites on load balancers and API gateways
Posture Management and Scanning Tools
These tools continuously scan your cloud environment for misconfigurations:CSPM (Cloud Security Posture Management)
Quick Audit with Prowler
Container and Kubernetes Security
If you’re running containers in the cloud, they need their own hardening layer:- Enable RBAC - restrict what service accounts can do
- Use namespaces to isolate workloads
- Apply PodSecurity standards - prevent privileged containers, host namespace usage
- Enable audit logging on the API server
- Use network policies to restrict pod-to-pod communication
- Never run containers as root unless absolutely necessary
- Scan images in CI/CD before they reach production
CI/CD and Secrets Management
Code pipelines that have cloud credentials are extremely high-value targets:- AWS Secrets Manager / Parameter Store - managed secrets with automatic rotation
- Azure Key Vault - certificate, key, and secret management
- GCP Secret Manager - similar to AWS Secrets Manager
- HashiCorp Vault - open-source, cloud-agnostic secrets management (popular in multi-cloud)
Quick Win Checklist
- Enable MFA on the root/global admin account - do this first
- Delete or deactivate root access keys (AWS)
- Enable CloudTrail / Activity Logs / Cloud Audit Logs in all regions
- Enable GuardDuty / Defender for Cloud / Security Command Center
- Block public access to all S3 buckets / Blob storage at account level
- Audit security groups - remove 0.0.0.0/0 on SSH and RDP
- Enable VPC Flow Logs
- Enforce EBS/disk encryption by default
- Review IAM roles/policies - remove wildcard permissions
- Run Prowler or ScoutSuite against your environment and fix Level 1 findings
- Enable automatic secret rotation where supported
- Scan container images for known vulnerabilities in CI/CD
Reference
- Prowler - Open-source cloud security scanner
- ScoutSuite - Multi-cloud auditing
- AWS Security Best Practices
- CIS AWS Foundations Benchmark
- GCP Security Best Practices
- Microsoft Cloud Security Benchmark
- Trivy - Container and IaC scanner
- truffleHog - Secret scanning in git history
Cloud security misconfigurations are the new open port. The tools to find them are free, the fixes are usually configuration changes, and the impact of getting it wrong is a publicly accessible S3 bucket on the front page of the news.
