सशर्त पहुंच और PIM वास्तव में हमलों को कैसे रोकते हैं?

पासवर्ड नीतियां अनुमान लगाने वाले हमलों को रोकती हैं। वे एक चोरी किए गए सेशन टोकन, एक फिशिंग MFA प्रॉम्प्ट, या एक स्थायी एडमिन खाते के खिलाफ कुछ नहीं करते जो दो साल से Global Administrator अधिकार के साथ पड़ा है। सशर्त पहुंच और विशेषाधिकार प्राप्त पहचान प्रबंधन (PIM) दो Azure AD / Entra ID नियंत्रण हैं जो वास्तव में उन अंतरालों को संबोधित करते हैं, और वे एक साथ सर्वश्रेष्ठ काम करते हैं।

सशर्त पहुंच के पीछे क्या काम कर रहा है

सशर्त पहुंच एक if-this-then-that इंजन है जिसका मूल्यांकन साइन-इन समय पर किया जाता है। "if" पक्ष (सिग्नल) में उपयोगकर्ता/समूह सदस्यता, डिवाइस अनुपालन स्थिति, नेटवर्क स्थान, साइन-इन जोखिम (Identity Protection से), एक्सेस किया जा रहा आवेदन, और क्लाइंट ऐप प्रकार (ब्राउज़र बनाम legacy प्रोटोकॉल) शामिल है। "then" पक्ष (नियंत्रण) में शामिल हैं: MFA की आवश्यकता है, एक अनुपालन डिवाइस की आवश्यकता है, एक अनुमोदित क्लाइंट ऐप की आवश्यकता है, पहुंच को पूरी तरह से ब्लॉक करें, या उपयोग की शर्तों की स्वीकृति की आवश्यकता है।

एक नीति जो लगभग हर tenant में मायने रखती है: legacy प्रमाणीकरण को ब्लॉक करें। POP, IMAP, और पुराने SMTP जैसे प्रोटोकॉल आधुनिक MFA चुनौतियों का समर्थन नहीं करते, इसलिए वे पहली चीज हैं जो credential-stuffing उपकरण कोशिश करते हैं। साइन-इन लॉग को "Client App = Other clients" से फ़िल्टर करके चेक करें — आप अक्सर एक legacy स्कैनर या एक पुराने multifunction प्रिंटर को basic auth के साथ प्रमाणीकृत होते हुए पाएंगे।

दूसरा जो दिन एक से रखने लायक है: सभी उपयोगकर्ताओं के लिए MFA की आवश्यकता है, केवल break-glass खातों के लिए एक बहिष्कार समूह के साथ स्कोप्ड। MFA को "सिर्फ admins" तक सीमित न करें। compromised मानक उपयोगकर्ता खाते वह तरीका हैं जिसके द्वारा हमलावर अपना पहला पदचिन्ह प्राप्त करते हैं privilege escalation शुरू होने से पहले।

साइन-इन जोखिम बनाम उपयोगकर्ता जोखिम — विभिन्न सिग्नल, विभिन्न प्रतिक्रियाएं

Identity Protection (Entra ID P2 का हिस्सा) दो अलग-अलग जोखिम स्कोर उत्पन्न करता है और इन्हें मिलाना आसान है:

• साइन-इन जोखिम — यह विशिष्ट प्रमाणीकरण प्रयास anomalous दिखता है (असंभव यात्रा, anonymous IP, अपरिचित साइन-इन गुण)।
• उपयोगकर्ता जोखिम — इस खाते को पहचान से जुड़े कारण के लिए flagged किया गया है (breach corpus में पाए गए leaked credentials, confirmed compromise गतिविधि)।

साइन-इन जोखिम का जवाब देने वाली सशर्त पहुंच नीति आम तौर पर MFA से चुनौती देनी चाहिए — यदि वास्तविक उपयोगकर्ता चुनौती पूरी कर सकता है, तो उन्हें अभी आने दें। उपयोगकर्ता जोखिम का जवाब देने वाली नीति को पासवर्ड रीसेट को force करना चाहिए, क्योंकि MFA अकेले मदद नहीं करता यदि credential ही पहले से burned है।

स्थायी admin पहुंच बड़ी समस्या क्यों है

यहां तक कि airtight सशर्त पहुंच के साथ, एक खाता जो permanently Global Administrator रखता है, वह directory में सादे दृष्टि में एक target है। कोई भी जो इसे compromise करता है, बिना किसी अतिरिक्त चरण के पूर्ण tenant नियंत्रण inherit करता है। PIM "permanent" भाग को हटा देता है।

PIM के साथ, admin भूमिकाएं eligible के रूप में assigned होती हैं, न कि active। उपयोगकर्ता को role को explicitly activate करना होता है, जो एक required justification, optional approval workflow, MFA re-confirmation, और एक time-bound window — आमतौर पर 1 से 8 घंटे — को trigger करता है, जिसके बाद role automatically deactivate हो जाता है। खाते के मालिक सहित कोई भी, स्थायी Global Admin नहीं रखता जब तक वे सक्रिय रूप से इसका उपयोग नहीं कर रहे हों।

न्यूनतम PIM कॉन्फ़िगरेशन जो वास्तव में उपयोगी है

• Helpdesk Administrator से ऊपर की प्रत्येक भूमिका: eligible, permanent नहीं।
• Global Administrator और Privileged Role Administrator: दूसरे admin से approval की आवश्यकता है, केवल self-activation नहीं।
• Activation MFA required, कोई अपवाद नहीं।
• 4 घंटे की अधिकतम activation duration लोगों को genuinely separate work sessions के लिए reactivate करने के लिए force करता है, जो cleaner audit trails भी बनाता है।
• सभी eligible assignments पर हर 90 दिन में access reviews — खाते एक project के लिए जोड़े जाते हैं और अन्यथा कभी हटाए नहीं जाते।

टीमें इसे कहां गलत प्राप्त करती हैं

सबसे आम असफलता नीति डिजाइन नहीं है, यह बहिष्कार सूची है। एक सशर्त पहुंच नीति जिसमें एक बढ़ती हुई "इन उपयोगकर्ताओं को बहिष्कृत करें क्योंकि app MFA का समर्थन नहीं करता" समूह अंत में आधे tenant को बहिष्कृत करता है। बहिष्कार को एक backlog item के रूप में track करें जिसमें एक owner और removal date हो, न कि एक permanent bucket।

दूसरी असफलता break-glass खाते हैं जिन्हें वास्तव में test नहीं किया गया है। दो emergency खाते, सशर्त पहुंच और PIM से बहिष्कृत, लंबे random passwords के साथ offline में संग्रहीत और किसी भी साइन-इन पर alerting — और किसी को त्रैमासिक रूप से उनमें लॉग इन करने का प्रयास करना चाहिए यह confirm करने के लिए कि वे अभी भी काम करते हैं।

सशर्त पहुंच और PIM एक compliance audit के लिए checkbox नहीं हैं। वे एक phished credential के बीच का अंतर हैं, जो एक inconvenience है और पूर्ण tenant compromise है। यदि आप एक Blue Team build-out के भाग के रूप में identity नियंत्रणों को मैप कर रहे हैं, तो Korra Studio के Cloud और Blue Team सेगमेंट detection पक्ष को cover करते हैं — Identity Protection जोखिम events Sentinel में वास्तव में क्या दिखते हैं और असंभव PIM activation patterns पर कैसे alert करें।