Conditional Access exclusions that need an owner
ข้อยกเว้นอาจจำเป็น แต่ต้องมีเหตุผล เจ้าของ ขอบเขต และวันทบทวนที่ชัดเจน
An exclusion is a control decision
Conditional Access policy สามารถกำหนดทั้งผู้ใช้ที่รวมอยู่และผู้ใช้ที่ยกเว้น โดย exclusion มีผลเหนือ inclusion ดังนั้นการเพิ่ม account หรือ group เข้า exclusion จึงไม่ใช่เพียงงาน configuration แต่เป็นการลดขอบเขตของ control ที่ต้องมีเหตุผลรองรับ
ข้อยกเว้นบางประเภทจำเป็นจริง เช่น emergency access account หรือ service identity ที่ยังไม่รองรับ control เดียวกับผู้ใช้ทั่วไป ปัญหาไม่ได้อยู่ที่การมี exclusion แต่อยู่ที่การมี exclusion ซึ่งไม่มีใครอธิบายได้ว่าใครอนุมัติ มีไว้ถึงเมื่อใด และมี control อื่นชดเชยหรือไม่
Necessary exclusions
Emergency access account ต้องเข้าถึง tenant ได้เมื่อ identity control ปกติขัดข้อง Microsoft แนะนำให้มีอย่างน้อยสองบัญชีที่เป็น cloud-only ใช้วิธี authentication ที่ทนต่อ phishing และถูกติดตามอย่างใกล้ชิด บัญชีเหล่านี้ควรถูกยกเว้นจาก policy ที่อาจ block access แต่ไม่ควรถูกใช้ในงานประจำวัน
สำหรับ service account, synchronization identity หรือ automation ควรตรวจว่าจำเป็นต้องเป็น user account หรือสามารถเปลี่ยนไปใช้ managed identity หรือ workload identity ได้หรือไม่ หากยังต้องยกเว้น ควรจำกัด resource, location, permission และ credential lifecycle ให้แคบที่สุด
Ownership record
Exclusion record ที่ตรวจสอบได้ควรมีข้อมูลอย่างน้อยดังนี้
- Account หรือ group ที่ถูกยกเว้น และ policy ที่เกี่ยวข้อง
- Business และ technical reason
- เจ้าของระบบ ผู้อนุมัติ และทีมที่ต้องตอบสนองเมื่อมีการใช้งาน
- Compensating controls เช่น alert, restricted role หรือ network restriction
- วันที่เริ่ม วันหมดอายุ หรือรอบทบทวนครั้งถัดไป
- แผนยกเลิกข้อยกเว้นเมื่อ dependency ได้รับการแก้ไข
Operational steps
- Export รายการ policy, included scope และ excluded scope เพื่อให้เห็นผลรวมก่อนแก้ไข
- จำแนกแต่ละ exclusion ว่าเป็น emergency access, workload dependency, temporary exception หรือรายการที่ไม่มีเจ้าของ
- ยืนยัน owner, business reason, compensating control และวันทบทวนก่อนคงข้อยกเว้นไว้
- ทดสอบ policy ด้วย report-only mode และ What If รวมถึง account สำคัญและเส้นทางกู้คืน
- เปิดใช้เป็นช่วง ติดตาม sign-in failure และเตรียมผู้ที่สามารถ rollback ได้
- นำ exclusion ชั่วคราวออกตามวันหมดอายุ และตรวจ membership change อย่างต่อเนื่อง
Review cycle
Microsoft แนะนำให้ validate emergency access account อย่างน้อยทุก 90 วัน และตรวจสอบ sign-in กับ audit activity อย่างสม่ำเสมอ รอบเดียวกันนี้สามารถใช้ทบทวน exclusion ที่มีความเสี่ยงสูงได้ ส่วน exclusion ชั่วคราวควรมีวันหมดอายุแทนการรอให้เจ้าของจำได้เอง
ก่อนเปิด policy ใหม่ควรใช้ report-only mode และ What If เพื่อดูผลกระทบกับ account สำคัญ จากนั้น deploy เป็นช่วงและติดตาม sign-in failure การเปลี่ยนจาก report-only ไปเป็น on ควรมี rollback path ที่ผู้ปฏิบัติงานเข้าใจตรงกัน
Warning signs
- Exclusion group เปิดให้ผู้ดูแลทั่วไปเพิ่มสมาชิกได้
- ชื่อ account ไม่สื่อ purpose และไม่มี owner
- ไม่มี alert เมื่อ emergency account sign in
- ข้อยกเว้นถูกสร้างเพื่อแก้ incident ชั่วคราวแต่ไม่เคยนำออก
- Policy จำนวนมากยกเว้นคนละกลุ่มจนไม่สามารถตอบได้ว่า account หนึ่งถูกควบคุมด้วยอะไร
ข้อยกเว้นที่ปลอดภัยไม่ใช่ข้อยกเว้นที่ไม่มีความเสี่ยง แต่เป็นข้อยกเว้นที่ขอบเขตชัด ติดตามได้ และยกเลิกได้