ปัญหา IAM ที่มองไม่เห็นในวันปกติ
เมื่อพนักงานย้ายทีม ผู้รับเหมาจบงาน หรือระบบใหม่เปิดใช้ บัญชีและสิทธิ์มักไม่เปลี่ยนตามทันที บางคนเก็บสิทธิ์จากบทบาทเดิม บัญชีคู่ค้าคงอยู่เกินสัญญา และบัญชีผู้ดูแลถูกใช้ทำงานประจำ เมื่อเกิดเหตุการณ์ ความยากไม่ได้อยู่แค่การหาว่าใครล็อกอิน แต่ต้องรู้ว่าใครมีสิทธิ์เข้าถึงอะไร ใครอนุมัติ และยังจำเป็นต่อหน้าที่หรือไม่
Identity and Access Management (IAM) คือความสามารถในการจัดการตัวตน การพิสูจน์ว่าเป็นใคร และการกำหนดว่าตัวตนนั้นทำอะไรได้บ้าง ครอบคลุมพนักงาน ผู้รับเหมา คู่ค้า ผู้ดูแลระบบ แอปพลิเคชัน และ service identity ไม่ใช่แค่การติดตั้ง single sign-on หรือซื้อระบบยืนยันตัวตน แต่เป็นการทำให้สิทธิ์สอดคล้องกับงานและความเสี่ยงตลอดวงจรชีวิต
เริ่มจากทำบัญชีตัวตนและระบบที่เข้าถึง
รวบรวมแหล่งตัวตนและระบบสำคัญก่อนเลือกเครื่องมือใหม่ ระบุระบบ HR หรือทะเบียนคู่ค้าที่เป็นแหล่งข้อมูลตั้งต้น ระบบ identity provider แอป SaaS ระบบภายใน โครงสร้าง cloud ฐานข้อมูล และบัญชี local ที่ไม่เชื่อมศูนย์กลาง จากนั้นจับคู่บัญชีกับบุคคลหรือเจ้าของที่รับผิดชอบ สถานะการจ้าง ทีม วัตถุประสงค์ และระดับสิทธิ์ที่มี
อย่าจำกัดการสำรวจไว้ที่บัญชีพนักงาน บัญชี service, API keys, automation, shared accounts และบัญชีฉุกเฉินมีผลต่อระบบมากและมักไม่มีผู้รับผิดชอบชัดเจน สำหรับแต่ละรายการให้บันทึกเจ้าของทางธุรกิจ เจ้าของทางเทคนิค เหตุผลที่ต้องมี วิธีเก็บ credential วันทบทวน และขั้นตอนยกเลิก หากไม่ทราบเจ้าของ ให้จัดเป็นความเสี่ยงที่ต้องแก้ ไม่ใช่ปล่อยไว้เป็นข้อยกเว้นถาวร
ออกแบบสิทธิ์ให้สัมพันธ์กับหน้าที่และความเสี่ยง
เริ่มจากบทบาทงานและกิจกรรมที่ต้องทำ ไม่เริ่มจากรายชื่อคนแล้วให้สิทธิ์ทีละระบบ สร้าง access package หรือ role สำหรับงานที่เกิดซ้ำ โดยระบุระบบ ข้อมูล และสิทธิ์ขั้นต่ำที่จำเป็น แยกสิทธิ์อ่าน แก้ไข อนุมัติ และดูแลระบบออกจากกัน เพื่อหลีกเลี่ยงการรวมอำนาจไว้กับบัญชีเดียวโดยไม่จำเป็น
Role-Based Access Control (RBAC) ช่วยจัดกลุ่มสิทธิ์ตามหน้าที่ แต่ไม่ควรสร้าง role จำนวนมากจนบริหารไม่ไหว หรือรวมคนที่มีความเสี่ยงต่างกันไว้ในชุดเดียว บางกรณีต้องเพิ่มเงื่อนไขตามบริบท เช่น สถานที่ อุปกรณ์ ความอ่อนไหวของข้อมูล เวลา หรือสถานะคำขอ การออกแบบที่ดีทำให้ผู้อนุมัติเห็นเหตุผลและผลกระทบของสิทธิ์ได้ ไม่ใช่ต้องเดาความหมายจากชื่อกลุ่มทางเทคนิค
จัดการวงจรชีวิตพนักงานและบุคคลภายนอก
ทำให้การรับเข้า เปลี่ยนบทบาท และออกจากองค์กรเป็นเหตุการณ์ที่กระตุ้นการเปลี่ยนสิทธิ์อย่างสม่ำเสมอ เชื่อมข้อมูลเริ่มงาน วันสิ้นสุดสัญญา หน่วยงาน ผู้บังคับบัญชา และตำแหน่งเข้ากับ workflow ขอสิทธิ์ เมื่อมีการย้ายทีม ให้ทบทวนทั้งการเพิ่มสิทธิ์ใหม่และการถอนสิทธิ์เดิม หากทำเพียงเพิ่ม สิทธิ์จะสะสมจนเกิด entitlement creep
ผู้รับเหมาและคู่ค้าควรมี sponsor ภายใน ขอบเขตระบบและข้อมูลที่อนุญาต วันหมดอายุ และวิธีต่ออายุที่ตรวจสอบได้ หลีกเลี่ยงบัญชีถาวรที่แชร์กันระหว่างทีม ให้ใช้ตัวตนเฉพาะบุคคลเมื่อทำได้ และจัดให้การสิ้นสุดสัญญาปิดบัญชีและ session ที่เกี่ยวข้องโดยอัตโนมัติในระบบความเสี่ยงสูง
ปกป้องบัญชีสิทธิ์สูงและตัวตนที่ไม่ใช่มนุษย์
บัญชีผู้ดูแลระบบมีผลกระทบสูงกว่าบัญชีทั่วไป จึงควรแยกบัญชีใช้งานประจำออกจากบัญชี admin ใช้การยืนยันตัวตนที่แข็งแรงตามความเสี่ยง จัดเก็บ credential ใน vault จำกัดเวลาการยกระดับสิทธิ์เมื่อเหมาะสม และบันทึก session ที่สำคัญ แนวทาง NIST Zero Trust ย้ำว่าไม่ควรเชื่อถือบัญชีหรืออุปกรณ์เพียงเพราะอยู่ในเครือข่ายหรือเป็นขององค์กร แต่ต้องประเมินตัวตนและสิทธิ์ก่อนเข้าถึงทรัพยากร
การยืนยันตัวตนหลายปัจจัย (MFA) เป็นมาตรการสำคัญ แต่ไม่ทดแทนการกำหนดสิทธิ์ขั้นต่ำ การปิดบัญชีเมื่อหมดความจำเป็น หรือการติดตามการใช้สิทธิ์ เลือก assurance ให้เหมาะกับประเภทผู้ใช้และทรัพยากร โดยเฉพาะผู้ดูแลระบบและระบบสำคัญ ควรพิจารณาวิธีที่ทนต่อ phishing สำหรับกรณีเสี่ยงสูง พร้อมวางทางกู้คืนบัญชีที่ไม่เปิดช่องให้ผู้โจมตีเลี่ยงการควบคุม
วางการอนุมัติและการทบทวนที่ทำได้จริง
คำขอสิทธิ์ควรระบุระบบ ข้อมูล บทบาท ระยะเวลา เหตุผลทางธุรกิจ และผู้รับผิดชอบการอนุมัติ เส้นทางอนุมัติแตกต่างได้ตามความเสี่ยง เช่น สิทธิ์อ่านข้อมูลทั่วไปอาจอนุมัติโดยผู้จัดการ ส่วนสิทธิ์เข้าถึงข้อมูลอ่อนไหวหรือสิทธิ์ admin ต้องผ่านเจ้าของข้อมูลหรือผู้ดูแลระบบที่กำหนด อย่าให้ทุกคำขอต้องผ่านคณะกรรมการเดียวจนงานล่าช้าและผู้ใช้หาทางเลี่ยง
ทบทวนสิทธิ์โดยแสดงข้อมูลที่ผู้อนุมัติเข้าใจ ได้แก่ ชื่อระบบ ความเสี่ยง วันที่ได้รับสิทธิ์ การใช้งานล่าสุด และเหตุผลที่ยังต้องใช้ แบ่งรายการเป็นชุดที่จัดการได้และให้เจ้าของรับรองหรือเพิกถอนอย่างชัดเจน หากไม่มีการตอบรับ ให้ยกระดับและตัดสินตามกติกาที่กำหนด ไม่ควรถือว่าความเงียบคือการอนุมัติ
แผนเริ่มต้น 90 วันและตัวชี้วัด
วัน 1–30 เลือกขอบเขตที่มีความเสี่ยงและผลกระทบชัด เช่น ระบบการเงิน ข้อมูลลูกค้า หรือบัญชีผู้ดูแล ทำ inventory แบบพอใช้ ระบุแหล่งข้อมูลตัวตน เจ้าของระบบ และช่องว่าง joiner-mover-leaver เก็บ baseline ของบัญชีค้าง สิทธิ์ admin และเวลาที่ใช้อนุมัติ จากนั้นตกลงหลักการและผู้มีอำนาจตัดสินใจร่วมกับธุรกิจ เทคโนโลยี และ security
วัน 31–60 ออกแบบ role หรือ access package สำหรับงานที่เกิดซ้ำ ปรับคำขอและการอนุมัติ ทดลองถอนสิทธิ์จากการย้ายทีมและจบสัญญา ทบทวนบัญชีผู้ดูแลกับ service account และทดสอบการกู้คืนเมื่อ MFA หรือ identity provider ใช้งานไม่ได้ ทดลองกับกลุ่มจำกัด เก็บเหตุที่ workflow ติดขัดและผลกระทบต่อการทำงานก่อนขยาย
วัน 61–90 เชื่อมเหตุการณ์ต้นทางให้เป็นอัตโนมัติในระบบที่พร้อม ขยาย access review ตามความเสี่ยง และจัดทำ dashboard ให้เจ้าของเห็นรายการค้างและข้อยกเว้น ตัวชี้วัดที่มีประโยชน์ ได้แก่ เวลาปิดบัญชีหลังสิ้นสุดงาน สัดส่วนสิทธิ์สูงที่มีเจ้าของ จำนวนบัญชีไม่มีเจ้าของ บัญชี inactive ที่ยังเปิดอยู่ อัตราคำขอที่อนุมัติครบหลักฐาน และเวลาที่ใช้ทำ access review
อ่านแนวทางอ้างอิง: NIST SP 800-63-4, NIST SP 800-207, CISA IAM Best Practices