Conditional Access اور PIM دراصل حملوں کو کیسے روکتے ہیں؟

Password پالیسیاں guessing کے حملوں کو روکتی ہیں۔ وہ چوری شدہ session token، phished MFA prompt، یا کسی standalone admin account کے خلاف کچھ نہیں کرتیں جو دو سال سے Global Administrator کی rights کے ساتھ موجود ہو۔ Conditional Access اور Privileged Identity Management (PIM) وہ دونوں Azure AD / Entra ID کنٹرولز ہیں جو دراصل ان خطرات کو سنبھالتے ہیں، اور وہ ایک ساتھ سب سے بہتر کام کرتے ہیں۔

Conditional Access پس منظر میں کیا کر رہا ہے

Conditional Access ایک if-this-then-that engine ہے جو sign-in کے وقت evaluate ہوتا ہے۔ "if" کا حصہ (signals) میں user/group membership، device compliance state، network location، sign-in risk (Identity Protection سے)، رسائی میں آنے والی application، اور client app type (browser بمقابلہ legacy protocol) شامل ہیں۔ "then" کا حصہ (controls) میں شامل ہیں: MFA درکار کریں، compliant device درکار کریں، approved client app درکار کریں، رسائی مکمل طور پر روکیں، یا terms-of-use قبول کرنا درکار کریں۔

ایک پالیسی جو تقریباً ہر tenant میں اہم ہے: legacy authentication کو بلاک کریں۔ POP، IMAP، اور پرانے SMTP جیسی protocols جدید MFA challenges کو support نہیں کرتیں، تو یہ وہ پہلی چیز ہیں جو credential-stuffing ٹولز کوشش کرتے ہیں۔ sign-in logs کو "Client App = Other clients" کے ساتھ filter کر کے دیکھیں اس سے پہلے کہ آپ block کریں — آپ کو اکثر ایک legacy scanner یا ایک پرانا multifunction printer ملے گا جو ابھی بھی basic auth کے ساتھ authenticate کر رہے ہوں۔

دوسرا جو پہلے دن سے رکھنے کے قابل ہے: تمام users کے لیے MFA درکار کریں، صرف break-glass accounts کے لیے exclusion group کے ساتھ۔ MFA کو "صرف admins" تک محدود نہ کریں۔ Compromised standard user accounts وہ ہیں جن سے حملہ آور پہلے پاؤں جمانے کی کوشش کرتے ہیں اس سے پہلے کہ privilege escalation شروع ہو۔

Sign-in risk بمقابلہ user risk — مختلف signals، مختلف جوابات

Identity Protection (Entra ID P2 کا حصہ) دو الگ risk scores تیار کرتا ہے اور انہیں ملانا آسان ہے:

• Sign-in risk — یہ مخصوص authentication کی کوشش غیر معمولی لگتی ہے (impossible travel، anonymous IP، unfamiliar sign-in properties)۔
• User risk — اس account کو کسی وجہ سے flag کیا گیا ہے جو خود identity سے متعلق ہے (leaked credentials جو breach corpus میں ملے ہوں، confirmed compromise activity)۔

ایک Conditional Access پالیسی جو sign-in risk کا جواب دے رہی ہو تو عام طور پر MFA کے ساتھ challenge کرنی چاہیے — اگر حقیقی user challenge مکمل کر سکے تو انہیں اندر جانے دیں۔ ایک پالیسی جو user risk کا جواب دے رہی ہو تو password reset کو force کرنا چاہیے، کیونکہ اگر credential خود پہلے سے burn ہو چکی ہو تو MFA اکیلا مدد نہیں دے سکتا۔

قابلِ برداشت ہر وقت admin رسائی بڑا مسئلہ کیوں ہے

یہاں تک کہ مضبوط Conditional Access کے ساتھ بھی، ایک account جو Global Administrator کو مستقل طور پر رکھتا ہے یہ directory میں نظر آنے والا target ہے۔ جو کوئی اسے compromise کرے گا وہ مکمل tenant کنٹرول حاصل کرے گا کسی اضافی قدم کے بغیر۔ PIM "permanent" کے حصے کو ہٹاتا ہے۔

PIM کے ساتھ، admin roles کو eligible کے طور پر assign کیا جاتا ہے نہ کہ active۔ User کو explicitly role کو activate کرنا ہوتا ہے، جو ایک ضروری justification کو trigger کرتا ہے، optional approval workflow، MFA re-confirmation، اور ایک time-bound window — عام طور پر 1 سے 8 گھنٹے — جس کے بعد role خودکار طور پر deactivate ہو جاتا ہے۔ کوئی بھی، account کے مالک سمیت، Global Admin کے پاس ہر وقت نہیں ہے جب تک کہ وہ اسے فعال استعمال میں نہ ہوں۔

ایک کم سے کم PIM ترتیب جو واقعی استعمال میں آتی ہے

• Helpdesk Administrator سے اوپر کا ہر role: eligible، permanent نہیں۔
• Global Administrator اور Privileged Role Administrator: ایک دوسرے admin کی approval درکار ہو، نہ صرف self-activation۔
• Activation MFA درکار ہے، کوئی exception نہیں۔
• 4 گھنٹے کی maximum activation duration لوگوں کو genuinely الگ الگ کام کے سیشنز کے لیے دوبارہ activate کرنے پر مجبور کرتا ہے، جو صاف audit trails بھی تیار کرتا ہے۔
• ہر 90 دن میں تمام eligible assignments پر access reviews — accounts ایک project کے لیے شامل ہو جاتے ہیں اور ورنہ کبھی ہٹائے نہیں جاتے۔

Teams یہاں غلط کہاں کرتی ہیں

سب سے عام ناکامی پالیسی ڈیزائن نہیں ہے، یہ exclusion list ہے۔ ایک Conditional Access پالیسی جس میں ایک بڑھتی ہوئی "یہ users استثنیٰ کریں کیونکہ app MFA کو support نہیں کرتا" group ہے آخرکار نصف tenant کو استثنیٰ کر دیتا ہے۔ Exclusions کو backlog item کے طور پر owner اور removal date کے ساتھ track کریں، permanent bucket کے طور پر نہیں۔

دوسری ناکامی break-glass accounts ہیں جو واقعی test نہیں کی گئیں۔ دو emergency accounts، Conditional Access اور PIM سے استثنیٰ، offline محفوظ لمبی random passwords کے ساتھ اور کسی بھی sign-in پر alerting — اور کسی کو quarterly میں ان میں log کرنے کی کوشش کرنی چاہیے تاکہ تصدیق کریں کہ وہ ابھی کام کر رہے ہیں۔

Conditional Access اور PIM compliance audit کے لیے checkbox نہیں ہیں۔ وہ phished credential کے درمیان فرق ہیں جو inconvenience ہو اور یہ کہ یہ full tenant compromise ہو۔ اگر آپ Blue Team build-out کے حصے کے طور پر identity controls کو map کر رہے ہیں، تو Korra Studio کے Cloud اور Blue Team segments detection کے حصے کو cover کرتے ہیں — Identity Protection risk events Sentinel میں واقعی کیسی نظر آتی ہیں اور impossible PIM activation patterns پر کیسے alert کریں۔