Security Services

CMK types

Envelope encryption flow

When your Spring service writes a PII record to DynamoDB with a customer-managed CMK:

1. App calls kms:GenerateDataKey — KMS returns a plaintext data key + encrypted copy
2. App encrypts the record locally with AES-256 using the plaintext data key
3. App stores ciphertext + encrypted data key in DynamoDB; wipes plaintext key from memory
4. On read: app calls kms:Decrypt on the encrypted data key, decrypts payload locally

sequenceDiagram
  participant App as Application
  participant KMS as AWS KMS
  participant Store as S3 / RDS / DynamoDB

  App->>KMS: GenerateDataKey(KeyId=CMK)
  KMS-->>App: Plaintext DEK + Encrypted DEK
  App->>App: Encrypt payload with Plaintext DEK
  App->>Store: Store ciphertext + Encrypted DEK
  Note over App: Zero plaintext DEK in memory

  App->>Store: Read ciphertext + Encrypted DEK
  App->>KMS: Decrypt(Encrypted DEK)
  KMS-->>App: Plaintext DEK
  App->>App: Decrypt payload locally

Key rotation

Automatic rotation (customer-managed symmetric CMKs): KMS generates new backing material annually; old versions decrypt existing ciphertext transparently. Rotation does not re-encrypt data — it rotates the CMK material used for new GenerateDataKey calls. Enable with one checkbox or EnableKeyRotation API.

Manual rotation: create a new CMK, re-encrypt data, update aliases and key policies, deprecate old key. Required for asymmetric keys and imported key material.

Grants vs key policies

Multi-Region Keys (MRKs)

A multi-region primary key in eu-west-1 has replica keys in us-east-1 with the same key ID and key material. Encrypt in one region, decrypt in another without cross-region KMS API calls. Use for global apps, DR failover, and DynamoDB global tables with client-side encryption. MRKs are not the same as replicating encrypted snapshots — the key ID travels with the data.

Create a customer-managed CMK with alias

# Create symmetric CMK with rotation
KEY_ID=$(aws kms create-key \
  --description "App data encryption key" \
  --key-usage ENCRYPT_DECRYPT \
  --query 'KeyMetadata.KeyId' --output text)

aws kms enable-key-rotation --key-id "$KEY_ID"

aws kms create-alias \
  --alias-name alias/app-data-prod \
  --target-key-id "$KEY_ID"

# Grant ECS task role decrypt (key policy + IAM policy both required)
aws kms create-grant \
  --key-id "$KEY_ID" \
  --grantee-principal arn:aws:iam::123456789012:role/order-service-task \
  --operations Decrypt GenerateDataKey

resource "aws_kms_key" "app_data" {
  description             = "App data encryption key"
  enable_key_rotation   = true
  deletion_window_in_days = 30

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "EnableRootAdmin"
        Effect = "Allow"
        Principal = { AWS = "arn:aws:iam::123456789012:root" }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "AllowECSRoleUse"
        Effect = "Allow"
        Principal = { AWS = aws_iam_role.ecs_task.arn }
        Action   = ["kms:Decrypt", "kms:GenerateDataKey"]
        Resource = "*"
      }
    ]
  })
}

resource "aws_kms_alias" "app_data" {
  name          = "alias/app-data-prod"
  target_key_id = aws_kms_key.app_data.key_id
}

import * as kms from 'aws-cdk-lib/aws-kms';

const appKey = new kms.Key(this, 'AppDataKey', {
  alias: 'app-data-prod',
  enableKeyRotation: true,
  description: 'Customer-managed CMK for application data',
});

appKey.grantDecrypt(taskRole);
appKey.grant(taskRole, 'kms:GenerateDataKey');

How secrets are versioned

Each secret has immutable versions identified by UUIDs. Two staging labels point to versions:

• AWSCURRENT — what apps should read in production
• AWSPENDING — used during rotation; rotation Lambda writes here first, then swaps labels

Rotation is atomic at the label swap: apps reading AWSCURRENT get the new password on the next GetSecretValue call. Cache secrets in memory with TTL (5–15 min), not forever.

Automatic rotation

Secrets Manager invokes a rotation Lambda on a schedule (default 30 days, configurable). Built-in rotation templates exist for:

• RDS (single-user and multi-user)
• Redshift
• DocumentDB
• Amazon MQ
• Custom rotation via your own Lambda (any database or API key)

Secrets Manager vs SSM Parameter Store

Create a secret with RDS rotation

aws secretsmanager create-secret \
  --name prod/order-service/rds \
  --description "Order service PostgreSQL credentials" \
  --kms-key-id alias/app-data-prod \
  --secret-string '{"username":"orders_app","password":"GENERATE_STRONG","host":"orders.xxxx.eu-west-1.rds.amazonaws.com","port":5432,"dbname":"orders"}'

# Attach managed rotation (single-user RDS PostgreSQL)
aws secretsmanager rotate-secret \
  --secret-id prod/order-service/rds \
  --rotation-lambda-arn arn:aws:lambda:eu-west-1:123456789012:function:SecretsManagerRDSRotation \
  --rotation-rules AutomaticallyAfterDays=30

resource "aws_secretsmanager_secret" "rds" {
  name       = "prod/order-service/rds"
  kms_key_id = aws_kms_key.app_data.arn
}

resource "aws_secretsmanager_secret_version" "rds" {
  secret_id = aws_secretsmanager_secret.rds.id
  secret_string = jsonencode({
    username = "orders_app"
    password = random_password.db.result
    host     = aws_db_instance.orders.address
    port     = 5432
    dbname   = "orders"
  })
}

resource "aws_secretsmanager_secret_rotation" "rds" {
  secret_id           = aws_secretsmanager_secret.rds.id
  rotation_lambda_arn = aws_serverlessapplicationrepository_cloudformation_stack.rds_rotation.outputs["RotationLambdaARN"]

  rotation_rules {
    automatically_after_days = 30
  }
}

import * as secretsmanager from 'aws-cdk-lib/aws-secretsmanager';
import * as rds from 'aws-cdk-lib/aws-rds';

const dbSecret = new rds.DatabaseSecret(this, 'OrderDbSecret', {
  username: 'orders_app',
  secretName: 'prod/order-service/rds',
  encryptionKey: appKey,
});

const instance = new rds.DatabaseInstance(this, 'OrdersDb', {
  engine: rds.DatabaseInstanceEngine.postgres({ version: rds.PostgresEngineVersion.VER_16 }),
  credentials: rds.Credentials.fromSecret(dbSecret),
  // ...
});

dbSecret.addRotationSchedule('Rotation', {
  automaticallyAfter: cdk.Duration.days(30),
});

WAF rule types

Managed rule groups (production starters)

Start every public ALB with AWSManagedRulesCommonRuleSet (OWASP baseline), add KnownBadInputs (Log4j/Spring4Shell), SQLi for data-heavy APIs, and IpReputationList for known-bad IPs. Bot Control adds per-request cost — enable when scraper abuse is real.

Shield Standard vs Advanced

Web ACL on an ALB

# Create Web ACL (REGIONAL scope for ALB)
WEBACL_ARN=$(aws wafv2 create-web-acl \
  --name order-api-waf \
  --scope REGIONAL \
  --default-action Allow={} \
  --rules '[
    {
      "Name": "RateLimit",
      "Priority": 1,
      "Statement": {
        "RateBasedStatement": {
          "Limit": 2000,
          "AggregateKeyType": "IP"
        }
      },
      "Action": { "Block": {} },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "RateLimit"
      }
    },
    {
      "Name": "AWS-AWSManagedRulesCommonRuleSet",
      "Priority": 2,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet"
        }
      },
      "OverrideAction": { "None": {} },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "CommonRuleSet"
      }
    }
  ]' \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=order-api-waf \
  --query 'Summary.ARN' --output text)

# Associate with ALB
aws wafv2 associate-web-acl \
  --web-acl-arn "$WEBACL_ARN" \
  --resource-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/order-api/abcdef1234567890

resource "aws_wafv2_web_acl" "order_api" {
  name  = "order-api-waf"
  scope = "REGIONAL"

  default_action { allow {} }

  rule {
    name     = "RateLimit"
    priority = 1
    action { block {} }
    statement {
      rate_based_statement {
        limit              = 2000
        aggregate_key_type = "IP"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "RateLimit"
      sampled_requests_enabled   = true
    }
  }

  rule {
    name     = "AWSManagedRulesCommonRuleSet"
    priority = 2
    override_action { none {} }
    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "CommonRuleSet"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "order-api-waf"
    sampled_requests_enabled   = true
  }
}

resource "aws_wafv2_web_acl_association" "alb" {
  resource_arn = aws_lb.order_api.arn
  web_acl_arn  = aws_wafv2_web_acl.order_api.arn
}

import * as wafv2 from 'aws-cdk-lib/aws-wafv2';

const vis = { cloudWatchMetricsEnabled: true, sampledRequestsEnabled: true };
const webAcl = new wafv2.CfnWebACL(this, 'OrderApiWaf', {
  name: 'order-api-waf', scope: 'REGIONAL', defaultAction: { allow: {} },
  visibilityConfig: { ...vis, metricName: 'order-api-waf' },
  rules: [
    { name: 'RateLimit', priority: 1, action: { block: {} },
      statement: { rateBasedStatement: { limit: 2000, aggregateKeyType: 'IP' } },
      visibilityConfig: { ...vis, metricName: 'RateLimit' } },
    { name: 'CommonRuleSet', priority: 2, overrideAction: { none: {} },
      statement: { managedRuleGroupStatement: { vendorName: 'AWS', name: 'AWSManagedRulesCommonRuleSet' } },
      visibilityConfig: { ...vis, metricName: 'CommonRuleSet' } },
  ],
});
new wafv2.CfnWebACLAssociation(this, 'AlbWafAssoc', {
  resourceArn: alb.loadBalancerArn, webAclArn: webAcl.attrArn,
});

What GuardDuty detects

Credential exfiltration (unusual geographies, Tor), crypto mining, IAM reconnaissance at volume, malware on EBS/EKS, anomalous S3 data events, and privileged EKS container launches — all without deploying agents on EC2.

Findings workflow

1. Enable GuardDuty in the security/admin account; delegate admin for org-wide enrollment
2. Severity — Low (4.0–4.9), Medium (5.0–6.9), High (7.0–8.9), Critical (9.0+) on a 0–10 scale
3. Aggregate — findings flow to Security Hub as ASFF (AWS Security Finding Format)
4. Triage — EventBridge rule on severity ≥ 7 → SNS/PagerDuty/Slack
5. Investigate — pivot on resource ARN, principal, and affected region in CloudTrail
6. Remediate — isolate SG, rotate credentials, quarantine EC2 snapshot; mark finding resolved in GuardDuty
7. Suppress — false positives get suppression rules (by finding type + resource tag) — document why

Inspector vulnerability scanning

Inspector scores findings with CVSS and EPSS. Gate CI on Critical CVEs via ECR enhanced scanning before promoting image tags. Inspector finds the CVE; GuardDuty tells you if exploitation is happening in your VPC.

Security Hub

Enable Security Hub in the security account; delegate administrator for the org. It ingests findings from:

• GuardDuty, Inspector, IAM Access Analyzer, Macie, Firewall Manager
• Third-party integrations (Prowler, Checkov, Prisma) via ASFF import
• Config rules mapped to Security Hub controls

Security standards — enable AWS Foundational Security Best Practices (FSBP) and CIS AWS Foundations Benchmark v1.4.0. Each control maps to a pass/fail per account/region. The security score is passed controls ÷ total enabled controls. Failed critical controls (e.g. root MFA disabled, public S3) should page on-call.

AWS Config rules

Compliance dashboards

Security Hub Insights filter by control failure type; export findings to S3/Athena for audit reports. Config Aggregator unifies multi-account inventory — essential for "every SG allowing SSH from 0.0.0.0/0" queries.

Detective controls (Config + Hub) flag drift after it happens — good for audit and auto-remediation. Preventive controls (SCPs, IAM denies) block the API call before change is recorded. Use both: SCPs deny public S3 at org level; Config catches anything that slips through.

Encrypt at rest — service by service

S3 bucket policy — deny unencrypted uploads

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

TLS in transit checklist

• 🔐

  ALB / CloudFront

  ACM certificate on HTTPS listener; redirect HTTP → HTTPS; TLS 1.2+ policy (ELBSecurityPolicy-TLS13-1-2-2021-06).

• 🔗

  Service-to-service

  RDS/Aurora: require SSL in connection string (sslmode=require). ElastiCache in-transit encryption enabled.

• 📡

  VPC endpoints

  Interface endpoints for S3, DynamoDB, Secrets Manager — traffic stays on AWS backbone, not public internet.

• 🛡

  API Gateway

  Custom domain with ACM cert; mutual TLS for B2B partners where required.

• 📋

  IAM enforcement

  aws:SecureTransport = true in policies for S3, SNS, SQS, ECR.

• ✅

  Verify continuously

  Config rules: alb-listener-https, rds-storage-encrypted, s3-default-encryption-kms.