ปัญหาหลัก: กุญแจสะสม#

ลองนึก scenario ที่ทำ access review ครั้งแรกในบริษัทใหญ่ — มักเจอพนักงานคนแบบนี้:

• เข้า ERP ในฐานะ accounting clerk (ตำแหน่งปัจจุบัน)
• เข้า HR system ในฐานะ HR officer (ตำแหน่งเก่าเมื่อ 2 ปีก่อน)
• เข้า inventory system ในฐานะ warehouse supervisor (ตำแหน่งเก่ากว่า เมื่อ 4 ปีก่อน)
• เข้า admin console ของ email server (ตำแหน่งช่วยทดลองช่วงโควิด)

พนักงานคนนี้ไม่ใช่คนไม่ดีนะครับ เธอแค่ทำงานในบริษัทมานาน ทุกครั้งที่ย้ายแผนก ฝ่าย IT ให้สิทธิ์ใหม่ แต่ไม่เคยเพิกถอนสิทธิ์เก่า

นี่แหละ privilege creep ปัญหาที่พบบ่อยที่สุดในการตรวจ IAM และเป็นเหตุผลที่ต้องมี IAM lifecycle

IAM Lifecycle 5 ขั้นตอน#

1
Enrollment → Role Determination → Provisioning → Review/Update → Deprovisioning

Enrollment — รับคนเข้าระบบครั้งแรก ตรวจตัวตน ออก credentials เริ่มต้น

Role Determination — กำหนดบทบาท คนนี้ทำหน้าที่อะไร เข้าระบบไหนได้บ้าง สิทธิ์ระดับไหน

Provisioning — ออกสิทธิ์จริงในระบบ — สร้าง user, ให้ permissions, แจกอุปกรณ์

Review/Update — ตรวจซ้ำเป็นระยะว่าสิทธิ์ที่มีอยู่ยังเหมาะกับบทบาทปัจจุบันไหม

• พนักงานทั่วไป — ทุก 6 เดือน
• Privileged accounts (admin) — ทุก 3 เดือน

Deprovisioning — เพิกถอนสิทธิ์เมื่อพนักงานออก ย้ายแผนก หรือเปลี่ยนบทบาท

ถ้าครบ 5 ขั้น = lifecycle ทำงาน ถ้าขาดขั้นไหน = privilege creep หรือ orphan account

Trap คลาสสิก: เร่งด่วนแค่ไหน?#

ข้อสอบมักถามว่า “พนักงานถูกเลิกจ้าง — IAM action ที่ urgent ที่สุด?”

หลอก: แจ้ง HR จริง: เพิกถอน access ทุกอย่างทันที (ทั้ง logical และ physical)

หลักคือ ระยะเวลาระหว่างที่พนักงานรู้ว่าตัวเองถูกเลิก กับเวลาที่ access ถูกเพิกถอน คือ window of unauthorized access หน้าต่างที่อันตรายที่สุด

บางบริษัทจริงจังขนาดเพิกถอน access ก่อนเรียกพนักงานเข้ามาฟังคำเลิกจ้างเลย

Auditor มอง IAM Lifecycle ยังไง#

• มี automated deprovisioning process ไหม (ผูกกับ HR system)
• Access review ทำตามรอบที่กำหนดไหม
• มี evidence ของการ review หรือเป็นแค่ rubber stamp
• Orphan accounts (user ที่ไม่มีเจ้าของแล้ว) มีกี่ตัว และจัดการยังไง

Authentication — พิสูจน์ตัวตน#

3 factors คลาสสิก:

• Something you know — รหัสผ่าน, PIN
• Something you have — token, smart card, มือถือที่รับ OTP
• Something you are — biometric (ลายนิ้วมือ, ใบหน้า, ม่านตา)

MFA (Multi-Factor Authentication) = ใช้ 2 factors ขึ้นไปจาก คนละกลุ่ม ไม่ใช่ password 2 อัน

หลักสำคัญคือ password อย่างเดียวเป็นวิธี authenticate ที่อ่อนที่สุด เพราะ password ถูกขโมยได้ทุกวิธีเลย (phishing, keylogger, brute force, leaked database)

Directory Services — ฐานข้อมูลของ identity#

ก่อน SSO + Federation ต้องเข้าใจ infrastructure ที่อยู่ข้างใต้ก่อน — directory service = ฐานข้อมูลที่เก็บ identity ขององค์กร

SSO — สะดวกแลกความเสี่ยง#

Single Sign-On (SSO) = login ครั้งเดียว เข้าได้หลายระบบ

ข้อดี: สะดวก ลด password fatigue (พนักงานไม่ต้องจำ 20 password) จัดการ IAM ง่าย

ข้อเสียที่ออกข้อสอบบ่อยคือ single point of failure ถ้า credentials ของ SSO หลุด = เข้าได้ทุกระบบ ไม่ใช่แค่ระบบเดียว

ทางแก้: SSO + MFA = บังคับเสมอ

Federation — SSO ข้ามองค์กร / ข้ามระบบ#

Federation = SSO ที่ขยายข้าม trust boundaries — login ที่บริษัท A ใช้ใน SaaS ของบริษัท B ได้

ตัวอย่าง: login ด้วย corporate credential เข้า Salesforce, ServiceNow, Slack ทั้งหมดที่ใช้ federation protocol

Federation Trap Patterns#

Authorization — ทำอะไรได้บ้าง#

หลังจาก authenticated แล้ว — สิทธิ์ที่จะทำอะไรในระบบ

ระดับของ access:

• Read — อ่านได้
• Write — เขียน/แก้ไขได้
• Execute — รันโปรแกรมได้
• Combinations — เช่น read + write แต่ไม่มี delete

หลัก Least Privilege (POLP) — ให้สิทธิ์ขั้นต่ำที่จำเป็นสำหรับงาน ไม่ให้เกิน

หลัก Need-to-know — สิทธิ์ขึ้นกับงานที่ทำ ไม่ใช่ตำแหน่ง

Accountability — ใครทำอะไรเมื่อไหร่#

ส่วนสุดท้ายที่หลายระบบลืมคือ logging ทุก action เพื่อให้ trace ย้อนได้

โดยเฉพาะ admin actions ต้อง log อย่างเข้มงวด เพราะ admin มีสิทธิ์ bypass control ส่วนใหญ่ ถ้า admin ทำผิดและไม่มี log แล้วใครจะรู้?

จะลงรายละเอียดเรื่อง logging ใน Section 5.13 (ตอน 51)

ทำไม “อยู่ในบ้านแล้วไว้วางใจได้” ใช้ไม่ได้แล้ว#

โมเดลเก่า — Network perimeter security

• มี firewall ใหญ่กั้นข้างนอก
• คนที่อยู่ข้างใน network = “trusted”
• ถ้าผ่าน firewall เข้ามาได้ เดินไปได้ทุกห้องในบ้าน

ปัญหา:

• ถ้าโจรเข้ามาได้แม้แค่จุดเดียว = เข้าทุกห้องได้
• พนักงาน Work from Home — อยู่ “นอก” perimeter ตลอดเวลา
• Cloud + SaaS — ข้อมูลไม่ได้อยู่ใน perimeter ของบริษัทอีกแล้ว
• BYOD — อุปกรณ์ส่วนตัวไม่ได้อยู่ใต้ control ของบริษัท

โควิด-19 ทำให้ทุกคนเห็นชัดเลยว่า perimeter security ตายไปแล้ว

ZTA — “ปิดบ้านทุกห้อง ไม่ใช่แค่ประตูหน้า”#

Zero Trust Architecture = “Never Trust, Always Verify”

หลักการ:

• ไม่มีใคร trusted แค่เพราะอยู่ใน network — ทุกคนต้องพิสูจน์ตัวเองทุกครั้ง
• Access ให้เป็น per-session ไม่ใช่ permanent
• ใช้ policy-based access control (PBAC) ที่พิจารณา context (อุปกรณ์, location, เวลา, behavior)
• Continuous monitoring — ดูตลอดว่า session ที่ active อยู่ ยังควรจะ active ไหม
• Identity-based (ไม่ใช่ network-location-based)

ตัวอย่างจริง: พนักงานเข้า ERP จากออฟฟิศบนคอม corporate ในเวลางาน access ปกติ พนักงานคนเดียวกันเข้า ERP จากต่างประเทศบนอุปกรณ์ใหม่ตี 3 ZTA จะถาม MFA เพิ่ม หรือไม่ก็ block ก่อน

องค์ประกอบ ZTA#

• MFA บังคับ ทุก session
• Centralized identity management
• POLP enforcement อัตโนมัติ
• Session-based trust (ไม่ใช่ network-based)
• Continuous verification

ข้อสอบ trap: “ZTA หมายความว่าอะไรสำหรับ internal users?”

หลอก: internal users ยัง trusted โดยไม่ต้อง re-authenticate จริง: ทุกคน รวม internal users ต้อง authenticate ทุก session ไม่ว่าอยู่ที่ไหน

PAM — กุญแจมาสเตอร์ใน vault#

Privileged Access Management (PAM) = ระบบจัดการบัญชี admin โดยเฉพาะ

ทำไมต้องมี PAM แยก? เพราะ admin accounts:

• มีอำนาจมหาศาล (สร้าง/ลบ user, เปลี่ยน config, อ่านข้อมูลทั้งหมด)
• ถ้าโดนขโมยก็เสียหายมหาศาลตาม
• มักเป็น shared accounts (root, admin) ทำให้ accountability ขาดหาย

ประเภทของ privileged accounts:

• Administrative accounts — admin ปกติ
• Emergency / Break-glass accounts — ใช้ในกรณีฉุกเฉินเมื่อบัญชี admin ปกติใช้ไม่ได้ ทุกการใช้ต้องบันทึกและ review
• Service accounts — บัญชีที่ application ใช้คุยกัน
• Application accounts — สำหรับ app ที่ต้องเข้า database
• SSH keys / Root access — สำหรับ Linux/Unix systems

PAM solutions ที่ดีจะมี:

• Password vaulting — เก็บ password ไว้ที่ส่วนกลาง ผู้ใช้ไม่เห็นจริง
• Session recording — บันทึกหน้าจอตอน admin ทำงาน
• Just-in-time access — ให้สิทธิ์เฉพาะตอนที่ต้องใช้ หมดเวลาก็ revoke
• Credential rotation — เปลี่ยน password อัตโนมัติทุก X ชั่วโมง/วัน

ข้อสอบ trap: “Break-glass account ใช้เมื่อไหร่?”

หลอก: ใช้ทำงาน admin ประจำวัน จริง: ใช้ในกรณีฉุกเฉินเมื่อบัญชี admin ปกติเข้าไม่ได้ และทุกการใช้ต้อง audit ทันที

มุมผู้บริหาร: PAM = ROI ที่พิสูจน์ได้#

ถ้าผู้บริหารถามว่าทำไมต้องลงทุน PAM คำตอบคือ insider threat report ของ Verizon และ Ponemon ทุกปีแสดงตรงกันว่า credential compromise + privilege misuse เป็นหนึ่งใน top cause ที่ปรากฏซ้ำทุกปี ของ major data breach

ค่า license PAM แพง แต่ก็ยังถูกกว่า cost ของ breach แค่ครั้งเดียว

Access Control Models#

CISA exam ชอบถามให้แยก 5 แบบนี้ออกจากกัน:

MAC — Mandatory Access Control

• Admin (system) เป็นคนกำหนด — user ไม่มีสิทธิ์เปลี่ยน
• ใช้ในระบบที่ classification สำคัญ — กระทรวงกลาโหม, intelligence

DAC — Discretionary Access Control

• เจ้าของข้อมูลเป็นคนกำหนด — owner share ให้ใครก็ได้
• ใช้ใน file system ทั่วไป — Windows, Unix file permissions
• เสี่ยง: owner อาจ share ผิด

RBAC — Role-Based Access Control

• สิทธิ์ผูกกับ role ไม่ใช่กับ user — assign role ให้ user แล้วได้สิทธิ์ตาม role
• ใช้ในองค์กรขนาดกลาง-ใหญ่ทั่วไป
• ข้อดี: จัดการง่าย ขยายได้
• ข้อเสีย: role explosion (role เยอะเกินจัดการไม่ไหว)

Rule-Based Access Control

• สิทธิ์ผูกกับ rule (if-then logic)
• เช่น “ถ้า IP อยู่ในเครือข่ายบริษัท → access ได้, ถ้านอก → block”

ABAC — Attribute-Based Access Control

• สิทธิ์ขึ้นกับ attributes ของ user, resource, environment
• Flexible สุด — รองรับเงื่อนไขซับซ้อน
• เช่น “ผู้จัดการ + แผนกการเงิน + จากออฟฟิศ + ในเวลางาน → อนุญาต”

PBAC — Policy-Based Access Control

• คล้าย ABAC แต่ enforce ผ่าน policy engine ส่วนกลาง
• เป็นทิศของ ZTA

ข้อสอบมักถามให้แยก RBAC vs ABAC: RBAC ผูกกับ role, ABAC ผูกกับ attributes (ที่อาจรวม role + อื่นๆ ด้วย)

IGA — Identity Governance and Administration#

IGA = IAM + governance + compliance

ขยายจาก IAM ปกติด้วย:

• Access certification — บังคับให้ manager review สิทธิ์ของลูกน้องเป็นระยะ
• SoD enforcement — ตรวจอัตโนมัติว่ามี role conflict ไหม (เช่น approver + requester ในคนเดียว)
• Audit reporting — ออก report สำหรับ compliance (SOX, PDPA)
• Workflow ของ access request — ขอ-อนุมัติ-เพิกถอน ผ่านระบบเดียว

IGA โดยทั่วไปเหมาะสำหรับองค์กรขนาดใหญ่ที่มี user หลายพันคนและ regulatory requirements

IDaaS — IAM ที่ส่งเป็น service#

Identity as a Service (IDaaS) = IAM ที่เช่าใช้บน cloud (เช่น Okta, Microsoft Entra ID, Auth0)

ข้อดี:

• ไม่ต้อง deploy on-premise
• ขยายง่าย
• รองรับ SaaS ได้ตั้งแต่แรก
• มี SSO + MFA built-in

ความเสี่ยงที่ auditor ต้องดู:

• Vendor dependency — IDaaS provider ล่ม = ทุกระบบเข้าไม่ได้
• Data residency — identity data เก็บที่ประเทศไหน (PDPA implication)
• Right to audit — provider ให้ตรวจได้แค่ไหน
• SOC 2 Type II report — ต้องมีและ review ก่อน adopt

Logical Access Layers — ป้องกันเป็นชั้น#

CRM ย้ำหลัก defense in depth ใน access control — มี 4 ชั้น:

1
Layer 1: Network access (ใช้ network ขององค์กรได้ไหม)
2
       ↓
3
Layer 2: Platform access (เข้าระบบ OS / server ได้ไหม)
4
       ↓
5
Layer 3: Database access (อ่าน database ได้ไหม)
6
       ↓
7
Layer 4: Application access (ใช้ feature ใน app ได้ไหม)

ทุกชั้นควรมี control แยก — ผ่าน network ไม่ได้แปลว่าผ่าน database ผ่าน database ไม่ได้แปลว่าผ่าน application

หลายองค์กรพลาดตรงนี้ Network firewall เข้มงวด แต่ database access เปิดให้ทุกคนใน network เข้าได้หมด ถ้าผู้ไม่หวังดีเข้า network ได้ = เข้า database ได้ทันที

DRM — เมื่อ access control ไม่พอ#

Digital Rights Management (DRM) = ควบคุมว่าทำอะไรกับเอกสารได้บ้าง หลังจากเข้าถึงแล้ว

ตัวอย่าง:

• เอกสารเปิดอ่านได้ แต่ copy ไม่ได้
• เอกสาร print ได้แค่ 3 ครั้ง
• เอกสาร expire หลัง 30 วัน
• เอกสารเปิดได้เฉพาะใน network บริษัท

DRM สำคัญสำหรับ:

• IP-heavy companies (ผลิตเอกสาร confidential เยอะ)
• Legal documents
• M&A documents
• Source code