Cloud & Infrastructure Security Skill

The principle of least privilege is the single most impactful security control in cloud environments. Overly broad permissions are the root cause of most privilege escalation attacks.

Least Privilege Policies

# ✅ CORRECT: Minimal, resource-scoped permissions
iam_role:
  permissions:
    - s3:GetObject
    - s3:ListBucket
  resources:
    - arn:aws:s3:::my-bucket/*   # Specific bucket only

# ❌ WRONG: Wildcard permissions are a breach waiting to happen
iam_role:
  permissions:
    - s3:*
  resources:
    - "*"

Service Accounts & OIDC

Prefer short-lived federated credentials over long-lived access keys. OIDC lets services like GitHub Actions assume roles without storing any secret.

# Create an OIDC identity provider for GitHub Actions
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

MFA

# Enable MFA for privileged accounts — root and admin especially
aws iam enable-mfa-device \
  --user-name admin \
  --serial-number arn:aws:iam::123456789:mfa/admin \
  --authentication-code1 123456 \
  --authentication-code2 789012

Checklist

• Root account not used in production; access keys deleted
• MFA enabled for all privileged accounts
• Service accounts use roles + OIDC, not long-lived credentials
• IAM policies follow least privilege (no * on resources or actions)
• Access reviews scheduled quarterly
• Unused credentials rotated or removed
• Permission boundaries set on delegated admin roles

2. Secrets Management

Secrets in code or environment variables are accidents waiting to happen — they end up in logs, error traces, and git history. Store them in a managed service with auditing and rotation.

Cloud Secrets Managers

// ✅ CORRECT: Fetch from secrets manager at runtime
import { SecretsManager } from '@aws-sdk/client-secrets-manager';

const client = new SecretsManager({ region: 'us-east-1' });
const secret = await client.getSecretValue({ SecretId: 'prod/api-key' });
const apiKey = JSON.parse(secret.SecretString!).key;

// ❌ WRONG: env vars aren't rotated, audited, or access-controlled
const apiKey = process.env.API_KEY;

Automatic Rotation

aws secretsmanager rotate-secret \
  --secret-id prod/db-password \
  --rotation-lambda-arn arn:aws:lambda:region:account:function:rotate \
  --rotation-rules AutomaticallyAfterDays=30

Checklist

• All secrets in a managed store (AWS Secrets Manager, Vercel Secrets, GCP Secret Manager)
• Automatic rotation enabled for database credentials
• API keys rotated at least quarterly
• No secrets in source code, logs, or error messages
• Secret access audit logging enabled
• Secrets scoped to environments (prod secrets ≠ dev secrets)

3. Encryption

Encryption should be non-negotiable for any data touching production — at rest to protect against storage breaches, in transit to prevent interception.

Encryption at Rest

# ✅ CORRECT: Encrypted RDS instance
resource "aws_db_instance" "main" {
  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn
  # ... other config
}

# ✅ CORRECT: Encrypted S3 bucket (enforce via bucket policy)
resource "aws_s3_bucket_server_side_encryption_configuration" "main" {
  bucket = aws_s3_bucket.main.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3.arn
    }
    bucket_key_enabled = true
  }
}

Encryption in Transit

# ✅ CORRECT: Enforce HTTPS-only on S3 via bucket policy
resource "aws_s3_bucket_policy" "enforce_tls" {
  bucket = aws_s3_bucket.main.id
  policy = jsonencode({
    Statement = [{
      Effect    = "Deny"
      Principal = "*"
      Action    = "s3:*"
      Resource  = ["${aws_s3_bucket.main.arn}/*", aws_s3_bucket.main.arn]
      Condition = { Bool = { "aws:SecureTransport" = "false" } }
    }]
  })
}

# Enforce TLS 1.2+ on RDS (parameter group)
resource "aws_db_parameter_group" "tls" {
  family = "postgres15"
  parameter {
    name  = "rds.force_ssl"
    value = "1"
  }
}

Checklist

• All storage encrypted at rest (RDS, S3, EBS, EFS)
• Customer-managed KMS keys used for sensitive data
• TLS enforced in transit — HTTP rejected, minimum TLS 1.2
• Certificates managed via ACM (no self-signed certs in prod)
• KMS key rotation enabled

4. Network Security

Your network perimeter is the outermost layer of defense. Keep it tight — anything publicly exposed is an attack surface.

VPC & Security Groups

# ✅ CORRECT: Minimal-ingress security group
resource "aws_security_group" "app" {
  name   = "app-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]  # Internal VPC only
  }

  egress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]   # HTTPS outbound only
  }
}

# ❌ WRONG: Never open all ports to the internet
resource "aws_security_group" "bad" {
  ingress {
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Common Misconfigurations to Catch

# ❌ Public S3 bucket
aws s3api put-bucket-acl --bucket my-bucket --acl public-read

# ✅ Private bucket with explicit policy
aws s3api put-bucket-acl --bucket my-bucket --acl private
aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json

# ❌ Publicly accessible RDS — extremely dangerous
resource "aws_db_instance" "bad" {
  publicly_accessible = true
}

# ✅ Private RDS in VPC
resource "aws_db_instance" "good" {
  publicly_accessible    = false
  vpc_security_group_ids = [aws_security_group.db.id]
  db_subnet_group_name   = aws_db_subnet_group.private.name
}

Checklist

• No databases publicly accessible
• SSH/RDP restricted to VPN/bastion — never 0.0.0.0/0
• Security groups scoped to minimum required ports and CIDRs
• Network ACLs as a second layer of defense
• VPC flow logs enabled for traffic visibility
• Private subnets for databases and internal services
• NAT gateway (not IGW) for private subnet egress

5. Logging & Monitoring

You can't defend what you can't see. Comprehensive logging is the foundation of incident detection, forensics, and compliance.

CloudWatch / Structured Logging

// ✅ CORRECT: Structured security event logging
import { CloudWatchLogsClient } from '@aws-sdk/client-cloudwatch-logs';

const logSecurityEvent = async (event: SecurityEvent) => {
  await cloudwatch.putLogEvents({
    logGroupName: '/aws/security/events',
    logStreamName: 'authentication',
    logEvents: [{
      timestamp: Date.now(),
      message: JSON.stringify({
        type: event.type,
        userId: event.userId,
        ip: event.ip,
        result: event.result,
        // Never log tokens, passwords, or PII
      })
    }]
  });
};

Alerting

Set up alarms for high-signal security events. Don't wait to be breached before noticing.

# Alert on root account usage
aws cloudwatch put-metric-alarm \
  --alarm-name "RootAccountUsage" \
  --metric-name "RootAccountUsageCount" \
  --namespace "CloudTrailMetrics" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789:SecurityAlerts

Checklist

• CloudTrail enabled in all regions with log file validation
• CloudWatch Logs / equivalent enabled for all services
• Failed authentication attempts logged
• Admin and privileged actions audited
• Log retention ≥ 90 days (1 year for compliance workloads)
• Logs shipped to a separate, tamper-resistant account or bucket
• Alerts configured for: root usage, failed logins, config changes, IAM mutations

6. CI/CD Pipeline Security

Your pipeline has broad production access — it's a high-value target. Treat it with the same rigor as your production environment.

Secure GitHub Actions Workflow