พนักงานลาออกแล้วแต่ยังล็อกอิน Web App ได้? Checklist ปิดสิทธิ์และตรวจบัญชีเชื่อมต่อ

สถานการณ์ที่ต้องแก้: ปิดบัญชีแล้ว แต่สิทธิ์บางส่วนยังอยู่

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

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

กำหนดขอบเขตและเวลาตัดสิทธิ์ก่อนลงมือ

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

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

ตารางตรวจรับหกกลุ่มที่ต้องมีหลักฐาน

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

กลุ่มที่สาม API Key และ Refresh Token: ระบุเจ้าของและระบบปลายทาง ประเมินว่าเคยเปิดเผยแก่บุคคลหรือไม่ บันทึกการเพิกถอนหรือหมุนเวียนพร้อมผลทดสอบบริการ กลุ่มที่สี่ OAuth Grant และ Integration: ตรวจสิทธิ์ที่มอบให้แอปภายนอก รวมถึง Webhook และงานตามกำหนดเวลา

กลุ่มที่ห้า ทรัพย์สินงาน: โอนเจ้าของไฟล์ Dashboard งานอนุมัติ Repository และ Automation ให้ผู้รับผิดชอบใหม่ก่อนปิดบัญชีเมื่อจำเป็น กลุ่มที่หก Audit Trail: เก็บรหัสใบงาน เวลา ผู้ดำเนินการ ผู้ตรวจซ้ำ ผลลัพธ์ และข้อยกเว้นค้าง โดยไม่บันทึกรหัสผ่าน คุกกี้เซสชัน หรือค่าโทเค็นจริงลงในรายงาน

ลำดับปฏิบัติจริง: ก่อนถึงเวลา ระหว่างตัดสิทธิ์ และหลังตัดสิทธิ์

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

เมื่อถึงเวลาที่ได้รับอนุมัติ ให้ปิดการยืนยันตัวตนหรือบัญชีที่เกี่ยวข้องตามสถาปัตยกรรมจริง เพิกถอนเซสชันที่ระบบรองรับ ปิดหรือเปลี่ยนสิทธิ์ API Key และ Grant ที่เสี่ยง โดยประสานเจ้าของ Integration ก่อนหมุนเวียน Secret ที่ใช้ร่วมกัน

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

ตัวอย่างใบงานตรวจรับที่นำไปปรับใช้ได้

ตัวอย่างสมมติ: พนักงาน A สิ้นสุดสิทธิ์วันที่ 5 พฤศจิกายน เวลา 18:00 น. ระบบหลักคือ Web App ฝ่ายขาย และมีรายงานอัตโนมัติที่เชื่อม API เจ้าของงานกำหนดให้ปิดบัญชีหลักและเซสชันในเวลานั้น ส่วนคีย์ของรายงานต้องย้ายไปบัญชีบริการที่องค์กรควบคุมก่อนเพิกถอนคีย์เดิม

ในใบงานควรมีแถว ‘Web App / บัญชี A / ปิดแล้ว 18:02 / ผู้ดำเนินการ IT / ตรวจเซสชันเดิมไม่ผ่าน 18:06 / ผู้ตรวจรับเจ้าของระบบ’ และอีกแถว ‘API รายงาน / คีย์เดิมเพิกถอนแล้ว / งานตามกำหนดเวลาทำงานด้วยบัญชีใหม่ / ผู้ตรวจรับฝ่ายรายงาน’ เวลานี้เป็นเพียงตัวอย่าง ไม่ใช่ SLA หรือข้อบังคับสำหรับทุกองค์กร

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

วินิจฉัยกรณีอดีตพนักงานยังเข้าใช้งานได้

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

ถ้า Web App ใช้ไม่ได้แล้ว แต่ API ยังตอบกลับ ให้ตรวจ Personal Access Token, API Key และ Service Account ที่เคยมีสิทธิ์ ถ้าระบบภายนอกยังเข้าถึงข้อมูลได้ ให้ตรวจ OAuth Grant และการอนุญาตแบบเชื่อมต่อระหว่างระบบ ทุกสาเหตุต้องบันทึกผลก่อนแก้ หลังแก้ และผู้ตรวจซ้ำ โดยไม่เก็บข้อมูลลับลงในใบงาน

แบ่งหน้าที่ให้ชัด ไม่ให้คนปิดสิทธิ์ตรวจรับตัวเองทั้งหมด

HR ยืนยันข้อมูลการออกจากงานและเวลาที่มีผล หัวหน้างานรับรองว่าระบบและงานที่ต้องส่งต่อครบ เจ้าของระบบกำหนดผลที่ต้องตรวจรับ IT หรือผู้ดูแลตัวตนดำเนินการปิดสิทธิ์และเก็บหลักฐาน ส่วนผู้ตรวจรับอีกคนยืนยันผล โดยเฉพาะบัญชีที่เข้าถึงข้อมูลสำคัญหรือสิทธิ์ผู้ดูแล

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

เกณฑ์ปิดงานและข้อยกเว้นที่ยอมรับได้

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

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

คำถามที่พบบ่อย

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

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

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

ใครเป็นคนตรวจรับ? เจ้าของระบบหรือหัวหน้างานยืนยันว่าขอบเขตและการส่งต่องานครบ ส่วนผู้ดูแลระบบให้หลักฐานการตัดสิทธิ์ งานที่มีความเสี่ยงสูงควรมีผู้ตรวจสอบอิสระจากผู้ดำเนินการ

แหล่งอ้างอิงและอ่านต่อ

แนวคิดเรื่องการบังคับใช้สิทธิ์อ้างอิง OWASP Authorization Cheat Sheet และการจัดการเซสชันอ้างอิง OWASP Session Management Cheat Sheet ส่วนหลักการยืนยันตัวตนดู NIST SP 800-63B เอกสารเหล่านี้เป็นกรอบแนวคิด ไม่ใช่หลักฐานว่าระบบใดระบบหนึ่งผ่านการตรวจมาตรฐาน

หากกำลังออกแบบสิทธิ์ตั้งแต่ต้น อ่าน Permission Matrix สำหรับระบบหลังบ้าน และการส่งต่องานดูแล Web App หรือดู บริการพัฒนา Web App เพื่อประเมินการออกแบบสิทธิ์และการตรวจรับให้เหมาะกับงานจริง