ใครถือกุญแจบัญชี Cloud ขององค์กรอยู่จริง: จัดการสิทธิ์เข้าถึงเมื่อทีมพัฒนาเปลี่ยนมือ

เดือนที่นักพัฒนาหลักของโครงการลาออก ทีมที่เหลือมักถามคำถามเดียวกันสองข้อพร้อมกัน คนคนนั้นยังเข้าบัญชี Google Cloud ของบริษัทได้อยู่หรือไม่ และมีใครรู้บ้างว่าเขาเคยสร้าง service account หรือ API key อะไรทิ้งไว้ระหว่างทาง คำถามแบบนี้ไม่ได้เกิดเฉพาะตอนพนักงานลาออก แต่เกิดซ้ำทุกครั้งที่สัญญากับ vendor ผู้พัฒนาระบบหมดอายุ หรือทีม outsource ย้ายไปรับงานที่อื่น จุดเปลี่ยนมือเหล่านี้คือช่วงเวลาที่สิทธิ์เข้าถึงหลุดออกจากสายตาคนดูแลได้ง่ายที่สุด เพราะไม่มีใครกำหนดไว้ล่วงหน้าว่าการเพิกถอนสิทธิ์เป็นหน้าที่ของใคร

ไม่มีใครนัดวันตรวจสิทธิ์ที่ไม่มีใครจำได้ว่าเคยให้ไป

จุดเปลี่ยนมือคือจุดที่สิทธิ์เข้าถึงหลุดจากการตรวจสอบ

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

ลำดับการเพิกถอนสิทธิ์ที่ควรทำเมื่อมีคนออกจากโครงการ

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

• ตรวจสอบและปิดหรือหมุนเวียน service account และ API key ที่คนนั้นสร้างหรือดูแลอยู่ก่อน เพราะ service account มักไม่ผูกกับ MFA และถูกมองข้ามในการตรวจสอบประจำวัน เอกสารแนวปฏิบัติของ Google Cloud แนะนำให้ปิดการใช้งาน service account ที่ไม่ใช้แล้วก่อน แล้วค่อยลบทิ้งจริงหลังผ่านไประยะหนึ่ง เพราะถ้าลบแล้วสร้างใหม่ด้วยชื่อเดิม IAM binding เดิมจะไม่ตามมา ขณะที่การปิดแล้วเปิดกลับยังเก็บ binding ไว้ครบ ผลในทางปฏิบัติคือถ้ามี pipeline อัตโนมัติที่ยังผูกอยู่โดยไม่มีใครรู้ ก็เปิดกลับได้โดยไม่เสียสิทธิ์เดิม

• ปิด human account หรือ SSO identity ของคนนั้นในทุกระบบที่เกี่ยวข้อง ไม่ใช่แค่ระบบหลักที่นึกออกก่อน

• หมุนเวียน secret ที่ใช้ร่วมกันในทีม เช่น database password หรือ API key ที่หลายคนเคยเห็นค่าจริง เพราะคนที่ออกไปมีโอกาสรู้ค่าที่ไม่ได้ผูกกับบัญชีตัวเองด้วย

• ตรวจสอบ audit log ย้อนหลังในช่วงก่อนวันที่ออกจริง เพื่อดูว่ามีการสร้างสิทธิ์ใหม่ ดาวน์โหลดข้อมูลจำนวนมาก หรือเปลี่ยนค่า configuration ที่ผิดปกติหรือไม่

การเขียนเงื่อนไขนี้ไว้ล่วงหน้าในTOR หรือสัญญาจ้างงานทำให้เมื่อถึงวันจริง ทีมไม่ต้องมานั่งคิดลำดับขั้นตอนกลางความเร่งรีบ

ทบทวนสิทธิ์แบบ least privilege ให้เป็นวงจร ไม่ใช่แค่ตอนมีคนออก

หลักการ least privilege (สิทธิ์เท่าที่จำเป็น) ตามนิยามของ NIST SP 800-53 คือการให้แต่ละ entity ได้รับทรัพยากรและสิทธิ์ของระบบเพียงขั้นต่ำที่จำเป็นต่อการทำหน้าที่ของตัวเอง หลักการนี้ได้ผลจริงก็ต่อเมื่อมีการทบทวนเป็นรอบ ไม่ใช่ให้สิทธิ์ไปแล้วปล่อยไว้จนกว่าจะมีเหตุการณ์บังคับให้ต้องตรวจ มาตรฐานของ NIST เองไม่ได้กำหนดตัวเลขตายตัวว่าต้องทบทวนทุกกี่วัน ข้อ AC-6(7) ใน SP 800-53 Rev. 5 ให้แต่ละองค์กรกำหนดความถี่เอง ซึ่งเราแนะนำให้ผูกกับความเสี่ยงของระบบนั้น ในทางปฏิบัติ เครื่องมืออย่าง Microsoft Entra เปิดให้ตั้งรอบทบทวนสิทธิ์แบบรายสัปดาห์ รายเดือน รายไตรมาส หรือรายปีได้ตามระดับความเสี่ยงของแต่ละกลุ่มสิทธิ์ ระบบที่แตะข้อมูลลูกค้าหรือมีสิทธิ์ระดับ admin ควรทบทวนถี่กว่าระบบภายในทั่วไป และเมื่อพูดถึงสิทธิ์ที่ควรอยู่ในวงจรทบทวนเดียวกัน สิทธิ์ของ AI agent ที่เชื่อมต่อระบบเองก็ควรถูกนับรวมด้วย แม้จะมีรายละเอียดเฉพาะของตัวเองที่ต่างออกไป

ใครควรเป็นเจ้าของกระบวนการนี้ ไม่ใช่ IT ฝ่ายเดียว

ข้อผิดพลาดที่พบบ่อยคือมองว่าการเพิกถอนสิทธิ์เป็นงานของ IT ล้วน ทั้งที่ IT มักไม่ใช่ฝ่ายแรกที่รู้ว่ามีคนออกจากโครงการ ฝ่ายบุคคลรู้วันที่พนักงานพ้นสภาพก่อนใคร จึงควรเป็นจุดเริ่มของ trigger ที่แจ้งไปยัง IT โดยอัตโนมัติ ฝ่ายจัดซื้อหรือกฎหมายรู้วันที่สัญญากับ vendorสิ้นสุดหรือไม่ต่ออายุ จึงควรเป็นคนแจ้งเช่นกัน เจ้าของระบบ (system owner) ควรเป็นคนเซ็นรับรู้ว่าสิทธิ์ถูกเพิกถอนครบตามรายการ ส่วนฝ่ายความปลอดภัยหรือ compliance ควรเป็นเจ้าของการตรวจ audit log และเก็บหลักฐานไว้ตอบผู้ตรวจสอบ IT ยังเป็นคนลงมือทำจริง แต่ไม่ควรเป็นฝ่ายเดียวที่รู้ว่าต้องทำเมื่อไหร่

เมื่อไม่จำเป็นต้องวางกระบวนการหนักขนาดนี้

ข้อจำกัดที่ต้องพูดให้ชัดคือ ระบบภายในขนาดเล็กที่มีผู้ใช้ไม่กี่คน ไม่มีข้อมูลส่วนบุคคลของลูกค้า และแทบไม่มีการเปลี่ยนตัวผู้ดูแลหรือ vendor ไม่จำเป็นต้องลงทุนกับเครื่องมือ identity governance หรือ automated access review เต็มรูปแบบ การตรวจสอบด้วยมือทุกไตรมาส พร้อมรายชื่อสิทธิ์ที่มีอยู่จริงในตอนนั้น ก็เพียงพอสำหรับความเสี่ยงระดับนี้ สิ่งที่องค์กรขนาดนี้ต้องการคือมีคนรับผิดชอบทำจริงตามรอบที่วางไว้ ไม่ใช่ระบบอัตโนมัติที่ซับซ้อนเกินความจำเป็นของงาน

ข้อโต้แย้งที่ได้ยินบ่อย

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

จะเริ่มตรงไหน

ถ้ายังไม่เคยทำเรื่องนี้อย่างเป็นระบบ จุดเริ่มต้นที่ทำได้จริงภายในไตรมาสนี้มีสี่ข้อ

• ทำ inventory สิทธิ์เข้าถึงทั้งหมดที่มีอยู่จริงตอนนี้ ทั้งใน Google Cloud, Microsoft Azure และ Cloudflare ว่าใครหรือ service account ไหนเข้าถึงอะไรได้บ้าง

• เขียน checklist ลำดับการเพิกถอนสิทธิ์ไว้ล่วงหน้า ก่อนที่จะมีคนออกจริง เพื่อไม่ต้องคิดขั้นตอนกลางความเร่งรีบ

• กำหนดเจ้าของกระบวนการให้ชัดว่าใครแจ้ง ใครลงมือทำ และใครเซ็นรับรู้ว่าทำครบ

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

ทีมของเรา (Superdev) มองกระบวนการนี้เป็นส่วนหนึ่งของงานวางระบบตั้งแต่ต้น ไม่ใช่งานเสริมที่ค่อยคิดทีหลัง

สรุปสั้น ๆ ความเสี่ยงของบัญชี Cloud ในช่วงเปลี่ยนมือไม่ได้มาจากภายนอกอย่างเดียว แต่อยู่ที่สิทธิ์เข้าถึงที่ไม่มีใครนัดตรวจตอนคนออกจากทีม ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้เขียนลำดับเพิกถอนสิทธิ์เป็นเอกสารไว้ล่วงหน้า และมอบหมายเจ้าของกระบวนการให้ชัดตั้งแต่วันนี้ หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างทบทวนแนวทางเรื่องสิทธิ์เข้าถึงภายใน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ