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

ผมเคยเจอบริษัทที่ทำการตรวจ 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)

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

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

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

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

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

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 ทุกปีแสดงว่า privileged credential abuse เป็น 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