Security (Bảo mật)Security

Part of the Cloud knowledge base — AWS deep dive. Complements DevOps Roadmap.

Overview

Security on AWS is not one service but a layered posture: identity (IAM, covered in its own page), data protection (KMS, encryption everywhere), secrets management (Secrets Manager, Parameter Store), threat detection (GuardDuty, Security Hub, Inspector, Macie, Detective), network and application defense (WAF, Shield, Security Groups, PrivateLink), and certificates (ACM). The unifying principle is the shared responsibility model: AWS secures the cloud (hardware, hypervisor, managed-service internals), and you secure what you put in the cloud (your data, configurations, identities, and network exposure). Nearly every breach on AWS is a customer-side misconfiguration, not an AWS failure.

For a DevOps engineer the practical goal is defense in depth with the boring parts automated. Encrypt everything at rest and in transit by default. Never let a secret touch source control. Assume detection is a pipeline, not a person watching a screen — findings from GuardDuty flow into Security Hub, trigger EventBridge automation, and page someone only when a human decision is genuinely needed. And treat security configuration as code (Config rules, IaC guardrails) so that a correct posture is the default and drift is caught automatically.

The governing trade-off is security vs. friction. Perfectly locked-down systems that block developers get worked around, and the workarounds are the vulnerability. The craft is making the secure path the easy path: KMS encryption that “just happens” on a bucket, secrets that rotate without anyone noticing, WAF rules that block attacks without breaking legitimate traffic. This page covers the AWS building blocks and the practices that make secure-by-default the low-friction default.

Fundamentals

The shared responsibility model, concretely

The dividing line moves as you go up the managed-service ladder: with Lambda or Fargate, AWS patches the OS; with EC2, you do. Knowing exactly where the line sits for each service you use is the first security skill.

Encryption: at rest vs. in transit

• At rest — data on disk (EBS, S3, RDS, DynamoDB, EFS) encrypted with keys managed by KMS. Most services offer one-checkbox encryption; the choice is which key (AWS-owned, AWS-managed, or your customer-managed CMK).
• In transit — data on the wire encrypted with TLS. Terminate TLS at the load balancer / API Gateway / CloudFront with an ACM certificate, and prefer TLS for internal hops too (RDS/Redis in-transit encryption, VPC endpoints).

The modern default is encrypt everything, everywhere, because the marginal cost is near zero and the downside of an unencrypted snapshot or an HTTP endpoint is catastrophic.

KMS in one picture

AWS Key Management Service (KMS) is a managed service for creating and controlling encryption keys, backed by FIPS 140-validated hardware security modules (HSMs). KMS keys never leave the HSM unencrypted. You rarely encrypt large data with KMS directly (there is a 4 KB limit); instead KMS enables envelope encryption.

Key Concepts

KMS key types

Choose a CMK whenever you need to (a) write a key policy controlling who can use/administer the key, (b) share encryption across accounts, (c) enforce your own rotation cadence, or (d) get per-key CloudTrail visibility for compliance. Otherwise AWS-managed keys are free and fine.

Envelope encryption

KMS does not encrypt your gigabytes directly. Instead:

1. Your application (or the AWS service) asks KMS for a data key via GenerateDataKey.
2. KMS returns the data key twice: once in plaintext (used immediately to encrypt your data locally with AES-256) and once encrypted under the CMK (the “wrapped” key).
3. You store the encrypted data key alongside the ciphertext and discard the plaintext key from memory.
4. To decrypt, you send the wrapped key back to KMS Decrypt, get the plaintext data key, decrypt your data, and discard the key again.

This is efficient (bulk crypto is local AES, only the tiny key round-trips to KMS), auditable (every Decrypt is a CloudTrail event), and revocable (disable the CMK and all data encrypted under it becomes inaccessible instantly). Every service-level “encrypt with KMS” checkbox is doing exactly this under the hood.

KMS key policies

Unlike IAM policies (attached to a principal), a key policy is a resource policy attached to the key itself, and it is the primary access control for a CMK — an IAM policy alone cannot grant access unless the key policy allows it. A minimal, correct key policy separates administrators (manage the key, cannot use it to decrypt) from users (encrypt/decrypt, cannot delete the key).

Worked example — a least-privilege CMK policy:

{
  "Version": "2012-10-17",
  "Id": "checkout-key-policy",
  "Statement": [
    {
      "Sid": "RootAccountFullControl",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "KeyAdmins",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/kms-admin" },
      "Action": [
        "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*",
        "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*",
        "kms:Get*", "kms:Delete*", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "KeyUsers",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/checkout-service" },
      "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com" }
      }
    }
  ]
}

The separation matters: the kms-admin role can rotate and disable the key but cannot decrypt data, and the checkout-service role can decrypt but cannot delete the key — so neither a compromised admin nor a compromised app is fully catastrophic. The kms:ViaService condition further restricts the service role to use the key only through Secrets Manager, not directly. Keep the root statement so you never lock yourself out (losing the last admin of a CMK with no root access is unrecoverable).

Secrets Manager vs. SSM Parameter Store

Both store configuration and secrets encrypted with KMS, but they target different needs.

Rule of thumb: if it needs automatic rotation (database credentials, third-party API keys) or cross-account sharing, use Secrets Manager. If it’s plain config or a static secret and you want zero cost, use Parameter Store SecureString. Many teams use both: Parameter Store for the bulk of config, Secrets Manager for the handful of rotating credentials.

Worked example — retrieving a secret in code (Python, boto3):

import boto3, json

def get_db_credentials():
    client = boto3.client("secretsmanager")
    resp = client.get_secret_value(SecretId="prod/checkout/db")
    secret = json.loads(resp["SecretString"])
    return secret["username"], secret["password"]

# From the CLI (e.g. in a CI step):
#   aws secretsmanager get-secret-value \
#     --secret-id prod/checkout/db \
#     --query SecretString --output text | jq -r .password

The critical property: the credential is never in the code, the image, or an env file committed to git — the app fetches it at runtime using its IAM role, and rotation happens transparently because the app always reads AWSCURRENT. Cache the result in memory to avoid hammering the API, and let the rotation Lambda swap the value behind the label.

Threat detection stack

AWS provides a set of complementary detection services; think of them as sensors feeding a central pane.

The intended workflow: GuardDuty/Inspector/Macie generate findings → Security Hub aggregates and scores them and runs compliance standards → EventBridge routes critical findings to automated response or a ticket → Detective helps you investigate the ones that need a human. Enable them org-wide via a delegated administrator account so a new member account is protected from day one. GuardDuty in particular is high signal-to-noise and should be considered a default-on baseline.

WAF & Shield

• AWS WAF — a web application firewall for HTTP(S), attached to CloudFront, ALB, API Gateway, or AppSync. You compose rules into a web ACL: managed rule groups (AWS/vendor-supplied for OWASP Top 10, bad bots, known-bad inputs), rate-based rules (throttle an IP), and custom match rules (block/allow by header, URI, geo, IP set). It defends against SQLi, XSS, and layer-7 floods.
• AWS Shield Standard — free, automatic protection against common layer-3/4 DDoS (SYN floods, reflection attacks) for all AWS customers.
• AWS Shield Advanced — paid, adds protection for larger/sophisticated DDoS, 24/7 access to the Shield Response Team, cost-protection for scaling during an attack, and tighter WAF integration. Worth it for internet-facing revenue-critical apps.

ACM: certificates

AWS Certificate Manager (ACM) provisions, manages, and auto-renews TLS certificates for free, when used with integrated services (CloudFront, ALB/NLB, API Gateway). You request a public cert, prove domain ownership (DNS validation is best — a CNAME that renews automatically), and attach it to your listener. ACM handles renewal so certificates never expire silently — the classic 2 a.m. outage. Note certs for CloudFront must live in us-east-1. For private/internal certs, ACM Private CA issues a private certificate hierarchy. ACM public certs cannot be exported (the private key stays in AWS) — for EC2-terminated or on-prem TLS you either use ACM Private CA or bring your own cert.

Network security recap

Layered from the perimeter inward (full detail in the Networking page):

• Security Groups — stateful, instance/ENI-level allow-only firewalls. Return traffic is automatically allowed. Reference other SGs as sources for clean tiering (web-SG allowed to reach app-SG).
• Network ACLs — stateless, subnet-level allow and deny rules. Evaluated in order. Useful for coarse subnet-wide blocks (e.g. deny a bad CIDR) that SGs cannot express.
• PrivateLink / VPC endpoints — reach AWS services (S3, DynamoDB, or a partner/SaaS service) over private AWS network paths instead of the public internet. Gateway endpoints (S3, DynamoDB) are free; Interface endpoints (most other services) are ENIs in your subnets, billed hourly + per-GB, and keep traffic off the internet entirely — important for compliance and for private subnets with no NAT.

Combine them: SGs for the common allow-lists, NACLs for coarse subnet guards, and PrivateLink to eliminate internet exposure for service-to-service and service-to-AWS-API traffic.

Best Practices

1. Encrypt everything at rest by default, using CMKs where control matters. Enable default encryption on S3, EBS, RDS, DynamoDB. Rationale: the marginal cost is near zero, and a single unencrypted snapshot or bucket is a headline breach; CMKs add per-key auditing and revocation for sensitive data.
2. Enforce TLS in transit and terminate with ACM. Redirect HTTP→HTTPS, use ACM certs with DNS auto-renewal, enable in-transit encryption for RDS/Redis. Rationale: plaintext on the wire is trivially sniffable, and ACM auto-renewal removes the classic expired-certificate outage.
3. Separate KMS key administrators from key users in the key policy. Rationale: a key admin who cannot decrypt and an app that cannot delete the key mean no single compromised principal is fully catastrophic.
4. Enable KMS key rotation and keep the root statement. Turn on annual (or on-demand) rotation; never remove root access from a CMK. Rationale: rotation limits the blast radius of a leaked key; losing the last administrator of a CMK is unrecoverable.
5. Never store secrets in code, images, env files, or Terraform state in git. Fetch from Secrets Manager / Parameter Store at runtime via IAM roles. Rationale: committed secrets leak forever in git history and are a top breach vector; runtime retrieval keeps them out of every artifact.
6. Use Secrets Manager rotation for database and third-party credentials. Rationale: static long-lived credentials are the most-stolen secret; automatic rotation shrinks the useful lifetime of any leak to hours.
7. Prefer Parameter Store SecureString for non-rotating config to save cost. Rationale: the standard tier is free; paying Secrets Manager’s per-secret fee for static feature flags is waste — reserve it for things that truly need rotation.
8. Turn GuardDuty on org-wide with a delegated administrator. Rationale: it is high signal, low effort, and auto-covers new accounts; a compromised account with no GuardDuty is a silent breach waiting to happen.
9. Aggregate findings in Security Hub and automate response via EventBridge. Rationale: humans cannot watch five separate detection consoles; central scoring plus automated containment (isolate SG, disable key) turns detection into fast response.
10. Scan images and instances with Inspector; block on critical CVEs in CI. Rationale: containers inherit every vulnerability in their base layer; gating deploys on Inspector findings stops known-exploitable images from reaching production.
11. Put WAF in front of internet-facing apps with AWS managed rule groups + rate limits. Rationale: managed rules cover the OWASP Top 10 and bad bots with near-zero maintenance; rate-based rules blunt credential-stuffing and layer-7 floods.
12. Use PrivateLink/VPC endpoints for AWS API and internal service traffic. Rationale: keeping traffic off the public internet reduces attack surface, satisfies data-residency requirements, and lets private subnets reach S3/DynamoDB without a costly NAT gateway.
13. Reference security groups as sources instead of CIDR ranges for internal tiers. Rationale: SG-to-SG rules stay correct as IPs change and encode intent (“web tier may reach app tier”) rather than brittle IP lists.
14. Enable Macie on buckets that may hold PII. Rationale: automated sensitive-data discovery catches PII landing in the wrong bucket before it becomes a compliance incident, which manual review never scales to.
15. Enforce encryption and exposure guardrails with AWS Config rules. Deploy managed rules (s3-bucket-server-side-encryption-enabled, encrypted-volumes, restricted-ssh) with auto-remediation. Rationale: prevention-plus-detection keeps posture correct automatically instead of relying on humans to never misconfigure.
16. Apply least privilege to KMS via kms:ViaService and grant conditions. Rationale: restricting a key to be usable only through the intended service (e.g. Secrets Manager) prevents a compromised role from decrypting data through unexpected paths.

References

• AWS Shared Responsibility Model
• AWS KMS Developer Guide
• KMS envelope encryption
• KMS key policies
• AWS Secrets Manager User Guide
• SSM Parameter Store
• Amazon GuardDuty User Guide
• AWS Security Hub User Guide
• Amazon Inspector User Guide
• Amazon Macie User Guide
• Amazon Detective User Guide
• AWS WAF Developer Guide
• AWS Shield Developer Guide
• AWS Certificate Manager User Guide
• AWS PrivateLink
• AWS Well-Architected — Security Pillar