บทที่ 03: Identity, Access & Federation at Scale

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

บทนี้เป็นหัวใจของ Domain 1 (Design Solutions for Organizational Complexity) ในส่วนที่ว่าด้วย “ใครทำอะไรได้บ้าง” ในสภาพแวดล้อมที่มีหลายร้อย account, ผู้ใช้หลายพันคน, และ identity provider (IdP) เดิมที่องค์กรใช้อยู่ก่อนย้ายมา AWS แล้ว บทที่ 02 (ดูบทที่ 02 — Multi-Account Governance) ได้วางกรอบว่า account เป็น isolation boundary ที่แข็งที่สุด และ Service Control Policy (SCP) เป็น guardrail ที่กำหนด “เพดานสิทธิ์” ระดับ organization โดยไม่ให้สิทธิ์เอง บทที่ 03 จะรับช่วงต่อในระดับ “สิทธิ์จริงที่ principal ได้รับ” — ตั้งแต่ policy evaluation logic เต็มรูปแบบ, การออกแบบ cross-account access ที่ปลอดภัย, การเชื่อม workforce identity ผ่าน IAM Identity Center และ federation, ABAC vs RBAC, permission boundary สำหรับ delegated administration, ไปจนถึง application identity ด้วย Amazon Cognito และ hybrid Active Directory

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

ไล่ policy evaluation ได้ครบทุกชั้น (identity-based, resource-based, permission boundary, session policy, SCP) และตอบได้ทันทีว่า principal คนหนึ่งเข้าถึง resource ได้หรือไม่ เมื่อโจทย์ให้ policy หลายตัวมาปนกัน
แยกออกว่าเมื่อไหร่ใช้ IAM role vs IAM user, เมื่อไหร่ใช้ IAM Identity Center vs SAML federation ตรง, เมื่อไหร่ใช้ Cognito
ออกแบบ cross-account access ด้วย external ID เพื่อกัน confused deputy และเข้าใจข้อจำกัดของ role chaining
เลือกใช้ ABAC (tag-based) เพื่อลดจำนวน policy ที่ต้องดูแลในองค์กรขนาดใหญ่ พร้อมเข้าใจ trade-off
ออกแบบ hybrid identity กับ Active Directory ผ่าน AWS Directory Service ให้ถูกรูปแบบ

ในเชิงข้อสอบ SAP-C02 keyword ที่ชี้มาบทนี้คือ existing identity provider, corporate Active Directory, single sign-on, third-party/vendor access to my account, temporary credentials, grant access without sharing credentials, thousands of users, centralized access across accounts

ขอบเขต: กลไก SCP × IAM intersection และ deny list vs allow list อยู่ที่บทที่ 02 (อ้างอิงเท่านั้น ไม่นิยามซ้ำ); KMS key policy และ grant → บทที่ 09; networking สำหรับเชื่อม on-premises AD (Direct Connect/VPN, DNS, security group) → บทที่ 04

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

2.1 IAM policy types ทั้ง 6 และหน้าที่ที่ต่างกัน

ก่อนจะเข้าใจ evaluation logic ต้องแยกให้ออกว่า policy แต่ละชนิด “ติดอยู่กับอะไร” และ “ทำหน้าที่อะไร” เพราะข้อสอบชอบเอามาปนเพื่อทดสอบว่าคุณรู้จริงหรือจำผิวเผิน

Policy type	ติดกับอะไร	หน้าที่	ให้สิทธิ์เองได้ไหม
Identity-based policy	IAM user, group, role	ระบุว่า identity นี้ทำอะไรได้กับ resource ใด	ได้ (managed หรือ inline)
Resource-based policy	ตัว resource เอง (S3 bucket, SQS queue, KMS key, Lambda, SNS)	ระบุว่า principal ใด (รวมข้าม account) ทำอะไรกับ resource นี้ได้	ได้ และมี `Principal` element
Permission boundary	IAM user หรือ role (แนบ 1 ตัว)	เพดานสิทธิ์สูงสุดของ identity นั้น (ไม่ให้สิทธิ์เอง)	ไม่ได้ — เป็น guardrail ระดับ identity
Session policy	ส่งตอน `AssumeRole`/`GetFederationToken`	จำกัดสิทธิ์ของ session ชั่วคราวให้แคบลงกว่า role	ไม่ได้ — filter เท่านั้น
Service Control Policy (SCP)	OU/account (ดูบทที่ 02)	เพดานสิทธิ์ระดับ organization	ไม่ได้ — guardrail
Resource Control Policy (RCP)	OU/account, บังคับกับ resource ในนั้น	เพดานสิทธิ์ฝั่ง resource ระดับ org (data perimeter)	ไม่ได้ — guardrail [uncertain รายละเอียดล่าสุด]

จุดที่ต้องฝังในหัว: มีเพียง identity-based และ resource-based เท่านั้นที่ “ให้สิทธิ์” (grant) ได้จริง ส่วน permission boundary, session policy, SCP, RCP ล้วนเป็น “boundary/guardrail” ที่ทำได้แค่ “หั่นสิทธิ์ให้แคบลง” ไม่เคยเพิ่มสิทธิ์ นี่คือหลักการเดียวกับที่บทที่ 02 อธิบายไว้กับ SCP แต่ตอนนี้ขยายให้ครบทุกชั้น

2.2 Policy evaluation logic เต็มรูปแบบ

นี่คือ cross-reference ที่บทที่ 01 และ 02 ฝากมา — ต้องแม่นระดับตอบได้ในหัว ลำดับการตัดสินใจของ IAM สำหรับ request หนึ่ง ๆ:

Default = implicit deny ทุก request เริ่มจากถูกปฏิเสธ
มี explicit deny ที่ไหนสักที่ในทุก policy หรือไม่ — ถ้ามี → DENY ทันที (explicit deny ชนะทุกอย่างเสมอ ไม่ว่าจะมี allow กี่ตัว)
SCP อนุญาตหรือไม่ (ดูบทที่ 02) — ถ้า SCP ไม่ allow action นั้น → DENY (ยกเว้น management account ที่ SCP ไม่มีผล)
RCP อนุญาตหรือไม่ (ถ้ามี, ฝั่ง resource) — ถ้าไม่ผ่าน → DENY
permission boundary อนุญาตหรือไม่ (ถ้า identity มี boundary) — ต้องมีทั้ง boundary allow และ identity policy allow
session policy อนุญาตหรือไม่ (ถ้าเป็น session ที่มี session policy)
identity-based หรือ resource-based policy มี explicit allow หรือไม่

หลักการรวม (mental model): สิทธิ์จริง = intersection ของทุก guardrail (SCP ∩ RCP ∩ permission boundary ∩ session policy) ∩ union ของ grant policy (identity-based ∪ resource-based) — แล้ว ลบทุกอย่างที่ถูก explicit deny

กรณีพิเศษที่ข้อสอบเจาะบ่อย: same-account vs cross-account สำหรับ resource-based policy

ภายใน account เดียวกัน: principal เข้าถึง resource ได้ถ้า “identity policy allow หรือ resource policy allow” (อย่างใดอย่างหนึ่งก็พอ — เป็น OR/union)
ข้าม account: ต้อง “identity policy (ใน account ของ principal) allow และ resource policy (ใน account ของ resource) allow” — ต้องผ่าน ทั้งสองฝั่ง (AND)

ยกเว้น IAM role trust policy กับ KMS ที่ resource policy เป็นตัวตัดสินหลัก แต่หลัก AND cross-account นี้คือสิ่งที่ทำให้โจทย์ S3 cross-account ผิดบ่อย: การเปิด bucket policy อย่างเดียวไม่พอ IAM ฝั่ง caller ก็ต้อง allow ด้วย

2.3 IAM roles & AWS STS

IAM role คือ identity ที่ ไม่มี long-term credential ผูกติด ใครก็ตามที่ “assume” ได้จะได้ temporary security credentials (access key + secret + session token) จาก AWS STS (Security Token Service) ที่หมดอายุตามที่กำหนด (15 นาที ถึงสูงสุด 12 ชั่วโมงสำหรับ session, แต่ role chaining จำกัดที่ 1 ชั่วโมง)

องค์ประกอบของ role มี 2 policy คนละหน้าที่:

Trust policy (เป็น resource-based policy ชนิดหนึ่ง): ระบุ Principal ว่า “ใครได้รับอนุญาตให้ assume role นี้” — เป็น account อื่น, service (ec2.amazonaws.com, lambda.amazonaws.com), SAML provider, หรือ OIDC provider
Permission policy (identity-based): ระบุว่าเมื่อ assume แล้ว “ทำอะไรได้บ้าง”

รูปแบบการใช้ role ที่ต้องแยกออก:

Service role / instance profile: EC2 assume role ผ่าน instance profile (wrapper ที่ผูก role เข้ากับ EC2 instance) — application บน EC2 ดึง credential จาก Instance Metadata Service (แนะนำ IMDSv2 เพื่อกัน SSRF) ไม่ต้อง hardcode key เด็ดขาด เป็นคำตอบมาตรฐานของโจทย์ “application on EC2 needs to access S3 without storing credentials”
Cross-account role: account A สร้าง role ที่ trust account B; ผู้ใช้ใน account B assume เข้ามาทำงานใน account A — ทดแทนการสร้าง IAM user ซ้ำในทุก account
Role chaining: assume role หนึ่งแล้วใช้ credential นั้นไป assume อีก role — session ที่ได้จะจำกัด max 1 ชั่วโมงเสมอ และเสีย session ต่อเนื่อง (ข้อสอบชอบถามว่าทำไม session หมดเร็วผิดคาด → เพราะ chaining)

2.4 External ID และ confused deputy problem

Confused deputy คือสถานการณ์ที่ third party (เช่น SaaS monitoring vendor) มี role เดียวที่ใช้เข้าถึง account ของลูกค้าหลายราย ถ้า attacker เดา ARN ของ role ในบัญชีลูกค้ารายอื่นได้ ก็อาจหลอกให้ vendor (deputy) ไป assume role ในบัญชีที่ไม่ใช่ของตนได้ External ID แก้ปัญหานี้: ลูกค้ากำหนดค่า secret string ที่ third party ต้องส่งมาใน sts:ExternalId ตอน AssumeRole และ trust policy บังคับด้วย Condition — ทำให้ vendor ต้องรู้ค่าเฉพาะของแต่ละลูกค้า ป้องกันการสลับบัญชี

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::THIRD_PARTY_ACCOUNT_ID:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "unique-per-customer-secret-9f3a" }
  }
}

keyword ในโจทย์: third-party SaaS needs access to your account → cross-account role + external ID (ไม่ใช่การสร้าง IAM user ให้ vendor และ ไม่ใช่การแชร์ access key ซึ่งเป็นคำตอบผิดที่พบบ่อย)

2.5 IAM Identity Center (เดิม AWS SSO)

สำหรับ workforce identity (พนักงานภายในองค์กร) ที่ต้อง login เข้าหลาย account IAM Identity Center คือคำตอบมาตรฐานแทนการสร้าง IAM user ในแต่ละ account องค์ประกอบสำคัญ:

Identity source: เลือกได้ 3 แบบ — (1) Identity Center built-in directory, (2) Active Directory (ผ่าน AWS Managed Microsoft AD หรือ AD Connector), (3) External IdP ผ่าน SAML 2.0 (Okta, Azure AD/Entra ID, Ping, Google Workspace) พร้อม SCIM สำหรับ auto-provisioning user/group
Permission set: คือ template ของสิทธิ์ (ประกอบด้วย managed policies + inline policy + permission boundary + session duration) ที่ Identity Center จะ materialize เป็น IAM role ในแต่ละ account ที่ assign — นี่คือกลไกเบื้องหลัง: permission set หนึ่งที่ assign ไป 50 account จะสร้าง IAM role ที่เหมือนกัน 50 ตัวโดยอัตโนมัติ
Assignment: จับคู่ (user หรือ group) × (permission set) × (account/OU) — ทำครั้งเดียวครอบทั้ง organization ผ่าน integration กับ AWS Organizations
AWS access portal: หน้า SSO เดียวที่ผู้ใช้เห็น account + role ทั้งหมดที่ตนเข้าได้

เทียบกับการทำ SAML federation ตรงเข้า IAM (สร้าง SAML identity provider ในแต่ละ account + trust policy เอง): Identity Center จัดการ role, trust, และ assignment ให้อัตโนมัติทั่ว org จึง least operational overhead กว่ามากในสภาพแวดล้อม multi-account keyword: centralized access to multiple accounts with existing corporate directory → IAM Identity Center

2.6 Federation: SAML 2.0, OIDC/web identity และ session tags

Federation คือการให้ identity จากภายนอก AWS (corporate IdP, social login) ได้ credential ชั่วคราวเข้า AWS โดยไม่ต้องมี IAM user

SAML 2.0 federation: ใช้กับ enterprise IdP (ADFS, Okta, Azure AD) ผู้ใช้ authenticate ที่ IdP → ได้ SAML assertion → เรียก sts:AssumeRoleWithSAML → ได้ temporary credential เหมาะกับ workforce ที่มี IdP อยู่แล้ว
OIDC / web identity federation: ใช้กับ OIDC provider (Google, Facebook, Amazon, หรือ Cognito) เรียก sts:AssumeRoleWithWebIdentity — ใช้กับ mobile/web app ที่ผู้ใช้ทั่วไป login และ EKS service account (IRSA) ที่ใช้ OIDC ในการให้ pod assume role
Session tags: ตอน federate สามารถส่ง attribute จาก IdP (เช่น department, project, costcenter) มาเป็น principal tag ของ session ผ่าน SAML attribute หรือ sts:AssumeRole — เป็นรากฐานของ ABAC (ดูข้อ 2.7) ตัวอย่าง attribute mapping: https://aws.amazon.com/SAML/Attributes/PrincipalTag:department

2.7 ABAC vs RBAC

RBAC (Role-Based Access Control) = สร้าง role/policy แยกตาม “หน้าที่” เช่น AdminRole, DevReadOnlyRole, ProjectA-Developer เมื่อองค์กรโต จำนวน role และ policy จะระเบิดตามจำนวน project × environment × team → ดูแลยาก

ABAC (Attribute-Based Access Control) = ให้สิทธิ์ตาม tag ที่ตรงกัน ระหว่าง principal และ resource เขียน policy ครั้งเดียวว่า “principal เข้าถึง resource ได้ถ้า tag project ตรงกัน” แล้วใช้ได้กับทุก project โดยไม่ต้องเขียน policy ใหม่:

{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/project": "${aws:PrincipalTag/project}"
    }
  }
}

มิติ	RBAC	ABAC
จำนวน policy เมื่อ scale	โตตามจำนวน role (linear/exponential)	คงที่ไม่กี่ policy
การเพิ่ม project/team ใหม่	ต้องสร้าง role/policy ใหม่	แค่ตั้ง tag ให้ตรง ไม่แตะ policy
ความชัดเจนในการ audit	ตรงไปตรงมา ดู role ก็รู้สิทธิ์	ต้องดู tag ของทั้ง principal และ resource
ความเสี่ยง	สิทธิ์บวมจาก role เก่าไม่ถูกลบ	tag ผิด/หายทำสิทธิ์เพี้ยนทันที; ต้องบังคับ tag governance เข้ม
เหมาะกับ	องค์กรเล็ก-กลาง, สิทธิ์นิ่ง	องค์กรใหญ่, multi-project, ทีมหมุนเวียนเร็ว

trade-off หลัก: ABAC ยืดหยุ่นและ scale ดีมากแต่ พึ่ง tag governance อย่างสมบูรณ์ — ถ้า tag ไม่ถูกบังคับ (เช่นบังคับ tag ตอนสร้าง resource ต้องใช้ SCP aws:RequestTag condition ดูบทที่ 02) ABAC จะกลายเป็นช่องโหว่ ในข้อสอบ keyword minimize the number of policies / scales as new projects are added / teams change frequently → ABAC

2.8 Permission boundary สำหรับ delegated administration

ปัญหา delegated administration: อยากให้ทีม developer สร้าง IAM role/user ได้เอง (เพื่อไม่ให้ทีม platform เป็นคอขวด) แต่ไม่อยากให้เขาสร้าง role ที่มีสิทธิ์เกินตัวเอง (privilege escalation) Permission boundary แก้ปัญหานี้: กำหนดว่า role ที่ developer สร้างได้ต้อง “แนบ boundary ตัวนี้เสมอ” และ boundary จำกัดเพดานสิทธิ์ของ role ลูกที่สร้างขึ้น

กลไก: ให้ developer มี identity policy ที่ allow iam:CreateRole/iam:CreateUser/iam:PutRolePolicy แต่มี condition iam:PermissionsBoundary บังคับว่า role ที่สร้างต้องแนบ boundary ARN ที่กำหนด และ deny การแก้/ลบ boundary — แบบนี้ developer มอบสิทธิ์ต่อได้เฉพาะภายในเพดานที่ platform team ตั้งไว้ นี่คือ safe delegation ที่ข้อสอบชอบถามในบริบท “ให้ทีมสร้าง IAM identity ได้เองอย่างปลอดภัย ไม่ต้องให้ admin ทำให้ทุกครั้ง”

2.9 AWS Resource Access Manager (RAM)

RAM ให้ แชร์ resource ข้าม account ภายใน (หรือข้าม) organization โดยไม่ต้องทำ cross-account role — เจ้าของ resource ยังคุมได้เต็มที่ ตัวอย่าง resource ที่แชร์ได้และมักออกข้อสอบ:

VPC subnet (VPC Sharing): account กลางเป็นเจ้าของ VPC แล้วแชร์ subnet ให้ account อื่นมา deploy resource ในนั้น → ลด VPC ซ้ำซ้อน, รวม network ให้จัดการที่เดียว (ดูบทที่ 04 สำหรับ network design)
AWS Transit Gateway → แชร์ให้หลาย account ต่อเข้า hub เดียว (ดูบทที่ 04)
Route 53 Resolver Rules, License Manager configurations, Prefix lists, Aurora DB clusters [uncertain รายการเต็มปัจจุบัน]

keyword: share subnet/TGW across accounts without duplicating → RAM ประเด็นข้อสอบ: RAM ต่างจาก resource-based policy ตรงที่ออกแบบมาเพื่อการแชร์ resource บางประเภทระดับ org โดยเฉพาะและ integrate กับ Organizations (auto-accept ได้เมื่อเปิด sharing ใน org)

2.10 Amazon Cognito: user pools vs identity pools

Cognito เป็น application-level identity (ลูกค้า/ผู้ใช้ปลายทางของแอป ไม่ใช่พนักงานภายในองค์กร) แยก 2 ส่วนที่คนสับสนบ่อยที่สุด:

User pool = directory ของผู้ใช้แอป (sign-up, sign-in, MFA, password policy, hosted UI, social/SAML/OIDC federation) ผลลัพธ์คือ JWT token (ID token + access token) ที่แอปใช้ authenticate ผู้ใช้ — เหมาะกับ authentication และเป็นแหล่ง identity ของ API (ใช้กับ API Gateway Cognito authorizer)
Identity pool (federated identities) = แลก token → AWS temporary credential ผ่าน STS เพื่อให้ผู้ใช้แอปเข้าถึง AWS resource โดยตรง (เช่น upload ไป S3, เขียน DynamoDB) รองรับทั้ง authenticated และ guest/unauthenticated identity

mental model: user pool ตอบ “คุณคือใคร” (authentication), identity pool ตอบ “คุณเข้าถึง AWS resource อะไรได้” (authorization to AWS) มักใช้คู่กัน: login ผ่าน user pool → เอา token ไปแลก credential ที่ identity pool keyword: mobile/web app, millions of end users, sign-up/sign-in, social login → Cognito user pool; let app users access S3/DynamoDB directly → identity pool

2.11 AWS Directory Service และ hybrid AD

สำหรับองค์กรที่มี Microsoft Active Directory อยู่แล้ว AWS Directory Service มี 3 ทางเลือกหลัก:

ตัวเลือก	คืออะไร	เมื่อไหร่ใช้
AWS Managed Microsoft AD	AD จริง (Windows Server AD) ที่ AWS host+manage เต็มรูปแบบ รองรับ trust กับ on-prem AD, group policy, schema extension	ต้องการ AD จริงใน AWS, รัน workload ที่ต้อง AD (RDS SQL Server, FSx, WorkSpaces, EC2 domain join), หรือทำ two-way trust กับ on-prem
AD Connector	proxy/gateway ที่ redirect authentication ไปยัง on-prem AD ไม่เก็บ user ใน AWS	อยาก reuse on-prem AD กับบริการ AWS โดยไม่ replicate directory; ต้องมี network ถึง on-prem (ดูบทที่ 04)
Simple AD	Samba-based directory ราคาถูก ฟีเจอร์จำกัด ไม่รองรับ trust/MFA/schema extension	dev/test เล็ก ๆ หรือความต้องการ AD พื้นฐานมาก ๆ

รูปแบบ hybrid ที่ออกข้อสอบ:

Two-way forest trust ระหว่าง AWS Managed Microsoft AD กับ on-prem AD → ผู้ใช้ on-prem login เข้าใช้ resource ใน AWS ด้วย credential เดิม โดย directory ยังอยู่ on-prem เป็น source of truth
IAM Identity Center ใช้ Managed Microsoft AD / AD Connector เป็น identity source เพื่อให้พนักงาน AD login เข้า AWS accounts ได้

การ join domain, DNS resolution, และ connectivity (VPN/Direct Connect) เพื่อให้ AD Connector ถึง on-prem เป็นเรื่อง networking → ดูบทที่ 04

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

3.1 เลือกกลไก identity/access ให้ตรงโจทย์

สถานการณ์ในโจทย์	คำตอบที่ถูก	ทำไมไม่ใช่ตัวอื่น
พนักงานภายในต้อง login หลาย account, มี Okta/Azure AD อยู่แล้ว	IAM Identity Center + external IdP	IAM user ต่อ account = ops สูง; SAML ตรงต่อ account = จัดการ trust เองทุก account
App มือถือมีผู้ใช้ปลายทางหลักล้าน ต้อง sign-up/sign-in	Amazon Cognito user pool	IAM user ไม่ scale ถึงระดับผู้ใช้แอป; Identity Center เป็น workforce ไม่ใช่ customer
ให้ผู้ใช้แอปเขียน S3/DynamoDB โดยตรงจาก client	Cognito identity pool (แลก credential)	ฝัง IAM key ในแอป = รั่วแน่นอน
Third-party SaaS เข้าถึง account เรา	Cross-account role + external ID	สร้าง IAM user ให้ vendor / แชร์ access key = ผิดหลัก least privilege และหมุน credential ไม่ได้
App บน EC2 เข้าถึง S3 โดยไม่เก็บ credential	Instance profile (role) + IMDSv2	hardcode key / เก็บใน env = credential leak
ให้ dev สร้าง IAM role เองแต่กันสิทธิ์เกิน	Permission boundary + condition ตอน create	ให้สิทธิ์ `iam:*` ตรง ๆ = privilege escalation
Policy บวมตามจำนวน project ที่เพิ่มเรื่อย ๆ	ABAC (session tag + resource tag)	RBAC สร้าง role ใหม่ทุก project = ระเบิด
แชร์ subnet/TGW ข้าม account	AWS RAM	VPC peering คนละเรื่อง (network path); สร้าง VPC ซ้ำ = สิ้นเปลือง
reuse corporate AD กับ AWS โดยไม่ replicate	AD Connector	Managed Microsoft AD = สร้าง directory ใหม่ (เกินจำเป็นถ้าแค่ proxy auth)
ต้อง AD จริงสำหรับ RDS SQL Server / FSx / WorkSpaces	AWS Managed Microsoft AD	AD Connector ไม่ host directory; Simple AD ไม่รองรับฟีเจอร์เต็ม

3.2 IAM Identity Center vs SAML federation ตรง vs IAM users

มิติ	IAM users (ต่อ account)	SAML federation ตรงเข้า IAM	IAM Identity Center
Credential	long-term (เสี่ยง)	temporary (STS)	temporary (STS)
Multi-account	สร้างซ้ำทุก account	ตั้ง SAML provider + role ทุก account เอง	assign ครั้งเดียวทั่ว org
เชื่อม external IdP	ไม่ได้โดยตรง	ได้ (ต่อ account)	ได้ (จุดเดียว + SCIM)
Ops overhead	สูงสุด	ปานกลาง-สูง	ต่ำสุด (สำหรับ multi-account)
เหมาะกับ	legacy/เฉพาะกรณี, service account	single account หรือ IdP เฉพาะทาง	มาตรฐาน workforce multi-account

3.3 Cognito vs IAM Identity Center vs Directory Service (ใครคือกลุ่มผู้ใช้)

บริการ	กลุ่มผู้ใช้	โจทย์สัญญาณ
Amazon Cognito	ลูกค้า/ผู้ใช้ปลายทางของแอป (external customers)	mobile/web app, sign-up, social login, millions of users
IAM Identity Center	พนักงาน/ผู้พัฒนาภายในองค์กร (workforce)	employees, developers, SSO to AWS accounts
AWS Directory Service	workload ที่ต้อง AD + hybrid AD	Active Directory, domain join, group policy, trust

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

4.1 Enterprise SSO ข้ามหลายร้อย account ด้วย Identity Center + Azure AD

โจทย์: บริษัทมี 200+ account ใน AWS Organizations, พนักงาน 5,000 คนอยู่ใน Azure AD (Entra ID), ต้องการให้พนักงาน login ที่เดียวแล้วเข้าถึง account ที่ได้รับอนุญาต ด้วย session ชั่วคราว และให้ทีม audit เพิกถอนสิทธิ์ได้จากจุดเดียว

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

เปิด IAM Identity Center ที่ management account (หรือ delegate administrator ไป account เฉพาะ)
ตั้ง Azure AD เป็น external IdP ผ่าน SAML 2.0 + เปิด SCIM เพื่อ auto-sync user/group จาก Azure AD
สร้าง permission set ตามหน้าที่: Billing-ReadOnly, Workload-Admin, SecurityAudit (session duration สั้นสำหรับ admin)
Assignment: group Cloud-Admins (จาก Azure AD) × permission set Workload-Admin × OU Workloads/Prod
Identity Center materialize IAM role ในทุก account ตาม assignment อัตโนมัติ

ทำไมเลือกแบบนี้ / trade-off:

least operational overhead: ไม่ต้องแตะ trust policy รายบัญชี, การเพิ่ม account ใหม่แค่รวมเข้า OU ก็ได้ role อัตโนมัติ
Source of truth ยังอยู่ที่ Azure AD → offboarding พนักงานที่ Azure AD ตัดสิทธิ์ AWS ทันที (ผ่าน SCIM)
แลก: ต้องพึ่ง Identity Center เป็น single point — ถ้า config permission set ผิดจะกระจายไปทุก account พร้อมกัน (blast radius ของ misconfig สูง) จึงควรคุม change ด้วย IaC/review

4.2 Third-party monitoring vendor เข้าถึงหลาย account อย่างปลอดภัย

โจทย์: SaaS cost-optimization vendor ต้อง read-only เข้าถึง billing/EC2 metadata ใน 50 account ของลูกค้า vendor รายเดียวให้บริการลูกค้าหลายบริษัท

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

แต่ละ account สร้าง cross-account role ที่ trust arn:aws:iam::VENDOR_ACCOUNT:root
trust policy บังคับ Condition sts:ExternalId = ค่าเฉพาะที่ vendor ออกให้ลูกค้ารายนี้
permission policy = read-only (ReadOnlyAccess หรือแคบกว่า) เท่าที่จำเป็น
deploy role เดียวกันทั้ง 50 account ด้วย CloudFormation StackSets (ผ่าน Organizations)

ทำไม / trade-off:

external ID กัน confused deputy: vendor ต้องส่งค่าตรงกับลูกค้ารายนั้นเท่านั้น จึง assume ข้ามบัญชีลูกค้ารายอื่นไม่ได้แม้เดา ARN ได้
ไม่มี long-term credential ให้ vendor → หมุน/เพิกถอนได้ทันทีที่ลบ role
แลก: ต้องเชื่อ vendor account root; ควรจำกัด action ให้แคบและใช้ Condition เพิ่ม (เช่น aws:SourceIp ถ้าทราบ) แทนการให้ ReadOnlyAccess กว้าง

4.3 ABAC สำหรับองค์กร multi-project ที่ทีมหมุนเวียนเร็ว

โจทย์: องค์กรมีหลายสิบ project, ทีมย้าย project บ่อย, ไม่อยากสร้าง IAM role ใหม่ทุกครั้งที่มี project เกิด ต้องการให้ engineer เข้าถึงเฉพาะ resource ของ project ตัวเอง

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

Azure AD/IdP ส่ง attribute project และ team มาเป็น session tag ผ่าน SAML (PrincipalTag)
Policy กลางตัวเดียว: allow action เมื่อ aws:ResourceTag/project == aws:PrincipalTag/project
บังคับ tag project ตอนสร้าง resource ด้วย SCP aws:RequestTag condition (ดูบทที่ 02)
reassign engineer ไป project ใหม่ = แก้ attribute ใน IdP เท่านั้น ไม่แตะ AWS

ทำไม / trade-off:

จำนวน policy คงที่แม้ project เพิ่มไม่จำกัด → scales as new projects are added
แลก: พึ่ง tag governance 100% — resource ที่ tag ผิด/ไม่มี tag จะเข้าไม่ได้หรือ (แย่กว่า) ถ้า policy ออกแบบหลวมอาจเข้าได้เกิน; audit ยากกว่า RBAC เพราะสิทธิ์ implicit อยู่ใน tag ต้องมี Config rule ตรวจ tag compliance เสริม

4.4 Hybrid AD สำหรับ Windows workload

โจทย์: ย้าย .NET/SQL Server workload มา AWS แต่ต้อง authenticate กับ corporate AD เดิม, ต้องการ single sign-on สำหรับ WorkSpaces และ domain-joined EC2

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

Deploy AWS Managed Microsoft AD ใน VPC สอง AZ
ตั้ง two-way forest trust กับ on-prem AD ผ่าน Direct Connect/VPN (ดูบทที่ 04)
domain-join EC2/RDS SQL Server/FSx เข้ากับ Managed Microsoft AD
ใช้ Managed Microsoft AD เป็น identity source ของ IAM Identity Center ให้ผู้ใช้ AD เข้า console ได้

ทำไม / trade-off:

Managed Microsoft AD เป็น AD จริง → รองรับ trust, group policy, และ workload ที่ต้อง Kerberos/LDAP เต็มรูปแบบ ต่างจาก AD Connector ที่เป็นแค่ proxy (เลือก Connector ถ้า ไม่ ต้อง host directory และแค่อยาก proxy auth)
แลก: มีค่าใช้จ่ายต่อเนื่องและต้องดูแล trust/DNS/connectivity ให้เสถียร; ถ้า link ไป on-prem ล่ม authentication ที่พึ่ง trust จะกระทบ — จึงควรออกแบบ resilient connectivity (ดูบทที่ 04)

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

คิดว่าเปิด bucket policy อย่างเดียวพอสำหรับ cross-account S3 — จริง ๆ ต้อง allow ทั้งฝั่ง resource policy และ identity policy ของ caller (AND) การเปิดฝั่งเดียวยังเข้าไม่ได้
สับสน permission boundary กับ SCP — SCP = ระดับ org/account (ดูบทที่ 02); permission boundary = ระดับ IAM identity เดี่ยว ทั้งคู่เป็น guardrail ไม่ให้สิทธิ์เอง แต่คนละ scope
เชื่อว่า SCP หรือ boundary “ให้สิทธิ์” ได้ — ไม่มีทาง ต้องมี identity/resource policy allow เสมอ guardrail แค่หั่นให้แคบ
เลือก IAM user สำหรับ third-party หรือ workforce — เกือบทุกครั้งผิด คำตอบคือ role + STS (temporary) หรือ Identity Center/federation
สับสน Cognito user pool กับ identity pool — user pool = authentication (คุณคือใคร, ได้ JWT); identity pool = แลกเป็น AWS credential (เข้าถึง AWS resource)
สับสน IAM Identity Center (workforce) กับ Cognito (customer) — พนักงานภายใน = Identity Center; ผู้ใช้ปลายทางของแอป = Cognito
ลืม external ID ในโจทย์ third-party access — ถ้าไม่มี external ID จะเปิดช่อง confused deputy; คำตอบที่ไม่มี external ID มักเป็น distractor
เลือก Managed Microsoft AD ทั้งที่แค่ต้อง proxy auth — ถ้าไม่ต้อง host directory และ on-prem AD ยังเป็น source of truth ให้เลือก AD Connector (ประหยัดและตรงกว่า)
คิดว่า role chaining ต่อ session ได้ยาว 12 ชั่วโมง — chaining จำกัด max 1 ชั่วโมงเสมอ
ใช้ RBAC ในโจทย์ที่บอกว่า project เพิ่มเรื่อย ๆ / ทีมเปลี่ยนบ่อย — สัญญาณชัดของ ABAC; RBAC จะทำ policy ระเบิด
ใช้ VPC peering แทน RAM สำหรับการแชร์ subnet — คนละเรื่อง; RAM แชร์ resource ให้ deploy ร่วมกัน ส่วน peering เชื่อม path network (ดูบทที่ 04)
hardcode IAM access key ใน EC2/Lambda — คำตอบถูกคือ instance profile/execution role เสมอ

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

ข้อ 1 — บริษัทมี 150 account และใช้ Okta เป็น IdP ต้องการให้พนักงาน single sign-on เข้าถึง account ที่ได้รับสิทธิ์ ด้วย temporary credential และจัดการสิทธิ์จากจุดเดียว วิธีที่ least operational overhead คือ?

A. สร้าง IAM user ให้พนักงานทุกคนในทุก account B. ตั้ง SAML identity provider และ role ในทุก account แยกกัน C. ใช้ IAM Identity Center เชื่อม Okta (SAML + SCIM) แล้ว assign permission set ระดับ OU D. ใช้ Amazon Cognito user pool ให้พนักงาน login

เฉลย

C — Identity Center จัดการ role/trust/assignment ทั่ว org ให้อัตโนมัติและ sync user จาก Okta ผ่าน SCIM

A ผิด: long-term credential + สร้างซ้ำทุก account = ops สูงสุด
B ผิด: ต้องดูแล SAML provider และ trust policy รายบัญชี 150 ครั้ง (ops สูง)
D ผิด: Cognito เป็น customer identity ไม่ใช่ workforce SSO เข้า AWS accounts

ข้อ 2 — SaaS vendor ต้อง read-only เข้าถึง account ของลูกค้าหลายราย ต้องออกแบบให้ vendor เข้าได้เฉพาะบัญชีที่ตนได้รับมอบหมาย ป้องกัน confused deputy วิธีที่ถูกคือ?

A. สร้าง IAM user + access key ให้ vendor B. Cross-account role ที่ trust vendor account พร้อม Condition บังคับ sts:ExternalId C. แชร์ root credential ของลูกค้าให้ vendor D. เปิด public read บน resource ที่เกี่ยวข้อง

เฉลย

B — cross-account role ให้ temporary credential + external ID ผูกกับลูกค้าแต่ละรายกัน confused deputy

A ผิด: long-term key แชร์ให้บุคคลภายนอก หมุนยาก เสี่ยงรั่ว
C ผิด: root credential = ให้สิทธิ์สูงสุดทั้งบัญชี ผิดหลักร้ายแรง
D ผิด: public access ละเมิด least privilege และ data protection

ข้อ 3 — Principal ใน account A ต้องอ่าน object จาก S3 bucket ใน account B ตั้ง bucket policy ใน B ให้ allow principal จาก A แล้ว แต่ยังเข้าไม่ได้ เพราะอะไร?

A. S3 ไม่รองรับ cross-account B. ต้องเปิด bucket ให้ public C. IAM identity policy ของ principal ใน account A ยังไม่ได้ allow action นั้น (cross-account ต้องผ่านทั้งสองฝั่ง) D. ต้องใช้ VPC peering ก่อน

เฉลย

C — cross-account access ต้อง allow ทั้ง resource policy (ฝั่ง B) และ identity policy (ฝั่ง A) แบบ AND

A ผิด: S3 รองรับ cross-account ผ่าน bucket policy
B ผิด: ไม่ต้อง public; แค่เปิดฝั่ง IAM ของ caller ให้ครบ
D ผิด: การเข้าถึง S3 ผ่าน API ไม่เกี่ยวกับ VPC peering

ข้อ 4 — องค์กรมีหลายสิบ project เกิดใหม่เรื่อย ๆ และ engineer ย้าย project บ่อย ต้องการให้ engineer เข้าถึงเฉพาะ resource ของ project ตน โดยไม่ต้องสร้าง policy ใหม่ทุก project แนวทางที่เหมาะสุดคือ?

A. RBAC: สร้าง role ต่อ project B. ABAC: ใช้ session tag ของ principal เทียบกับ resource tag ใน condition C. ให้ทุกคนใช้ AdministratorAccess D. สร้าง account ใหม่ต่อ project

เฉลย

B — ABAC เขียน policy กลางครั้งเดียว เทียบ aws:PrincipalTag กับ aws:ResourceTag scale ตาม project โดยไม่แตะ policy

A ผิด: policy/role ระเบิดตามจำนวน project
C ผิด: ละเมิด least privilege
D ผิด: over-engineered สำหรับการแยกสิทธิ์ระดับ resource; และไม่ตอบเรื่องการย้ายทีม (ดูบท 02 เรื่องเมื่อไหร่ควรแยก account)

ข้อ 5 — Platform team อยากให้ developer สร้าง IAM role เองเพื่อ deploy งาน แต่ต้องกันไม่ให้ developer สร้าง role ที่มีสิทธิ์เกินเพดานที่กำหนด กลไกใดเหมาะสุด?

A. SCP อย่างเดียว B. ให้ developer มี iam:* เต็ม C. Permission boundary + condition iam:PermissionsBoundary บังคับตอน create role D. MFA บังคับทุกครั้ง

เฉลย

C — permission boundary จำกัดเพดาน role ที่ developer สร้าง และ condition บังคับให้ role ใหม่ต้องแนบ boundary เสมอ (safe delegation)

A ผิด: SCP คุมระดับ account/org ไม่ได้เจาะจงการ delegate การสร้าง role ต่อ; แต่ใช้เสริมได้ (ดูบท 02)
B ผิด: privilege escalation เต็มรูปแบบ
D ผิด: MFA เป็น authentication control ไม่เกี่ยวกับการจำกัดเพดานสิทธิ์ที่มอบต่อ

ข้อ 6 — แอปมือถือมีผู้ใช้ปลายทางหลายล้านคน ต้องการ sign-up/sign-in พร้อม social login และให้ผู้ใช้ upload ไฟล์ไป S3 โดยตรงจาก client อย่างปลอดภัย ต้องใช้บริการใดและอย่างไร?

A. IAM user ต่อผู้ใช้หนึ่งคน B. Cognito user pool (authentication) + identity pool (แลกเป็น AWS temporary credential เข้า S3) C. IAM Identity Center D. ฝัง IAM access key ในแอป

เฉลย

B — user pool จัดการ sign-in/social login, identity pool แลก token เป็น scoped STS credential ให้เข้า S3 ตรง

A ผิด: IAM ไม่ scale ระดับล้านผู้ใช้แอป
C ผิด: Identity Center เป็น workforce SSO ไม่ใช่ customer app identity
D ผิด: hardcode key ในแอป = รั่วแน่นอน

ข้อ 7 — บริษัทมี on-premises Active Directory เป็น source of truth ต้องการให้ EC2/RDS SQL Server บน AWS authenticate กับ AD เดิม โดย ไม่ ต้องการ replicate directory เข้า AWS ควรใช้อะไร?

A. AWS Managed Microsoft AD สร้าง directory ใหม่ B. Simple AD C. AD Connector (proxy authentication ไป on-prem AD) D. Cognito user pool

เฉลย

C — AD Connector เป็น proxy ที่ redirect auth ไป on-prem AD โดยไม่เก็บ user ใน AWS ตรงกับ “ไม่ replicate directory”

A ผิด: Managed Microsoft AD สร้าง directory จริงใน AWS (เกินจำเป็นถ้าแค่ proxy) — เลือกเมื่อต้อง host AD/trust
B ผิด: Simple AD ไม่รองรับ trust กับ on-prem AD จริง
D ผิด: Cognito เป็น app identity ไม่ใช่ AD integration; connectivity ไป on-prem ดูบท 04

ข้อ 8 — ทีม network ต้องการให้หลาย account deploy resource ใน VPC subnet ที่เป็นของ account กลาง เพื่อรวมการจัดการ network ไว้ที่เดียวและเลี่ยง VPC ซ้ำซ้อน ควรใช้อะไร?

A. VPC peering ทุกคู่ account B. AWS Resource Access Manager (RAM) แชร์ subnet C. Cross-account IAM role D. Transit Gateway อย่างเดียว

เฉลย

B — RAM แชร์ subnet ให้ account อื่นมา deploy resource ในนั้น (VPC Sharing) รวม network ที่เดียว

A ผิด: peering เชื่อม path network ระหว่าง VPC ไม่ใช่การให้ deploy ใน subnet ร่วม (ดูบท 04)
C ผิด: cross-account role เป็นเรื่องสิทธิ์ ไม่ใช่การแชร์ network resource
D ผิด: TGW เชื่อม VPC เข้า hub แต่ไม่ทำให้ deploy ใน subnet เดียวกัน; แม้ TGW เองก็แชร์ผ่าน RAM ได้ (ดูบท 04)

ข้อ 9 — ในการ evaluate request หนึ่ง มี identity policy allow, resource policy allow, แต่มี SCP explicit deny action นั้น ผลลัพธ์คือ?

A. Allow เพราะมี allow สองที่ B. Deny เพราะ explicit deny (รวมถึงจาก SCP guardrail) ชนะทุก allow เสมอ C. ขึ้นกับลำดับที่แนบ policy D. Allow เฉพาะถ้าเป็น same-account

เฉลย

B — explicit deny ที่ใดก็ตาม (identity/resource/SCP/boundary) ชนะ allow ทั้งหมด (ดูบท 01, 02 หลักเดียวกัน)

A ผิด: allow ไม่เคยชนะ explicit deny
C ผิด: IAM evaluation ไม่ขึ้นกับลำดับ
D ผิด: same/cross-account ไม่เปลี่ยนกฎ explicit deny

7. Cross-references

บทที่ 01 — keyword mapping (existing IdP, single sign-on, temporary credentials, least operational overhead) และหลัก explicit deny > allow ที่บทนี้ขยายเต็ม
บทที่ 02 — SCP mechanics, deny list vs allow list, intersection ของ SCP × IAM, การบังคับ tag ตอนสร้างด้วย SCP aws:RequestTag (ใช้คู่กับ ABAC ในบทนี้), delegated administration ระดับ org
บทที่ 04 — networking สำหรับ AD hybrid (Direct Connect/VPN, DNS resolution, security group), การใช้ RAM แชร์ Transit Gateway/subnet ในบริบท network design, VPC peering vs TGW vs PrivateLink
บทที่ 05 — instance profile ในบริบท EC2/Auto Scaling, IRSA (OIDC) สำหรับ EKS service account
บทที่ 09 — KMS key policy vs IAM vs grant, cross-account key usage, Secrets Manager สำหรับ credential rotation (ต่อยอดจากหลักการ “อย่า hardcode credential” ในบทนี้), CloudHSM
บทที่ 10 — cost allocation tag (ใช้ tag governance ร่วมกับ ABAC), การใช้ cross-account role/RAM ในบริบท financial governance
บทที่ 11 — CloudTrail audit ของ AssumeRole/federation events, การตรวจ tag compliance (Config) เพื่อรองรับ ABAC
บทที่ 12 — การย้าย workload ที่พึ่ง AD (rehost domain-joined servers), identity ในบริบท migration