IDOR (Insecure Direct Object Reference) — บั๊กที่ครองอันดับ 1 ของ OWASP Top 10#

IDOR = บั๊กที่ system ตรวจแค่ AuthN — ไม่ตรวจ AuthZ ตอนคน access ข้อมูล

ตัวอย่างที่หลายคนเคยเจอครับ. ลองนึกเว็บไหนสักเว็บที่คุณเข้าดูใบเสร็จของตัวเอง — URL หน้านี้น่าจะหน้าตาประมาณ:

1
https://shop.example.com/invoice/12345

12345 = เลขใบเสร็จของคุณ. ทีนี้ — ลองเปลี่ยน URL เป็น:

1
https://shop.example.com/invoice/12346

แล้วระบบ — ก็โชว์ใบเสร็จของคนอื่นให้คุณดู — เห็นชื่อ — เห็นที่อยู่ — เห็นเลขบัตรเครดิต (4 ตัวท้าย) — เห็นรายการสินค้า

นี่คือ IDOR. ระบบรู้ว่า “คุณคือสมชาย” (AuthN ผ่าน) — แต่ไม่ได้ตรวจว่า “ใบเสร็จเลข 12346 เป็นของสมชายหรือเปล่า” (AuthZ ไม่ทำ). developer คิดเอาเองว่า — ถ้าคุณ login แล้ว = คุณคงจะเห็นใบเสร็จของตัวเองเท่านั้น. ผิด. คุณเปลี่ยน URL ได้ตามใจ

นี่คือเหตุผลที่ OWASP Top 10 ปี 2021 จัด Broken Access Control ขึ้นเป็น อันดับ 1 ของ vulnerability ใน web application — แซง SQL Injection ที่ครองอันดับ 1 มาเป็น 10 กว่าปี. ในรายงาน OWASP ปี 2021 — 94% ของ application ที่ทดสอบ เจอ Broken Access Control อย่างน้อย 1 จุด

มุมผู้บริหาร: ถ้าบริษัทคุณมี web application ที่จัดการข้อมูลลูกค้า / ข้อมูลภายใน — ขอ pen test ที่ enumerate Broken Access Control เป็นพิเศษ. อย่ายอมรับรายงาน pen test ที่บอกว่า “ผ่าน” โดยที่ไม่มี section ทดสอบ IDOR + AuthZ logic — เพราะ scanner อัตโนมัติส่วนใหญ่จับ IDOR ไม่ได้ (มันต้องเทสด้วย logic ของคน). pattern ของวงการคือ — บริษัทคิดว่า “เรามี login = ปลอดภัย” → 2 ปีต่อมาเจอข้อมูลลูกค้าหลุดเพราะ IDOR

กับดักคลาสสิคของ SaaS เริ่มต้น — “Login ผ่าน = เข้าได้ทุกอย่าง”#

นี่คือ pattern ที่บริษัท SaaS เริ่มต้นตกบ่อยที่สุดครับ. ตอน MVP เพิ่งสร้าง — developer คิดว่า — “ขอแค่มี login ก่อน. AuthZ เอาไว้ทำทีหลัง”. MVP ออก market — ลูกค้าเพิ่ม — ทีม dev เพิ่ม feature ใหม่เรื่อยๆ — ลืมกลับมาทำ AuthZ

วันหนึ่ง ลูกค้าคนหนึ่งของ SaaS นั้น — เผลอเห็นข้อมูลของลูกค้าอีกคน เพราะแก้ URL — ข่าวออก — บริษัท SaaS โดน churn + ถูกปรับ PDPA

วิธีแก้ — AuthZ ต้องอยู่ใน design ตั้งแต่วันแรก ไม่ใช่ทำทีหลัง. ทุก endpoint ของ API ต้องถามคำถามนี้: “user ที่ login อยู่ มีสิทธิ์ access object นี้หรือเปล่า?”. ไม่ใช่แค่ “login แล้ว = ผ่าน”

หัวใจของ RBAC — ผูกสิทธิ์ไว้กับ “ตำแหน่ง” ไม่ใช่กับ “คน”#

ลองนึกบริษัทที่คุณรู้จัก — มี HR / Sales / Finance / Engineering / Admin. ใน RBAC — เราไม่ได้คิดในมุม “สมชายมีสิทธิ์ทำอะไรบ้าง”. เราคิดในมุม:

• ตำแหน่ง “พนักงานบัญชี” ทำอะไรได้บ้าง? → เปิดดูใบ Invoice, สร้าง Journal Entry, ปิดงบเดือน
• ตำแหน่ง “Sales Manager” ทำอะไรได้บ้าง? → ดู pipeline ของทีม, อนุมัติส่วนลด ≤ 10%, ดู commission report
• ตำแหน่ง “Sales Rep” ทำอะไรได้บ้าง? → ดู pipeline ของตัวเองเท่านั้น, ขอส่วนลด, ส่ง quotation

แล้วค่อย ใส่คนเข้า role — สมชายเป็น “พนักงานบัญชี” → สมชายได้สิทธิ์ของ role นั้นทั้งชุด

ทำไมการคิดแบบนี้ถึงดี? — เพราะมัน scale ได้

ลองนึก — บริษัท 5,000 คน. ถ้าจัดการสิทธิ์แบบ “ผูกกับคนทีละคน” — คุณต้อง config สิทธิ์ 5,000 ชุดที่ต่างกัน. ทีม HR เพิ่มคนใหม่ทุกเดือน — ต้องสร้างสิทธิ์ใหม่ทุกครั้ง

แต่ถ้าใช้ RBAC — คุณมีแค่ 30 role (สมมุติ) สำหรับทั้งบริษัท. คนใหม่เข้า — ใส่เข้า role ที่ตรงตำแหน่ง — จบ. คนย้ายแผนก — เปลี่ยน role — สิทธิ์เปลี่ยนทั้งชุดอัตโนมัติ. คนลาออก — เอาออกจาก role — access หายทันที

ตัวอย่าง RBAC ในระบบจริง#

• AWS IAM — ทุก service ของ AWS ใช้ RBAC. คุณสร้าง role “ReadOnlyAnalyst” — ใส่ policy “อ่าน S3 + อ่าน DynamoDB ได้” — แล้วใส่พนักงาน data analyst เข้า role นั้น
• Azure RBAC — เหมือนกัน. มี built-in role เช่น “Reader”, “Contributor”, “Owner” — บริษัทเอาไปใช้ได้เลย
• Salesforce — มี role hierarchy ที่ออกแบบสำหรับ sales org. CEO อยู่บนสุด → VP → Manager → Rep
• Google Workspace — มี admin role ที่แยก: Super Admin, User Management Admin, Help Desk Admin

ข้อเสียที่ทุกคนต้องรู้ — Role Explosion#

RBAC ดี — แต่มี achilles heel ที่ pattern คลาสสิคของวงการเรียกว่า “Role Explosion”

ลองนึก — บริษัทเริ่มจาก 5 role: Sales / Finance / HR / Engineering / Admin. ดูเหมือนพอเพียง

แต่ทีนี้ — มีพนักงานคนหนึ่งทำ “Sales แต่ดูข้อมูล Finance ของลูกค้าตัวเองได้”. ออกแบบยังไง? — สร้าง role ใหม่ — “Sales-WithFinanceView”

แล้วก็มีอีกคน — “Sales แต่ดู Finance ได้เฉพาะ region เอเชีย” — สร้างอีก role — “Sales-WithFinanceView-AsiaOnly”

อีกคน — “Sales แต่ใน project พิเศษ มีสิทธิ์ approve discount ถึง 30%” — สร้างอีก role

ปีหนึ่งต่อมา — บริษัทที่เริ่มจาก 5 role — มี 400 role. ทีม IT ไม่รู้ว่าแต่ละ role ทำอะไรได้บ้าง. รายชื่อ role ของบริษัทใหญ่ขึ้นเป็น Excel sheet 400 บรรทัด — ไม่มีใครกล้าลบ — เพราะกลัวจะหัก work flow ของพนักงาน

นี่คือ Role Explosion — RBAC ที่บวมจนจัดการไม่ได้. เป็น pattern ที่บริษัทไทยขนาดกลาง-ใหญ่ติดบ่อยมาก. แก้ยากมากเพราะมัน slow rot — สะสมทีละ role ตามคำขอ ad-hoc — ไม่มีใครรู้สึก “ไม่ดี” จนกระทั่งมันเป็น 400

วิธีป้องกัน Role Explosion:

• ตั้งกฎ — role ใหม่ต้องได้รับ approve จาก role committee (รวม IT + Security + Business). ไม่ใช่ใครอยากได้สิทธิ์พิเศษก็ขอ role ใหม่ได้
• review role audit รายปี — role ที่ไม่มีคนอยู่ใน 6 เดือน = ลบ. role ที่ permission overlap กับ role อื่น = รวม
• คิดเป็น ABAC แทน (หัวข้อถัดไป) — ถ้า requirement เริ่มซับซ้อน เกินที่ role จะ handle ได้

มุมผู้บริหาร: ลองขอ list ของ role ในบริษัทคุณจากทีม IT. ถ้าตัวเลขมากกว่า 50 role สำหรับบริษัทขนาด 500 คน = คุณมี Role Explosion. ROI ของการ คลีน role = สูงมาก — เพราะ role ที่ลึกลับ + permission ที่ไม่มีใครรู้ที่มา = หลุมที่ insider threat ใช้ซ่อนตัว. เคสที่เจอได้ทั่วไป — ลาออกไปแล้ว แต่ยังมี role พิเศษค้างอยู่ — ใช้ตัวระบบ login ไม่ได้ แต่มี service account ที่ผูกกับ role ยังทำงานอยู่

หัวใจของ ABAC — ตัดสินใจตาม “คุณสมบัติ” ของ subject + object + context#

ลองนึกฉาก — ผู้บริหารคนหนึ่งบอกทีม IT:

“ผมอยากให้พนักงาน Finance department — ที่อยู่ในประเทศไทย — ใช้ corporate laptop — ระหว่างเวลา 9 โมงเช้า ถึง 6 โมงเย็น — เท่านั้น — เข้า payroll system ได้”

ใน RBAC — คุณทำยังไง? — ต้องสร้าง role ที่ encode ทั้งหมดนี้: “Finance-Thai-OfficeHours-CorpDevice” — แล้วค่อยใส่คนเข้า

แต่ในเดือนหน้า ผู้บริหารบอกว่า — “ยกเว้นช่วงปลายเดือนที่ payroll ต้องปิดงบ — อนุญาตให้เข้านอกเวลาทำการได้”. คุณต้องสร้าง role อีกตัว — “Finance-Thai-PayrollClose-AnyHours-CorpDevice”

อีก 3 เดือนต่อมา ผู้บริหารบอกว่า — “ที่ปรึกษาภายนอกที่ NDA แล้ว — ขอเข้าได้บางช่วงด้วย”. คุณสร้าง role อีก. Role Explosion เริ่มเกิด

นี่คือจุดที่ ABAC เข้ามา. ใน ABAC — คุณไม่เขียน role ตายตัว — คุณเขียน policy ที่อ่านได้เหมือนประโยคของคน:

1
ALLOW access to payroll_system IF:
2
  user.department = "Finance"
3
  AND user.country = "Thailand"
4
  AND device.type = "corporate-managed"
5
  AND current_time BETWEEN 09:00 AND 18:00
6
  AND user.country = device.country  (anti-spoofing — ห้าม IP ไม่ตรงสัญชาติ)

ทุก attribute ในประโยคนี้ — เรียกว่า attribute. มันมาจาก 3 ฝั่ง:

• Subject attribute = ของคนที่ขอเข้า — department, country, role, clearance level
• Object attribute = ของสิ่งที่ขอเข้า — data classification, owner, sensitivity tier
• Context attribute = สภาพแวดล้อม — เวลา, IP address, device type, location, network

ABAC policy = เอา attribute พวกนี้มาเขียน rule ที่อ่านได้

ABAC ใช้ที่ไหนจริง#

• AWS IAM Conditions — IAM ของ AWS ใช้ ABAC ผสม RBAC. คุณเขียน policy ได้ว่า “allow s3 IF aws = 10.0.0.0/8 AND aws < 2026-12-31”
• Azure Conditional Access — ของ Microsoft Entra ID — ตั้ง rule ได้เป็น “ถ้า user อยู่นอกประเทศ + ใช้ device ที่ไม่ใช่ corporate = ต้อง MFA + จำกัด session 1 ชั่วโมง”
• Zero Trust Architecture — แทบทุก zero trust framework (BeyondCorp ของ Google, NIST 800-207) — ใช้ ABAC เป็นแกน — เพราะ zero trust ต้องประเมินทุก request ตาม context ตลอดเวลา ไม่ใช่แค่ “role อะไร”

Trade-off — ABAC ยืดหยุ่นสุด แต่ debug ยากสุด#

ข้อดี ABAC:

• ยืดหยุ่นสูงสุด — เขียน rule อะไรก็ได้ตาม attribute
• ลด Role Explosion — แทนที่จะมี 400 role ก็มี 30 policy ที่ครอบคลุมทุก case
• Context-aware — policy เปลี่ยนตาม situation (เวลา / สถานที่ / device) — ไม่ใช่ static

ข้อเสีย ABAC:

• เขียน policy ยาก — ต้องคิดเป็น logic. มี edge case เยอะ
• Debug ยาก — พนักงาน complain “ทำไมผมเข้าไม่ได้?” — ต้องไล่ดู attribute ของ user + device + context — เทียบกับ policy — หา rule ที่ blocking
• ต้องการ infrastructure — ต้องมี PDP (Policy Decision Point) + PEP (Policy Enforcement Point) + ระบบ collect attribute ตลอดเวลา. แพง + ซับซ้อน
• performance — ทุก request ต้อง evaluate policy ใหม่. cache ยาก

ในวงการ — บริษัทส่วนใหญ่ใช้ RBAC เป็นหลัก + เพิ่ม ABAC เฉพาะจุด ที่ต้องการ context-awareness (เช่น login จากต่างประเทศ = ต้อง MFA เพิ่ม). น้อยบริษัทที่ใช้ ABAC อย่างเดียวทั้งระบบ — เพราะ overhead สูง

มุมผู้บริหาร: บริษัทไทยขนาดกลางที่ยังไม่มี ABAC = ไม่ผิด. เริ่มจาก RBAC ที่สะอาด (ไม่มี Role Explosion) + เปิด Conditional Access ของ Microsoft Entra ID หรือ Google Workspace (เป็น ABAC สำเร็จรูป) — ครอบคลุม use case 80%. ABAC แบบเต็มๆ ทั้งระบบ = เก็บไว้เมื่อบริษัทใหญ่ระดับ enterprise + ทีม security มี maturity เพียงพอที่จะดูแล policy. อย่ากระโดดไป ABAC โดยไม่จัด RBAC ให้สะอาดก่อน — มันจะกลายเป็น policy chaos ที่ debug ไม่ออก

หัวใจของ MAC — ระบบเป็นคนตัดสิน ไม่ใช่เจ้าของไฟล์#

ใน RBAC / ABAC ที่เราเพิ่งดู — admin เป็นคน config policy. แต่ policy ที่กำหนดแล้ว — user ปกติ override ได้บางที (เช่น “พนักงานนี้แชร์ doc ของตัวเองให้คนนอก” — admin อาจอนุญาต)

ใน MAC — ทุกคนใน system รวมทั้ง admin — ต้องเชื่อ system. ไม่มีใคร override ได้

ใช้ภาพทหารครับ — ระบบความลับของกองทัพ — แบ่งระดับ:

• Unclassified (ไม่ลับ — ใครก็เห็นได้)
• Confidential (ลับ — ระดับต่ำ)
• Secret (ลับมาก)
• Top Secret (ลับสุดยอด)

ทหารแต่ละคน — มี clearance level ของตัวเอง (เช่น Secret-cleared). กฎ MAC ของกองทัพ:

• No Read Up — ทหารระดับ Secret — อ่าน Top Secret ไม่ได้. ระบบบล็อก. แม้นายพล Top Secret จะอยากให้ก็ตาม — ต้องผ่านกระบวนการ re-clearance ของหน่วยข่าวกรอง
• No Write Down — ทหารระดับ Top Secret — เขียนข้อมูลลงในไฟล์ระดับ Confidential ไม่ได้. ป้องกัน “leak by mistake” — เผลอเอาข้อมูลลับลงไฟล์ที่คนอื่นเห็นได้

นี่คือ Bell-LaPadula model — รากของ MAC. ในวงการ security ยังใช้สอน CISSP / CISA ทุกวันนี้

MAC ในระบบ IT จริง#

• SELinux (Security-Enhanced Linux) — Linux distribution ที่มี MAC built-in. ใช้กันใน Red Hat Enterprise Linux. process แต่ละตัวมี security context — ระบบบังคับว่า process A เข้าถึงไฟล์ B ได้หรือไม่ — โดยที่ root override ไม่ได้ (เพราะ SELinux อยู่เหนือ root)
• AppArmor — เหมือน SELinux แต่ใน Ubuntu / Debian. profile-based MAC
• Trusted Solaris — old-school Unix variant ของ Sun Microsystems ที่ใช้ในงาน government / military
• iOS / Android sandboxing — app บนมือถือถูกบังคับให้อยู่ใน sandbox ของตัวเอง — เข้าไฟล์ของ app อื่นไม่ได้ — แม้ user อยากให้ก็ตาม (จนกว่าจะ jailbreak) — นี่คือ MAC ระดับ OS

Most enterprise ไม่ใช้ MAC แท้ๆ — แต่ใช้ concept ใน Data Classification#

นี่คือจุดที่หลายคนสับสน. บริษัทไทยทั่วไปไม่ได้ deploy SELinux. แต่ — concept ของ MAC อยู่ในทุกบริษัทที่มี data classification policy:

• Public — ข้อมูลที่ปล่อยให้สาธารณะรู้ได้ (marketing material, ข่าวประชาสัมพันธ์)
• Internal — ข้อมูลภายในที่พนักงานเห็นได้ทั้งหมด (employee handbook)
• Confidential — ข้อมูลที่จำกัดบางแผนก (financial report ก่อนประกาศ, contract กับ vendor)
• Restricted — ข้อมูลความลับสูงสุด (เงินเดือนพนักงาน, key encryption, ข้อมูลลูกค้าที่เป็น PII)

แต่ละ tier — มี handling rule. พนักงานทั่วไปไม่มีสิทธิ์ override — เช่น พนักงานเอา doc ที่เป็น Confidential ไปส่งใน email ส่วนตัว = ระบบ DLP (Data Loss Prevention) บล็อก. นี่คือ MAC-style enforcement แม้จะไม่ใช่ MAC แท้ทาง technical

มุมผู้บริหาร: บริษัทคุณมี data classification policy หรือยัง? — 4 tier ก็พอ (Public / Internal / Confidential / Restricted). ทุกไฟล์ที่ company สร้าง — ต้องมี tag tier นี้. ทุก SaaS ของบริษัทที่จัดการข้อมูลลูกค้า — ต้องบังคับ tag. ROI สูงมาก — เพราะวันที่มี data breach — ทุก investigator + ทุก regulator จะถามว่า “ข้อมูลที่หลุดเป็นระดับไหน”. ถ้าตอบไม่ได้ = บริษัทคุณจะถูกประเมินว่า ไม่ได้ทำ data governance — penalty หนักกว่า

หัวใจของ DAC — เจ้าของไฟล์มีอำนาจตัดสินใจเอง#

Discretionary = ใช้ดุลยพินิจ. ในระบบ DAC — เจ้าของไฟล์ตัดสินใจเองว่าใครเข้าถึงไฟล์นั้นได้บ้าง

ตัวอย่างที่ทุกคนใช้ทุกวัน:

• Google Drive — คุณสร้างไฟล์ Google Docs — กดปุ่ม Share — เลือก “เพิ่มคน” + ใส่ email — เลือกสิทธิ์ (Viewer / Commenter / Editor) — ส่ง. ระบบไม่เคยถามคุณว่า “ไฟล์นี้ classification อะไร” — คุณเป็นเจ้าของ คุณตัดสินใจเอง
• Windows NTFS — คลิกขวาที่ไฟล์ → Properties → Security tab → เพิ่ม user — กำหนด permission (Read / Write / Modify / Full Control). เจ้าของไฟล์ตัดสินใจ
• Linux File Permissions — chmod 755 file.txt — เจ้าของกำหนด rwx ของตัวเอง / group / other
• Slack channel — เจ้าของ channel เลือกว่าใครเข้าได้บ้าง

DAC คือ default ของ consumer + productivity software ทั่วโลก. ทำไม? — เพราะมัน flex สำหรับ user. user มีอำนาจ — share ใครก็ได้

ข้อเสียที่ทำให้ DAC อันตรายในระดับองค์กร — User เผลอแชร์#

ลองนึก pattern คลาสสิคของวงการ ที่ขึ้นข่าวบ่อยมาก:

• พนักงานบริษัทคนหนึ่ง — สร้าง Google Sheet — มีรายชื่อลูกค้า + เบอร์โทร + ยอดซื้อ
• ต้องส่งให้เพื่อนภายในแผนกดู — กดปุ่ม Share → เลือก “Anyone with the link” → copy link → ส่ง chat — เร็วและสะดวก
• ไม่กี่เดือนต่อมา — link ของ sheet นั้น ถูก search engine index — มี crawler เก็บไป — กลายเป็นผลลัพธ์ที่ search ใน Google เจอ
• ข้อมูลลูกค้าของบริษัทหลุดเข้าไปอยู่ใน Google Search

นี่คือ pattern ที่ขึ้นข่าวไม่ต่ำกว่า 10 ครั้งใน 5 ปีที่ผ่านมาในต่างประเทศ — และเป็น pattern ที่บริษัทไทยติดบ่อยมาก (แต่ไม่ค่อยขึ้นข่าว เพราะบริษัทไทยไม่ค่อย disclosure). หลายครั้งเป็น Google Drive ที่ตั้งเป็น “anyone with link” ของ folder ที่มีรายชื่อพนักงาน + เงินเดือน

ข้อเสียที่ใหญ่กว่า — Transitive Sharing#

มีปัญหาที่ลึกกว่าครับ. ในระบบ DAC — ถ้าคุณ share ไฟล์ให้ใครได้ คนนั้นอาจ share ต่อให้คนอื่นได้

• คุณ share Google Sheet ให้สมหญิง (Editor)
• สมหญิงเปิดสิทธิ์ Share ของไฟล์ที่คุณสร้าง — เพิ่มสมชาย (Editor)
• สมชายเพิ่มคนนอกบริษัท

ไฟล์ที่ คุณเป็นเจ้าของ — ตอนนี้คนนอกบริษัทเห็น — คุณไม่รู้ตัว

นี่คือ transitive sharing problem ของ DAC. Google ทำให้แก้ได้ผ่าน “สิทธิ์ในการ share” ที่ตั้งได้ — แต่ default ของส่วนใหญ่ของ tier ใหม่คือ เปิด share ได้ — เพื่อให้ user สะดวก

บริษัทควรใช้ DAC อย่างไร#

• อย่าใช้ DAC ทั้งบริษัทโดยไม่มี control — บังคับให้ Google Workspace / Microsoft 365 มี sharing policy ระดับ organization (เช่น “ไฟล์ที่มี tag Confidential ห้าม share ออกนอก domain”)
• ใช้ DLP รุ่นใหม่ที่อ่าน content — บางระบบ scan content ของไฟล์ — เจอ pattern PII (เลขบัตรประชาชน / เลขบัตรเครดิต) = บล็อก share อัตโนมัติ
• review sharing audit log รายสัปดาห์ — ใครแชร์อะไรออกนอกบริษัทบ้าง
• education — ฝึกพนักงานให้รู้ว่า “Anyone with link” = สาธารณะ — ไม่ใช่ “เฉพาะคนที่ฉันส่ง link ให้”

มุมผู้บริหาร: ลองทำ exercise ง่ายๆ ในบริษัทคุณ — ขอ list ของ Google Drive ที่ public หรือ “Anyone with link” ในทั้ง organization. ถ้าบริษัทคุณใช้ Google Workspace — มี Drive audit log ที่ทำได้. ส่วนใหญ่ของบริษัทไทย — ตัวเลขจะตกใจ — เพราะพนักงานทำ ad-hoc ไปเรื่อย โดยไม่มี policy ว่าด้วยการ share. ROI ของ exercise นี้สูงมาก — เพราะตัวเลขที่เห็น = risk ของ data breach แบบเงียบๆ ที่บริษัทไม่รู้ว่ามี

กฎที่ 1 — Least Privilege (สิทธิ์น้อยที่สุดที่จำเป็น)#

ทุก user, ทุก process, ทุก service — ได้รับสิทธิ์เฉพาะที่จำเป็นในการทำงาน — ไม่เกินกว่านั้น

ตัวอย่างชีวิตจริง:

• service account ของ web app ที่ access database — ควรได้สิทธิ์ SELECT + INSERT + UPDATE เฉพาะ table ที่ใช้ — ไม่ใช่ DROP TABLE หรือ Admin
• พนักงาน HR — มี access แค่ระบบ HR — ไม่ควรมี access ระบบบัญชี / engineering
• CEO — แม้จะเป็นคนใหญ่สุด — ไม่ได้แปลว่าต้องมี admin ของระบบ IT. CEO ดู report, สั่งการได้ — แต่ admin access ของ system ควรอยู่กับ IT เท่านั้น (ลด attack surface)

ทำไมสำคัญ? — เพราะถ้า account นั้นถูก compromise — damage ถูกจำกัดที่สิทธิ์ที่มี. CEO account ที่มีสิทธิ์ทั่วบริษัท ถูก phish = end of game. CEO account ที่มีแค่ “ดู report” = damage จำกัด

กฎที่ 2 — Need-to-Know (รู้เท่าที่จำเป็น)#

user เห็นข้อมูลเฉพาะที่ต้องใช้ในงาน — ไม่ใช่ทั้งหมดที่มีในระบบ

ความต่างกับ Least Privilege:

• Least Privilege = สิทธิ์ในการ “ทำ” (action) — read / write / delete
• Need-to-Know = สิทธิ์ในการ “เห็น” (visibility) — เห็นข้อมูลของใครบ้าง

ตัวอย่าง:

• Sales Rep ดู pipeline ได้ — แต่เห็นเฉพาะลูกค้าของตัวเอง — ไม่ใช่ของ Sales Rep ทุกคนในบริษัท
• HR ของ region เอเชีย — เห็นข้อมูลพนักงานของ region เอเชีย — ไม่ใช่ของ region อเมริกา
• Customer support — เห็น ticket ของลูกค้าที่ตัวเองดูแล — เห็นชื่อ + เบอร์ — แต่ไม่เห็น credit card หรือ password

กฎที่ 3 — Separation of Duties (SoD — แยกหน้าที่)#

งานสำคัญงานเดียว ต้องการคน ≥ 2 คน approve. ป้องกันคน 1 คนทำผิดคนเดียว

ตัวอย่างคลาสสิคที่ใช้สอน CISA:

• คนสร้าง vendor ในระบบ ≠ คนอนุมัติจ่ายเงินให้ vendor — ถ้าคนเดียวทำทั้ง 2 = สร้าง vendor ปลอม + อนุมัติเงินให้ตัวเอง
• คนสั่ง trade ≠ คนยืนยัน trade ≠ คนทำ settlement — ใน trading desk แยก front office / middle office / back office
• developer ที่เขียน code ≠ คน deploy code ขึ้น production — เพราะ developer ที่มีสิทธิ์ deploy = ใส่ backdoor ได้ในชื่อตัวเอง

เคสจริง — Société Générale 2008 (€4.9B Trader Fraud)#

นี่คือเคสที่ใช้สอน SoD ในทุกห้องเรียน CISA / CISSP ทั่วโลกครับ. มันคือบทเรียนว่า ถ้า Separation of Duties พัง — แม้แบงค์ระดับโลกก็ล้มได้

มกราคม 2008 — Société Générale ธนาคารใหญ่อันดับ 2 ของฝรั่งเศส — ประกาศขาดทุน €4.9 พันล้านยูโร (ราว 240,000 ล้านบาทในตอนนั้น) จากการ trade ของ trader คนเดียว — ชื่อ Jérôme Kerviel

Kerviel ทำงานที่ Société Générale ตั้งแต่ปี 2000:

• ปี 2000-2005 — เริ่มต้นที่ back office — งานยืนยัน trade + reconcile + ทำ settlement
• ปี 2005 — ย้ายไป front office — เป็น trader ที่ Delta One desk — trade futures index ของยุโรป

จุดที่พลาด — Société Générale อนุญาตให้ Kerviel ย้ายจาก back office ไป front office โดยที่เขายังรู้วิธีทำงานของ back office. เขามี knowledge ที่ครอบทั้ง 2 บทบาท — บทบาทที่หลักการ SoD บอกว่า “คนเดียวต้องไม่รู้ทั้งคู่”

ด้วย knowledge นี้ — Kerviel:

• ทำ trade จริง = position ใหญ่ขนาด €50 พันล้าน (มากกว่า market cap ของ Société Générale ทั้งบริษัทตอนนั้น)
• เพื่อปกปิด — สร้าง trade ปลอมในระบบ back office ที่ offset position จริงๆ — ทำให้ middle office มองว่าบริษัทไม่มี risk
• รู้ตารางเวลาของ reconciliation = ปลอม trade ที่จะหายไปก่อน reconcile + สร้างใหม่หลัง reconcile
• ปลอมเอกสาร confirmation ของ counterparty
• ทำแบบนี้ตั้งแต่ปี 2005-2008 — ปลอม trade รวมๆ มูลค่าหลายพันล้าน — โดยที่ระบบ control ของ Société Générale ไม่จับ

ตอนกระแสตลาดในมกราคม 2008 — position จริงที่ Kerviel สร้างไว้ — ขาดทุน. Société Générale ต้อง unwind position ในตลาดที่กำลังตก = ขาดทุน €4.9B ภายในไม่กี่วัน

บทเรียน — Société Générale มี risk control + audit + 4 eyes principle ครบ — แต่ทุกตัวพัง เพราะ Kerviel มี knowledge ของทั้ง front office และ back office — เขารู้ว่า audit จะดูตรงไหน + เลี่ยงตรงไหนได้. SoD ที่ทำให้คน 1 คน ไม่มีทางถือ 2 บทบาทขัดกัน = control พื้นฐานที่ป้องกันเรื่องแบบนี้ได้

หลังเคสนี้ — ทุกธนาคารทั่วโลก revisit SoD ของ trader floor. มาตรฐาน Basel III เพิ่ม requirement ให้ trader ที่ย้ายจาก back office ต้อง cooling-off period 2 ปี ก่อนเริ่ม trade — และ access ของ back office system ต้องถูกตัดทันทีที่ย้าย

มุมผู้บริหาร: SoD เป็น control ที่ ราคาถูก + ROI สูงสุด ในงาน fraud prevention. ไม่ต้องลงทุน technology อะไรเลย — แค่ออกแบบ workflow ให้ critical task ต้องมี ≥ 2 คน approve. ลองตรวจในบริษัทคุณ — มี process ไหนที่คน 1 คน สร้าง + อนุมัติ + จ่าย ได้คนเดียวไหม? — ถ้ามี = เป็น ช่องโหว่ที่ใหญ่ที่สุด. แก้ได้ในวันเดียวด้วยการเปลี่ยน workflow

Bonus — ACL vs Capability: 2 รูปแบบของการเก็บสิทธิ์#

มาดู technical detail ปิดท้ายครับ. เวลา system เก็บข้อมูลว่า “ใครเข้าอะไรได้บ้าง” — มี 2 รูปแบบ:

1
ห้องเก็บเงิน — เฉพาะคนเหล่านี้เท่านั้น:
2
- คุณ A (อ่าน + เขียน)
3
- คุณ B (อ่าน)
4
- คุณ C (อ่าน + เขียน + ลบ)

1
คุณ A — บัตรนี้เข้าได้:
2
- ห้องเก็บเงิน (อ่าน + เขียน)
3
- ห้อง server (อ่าน)
4
- ห้องเอกสาร (อ่าน + เขียน + ลบ)

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — เริ่มที่ RBAC ที่สะอาด. เพิ่ม ABAC เมื่อต้องการความยืดหยุ่นเฉพาะจุด

นี่คือคำแนะนำที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. บริษัทไทยขนาดกลางส่วนใหญ่ — ยังไม่ต้อง ABAC ทั้งระบบ. เริ่มจากการจัด RBAC ให้สะอาด — role ไม่บวม + review ทุกปี + ลบ role ที่ไม่ใช้

หลังจาก RBAC สะอาด — เพิ่ม ABAC เฉพาะ use case ที่ต้องการ:

• Conditional Access ของ Microsoft Entra ID — เปิดให้ระบบประเมิน context (IP / device / location) ก่อนอนุญาต login
• Google Workspace Context-Aware Access — เหมือนกัน
• AWS IAM Conditions — สำหรับ cloud workload
• Sensitivity labels + DLP — สำหรับ document sharing

3 ขั้นตอนของการ implement ที่ผมแนะนำสำหรับบริษัทไทยขนาดกลาง:

1. ขั้นที่ 1 (เดือน 1-3) — Clean RBAC — รวบรวม role ทั้งหมด + review + ลบที่ซ้ำซ้อน + เขียน documentation
2. ขั้นที่ 2 (เดือน 4-6) — Conditional Access — เปิด Conditional Access ของ IdP — กำหนด rule พื้นฐาน (เช่น MFA required from outside corp network)
3. ขั้นที่ 3 (เดือน 7+) — Data Classification + DLP — tag data ของบริษัท + setup DLP — บล็อก share Confidential data ออกนอก domain

ทำตามนี้ — บริษัทคุณจะมี authorization architecture ที่เทียบเคียงได้กับ enterprise ระดับโลก — โดยที่ไม่ต้องลงทุนระดับล้านบาท

ข้อสอง — Separation of Duties เป็น control ที่ราคาถูกที่สุด + ROI สูงที่สุดในงาน fraud prevention

ข้อนี้เป็น mindset shift ที่ผู้บริหารหลายคนยังไม่เห็นภาพครับ. SoD ไม่ต้องลงทุนเทคโนโลยี. มันคือเรื่องของ workflow design — ออกแบบให้ critical task ต้องมี ≥ 2 คน approve

ลองทำ exercise ในบริษัทคุณ — ระบุ critical workflow:

• จ่ายเงินให้ vendor — คนสร้าง vendor record ≠ คนอนุมัติเงิน
• เปลี่ยน salary ของพนักงาน — คนเสนอเปลี่ยน ≠ คนอนุมัติ ≠ คน execute ในระบบ HRIS
• deploy code ขึ้น production — developer ที่เขียน ≠ คน review code ≠ คน deploy
• release ข้อมูล customer ให้คนภายนอก — คนรับคำขอ ≠ คนอนุมัติ ≠ คน export ข้อมูล
• สร้าง admin account ในระบบ — คนขอ ≠ คนอนุมัติ ≠ คน provision

ถ้าใน workflow ไหน คน 1 คนทำทั้งหมดได้ = ช่องโหว่ที่ใหญ่ที่สุด. แก้ได้ในวันเดียว — แค่ออก policy ใหม่ + บังคับ workflow ใน system

case ของ Société Générale 2008 — ในวงการ banking ใช้สอนกันทุกห้องเรียนทั่วโลกว่า knowledge ของ 2 บทบาทใน 1 คน = bomb ที่รอจุด. €4.9B หายไปเพราะคนเดียวที่รู้ทั้ง front office + back office. ถ้า SoD ทำงาน — Kerviel อาจ trade เล็กๆ ได้ — แต่ไม่มีทางปลอม trade ในระบบ back office พร้อมกัน

ในวงการ security ปี 2026 — บริษัทที่มี SoD ที่ดี = ลด fraud risk 70-80% โดยไม่ต้องลงทุนเทคโนโลยี. นี่คือ control ที่ ROI สูงที่สุดที่บริษัทไทยควรเริ่มทันที