Break-glass Account สำหรับทีม: มีบัญชีสำรองแล้วเข้าได้จริงหรือ
บัญชีฉุกเฉินช่วยเมื่อ admin ปกติเข้าไม่ได้ แต่ถ้าพึ่งโทรศัพท์หรือระบบยืนยันตัวเดียวกันก็อาจช่วยอะไรไม่ได้ ชวนดูวิธีคิดเรื่องทางเข้า ผู้ถือสิทธิ์ การแจ้งเตือน และการทดสอบ
บัญชี admin สำรองอาจดูเหมือนคำตอบง่าย ๆ สำหรับวันที่เข้าระบบไม่ได้ แต่ถ้าบัญชีนั้นต้องใช้โทรศัพท์เครื่องเดียวกับบัญชีหลัก หรือยังต้องผ่านระบบยืนยันตัวที่กำลังมีปัญหา มันก็อาจล้มไปพร้อมกัน บัญชีแบบ break-glass จึงไม่ได้มีคุณค่าเพราะ “มีอีกหนึ่งชื่อผู้ใช้” คุณค่าของมันอยู่ที่เป็นทางเข้าฉุกเฉินที่ยังใช้ได้เมื่อทางปกติใช้ไม่ได้
สำหรับทีมเล็ก ผมจะเริ่มจากคำถามที่เจาะจงกว่า “ควรสร้างไหม”: ถ้า admin หลักเข้า Microsoft 365 ไม่ได้ในวันนี้ ทีมยังมีใครและมีอะไรที่พาเข้าไปแก้ปัญหาได้ โดยไม่ต้องขอความช่วยเหลือจากบัญชีที่ถูกล็อกอยู่? คำตอบนี้ช่วยตัดสินทั้งว่าจะต้องมีบัญชีฉุกเฉินหรือไม่ และควรป้องกันมันอย่างไร
ลองนึกถึงทีมที่มีผู้ดูแลสองคน ทั้งคู่ใช้แอปยืนยันตัวบนโทรศัพท์ และใช้บัญชีงานผ่านตัวตนกลางเดียวกัน วันหนึ่งโทรศัพท์ของคนหนึ่งหาย ส่วนอีกคนติดเงื่อนไขการลงชื่อเข้าที่ตั้งผิด การมีชื่อ admin คนที่สามในรายชื่อผู้ใช้ยังไม่พอ ถ้าเขาต้องผ่านเงื่อนไขเดียวกันทั้งหมด ผมจะวาดเส้นทางเข้าของแต่ละบัญชีก่อน แล้ววงจุดที่ล้มพร้อมกันได้
ทางสำรองต้องไม่ติดประตูเดียวกับทางหลัก
จุดพึ่งพาที่มักมองข้ามคือบัญชีฉุกเฉินยังอาศัย identity provider ภายนอก, โทรศัพท์ของ admin คนเดิม, กล่องอีเมลที่ต้องเข้าใช้ผ่านระบบที่เสีย หรือการอนุมัติจากคนที่ไม่มีใครติดต่อได้ หากเหตุที่วางแผนรับมือคือระบบตัวตนกลางล่ม ทางสำรองที่ต้องผ่านระบบนั้นก็ไม่ได้สำรองจริง
คำแนะนำของ Microsoft สำหรับ Entra ID จึงเสนอให้มีบัญชีฉุกเฉินอย่างน้อยสองบัญชีที่อยู่ใน cloud โดยตรง ไม่ผูกกับระบบ federated identity และใช้วิธียืนยันตัวที่ทนการหลอกลวง เช่น passkey บนกุญแจ FIDO2 ซึ่งต่างจากวิธีของ admin ปกติ นี่เป็นแนวทางเฉพาะสภาพแวดล้อม Microsoft ไม่ใช่สูตรจำนวนบัญชีสำหรับทุกบริการ แต่หลักที่ยืมมาได้คือสำรองทั้ง เส้นทาง ไม่ใช่แค่ชื่อบัญชี
บางทีมอาจคิดว่าให้บัญชีฉุกเฉินข้าม MFA ไปเลยจะเข้าได้ง่ายกว่า ผมไม่ชอบทางลัดนี้ เพราะบัญชีที่มีสิทธิ์สูงและเข้าได้ด้วยรหัสผ่านอย่างเดียวมีมูลค่าสูงสำหรับผู้โจมตี อีกทั้ง Microsoft ระบุว่าบัญชีฉุกเฉินก็อยู่ภายใต้ข้อกำหนด MFA เมื่อการบังคับใช้ครอบคลุม tenant นั้น ควรเลือกวิธีที่ยังแข็งแรงแต่ไม่พึ่งปัจจัยเดียวกับทางปกติ และตรวจ policy จริงของบริการที่ใช้ก่อนตั้งค่า
กุญแจอยู่กับใคร และใครจะรู้เมื่อมันถูกหยิบไปใช้
พอเห็นทางเข้าแล้ว ผมจะถามเรื่องต่อไปคือ ใครถือ credential ใครถือกุญแจหรือวิธียืนยันตัวสำรอง เก็บไว้ที่ไหน และถ้าคนถือของลาหรือออกจากทีม ใครเปิดใช้แทนได้ การเก็บทุกอย่างไว้ใน password manager เดียวที่ต้องล็อกอินด้วยบัญชีงานนั้นสะดวกในวันปกติ แต่วันฉุกเฉินอาจกลายเป็นวงกลมที่ไม่มีทางออก การแยกสถานที่เก็บและกำหนดผู้ได้รับอนุญาตจึงสำคัญกว่าซองที่เขียนว่า “ฉุกเฉิน” สวย ๆ
ในตัวอย่างทีมสองคนนี้ ผมจะไม่ให้บัญชีฉุกเฉินเป็นบัญชีทำงานประจำ ไม่ผูก mailbox หรือ automation เข้าไปเพิ่ม และไม่แชร์วิธีเข้าผ่านแชตกลุ่ม ผู้ดูแลควรตกลงล่วงหน้าว่าเหตุแบบไหนใช้ได้ ใครอนุมัติหรือรับรู้ และหลังใช้ต้องบันทึกว่าเข้าไปทำอะไร ถ้ามีคนถือสิทธิ์เพียงคนเดียวก็ต้องยอมรับตรง ๆ ว่าความพร้อมยังพึ่งคนนั้นอยู่
การไม่ใช้ประจำทำให้ตรวจจับได้ง่ายขึ้น: การลงชื่อเข้าหรือการเปลี่ยนแปลงสิทธิ์ของบัญชีนี้ควรเป็นเหตุให้คนรับผิดชอบได้รับแจ้ง Microsoft แนะนำให้ติดตาม sign-in และ audit log ของบัญชีฉุกเฉิน ด้วย แต่ alert ที่ส่งเข้ากล่องอีเมลเดียวกับระบบที่กำลังเสียก็ช่วยได้จำกัด ต้องดูว่าใครรับสัญญาณได้จริง และทดสอบว่าข้อความไปถึงเขา
ลองเปิดประตูในวันที่ยังไม่เกิดเหตุ
บัญชีที่สร้างแล้วเก็บเงียบไปหนึ่งปีอาจถูก policy ใหม่ขวาง กุญแจหาย หรือเจ้าของเดิมลาออก ผมอยากให้ทีมลองทดสอบแบบควบคุม: ให้ผู้มีสิทธิ์หยิบวิธียืนยันตัวจากที่เก็บ เข้าระบบจากเครื่องที่กำหนด ตรวจว่ามองเห็นเฉพาะสิ่งที่จำเป็นต่อการกู้ทางเข้า ดูว่า alert ทำงาน แล้วออกจากระบบและเก็บของกลับ ไม่จำเป็นต้องรอให้ระบบล่มจริงเพื่อรู้ว่ากุญแจอยู่ผิดลิ้นชัก
สำหรับ Microsoft Entra เอกสารแนะนำให้ตรวจว่าบัญชียังใช้งานได้อย่างน้อยทุก 90 วัน ทีมที่ใช้บริการอื่นควรเลือกความถี่ตามการเปลี่ยนแปลงของระบบและคนดูแล ไม่ต้องยืมตัวเลขนี้ไปใช้โดยไม่คิด ทุกครั้งที่เปลี่ยน policy การลงชื่อเข้า เปลี่ยนผู้ดูแล หรือเปลี่ยนวิธียืนยันตัว ก็ควรถือเป็นเหตุให้ทดสอบอีกครั้ง
ผลทดสอบที่มีประโยชน์ไม่ใช่แค่เครื่องหมายถูกว่า “ล็อกอินผ่าน” ต้องตอบได้ด้วยว่าใช้เวลาติดตามผู้ถือสิทธิ์แค่ไหน มี alert ถึงคนที่รับผิดชอบหรือไม่ และหลังใช้ทีมปิด session ตรวจ log และคืน credential เข้าที่แล้วหรือยัง หากทดสอบไม่ผ่าน นั่นเป็นงานแก้ไขที่ชัดเจนกว่าการรอให้ปัญหาเกิดจริง
บัญชีฉุกเฉินเพิ่มสิทธิ์สูงอีกจุดหนึ่งให้ต้องดูแล ผมจะยอมรับต้นทุนนี้ก็ต่อเมื่อทีมบอกได้ว่ามันช่วยผ่านความเสียหายแบบไหน ใครเข้าถึงได้ และจะรู้ได้อย่างไรถ้ามันถูกใช้ผิดเวลา ถ้าตอบไม่ได้ เริ่มจากวาดเส้นทางเข้า admin ปัจจุบันก่อน การเพิ่มบัญชีทันทีอาจเพิ่มประตู แต่ยังไม่เพิ่มทางออก