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

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

• เข้า 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 / ล็อกอินครั้งเดียวใช้ได้ทุก system) = 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 / Principle of Least Privilege) — ให้สิทธิ์ขั้นต่ำที่จำเป็นสำหรับงาน ไม่ให้เกิน

หลัก 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 / Policy-Based Access Control) ที่พิจารณา 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 (JIT) — ให้สิทธิ์เฉพาะตอนที่ต้องใช้ หมดเวลาก็ 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 (คุม access แบบบังคับ — military model)

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

DAC — Discretionary Access Control (เจ้าของกำหนด access เอง)

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

RBAC — Role-Based Access Control (คุม access ตาม role)

• สิทธิ์ผูกกับ 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 (คุม access ตาม attribute)

• สิทธิ์ขึ้นกับ 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 (Separation of Duties) 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 ได้ทันที

Information Security กับ External Parties — 20 รายการต้องมีในสัญญา#

หลายองค์กรลืมว่า 3rd party (vendor / contractor / partner) ที่ต้องเข้าระบบเรา คือช่องโหว่ที่ใหญ่ที่สุดของ IAM เลย เซ็นสัญญาเสร็จก็ปล่อยเลย ไม่มี control อะไรเลย พอเกิดเรื่องก็ไปไล่ไม่ได้

ลองนึกภาพ scenario คลาสสิคของวงการ บริษัทจ้าง outsource ทำ payroll ส่งไฟล์เงินเดือนผ่าน FTP plain ทุกเดือน วันหนึ่ง outsource โดน ransomware ข้อมูลเงินเดือนพนักงานทั้งบริษัทรั่ว ฟ้องไม่ได้เพราะ contract ไม่ได้พูดเรื่อง security เลย

จุดสำคัญในมุม auditor คือก่อนเซ็นสัญญากับ 3rd party ที่ต้อง access ระบบ ลองดู 20 รายการที่ contract ควรครอบคลุมครับ:

1. Compliance with org’s policy — partner ต้องปฏิบัติตาม security policy ของบริษัทเรา ไม่ใช่ใช้ของเขาเอง
2. Asset protection — ระบุชัดว่า partner เข้าถึง asset ตัวไหนได้บ้าง (whitelist ไม่ใช่ blacklist)
3. Confidentiality / NDA — Non-Disclosure Agreement ต้องเซ็นก่อน access ครั้งแรก
4. Information classification handling — partner ต้องรู้ data classification และปฏิบัติตามมาตรฐานของแต่ละชั้น
5. Personnel screening — staff ของ partner ที่จะ access ต้องผ่าน background check
6. Security training — partner staff ต้องผ่าน security awareness training ก่อน access
7. Change management — partner ต้อง notify บริษัทเราก่อน change ที่อาจกระทบ service
8. Access control policy — partner ต้อง enforce access control ในมาตรฐานเดียวกับเรา
9. Acceptable Use — partner ห้ามใช้ระบบนอกขอบเขตที่ตกลง (no side-project, no personal use)
10. SLA + monitoring — กำหนด performance KPI + security KPI ที่วัดได้
11. Right to audit — บริษัทเรามีสิทธิ์เข้าตรวจ partner ได้ (ระบุ frequency + notice period)
12. Incident reporting — partner ต้องแจ้ง incident ภายใน X ชั่วโมง (ปกติ 24-72 ชม)
13. Escalation procedure — กำหนด escalation path เมื่อเกิด incident (ใครคุยกับใคร)
14. IP rights — ระบุชัดว่า data / code / output ที่เกิดจาก engagement เป็นของใคร
15. Subcontractor disclosure — partner ต้องเปิดเผย 3rd-tier party ที่ใช้ต่อ (และต้องขออนุญาตก่อน)
16. Termination procedure — เมื่อจบสัญญา return + destroy data, revoke access ทั้งหมด
17. Liability + indemnification — กำหนดความรับผิดชอบและการชดใช้ค่าเสียหายเมื่อเกิดเรื่อง
18. Insurance — partner ต้องมี cyber insurance + Errors & Omissions (E&O) cover ที่เหมาะสม
19. Compliance with laws — ระบุกฎหมายที่ใช้ (GDPR / PDPA / HIPAA / SOX ตามขอบเขต)
20. Exit clause + data portability — เมื่อย้าย vendor ต้อง extract data ได้ + transition assistance

ในมุม auditor ตอนเปิดสัญญา 3rd party ลองเช็คว่าครบ 9 หมวดนี้ไหม ถ้าขาดหมวดไหน คือ gap ที่ต้อง flag ทันที โดยเฉพาะหมวด Oversight (11, 15) และ Exit (16, 20) ที่บริษัทไทยตกบ่อยที่สุด

มุมผู้บริหาร: สัญญา 3rd party ที่ไม่มี 20 ข้อนี้ = บริษัทรับ risk ของ partner เข้ามาเองทั้งหมด ถ้า partner ทำพัง บริษัทเราจะต้องตอบทั้ง regulator, customer, board เอง โดยที่เรียกอะไร partner กลับไม่ได้

Auditor 5-Step Approach สำหรับ Logical Access#

CRM ระบุ 5 ขั้นตอนมาตรฐานที่ IS auditor ใช้ตรวจ logical access เป็น sequence ที่ตามกันลำดับ ไม่ใช่เลือกทำเป็นข้อๆ ขั้นก่อนหน้าเป็น input ของขั้นถัดไป

Step 1: Obtain general understanding เข้าใจภาพรวมก่อน

• Interview key personnel — CISO, IAM admin, application owner, business unit head
• Review IAM policy + standards + procedure ที่บริษัทมี
• เข้าใจ business context — บริษัททำอะไร, ข้อมูลสำคัญอยู่ที่ไหน, ใครเข้าถึงอะไร

Step 2: Document + evaluate controls วาดภาพและประเมิน control design

• Diagram access flow — user → authenticator → application → data
• ลิสต์ IAM tools ที่ใช้ — IDP (Identity Provider), PAM, IGA, MFA solution
• ประเมิน control design — ออกแบบมารองรับ risk ที่ระบุไหม

Step 3: Test controls ทดสอบจริงว่า control ทำงานตามที่ออกแบบ

• Sample-test user access review — เลือกตัวอย่างมาตรวจว่ามี evidence จริงไหม หรือเป็นแค่ rubber stamp
• ทดสอบ provisioning / deprovisioning — ลองสร้าง user ใหม่ + ลอง terminate ดูว่า access ถูกตัดจริงไหม
• Validate SoD matrix — มี role conflict จริงไหม (เช่น approver + requester ในคนเดียว)

Step 4: Evaluate access control environment มอง access จากมุม external + internal

• ทดสอบ access จาก external network — VPN, web portal, mobile app
• ทดสอบ access จาก internal network — workstation, server, network device
• Validate MFA enforcement — บังคับจริงไหม หรือมี bypass exception เยอะ
• Check privileged account inventory — list ของ admin / service / break-glass account ครบไหม

Step 5: Evaluate security environment มอง logging + response readiness

• Review audit log integrity — log ถูก tamper ได้ไหม, retention พอไหม
• ตรวจ log forwarding ไปยัง SIEM — ครบ source ไหม, real-time ไหม
• Incident response readiness สำหรับ IAM event — มี playbook ไหม, ใครรับ alert

กับดักของข้อสอบ: ขั้นไหนสำคัญสุด? ไม่มีขั้นไหนเป็นพิเศษ มันเป็น sequence ที่ต้องครบ ขั้น 1 ทำไม่ดี ขั้น 2-5 ทำไปก็ไม่มี baseline เปรียบเทียบ ขั้น 5 ทำไม่ดี ทุก control ก่อนหน้าก็ไม่มี accountability backup

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

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

ลองคิดง่ายๆ ครับ — เพลงที่ผมซื้อจาก iTunes สมัยปี 2008 ตอนนี้ยังเปิดได้ไหม? ถ้า activation server ของ Apple ยัง online อยู่ก็เปิดได้ ถ้าวันใด Apple ปิด server นั้น (เคยเกิดมาแล้วกับเพลง MSN Music ของ Microsoft ปี 2011) เพลงที่จ่ายเงินซื้อไปก็จะ “ตาย” เปิดไม่ได้อีก นี่คือลักษณะ tethered ของ DRM — สิทธิ์อยู่ในมือผู้ขาย ไม่ใช่ผู้ซื้อ

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

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

CRM พูดถึง DRM ในสามมุม — implement ที่ไหน, restrict อะไรได้บ้าง, ใช้ technology อะไร

DRM Implement ได้ที่ไหนบ้าง (CRM list)

• Copyrighted content (เพลง รูป OTT media)
• Software application
• Confidential document (bank statement, financial report)
• Intellectual property (patent, trade secret, policy plan)
• Government documentation
• Literature (online library, e-book reader)

6 DRM Restrictions ที่ CRM ระบุ (Figure 5.14)

9 DRM Technologies ที่ CRM ระบุ

ผมจัดกลุ่มให้จำง่าย — กลุ่ม identity, กลุ่ม content, กลุ่ม protocol

6 DRM Best Practices ที่ CRM แนะนำ

1. Perform DRM content inventory — รู้ก่อนว่ามี content อะไรที่ต้อง rights-managed
2. Adopt a risk-based approach — ไม่ใช่ทุก content ต้อง DRM (กัน DRM ที่เข้มจนผู้ใช้ใช้งานไม่ได้)
3. Continuously monitor DRM — กฎหมายและ technology เปลี่ยนเร็ว ต้องตามให้ทัน
4. Integrate with other tools — DRM ทำงานได้ดีตอน integrate กับ ECM (Enterprise Content Management) และ DAM (Digital Asset Management)
5. Minimize Shadow IT — device ที่ไม่ manage = leak ที่ DRM กันไม่ได้
6. Automate the DRM process — manual ไม่ scale

Trap ของ DRM