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 สูงที่สุดที่บริษัทไทยควรเริ่มทันที