Cloud Security

Cloud Security Fundamentals

Cloud platforms (AWS, Azure, GCP) give you enormous power with a few API calls — and the same ease makes misconfiguration the leading cause of cloud breaches. The overwhelming majority of cloud incidents are not sophisticated provider exploits; they are customer misconfigurations: a public storage bucket, an over-permissioned role, a leaked long-lived key. This guide covers the core concepts and the concrete controls that prevent those mistakes, framed for learning in accounts and labs you own.

The Shared Responsibility Model

The provider secures the cloud; you secure what you put in the cloud. Exactly where that line falls depends on the service model. The more managed the service, the more the provider handles — but identity, data, and access configuration are almost always yours.

Identity and Access Management (IAM)

IAM is the heart of cloud security. It governs who (users, roles, services) can do what (actions) on which resources. The guiding principle is least privilege: grant only the permissions needed, nothing more.

Core practices

1. Enable MFA on the root/owner account and never use root for daily work.
2. Prefer roles (temporary, auto-rotating credentials) over long-lived access keys.
3. Avoid wildcards — "Action": "*" and "Resource": "*" are how privilege escalation starts.
4. Scope policies to specific actions and specific resource ARNs.

Bad vs. good policy

The bad policy grants full S3 access to everything. The good policy grants only read/write on one bucket's objects.

// BAD: wildcard action and resource
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}

// GOOD: least-privilege, scoped to one bucket's objects
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-uploads/*"
  }]
}

Storage Misconfiguration

Publicly exposed object storage — S3 buckets, Azure Blob containers, GCS buckets — is the classic cloud breach. A single "make public" toggle or an overly broad bucket policy can expose customer data to the entire internet. Prevention:

1. Enable account-level Block Public Access so no bucket can be made public by accident.
2. Default to private ACLs and use signed/pre-signed URLs for temporary sharing.
3. Enable encryption at rest (SSE with KMS) on every bucket.
4. Turn on access logging and object versioning for recovery and forensics.

# Enforce Block Public Access on a bucket in YOUR account
aws s3api put-public-access-block --bucket my-app-uploads \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Audit: which buckets are readable by "everyone"?
aws s3api get-bucket-acl --bucket my-app-uploads

Network Security in the Cloud

Cloud networking mirrors on-prem concepts with provider-specific names. A VPC (Virtual Private Cloud) is your isolated network; subnets split it into public (internet-facing) and private (internal-only) zones. Security groups are stateful virtual firewalls attached to instances. Best practices: put databases and internal services in private subnets, expose only what must be public through a load balancer, and write security-group rules that allow specific ports from specific sources — never 0.0.0.0/0 on SSH or database ports.

Secrets Management

Never hardcode credentials in source code, container images, or environment files committed to git. Use a managed secrets manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) or KMS for keys, and rotate secrets on a schedule.

The metadata endpoint and SSRF

Cloud instances expose a metadata service at 169.254.169.254 that returns instance credentials. A Server-Side Request Forgery (SSRF) flaw in an app can trick it into fetching that endpoint and leaking role credentials — this was the root of several major breaches. Mitigation: enforce IMDSv2, which requires a session token (a PUT request) before metadata is served, blocking simple SSRF reads. Combine with least-privilege instance roles so leaked credentials are low-value.

Logging, Monitoring, and Detection

You cannot defend what you cannot see. Enable CloudTrail (AWS), Activity Log (Azure), or Cloud Audit Logs (GCP) to record every API call. Threat-detection services like GuardDuty analyze those logs and network flows for anomalies (credential exfiltration, crypto-mining, unusual regions). Use configuration services (AWS Config, Azure Policy) to detect config drift — a resource that no longer matches your secure baseline.

Containers and Kubernetes

Container platforms add their own security surface. Core hygiene:

1. Scan images for known vulnerabilities before deploying (Trivy, Grype, provider registry scanning).
2. No privileged pods and drop unnecessary Linux capabilities; run as non-root.
3. Apply least privilege via Kubernetes RBAC and restrict pod-to-pod traffic with NetworkPolicies.
4. Never bake secrets into images; mount them from a secret store at runtime.

CSPM and Multi-Cloud Awareness

Cloud Security Posture Management (CSPM) tools continuously scan your accounts against best-practice and compliance rules, flagging public buckets, over-permissioned roles, and unencrypted volumes. Open-source options include Prowler and ScoutSuite. Because most organizations run more than one provider, it helps to know the equivalent terms:

Practice Exercises

1. In your own free-tier account, enable MFA on the root user and audit all IAM policies for wildcard actions or resources.
2. Create a test bucket, then enforce account-level Block Public Access and verify with get-bucket-acl that it is no longer public.
3. Enable CloudTrail (or the Azure/GCP equivalent) and locate the log entry for an action you just performed.
4. Run Prowler or ScoutSuite against your account and triage the top three findings.
5. Store a value in a secrets manager, rotate it, and update an app to read it at runtime instead of from a hardcoded string.
6. Walk the flaws.cloud challenge or deploy CloudGoat into your own account to see how a public bucket and over-permissioned role chain into escalation.