Cloud Security: Protecting Your AWS, Azure, and GCP Infrastructure

82% of cloud data breaches involve data stored in the cloud that was misconfigured, not hacked (IBM, 2024). The attacker didn't break encryption or exploit a zero-day — they found an S3 bucket set to public, an IAM role with admin privileges assigned to a Lambda function, or a database with no VPC and a default password. Cloud security isn't about advanced threats. It's about getting the basics right across hundreds of configuration options.

We've helped organizations migrate to and secure workloads on AWS, Azure, and GCP. This guide covers the patterns and misconfigurations we see most often — with provider-specific fixes.

1. The Shared Responsibility Model — What's Actually Your Problem

Every cloud provider operates under a shared responsibility model. They secure the infrastructure; you secure what runs on it. The split varies by service type:

Notice: IAM and data security are always your responsibility, regardless of service type. Moving to managed services reduces your surface area (no more OS patching) but doesn't eliminate your security obligations.

2. IAM — The Foundation of Cloud Security

Identity and Access Management is where cloud security starts and where most breaches originate. An overprivileged service account is the master key attackers look for.

IAM Across Providers

// ❌ BAD — "AdministratorAccess" on a Lambda
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}

// ✅ GOOD — Only the actions and resources this function needs
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:ap-south-1:123456789:table/orders"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::invoices-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": ["sqs:SendMessage"],
      "Resource": "arn:aws:sqs:ap-south-1:123456789:order-notifications"
    }
  ]
}

IAM rules that prevent 90% of issues:

• No long-lived access keys — use roles, managed identities, or workload identity
• MFA required for all human users, especially root/global admin accounts
• No "Action": "*" or "Resource": "*" in any policy
• Service accounts get the minimum permissions they need — audit quarterly
• Use AWS Organizations SCPs / Azure Management Groups / GCP Organization Policies to set guardrails
• Enable IAM Access Analyzer (AWS) / Entra ID Access Reviews (Azure) / IAM Recommender (GCP)

3. Network Security — VPCs, Security Groups, and Private Endpoints

Default cloud networking is often more open than you think. The goal: nothing is accessible from the internet unless explicitly intended.

resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # ✅ Only accept traffic from ALB
  ingress {
    from_port       = 3000
    to_port         = 3000
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  # ✅ Only allow outbound to specific destinations
  egress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # HTTPS out for APIs
  }

  egress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.database.id]
  }

  # ❌ NEVER: ingress from 0.0.0.0/0 on any port
  # ❌ NEVER: egress to 0.0.0.0/0 on all ports
}

4. Data Encryption — At Rest and In Transit

Encryption should be the default, not an opt-in. All three providers offer encryption for their managed services — the issue is that some services still default to unencrypted.

resource "aws_s3_bucket" "data" {
  bucket = "pillai-customer-data"
}

# ✅ Block ALL public access
resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# ✅ Enforce encryption with customer-managed key
resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data_key.arn
    }
    bucket_key_enabled = true  # Reduces KMS API calls and cost
  }
}

# ✅ Enforce TLS in transit
resource "aws_s3_bucket_policy" "enforce_tls" {
  bucket = aws_s3_bucket.data.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "EnforceTLS"
      Effect    = "Deny"
      Principal = "*"
      Action    = "s3:*"
      Resource  = ["${aws_s3_bucket.data.arn}/*"]
      Condition = { Bool = { "aws:SecureTransport" = "false" } }
    }]
  })
}

5. Logging and Monitoring — You Can't Protect What You Can't See

The first thing we enable on any cloud account: centralized logging. If you're compromised and don't have logs, you can't determine what was accessed, when, or by whom.

Minimum viable logging: CloudTrail (AWS) / Activity Log (Azure) / Audit Logs (GCP) enabled in all regions, stored in a separate account/project with write-once/append-only policies. S3 access logs on sensitive buckets. VPC Flow Logs on production VPCs. GuardDuty / Defender / SCC for automated threat detection. Total cost for a small-to-mid infrastructure: $50-200/month — a fraction of what a breach investigation costs. For more on building observability, see our monitoring and observability guide.

6. Top 10 Cloud Misconfigurations We Find in Audits

These aren't theoretical — we find these in real client environments. Ranked by how often we see them:

7. Cloud Security Posture Management (CSPM)

Manually checking hundreds of configuration options across dozens of services doesn't scale. CSPM tools continuously scan your cloud accounts against security benchmarks (CIS, NIST, PCI DSS).

# Install
pip install prowler

# Run full CIS AWS Foundations Benchmark
prowler aws --compliance cis_2.0_aws

# Run specific checks
prowler aws --check s3_bucket_public_access \
                    iam_root_mfa_enabled \
                    cloudtrail_multi_region_enabled

# Output as JSON for CI pipeline
prowler aws --compliance cis_2.0_aws -M json -o results/

# Exit code 1 if critical findings → use in CI
prowler aws --severity critical --status FAIL --exit-code 1

8. Compliance Frameworks Mapped to Cloud Controls

If you need to comply with SOC 2, HIPAA, PCI DSS, or GDPR, cloud providers offer compliance-mapped services. But the mapping is "this service can help you comply" — not "using this service means you are compliant."

For a deep dive into SOC 2 specifically, see our SOC 2 compliance guide for startups. For GDPR, see our data privacy and GDPR compliance guide.

9. Frequently Asked Questions