บทที่ 09: Security Architecture & Data Protection

1. วัตถุประสงค์บท

บทนี้เป็นเจ้าของ Security pillar ในเชิงลึกและครอบคลุมทั้ง Domain 1 (Solutions for Organizational Complexity), Domain 2 (Design for New Solutions) และ Domain 3 (Continuous Improvement) — เพราะ security เป็น cross-cutting concern ที่แทรกอยู่ในทุกโจทย์ระดับ Professional ไม่ว่าจะเป็น encrypt data at rest, protect against DDoS, detect malicious activity, centralize security findings across accounts, discover PII, automated remediation, immutable audit trail, หรือ break-glass access คำเหล่านี้ (เชื่อมโยงบทที่ 01 — keyword mapping) แต่ละคำชี้ไปยังบริการ security เฉพาะที่ต้องแยกให้ขาด

จุดที่ SA Pro ต่างจาก Associate คือไม่ใช่แค่รู้ว่า “KMS เข้ารหัสข้อมูล” หรือ “GuardDuty ตรวจจับภัยคุกคาม” แต่คือการออกแบบ defense in depth ที่มีหลายชั้นทำงานร่วมกัน, เลือกได้ว่า key policy vs IAM vs grant ควบคุมการเข้าถึง key อย่างไรในบริบท cross-account, แยก preventive vs detective control ให้ตรงโจทย์, วางสถาปัตยกรรม security services แบบ organization-wide (delegated admin, aggregation ที่ Audit account), และออกแบบ incident response ที่เก็บ evidence ได้จริงโดยไม่ทำลาย forensics — ทั้งหมดโดยชั่ง operational overhead กับระดับ security ที่ business ต้องการ

บทก่อนหน้าฝาก cross-reference มายังบทนี้จำนวนมาก: บทที่ 01 ฝาก detective vs preventive controls และ least privilege เป็นแกน Security pillar; บทที่ 02 ฝาก รายละเอียดฟังก์ชัน GuardDuty/Config/Security Hub/KMS/defense-in-depth (บท 02 แตะเฉพาะ delegated admin กับ guardrail mechanism); บทที่ 03 ฝาก KMS key policy vs IAM vs grant, cross-account key, Secrets Manager rotation, CloudHSM; บทที่ 04 ฝาก WAF/Shield เชิงลึก, Network Firewall ในบริบท DiD, data perimeter; บทที่ 06/07/08 ฝาก encryption ของ storage/database/backup ผ่าน KMS — จะครอบคลุมให้ครบที่นี่

เมื่อจบบทนี้คุณจะสามารถ:

ออกแบบ defense in depth หลายชั้น (identity → network → compute → data → detection → response) และอธิบาย shared responsibility model ในบริบท Pro
เลือกและออกแบบ AWS KMS: CMK types, key policy vs IAM vs grant, envelope encryption, multi-region keys, key rotation, cross-account usage และรู้ว่าเมื่อไหร่ต้อง CloudHSM
แยก AWS Secrets Manager vs SSM Parameter Store และออกแบบ automatic rotation; เลือกใช้ ACM vs ACM Private CA
วางระบบ detective controls แบบ org-wide: GuardDuty, Security Hub, Detective, Macie, Config, CloudTrail (org trail/data events/Lake)
ออกแบบ perimeter protection: WAF managed rules/rate-based, Shield Advanced, Firewall Manager org-wide
ออกแบบ automated remediation (EventBridge + SSM Automation) และ incident response (isolation, forensics account, break-glass)

ขอบเขต: IAM/federation/policy evaluation → บทที่ 03 (บทนี้ต่อยอดเฉพาะมุม KMS/Secrets/data protection); network segmentation (Security Group/NACL/Network Firewall) → บทที่ 04 (บทนี้อ้างอิงในบริบท DiD เท่านั้น); governance policy (SCP/Organizations) → บทที่ 02 (บทนี้ใช้เป็น preventive layer)

2. แนวคิดหลัก

2.1 Defense in Depth เชิงสถาปัตยกรรม

Defense in depth คือหลักการวาง security control หลายชั้นซ้อนกัน เพื่อว่าเมื่อชั้นใดชั้นหนึ่งถูกเจาะ ชั้นถัดไปยังป้องกันอยู่ — ไม่มีชั้นเดียวที่เป็น single point of security failure ในบริบท SA Pro เราต้องเห็นภาพเป็น layer ดังนี้:

ชั้น	control หลัก	บทที่เป็นเจ้าของ
Organization/Governance	SCP (preventive guardrail), Control Tower, RCP	บทที่ 02
Identity	IAM least privilege, permission boundary, MFA, federation	บทที่ 03
Network perimeter/edge	WAF, Shield, CloudFront, Network Firewall, SG/NACL	บทที่ 04 + บทนี้ (WAF/Shield)
Network segmentation	private subnet, VPC endpoint policy, data perimeter	บทที่ 04
Compute/host	Inspector (vulnerability), SSM Patch Manager, IMDSv2	บทนี้ + บทที่ 11
Data	KMS encryption at rest, TLS in transit, Macie, S3 Object Lock	บทนี้
Detection	GuardDuty, Security Hub, Config, CloudTrail, Detective	บทนี้
Response	EventBridge + SSM automation, forensics account, break-glass	บทนี้

หลักการออกสอบ: โจทย์ที่ให้ตัวเลือกเป็น “control ชั้นเดียว” มักผิด — Pro ต้องการหลายชั้น เช่น protect a public web app ที่ถูกต้องคือ CloudFront + WAF (edge) + Shield Advanced (DDoS) + private origin (ALB ใน private subnet) + Security Group (segmentation) ไม่ใช่แค่ WAF อย่างเดียว จุดสำคัญคือ preventive layer หยุดการโจมตี, detective layer ตรวจจับสิ่งที่ผ่านเข้ามา, response layer จำกัดความเสียหาย — สามหน้าที่นี้ต้องมีครบ

2.2 Shared Responsibility Model ในบริบท Pro

หลักคลาสสิก “AWS รับผิดชอบ security of the cloud, ลูกค้ารับผิดชอบ security in the cloud” ยังจริง แต่ระดับ Pro ต้องเข้าใจว่า เส้นแบ่งเลื่อนตามระดับ managed ของบริการ:

IaaS (EC2): ลูกค้ารับผิดชอบเยอะสุด — OS patching, application, network config, encryption, IAM ทั้งหมด (AWS ดูแลแค่ hypervisor/hardware/physical)
Managed service (RDS, ElastiCache): AWS ดูแล OS/engine patching ให้ (แต่ลูกค้ายังต้อง config encryption, network, IAM, และเลือก maintenance window)
Serverless (Lambda, S3, DynamoDB): ลูกค้ารับผิดชอบน้อยสุด — แค่ data, IAM policy, และ config (AWS ดูแล OS/runtime/scaling)

จุดออกสอบ: โจทย์ reduce security operational burden of patching → ย้ายจาก EC2 ไป managed/serverless (เชื่อมโยง keyword least operational overhead บทที่ 01) เพราะเลื่อนภาระ patching ไปฝั่ง AWS ส่วน ensure OS-level compliance across EC2 fleet → เป็นความรับผิดชอบลูกค้า ต้องใช้ SSM Patch Manager + Inspector (2.16) กับดักคือคิดว่า “ใช้ RDS แล้วไม่ต้องสน security” — จริง ๆ ลูกค้ายังต้องคุม encryption/IAM/network เสมอ

2.3 AWS KMS — CMK types และกลไกภายใน

AWS Key Management Service (KMS) เป็นหัวใจของ encryption at rest ทั้งหมดบน AWS KMS key (เดิมเรียก CMK — Customer Master Key) แบ่งเป็น 3 ประเภทที่ต้องแยกให้ขาด:

ประเภท key	ใครสร้าง/ควบคุม	key policy แก้ได้	rotation	cross-account	เห็นใน CloudTrail	ค่าใช้จ่าย
AWS owned key	AWS เป็นเจ้าของ ใช้ร่วมหลายลูกค้า	ไม่ได้	AWS จัดการ	ไม่ได้	ไม่เห็น	ฟรี
AWS managed key (`aws/service`)	AWS สร้างต่อ service ต่อ account	ไม่ได้ (ดูได้)	ทุก 1 ปี auto	ไม่ได้	เห็น (usage)	ฟรี (จ่ายเฉพาะ API call)
Customer managed key (CMK)	ลูกค้าสร้างและควบคุมเต็ม	ได้ (key policy เอง)	เปิด/ปิด/on-demand ได้	ได้ (ผ่าน key policy + grant)	เห็นเต็ม	จ่ายต่อ key/เดือน + API call

จุดตัดสินใจสำคัญ: เมื่อโจทย์ต้องการ control over key policy, audit การใช้ key, cross-account access, key rotation ที่กำหนดเอง, หรือ ability to disable/revoke key → ต้องเป็น customer managed key เท่านั้น AWS managed key ใช้ง่าย (default) แต่แก้ policy ไม่ได้และแชร์ข้าม account ไม่ได้ กับดักที่ออกสอบบ่อย: โจทย์บอก must be able to revoke access to encrypted data immediately across the organization → customer managed key (disable key แล้วทุกคน decrypt ไม่ได้ทันที) — AWS managed key ทำไม่ได้

Key material origin: customer managed key มี option สร้าง key material ได้หลายแบบ — KMS สร้างเอง (default), import key material เอง (BYOK — bring your own key, ลูกค้าถือ material ต้นทาง), หรือใช้ custom key store ที่ backed ด้วย CloudHSM (2.7)

2.4 Key Policy vs IAM vs Grants (บทที่ 03 ฝากมา)

การควบคุมว่าใครใช้ KMS key ได้ มี 3 กลไกที่ทำงานร่วมกัน — นี่คือจุดที่บทที่ 03 ฝากมาให้ลงลึก:

Key policy = resource-based policy ที่ติดกับตัว key เอง (ดูบทที่ 03 — resource-based policy) เป็น แหล่งอำนาจหลัก (root of trust) ของ key ทุก key ต้องมี key policy และถ้า key policy ไม่อนุญาต ไม่มีทางเข้าถึง key ได้เลยแม้ IAM จะ allow — key policy คือ “ประตูใหญ่”
IAM policy = identity-based policy ที่ให้ principal ใช้ KMS action ได้ แต่จะมีผลก็ต่อเมื่อ key policy delegate อำนาจให้ IAM ผ่าน statement "Principal": {"AWS": "arn:aws:iam::<account>:root"} + kms:* (การมอบอำนาจให้ IAM ของ account นั้นตัดสินใจ) — นี่คือ pattern มาตรฐาน
Grant = การมอบสิทธิ์แบบ ชั่วคราวและ programmatic ให้ principal ใช้ key เฉพาะ operation (encrypt/decrypt/generate) โดยไม่แก้ key policy เหมาะกับ AWS service ที่ต้องใช้ key ในนามของ user (เช่น EBS, Aurora สร้าง grant อัตโนมัติ) และ revoke ได้ทันที

ตัวอย่าง key policy ที่ delegate ให้ IAM ของ account เจ้าของ + ให้ cross-account principal decrypt ได้:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMDelegation",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowCrossAccountDecrypt",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:role/AppRole" },
      "Action": ["kms:Decrypt", "kms:DescribeKey"],
      "Resource": "*"
    }
  ]
}

คำอธิบาย: statement แรกมอบอำนาจให้ IAM ของ account 1111... (root = ทั้ง account) ตัดสินใจสิทธิ์ผ่าน IAM policy ตามปกติ; statement สองอนุญาตให้ role ใน account 4444... decrypt ได้โดยตรง จุดสำคัญ cross-account KMS ต้องผ่านสองด่าน (เชื่อมโยงบทที่ 03 — cross-account = AND): (1) key policy ใน account เจ้าของ key ต้อง allow principal ปลายทาง และ (2) IAM policy ใน account ปลายทางต้อง allow kms:Decrypt บน key ARN นั้น — ขาดด้านใดด้านหนึ่งไม่ได้ กับดักออกสอบ: เปิดแค่ IAM ฝั่ง consumer แต่ลืมแก้ key policy → decrypt ไม่ได้

2.5 Envelope Encryption — กลไกที่ทำให้ KMS scale

KMS ไม่ได้เข้ารหัสข้อมูลก้อนใหญ่โดยตรง (จำกัดที่ 4 KB ต่อ request) แต่ใช้ envelope encryption:

Service ขอ data key จาก KMS ด้วย GenerateDataKey — KMS คืน data key มา 2 รูป: plaintext (ใช้เข้ารหัสข้อมูลจริงในเครื่อง) และ encrypted (เข้ารหัสด้วย KMS key)
ข้อมูลจริงถูกเข้ารหัสด้วย plaintext data key (ทำในเครื่อง เร็ว ไม่จำกัดขนาด)
plaintext data key ถูกทิ้งจาก memory เก็บเฉพาะ encrypted data key ไว้ข้าง ๆ ข้อมูล
ตอน decrypt: ส่ง encrypted data key กลับให้ KMS Decrypt → ได้ plaintext data key คืน → ถอดรหัสข้อมูล

ทำไมสำคัญ: envelope encryption คือเหตุผลที่ S3/EBS/RDS เข้ารหัส object/volume ขนาด TB ได้โดย KMS ยัง scale — KMS จัดการแค่ data key เล็ก ๆ นี่ยังเป็นฐานของ KMS request cost (ทุก encrypt/decrypt = API call) ซึ่งเป็นเหตุผลที่ S3 มี S3 Bucket Keys (ลด KMS API call โดยใช้ bucket-level data key ลดต้นทุนได้มากเมื่อมี object จำนวนมหาศาล — เชื่อมโยงบทที่ 06)

2.6 Multi-Region Keys และ Key Rotation

Multi-region KMS keys: ปกติ KMS key เป็น region-scoped (key ใน us-east-1 ใช้ decrypt ข้อมูลใน eu-west-1 ไม่ได้) Multi-region key แก้ปัญหานี้โดยให้ primary key + replica key ที่มี key material เดียวกัน (same key ID) ข้าม region ทำให้ข้อมูลที่เข้ารหัสใน region หนึ่ง decrypt ได้ใน region อื่นด้วย replica key โดยไม่ต้อง re-encrypt

use case หลัก: DR/multi-region (เชื่อมโยงบทที่ 08) — เมื่อ replicate encrypted data ข้าม region (S3 CRR, Aurora Global Database, DynamoDB Global Tables, EBS snapshot copy) ต้องมี key ที่ decrypt ได้ทั้งสองฝั่ง multi-region key ทำให้ไม่ต้อง decrypt+re-encrypt ระหว่างทาง
trade-off: แต่ละ replica ยังมี key policy/grant ของตัวเอง (บริหารแยกต่อ region) และการมี key material เดียวกันข้าม region เป็น security consideration (ต้อง trust ทั้งสอง region)

Key rotation:

automatic rotation (customer managed key): KMS สร้าง key material ใหม่ ทุก 1 ปี (ปรับ interval ได้ [uncertain รายละเอียดล่าสุด]) โดย เก็บ material เก่าไว้ decrypt ข้อมูลเดิม — key ID/ARN คงเดิม โปร่งใสต่อ application ไม่ต้อง re-encrypt
manual rotation: สร้าง key ใหม่แล้ว update alias ให้ชี้ key ใหม่ (จำเป็นเมื่อใช้ imported key material ที่ไม่รองรับ auto rotation)
AWS managed key: rotate อัตโนมัติทุก 1 ปี แก้ไม่ได้

จุดออกสอบ: rotate encryption keys annually with no application change → customer managed key + enable automatic rotation (โปร่งใส) ไม่ใช่ manual re-encryption

2.7 AWS CloudHSM — เมื่อไหร่จำเป็น (บทที่ 03 ฝากมา)

AWS CloudHSM คือ dedicated hardware security module (single-tenant) ที่ลูกค้าควบคุมเต็มและ AWS เข้าถึง key material ไม่ได้เลย ต่างจาก KMS ที่เป็น multi-tenant managed service:

มิติ	AWS KMS	AWS CloudHSM
tenancy	multi-tenant (shared HSM หลัง KMS)	single-tenant dedicated HSM
ใครถือ key	AWS host (ลูกค้าควบคุมผ่าน policy)	ลูกค้าเท่านั้น (AWS เข้าไม่ถึง)
operational overhead	ต่ำ (fully managed)	สูง (ลูกค้าจัดการ cluster, HA, user)
FIPS validation	FIPS 140-2 Level 3 [uncertain ระดับล่าสุด อาจเป็น 140-3]	FIPS 140-2 Level 3 [uncertain]
integration	native กับ ~ทุก AWS service	ผ่าน custom key store หรือ PKCS#11/JCE/CNG

เมื่อไหร่ต้อง CloudHSM (ไม่ใช่ KMS): (1) มี regulatory requirement ที่บังคับ single-tenant HSM หรือให้ ลูกค้าถือ key material แต่เพียงผู้เดียว (AWS ต้องเข้าไม่ถึงแม้ทางเทคนิค), (2) ต้องรัน cryptographic operation เฉพาะ (SSL offload, custom PKI, Oracle TDE with own HSM), (3) ต้องการ FIPS 140-2 Level 3 dedicated เป็นข้อบังคับสัญญา ในทางปฏิบัติ default คือ KMS เสมอ (operational overhead ต่ำกว่ามาก) — CloudHSM ตอบเฉพาะเมื่อโจทย์ระบุ dedicated/single-tenant HSM, AWS must not have access to key material, หรือ FIPS 140-2 Level 3 dedicated ชัดเจน สามารถผสมได้ด้วย KMS custom key store (KMS เป็นหน้าบ้านให้ integration ง่าย แต่ key material อยู่ใน CloudHSM cluster ของลูกค้า)

2.8 Secrets Manager vs SSM Parameter Store (บทที่ 03/07 ฝากมา)

ต่อยอดหลัก “อย่า hardcode credential” (บทที่ 03) — สอง service เก็บ secret/config ที่ต้องแยกให้ขาด:

มิติ	AWS Secrets Manager	SSM Parameter Store
จุดประสงค์หลัก	secret (DB credential, API key)	config + secret (SecureString)
automatic rotation	มี built-in (Lambda rotation, native กับ RDS/Redshift/DocumentDB)	ไม่มี built-in (ต้องเขียนเอง)
encryption	KMS เสมอ	Standard=plaintext, SecureString=KMS
cross-account/resource policy	มี	มี (advanced tier)
ค่าใช้จ่าย	จ่ายต่อ secret/เดือน + API call	Standard ฟรี, Advanced มีค่าใช้จ่าย
ขนาด/จำนวน	ใหญ่กว่า	Standard 4 KB, Advanced 8 KB
generate random secret	มี (`GetRandomPassword`)	ไม่มี

จุดตัดสินใจ: โจทย์ที่มีคำว่า automatic credential rotation, rotate database password every 30 days, หรือ integrate rotation with RDS → Secrets Manager เสมอ (เชื่อมโยงบทที่ 07 — RDS Proxy ดึง credential จาก Secrets Manager และรองรับ native rotation) ส่วนโจทย์ store configuration values cost-effectively, store non-sensitive config หรือ free → Parameter Store (Standard tier ฟรี) กับดัก: ตอบ Secrets Manager สำหรับ plain config ที่ไม่ต้อง rotate = จ่ายแพงเกินจำเป็น; ตอบ Parameter Store สำหรับ automatic rotation = ต้องเขียน rotation เอง(operational overhead สูง)

Secrets Manager rotation กลไก: Secrets Manager เรียก Lambda rotation function ที่ทำ 4 ขั้น (createSecret → setSecret → testSecret → finishSecret) โดยใช้ strategy สอง credential สลับกัน (alternating users) เพื่อไม่ให้ connection ขาดตอน rotate — สำคัญกับ zero-downtime credential rotation และทำงานคู่ RDS Proxy (บทที่ 07) ที่ pool connection ด้วย credential จาก Secrets Manager

2.9 ACM & ACM Private CA

AWS Certificate Manager (ACM) จัดการ public TLS certificate ฟรีสำหรับใช้กับ AWS service (CloudFront, ALB, API Gateway) — auto-renew ให้ ลด operational overhead ของการต่ออายุ cert (จุดออกสอบ avoid certificate expiry outages → ACM auto-renewal) ข้อจำกัดสำคัญ: ACM public cert export ไม่ได้ (private key อยู่กับ AWS) ใช้ terminate TLS ได้เฉพาะบน AWS managed service ที่ integrate — ใช้บน EC2 โดยตรงไม่ได้

ACM Private CA (AWS Private Certificate Authority) เป็น managed private CA สำหรับออก certificate ภายในองค์กร (internal service, mTLS, IoT device, EKS pod identity) เมื่อโจทย์ต้องการ:

issue private/internal certificates at scale → ACM Private CA
mutual TLS (mTLS) authentication between services → ACM Private CA ออก client cert + ALB/API Gateway ตรวจ client cert
build internal PKI without managing CA infrastructure → ACM Private CA (แทนการรัน Microsoft CA/OpenSSL เอง)

trade-off: ACM Private CA มีค่าใช้จ่ายต่อ CA/เดือน + ต่อ cert ที่ออก — สำหรับ public-facing ใช้ ACM public (ฟรี) ก็พอ

2.10 Data Protection — Encryption at Rest / in Transit (บทที่ 06/07/08 ฝากมา)

รวม encryption ของทุก storage/database ที่บทก่อนฝากมาไว้ที่นี่ (ทุกตัวใช้ KMS envelope encryption เป็นฐาน):

บริการ	encryption at rest	หมายเหตุ
Amazon S3	SSE-S3 / SSE-KMS / SSE-C / DSSE-KMS (ดู 2.11)	encryption default เปิดแล้วทุก bucket
Amazon EBS	KMS (encryption by default ตั้งได้ระดับ account/region)	snapshot สืบทอด encryption; copy เปลี่ยน key ได้
Amazon EFS / FSx	KMS at rest + TLS in transit	(บทที่ 06)
Amazon RDS/Aurora	KMS (ต้องเปิดตอนสร้าง — enable ทีหลังต้อง snapshot+restore)	read replica/snapshot สืบทอด; cross-region copy ต้อง re-encrypt ด้วย key ปลายทาง
Amazon DynamoDB	KMS (default owned key, เลือก CMK ได้)	(บทที่ 07)
AWS Backup	KMS (independent key ต่อ vault)	cross-region/account copy ต้องมี key ปลายทาง (บทที่ 08)

จุดออกสอบสำคัญที่บทก่อนฝากมา:

RDS encryption เปิดหลังสร้างไม่ได้ — ต้อง snapshot → copy snapshot พร้อม encrypt → restore (เชื่อมโยงบทที่ 07) โจทย์ encrypt existing unencrypted RDS = ทำผ่าน snapshot ไม่ใช่ toggle
Cross-region encrypted replica/backup ต้องใช้ key ที่ decrypt ได้ที่ปลายทาง (เชื่อมโยงบทที่ 08) — cross-region snapshot copy ต้อง re-encrypt ด้วย key ใน region ปลายทาง หรือใช้ multi-region key (2.6) เพื่อไม่ต้องจัดการหลาย key; key policy สำหรับ cross-account backup ต้อง allow AWS Backup service principal
IAM database authentication (เชื่อมโยงบทที่ 07): RDS/Aurora รองรับ auth ด้วย IAM token (15 นาที) แทน password → ไม่ต้องเก็บ DB password เลย เหมาะ avoid managing database passwords (ทางเลือกของ Secrets Manager rotation สำหรับบาง use case)

Encryption in transit: TLS ทุก endpoint ที่รับ traffic (ALB/CloudFront/API Gateway terminate TLS ด้วย ACM cert), enforce ผ่าน SG/bucket policy (aws:SecureTransport), และ VPC traffic เข้ารหัสได้ผ่าน service ที่รองรับ TLS — สำหรับ compliance ที่ต้อง encrypt ทุก hop รวม intra-VPC ใช้ application-level TLS หรือ Nitro-based instance (in-transit encryption ระหว่าง instance บาง type)

2.11 S3 Encryption Options เต็ม (บทที่ 06 ฝากมา)

S3 มี 4 แบบที่ต้องแยก — เชื่อมโยงบทที่ 06 (บทนี้เป็นเจ้าของรายละเอียด encryption):

option	ใครถือ/จัดการ key	เห็นใน CloudTrail	use case
SSE-S3 (`AES256`)	AWS จัดการ key เต็ม (default)	ไม่เห็น key usage	encryption at rest พื้นฐาน ฟรี least ops
SSE-KMS (`aws:kms`)	KMS key (AWS managed หรือ CMK)	เห็น (audit ทุก decrypt)	ต้อง audit/control key/rotation → CMK
SSE-C	ลูกค้าถือ key เอง ส่งมากับทุก request	ไม่เก็บ key	ลูกค้าต้องถือ key material นอก AWS
DSSE-KMS	double-layer KMS encryption	เห็น	regulatory ที่บังคับ double encryption

จุดตัดสินใจ: audit every access to encrypted objects หรือ control who can decrypt → SSE-KMS ด้วย customer managed key (key policy จำกัดได้); simplest at-rest encryption, no key management → SSE-S3; customer must retain key material outside AWS → SSE-C; regulatory double encryption → DSSE-KMS จุดต้นทุน: SSE-KMS มี KMS API cost ต่อ request — ใช้ S3 Bucket Keys (2.5) ลด KMS call ได้มากเมื่อ object เยอะ

2.12 CloudTrail — บันทึกทุก API (เจ้าของ audit trail)

AWS CloudTrail บันทึก API activity ทุกอย่างในบัญชี เป็นรากฐานของ audit และ incident response:

Management events: control plane operation (CreateBucket, AssumeRole, StopInstance) — บันทึก default ฟรี
Data events: data plane operation ปริมาณสูง (S3 GetObject/PutObject, Lambda Invoke, DynamoDB item) — ต้องเปิดเอง มีค่าใช้จ่าย สำคัญกับ audit who accessed specific S3 objects
Organization trail: trail เดียวจาก management account ที่ครอบทุก account ใน org ส่ง log ไป Log Archive account (เชื่อมโยงบทที่ 02) — member account ปิด/แก้ไม่ได้ = tamper-resistant central audit
Log file integrity validation: hash chain (SHA-256 + digest file) พิสูจน์ว่า log ไม่ถูกแก้
CloudTrail Lake: managed data store แบบ SQL-queryable สำหรับ analyze CloudTrail event โดยไม่ต้อง export ไป Athena — ตอบ run SQL queries on audit logs / long-term immutable audit (ทางเลือกของ log → S3 → Athena)

จุดออกสอบ: centralized tamper-proof audit across all accounts → organization trail + Log Archive account + S3 bucket ที่ล็อกด้วย Object Lock/policy + log file integrity validation; track access to sensitive S3 data → เปิด data events (management events ไม่บันทึก object-level access)

2.13 GuardDuty — threat detection (บทที่ 01/02 ฝากมา)

Amazon GuardDuty เป็น detective control (เชื่อมโยงบทที่ 01 — preventive vs detective) ที่ใช้ ML + threat intelligence วิเคราะห์ VPC Flow Logs, DNS logs, CloudTrail events (และ optional: S3, EKS audit, RDS login, Lambda, malware scan) เพื่อตรวจจับพฤติกรรมผิดปกติ โดยไม่ต้อง deploy agent (analyze log ที่มีอยู่แล้ว = least ops)

ตรวจจับ: cryptomining, credential exfiltration, communication กับ known-malicious IP, port scanning, anomalous API calls, unusual data access
Organization-wide: กำหนด delegated administrator (Audit account, เชื่อมโยงบทที่ 02) เพื่อ enable GuardDuty ทุก account อัตโนมัติและ aggregate finding ที่เดียว
จุดออกสอบ: detect compromised instances / malicious activity with least operational overhead → GuardDuty (agentless, ML) — ไม่ใช่ Inspector (นั่นคือ vulnerability, 2.16) หรือ Macie (นั่นคือ PII, 2.15) finding ของ GuardDuty ป้อนเข้า Security Hub และ trigger EventBridge → automated remediation (2.17)

2.14 Security Hub — aggregation + standards (บทที่ 02 ฝากมา)

AWS Security Hub เป็น ศูนย์รวม (aggregator) ของ security finding จากหลาย service (GuardDuty, Inspector, Macie, IAM Access Analyzer, third-party) ในรูปแบบมาตรฐาน ASFF (AWS Security Finding Format) พร้อมรัน compliance standard อัตโนมัติ:

Security standards: AWS Foundational Security Best Practices, CIS AWS Benchmark, PCI DSS, NIST — Security Hub run automated check และให้ compliance score
Cross-account/region aggregation: aggregate finding ทั้ง org ที่ delegated admin (Audit account) + cross-region aggregation ไปยัง home region เดียว
จุดแยกกับ GuardDuty: GuardDuty = สร้าง threat finding; Security Hub = รวบรวมและจัดลำดับ finding จากหลายแหล่ง + วัด compliance เมื่อโจทย์ single pane of glass for security findings across accounts หรือ continuous compliance against CIS/PCI → Security Hub finding ทั้งหมดส่งต่อ EventBridge เพื่อ automated response ได้

2.15 Detective & Macie

Amazon Detective ทำ root cause analysis / investigation ต่อยอดจาก GuardDuty finding — สร้าง behavior graph จาก log (VPC Flow, CloudTrail, GuardDuty) เพื่อให้ analyst เจาะดูว่า “เกิดอะไรขึ้นก่อน-หลัง finding นี้” โดยไม่ต้อง query log เอง เมื่อโจทย์ investigate the root cause / scope of a security finding → Detective (ไม่ใช่ GuardDuty ที่แค่ detect)

Amazon Macie ใช้ ML ค้นหาและจัดประเภท sensitive data (PII, PHI, credential) ใน S3 — ตรวจว่า bucket ไหนมี PII, ตั้งค่า public ผิด, หรือ unencrypted เมื่อโจทย์ discover PII/sensitive data in S3, identify buckets containing credit card numbers, หรือ data classification for compliance → Macie (ไม่ใช่ GuardDuty/Inspector) finding ของ Macie ก็เข้า Security Hub + EventBridge

2.16 AWS Config & Inspector — posture (บทที่ 01/02 ฝากมา)

AWS Config เป็น detective control ที่บันทึก configuration state + history ของทุก resource และประเมินกับ Config rules (managed หรือ custom Lambda):

Config rules: ตรวจ compliance ต่อเนื่อง (เช่น “S3 bucket ต้อง encrypted”, “EBS ต้อง encrypted”, “SG ห้ามเปิด 0.0.0.0/0 port 22”)
Conformance packs: ชุด Config rules + remediation ที่ deploy เป็นแพ็กเดียว (PCI, HIPAA, operational best practices) — deploy ทั้ง org ได้
Remediation: ผูก Config rule กับ SSM Automation document เพื่อ auto-fix เมื่อ non-compliant (เช่น เจอ SG เปิดกว้าง → auto revoke)
Config aggregator: รวม config/compliance ทั้ง org ที่ Audit account (เชื่อมโยงบทที่ 02)
จุดแยก: Config = config compliance & change tracking (เชื่อมโยงบทที่ 01 — detect/report → Config); ต่างจาก GuardDuty (threat) และ Inspector (vulnerability) โจทย์ detect and auto-remediate non-compliant configuration → Config rule + SSM remediation

Amazon Inspector สแกน software vulnerability (CVE) + network exposure ของ EC2, ECR container image, และ Lambda — automated, agentless (ใช้ SSM agent), continuous rescan เมื่อมี CVE ใหม่ เมื่อโจทย์ scan EC2/containers for known vulnerabilities (CVE) หรือ identify unintended network exposure → Inspector (ไม่ใช่ Config ที่ดู config, ไม่ใช่ GuardDuty ที่ดู threat behavior)

2.17 Automated Remediation — EventBridge + SSM (บทที่ 01 ฝากมา)

pattern มาตรฐานของ security automation ระดับ Pro: detective finding → event → automated action

GuardDuty/Config/Security Hub finding
        │ (finding เป็น event)
        ▼
   Amazon EventBridge rule (filter ตาม finding type/severity)
        │
        ├──► SSM Automation runbook (isolate instance, revoke SG, disable key)
        ├──► Lambda (custom remediation / enrichment)
        └──► SNS (notify security team)

EventBridge เป็น event router (เชื่อมโยงบทที่ 05) จับ finding ตาม pattern แล้วส่งไป target
SSM Automation document (runbook) ทำ action ที่ผูกไว้ (quarantine instance ด้วยการเปลี่ยน SG เป็น isolation SG, snapshot volume, revoke key grant, tag resource)
จุดออกสอบ: automatically respond to security findings without human intervention → EventBridge + SSM Automation/Lambda เป็นคำตอบ pattern เดียวกันเสมอ ตัวอย่าง: GuardDuty เจอ compromised instance → EventBridge → SSM Automation ย้าย instance ไป forensic SG (deny all outbound) + snapshot memory/disk + แจ้งทีม

2.18 Edge/Perimeter — WAF, Shield, Firewall Manager (บทที่ 04 ฝากมา)

บทที่ 04 ฝาก WAF/Shield เชิงลึกมาที่นี่ (วางบน CloudFront/ALB/API Gateway):

AWS WAF = web application firewall (L7) กรอง HTTP(S) request ตาม rule:

Managed rule groups: ชุด rule สำเร็จจาก AWS/marketplace (SQL injection, XSS, OWASP Top 10, known bad inputs, bot control) — ลด operational overhead ของการเขียน rule เอง
Rate-based rules: จำกัด request ต่อ IP ต่อช่วงเวลา (กัน brute-force / L7 flood)
Custom rules: match IP set, geo, header, URI, body, size
deploy บน CloudFront (global edge), ALB (regional), API Gateway, AppSync, Cognito

AWS Shield:

Shield Standard = ฟรี auto ทุกบัญชี ป้องกัน common L3/L4 DDoS (SYN flood, UDP reflection)
Shield Advanced = จ่ายเพิ่ม เพิ่ม: ป้องกัน DDoS ระดับสูง L3/L4/L7, DDoS Response Team (DRT) ช่วยตอบสนอง, cost protection (คืนค่า scaling ที่เกิดจาก DDoS), real-time metrics, และ auto-deploy WAF rule (automatic application layer DDoS mitigation) เมื่อโจทย์ protect against large-scale DDoS with SLA/cost protection/expert support → Shield Advanced (Standard ไม่มี L7/DRT/cost protection)

AWS Firewall Manager = จัดการ WAF/Shield Advanced/Network Firewall/Security Group policy ทั้ง organization จากที่เดียว (เชื่อมโยงบทที่ 02 — org-wide) — auto-apply policy กับ account/resource ใหม่ที่เข้ามา เมื่อโจทย์ enforce WAF rules across all accounts and new resources automatically → Firewall Manager (ไม่ใช่ตั้ง WAF ทีละ account) ต้องใช้คู่ Organizations + delegated admin

Data perimeter (บทที่ 04 ฝากมา): การสร้างขอบเขตให้ “เฉพาะ identity ที่เชื่อถือเข้าถึงเฉพาะ resource ที่เชื่อถือจาก network ที่เชื่อถือ” ผ่าน VPC endpoint policy + resource policy Condition (aws:PrincipalOrgID, aws:SourceVpce, aws:ResourceOrgID) + RCP (Resource Control Policy) ระดับ org (เชื่อมโยงบทที่ 03) — กันข้อมูลไม่ให้ถูกส่งออกไปยัง account/network นอกองค์กร (data exfiltration prevention) โจทย์ ensure S3 data can only be accessed from within our organization/VPC → bucket policy + endpoint policy + aws:PrincipalOrgID/aws:SourceVpce condition

2.19 Incident Response บน AWS

การออกแบบ incident response (IR) ที่ SA Pro ต้องรู้:

Forensics/security account แยก: เก็บ evidence (snapshot, log) ใน account แยกที่ investigator เข้าถึง เพื่อไม่ให้ attacker ที่ยึด production account ทำลายหลักฐาน (เชื่อมโยงบทที่ 02 — account เป็น isolation แข็งสุด)
Isolation: quarantine compromised instance โดย เปลี่ยน Security Group เป็น isolation SG (deny all) — ไม่ terminate ทันที (จะเสีย memory/volatile evidence) แต่ snapshot EBS + capture memory ก่อน
Evidence preservation: EBS snapshot (immutable), copy log ไป forensics account, ใช้ S3 Object Lock (บทที่ 06) กัน evidence ถูกลบ
Break-glass access: เตรียม emergency role ที่มีสิทธิ์สูง เก็บ credential ปิดผนึก (MFA hardware, ใน vault) ใช้เฉพาะภาวะฉุกเฉินเมื่อ IAM/Identity Center ปกติล่ม — ต้อง log ทุกการใช้ (CloudTrail) + alert ทันที และ review ภายหลัง เมื่อโจทย์ emergency access when normal identity provider is unavailable → break-glass role ใน account พร้อม strong audit
automate IR ด้วย EventBridge + SSM (2.17) เพื่อลด response time

2.20 Compliance — Artifact & Audit Manager

AWS Artifact = portal ดาวน์โหลด AWS compliance report/agreement (SOC, ISO, PCI DSS, HIPAA BAA) — สำหรับส่งให้ auditor พิสูจน์ว่า “AWS (ฝั่ง of the cloud) compliant” เมื่อโจทย์ provide auditor with AWS SOC 2 report → Artifact
AWS Audit Manager = automate การเก็บ evidence ต่อ compliance framework (CIS, PCI, GDPR, custom) โดยดึงหลักฐานจาก Config/CloudTrail/Security Hub มาประกอบเป็น audit report อัตโนมัติ — ลดงาน manual ของการรวบรวมหลักฐาน เมื่อโจทย์ continuously collect evidence for compliance audits / automate audit preparation → Audit Manager (ไม่ใช่ Artifact ที่แค่ดาวน์โหลด report ของ AWS)

จุดแยก: Artifact = report ของ AWS; Audit Manager = รวบรวม evidence ของ workload ลูกค้า; Config = ตรวจ compliance ต่อเนื่อง; Security Hub = compliance score จาก standard — สี่ตัวนี้ทำงานคนละหน้าที่ในสาย compliance

3. ตารางเปรียบเทียบบริการ

3.1 detective service — ตรวจอะไร → ใช้ตัวไหน

requirement / keyword	บริการ	เหตุผล / trade-off
detect malicious activity / compromised instance / threat	GuardDuty	ML บน log ที่มีอยู่ agentless least ops; ไม่สแกน CVE/PII
scan for software vulnerabilities (CVE) / network exposure	Inspector	vulnerability assessment EC2/ECR/Lambda; ไม่ดู threat behavior
discover / classify PII / sensitive data in S3	Macie	data classification ML บน S3 เท่านั้น
config compliance / detect non-compliant resource + auto-remediate	Config (+ SSM remediation)	บันทึก config state + rule; detective (บทที่ 01)
single pane of glass / aggregate findings + CIS/PCI compliance score	Security Hub	aggregator + standards; ไม่สร้าง finding เอง
investigate root cause / scope of a finding	Detective	behavior graph ต่อยอดจาก GuardDuty
record every API call / immutable audit trail	CloudTrail (org trail + data events)	audit ทุก API; data event สำหรับ object-level

3.2 key/secret management — เปรียบเทียบ

requirement / keyword	บริการ/option	เหตุผล / trade-off
encrypt at rest, control key policy/rotation, audit usage, revoke access	KMS customer managed key	ควบคุมเต็ม + CloudTrail; จ่ายต่อ key
simplest encryption, no key management	KMS AWS managed key / SSE-S3	ฟรี/ง่าย แต่แก้ policy ไม่ได้
single-tenant HSM / AWS must not access key material / FIPS L3 dedicated	CloudHSM	ลูกค้าถือ key เต็ม; operational overhead สูง
automatic database credential rotation	Secrets Manager	native rotation กับ RDS; จ่ายต่อ secret
store config cost-effectively / free	Parameter Store (Standard)	ฟรี; ไม่มี built-in rotation
public TLS cert, auto-renew	ACM	ฟรี, integrate AWS service; export ไม่ได้
issue internal/private certs, mTLS	ACM Private CA	managed private PKI; จ่ายต่อ CA + cert

3.3 perimeter/response — เปรียบเทียบ

requirement / keyword	บริการ	เหตุผล / trade-off
filter L7 / SQL injection, XSS, bad bots, rate limit	WAF (managed + rate-based rules)	บน CloudFront/ALB/API GW
basic DDoS L3/L4	Shield Standard	ฟรี auto
large-scale DDoS, L7 mitigation, cost protection, DRT support	Shield Advanced	จ่ายเพิ่ม; SLA + expert
enforce WAF/SG/Shield across all accounts + new resources	Firewall Manager	org-wide auto-apply; ต้องมี Organizations
auto respond to findings, no human	EventBridge + SSM Automation/Lambda	pattern มาตรฐาน security automation
restrict data access to org/VPC only (anti-exfiltration)	data perimeter (endpoint policy + RCP + `aws:PrincipalOrgID`)	บทที่ 03/04
download AWS SOC/PCI report	Artifact	report ของ AWS
automate evidence collection for audits	Audit Manager	evidence ของ workload ลูกค้า

4. สถาปัตยกรรมตัวอย่างและ trade-off

4.1 Organization-wide security baseline (multi-account)

โจทย์: องค์กรมี 80 account ใน AWS Organizations ต้องการ centralized security ที่เปิดใช้อัตโนมัติทุก account ใหม่ รวม finding ที่เดียว บังคับ WAF ทั้ง org และ audit trail ที่ลบไม่ได้

สถาปัตยกรรม:

Audit account (บทที่ 02) เป็น delegated administrator ของ GuardDuty + Security Hub + Config aggregator + Macie → enable ทุก account อัตโนมัติผ่าน Organizations, aggregate finding ที่เดียว
Log Archive account (บทที่ 02) รับ organization CloudTrail (management + data events) → S3 bucket ที่ล็อก Object Lock + log file integrity validation (immutable audit)
Firewall Manager (delegated admin) บังคับ WAF policy + Shield Advanced + baseline SG ทุก account/resource ใหม่
SCP (บทที่ 02) เป็น preventive layer: deny ปิด GuardDuty/Config/CloudTrail, require encryption
Security Hub finding → EventBridge → SSM Automation (4.3) เพื่อ auto-remediate

trade-off: delegated admin แยกจาก management account (best practice — ไม่รัน security tooling บน payer) แลกด้วยการตั้งค่าเริ่มต้นที่ซับซ้อน แต่ได้ least operational overhead เมื่อ account เพิ่ม (auto-enroll) เทียบกับตั้ง security ทีละ account ที่ไม่ scale — เชื่อมโยงบทที่ 02 delegated administration

4.2 Encrypted data protection ข้าม region สำหรับ regulated workload

โจทย์: workload ทางการเงินต้อง encrypt data at rest ด้วย key ที่องค์กรควบคุมและ audit ได้, replicate ข้าม region เพื่อ DR (บทที่ 08), และ revoke access to all encrypted data immediately ได้เมื่อเกิดเหตุ

สถาปัตยกรรม:

KMS multi-region customer managed key (primary us-east-1 + replica eu-west-1) → S3 (SSE-KMS) + EBS + RDS ใช้ key นี้; data replicate ข้าม region (S3 CRR/Aurora Global DB) decrypt ได้ทั้งสองฝั่งโดยไม่ต้อง re-encrypt
Key policy จำกัดเฉพาะ role ที่จำเป็น + delegate ให้ IAM; ทุก decrypt log ใน CloudTrail (audit)
S3 Bucket Keys ลด KMS cost เมื่อ object เยอะ
revoke: disable key → ทุก decrypt ล้มเหลวทันทีทั้ง org (ทำได้เพราะเป็น customer managed key)
AWS Backup vault ใช้ key แยก + Vault Lock Compliance mode (บทที่ 08) กัน backup ถูกลบ

trade-off: multi-region key ให้ความสะดวก DR (decrypt ได้สองฝั่ง) แต่ต้อง trust key material ในสอง region และบริหาร key policy แยกต่อ replica; customer managed key มีค่าใช้จ่ายต่อ key + KMS API แต่ได้ control/audit/revoke ที่ regulated workload ต้องการ (AWS managed key ทำไม่ได้) — เชื่อมโยงบทที่ 06/07/08

4.3 Automated threat detection & response

โจทย์: ต้องการตรวจจับ compromised EC2 และตอบสนองอัตโนมัติภายในไม่กี่นาทีโดยไม่ต้องมีคนเฝ้า พร้อมเก็บ evidence สำหรับ forensics

สถาปัตยกรรม:

GuardDuty ตรวจจับ (cryptomining/C2 communication) → finding
EventBridge rule filter finding severity สูง → trigger SSM Automation runbook
runbook: (1) เปลี่ยน SG ของ instance เป็น isolation SG (deny all outbound — ตัด C2 แต่ instance ยังรัน), (2) snapshot EBS เก็บ evidence, (3) tag instance quarantined, (4) SNS แจ้ง security team
evidence (snapshot) share ไป forensics account แยก (บทที่ 02) ที่ investigator ใช้ Detective เจาะ root cause
finding aggregate ที่ Security Hub

trade-off: automation ลด response time (นาที แทนชั่วโมง) และไม่พึ่งคนเฝ้า 24/7 แต่ต้องออกแบบ runbook ระวังไม่ให้ isolate ผิด (false positive ทำ production ล่ม) — จึงมัก isolate + snapshot ก่อน (ไม่ terminate) เพื่อรักษา evidence และให้คน review ก่อน terminate จริง เชื่อมโยง 2.17/2.19

4.4 mTLS สำหรับ internal microservices

โจทย์: microservices ภายในต้อง authenticate กันด้วย mutual TLS โดยไม่รัน CA infrastructure เอง และ cert ต้องหมุนอัตโนมัติ

สถาปัตยกรรม:

ACM Private CA ออก private cert ให้แต่ละ service (client + server cert)
ALB / API Gateway config mTLS: ตรวจ client cert กับ trust store (CA bundle) ก่อนยอมให้ผ่าน
cert lifecycle จัดการผ่าน ACM (auto-renew) — service ดึง cert จาก ACM/Secrets Manager
traffic in transit เข้ารหัส TLS end-to-end

trade-off: ACM Private CA มีค่าใช้จ่ายต่อ CA/เดือน + ต่อ cert แต่ประหยัดกว่ารัน + secure Microsoft CA/OpenSSL เอง (operational + security overhead) และ integrate native กับ ALB mTLS — เหมาะ zero-trust internal network เชื่อมโยง 2.9

5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ

สับสน GuardDuty / Inspector / Macie: GuardDuty = threat behavior (log-based ML), Inspector = CVE vulnerability (EC2/ECR/Lambda), Macie = PII ใน S3 — โจทย์ malicious activity → GuardDuty, known vulnerabilities → Inspector, sensitive data discovery → Macie
เปิดแค่ IAM ฝั่ง consumer แต่ลืม key policy (cross-account KMS): cross-account ต้องผ่านสองด่าน (key policy ฝั่ง owner AND IAM ฝั่ง consumer) — ลืมด่านใดด่าน decrypt ไม่ได้ (เชื่อมโยงบทที่ 03)
ตอบ AWS managed key เมื่อโจทย์ต้อง revoke/control/audit/rotate เอง: AWS managed key แก้ policy/rotate เองไม่ได้และ revoke ทันทีไม่ได้ — ต้อง customer managed key
ตอบ CloudHSM ทั้งที่ KMS พอ: CloudHSM ตอบเฉพาะ single-tenant HSM / AWS must not access key / FIPS L3 dedicated — ไม่งั้น KMS เสมอ (operational overhead ต่ำกว่ามาก) การตอบ CloudHSM แบบ default = over-engineering
ตอบ Parameter Store สำหรับ automatic rotation: Parameter Store ไม่มี built-in rotation — automatic credential rotation → Secrets Manager; กลับกันตอบ Secrets Manager สำหรับ plain config = แพงเกินจำเป็น
ลืมเปิด CloudTrail data events เมื่อโจทย์ต้อง audit object-level access: management events ไม่บันทึก S3 GetObject/PutObject — track who accessed specific objects ต้องเปิด data events (มีค่าใช้จ่าย)
ตอบ Shield Standard เมื่อโจทย์ต้อง L7/cost protection/DRT: Standard ฟรีแต่แค่ L3/L4 พื้นฐาน — large-scale DDoS + cost protection + expert support → Shield Advanced
ตั้ง WAF ทีละ account แทน Firewall Manager: enforce across all accounts and new resources automatically → Firewall Manager (org-wide) ไม่ใช่ตั้งทีละ account (ไม่ scale)
สับสน Config กับ Inspector: Config = configuration compliance (encrypted? SG เปิดกว้าง?), Inspector = software CVE — non-compliant configuration → Config, vulnerable software → Inspector
สับสน Artifact กับ Audit Manager: Artifact = ดาวน์โหลด compliance report ของ AWS; Audit Manager = เก็บ evidence ของ workload ลูกค้า อัตโนมัติ
สับสน Security Hub กับ GuardDuty: GuardDuty สร้าง finding; Security Hub รวบรวม finding หลายแหล่ง + compliance standard — single pane of glass / CIS score → Security Hub
terminate compromised instance ทันทีตอน IR: ทำลาย volatile evidence — ต้อง isolate (SG deny all) + snapshot ก่อน แล้วค่อยพิจารณา terminate
encrypt RDS ที่มีอยู่ด้วยการ toggle setting: RDS เปิด encryption หลังสร้างไม่ได้ — ต้อง snapshot → copy พร้อม encrypt → restore (เชื่อมโยงบทที่ 07)
ลืมว่า ACM public cert export ไม่ได้: ใช้ terminate TLS ได้เฉพาะ AWS managed service — บน EC2 โดยตรงต้องใช้ ACM Private CA หรือ import cert เอง
มองข้าม data perimeter/anti-exfiltration: data must not leave the organization → resource policy + VPC endpoint policy + aws:PrincipalOrgID/RCP ไม่ใช่แค่ encryption (เชื่อมโยงบทที่ 03/04)

6. คำถามทบทวน

ข้อ 1. องค์กรต้องการเข้ารหัส S3 object ด้วย key ที่ต้อง audit ได้ว่าใคร decrypt เมื่อไร ควบคุม key policy เอง และสามารถ revoke การเข้าถึงข้อมูลที่เข้ารหัสทั้งหมดได้ทันทีเมื่อเกิดเหตุ ควรใช้อะไร

เฉลย

SSE-KMS ด้วย customer managed key — key policy ควบคุมเอง, ทุก decrypt log ใน CloudTrail, disable key = revoke การเข้าถึงทันที

SSE-S3 ผิด — AWS จัดการ key เต็ม audit key usage ไม่ได้ และ revoke/control ไม่ได้
SSE-KMS ด้วย AWS managed key ผิด — แก้ key policy ไม่ได้และ revoke ทันทีไม่ได้
SSE-C ผิด — ลูกค้าต้องส่ง key ทุก request และ AWS ไม่ audit key usage; overhead สูงและไม่ตรงความต้องการ audit ผ่าน CloudTrail

ข้อ 2. application ต้องเข้าถึง RDS ด้วยรหัสผ่านที่ต้องหมุนอัตโนมัติทุก 30 วันแบบ zero-downtime และไม่อยาก hardcode credential ควรใช้บริการใด

เฉลย

AWS Secrets Manager — native rotation กับ RDS (alternating users, zero-downtime), application ดึง credential runtime; ทำงานคู่ RDS Proxy (บทที่ 07)

SSM Parameter Store ผิด — ไม่มี built-in rotation ต้องเขียน Lambda rotation เอง (operational overhead สูง)
hardcode ใน environment variable ผิด — ละเมิดหลัก least-secret-exposure และ rotate ไม่ได้
KMS ผิด — เข้ารหัส secret ได้แต่ไม่จัดการ rotation ของ credential เอง

ข้อ 3. ต้องตรวจจับ compromised EC2 ที่สื่อสารกับ IP มุ่งร้ายและ cryptomining ทั่วทั้ง 60 account โดย operational overhead ต่ำสุด (ไม่ deploy agent) และรวม finding ที่เดียว ควรออกแบบอย่างไร

เฉลย

GuardDuty เปิดทั้ง org ผ่าน delegated administrator (Audit account) — ML บน VPC Flow/DNS/CloudTrail log ที่มีอยู่ (agentless) + aggregate finding ที่ delegated admin

Inspector ผิด — สแกน CVE vulnerability ไม่ใช่ threat behavior แบบ C2/cryptomining
Macie ผิด — ค้นหา PII ใน S3 ไม่เกี่ยวกับ compromised instance
ติดตั้ง IDS agent บนทุก instance ผิด — operational overhead สูง โจทย์ต้อง least ops

ข้อ 4. ต้องบังคับ WAF managed rules กับทุก public ALB ในทุก account ของ organization รวมถึง account/ALB ที่สร้างใหม่ในอนาคตโดยอัตโนมัติ ควรใช้อะไร

เฉลย

AWS Firewall Manager (คู่ Organizations + delegated admin) — กำหนด WAF policy กลางแล้ว auto-apply กับ resource ที่มีอยู่และที่สร้างใหม่ทุก account

ตั้ง WAF ทีละ account/ALB ผิด — ไม่ scale และ resource ใหม่จะหลุด
Shield Advanced ผิด — เน้น DDoS ไม่ใช่การ enforce WAF rule ทั้ง org
SCP ผิด — เป็น guardrail permission ไม่ deploy WAF rule ให้

ข้อ 5. ระบบต้องการ encrypt data at rest ด้วย key ที่ AWS ต้องไม่สามารถเข้าถึง key material ได้เลย และมี regulatory บังคับ single-tenant FIPS 140-2 Level 3 HSM ควรใช้อะไร

เฉลย

AWS CloudHSM — single-tenant dedicated HSM ที่ลูกค้าถือ key material แต่เพียงผู้เดียว AWS เข้าไม่ถึง (อาจใช้ผ่าน KMS custom key store เพื่อ integration ง่ายขึ้น)

KMS customer managed key ผิด — เป็น multi-tenant managed HSM หลัง KMS; AWS host key material (ควบคุมผ่าน policy แต่ไม่ใช่ single-tenant ที่ AWS เข้าไม่ถึงเชิงกายภาพ)
SSE-S3 ผิด — AWS จัดการ key เต็ม
import key material เข้า KMS (BYOK) ผิดในบริบทนี้ — ยังอยู่บน multi-tenant KMS ไม่ใช่ dedicated single-tenant HSM ตาม regulatory

ข้อ 6. ทีม compliance ต้องพิสูจน์ต่อ auditor ว่า infrastructure เป็นไปตาม CIS AWS Benchmark อย่างต่อเนื่องและต้องการ compliance score รวมทุก account ควรใช้อะไร

เฉลย

AWS Security Hub เปิด CIS AWS Foundations Benchmark standard + cross-account aggregation ที่ delegated admin — automated check + compliance score รวม

GuardDuty ผิด — สร้าง threat finding ไม่วัด compliance ต่อ standard
AWS Artifact ผิด — ดาวน์โหลด compliance report ของ AWS ไม่ประเมิน workload ลูกค้า
Config อย่างเดียว ทำ rule check ได้แต่ Security Hub ให้ standard-based score + aggregation ตรงโจทย์กว่า (Config เป็น data source ให้ Security Hub)

ข้อ 7. เมื่อ GuardDuty พบ instance ถูกยึด ต้องตอบสนองอัตโนมัติภายในไม่กี่นาทีเพื่อตัดการสื่อสารของ attacker แต่ต้องเก็บหลักฐานสำหรับ forensics ควรออกแบบอย่างไร

เฉลย

EventBridge rule จับ GuardDuty finding → SSM Automation runbook ที่เปลี่ยน SG เป็น isolation SG (deny all outbound), snapshot EBS เก็บ evidence, tag quarantined, SNS แจ้งทีม — evidence ส่งไป forensics account

terminate instance ทันที ผิด — ทำลาย volatile evidence (memory/disk state) ที่ต้องใช้ forensics
แจ้งทีมให้แก้ manual ผิด — ไม่ตรง requirement ตอบสนองอัตโนมัติภายในไม่กี่นาที
ปิด GuardDuty ผิดสิ้นเชิง — เป็น detective control ที่ต้องคงไว้

ข้อ 8. ต้องหาว่า S3 bucket ใดในองค์กรมีข้อมูล PII (เลขบัตรเครดิต, PHI) เพื่อจัดการ compliance ควรใช้บริการใด

เฉลย

Amazon Macie — ML ค้นหาและจัดประเภท sensitive data (PII/PHI) ใน S3 พร้อมชี้ bucket ที่ public/unencrypted; finding เข้า Security Hub

GuardDuty ผิด — threat detection ไม่จัดประเภท data
Inspector ผิด — vulnerability scanning ไม่เกี่ยว data content
Config ผิด — ตรวจ config (encrypted/public?) ได้แต่ไม่วิเคราะห์เนื้อหาว่ามี PII

ข้อ 9. application data ต้อง encrypt at rest และ replicate ข้าม region เพื่อ DR โดยข้อมูลที่เข้ารหัสใน region หลักต้อง decrypt ได้ที่ region สำรองโดยไม่ต้อง re-encrypt ควรใช้ key แบบใด

เฉลย

KMS multi-region key (primary + replica ที่มี key material เดียวกันข้าม region) — data ที่เข้ารหัสใน region หนึ่ง decrypt ได้ด้วย replica key อีก region โดยไม่ต้อง decrypt+re-encrypt ระหว่างทาง (เชื่อมโยงบทที่ 08 DR)

customer managed key แยกอิสระต่อ region ผิด — key material ต่างกัน ต้อง decrypt+re-encrypt ระหว่าง replicate (ซับซ้อน/ช้า)
AWS managed key ผิด — region-scoped และไม่รองรับ multi-region
SSE-S3 ผิด — ไม่ใช่ CMK และไม่มีแนวคิด multi-region key ที่ควบคุมได้

ข้อ 10. microservices ภายในต้อง authenticate กันด้วย mutual TLS โดยไม่ต้องรัน certificate authority infrastructure เอง ควรใช้อะไร

เฉลย

AWS Private CA (ACM Private CA) ออก private client/server cert + ALB/API Gateway config mTLS ตรวจ client cert — managed PKI ไม่ต้องรัน CA เอง, cert lifecycle ผ่าน ACM

ACM public certificate ผิด — สำหรับ public TLS, export ไม่ได้ และไม่เหมาะออก client cert ภายในจำนวนมาก
self-managed OpenSSL/Microsoft CA ผิดในบริบท least ops — operational + security overhead สูง
KMS ผิด — จัดการ encryption key ไม่ใช่ X.509 certificate/PKI

ข้อ 11. ต้อง audit ได้ว่าใครเรียก S3 GetObject บน bucket ข้อมูลสำคัญ และเก็บ audit log ทั้ง org แบบลบไม่ได้ที่ account กลาง ควรออกแบบอย่างไร

เฉลย

Organization CloudTrail เปิด S3 data events ส่ง log ไป Log Archive account ใน S3 bucket ที่ล็อกด้วย Object Lock + log file integrity validation

management events อย่างเดียว ผิด — ไม่บันทึก object-level (GetObject/PutObject) ต้องเปิด data events
VPC Flow Logs ผิด — บันทึก network flow ไม่ใช่ S3 API call ระดับ object
เก็บ log ใน production account เอง ผิด — attacker ที่ยึด account ลบ log ได้ ต้อง Log Archive account แยก + immutable

ข้อ 12. ต้อง automate การเก็บ evidence ต่อ compliance framework (เช่น PCI DSS) จาก Config/CloudTrail/Security Hub เพื่อเตรียม audit อย่างต่อเนื่อง ควรใช้บริการใด

เฉลย

AWS Audit Manager — map control ของ framework เข้ากับ evidence จาก Config/CloudTrail/Security Hub อัตโนมัติ ประกอบเป็น audit-ready report ต่อเนื่อง

AWS Artifact ผิด — ให้ดาวน์โหลด compliance report ของ AWS เอง ไม่รวบรวม evidence ของ workload ลูกค้า
Security Hub ผิดบางส่วน — ให้ compliance score/finding แต่ไม่ทำ evidence collection ต่อ framework แบบ audit package
Config อย่างเดียว ผิด — เป็น data source หนึ่ง ไม่ประกอบ audit evidence ข้ามหลายแหล่ง

7. Cross-references

บทที่ 01 — Exam Blueprint & SA-Pro Mindset: (รับ cross-ref) detective vs preventive control และ least privilege เป็นแกน Security pillar — บทนี้ขยายเต็ม (preventive = SCP/IAM/WAF; detective = GuardDuty/Config/CloudTrail/Macie/Inspector; responsive = EventBridge+SSM); keyword mapping — detect → detective service, encrypt/control key → KMS CMK, DDoS → Shield, rotate credential → Secrets Manager; convention <details> ห่อเฉลย + bullet “ทำไมตัวเลือกอื่นผิด”
บทที่ 02 — Multi-Account Governance: (รับ cross-ref) รายละเอียด GuardDuty/Config/Security Hub/KMS/defense-in-depth ที่บท 02 ฝากมา — บทนี้เป็นเจ้าของ; delegated administration ที่ Audit account, Log Archive account สำหรับ org CloudTrail, SCP เป็น preventive layer, Firewall Manager คู่ Organizations
บทที่ 03 — Identity, Access & Federation: (รับ cross-ref) KMS key policy (resource-based) vs IAM vs grant, cross-account key usage (สองด่าน AND), Secrets Manager ต่อยอด “อย่า hardcode credential”, CloudHSM, RCP/data perimeter; IAM database authentication
บทที่ 04 — Networking at Scale & Hybrid: (รับ cross-ref) WAF/Shield เชิงลึกบน CloudFront/ALB, Network Firewall ในบริบท DiD, data perimeter (VPC endpoint policy + aws:PrincipalOrgID/aws:SourceVpce); SG/NACL segmentation เป็น network layer ของ defense in depth
บทที่ 06 — Storage & Data Transfer: (รับ cross-ref) S3 encryption options เต็ม (SSE-S3/SSE-KMS/SSE-C/DSSE) + S3 Bucket Keys, EBS/EFS/FSx encryption ผ่าน KMS, S3 Object Lock สำหรับ evidence/immutable audit
บทที่ 07 — Databases & Data Migration: (รับ cross-ref) RDS/Aurora/DynamoDB encryption at rest ด้วย KMS (RDS เปิด encryption หลังสร้างไม่ได้ ต้อง snapshot+restore), RDS Proxy + Secrets Manager rotation, IAM database authentication, Lake Formation fine-grained access เชิง security
บทที่ 08 — Resilience, HA & DR: (รับ cross-ref) KMS multi-region key สำหรับ encrypt backup/replica ข้าม region, key policy สำหรับ cross-account backup (AWS Backup service principal), Backup Vault Lock Compliance mode เป็น data protection กัน ransomware
บทที่ 11 — Operational Excellence & Monitoring (ฝากไป): SSM Automation/Patch Manager/Session Manager เชิง operation, CloudWatch สำหรับ security metric/alarm, centralized logging pattern — บทนี้ใช้ SSM/EventBridge เป็น response primitive เท่านั้น
บทที่ 14 — Exam Scenarios (ฝากไป): decision framework “detect อะไร → service ไหน” (GuardDuty/Inspector/Macie/Config), “key management → KMS/CloudHSM”, “secret → Secrets Manager/Parameter Store” นำไปสังเคราะห์เป็น cross-domain scenario (security + networking + cost)