Cloud Security

A practitioner's framework for securing cloud infrastructure across AWS, GCP, and Azure. This skill covers IAM, secrets management, network security, encryption, audit logging, zero trust, and compliance - with opinionated guidance on when to use each pattern and why it matters. Designed for engineers who own the security posture of a cloud environment, not just a single service.

---

When to use this skill

Trigger this skill when the user:

• Designs or audits IAM roles, policies, or permission boundaries
• Manages secrets, API keys, or credentials in cloud environments
• Configures VPC security groups, NACLs, or network access controls
• Implements encryption at rest or in transit for cloud resources
• Sets up audit logging (CloudTrail, Cloud Audit Logs, Azure Monitor)
• Architects a zero trust or service mesh network
• Prepares for SOC 2, HIPAA, or PCI-DSS compliance
• Hardens a cloud account, project, or subscription configuration

Do NOT trigger this skill for:

• Application-layer security (SQL injection, XSS, auth flows) - use the backend-engineering skill's security reference instead
• On-premises or bare-metal infrastructure that has no cloud component

---

Key principles

1. Least privilege IAM - Every identity (human, service, CI/CD pipeline) gets only the minimum permissions required for its specific task. Never use root or owner-level credentials in automation. Scope permissions to a resource ARN or path, not *. Review and prune permissions quarterly.

2. Encrypt at rest and in transit - All data at rest uses provider-managed KMS keys (or customer-managed for regulated workloads). All data in transit uses TLS 1.2+ with no exceptions. Internal service traffic is not exempt. Certificate rotation is automated.

3. Never store secrets in code - No credentials, API keys, or tokens belong in source code, Dockerfiles, CI config, or environment variables baked into images. Secrets live in a secrets manager and are fetched at runtime. Secret scanning runs in every CI pipeline. Pre-commit hooks block high-entropy strings.

4. Defense in depth - No single control is the whole security posture. Layer network controls (VPC, security groups, NACLs), identity controls (IAM), data controls (encryption, DLP), and detection controls (audit logs, SIEM) so a failure in one layer does not compromise the system.

5. Audit everything - Every privileged action, every IAM change, every secret access, and every configuration drift must be logged to an immutable, centralized store. Logs have value only when there is alerting on anomalies and a process to act on them.

---

Core concepts

Shared responsibility model

Cloud providers secure the infrastructure of the cloud (physical hardware, hypervisor, managed service internals). You secure everything in the cloud: identity, data, network configuration, OS patching, application code, and compliance posture. Misunderstanding this boundary is the root cause of most cloud breaches.

Layer	Provider's responsibility	Your responsibility
Physical hardware	Provider	-
Hypervisor / virtualization	Provider	-
Managed service internals	Provider	Configuration and access
Network configuration (VPC, SGs)	-	You
Identity and IAM	-	You
Data encryption	Provider tooling	Your configuration and keys
OS patching (VMs)	-	You
Application code	-	You

IAM hierarchy: identity, policy, role

• Identity - who (or what) is making the request: a human user, a service account, a Lambda function, an EC2 instance, a CI/CD pipeline.
• Policy - the document that grants or denies specific actions on specific resources. Policies are attached to identities or roles.
• Role - a temporary identity assumed by a service or person. Roles issue short-lived credentials. Always prefer roles over long-lived access keys.

The evaluation order: explicit deny > service control policy (SCP/org policy) > identity-based policy > resource-based policy. A single explicit deny anywhere in the chain blocks access.

Network segmentation

Isolate workloads at multiple levels:

• Account/project level - separate AWS accounts or GCP projects per environment (prod, staging, dev) to create a hard blast-radius boundary
• VPC level - separate VPCs per environment or workload tier
• Subnet level - public subnets for load balancers only, private subnets for compute, isolated subnets for databases with no route to the internet
• Security group level - stateful rules on each resource; restrict to minimum source/port required

Encryption envelope pattern

KMS uses a two-layer encryption model: a Customer Master Key (CMK) in the cloud KMS encrypts a short-lived Data Encryption Key (DEK). The DEK encrypts the actual data. Store the encrypted DEK alongside the data. The CMK never leaves KMS. To decrypt, call KMS to decrypt the DEK, use the DEK in memory, then discard it. This pattern limits the blast radius of a key compromise and enables key rotation without re-encrypting all data.

---

Common tasks

Design IAM with least privilege

Start from the action, not the service. Ask: "What exact API calls does this identity need to make?" Then scope to specific resources.

AWS IAM policy - tightly scoped service role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSpecificS3Bucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    },
    {
      "Sid": "ReadSpecificSecret",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789:secret:my-app/db-*"
    }
  ]
}

GCP IAM - workload identity for a Cloud Run service:

# Bind a service account to a specific role on a specific resource
# gcloud run services add-iam-policy-binding my-service \
#   --member="serviceAccount:my-svc@project.iam.gserviceaccount.com" \
#   --role="roles/run.invoker"

# Grant minimal storage access - prefer predefined roles over basic roles
# gcloud projects add-iam-policy-binding PROJECT_ID \
#   --member="serviceAccount:my-svc@project.iam.gserviceaccount.com" \
#   --role="roles/storage.objectViewer" \
#   --condition="resource.name.startsWith('projects/_/buckets/my-app-bucket')"

Never use roles/owner, roles/editor, or AdministratorAccess for service accounts. Use permission boundaries on AWS to cap maximum effective permissions.

Manage secrets with Vault or AWS Secrets Manager

HashiCorp Vault - dynamic database credentials (no long-lived passwords):

# Enable the database secrets engine
path "database/config/postgres" {
  capabilities = ["create", "update"]
}

# Define a role that generates short-lived credentials
resource "vault_database_secret_backend_role" "app" {
  name    = "app-role"
  backend = vault_database_secrets_engine.db.path
  db_name = vault_database_secrets_engine_connection.postgres.name
  creation_statements = [
    "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';",
    "GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
  ]
  default_ttl = "1h"
  max_ttl     = "24h"
}

AWS Secrets Manager - fetch at runtime (never at build time):

import boto3
import json

def get_secret(secret_name: str, region: str = "us-east-1") -> dict:
    client = boto3.client("secretsmanager", region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])

# Usage: fetch on startup, cache in memory, never log
db_config = get_secret("prod/my-app/database")

Enable automatic rotation in AWS Secrets Manager for RDS credentials. Set a rotation window of 30 days or fewer. Use resource-based policies to restrict which roles can call GetSecretValue.

Configure VPC security - security groups and NACLs

VPC Layout (3-tier):
  Public subnet  (10.0.1.0/24) - ALB only, ingress 443/80 from 0.0.0.0/0
  Private subnet (10.0.2.0/24) - App servers, ingress from ALB SG only
  Data subnet    (10.0.3.0/24) - RDS/ElastiCache, ingress from App SG only, no NAT

Security group rules (stateful - return traffic is automatic):

SG	Inbound rule	Source	Port
alb-sg	HTTPS	0.0.0.0/0	443
app-sg	HTTP	alb-sg (SG id)	8080
db-sg	Postgres	app-sg (SG id)	5432

NACL rules (stateless - explicit rules for both directions):

• Data subnet NACL: deny all inbound from internet (0.0.0.0/0), allow from private subnet CIDR only. Deny all outbound to internet. This is the belt to the security group's suspenders.

Security groups are the primary control. NACLs are a secondary blast-radius limiter. Never expose port 22 (SSH) or 3389 (RDP) to 0.0.0.0/0 - use SSM Session Manager or a bastion in a locked-down subnet.

Implement encryption at rest and in transit

AWS S3 bucket - enforce encryption and TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonTLS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    },
    {
      "Sid": "DenyNonEncryptedPuts",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-app-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

For RDS: enable encryption at creation (cannot be added later without snapshot restore). Use a customer-managed KMS key (CMK) for regulated workloads so you control the key policy and can audit usage separately.

Set up audit logging - CloudTrail and Cloud Audit Logs

AWS CloudTrail - organization-wide, immutable configuration:

resource "aws_cloudtrail" "org_trail" {
  name                          = "org-audit-trail"
  s3_bucket_name                = aws_s3_bucket.audit_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true  # SHA-256 digest for tamper detection
  is_organization_trail         = true  # covers all accounts in AWS Org

  event_selector {
    read_write_type           = "All"
    include_management_events = true

    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3:::"]  # all S3 data events
    }
  }

  cloud_watch_logs_group_arn = "${aws_cloudwatch_log_group.cloudtrail.arn}:*"
  cloud_watch_logs_role_arn  = aws_iam_role.cloudtrail_cw.arn
}

GCP Cloud Audit Logs - enable data access logs at org level:

# Organization-level audit config (apply via gcloud or Terraform)
auditConfigs:
  - service: allServices
    auditLogConfigs:
      - logType: ADMIN_READ
      - logType: DATA_READ
      - logType: DATA_WRITE

Critical alerts to configure: root account login (AWS), IAM policy changes, security group modifications, CloudTrail disabled, MFA disabled for privileged accounts.

Implement zero trust network - service mesh with mTLS

Zero trust assumes the network is hostile. Every service-to-service call must be authenticated and encrypted, regardless of whether it is "inside" the VPC.

Istio service mesh - enforce mTLS across the mesh:

# PeerAuthentication: require mTLS for all services in the namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # reject plaintext connections

---
# AuthorizationPolicy: service A can only call specific methods on service B
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-orders-to-payments
  namespace: production
spec:
  selector:
    matchLabels:
      app: payments-service
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/orders-service"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/charges", "/v1/refunds"]

Each service has its own SPIFFE identity (service account). The mesh enforces that only authorized callers can reach each endpoint - even if an attacker compromises the internal network, they cannot spoof a service identity.

Prepare for SOC 2 compliance - controls checklist

SOC 2 is organized around Trust Service Criteria (TSC). For a Type II audit you must demonstrate controls operated continuously over a period (typically 6-12 months).

Common Technical Controls Checklist:

Access Controls (CC6)
  [ ] MFA enforced for all human users with cloud console access
  [ ] Privileged access (root/owner) has separate credentials, used only for break-glass
  [ ] Access reviews conducted quarterly; terminated employees deprovisioned within 24h
  [ ] Service accounts use roles, not long-lived keys
  [ ] SSH/RDP access disabled in favor of SSM / IAP (Identity-Aware Proxy)

Change Management (CC8)
  [ ] All infrastructure changes via IaC (Terraform/Pulumi), not manual console
  [ ] IaC changes require peer review in PRs before apply
  [ ] Deployment pipeline enforces approvals for production changes
  [ ] Rollback procedures documented and tested

Monitoring and Alerting (CC7)
  [ ] CloudTrail / Cloud Audit Logs enabled across all regions and accounts
  [ ] Log retention >= 1 year (hot) + 7 years (cold/archived)
  [ ] Alerts on: IAM changes, SG changes, root login, failed auth spikes, CloudTrail off
  [ ] Incident response runbooks exist and are tested annually

Encryption (CC6.7)
  [ ] All data at rest encrypted (KMS CMK for regulated data)
  [ ] All data in transit uses TLS 1.2+
  [ ] Key rotation policy documented and automated
  [ ] No plaintext secrets in code, logs, or environment variables

Availability (A1)
  [ ] Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined
  [ ] Backups tested by restoring to a non-production environment quarterly
  [ ] Multi-AZ or multi-region architecture for critical services

See references/compliance-frameworks.md for SOC 2, HIPAA, and PCI-DSS controls comparison.

---

Anti-patterns

Anti-pattern	Why it's dangerous	What to do instead
Wildcard IAM policies (Action: "*", Resource: "*")	Any exploit or misconfiguration grants full account access	Scope policies to exact actions and specific resource ARNs
Long-lived access keys for service accounts	Keys can leak via logs, git history, or compromised machines; there is no expiry	Use IAM roles and instance profiles; rotate keys every 90 days if roles are impossible
Flat VPC with all resources in public subnets	Any misconfigured security group exposes databases and internal services to the internet	Three-tier subnet architecture; databases never in public subnets
Secrets hardcoded in environment variables baked into container images	Image layers persist forever; any image pull leaks the secret	Fetch secrets at runtime from a secrets manager; never bake into images
Single AWS account / GCP project for all environments	A prod incident can reach dev data; a dev mistake can delete prod resources	Separate accounts/projects per environment with SCPs to enforce boundaries
Disabling CloudTrail or audit logs to reduce cost	Audit gaps make incident investigation impossible; compliance evidence destroyed	Compress and archive logs to cheap storage (S3 Glacier); cost is negligible vs. risk

---

Gotchas

1. Service Control Policies silently block actions - An SCP at the AWS Organization level that denies an action overrides any IAM Allow in a member account. When a permission looks correct in IAM but still fails with "AccessDenied", check the SCP chain at the organization and OU level - they are often overlooked because they're managed by a separate team.

2. CloudTrail logging gap on multi-region trails - A trail configured as multi-region still won't capture events from services that are global (IAM, STS, CloudFront) unless include_global_service_events is explicitly set to true. Most IAM changes and assume-role events fall into this gap and disappear from audit logs without this flag.

3. KMS key deletion is irreversible after the waiting period - KMS imposes a 7-30 day waiting period before key deletion, but once the period expires, the key and all data encrypted with it that lacks a backup decryption path are permanently unrecoverable. Never schedule a key for deletion unless you have verified that no data encrypted with it needs to be decrypted in the future.

4. Security group rule accumulation - Security groups are additive - rules are only added, never automatically removed. Over months, groups accumulate stale rules (former services, debug ports, one-off access). A security group that looks fine has rules from two years ago that opened ports to long-deleted resources, some of which may overlap with new infrastructure in the same CIDR range.

5. Secrets in environment variables baked into container images - Setting ENV DB_PASSWORD=... in a Dockerfile bakes the secret into every image layer permanently. Anyone with docker history access or registry pull access can recover it. Secrets must be injected at container runtime from a secrets manager, never built into the image.

---

References

For deep-dive guidance on specific domains, load the relevant file from references/:

• references/compliance-frameworks.md - SOC 2, HIPAA, PCI-DSS controls comparison and evidence requirements