Skip to main content

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)
Least privilege on all IAM entities:
Use roles, not long-lived keys:
  • 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 allow 0.0.0.0/0 on SSH, RDP, or other management ports.
Fix: Use AWS Systems Manager Session Manager, Azure Bastion, or GCP IAP Tunnel instead of exposing SSH/RDP at all. These provide audited, authenticated access without opening any inbound 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 to 169.254.169.254 can steal instance credentials.

Network Controls in the Cloud

AWS VPC

VPC design principles:
  • 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:
Key Kubernetes hardening points:
  • 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:
For secrets management:
  • 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)
Scan your code and git history for leaked secrets:

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


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.