Twitter 2020 — เคสที่ทำให้วงการตื่น#

ขอใช้เคสจริงเล่าให้เห็นภาพชัดครับ — Twitter 2020

วันที่ 15 กรกฎาคม 2020 — กลางวันของวงการ social media ทั่วโลก บัญชี Twitter ของบุคคลที่ดังที่สุดในโลกพร้อมกัน — Barack Obama, Elon Musk, Bill Gates, Apple, Joe Biden, Kanye West, Jeff Bezos, Warren Buffett — โพสต์ tweet เหมือนกันเป๊ะ:

“ผมอยากตอบแทนสังคม. ส่ง Bitcoin มาที่ wallet นี้ — ผมจะส่งคืน 2 เท่า ภายใน 30 นาที”

ภายใน 2 ชั่วโมง — โจรได้ Bitcoin มูลค่า $118,000 จากผู้ใช้ทั่วโลกที่หลงเชื่อ. แต่นั่นคือ damage เล็ก. damage ใหญ่คือ — ในชั่วโมงนั้น โจรเข้าถึงข้อความ private ของบัญชีระดับโลก + ดาวน์โหลด data ของ 8 บัญชีเต็ม (รวม direct messages ที่ไม่เคยถูก reveal ในประวัติศาสตร์ของ Twitter เลย)

โจรเข้ามาได้ยังไง? — Spear phishing พนักงาน Twitter 4 คนที่มีสิทธิ์เข้า admin panel ภายใน — เครื่องมือที่พนักงาน support ใช้รีเซ็ต password, เปลี่ยน email, ปลด lock บัญชี. โจรหลอกให้พนักงานบอก credential + MFA code → เข้า admin panel → จากนั้น กดเปลี่ยน email ของบัญชี @BarackObama ได้ในคลิกเดียว → reset password → take over

ที่น่าตกใจที่สุดในเคสนี้ — ไม่ใช่เพราะระบบของ Twitter ถูกแฮกในแง่ technical. ไม่มีใครเจาะ encryption, ไม่มีใครหา zero-day vulnerability. โจรแค่ ขโมย identity ของพนักงาน 4 คน + ใช้เครื่องมือที่ Twitter ออกแบบให้พนักงานใช้ปกติ — ผลคือบัญชีระดับโลกโดนยึดในชั่วโมงเดียว

บทเรียนของวงการจากเคสนี้ครับ — identity layer คือ single point of failure ของทุกบริษัท. ถ้าโจรครอบครอง identity ของคนที่มีสิทธิ์ — ทุก control อื่นไม่มีความหมาย. และนี่คือเหตุที่ Part 2 ของ series นี้ มี 8 EPs ทั้งหมดเพื่อปูเรื่อง identity — เพราะถ้าเรื่องนี้ไม่แน่น ทุก control ที่ผมจะเล่าใน Part 3-6 ไม่มีประโยชน์

มุมผู้บริหาร: ถ้าวันนี้คุณมีงบ security 100 บาท — ทุกหนังสือ + ทุก consulting firm ระดับโลกจะแนะนำตรงกันว่า ลงใน identity ก่อน — มากกว่าทุก control อื่น. เหตุผลคือ — control อื่นๆ ทั้งหมด build บน identity เป็นฐาน. firewall ที่ดีที่สุดในโลก + encryption ที่แข็งที่สุด + SIEM ที่แพงที่สุด — ถ้าไม่รู้ว่าใครเป็นใคร + ใครมีสิทธิ์อะไร = ไร้ประโยชน์. คำถามที่ผู้บริหารควรถาม CIO ในประชุมถัดไปคือ — “ในบริษัทเราตอนนี้ — มี account กี่บัญชี? เป็นของคนปัจจุบันกี่บัญชี? เป็น service account กี่บัญชี? และมีบัญชีที่ไม่มีคนรับผิดชอบกี่บัญชี?” ถ้าตอบไม่ได้ภายใน 1 นาที = บริษัทคุณยังไม่รู้จัก identity ของตัวเอง

Vendor หลักในตลาด — รู้ชื่อไว้ก่อน#

ผมจะไม่ลึกใน vendor ตอนนี้ครับ — เพราะเรื่อง vendor selection อยู่ใน EP ถัดๆ ไป. แต่อยากให้คุณรู้จักชื่อ 4 ตัวที่ผู้บริหารน่าจะเจอบ่อย:

• Okta — vendor ที่ใหญ่ที่สุดในวงการ IAM ตอนนี้ (ในอเมริกา + ระดับโลก). โดดเด่นเรื่อง SSO + Multi-Cloud. ราคาเริ่มต้น $2-8/user/เดือน ขึ้นกับ feature
• Microsoft Entra ID (ชื่อเก่า Azure AD) — IAM ของ Microsoft. รวมอยู่ใน Microsoft 365 license หลายตัวอยู่แล้ว — บริษัทที่ใช้ Office 365 มักได้ Entra ID มาด้วย “ฟรี” (ในระดับ feature พื้นฐาน). บริษัทไทยที่ใช้ Microsoft ecosystem ส่วนใหญ่จะลงเอยที่ Entra ID
• Ping Identity — vendor enterprise สำหรับบริษัทใหญ่ที่มีระบบเก่า (legacy) เยอะ. เน้นเรื่อง federation + integration กับระบบเก่า
• JumpCloud — vendor ใหม่กว่า เน้นบริษัทเล็ก-กลาง. ราคาประหยัด ใช้ง่าย แต่ feature น้อยกว่า Okta / Entra

ผมจะกลับมาคุยเรื่อง vendor selection ลึกขึ้นใน EP.15 ตอนคุยเรื่อง Federation / SSO. ตอนนี้ขอให้คุณคุ้นชื่อก่อนพอ

กลับมาที่ analogy — ระบบบัตรประจำตัวของบริษัท#

ผมขอใช้ analogy ที่จะใช้ไปทั้ง EP นี้ครับ — IAM คือระบบบัตรประจำตัวพนักงานของบริษัท แต่ดิจิทัล + ใช้กับ 50 ระบบพร้อมกัน

ลองนึกภาพบริษัทขนาดกลางขนาด 500 คน. พนักงานหนึ่งคนใช้ระบบอะไรบ้างในวันทำงานปกติ? — email, Slack/Teams, Google Drive/SharePoint, CRM (เช่น Salesforce/HubSpot), ERP (เช่น SAP/Oracle), HR system, ระบบเงินเดือน, VPN, Wi-Fi office, Zoom, Figma (ถ้าเป็น designer), GitHub (ถ้าเป็น developer), Adobe Creative Cloud, ระบบจอง meeting room, ระบบเบิกค่าใช้จ่าย — เฉลี่ยพนักงานหนึ่งคนใช้ 20-50 ระบบ

ทีนี้คิดต่อ — บริษัท 500 คน × 30 ระบบ = 15,000 account ที่ต้องจัดการ. แล้วทุกปีมีพนักงานเข้าใหม่ ออก ย้ายแผนก เลื่อนตำแหน่ง — เท่ากับมี การเปลี่ยนแปลง 1,000+ ครั้งต่อปี. ถ้าทำด้วยมือ — ไม่มีทางทำได้ครับ. ต้องมีระบบ

นี่คือเหตุที่ IAM เกิดขึ้นมา — ระบบที่ทำให้ HR + IT + Manager ทำงานร่วมกันได้ในเรื่อง identity แบบอัตโนมัติ + ตรวจสอบได้. ในเมืองที่เราเดินมาตั้งแต่ EP.01 — IAM คือ ระบบทะเบียนราษฎร์ของเมือง + ระบบออกบัตรประชาชน + ระบบกุญแจห้อง รวมกัน — แต่สำหรับบริษัท + แบบดิจิทัล

Lifecycle 3 ขั้น — J / M / L#

วงการ IAM เรียก 3 ช่วงสำคัญของชีวิตพนักงานในบริษัทว่า J / M / L:

• J — Joiner (วันที่เข้ามา)
• M — Mover (วันที่ย้ายแผนก / เลื่อนตำแหน่ง / เปลี่ยนบทบาท)
• L — Leaver (วันสุดท้ายที่ออก)

แต่ละขั้นมี process + ความเสี่ยง + เครื่องมือที่ต่างกัน. และจาก pattern ที่ออกข้อสอบ CISA บ่อย + รายงาน access review ของวงการ — บริษัทไทย ส่วนใหญ่ทำขั้น J ค่อนข้างดี (เพราะ HR อยากให้พนักงานใหม่ทำงานได้เร็ว), ทำขั้น M ลวกๆ (เพราะไม่มีใครเป็นเจ้าของ process), และทำขั้น L แย่ที่สุด (เพราะตอนพนักงานออก ไม่มีใครเดือดร้อนนอกจาก security team)

ใน 3 ส่วนถัดไปของ EP นี้ — เราเจาะทีละขั้นครับ

มุมผู้บริหาร: ก่อนเข้า detail ผมอยากให้คุณตอบคำถามตัวเองสั้นๆ ครับ — บริษัทคุณมีคนที่เป็นเจ้าของ “IAM process” ชัดเจนไหม? ใครเป็น single point of contact ที่ตอบได้ว่า — พนักงานคนนี้มี access อะไรบ้าง?. ถ้าคำตอบคือ “HR ดูเรื่องคน. IT ดูเรื่องระบบ. ไม่มีคนที่ดูทั้ง 2 ฝั่งรวมกัน” = บริษัทคุณยังไม่มี IAM. มีแค่ HR system + IT system ที่ทำงานแยกกัน. นี่คือต้นทางของ orphan account ที่เราจะคุยใน Leaver section. คำแนะนำของผมคือ — แต่งตั้งคนหนึ่งคน (มักเป็น CIO หรือ CISO หรือ HR Director — ขึ้นกับขนาดบริษัท) ให้เป็น “IAM Owner” — รับผิดชอบทั้ง process + technology. ค่าจ้างคนคนนี้ < ค่า breach 1 ครั้งหลายร้อยเท่า

Provisioning — การสร้างสิทธิ์อัตโนมัติ#

Provisioning = process ที่ระบบ IAM สร้าง account + กำหนดสิทธิ์ใน ทุกระบบ ของบริษัท อัตโนมัติ เมื่อ HR กรอกข้อมูลพนักงานใหม่เข้ามาใน HR system

ขั้นตอนคร่าวๆ ครับ:

1. HR กรอกข้อมูล ลง HR system — ชื่อ, ตำแหน่ง, แผนก, manager, วันเริ่มงาน
2. IAM ดึงข้อมูลจาก HR system อัตโนมัติ
3. IAM ดู rule ที่บริษัทตั้งไว้ — เช่น “ตำแหน่ง Sales Manager แผนก North = ต้องมี Email + Slack + CRM (สิทธิ์ Manager) + VPN + ระบบเบิกค่าใช้จ่าย”
4. IAM สร้าง account ใน 5 ระบบนั้นพร้อมกัน — ทุกระบบมี email เดียวกัน, password ชั่วคราวเดียวกัน, สิทธิ์ตาม rule
5. IAM ส่ง email ให้พนักงาน + manager — บอกว่ามี account อะไรพร้อมแล้ว
6. พนักงานวันแรก login — ทำงานได้ทันที

วงการเรียก state ที่พนักงานใหม่ทำงานได้ทันทีว่า Day-1 Readiness — พร้อมตั้งแต่วันแรก

Real case — Microsoft Entra ID auto-provisioning#

ผมขอใช้เคสจริงเล่าครับ — บริษัท technology ขนาดกลาง (~1,000 คน) ที่เปลี่ยนจาก manual provisioning มาเป็น Microsoft Entra ID auto-provisioning ผ่าน SCIM protocol (มาตรฐานการ sync identity ระหว่างระบบ)

ก่อนเปลี่ยน — manual:

• HR ส่ง email หา IT — “พนักงานใหม่ 5 คนเข้าวันจันทร์ครับ”
• IT คน 1 คน นั่งสร้าง account ใน 12 ระบบ × 5 คน = 60 account ด้วยมือ
• เวลาที่ใช้: 2-3 วัน
• ความผิดพลาด: บ่อย — ลืมสร้างในระบบใดระบบหนึ่ง, ใส่สิทธิ์ผิด, copy-paste สิทธิ์ของพนักงานเก่า (ที่อาจมีสิทธิ์เกินจำเป็น)

หลังเปลี่ยน — auto-provisioning:

• HR กรอกข้อมูลใน HR system
• Entra ID sync ข้อมูลทุก 30 นาที — เห็นพนักงานใหม่
• ดู rule ที่ตั้งไว้ตามตำแหน่ง + แผนก → สร้าง account ในทั้ง 12 ระบบพร้อมกัน
• เวลาที่ใช้: 30 นาที
• ความผิดพลาด: น้อยมาก (เพราะ rule เขียนไว้ตายตัว — ไม่มี human decision ใน loop)

ผลที่ Microsoft โฆษณาเป็น case study — onboarding time จาก 3 วัน → 30 นาที. นั่นคือสิ่งที่บริษัทไทยควรเล็ง

กับดักของ Joiner — over-provisioning จาก Day 1#

แต่ — และนี่คือจุดสำคัญที่บริษัทไทยพลาดบ่อยที่สุดครับ — กับดักของขั้น Joiner ไม่ใช่ “พนักงานใหม่ login ไม่ได้”. กับดักคือ “พนักงานใหม่ได้สิทธิ์เกินจำเป็น”

อะไรทำให้เกิด over-provisioning ตั้งแต่ Day 1? — admin ขี้เกียจคิด

นี่เป็น pattern คลาสสิคของบริษัทไทย. ลองนึก scenario นี้ — พนักงาน Mr.B เข้าใหม่ตำแหน่ง Sales Manager. IT admin ที่ดู account ไม่อยากเสียเวลาคิดว่า Sales Manager ควรมีสิทธิ์อะไรบ้าง. เขาเปิด account ของ Mr.C (Sales Manager คนเดิม) → กด “copy permissions to new user” → จบ. Mr.B ได้สิทธิ์ เท่า Mr.C ทันที

ปัญหาคืออะไร? — Mr.C ทำงานบริษัทนี้มา 5 ปี. ในระหว่างนั้น Mr.C เคยช่วยแผนก Marketing ตอน campaign ใหญ่ → ได้สิทธิ์เข้า marketing tools เพิ่ม. เคยช่วยแผนก Finance สรุปยอดขายปลายปี → ได้สิทธิ์ดู finance dashboard เพิ่ม. เคย backup ให้ Sales Director ลาคลอด → ได้สิทธิ์ admin ของ CRM. ทั้งหมดนี้ Mr.C ใช้ครั้งเดียวแล้วไม่ใช้อีก — แต่สิทธิ์ยังอยู่

ตอน IT copy permission ของ Mr.C ให้ Mr.B — Mr.B ที่เพิ่งเริ่มงาน Day 1 ได้สิทธิ์เกินจำเป็น 4-5 เท่า. และ Mr.B ก็ไม่รู้ว่าตัวเองมีสิทธิ์เหล่านั้น เพราะไม่เคยเปิดใช้

นี่คือจุดเริ่มต้นของปัญหาที่เราจะเจอใน Mover section — Privilege Creep

ทางแก้ — Role-Based Access Control (RBAC) จาก Day 1#

ทางแก้ที่บริษัท security-mature ใช้คือ — ไม่ copy สิทธิ์จากคนใดคนหนึ่ง. ใช้ template ของ “ตำแหน่ง” แทน

RBAC (Role-Based Access Control — การควบคุมการเข้าถึงตามบทบาท) = ระบบที่กำหนดสิทธิ์ตาม role (เช่น “Sales Manager - North”, “Finance Analyst”) ไม่ใช่ตามคน. ทุกคนใน role เดียวกันได้สิทธิ์เท่ากันเป๊ะ — ไม่ขึ้นกับว่าคนคนนั้นเคยทำงานพิเศษอะไรในอดีต

ขั้น Joiner ที่ดี:

1. HR ระบุ role ของพนักงานใหม่ใน HR system
2. IAM ดู role → สร้าง account + ให้สิทธิ์ตาม template ของ role นั้น (ไม่ใช่ copy จากคนใดคนหนึ่ง)
3. ถ้าพนักงานใหม่ต้องการสิทธิ์เพิ่มในภายหลัง → ต้องขออนุมัติแยกต่างหาก — ทำเป็น exception ที่มี ticket + manager sign-off

ผลคือ — พนักงานใหม่ Day 1 = minimum permission ที่ทำงานได้ — ไม่ใช่ everything-everyone-has. นี่คือหลักการ Least Privilege (สิทธิ์น้อยที่สุดที่ทำงานได้) ที่เราจะคุยลึกใน EP.16

RBAC ลึกอีกใน EP.16 ครับ — ตอนนี้ขอแค่รู้ว่า มี alternative ของ “copy สิทธิ์จากคนเก่า” ที่ไม่ก่อปัญหา

มุมผู้บริหาร: 2 คำถามที่ผู้บริหารควรถาม HR + IT ในประชุมถัดไปเรื่อง Joiner ครับ. คำถามที่ 1: “พนักงานใหม่ Day 1 — login ระบบทำงานได้ภายในกี่นาที?” ถ้าตอบ “ต้องรอ 1-3 วัน” = บริษัทคุณยังใช้ manual provisioning. กำลังเสียเวลา + เสีย first impression ของพนักงานใหม่. คำถามที่ 2: “Access ที่พนักงานใหม่ได้ใน Day 1 — มาจาก template ของตำแหน่ง หรือ copy จากคนที่เคยอยู่ในตำแหน่งเดิม?” ถ้าตอบ “copy จากคนเก่า” = คุณกำลังสะสมหนี้ permission ตั้งแต่ Day 1 ของทุกคน. 2 คำถามนี้แยกบริษัทระดับ “ทำได้” กับ “ทำดี” ได้ในประโยคเดียว

Privilege Creep — การคืบคลานของสิทธิ์#

Privilege Creep (การคืบคลานของสิทธิ์) = ปรากฏการณ์ที่สิทธิ์ของพนักงานคนหนึ่งสะสมเพิ่มขึ้นเรื่อยๆ ตามเวลาที่ทำงานในบริษัท — โดยที่ไม่มีใครเอาสิทธิ์เก่าออก

คำว่า “creep” (คืบคลาน) บอกอะไร? — มันคืบเข้ามาทีละนิด ช้าๆ จนไม่มีใครสังเกต. ไม่มีจุดไหนที่ใครพูดว่า “เอ๊ะ Mr.D ตอนนี้มีสิทธิ์เกินไปแล้วนะ” — เพราะแต่ละครั้งที่เพิ่มสิทธิ์มันเหมาะสมในตอนนั้น

ผมขอเล่าเป็น story ครับ — เรื่องของ Mr.D ที่ทำงานในบริษัทเดียวมา 4 ปี:

ปีที่ 1 — Mr.D เริ่มงานในแผนก Sales. ตำแหน่ง Sales Executive. สิทธิ์ที่ได้: Email, Slack, CRM (สิทธิ์ระดับ user), ระบบเบิกค่าใช้จ่าย. ใช้งานทุกระบบทุกวัน. ทุกอย่างเหมาะสม

ปีที่ 2 — Mr.D ย้ายแผนกไป Marketing. บริษัทเห็นว่า Mr.D เก่งเรื่อง storytelling ลูกค้า — ย้ายไปทำ content marketing. สิทธิ์เพิ่ม: Marketing tools (HubSpot Marketing Hub, Hootsuite, Canva Pro), Analytics dashboard, ระบบ approve content. แต่สิทธิ์เก่าใน Sales? — ยังอยู่. ไม่มีใครเอาออก เพราะ “เผื่อต้องกลับมาช่วย Sales”

ปีที่ 3 — Mr.D ย้ายไป Finance. ทำ financial planning + budget allocation. สิทธิ์เพิ่ม: ERP (สิทธิ์ Finance Analyst), ระบบทำงบประมาณ, ระบบดู P&L รายแผนก, ระบบ approve PO. สิทธิ์ใน Marketing? — ยังอยู่. ใน Sales? — ยังอยู่. รวมแล้ว Mr.D มีสิทธิ์ของ 3 แผนกซ้อนกัน

ปีที่ 4 — Mr.D เลื่อนเป็น Finance Manager. สิทธิ์เพิ่ม: Executive dashboard ของ Board, ระบบ approve งบใหญ่, สิทธิ์ admin ของ ERP บางส่วน. รวม 4 ปี — Mr.D สะสมสิทธิ์ของ 4 ตำแหน่งซ้อนกัน + executive level

ทีนี้คำถามครับ — Mr.D ใช้สิทธิ์ของ Sales จากปีที่ 1 ครั้งสุดท้ายเมื่อไหร่? คำตอบที่น่าจะตรง — 2 ปีที่แล้ว ตอนกลับไปช่วย Sales 1 ครั้ง. หลังจากนั้น Mr.D ไม่เคย login CRM อีกเลย. แต่ account ของ Mr.D ใน CRM ยังเปิดอยู่ — และมีสิทธิ์ดูข้อมูลลูกค้าทั้งบริษัท

ทำไม Privilege Creep อันตราย — blast radius#

ทีนี้คำถามที่ผู้บริหารต้องคิดครับ — ถ้า account ของ Mr.D โดน compromise วันนี้ — โจรได้อะไร?

คำตอบที่น่ากลัวคือ — โจรได้กุญแจของ 4 แผนกพร้อมกัน. โจรจะ:

• เข้า CRM → ดาวน์โหลด customer database 50,000 รายชื่อ + ประวัติการซื้อ
• เข้า Marketing tools → ดาวน์โหลด email list ของลูกค้า + ตั้ง campaign หลอกในนาม Mr.D
• เข้า ERP Finance → ดูข้อมูลการเงินทั้งบริษัท + ดู P&L ของแผนกทุกแผนก
• เข้า Executive dashboard → ดู strategy ของ Board

วงการเรียกพื้นที่ที่โจรเข้าถึงได้ผ่าน 1 account ว่า blast radius (รัศมีการระเบิด). Account ที่มี privilege creep มี blast radius ที่บานเกินจำเป็นมาก — โจรเข้ามา 1 ครั้ง = ได้ข้อมูลของ 4 แผนกพร้อมกัน

ถ้าเป็น Mr.D ที่เพิ่งย้ายมา Finance ใหม่ + ไม่มีสิทธิ์ของ Sales / Marketing / executive ค้าง — โจรเข้ามาเดียวกัน = ได้ข้อมูล Finance อย่างเดียว. blast radius เล็กลง 4 เท่า

Stat ที่บริษัทไทยต้องรู้#

จากรายงาน access review ของบริษัทที่ปรึกษา security ระดับโลก (Microsoft, Varonis, SailPoint) — pattern ที่ออกมาตรงกันคือ พนักงานที่ทำงานในบริษัทเดียวมามากกว่า 3 ปี มักมีสิทธิ์เกินที่ใช้จริง 3-5 เท่า

หมายความว่ายังไง? — ถ้าทำ audit สิทธิ์ของพนักงานคนหนึ่ง แล้วถามว่า “สิทธิ์ใน list นี้ — คุณใช้ตัวไหนใน 90 วันที่ผ่านมาบ้าง?” — คำตอบจะอยู่ที่ 20-30% ของ list. อีก 70-80% เป็นสิทธิ์ที่ไม่ได้ใช้ — แต่ยังเปิดอยู่ — และเป็น blast radius ที่บานเปล่าๆ

นี่ไม่ใช่ปัญหาของบริษัทไทยอย่างเดียวครับ. การศึกษาในวงการระดับโลก (เช่น Microsoft, Varonis report ต่างๆ) ทุกตัวชี้ตรงกันว่า — บริษัททั่วโลกมีสิทธิ์ที่ใช้จริงต่ำกว่าสิทธิ์ที่เปิดไว้ 50-70%. ความเสี่ยงนี้เป็น universal — ไม่ใช่ปัญหาเฉพาะถิ่น. แต่บริษัทไทยมักรุนแรงกว่าเพราะ culture ของไทยไม่ค่อยถอดสิทธิ์ — รู้สึกเหมือนเป็นการลดสถานะของพนักงาน

ทางแก้ — Mover process ที่มี Permission Reset#

ทางแก้ที่ดีที่สุดของ Privilege Creep คือ — ตอนพนักงานย้ายแผนก = reset permission กลับมาที่ template ของตำแหน่งใหม่ ไม่ใช่เพิ่มสิทธิ์ใหม่บนของเก่า

ขั้นตอน Mover process ที่ดี:

1. HR แจ้ง IAM ว่าพนักงานจะย้ายแผนก (พร้อมระบุวันที่)
2. IAM ดูสิทธิ์ปัจจุบันของพนักงาน + ดูสิทธิ์ของ role ใหม่
3. IAM ทำ “diff” — เห็นว่าสิทธิ์ตัวไหนต้องเพิ่ม, ตัวไหนต้องเอาออก
4. ก่อนวันย้าย — manager เก่า + manager ใหม่ + พนักงาน ดู diff ร่วมกัน — confirm
5. วันย้าย — IAM execute diff อัตโนมัติ → เอาสิทธิ์เก่าออก + เพิ่มสิทธิ์ใหม่

ผลคือ — พนักงานที่ทำงานในบริษัทมา 10 ปี + ย้ายแผนกมา 5 รอบ จะมีสิทธิ์ที่ ตรงกับงานปัจจุบัน — ไม่ใช่ผลรวมของทุกตำแหน่งที่เคยอยู่

Hard case — พนักงานที่ทำหลายบทบาทพร้อมกัน#

ผมต้องเตือนครับว่ามี edge case ที่ไม่ง่าย — พนักงานบางคนทำหลายบทบาทพร้อมกันจริงๆ. เช่น ใน SME ที่คนน้อย — คนหนึ่งคนทำ Sales + Marketing + Customer Service พร้อมกัน. ในกรณีนี้ การ reset เป็น role เดียวจะไม่ work

ทางแก้คือ — ระบบ IAM ที่ดีต้องรองรับ multi-role assignment — assign ให้พนักงานหนึ่งคนมีได้หลาย role พร้อมกัน + ทุก role มี start date + end date. ถ้าวันหนึ่งบริษัทโตขึ้น มี Sales เต็มเวลาแล้ว → ถอด role Sales ของพนักงานคนเดิมออก. ระบบไม่งง

มุมผู้บริหาร: คำถามที่จะเปลี่ยนวิธีคิดเรื่อง Mover ของบริษัทคุณครับ — “ครั้งล่าสุดที่คุณเซ็นย้ายพนักงานคนหนึ่งจากแผนกหนึ่งไปอีกแผนก — ใครเป็นคนตัดสินใจว่า access เก่าจะถูกเอาออกหรือเก็บไว้?” ในบริษัทไทยส่วนใหญ่ — คำตอบคือ “ไม่มีใคร” — เพราะคำถามนี้ไม่เคยถูกตั้ง. ผมแนะนำให้คุณเพิ่ม 1 บรรทัด ในเอกสารอนุมัติย้ายพนักงาน — “Access เก่าที่ต้องเอาออก: ___ / Access ใหม่ที่ต้องเพิ่ม: ___ / Access เก่าที่ต้องเก็บไว้ (พร้อมเหตุผล): ___”. แค่บรรทัดเดียวนี้ — ทำให้ Mover process เปลี่ยนจาก “ไม่มีใครคิด” เป็น “ทุกคนต้องคิด”. Privilege Creep จะลดลง 60-70% โดยไม่ต้องลงทุน tool เพิ่มเลย

ภาพแย่ที่เป็น pattern คลาสสิคของวงการ#

ผมขอเล่าเป็น scenario ที่หลายคนรายงานในวงการครับ — เป็น pattern ที่ ISACA และนักวิจัย security ใช้สอนเรื่อง orphan account บ่อยที่สุด. ลองนึก scenario นี้ — สมมติพนักงานคนหนึ่ง (ขอเรียกว่า Mr.E) ทำงานบริษัท IT ขนาดกลางในกรุงเทพ ตำแหน่ง System Engineer. เขาลาออกตามขั้นตอนปกติ — ส่ง resignation letter, ทำงานต่อ 1 เดือน, hand-over งานให้คนใหม่, คืน laptop + บัตรพนักงานในวันสุดท้าย, signature ในเอกสาร exit interview. ทุกอย่างเรียบร้อย

วันสุดท้าย — Mr.E รู้สึกประหลาดใจเล็กน้อยที่ HR ไม่ได้บอกอะไรเรื่อง account ของบริษัท. เขาคิดในใจ — “เดี๋ยว IT คงปิดเอง”. กลับบ้าน. ขึ้นงานใหม่. ลืมเรื่องบริษัทเก่าไป

6 เดือนต่อมา — Mr.E เปิด laptop ส่วนตัวที่บ้าน. เห็น VPN client ที่เคย install ตอนทำงานบริษัทเก่า — ลืมถอน. ลองกด connect เล่นๆ. ใส่ username + password เดิม ของบริษัทเก่า. — connect ติด. เข้า internal network ของบริษัทเก่าได้

Mr.E ตกใจครับ. ในสมมติฐานนี้ เขาไม่ใช่คนที่อยากทำอะไรไม่ดี — แค่อยากทดลอง. แต่ลองคิดต่อ — ถ้า Mr.E เป็นคนที่ไม่ดี — หรือถ้าเครื่อง laptop ของเขาโดน malware ที่ขโมย credential ของบริษัทเก่าไปแล้ว — บริษัทเก่าไม่มีทางรู้เลยว่ามีคนข้างนอกที่ยังเข้าระบบของเขาได้

Mr.E โทรหา IT บริษัทเก่า — บอก “ผมยัง login VPN ได้นะครับ ปิด account ผมหน่อย”. IT ตอบ — “อ้าว — ลืมครับ — ปิดให้เลย”. จบ. 6 เดือนของ orphan account จบลงด้วยโทรศัพท์ 1 สาย

นี่ไม่ใช่เคสที่หายากครับ. ในบริษัทไทยที่ไม่มี Leaver process ที่เป็นทางการ — เกือบทุกบริษัทมี orphan account ค้างอยู่ — ปริมาณมากน้อยขึ้นกับขนาด

Deprovisioning — Disable, อย่าลบ#

Deprovisioning = process ที่ตรงข้ามกับ Provisioning — ปิด account ของพนักงานในทุกระบบ ในวันสุดท้ายที่พนักงานทำงาน

จุดที่ subtle ที่บริษัทไทยมักเข้าใจผิด — คำว่า “ปิด” ในที่นี้ = disable. ไม่ใช่ delete

• Disable = ปิดไม่ให้ login ได้ — แต่ data ของ account + log activity ทั้งหมดยังอยู่
• Delete = ลบ account ทิ้งหมด — data หาย, log หาย, ไม่มีร่องรอย

ทำไมต้อง disable ไม่ใช่ delete? — 3 เหตุผล:

เหตุผลที่ 1 — Forensic investigation. ถ้าหลังพนักงานออกไป — 3 เดือนต่อมามีเหตุการณ์ data leak เกิดขึ้น — ทีม security ต้องสามารถย้อนดู log ของพนักงานคนนั้นได้ ว่าก่อนออกได้ทำอะไรในระบบบ้าง. ถ้า account ถูก delete = log หาย = investigate ไม่ได้

เหตุผลที่ 2 — Email forwarding + business continuity. ถ้าพนักงาน Sales ออก — ลูกค้าของเขายังเคยส่ง email มาที่ email ของเขาอยู่. บริษัทต้อง forward email มาที่คนใหม่ที่รับช่วงงาน. ถ้า delete email = ลูกค้าได้ bounce-back = เสียลูกค้า

เหตุผลที่ 3 — Audit trail สำหรับ regulator. ในบริษัทที่อยู่ภายใต้ regulation (เช่น SOX, PDPA) — มี requirement ให้เก็บ log ของ user activity เป็นระยะเวลาหนึ่ง (ปกติ 1-7 ปี). ถ้า delete account ทันที = log ของ activity เก่าหาย = ไม่ compliant

ทาง best practice คือ — Disable ทันทีในวันสุดท้าย → เก็บ disabled state ไว้ 1-2 ปี → ค่อย archive → ค่อยลบหลังหมดอายุ retention

Leaver Checklist — รายการที่ต้อง revoke#

ทีนี้คำถามคือ — มีอะไรบ้างที่ต้องปิด/คืน ในวันสุดท้าย?. ผมขอ list ที่บริษัทไทยมักลืมเป็นข้อๆ ครับ:

Digital access:

• Email account (disable + forward ไปที่ manager)
• Active Directory / Entra ID account
• VPN access
• Slack / Teams / Zoom
• Google Drive / SharePoint / OneDrive
• CRM (Salesforce, HubSpot, ฯลฯ)
• ERP (SAP, Oracle, ฯลฯ)
• HR self-service
• ระบบเงินเดือน (เก็บ read-only แต่ปิด edit)
• SaaS subscriptions ทุกตัว (Figma, Notion, GitHub, Adobe, ฯลฯ)
• API keys + access tokens (สำหรับ developer / DevOps — ตัวที่ลืมบ่อยที่สุด)
• SSH keys + service account credential ที่ผูกกับชื่อพนักงาน

Physical access:

• บัตรพนักงาน (เข้าออฟฟิศ)
• Key card / fob (เข้าห้อง server, ห้อง confidential)
• Laptop + accessories
• Mobile phone ของบริษัท
• 2FA hardware token (YubiKey, RSA token)

Third-party access:

• ลบชื่อพนักงานออกจาก vendor portal ที่บริษัทใช้
• แจ้ง vendor ที่ contract direct กับพนักงาน (เช่น vendor ที่มี email ของเขาเป็น primary contact) — เปลี่ยน contact

Soft items:

• เปลี่ยน password ของ shared account ที่พนักงานรู้ (เช่น admin password ของระบบ social media ของบริษัท)
• Review ของ commit หรือ deployment ที่พนักงานทำในระยะ 30 วันสุดท้าย — เช็คว่ามี backdoor หรือ unauthorized change ไหม
• ปิด GitHub / GitLab / Bitbucket access

ลองนับดู — ทั้งหมด 20+ รายการ. ถ้าทำด้วยมือ + ไม่มี checklist + ไม่มี HR + IT shared ownership = ลืมแน่นอน. และพอลืม → เกิด orphan account

Orphan Account — ผีในระบบ#

Orphan Account (บัญชีกำพร้า) = account ที่ยังเปิดอยู่ในระบบ — แต่ไม่มีคนรับผิดชอบ

3 sources หลักของ orphan account:

1. พนักงานออกไป — แต่ account ไม่ถูกปิด (เคส Mr.E ที่เพิ่งเล่า)
2. Service account ของระบบเก่าที่เลิกใช้แล้ว — ระบบเก่าโดน decommission ไป 2 ปีแล้ว แต่ service account ที่เคยใช้ยังเปิดอยู่
3. Vendor account ที่หมดสัญญา — vendor ที่เคย contract กับบริษัท ทำโครงการเสร็จ ลาออกแล้ว — แต่ admin account ที่บริษัทสร้างให้ vendor เข้าระบบยังเปิดอยู่

ทำไม orphan account อันตราย? — เพราะมันคือประตูที่บริษัทไม่รู้ว่ามี. ไม่มีใครเฝ้า (เพราะไม่รู้ว่ามี). ไม่มีใคร rotate password (เพราะไม่รู้ว่าเป็นของใคร). ไม่มีใคร enable MFA (เพราะไม่มีคนเป็นเจ้าของ). โจรเข้าผ่าน orphan account = เข้าได้ลับๆ เป็นเดือนๆ หรือเป็นปีๆ โดยไม่มีใครเห็น

Real case — Tesla 2018#

ขอเล่าเคสจริงที่ทำให้วงการตื่นเรื่อง Leaver process — Tesla 2018

ในเดือนมิถุนายน 2018 Tesla ค้นพบว่าพนักงานคนหนึ่งของบริษัท Martin Tripp (Process Technician) ได้พยายาม sabotage ระบบการผลิตของ Tesla รายละเอียดของเคสนี้ Elon Musk ส่ง email ทั่วบริษัทบอกว่า — Tripp ได้แก้ code ของระบบ Manufacturing Operating System (MOS) แล้ว export ข้อมูล sensitive จำนวนมาก ไปให้บุคคลที่สาม

จุดสำคัญของเคสนี้สำหรับ EP ของเราคือ Tripp ทำสิ่งเหล่านี้ “ในช่วงที่เขายังเป็นพนักงานอยู่” แต่หลังจากที่เขาเพิ่งโดน demote จากตำแหน่งที่เขาคิดว่าควรได้ หมายความว่า insider ที่กำลังจะกลายเป็น leaver ยังมี access เต็มที่ ในช่วงที่เขามี motive ที่จะทำร้ายบริษัท

เคส Tesla ทำให้วงการเข้าใจว่า — risk ของ Leaver ไม่ได้เริ่มในวันสุดท้าย — มันเริ่มในวันที่พนักงานเริ่มไม่พอใจ. และ best practice ใหม่ที่หลายบริษัทเริ่มทำหลัง Tesla คือ — เมื่อพนักงานยื่นใบลาออก → เปลี่ยน access ของเขาเป็น “monitoring mode” ทันที — ยังทำงานได้ปกติ แต่ทุก activity ถูก log + alert ถ้าทำอะไรผิดปกติ (เช่น download data จำนวนมาก, copy ไฟล์ออก USB, forward email หลาย thread ออก)

Real case — Twitter 2020 (กลับมาอีกครั้ง)#

ผมขอกลับมาที่ Twitter 2020 อีกครั้งครับ — เพราะมี dimension ของเคสนี้ที่เกี่ยวกับ Leaver ที่ผมไม่ได้พูดในช่วงต้น EP

การ social engineering ที่ใช้หลอกพนักงาน Twitter — ส่วนหนึ่งของข้อมูลที่โจรใช้ → มาจาก “อดีตพนักงาน Twitter” ที่ขายข้อมูลเชิงโครงสร้างของระบบภายใน + ชื่อ + ตำแหน่งของพนักงาน support — ใน dark forum

หมายความว่า — risk ของ Leaver ไม่จบในวันสุดท้าย — มันต่อเนื่องไปอีกหลายเดือนหรือหลายปี. อดีตพนักงานที่ออกไปด้วยความขมขื่น = threat vector ที่ใช้ได้นาน สำหรับโจรที่ social engineer พนักงานที่ยังอยู่. นี่คือเหตุที่บริษัท security-mature เริ่มทำ exit interview ที่มี security component — บอกอดีตพนักงานชัดเจนว่ามี NDA + อะไรพูดได้/ไม่ได้ + แม้ออกไปแล้วยังมี obligation ทางกฎหมาย

มุมผู้บริหาร: ผมอยากให้คุณตอบคำถามตัวเอง 1 ข้อเงียบๆ ครับ — “ในบริษัทคุณ — มี shared checklist ระหว่าง HR + IT ที่ทำให้ในวันสุดท้ายของพนักงานทุกคน account ถูกปิด 100% ครบทุก system หรือไม่?” ถ้าตอบ “ไม่มี” — ผมแทบรับประกันได้ว่าบริษัทคุณมี orphan account ค้างอยู่. อาจจะ 5 บัญชี อาจจะ 50 บัญชี — แต่มีแน่นอน. คำแนะนำของผมคือ — ในประชุมถัดไป สั่งให้ HR + IT ร่วมกันสร้าง “Leaver Checklist” ที่มี 20+ รายการ + ตั้งเป้าให้ใช้กับพนักงานที่ออกในเดือนถัดไปทุกคน + รายงานผลในประชุมถัดไป. ค่าใช้จ่ายในการทำ checklist = ใช้เวลา HR + IT รวม 2-3 ชั่วโมง. ป้องกัน breach 1 ครั้ง = หลายล้านบาท. ROI ที่ดีที่สุดในวงการ security คือเรื่องนี้

Account Reviews — ตรวจรอบสั้น#

Account Reviews (การทบทวนบัญชี) = process ที่ manager นั่งดู รายชื่อลูกน้องของตัวเอง + รายการ access ที่ลูกน้องแต่ละคนมี — เป็นรอบ. ปกติทุก 3-6 เดือน

ในการ review แต่ละครั้ง — manager ตอบคำถาม 3 ข้อสำหรับ access แต่ละตัวของลูกน้องแต่ละคน:

1. ยังต้องใช้ — สิทธิ์นี้ยังจำเป็นสำหรับงานของลูกน้องคนนี้ → keep
2. ไม่ใช้แล้ว — สิทธิ์นี้ไม่ต้องการแล้ว → revoke
3. ไม่รู้จัก — manager ไม่รู้ว่าทำไมลูกน้องมีสิทธิ์นี้ → escalate + investigate

คำตอบที่ 3 เป็นคำตอบที่สำคัญที่สุด — เพราะมันเป็น signal ว่า มีสิทธิ์ที่ไม่มีใครเข้าใจที่มาที่ไป. นี่คือ orphan permission ที่ Privilege Creep สร้างขึ้น

Account Review เป็น process ที่ เครื่องมือ IAM ส่วนใหญ่รองรับ built-in — Okta, Microsoft Entra ID, SailPoint, Saviynt ทุกตัวมี module นี้. ระบบจะส่ง email ให้ manager ทุก 3 เดือน — “กรุณา review access ของลูกน้อง 12 คน — กดปุ่ม approve/revoke”. Manager ใช้เวลา 30-60 นาทีก็เสร็จ

Recertification — sign-off ที่เป็นทางการรายปี#

Recertification (การรับรองสิทธิ์ซ้ำ) = ขั้นที่ใหญ่กว่า Account Review. เป็น formal sign-off ของ manager ทุก 12 เดือน — manager ต้อง เซ็นรับรองอย่างเป็นทางการ:

“ผม [ชื่อ manager] ยืนยันว่าลูกน้อง 12 คนต่อไปนี้ — มี access ตามรายการที่แนบ — ทั้งหมดเหมาะสมกับงานปัจจุบัน + ใช้ในระยะ 90 วันที่ผ่านมา”

ความแตกต่างระหว่าง Review กับ Recertification:

• Review = approval ทั่วไป, ระดับ operational
• Recertification = legal sign-off, ถ้าเซ็นแล้วเกิดปัญหา → manager รับผิดชอบ

นี่คือเหตุที่ Recertification เป็น process ที่ผู้บริหารต้องเข้าใจ — เพราะมันโอน accountability ไปที่ manager ผ่านการเซ็น. แต่ก็เพราะแบบนี้ — มันมักโดนทำ pro forma (เซ็นโดยไม่อ่าน)

กับดักของ Recertification — ทำเพราะต้อง ไม่ใช่เพราะต้องการ#

นี่คือ pattern คลาสสิคของวงการที่บริษัทไทยติดบ่อยที่สุดครับ — Recertification ที่ทำเพราะ regulator บังคับ ไม่ใช่เพราะอยากปลอดภัย

ภาพคลาสสิคที่ออกข้อสอบ CISA บ่อย:

• ถึงปลายปี — ระบบส่ง email ให้ manager 100+ คน — “กรุณา recertify access ของลูกน้อง — deadline: 15 ธันวาคม”
• Manager ที่ยุ่ง → เปิด email ใน 5 นาทีสุดท้ายก่อน deadline → กด “Approve All” โดยไม่อ่าน → submit
• ระบบบันทึก: “Manager X ได้ recertify ลูกน้อง 12 คน — เสร็จสมบูรณ์”
• Audit ปีหน้าผ่าน — เพราะมีหลักฐานเซ็น

ปัญหาคืออะไร? — Recertification ที่ทำแบบนี้ = check-the-box theater เหมือนที่เราคุยใน EP.09 เรื่อง compliance theater. ไม่มีใครได้ดูจริงๆ ว่า access ของลูกน้องเหมาะสมไหม. orphan permission ที่ควรถูกถอด → ถูก recertify แทน. Privilege Creep ที่ควรถูก reset → ถูก approve

เคล็ดลับที่ work — Recertification ผูกกับโบนัส#

ทางแก้ที่ work ในบริษัทระดับโลกครับ (มี case study จาก SailPoint และนักวิจัย identity governance ออกมาเล่า) — ทำให้ Recertification เป็น mandatory เพื่อจ่ายโบนัสประจำปีของ manager

หมายความว่า — ถ้า manager ไม่ recertify ลูกน้อง 100% ภายใน deadline → โบนัสประจำปีของ manager ระงับ จนกว่าจะ recertify ครบ. และ — ถ้า audit รอบหน้าเจอว่า recertify แบบ “Approve All” โดยไม่ได้ตรวจจริง → manager โดน performance review hit + อาจกระทบ promotion

ผลคือ — manager เริ่มใส่ใจ. เพราะ recertify ผิดพลาด = กระทบเงินในกระเป๋าตัวเอง

มีบริษัท financial services ในไทยที่ใช้วิธีนี้ — อัตรา “Approve All blind” ลดจาก 80% เหลือ 12% ใน 1 ปี. และ orphan permission ในบริษัทลดลง 60% ในปีเดียวกัน. Incentive alignment ทำงานเสมอ — ถ้าผูก security กับเงินที่ manager สนใจ = manager จะสนใจ security

Vendor — IAM Governance Platforms#

ผู้เล่นในวงการ Account Review + Recertification ที่เด่นๆ มี 2 ตัว:

• SailPoint — vendor ที่ใหญ่ที่สุด focus ที่ identity governance. บริษัทใหญ่ในอเมริกาส่วนใหญ่ใช้. ราคา enterprise — $100,000+ ต่อปี
• Saviynt — competitor หลักของ SailPoint. focus ที่ cloud-first companies. ราคาใกล้เคียง

ทั้ง 2 ตัวเป็น IAM Governance Platforms — แยกจาก IAM operational tool (Okta, Entra ID) ที่ทำเรื่อง authentication + provisioning. Governance platforms เน้นเรื่อง — review, recertification, segregation of duties, compliance reporting

สำหรับบริษัทเล็ก-กลาง — feature governance ของ Okta หรือ Entra ID มักเพียงพอ ไม่ต้องซื้อ governance platform แยก. แต่บริษัทขนาดใหญ่ที่อยู่ภายใต้ regulation หนัก (เช่น financial services, healthcare) มักลงทุน SailPoint หรือ Saviynt เพิ่ม

มุมผู้บริหาร: ในประชุมถัดไป ลองถาม CIO/CISO 2 คำถามครับ. คำถาม 1: “บริษัทเราทำ Account Review หรือ Recertification ไหม? ถ้าทำ — ทำเป็นรอบเท่าไหร่?” ถ้าตอบ “ทำปีละครั้ง” = baseline. ถ้าตอบ “ทำทุก 3-6 เดือน” = ดี. ถ้าตอบ “ไม่ได้ทำ” = ปัญหา. คำถาม 2: “อัตราการกด ‘Approve All’ ของ manager เราอยู่ที่เท่าไหร่?” ถ้าตอบ “ไม่รู้” = บริษัทไม่ track. ถ้าตอบ ”> 50%” = recertification ของบริษัทคุณเป็น theater. และคำถามต่อมาที่จะเปลี่ยนทุกอย่างคือ — “ถ้าเราผูก recertification เข้ากับโบนัส manager ปีหน้า — จะ work ไหม?”. คำตอบของบริษัทระดับโลกหลายเจ้า = work มาก

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

ข้อแรก — ถ้า HR + IT ไม่มี Leaver Checklist ที่ shared — บริษัทมี orphan account แน่ๆ

นี่เป็นข้อที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. ตามรายงานจาก auditor ในวงการ — เกือบทุกบริษัท ที่ไม่มี Leaver Checklist ที่เป็น shared document ระหว่าง HR กับ IT — มี orphan account ค้างอยู่. ปริมาณน้อยมากในบริษัทเล็ก (อาจจะ 3-5 บัญชี). มหาศาลในบริษัทใหญ่ที่มี turnover เยอะ (อาจจะหลายร้อยบัญชี)

วิธีตรวจง่ายๆ ที่ใช้กันทั่วไปในวงการ — ขอ list ของ user account ทั้งหมดในระบบ → join กับ HR roster ของพนักงานปัจจุบัน → ดู diff. เป็น pattern คลาสสิคที่ใช้ใน access review — แทบทุกครั้งจะเจอ account ในระบบที่ไม่มีใน HR. นั่นคือ orphan account. และเกือบทุกครั้งบริษัทจะตกใจว่า “เอ๊ะ เราไม่รู้ว่ามีเยอะขนาดนี้”

แค่ 1 step เริ่มต้น — ใช้เวลา 1 วัน + คน 2 คน (HR analyst + IT admin) + เอกสาร Excel 1 ใบ — ทำให้บริษัทคุณเห็น orphan account ที่ค้างอยู่ทั้งหมด. ลงทุนน้อยที่สุดในวงการ security ที่ ROI สูงที่สุด

ข้อสอง — Recertification ปีละครั้ง = ฮีโร่ของบริษัทที่อยู่นาน

บริษัทที่ทำธุรกิจมานาน 10-20 ปี — มีพนักงานที่อยู่มานานเฉลี่ย 5-10 ปี — เป็นบริษัทที่ Privilege Creep รุนแรงที่สุด. เพราะแต่ละคนสะสมสิทธิ์ของหลายตำแหน่งซ้อนกัน. และเพราะ culture ของไทยไม่ค่อยถอดสิทธิ์ — สิทธิ์เก่าค้างอยู่นาน

Recertification ที่ทำจริง (ไม่ใช่ที่ผ่านพิธี) เป็น single ปฏิบัติการที่จะลด Privilege Creep มากที่สุด. และผมเสนอให้ผู้บริหารทำ 3 อย่างเริ่มต้น:

1. ตั้ง Recertification cycle รายปี — เริ่มที่ปีนี้
2. ผูก Recertification เข้ากับโบนัส manager — ถ้าไม่ทำ = ไม่ได้โบนัส
3. Track อัตรา blind-approve — เป้าหมาย < 20% ภายใน 2 ปี

3 ข้อนี้ — ไม่ต้องลงทุน tool ใหม่. ใช้ tool ที่มีอยู่แล้ว (Okta หรือ Entra ID หรือแม้แต่ Excel). ใช้วินัยของ HR + Finance ในการผูก recertification เข้ากับโบนัส. ผลในปีที่ 2 — orphan permission ลด 60-70%. และเมื่อ Privilege Creep ลด = blast radius ของทุก account ลด = ถ้าโจรเข้าได้ 1 account = ความเสียหายลดทันที