Access Review สำหรับทีมเล็ก: เปิดรายชื่อแล้วตอบ 4 คำถาม

Access Review คือการทบทวนเป็นระยะว่า ใครยังควรเข้าระบบใด และควรทำอะไรในระบบนั้นได้บ้าง ผลลัพธ์ที่ต้องการไม่ใช่รายชื่อผู้ใช้ที่ดูเรียบร้อย แต่คือการคงสิทธิ์ที่ยังจำเป็น ลดสิทธิ์ที่กว้างเกินงาน ถอนสิทธิ์ที่หมดเหตุผล และมอบหมายคนหาคำตอบให้บัญชีที่ยังไม่ชัด

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

รอบแรกไม่ต้องครอบคลุมทุกแอป ให้เลือกระบบสำคัญ 3–5 ตัว เปิดรายชื่อบัญชี แล้วใช้คำถามสี่ข้อเพื่อตัดสินใจให้จบว่าใครต้องคง ลด ถอน หรือกลับไปตรวจเพิ่ม วิธีนี้ช่วยให้ทีมลงมือแก้สิทธิ์จริงได้โดยไม่ต้องรอเครื่องมือราคาแพงหรือแบบฟอร์มขนาดใหญ่

ลองใช้วิธีนี้กับทีมสามคนที่เปิดรายชื่อผู้ใช้ช่วงปลายไตรมาส แล้วพบสามเรื่องพร้อมกันครับ ผู้รับจ้างที่จบโครงการไปสองเดือนยังเปิดโฟลเดอร์เดิมได้ บัญชี support@ ถูกใช้ร่วมกันจนตอบไม่ได้ว่าใครเปลี่ยนค่าอะไร และใน SaaS อีกตัว ทุกคนเป็นผู้ดูแลระบบเพราะตอนเริ่มใช้ยังไม่มีเวลาจัดสิทธิ์ให้ละเอียด ทั้งสามบัญชีทำงาน “ปกติ” แต่ต้องการการตัดสินใจคนละแบบ

เริ่มจากระบบที่ถ้าสิทธิ์ผิดแล้วกระทบงาน

ข้อผิดพลาดที่ทำให้รอบแรกไม่จบคือพยายามตรวจทุกบัญชีในทุกบริการพร้อมกัน รายชื่อยาวขึ้นเรื่อย ๆ แต่ทีมหมดเวลาก่อนถอนสิทธิ์แม้แต่บัญชีเดียว

ผมแนะนำให้เริ่มจากระบบสำคัญเพียง 3–5 ตัว เช่น อีเมล พื้นที่เก็บไฟล์ ระบบบัญชี ที่เก็บ source code และระบบ production เลือกระบบที่ถ้าคนผิดคนเข้าถึงแล้วจะกระทบข้อมูล เงิน ลูกค้า หรือการให้บริการอย่างชัดเจน

จากนั้นดึงรายชื่อผู้ใช้ของแต่ละระบบออกมาเท่าที่ทำได้ รายชื่อไม่ต้องสมบูรณ์ตั้งแต่รอบแรก แต่ควรแยกให้เห็นบัญชีผู้ใช้ทั่วไป ผู้ดูแลระบบ บุคคลภายนอก และบัญชีที่ไม่มีใครแน่ใจว่าเป็นของใคร หากพบบัญชีของระบบอัตโนมัติหรือ integration ให้จดไว้ก่อนและหาเจ้าของภายหลัง อย่ารีบลบเพียงเพราะไม่มีคนเข้าใช้งานโดยตรง

NIST Cybersecurity Framework 2.0 ใช้หลักว่าควรให้สิทธิ์เท่าที่จำเป็นต่อหน้าที่และทบทวนสิทธิ์ตามความเหมาะสม พูดแบบง่ายคือ คนหนึ่งอาจยังต้องใช้ระบบ แต่ไม่ได้แปลว่ายังต้องเปิดได้ทุกส่วนหรือเป็นผู้ดูแลระบบตลอดไป

เปิดรายชื่อแล้วตอบเพียง 4 คำถาม

แทนที่จะเริ่มจากชื่อ role หรือศัพท์ security ให้หยิบบัญชีขึ้นมาทีละรายการ แล้วถามว่า:

1. บัญชีนี้เป็นของใคร: เป็นพนักงาน ผู้รับจ้าง บัญชีกลาง หรือระบบอัตโนมัติ และมีใครรับผิดชอบ
2. ยังต้องใช้เพื่อทำงานอะไร: ถ้าตอบไม่ได้ อย่าเพิ่งถือว่ายังจำเป็น ให้ระบุคนที่ต้องกลับไปหาคำตอบ
3. สิทธิ์กว้างเกินงานหรือไม่: ยังต้องเข้าทั้งระบบ หรือควรเหลือเพียงบางโครงการ บางโฟลเดอร์ หรือสิทธิ์ผู้ใช้ทั่วไป
4. หลังตัดสินใจ ใครต้องทำอะไรเมื่อไร: การประชุมยังไม่จบจนกว่าจะมีคนถอน ลด หรือยืนยันสิทธิ์และตรวจผล

คำตอบสุดท้ายมีได้สี่แบบ: คงไว้ ลดขอบเขต ถอนออก หรือพักไว้เพื่อหาคำตอบเพิ่มเติม ภาษาอังกฤษอาจเรียกว่า Keep, Reduce, Remove และ Investigate แต่ชื่อไม่สำคัญเท่าการไม่ปล่อยรายการที่ “ยังไม่รู้” ให้กลายเป็น “อนุมัติ” โดยอัตโนมัติ

ลองตัดสินใจจากสามบัญชีในสถานการณ์เดิม

ผู้รับจ้างที่จบงานแล้ว: ถอนสิทธิ์

ผู้รับจ้างรายนี้มีเหตุผลในการเข้าถึงโฟลเดอร์ตอนโครงการยังเดิน แต่เมื่อส่งมอบงานและหมดสัญญา เหตุผลนั้นก็หมดลงด้วย ทีมจึงควรถอนสิทธิ์ ตรวจว่าเข้าจากลิงก์หรือกลุ่มอื่นได้อีกหรือไม่ และบันทึกว่าใครตรวจผล

ประเด็นนี้ไม่ควรรอการประชุมรายไตรมาส หากรู้วันจบงานล่วงหน้า ควรกำหนดการปิดสิทธิ์ไว้ในขั้นตอน offboarding ตั้งแต่ต้น รอบรายไตรมาสมีไว้จับสิ่งที่กระบวนการปกติพลาด ไม่ได้มีไว้แทนการปิดบัญชีคนออก

บัญชี support@: หาคำตอบก่อน แล้วลดการใช้ร่วมกัน

เหตุผลที่ทีมใช้บัญชี support ร่วมกันอาจเข้าใจได้ ลูกค้าจำชื่อเดียว ทุกคนเห็นงาน และระบบเดิมอาจไม่รองรับผู้ใช้หลายคน แต่การแชร์รหัสผ่านทำให้บันทึกย้อนหลังชี้ได้เพียงว่าบัญชี support เป็นคนเปลี่ยนค่า ไม่ได้บอกว่าเป็นใคร

อย่าเริ่มด้วยคำสั่งว่า “ห้ามใช้บัญชีกลาง” ให้ถามก่อนว่าระบบรองรับ shared mailbox, queue หรือการมอบหมายงานให้ผู้ใช้รายบุคคลหรือไม่ ถ้ารองรับ ให้แต่ละคนใช้บัญชีของตัวเองแล้วแชร์เฉพาะงาน หากยังเลิกใช้บัญชีกลางไม่ได้ อย่างน้อยต้องมีเจ้าของ รายชื่อผู้ที่ได้รับอนุญาต วิธีใช้ MFA และขั้นตอนเปลี่ยนรหัสเมื่อสมาชิกทีมเปลี่ยน

ทุกคนเป็น Admin: ลดเฉพาะสิทธิ์ที่ไม่เกี่ยวกับงาน

คำถามที่ใช้ตัดสินไม่ใช่ “ไว้ใจคนนี้หรือไม่” แต่คือ “งานประจำของเขาต้องเปลี่ยนค่าระบบ เพิ่มผู้ใช้ หรือปิดบันทึกเหตุการณ์หรือไม่” คนทำบัญชีอาจต้องใช้ระบบบัญชีทุกวัน แต่ไม่จำเป็นต้องจัดการผู้ใช้และ billing นักพัฒนาอาจต้อง deploy งาน แต่ไม่จำเป็นต้องเป็นเจ้าของทั้ง organisation

ถ้ามี role ที่แคบกว่าและยังทำงานได้ ให้ลดสิทธิ์ลง แต่ไม่ควรลดจนไม่มีใครกู้ระบบหรือรับมือเหตุฉุกเฉินได้ ระบบสำคัญควรมีผู้ดูแลสำรองที่ป้องกันเหมาะสม แยกจากบัญชีใช้งานประจำ และมีเจ้าของชัดเจน

เรื่องไหนทำทันที เรื่องไหนรอตรวจเป็นรอบ

มีสองจังหวะที่ทำงานร่วมกันครับ จังหวะแรกเกิดเมื่อคนเข้าทีม ออกจากทีม เปลี่ยนหน้าที่ หรือจบโครงการ สิทธิ์ต้องเปลี่ยนตามเหตุการณ์นั้น ไม่ควรรอวันประชุม ส่วนการตรวจเป็นรอบมีหน้าที่หาเรื่องที่ไม่มีใครสังเกต เช่น สิทธิ์ชั่วคราวที่ไม่ถูกถอน คนย้ายงานภายใน หรือบัญชีที่ถูกสร้างนอกขั้นตอนปกติ

NCSC แนะนำกระบวนการสำหรับคนเข้า ย้ายบทบาท และออกจากองค์กร เพื่อให้สิทธิ์เปลี่ยนตามสถานะการทำงาน ขณะที่ CIS Control 5 ใช้การตรวจบัญชีผู้ใช้และผู้ดูแลอย่างน้อยรายไตรมาสเป็นแนวทางหนึ่ง รายไตรมาสจึงเป็นจุดเริ่มที่อธิบายได้ ไม่ใช่ตัวเลขตายตัว ระบบการเงินหรือ production อาจต้องตรวจถี่กว่า

รอบแรกใช้เวลาหนึ่งชั่วโมง แต่ต้องจบด้วยการเปลี่ยนจริง

กรอบเวลาง่าย ๆ สำหรับทีมเล็กคือใช้ช่วงแรกเลือกระบบและเตรียมรายชื่อ จากนั้นใช้เวลาส่วนใหญ่กับบัญชีที่เสี่ยงหรือไม่ชัด เช่น ผู้ดูแล บุคคลภายนอก บัญชีที่ไม่รู้จัก และบัญชีที่ไม่ได้ใช้นาน ช่วงท้ายมอบหมายงานให้คนถอน ลด หรือหาคำตอบ พร้อมกำหนดวันที่ตรวจซ้ำ

หลักฐานที่ต้องเก็บไม่จำเป็นต้องเป็น screenshot ทุกหน้า แค่ตอบได้ว่าตรวจระบบใด ใช้รายชื่อ ณ วันไหน ใครช่วยยืนยัน ตัดสินใจอย่างไร และการเปลี่ยนสิทธิ์เสร็จแล้วหรือยัง หากรายการหนึ่งยังหาคำตอบไม่ได้ ต้องมีเจ้าของและวันกลับมาตรวจ ไม่ปล่อยค้างแบบไม่มีกำหนด

สำหรับรอบแรก เป้าหมายไม่ใช่ทำ inventory ให้สวยหรือพิสูจน์ว่าระบบปลอดภัยทั้งหมด เป้าหมายคือปิดสิทธิ์ที่หมดเหตุผล ลดสิทธิ์ที่กว้างเกินงาน และทำให้รายการที่ยังไม่รู้มีคนรับผิดชอบ ถ้าทีมยังไม่มีข้อตกลงพื้นฐานเรื่อง owner, MFA และการปิดบัญชี Security Baseline สำหรับองค์กรเล็ก ใช้เป็นจุดเริ่มร่วมกับ แนวทางเลือก MFA ได้

เมื่อทำรอบแรกจบ ทีมควรเห็นการเปลี่ยนแปลงจริงอย่างน้อยหนึ่งหรือสองรายการ หากประชุมแล้วทุกบัญชียังอยู่เหมือนเดิมทั้งหมด สิ่งที่ควรถามไม่ใช่ว่าแบบฟอร์มครบหรือยัง แต่คือคนทบทวนมีข้อมูลและอำนาจพอตัดสินใจหรือไม่

อ่านต่อที่เกี่ยวข้อง

• Security Baseline สำหรับองค์กรเล็ก: ทำไมทีมเล็กก็ควรมีฉบับของตัวเอง
• Multi-Factor Authentication คืออะไร และควรเลือกใช้แบบไหนในทางปฏิบัติ

แหล่งข้อมูลอ้างอิง

• NIST Cybersecurity Framework 2.0
• CIS Control 5: Account Management
• NCSC: Identity and Access Management
• Microsoft Learn: Plan an Access Reviews Deployment