Conditional Access மற்றும் PIM எவ்வாறு தாக்குதलை உண்மையாகத் தடுக்கின்றன?

கடவுச்சொல் நীதிகள் অনுமান தாக்குதலை தடுக்கின்றன. அவை盗まれたセッションทoken, phished MFA prompt, அல்லது இரண்டு ஆண்டுகளாக Global Administrator உரிமைகளுடன் இருக்கும் நிரந்தர admin खाते க்கு எதிராக எதுவும் செய்யாது. Conditional Access மற்றும் Privileged Identity Management (PIM) என்பவை Azure AD / Entra ID controls ஆகும், அவை உண்மையாக இந்த இடைவெளிகளை தீர்க்கின்றன, மற்றும் அவை ஒன்றாக சிறப்பாக வேலை செய்கின்றன.

Conditional Access பின்னணியில் என்ன செய்கிறது

Conditional Access என்பது sign-in நேரத்தில் மதிப்பிடப்படும் if-this-then-that engine ஆகும். "if" பக்கம் (signals) பயனர்/குழு உறுப்பியல், device compliance நிலை, network location, sign-in risk (Identity Protection இலிருந்து), அணுகப்படும் பயன்பாடு, மற்றும் client app வகை (browser vs. legacy protocol) ஐ உள்ளடக்கியது. "then" பக்கம் (controls) உள்ளடக்கியது: MFA தேவைப்படுகிறது, compliant device தேவைப்படுகிறது, approved client app தேவைப்படுகிறது, அணுகலை முழுவதுமாக தடுக்கவும், அல்லது terms-of-use ஏற்றுக்கொள்ளல் தேவைப்படுகிறது.

ஒரு policy ஏறக்குறைய ஒவ்வொரு tenant இலும் முக்கியமானது: legacy authentication தடுக்கவும். POP, IMAP, மற்றும் பழைய SMTP போன்ற protocols நவீன MFA challenges ஐ ஆதரிக்கவில்லை, எனவே அவை credential-stuffing tools முதலில் முயற்சிக்கும் விஷயம். sign-in logs ஐ "Client App = Other clients" மூலம் filter செய்து check செய்யவும் — நீங்கள் பெரும்பாலும் ஒரு legacy scanner அல்லது பழைய multifunction printer ஐ basic auth உடன் authenticate செய்வதைக் கண்டுபிடிப்பீர்கள்.

நாளை முதல் கொண்டிருக்க மதிப்புள்ள இரண்டாவது ஒன்று: அனைத்து பயனர்களுக்கு MFA தேவைப்படுகிறது, break-glass accounts க்கு மட்டும் ஒரு exclusion group உடன் scoped. MFA ஐ "just admins" க்கு scope செய்யாதீர்கள். Compromised standard user accounts என்பது தாக்குபவர்கள் privilege escalation கூட தொடங்குவதற்கு முன் அவர்களின் முதல் foothold ஐ எவ்வாறு பெறுகிறார்கள்.

Sign-in risk vs. user risk — வெவ்வேறு signals, வெவ்வேறு responses

Identity Protection (Entra ID P2 இன் பகுதி) இரண்டு தனி risk scores ஐ உत்பन்னம் செய்கிறது மற்றும் அவற்றை மதிப்பிடுவது எளிது:

• Sign-in risk — இந்த குறிப்பிட்ட authentication attempt அசாதாரணமாகத் தெரிகிறது (impossible travel, anonymous IP, unfamiliar sign-in properties).
• User risk — இந்த account அடையாளத்திற்கு தொடர்புடைய ஒரு காரணத்திற்கு flag செய்யப்பட்டுள்ளது (breach corpus இல் கண்டுபிடிக்கப்பட்ட leaked credentials, confirmed compromise activity).

Sign-in risk க்கு responding Conditional Access policy பொதுவாக MFA உடன் சவால் விடுக்க வேண்டும் — real user challenge ஐ complete செய்ய முடிந்தால், அவர்களை அனுமதிக்கவும். User risk க்கு responding policy password reset ஐ force செய்ய வேண்டும், কারணம் credential தன்னை ஏற்கனவே burned எனில் MFA மட்டும் உதவாது.

நிரந்தর admin access ஏன் பெரிய பிரச்சனை

Entra செய்யப்பட்ட Conditional Access உடன் கூட, Global Administrator ஐ நிரந்தரமாக வைத்திருக்கும் account directory இல் தெளிவான view இல் உள்ள target ஆகும். அதை compromise செய்யும் யாரும் நிரந்தர Admin வைத்திருப்பவர் கூடுதல் step ஆவசியமின்றி full tenant control ஐ வாரிசு பெறுகிறார்கள். PIM "permanent" பகுதியை நீக்குகிறது.

PIM உடன், admin roles eligible ஆக assign செய்யப்படுகின்றன, active அல்ல. பயனர் explicitly role ஐ activate செய்ய வேண்டும், இது required justification, optional approval workflow, MFA re-confirmation, மற்றும் time-bound window ஐ trigger செய்கிறது — பொதுவாக 1 முதல் 8 மணிநேரம் — அதன் பிறகு role automatically deactivate ஆகிறது. யாரும் இல்லை, account owner உட்பட, active இல்லாவிட்டால் அவர்கள் standing Global Admin ஐ வைத்திருக்கவில்லை.

ஒரு minimum PIM configuration அது உண்மையாகவே பயன்படக்கூடியது

• Helpdesk Administrator க்கு மேலேயுள்ள ஒவ்வொரு role: eligible, permanent அல்ல.
• Global Administrator மற்றும் Privileged Role Administrator: இரண்டாவது admin இலிருந்து approval தேவைப்படுகிறது, self-activation மட்டும் அல்ல.
• Activation MFA தேவைப்படுகிறது, விதிவிலக்கு இல்லை.
• Maximum activation duration 4 மணிநேரத்தில் மக்களை genuinely separate work sessions க்கு reactivate செய்ய வேண்டிய force செய்கிறது, இது சுத்தமான audit trails ஐ produce செய்கிறது.
• Access reviews ஒவ்வொரு 90 நாட்களில் அனைத்து eligible assignments இல் — accounts ஒரு project க்கு add செய்யப்பட்டு otherwise remove செய்யப்படவில்லை.

Teams இதை எங்கு தவறாக செய்கிறது

সবচும் பொதுவான failure policy design அல்ல, அது exclusion list ஆகும். ஒரு Conditional Access policy ever-growing "exclude these users because the app doesn't support MFA" group உடன் eventually half the tenant ஐ exclude செய்கிறது. Exclusions ஐ backlog item என track செய்யவும் ஒரு owner மற்றும் removal date உடன், permanent bucket அல்ல.

ரண்டாவது failure break-glass accounts ஆகும் அவை உண்மையாகவே tested அல்ல. இரண்டு emergency accounts, Conditional Access மற்றும் PIM இலிருந்து excluded, long random passwords offline இல் stored மற்றும் alerting any sign-in இல் — மற்றும் யாரும் அவர்கள் இன்னும் work செய்கிறான்றா confirm செய்ய quarterly க்குள் log in செய்ய முயற்சி செய்ய வேண்டும்.

Conditional Access மற்றும் PIM compliance audit க்கு checkbox அல்ல. அவை phished credential இன் inconvenience மற்றும் full tenant compromise க்கு இடையேயான வேறுபாடு ஆகும். நீங்கள் Blue Team build-out இன் பகுதியாக identity controls ஐ mapping செய்கிறீர்கள் என்றால், Korra Studio இன் Cloud மற்றும் Blue Team segments detection பக்கத்தை cover செய்கிறது — Identity Protection risk events Sentinel இல் என்ன தெரிகிறது மற்றும் impossible PIM activation patterns இல் alert செய்வது.