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 + ความเสี่ยง + เครื่องมือที่ต่างกัน. และจากประสบการณ์ผม — บริษัทไทย ส่วนใหญ่ทำขั้น 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 = ความเสียหายลดทันที