Conditional Access และ PIM ป้องกันการโจมตีได้อย่างไร?

นโยบายรหัสผ่านหยุดการโจมตีแบบ guess ได้ พวกเขาไม่สามารถทำอะไรกับ session token ที่ถูกขโมย prompt MFA ที่ถูก phish หรือบัญชีผู้ดูแลระบบถาวรที่นั่งอยู่ด้วยสิทธิ์ Global Administrator มาเป็นสองปีแล้ว Conditional Access และ Privileged Identity Management (PIM) เป็นการควบคุม Azure AD / Entra ID สองตัวที่จริงๆ แล้วแก้ไขช่องโหว่เหล่านั้นได้ และทำงานได้ดีที่สุดเมื่อทำงานร่วมกัน

สิ่งที่ Conditional Access ทำอยู่เบื้องใน

Conditional Access คือ engine แบบ if-this-then-that ที่ได้รับการประเมินในเวลาลงชื่อเข้าใช้ ด้าน "if" (signals) รวมถึงสมาชิก user/group สถานะการปฏิบัติตามของอุปกรณ์ ตำแหน่งเครือข่าย ความเสี่ยงจากการลงชื่อเข้าใช้ (จาก Identity Protection) แอปพลิเคชันที่กำลังเข้าถึง และประเภทแอปไคลเอนต์ (browser เทียบกับ legacy protocol) ด้าน "then" (controls) รวมถึง: ต้องการ MFA ต้องการอุปกรณ์ที่ปฏิบัติตามนโยบาย ต้องการแอปไคลเอนต์ที่อนุมัติ บล็อกการเข้าถึงทั้งหมด หรือต้องการการยอมรับเงื่อนไขการใช้งาน

นโยบายที่สำคัญในเกือบทุก tenant: บล็อก legacy authentication โปรโตคอลเช่น POP IMAP และ SMTP ที่เก่ากว่าไม่รองรับ modern MFA challenges ดังนั้นมันคือสิ่งแรกที่เครื่องมือ credential-stuffing พยายาม ตรวจสอบ sign-in logs ที่ filtered ด้วย "Client App = Other clients" ก่อนที่คุณจะบล็อก — คุณจะบ่อยครั้งพบ legacy scanner หรือ multifunction printer เก่าที่ยังคงตรวจสอบสิทธิ์ด้วย basic auth

ตัวที่สองที่ควรมีตั้งแต่วันแรก: ต้องการ MFA สำหรับผู้ใช้ทั้งหมด ขอบเขตพร้อมกลุ่มยกเว้นสำหรับบัญชี break-glass เท่านั้น อย่า scope MFA เป็น "เฉพาะผู้ดูแลระบบ" บัญชีผู้ใช้มาตรฐานที่ถูกบุกรุกเข่าคือวิธีที่ผู้โจมตีได้ foothold แรกของพวกเขาก่อนที่ privilege escalation จะเริ่มต้น

Sign-in risk เทียบกับ user risk — signals ที่แตกต่างกัน responses ที่แตกต่างกัน

Identity Protection (ส่วนหนึ่งของ Entra ID P2) สร้าง risk scores แยกกันสองตัว และมันง่ายที่จะสับสน:

• Sign-in risk — ความพยายามตรวจสอบสิทธิ์โดยเฉพาะนี้ดูผิดปกติ (impossible travel anonymous IP unfamiliar sign-in properties)
• User risk — บัญชีนี้ได้รับการทำเครื่องหมายด้วยเหตุผลที่เกี่ยวข้องกับตัวตนเอง (leaked credentials ที่พบในเนื้อหา breach ยืนยันกิจกรรมการบุกรุก)

นโยบาย Conditional Access ที่ตอบสนองต่อ sign-in risk ควรจะให้ challenge ด้วย MFA โดยทั่วไป — ถ้าผู้ใช้จริงสามารถ complete challenge ได้ให้พวกเขาผ่านไป นโยบายที่ตอบสนองต่อ user risk ควรบังคับให้ reset รหัสผ่าน เพราะ MFA เพียงอย่างเดียวไม่ช่วยหากข้อมูลประจำตัวเองถูกเผาไหม้แล้ว

ทำไม standing admin access จึงเป็นปัญหาที่ใหญ่กว่า

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

กับ PIM บทบาท admin ถูกกำหนดให้เป็น eligible แทนที่จะ active ผู้ใช้ต้อง explicitly activate บทบาท ซึ่งทำให้เกิด required justification optional approval workflow MFA re-confirmation และ time-bound window — โดยทั่วไป 1 ถึง 8 ชั่วโมง — หลังจากนั้นบทบาท automatically deactivates ไม่มีใครรวมถึง account owner มี standing Global Admin เว้นแต่พวกเขากำลัง actively ใช้มัน

การกำหนดค่า PIM ขั้นต่ำที่ใช้ได้จริง

• ทุกบทบาทเหนือ Helpdesk Administrator: eligible ไม่ใช่ permanent
• Global Administrator และ Privileged Role Administrator: ต้องการการอนุมัติจากผู้ดูแลระบบที่สอง ไม่ใช่ self-activation เพียงอย่างเดียว
• Activation MFA required ไม่มีข้อยกเว้น
• Maximum activation duration 4 ชั่วโมง บังคับให้ผู้คนต้อง reactivate สำหรับ work sessions ที่แยกจริงๆ ซึ่งยังสร้าง audit trails ที่สะอาดกว่า
• Access reviews ทุก 90 วันในทุก eligible assignments — บัญชีต่างๆ ถูกเพิ่มสำหรับโปรเจ็กต์หนึ่งและไม่เคยถูกนำออก

ที่ที่ทีมทำผิดพลาด

ความล้มเหลวที่พบบ่อยที่สุดไม่ใช่การออกแบบนโยบาย มันคือ exclusion list นโยบาย Conditional Access ที่มี ever-growing "exclude users เหล่านี้เพราะแอปไม่รองรับ MFA" group ในที่สุด excludes ครึ่งหนึ่งของ tenant Track exclusions เป็น backlog item ที่มี owner และ removal date ไม่ใช่ permanent bucket

ความล้มเหลวที่สองคือ break-glass accounts ที่ไม่ได้รับการทดสอบจริง บัญชี emergency สองบัญชี excluded จาก Conditional Access และ PIM ด้วย long random passwords ที่เก็บ offline และ alerting ในการลงชื่อเข้าใช้ใดๆ — และใครบางคนควร พยายาม log ลงทะเบียนเข้าไปในนั้นทั้ง quarterly เพื่อยืนยันว่าพวกเขายังคงทำงาน

Conditional Access และ PIM ไม่ใช่ checkbox สำหรับการตรวจสอบ compliance ไม่ใช่ checkbox มันคือความแตกต่างระหว่าง phished credential ที่เป็น inconvenience และมันเป็น full tenant compromise ถ้าคุณกำลัง map out identity controls เป็นส่วนหนึ่งของ Blue Team build-out Korra Studio's Cloud และ Blue Team segments cover detection side — สิ่งที่ Identity Protection risk events จริงๆ ดูเหมือน Sentinel และวิธีการแจ้งเตือนเกี่ยวกับ impossible PIM activation patterns