CISSP Domain 5: Identity and Access Management

Domain 5 ว่าด้วยการทำให้ subject ที่ถูกต้องเข้าถึง asset ที่ถูกต้อง ด้วยสิทธิที่ เหมาะสม ในเวลาที่เหมาะสม และทิ้งหลักฐานที่ตรวจสอบย้อนหลังได้ คำว่า subject ไม่ได้หมายถึงพนักงานเท่านั้น แต่รวม contractor, customer, partner, device, application, workload, service account และ privileged administrator ส่วน asset ครอบคลุมข้อมูล ระบบ อุปกรณ์ application, service และ facility

หลักคิดสำหรับข้อสอบ: เริ่มจาก business requirement และ identity lifecycle ก่อนเลือก authentication technology ให้สิทธิตาม least privilege และ need-to-know, แยกหน้าที่ที่ขัดกัน, ตรวจสิทธิซ้ำตลอดอายุ identity และทำให้ privileged action ผูกกลับไปยังบุคคลหรือ service owner ที่รับผิดรับชอบได้

1. ภาพรวม Domain และน้ำหนักข้อสอบ

ตาม CISSP Certification Exam Outline ของ ISC2 Domain 5 มีน้ำหนักเฉลี่ย 13% ของข้อสอบ เนื้อหาครอบคลุม physical และ logical access, identification และ authentication strategy, federated identity, authorization mechanisms, identity provisioning lifecycle และ authentication systems

คำว่า “น้ำหนักเฉลี่ย” ใช้จัดสรรเวลาอ่าน ไม่รับประกันจำนวนข้อที่ผู้สอบแต่ละคนจะพบ โจทย์มักให้สถานการณ์ซึ่งคำตอบเชิงเทคนิคหลายข้อทำได้ แต่ถามหาสิ่งที่ต้องทำ FIRST, control ที่ BEST หรือบทบาทที่มี accountability ตัวอย่างเช่น พนักงานย้ายฝ่ายแล้วต้องใช้ระบบใหม่ คำตอบที่ดีไม่ใช่เพียงเพิ่ม role ใหม่ แต่ต้อง ถอน entitlement เก่าที่ไม่จำเป็น ตรวจ Separation of Duties (SoD) และบันทึกการ อนุมัติด้วย

ความสามารถสำคัญของ Domain นี้ประกอบด้วย

1. แยก identity function ให้ถูกต้อง เข้าใจ identification, identity proofing, authentication, authorization, accounting และ accountability ว่าแก้คนละปัญหา
2. เลือก access control model ตาม requirement เปรียบเทียบ Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), rule-based และ Attribute-Based Access Control (ABAC)
3. ออกแบบ authentication และ session อย่างเป็นระบบ ใช้ authenticator, Multi-Factor Authentication (MFA), certificate, passkey, adaptive signal, timeout และ recovery ให้สัมพันธ์กับ risk
4. เชื่อม trust ข้ามระบบอย่างควบคุม เข้าใจ Single Sign-On (SSO), federation, Identity Provider (IdP), Relying Party (RP), assertion และ protocol ที่เกี่ยวข้อง
5. จัดการ identity ตลอด lifecycle ตั้งแต่ joiner, mover, leaver ไปจนถึง account review, deprovisioning, service identity และ credential retirement
6. ปกป้อง privileged access ลด standing privilege, ใช้ Privileged Access Management (PAM), Just-In-Time (JIT), session monitoring และ emergency access

Domain 5 รับ business authority และ risk requirement จาก Domain 1, classification กับ handling requirement จาก Domain 2, trust และ cryptographic capability จาก Domain 3 และ network admission context จาก Domain 4 การตัดสินสิทธิยังต้องย้อนกลับ ไปยัง Data owner หรือ System owner ผู้กำหนด requirement ส่วน Risk owner เป็นผู้มี authority ยอมรับ residual risk ไม่ใช่ administrator หรือผู้ติดตั้ง IAM โดยอัตโนมัติ

2. แนวคิดหลักพร้อมคำอธิบาย

2.1 Identity ไม่เท่ากับ account และ account ไม่เท่ากับสิทธิ

Digital identity คือชุด attribute และ identifier ที่แทน subject ภายในบริบทหนึ่ง บุคคลเดียวอาจมี employee identity, customer identity และ administrator identity หลายชุดโดยมีวัตถุประสงค์ต่างกัน Account คือ record ที่ระบบใช้จัดการการเข้าถึง ส่วน entitlement คือสิทธิหรือความสามารถที่ account ได้รับ เช่น อ่าน repository, อนุมัติ invoice หรือ restart production service

การสร้าง account จึงไม่พิสูจน์ว่าบุคคลนั้นเป็นใคร และการ authenticate สำเร็จก็ไม่ ควรทำให้ได้รับทุก entitlement Identity architecture ต้องรักษาความสัมพันธ์ authoritative source → identity → account → role/attribute → entitlement → resource พร้อม owner, approval, เวลาเริ่ม-สิ้นสุด และ evidence ที่ตรวจสอบได้

2.2 AuthN, AuthZ และ accountability เป็นคนละชั้น

Authentication (AuthN) สร้างความเชื่อมั่นว่า claimant ควบคุม authenticator ที่ ผูกกับ identity ที่อ้าง Authorization (AuthZ) ตัดสินว่า subject ที่ผ่าน AuthN แล้วทำ action ใดกับ object ใดได้ภายใต้ policy และ context ปัจจุบัน ส่วน accountability คือความสามารถผูก action กับ subject หรือผู้มี authority และให้ บุคคลนั้นรับผิดรับชอบต่อผลได้

AuthN ที่แข็งแรงไม่แก้ AuthZ ที่กว้างเกิน ตัวอย่างเช่น attacker ใช้ session ของ พนักงานที่ผ่าน MFA แล้วเรียก API ซึ่งขาด object-level authorization ข้อมูลยังรั่วได้ ในทางกลับกัน policy อาจถูกต้องแต่ log ใช้ shared account ทำให้ระบุผู้กระทำไม่ได้ ระบบจึงต้องออกแบบ authentication, authorization, session และ audit trail ร่วมกัน

2.3 Least privilege เป็นสถานะที่ต้องรักษา ไม่ใช่อนุมัติครั้งเดียว

Least privilege ให้เฉพาะสิทธิขั้นต่ำที่จำเป็นต่อหน้าที่ในช่วงเวลาที่ต้องใช้ Need-to-know เพิ่มเงื่อนไขว่าบุคคลต้องมีเหตุผลทางงานที่จะเข้าถึงข้อมูลนั้น แม้มี clearance หรืออยู่ใน role ที่กว้างกว่า ส่วน SoD แยกงานที่ขัดกันเพื่อไม่ให้บุคคลเดียว เริ่ม อนุมัติ และปกปิดธุรกรรมสำคัญได้

สิทธิที่เหมาะสมในวันแรกอาจกลายเป็น privilege creep หลังย้ายงานหรือทำ project จบ จึงต้องมี expiry, access review, event-driven revocation และ usage monitoring JIT access ลดเวลาที่ privilege เปิดอยู่ ส่วน Just-Enough Administration (JEA) ลดขอบเขตคำสั่งหรือ resource ที่ใช้ได้ ทั้งสองหลักเสริมกันแต่ไม่ใช่สิ่งเดียวกัน

2.4 Policy decision ต้องแยกจากจุดบังคับใช้

ระบบ authorization สมัยใหม่มักแยก Policy Decision Point (PDP) ซึ่งประเมิน policy ออกจาก Policy Enforcement Point (PEP) ซึ่ง intercept request และบังคับ ผล allow/deny ข้อมูลประกอบอาจมาจาก identity directory, attribute source, device posture, classification หรือ threat signal

ถ้า PEP บังคับไม่ครบทุก path ต่อให้ PDP ตัดสินถูกก็ยังมี bypass หาก attribute เก่า หรือไม่น่าเชื่อถือ ผลตัดสินก็ผิดได้ Design ต้องกำหนด default behavior เมื่อ PDP, directory หรือ risk engine ใช้งานไม่ได้ โดยพิจารณาทั้ง security, Availability และ human safety ไม่ใช้คำว่า fail closed เป็นคำตอบอัตโนมัติทุกกรณี

2.5 Centralization เพิ่ม consistency และเพิ่ม concentration risk

Directory, SSO และ federation ช่วยรวม policy, ลด password proliferation และเร่ง revocation แต่ทำให้ IdP, directory, signing key และ administrative plane เป็น dependency สำคัญ หากถูกยึด attacker อาจเข้าถึงหลาย application ด้วย trust เดียว หากล่ม ผู้ใช้ก็อาจเข้า service จำนวนมากไม่ได้

จึงต้อง harden identity plane, แยก privileged administration, ปกป้อง signing key, ทดสอบ recovery, จำกัด assertion และ token, เฝ้าระวัง configuration change และไม่ ให้ทุก application รับ trust กว้างเท่ากัน SSO ลดจำนวนครั้งที่ login ไม่ได้ลดความ จำเป็นของ authorization ต่อ resource

2.6 Human และ non-human identity ต้องมี governance เท่าเทียมกัน

Device, service, workload, API client, automation และ AI agent ล้วนเป็น subject ที่ อาจถือ privilege สูง Non-human identity มักเพิ่มเร็ว ถูกฝัง secret ไว้นาน ไม่มี owner ชัดเจน และไม่เข้ากระบวนการ HR offboarding จึงกลายเป็นช่องโหว่แม้ user account ถูกจัดการดี

ทุก identity ต้องมี unique identifier, owner, purpose, allowed resource, credential lifecycle, monitoring และ retirement trigger เมื่อทำได้ให้ใช้ short-lived credential หรือ workload identity ที่ออกตาม runtime context แทน static secret ที่ คัดลอกข้าม environment แต่ต้องตรวจ trust ของ platform ที่ออก credential ด้วย

3. เจาะลึกหัวข้อย่อยพร้อมตัวอย่าง

3.1 Identification, identity proofing, authentication และ AAA

ลำดับพื้นฐานของการเข้าถึงเริ่มจาก identification ซึ่ง subject อ้าง identifier เช่น username หรือ certificate subject จากนั้นระบบทำ AuthN, ตัดสิน AuthZ และสร้าง record เพื่อ accounting/accountability Username ไม่ใช่ secret และการรู้ employee ID ไม่ใช่หลักฐานว่าผู้นั้นเป็นเจ้าของ identity

Identity proofing เชื่อม digital identity กับบุคคลหรือ entity ที่มีอยู่จริงตาม ระดับความเชื่อมั่นที่ use case ต้องการ อาจตรวจเอกสาร แหล่งข้อมูลที่เชื่อถือ การพบ ตัว หรือวิธี remote proofing ที่มี anti-fraud control ไม่ใช่ทุก service ต้องรู้ชื่อ จริง บริการบางอย่างอนุญาต pseudonymous identity ได้ หาก mission และ obligation ไม่ ต้องการ real-world identity การเก็บหลักฐานมากเกินจำเป็นเพิ่ม privacy และ breach risk

Enrollment สร้าง subscriber account และผูก authenticator หลัง proofing หรือ registration ส่วน credential เป็นข้อมูลหรือโครงสร้างที่เชื่อม identity กับ authenticator หรือ attribute ที่เกี่ยวข้อง คำว่า authenticator เน้นสิ่งที่ claimant ครอบครองและใช้พิสูจน์การควบคุม เช่น password secret, private key หรือ hardware authenticator

Authentication, Authorization and Accounting (AAA) ใช้แพร่หลายใน network และ administrative access

• Authentication ตรวจ credential หรือ authenticator ของ subject
• Authorization ส่งหรือบังคับ policy เช่น network segment, command privilege หรือ session parameter
• Accounting บันทึกเวลาเริ่ม-จบ ปริมาณการใช้ คำสั่งหรือ event ที่เกี่ยวข้อง

Accounting สนับสนุน accountability แต่ไม่เท่ากัน Log ที่ไม่มี unique identity, เวลาเชื่อถือไม่ได้ ถูกแก้ไขได้ หรือไม่มีผู้ review ย่อมพิสูจน์ผู้กระทำได้จำกัด Accountability ต้องมี governance, individual attribution, evidence protection และ consequence process เพิ่มเติม

ภาพนี้แยกหน้าที่แต่ละชั้นตั้งแต่การอ้าง identity ไปจนถึงการผูก action เพื่อ accountability

flowchart LR Subject["Subject / claimant"] --> Ident["Identification: อ้าง identity"] Ident --> Authn["Authentication (AuthN): พิสูจน์ authenticator"] Authn --> Authz["Authorization (AuthZ): ตัดสิน action ต่อ object"] Authz --> Result["ผลการเข้าถึง resource"] Authn --> Acct["Accounting: บันทึก event"] Authz --> Acct Result --> Acct Acct --> Accountable["Accountability: ผูก action กับ subject / authority"]

3.2 Authentication factors และ MFA

Authentication factor แบบดั้งเดิมแบ่งเป็น

• Something you know เช่น password หรือ Personal Identification Number (PIN)
• Something you have เช่น smart card, hardware authenticator หรือ private key ในอุปกรณ์ที่ควบคุม
• Something you are เช่น biometric characteristic

Location และ behavioral pattern เช่น typing rhythm ใช้เป็น contextual หรือ adaptive signal ได้ แต่ไม่ควรนับเป็น factor ที่เป็นอิสระโดยอัตโนมัติ MFA ต้องใช้ factor อย่างน้อยสองประเภทที่ต่างกัน Password สองชุดยังเป็น single-factor เพราะทั้งคู่คือ something you know Smart card ที่ต้องใช้ PIN รวม possession กับ knowledge จึงเป็น สอง factor หาก protocol และ implementation แยกการควบคุมจริง

Password policy ต้องเน้นความยาว การป้องกัน password ที่พบบ่อยหรือรั่ว การใช้ password manager, rate limiting, secure recovery และ salted password hashing ตาม Domain 3 การบังคับเปลี่ยนตามปฏิทินโดยไม่มีเหตุอาจทำให้ผู้ใช้เลือก pattern ที่เดาง่าย แต่ต้องเปลี่ยนเมื่อมีหลักฐานว่า secret ถูกเปิดเผยหรือเมื่อ risk กำหนด

One-Time Password (OTP) ลดการนำรหัสเดิมกลับมาใช้ แต่ OTP ที่ผู้ใช้พิมพ์ให้ เว็บไซต์ปลอมอาจถูก relay แบบ real time Push notification อาจถูกโจมตีด้วย MFA fatigue Phishing-resistant authentication ใช้ cryptographic binding กับ verifier หรือ origin ที่ถูกต้อง เช่น FIDO/WebAuthn หรือ certificate-based mechanism ที่ ออกแบบและ validate อย่างเหมาะสม จึงต่างจากเพียงมีหลาย factor

Passkey ใช้ public-key credential โดย private key อยู่กับ authenticator และไม่ ส่ง shared password ให้ verifier Passkey อาจ sync ข้ามอุปกรณ์ตาม ecosystem และ assurance ขึ้นกับ authenticator, account recovery, device protection และ sync trust คำว่า “passwordless” ไม่รับประกันว่าเป็น MFA หรือ phishing-resistant ทุกแบบ ต้อง ตรวจ protocol และ threat model

Biometric ไม่เปลี่ยนได้ง่ายเหมือน password และ sensor อาจมี error จึงต้องมี liveness/presentation-attack detection, protected template, alternative method และ privacy control False Acceptance Rate (FAR) คือสัดส่วนที่ระบบยอมรับผู้ไม่ควรผ่าน ส่วน False Rejection Rate (FRR) คือสัดส่วนที่ปฏิเสธผู้ควรผ่าน เมื่อปรับ threshold ให้เข้ม FAR มักลดแต่ FRR มักเพิ่ม จุดที่สองอัตรามีค่าเท่ากันเรียก Crossover Error Rate (CER) หรือ Equal Error Rate (EER); ค่าต่ำกว่าบ่งชี้การแยกที่ดีกว่าในการทดสอบ เดียวกัน แต่ performance จริงยังขึ้นกับประชากร sensor และ attack condition

3.3 Authentication systems, certificate, Kerberos และ session

Certificate-based authentication ให้ subject พิสูจน์ว่าควบคุม private key ที่ สัมพันธ์กับ public-key certificate ระบบต้อง validate chain, issuer, validity, revocation ตาม requirement, key usage, subject binding และ peer name/context การมี certificate เพียงอย่างเดียวไม่พอหาก private key ถูกขโมยหรือ authorization mapping ผิด Smart card สามารถเก็บ private key ใน hardware และใช้ PIN เพื่อ activate key ได้

Kerberos เป็น ticket-based authentication protocol สำหรับ environment ที่มี Key Distribution Center (KDC) ซึ่งประกอบด้วย Authentication Service (AS) และ Ticket-Granting Service (TGS) หลัง initial authentication client ได้ Ticket-Granting Ticket (TGT) เพื่อขอ service ticket โดยไม่ส่ง password ไปยังทุก service ข้อดีคือ centralized authentication และ SSO ภายใน trust domain ข้อจำกัดคือ KDC เป็น critical dependency, symmetric keys ต้องป้องกัน, เวลา client/server ต้อง สอดคล้อง และ ticket theft หรือ service account key compromise ยังสร้างผลกระทบได้

Directory เช่น Lightweight Directory Access Protocol (LDAP) เก็บและค้น identity, group กับ attribute ได้ แต่ LDAP เป็น access protocol ไม่ใช่ access control model การใช้ LDAP bind, TLS, directory ACL และ application authorization เป็นคนละส่วน อย่าสรุปว่าระบบปลอดภัยเพียงเพราะ “เชื่อม Active Directory” หรือ directory กลางแล้ว

หลัง AuthN สำเร็จ ระบบมักออก session หรือ token เพื่อไม่ให้พิสูจน์ใหม่ทุก request Session management ต้องป้องกัน identifier จากการคาดเดาและ theft, rotate หลัง privilege change, ใช้ idle และ absolute timeout, reauthenticate หรือ step-up ก่อน action สำคัญ, revoke เมื่อ account หรือ risk เปลี่ยน และป้องกัน Cross-Site Request Forgery (CSRF) ตาม application design การ logout ที่ลบเฉพาะ browser cookie แต่ token ฝั่ง server ยังใช้ได้ไม่ใช่ revocation ที่สมบูรณ์

Adaptive authentication ใช้ signal เช่น device posture, location anomaly, behavior, resource sensitivity และ threat intelligence เพื่อ allow, deny หรือขอ step-up authentication Signal เหล่านี้ต้องมีคุณภาพ อธิบายได้ในระดับที่ governance ต้องการ และไม่สร้าง privacy หรือ discrimination risk โดยไม่มีการควบคุม

3.4 Authorization และ access control models

Authorization ตอบคำถามว่า subject ใดทำ operation ใดกับ object ใดภายใต้เงื่อนไข อะไร Model แต่ละแบบเหมาะกับ governance และ scale ต่างกัน องค์กรจริงมักผสมหลายแบบ เช่น RBAC ให้ baseline ตามหน้าที่ แล้ว ABAC จำกัดเพิ่มตาม classification, device และ เวลา

Model	ผู้กำหนดหรือข้อมูลตัดสินหลัก	จุดแข็ง	Risk และข้อจำกัดสำคัญ
DAC	Owner ของ object มอบสิทธิให้ subject อื่นตาม discretion	ยืดหยุ่น เหมาะกับ collaboration และ file ownership	สิทธิแพร่ต่อหรือสะสมง่าย; owner อาจตัดสินไม่สอดคล้อง policy กลาง
MAC	Authority กลางกำหนด label, clearance และกฎที่ user เปลี่ยนเองไม่ได้	บังคับ information-flow policy สม่ำเสมอ เหมาะกับ requirement เข้ม	แข็งและบริหารยาก; label/clearance ผิดทำให้ผลตัดสินผิด
RBAC	Role เชื่อม job function กับ permission แล้ว assign user เข้า role	review และ scale ง่ายกว่ามอบสิทธิรายคน; สนับสนุน SoD	Role explosion, role drift และ toxic role combination
Rule-based	System-wide rule เช่น เวลา network หรือ transaction condition	บังคับเงื่อนไขที่ชัดเจนแบบอัตโนมัติ	Rule conflict, ลำดับ และ exception ทำให้ซับซ้อน
ABAC	Attribute ของ subject, object, action และ environment เทียบกับ policy	ละเอียดและ dynamic รองรับหลายองค์กรและ context	ต้องมี attribute authority, freshness, policy testing และ explainability
Risk-based	Risk score หรือ adaptive signal ณ เวลาขอ access	ตอบสนอง threat/context ได้แบบ dynamic	False decision, opaque model และ fallback อาจกระทบ security หรือ Availability

DAC มักเห็นใน file permission ที่ owner grant สิทธิได้ MAC ไม่ได้แปลว่าใช้ Message Authentication Code ซึ่งย่อเป็น MAC เหมือนกัน ต้องดูบริบท ใน access control คำนี้คือ Mandatory Access Control และมักเชื่อม subject clearance กับ object label ตาม policy กลาง

RBAC ควรเริ่มจาก role engineering ตาม business process ไม่ใช่คัดลอกสิทธิของ พนักงานคนก่อน Role อาจมี hierarchical inheritance, mutually exclusive roles และ ข้อจำกัดว่าใคร activate role ได้ Static SoD กันไม่ให้บุคคลถือ role ที่ขัดกัน พร้อมกัน ส่วน Dynamic SoD อาจยอมให้ถือหลาย role แต่ห้ามใช้ role ขัดกันใน transaction หรือ session เดียวกัน

Rule-based access control ไม่เหมือน RBAC ตัวแรกตัดสินด้วย rule ที่ใช้ทั่วระบบ เช่น “ปฏิเสธ administrative login นอก maintenance window” ส่วน RBAC ตัดสินจาก role ที่ subject ได้รับ Rule อาจใช้ประกอบ DAC, MAC, RBAC หรือ ABAC ได้

ABAC ประเมิน attribute เช่น subject.department = finance, object.classification = confidential, action = approve, device.managed = true และ environment.time กับ policy จุดท้าทายไม่ใช่เพียงเขียน expression แต่ต้องรู้ว่า ใครออก attribute, อัปเดตเมื่อไร, เชื่อถือข้ามองค์กรได้หรือไม่ และ deny reason ถูก บันทึกหรือไม่ Attribute ที่ stale หลังพนักงานย้ายฝ่ายทำให้ policy ที่ถูกต้องในเชิง ตรรกะอนุญาตผิดคนได้

Access Control List (ACL) ผูก object กับรายชื่อ subject/group และ permission ส่วน capability เป็นสิ่งอ้างอิงที่ subject ถือเพื่อแสดงสิทธิต่อ object ทั้งสองเป็น กลไก representation ไม่ได้จับคู่กับ governance model เพียงแบบเดียว ต้องป้องกันการ ปลอม คัดลอก ใช้ซ้ำ และ revoke ตามรูปแบบของระบบ

3.5 SSO และ federated identity

SSO ให้ผู้ใช้ authenticate ครั้งหนึ่งแล้วเข้าหลาย application โดยไม่ต้อง login ซ้ำทุกครั้งในช่วง session ที่กำหนด ช่วยลด password fatigue และรวม authentication policy แต่เพิ่ม blast radius ของ credential/session compromise และ dependency ต่อ SSO service Application ยังต้องตัดสิน authorization ของตน และ sensitive action อาจ ต้อง step-up หรือ reauthentication

Federation คือ trust arrangement ที่ Relying Party หรือ Service Provider (SP) ยอมรับ assertion/token เกี่ยวกับ subject จาก IdP ต่าง administrative domain การมี federation มักสนับสนุน SSO แต่สองคำไม่เท่ากัน SSO อาจเกิดใน domain เดียวผ่าน Kerberos หรือ shared identity platform ส่วน federation อาจใช้กับ transaction เดียวโดยไม่ให้ ประสบการณ์ SSO ต่อเนื่อง

องค์ประกอบ trust ที่ต้องกำหนด ได้แก่ issuer และ audience ที่อนุญาต, signing หรือ encryption key, attribute mapping, assurance, token lifetime, clock tolerance, revocation/termination, metadata change, privacy, incident notification และ responsibility ของแต่ละฝ่าย Federation ลดการสร้าง password ที่ RP แต่ไม่ได้โอน accountability ของ RP ในการกำหนดสิทธิและปกป้อง resource ไปให้ IdP

ภาพนี้แสดง trust ข้าม administrative domain โดย RP ยังต้องตัดสิน AuthZ ต่อ resource ของตน

flowchart LR User["Subject / user"] --> Idp["IdP: ทำ Authentication"] Idp --> Token["Assertion / token"] Token --> Rp["RP / SP: ตรวจตาม trust context"] Rp --> LocalAuthz["Local Authorization (AuthZ)"] LocalAuthz --> Resource["Resource"] Trust["Trust agreement: issuer, audience, key, attribute, assurance, lifetime"] -.-> Idp Trust -.-> Rp

Protocol และมาตรฐานที่พบบ่อยมีดังนี้

• Security Assertion Markup Language (SAML) ใช้ XML assertion ส่งข้อมูล authentication และ attribute ระหว่าง IdP กับ SP พบบ่อยใน browser-based enterprise federation ต้อง validate signature, issuer, audience, recipient, time และ assertion binding ให้ครบ
• OpenID Connect (OIDC) เป็น identity layer บน OAuth 2.0 ใช้ ID Token เพื่อส่ง authentication claims และมี UserInfo endpoint ตาม flow ต้อง validate issuer, audience, signature, nonce และ flow-specific controls
• OAuth 2.0 เป็น authorization framework สำหรับ delegated access ให้ client ใช้ access token เรียก resource ตาม scope ไม่ใช่ authentication protocol โดยตัวมันเอง การใช้ access token แทนหลักฐานว่า user login โดยไม่มี OIDC หรือ design ที่ถูกต้อง เป็นข้อผิดพลาด
• System for Cross-domain Identity Management (SCIM) เป็นมาตรฐานสำหรับ provisioning และจัดการ user/group ข้ามระบบ ไม่ใช่ authentication หรือ SSO

ตัวอย่าง: บริษัทให้พนักงานใช้ SaaS ผ่าน corporate IdP เมื่อ HR ปิดสถานะพนักงาน workflow ต้อง disable identity, ถอน active session/token ตาม capability, ส่ง SCIM deprovisioning ไป SaaS และตรวจว่า local fallback account ไม่ค้างอยู่ การปิด account ที่ IdP อย่างเดียวอาจไม่หยุด long-lived token หรือ local account ของ provider

Federation risk สำคัญคือ account linking ผิด, domain takeover, weak recovery, overbroad attribute, token replay, signing key compromise และ configuration drift ระหว่าง on-premises, cloud และ hybrid trust Trust agreement ต้องมี technical validation และ contractual responsibility ไม่ใช่เพียงแลก metadata แล้วจบ

3.6 Physical และ logical access enforcement

Physical access control ปกป้อง facility, room, rack และอุปกรณ์ หลักทั่วไปคือ deterrence, delay, detection, response และ evidence Control อาจประกอบด้วย perimeter, guard, badge, smart card, biometric, turnstile, access control vestibule, lock, camera, alarm และ visitor escort ต้องออกแบบตาม safety, accessibility, emergency egress และ privacy ไม่ใช้ control ที่ขัดกับการอพยพหรือชีวิต

Tailgating คือผู้ไม่มีสิทธิเดินตามผู้มีสิทธิเข้าพื้นที่โดยไม่ได้รับ authorization ส่วน piggybacking มักใช้เมื่อผู้มีสิทธิยินยอมหรือช่วยพาเข้า แม้ตำราบางแห่งใช้สองคำ สลับกัน Control เช่น awareness, guard, anti-passback, turnstile และ access vestibule ช่วยลด risk แต่ต้องมี emergency override และ monitoring

Logical access มี enforcement หลายชั้น ได้แก่ operating system, database, application, API, cloud control plane, network และ data object การผ่าน badge เข้าห้อง หรือผ่าน Network Access Control (NAC) ไม่ได้ให้สิทธิ application โดยอัตโนมัติ และ การอยู่ใน corporate network ไม่แทน AuthN/AuthZ ตามหลัก Zero Trust Architecture

Defense in depth ใช้ control ต่างชนิดซ้อนกัน เช่น device certificate สำหรับ network admission, user MFA สำหรับ SSO, RBAC/ABAC สำหรับ application, database permission สำหรับ data และ log สำหรับ accountability หากทุกชั้น map กลับไป shared group ที่กว้างหรือใช้ shared credential เดียวกัน ความหลากหลายภายนอกอาจซ่อน common failure ภายใน

3.7 Identity lifecycle: joiner, mover และ leaver

Lifecycle ที่ควบคุมได้เริ่มจาก authoritative source และ event ที่น่าเชื่อถือ เช่น HR record สำหรับ workforce, contract system สำหรับ supplier หรือ asset registry สำหรับ device ขั้นตอนหลักมีดังนี้

1. Define ระบุ identity type, owner, naming rule, baseline role, proofing และ retention requirement
2. Approve ให้ Data owner, System owner หรือ delegated approver อนุมัติ entitlement ตาม business need พร้อมตรวจ SoD
3. Provision สร้าง unique account และ credential ผ่าน workflow ที่บันทึกได้ หลีกเลี่ยง manual copy จากผู้ใช้คนอื่น
4. Operate monitor authentication, privilege use, dormant account, credential age และ anomaly พร้อมให้ผู้ใช้รายงาน lost authenticator
5. Change เมื่อย้าย role, project หรือ location ให้เพิ่มสิทธิใหม่และถอนสิทธิเก่า ตาม effective time ไม่ทำแต่ add-only
6. Review ให้ owner recertify entitlement ตาม risk และตรวจทั้ง direct grant, group inheritance, nested role, local account และ emergency exception
7. Revoke and retain disable access อย่างทันท่วงที ถอน session/key/token และเก็บ record ตาม legal, audit และ investigation requirement ก่อนลบเมื่อครบ retention

ภาพนี้แยก control ของ Joiner, Mover และ Leaver จาก lifecycle event เดียวกัน

flowchart TD Source["Authoritative source / trusted event"] --> Event["Lifecycle event"] Event --> Joiner["Joiner: baseline, approval, provisioning"] Event --> Mover["Mover: grant สิทธิใหม่ และ revoke สิทธิเก่า"] Event --> Leaver["Leaver: disable access และถอน session / key / token"] Joiner --> Operate["Operate: monitor และ review entitlement"] Mover --> Operate Operate --> Review["Access review / recertification"] Review --> Operate Leaver --> Retain["Retain record / evidence ตาม requirement"]

Joiner ต้องได้ baseline ที่เหมาะกับหน้าที่ ไม่ใช่ entitlement สูงสุดเพื่อความ สะดวก Mover เป็นจุดเกิด privilege creep มากที่สุด เพราะองค์กรมักเพิ่มสิทธิใหม่ โดยไม่ถอนของเดิม Leaver ที่มีความเสี่ยงอาจต้องประสาน HR, manager, physical security, IAM และ operations ให้ badge, remote session, API key และ privileged path ถูกถอนตามเวลาที่กำหนด การลบ account ทันทีโดยไม่พิจารณา evidence, record ownership หรือ retention อาจทำลายข้อมูลที่องค์กรยังต้องใช้ จึงมัก disable ก่อนแล้ว disposition ตาม process

Access review ที่มีคุณภาพให้ผู้รู้ business context ตัดสินจากสิทธิจริง ไม่ใช่เพียง ส่ง spreadsheet รายชื่อ account ให้กดยืนยัน Reviewer ต้องเห็น entitlement, source, last use, owner, SoD conflict, expiry และ resource sensitivity พร้อมติดตาม revocation จนสำเร็จ Orphaned account ไม่มี owner หรือไม่ผูกกับ active identity ส่วน dormant account ไม่ได้ใช้นาน ทั้งคู่ต้องตรวจสอบ แต่อาจมีเหตุผลทางระบบหรือ retention ที่ต่างกัน จึงไม่ควรลบทันทีโดยไม่มี validation

3.8 Privileged Access Management

Privileged identity สามารถเปลี่ยน security configuration, สร้าง identity, อ่านข้อมูล กว้าง, ข้าม control หรือทำให้ service หยุดได้ ตัวอย่างคือ domain administrator, cloud tenant administrator, database administrator, root, network administrator, application deployment identity และ account ที่จัดการ IAM เอง Privilege จึงวัดจาก ผลกระทบ ไม่ใช่ชื่อ account เท่านั้น

PAM เป็นชุด governance, process และ technology สำหรับควบคุม privileged access องค์ประกอบที่สำคัญ ได้แก่

• แยก standard user account ออกจาก named administrative account และห้ามใช้ admin identity อ่าน email หรือ browse web โดยไม่จำเป็น
• เก็บ credential ที่หลีกเลี่ยงไม่ได้ใน vault, จำกัด checkout, rotate หลังใช้หรือ เมื่อมีเหตุ และไม่เปิด secret ให้ operator เห็นหากใช้ broker ได้
• ใช้ JIT elevation, time-bound approval และ JEA เพื่อลด standing privilege
• บังคับ MFA และ privileged access workstation หรือ hardened management path ตาม risk
• proxy, record หรือ log privileged session/command โดยคุ้มครอง sensitive data และ แจ้งผู้เกี่ยวข้องตาม policy
• ตรวจ toxic combination, unusual command, mass access และ privilege escalation
• กำหนด owner, review, expiry และ recovery ให้ service/root/built-in account

Privilege escalation อาจเป็นสิ่งที่ได้รับอนุญาต เช่นใช้ sudo ทำคำสั่งเฉพาะหลัง approval หรือเป็น attack ที่ใช้ช่องโหว่เพื่อเพิ่มสิทธิ Control ต้องแยกสองกรณีผ่าน policy, secure configuration และ audit การบันทึกว่า user รัน sudo อย่างเดียวไม่พอ หากไม่รู้ command, target, time, result และ ticket/justification ที่เกี่ยวข้อง

Break-glass account ใช้เมื่อ normal identity path ล้มเหลว ต้องมีจำนวนจำกัด, credential ป้องกันแยกจาก dependency ปกติ, MFA หรือ compensating control ตาม use case, alert เมื่อใช้, procedure อนุมัติย้อนหลังเมื่อเหตุฉุกเฉินไม่ให้รอล่วงหน้า, rotation หลังใช้ และการทดสอบเป็นระยะ Emergency account ที่ไม่เคยทดสอบอาจใช้ไม่ได้เมื่อ IdP ล่ม ส่วน account ที่ exempt monitoring กลายเป็น backdoor

Shared privileged account ลด accountability หาก legacy system หลีกเลี่ยงไม่ได้ให้ใช้ named login เข้าสู่ PAM broker ก่อน checkout, จำกัดคนและเวลา, บันทึก session, rotate credential และวางแผนเลิกใช้ Shared secret ในเอกสารหรือ chat ไม่ใช่ vault และการซ่อน password จาก user ไม่ได้ทดแทน authorization กับ session control

3.9 Service, device และ workload identities

Service account ไม่ควรใช้ password แบบ human ที่ไม่มีวันหมดอายุ แนวทางที่ดีกว่าคือ managed service identity, certificate, platform-attested workload identity หรือ short-lived token ที่ออกให้ workload ตาม environment พร้อม audience และ scope จำกัด หากจำเป็นต้องใช้ long-lived secret ต้องเก็บใน secret manager, rotate อัตโนมัติ, จำกัด egress/read permission และตรวจการใช้นอก pattern

Lifecycle ของ non-human identity ต้องผูกกับ application owner และ deployment lifecycle เมื่อ retire service ต้องถอน account, key, certificate, trust policy, federation client และ network rule ที่เกี่ยวข้อง CI/CD identity ไม่ควรมี privilege ถาวรข้าม development, test และ production และ repository ไม่ควรเก็บ production secret ใน source code

Device identity อาจสร้างจาก certificate, hardware key หรือ enrollment record แต่ device authentication ไม่พิสูจน์ว่า user ที่ถือ device ได้รับอนุญาต และ user AuthN ไม่พิสูจน์ว่า device compliant การตัดสิน access ที่มี risk สูงจึงมักใช้ทั้ง user identity, device identity, posture และ resource policy

3.10 Network AAA, 802.1X และ access admission

IEEE 802.1X เป็น framework สำหรับ port-based network access control โดยมี supplicant ที่ endpoint, authenticator เช่น switch/access point และ authentication server ซึ่งมักใช้ Remote Authentication Dial-In User Service (RADIUS) กับ Extensible Authentication Protocol (EAP) Authenticator ควบคุม port แต่ อาจส่ง authentication exchange ไป server เพื่อ validate user/device และรับ policy

RADIUS ใช้บ่อยกับ remote/network access ส่วน Terminal Access Controller Access-Control System Plus (TACACS+) ใช้บ่อยกับ administration ของ network device เพราะแยก authentication, authorization และ accounting ของ command ได้ละเอียดกว่าในหลาย implementation ต้องป้องกัน channel, shared secret/key, server availability และ configuration ตาม protocol/product ไม่ถือว่า AAA server กลางปลอดภัยโดยอัตโนมัติ

NAC อาจตรวจ identity, certificate, device posture และ compliance ก่อน assign VLAN, access policy หรือ quarantine แต่ network admission ไม่ให้ application entitlement และ posture เป็นข้อมูล ณ เวลาหนึ่ง ต้องตรวจซ้ำเมื่อ risk เปลี่ยน Remote access ผ่าน VPN ก็เช่นกัน: tunnel ที่ authenticate สำเร็จปกป้อง channel แต่ยังต้อง enforce least privilege ที่ application และ data layer

4. กรอบมาตรฐานที่เกี่ยวข้อง

4.1 NIST

NIST Cybersecurity Framework (CSF) 2.0 วาง IAM ไว้ในวงจร outcome ตั้งแต่ Govern กำหนด policy/role, Identify ทำ inventory ของ identity และ dependency, Protect จัดการ identity/authentication/access, Detect เฝ้าระวัง misuse, Respond ถอน session หรือ credential และ Recover ฟื้น identity service กับ emergency access

NIST SP 800-63-4 Digital Identity Guidelines เป็นชุดแนวทาง risk-based สำหรับ digital identity ของบุคคล โดยแยก Identity Assurance Level (IAL) สำหรับ identity proofing, Authentication Assurance Level (AAL) สำหรับ authentication และ Federation Assurance Level (FAL) สำหรับ federation ชุดเอกสารประกอบด้วย SP 800-63A-4 เรื่อง proofing/enrollment, SP 800-63B-4 เรื่อง authentication และ authenticator management และ SP 800-63C-4 เรื่อง federation/assertion ไม่ควรนำ ข้อกำหนดเฉพาะ federal service ไปใช้แบบ checklist โดยไม่วิเคราะห์ mission, privacy, customer experience และ organizational risk

เอกสาร NIST อื่นที่เกี่ยวข้อง ได้แก่

• NIST SP 800-162, Guide to Attribute Based Access Control Definition and Considerations ให้นิยาม ABAC จาก attribute ของ subject, object, operation และ environment ที่ประเมินกับ policy
• NIST SP 800-53 Rev. 5 มีกลุ่ม control ที่สัมพันธ์โดยตรง เช่น Access Control (AC), Identification and Authentication (IA) และ Audit and Accountability (AU)
• NIST SP 800-207, Zero Trust Architecture เน้นไม่ให้ implicit trust จาก network location และให้ตัดสิน access ต่อ resource จาก identity, context และ policy

4.2 ISO/IEC 27001 และ ISO/IEC 27002

ISO/IEC 27001:2022 กำหนด requirement สำหรับ Information Security Management System (ISMS) และใช้ Annex A เป็น reference controls ที่เลือกตาม risk พร้อมบันทึกใน Statement of Applicability (SoA) หัวข้อ IAM ที่เกี่ยวข้องโดยตรง ได้แก่ access control, identity management, authentication information, access rights, privileged access rights, information access restriction และ secure authentication รวมถึง physical entry, logging, monitoring และ supplier/cloud access ที่สัมพันธ์กัน

ISO/IEC 27002:2022 ให้ implementation guidance เพิ่มเติม หลักสำคัญคือมี lifecycle ของ identity และ authentication information, จำกัด privileged right, review access rights หลัง change และ termination และรักษาหลักฐาน ไม่ใช่เพียงมี directory หรือ MFA แล้วถือว่า ISMS สอดคล้อง

4.3 COBIT

COBIT 2019 เชื่อม IAM กับ governance และ management objectives เช่น APO13 Managed Security, DSS05 Managed Security Services, DSS06 Managed Business Process Controls และ MEA สำหรับ monitoring/evaluation COBIT เหมาะกับการกำหนด decision rights, process owner, segregation, metric และ assurance มากกว่าบอกว่าจะ configure SAML claim หรือ PAM vault อย่างไร

ตัวอย่างการใช้: governance body กำหนด risk appetite, management กำหนด access policy, business owner อนุมัติ entitlement, IAM operations provision/revoke, security operations monitor misuse และ assurance function ประเมินว่า access review กับ deprovisioning ให้ผลตาม objective หรือไม่

4.4 ITIL

ITIL 4 มอง identity service เป็นส่วนหนึ่งของ service value system Practices ที่ เกี่ยวข้อง ได้แก่ information security management, service configuration management, change enablement, monitoring and event management, incident management และ service desk IAM change ต้องเชื่อมกับ joiner/mover/leaver, service dependency, request model, approval, incident และ recovery

Service desk มีบทบาทสูงใน password reset และ account recovery จึงเป็นเป้าหมายของ social engineering ต้องมี proofing ที่เหมาะกับ risk, script ที่ตรวจสอบได้, escalation และ log ไม่ใช้ “รู้ข้อมูลส่วนตัวหลายข้อ” เป็นหลักฐานแข็งแรงโดยอัตโนมัติ การเร่งคืน บริการต้องไม่ทำลาย identity assurance

4.5 ใช้กรอบร่วมกันอย่างไร

ใช้ NIST อธิบาย digital identity, assurance และ technical guidance ใช้ ISO/IEC 27001 จัด IAM ให้อยู่ใน risk-based ISMS ใช้ COBIT กำหนด governance objective และ decision rights และใช้ ITIL ฝัง provisioning, support, change, incident และ recovery ใน service management กรอบเหล่านี้เสริมกัน ไม่ใช่ certification หนึ่งแทนอีกกรอบหนึ่ง

ลำดับที่รักษาความสอดคล้องกับบทก่อนหน้าคือ requirement → architecture → control → evidence → residual risk ตัวอย่าง: Data owner กำหนดว่า financial approval ต้องมี SoD; architect เลือก RBAC กับ dynamic constraint; IAM และ application บังคับ policy; Domain 6 ทดสอบ toxic combination และ transaction; Risk owner ตัดสิน exception ที่ ยังเหลือ

5. คำศัพท์สำคัญพร้อมนิยาม

คำศัพท์	นิยามสั้น
Identity	ชุด identifier และ attribute ที่แทน subject ในบริบทหนึ่ง
Account	record ที่ระบบใช้ผูก identity, credential, state และ entitlement
Entitlement	สิทธิหรือความสามารถที่อนุญาตให้ subject ใช้ resource หรือ action
Identification	การที่ subject อ้าง identity หรือ identifier
Identity proofing	การสร้างความเชื่อมั่นว่า identity เชื่อมกับบุคคล/entity ที่อ้าง
Authentication (AuthN)	การพิสูจน์ว่า claimant ควบคุม authenticator ที่ผูกกับ identity
Authorization (AuthZ)	การตัดสินว่า subject ทำ action ใดกับ object ได้
Accounting	การบันทึกกิจกรรมและการใช้ resource เพื่อการติดตาม
Accountability	ความสามารถผูก action กับ subject/authority และให้รับผิดรับชอบต่อผล
Authenticator	สิ่งหรือ secret ที่ claimant ควบคุมและใช้ใน authentication protocol
Credential	ข้อมูลหรือโครงสร้างที่ผูก identity กับ authenticator หรือ attribute
MFA	authentication ที่ใช้ factor ต่างประเภทอย่างน้อยสองประเภท
SSO	การ authenticate ครั้งเดียวแล้วเข้าหลาย application ใน session/trust ที่กำหนด
Federation	trust arrangement ที่ RP ยอมรับ assertion/token จาก IdP ต่าง domain
IdP	ระบบหรือบทบาทที่ authenticate subject และออก assertion หรือ identity token
Relying Party (RP)	ระบบที่พึ่งพาผล authentication หรือ assertion จากผู้ให้บริการ identity
Assertion	ข้อความที่ IdP ส่งเกี่ยวกับ authentication event หรือ subject attribute
Least privilege	ให้สิทธิขั้นต่ำที่จำเป็นในช่วงเวลาที่ต้องใช้
Need-to-know	ให้เข้าถึงข้อมูลเมื่อมีเหตุผลทางงานที่จำเป็น
Separation of Duties (SoD)	แยกหน้าที่ขัดกันเพื่อลด fraud และ error
DAC	owner ของ object มี discretion ในการมอบสิทธิภายใต้ระบบ
MAC	authority กลางบังคับ policy ด้วย label/clearance ที่ user เปลี่ยนเองไม่ได้
RBAC	มอบ permission ให้ role แล้ว assign subject เข้า role ตามหน้าที่
Rule-based access control	ตัดสิน access ด้วย system-wide rules และเงื่อนไข
ABAC	ตัดสินด้วย attribute ของ subject, object, action และ environment เทียบ policy
PDP	จุดที่ประเมิน policy และให้ผล authorization decision
PEP	จุดที่ intercept request และบังคับ authorization decision
Privilege creep	การสะสมสิทธิเกินความจำเป็นเมื่อหน้าที่เปลี่ยนไป
Access review	การที่ owner ตรวจและ recertify ว่าสิทธิยังจำเป็นและเหมาะสม
Orphaned account	account ที่ไม่มี owner หรือไม่ผูกกับ active identity ที่ตรวจสอบได้
Dormant account	account ที่ไม่มีการใช้งานนานตามเกณฑ์องค์กร
PAM	governance, process และ technology สำหรับควบคุม privileged access
JIT access	ให้ privilege เฉพาะเวลาที่อนุมัติและถอนเมื่อหมดช่วง
JEA	จำกัด privilege ให้เหลือเฉพาะคำสั่งหรือ resource ที่จำเป็น
Break-glass account	identity ฉุกเฉินสำหรับใช้เมื่อ normal access path ใช้ไม่ได้
Service account	non-human account ที่ process หรือ service ใช้ทำงาน
Session	สถานะต่อเนื่องหลัง authentication ที่ผูก request กับ subject/context
Provisioning	การสร้างหรือปรับ identity, account, credential และ entitlement
Deprovisioning	การถอน/ปิด account, credential, session และ entitlement เมื่อไม่จำเป็น

6. Exam Tips: จุดที่ข้อสอบชอบหลอก

1. Identification คือการอ้าง; authentication คือการพิสูจน์ Username ไม่ใช่ secret
2. AuthN ไม่เท่ากับ AuthZ Login สำเร็จไม่ได้แปลว่าอ่านทุก object ได้
3. Accounting ไม่เท่ากับ accountability Shared account และ log อ่อนทำให้ attribution ต่ำ
4. สอง password ไม่ใช่ MFA ต้องใช้ factor คนละประเภท
5. Passwordless ไม่ได้แปลว่า MFA เสมอ ตรวจ authenticator และ protocol
6. Biometric ไม่ควรถือเป็น secret ที่เปลี่ยนง่าย ต้องป้องกัน template และมี fallback
7. FAR ต่ำกับ FRR ต่ำเป็น trade-off Threshold ที่เข้มขึ้นอาจปฏิเสธผู้ใช้จริงมากขึ้น
8. Least privilege ไม่เท่ากับ need-to-know หนึ่งคำเน้นสิทธิขั้นต่ำ อีกคำเน้นเหตุผลเข้าถึงข้อมูล
9. SoD ป้องกัน conflict; least privilege ลดขอบเขต ใช้ร่วมกันแต่แก้คนละปัญหา
10. RBAC ไม่ใช่ rule-based access control Role ผูกหน้าที่; rule ผูกเงื่อนไข
11. MAC มีสองความหมายตามบริบท ในบทนี้มักเป็น Mandatory Access Control; Domain 3 อาจหมายถึง Message Authentication Code
12. DAC ยืดหยุ่นแต่ owner อาจกระจายสิทธิ ไม่เหมาะกับทุก policy ที่ต้องบังคับกลาง
13. ABAC dynamic แต่พึ่ง attribute quality Attribute เก่าทำให้ policy ตัดสินผิด
14. SSO ไม่เท่ากับ federation SSO กล่าวถึงประสบการณ์ login; federation กล่าวถึง trust ข้าม domain
15. OAuth 2.0 ไม่ใช่ authentication protocol โดยตัวมันเอง OIDC เพิ่ม identity layer
16. SCIM ใช้ provisioning ไม่ใช่ SSO อย่าสลับกับ SAML/OIDC
17. Federation ไม่โอน authorization accountability ไป IdP RP ยังปกป้อง resource ของตน
18. MFA ไม่แก้ session theft ทั้งหมด ต้องป้องกันและ revoke session/token
19. Certificate ไม่พอถ้าไม่ validate chain/context และ private key compromise ยังสำคัญ
20. Network admission ไม่เท่ากับ application access 802.1X, NAC หรือ VPN ไม่ให้ entitlement อัตโนมัติ
21. Mover ต้องทั้ง grant และ revoke การเพิ่มอย่างเดียวทำให้ privilege creep
22. Disable กับ delete ไม่เหมือนกัน Disable หยุดใช้; deletion ต้องคำนึง evidence/retention
23. PAM ไม่ใช่แค่ password vault ต้องมี approval, JIT/JEA, monitoring, review และ recovery
24. Shared admin account ทำลาย accountability หาก legacy บังคับให้ใช้ ต้องมี broker และ compensating controls
25. Break-glass ต้อง monitor และทดสอบ การ exempt ทุก control ทำให้เป็น backdoor
26. Service account ต้องมี owner และ lifecycle “ระบบใช้” ไม่ใช่เหตุผลให้ secret ไม่มีวันหมดอายุ
27. ถ้าโจทย์ถาม FIRST ให้ยืนยัน requirement และ owner อย่า provision ก่อน approval
28. ถ้าโจทย์ถาม BEST ให้มอง lifecycle Identity control ต้อง provision, review, revoke, monitor และ recover ได้

7. Cross-reference ไป Domain อื่น

• Domain 1: Security and Risk Management — ใช้ governance, policy, personnel security, supplier agreement, risk appetite และ accountability กำหนด identity authority, approval, SoD และ residual risk
• Domain 2: Asset Security — Data owner, classification และ handling requirement กำหนด need-to-know, entitlement, access review และ log/identity data retention
• Domain 3: Security Architecture and Engineering — Trust boundary, reference monitor, cryptography, PKI, password hashing, Zero Trust และ fail securely เป็นฐาน ของ authenticator, PDP/PEP และ identity plane design
• Domain 4: Communication and Network Security — 802.1X, EAP, RADIUS, NAC, VPN, mTLS, certificate, management plane และ workload communication ต้องใช้ identity โดยไม่ถือว่า network location สร้าง trust
• Domain 6: Security Assessment and Testing — ทดสอบ provisioning/deprovisioning, access review, SoD, authorization bypass, MFA, federation claim, PAM session, orphaned account และ evidence ว่า control ทำงานจริง
• Domain 7: Security Operations — ดำเนิน account administration, log monitoring, User and Entity Behavior Analytics (UEBA), incident revocation, credential rotation, privileged operation, recovery และ physical access ในงานประจำ
• Domain 8: Software Development Security — ออกแบบ application/API AuthN/AuthZ, session, OAuth/OIDC validation, secret management, CI/CD identity, service account และ object-level authorization ตลอด Software Development Life Cycle (SDLC)

IAM ที่มีคุณภาพจึงไม่จบเมื่อ user login สำเร็จ แต่ต้องพิสูจน์ได้ว่า identity มีที่มา น่าเชื่อถือ, authenticator เหมาะกับ risk, policy ให้สิทธิเท่าที่จำเป็น, ทุก enforcement path ตัดสินสอดคล้องกัน, privileged action ตรวจสอบย้อนหลังได้ และ access ถูกถอนทันที เมื่อ business relationship หรือ risk เปลี่ยน พร้อมส่ง residual risk ให้ผู้มี authority ตัดสินใจ