Conditional Access এবং PIM আসলে কীভাবে আক্রমণ প্রতিরোধ করে?

পাসওয়ার্ড নীতি অনুমান আক্রমণ প্রতিরোধ করে। চুরি করা সেশন টোকেন, phishing করা MFA প্রম্পট, বা দুই বছর ধরে Global Administrator অধিকার সহ স্থায়ী admin অ্যাকাউন্টের বিরুদ্ধে তারা কিছুই করে না। Conditional Access এবং Privileged Identity Management (PIM) হল দুটি Azure AD / Entra ID নিয়ন্ত্রণ যা আসলে সেই ফাঁকগুলি সমাধান করে, এবং তারা একসাথে সবচেয়ে ভালো কাজ করে।

Conditional Access পর্দার পিছনে কী করছে

Conditional Access হল একটি if-this-then-that ইঞ্জিন যা সাইন-ইন সময়ে মূল্যায়িত হয়। "if" দিক (signals) ব্যবহারকারী/গ্রুপ সদস্যপদ, ডিভাইস সম্মতি অবস্থা, নেটওয়ার্ক অবস্থান, সাইন-ইন ঝুঁকি (Identity Protection থেকে), অ্যাক্সেস করা অ্যাপ্লিকেশন এবং ক্লায়েন্ট অ্যাপ প্রকার (ব্রাউজার বনাম legacy প্রোটোকল) অন্তর্ভুক্ত করে। "then" দিক (controls) অন্তর্ভুক্ত করে: MFA প্রয়োজন, সম্মত ডিভাইস প্রয়োজন, অনুমোদিত ক্লায়েন্ট অ্যাপ প্রয়োজন, অ্যাক্সেস সম্পূর্ণ অবরুদ্ধ করুন, বা ব্যবহারের শর্তাবলী গ্রহণ প্রয়োজন।

এমন একটি নীতি যা প্রায় প্রতিটি tenant-এ গুরুত্বপূর্ণ: legacy authentication অবরুদ্ধ করুন। POP, IMAP এবং পুরানো SMTP-এর মতো প্রোটোকলগুলি আধুনিক MFA চ্যালেঞ্জ সমর্থন করে না, তাই সেগুলি হল credential-stuffing টুলগুলির প্রথম চেষ্টার লক্ষ্য। "Client App = Other clients" দ্বারা ফিল্টার করা সাইন-ইন লগ পরীক্ষা করুন অবরুদ্ধ করার আগে — আপনি প্রায়শই একটি পুরানো legacy scanner বা একটি পুরানো multifunction প্রিন্টার এখনও basic auth দিয়ে প্রমাণীকরণ করছেন তা খুঁজে পাবেন।

দ্বিতীয়টি প্রথম দিন থেকে থাকার যোগ্য: সমস্ত ব্যবহারকারীর জন্য MFA প্রয়োজন, শুধুমাত্র break-glass অ্যাকাউন্টের জন্য একটি exclusion গ্রুপ সহ scoped। MFA কে "শুধুমাত্র admins" এ সীমাবদ্ধ করবেন না। সমস্যাগ্রস্ত মান ব্যবহারকারী অ্যাকাউন্টগুলি হল কীভাবে আক্রমণকারীরা তাদের প্রথম foothold পায় এমনকি privilege escalation শুরু হওয়ার আগে।

Sign-in ঝুঁকি বনাম ব্যবহারকারী ঝুঁকি — বিভিন্ন সংকেত, বিভিন্ন প্রতিক্রিয়া

Identity Protection (Entra ID P2 এর অংশ) দুটি আলাদা ঝুঁকি স্কোর তৈরি করে এবং সেগুলি একত্রিত করা সহজ:

• Sign-in ঝুঁকি — এই নির্দিষ্ট প্রমাণীকরণ প্রচেষ্টা অসাধারণ দেখাচ্ছে (impossible travel, anonymous IP, unfamiliar sign-in properties)।
• ব্যবহারকারী ঝুঁকি — এই অ্যাকাউন্টটি identity নিজেই-এর সাথে যুক্ত কারণের জন্য ফ্ল্যাগ করা হয়েছে (leaked credentials breach corpus-এ পাওয়া গেছে, নিশ্চিত compromise কার্যকলাপ)।

সাইন-ইন ঝুঁকিতে প্রতিক্রিয়া জানানোর একটি Conditional Access নীতি সাধারণত MFA দিয়ে চ্যালেঞ্জ করা উচিত — যদি প্রকৃত ব্যবহারকারী চ্যালেঞ্জটি সম্পন্ন করতে পারে, তাদের মধ্য দিয়ে যেতে দিন। ব্যবহারকারী ঝুঁকিতে প্রতিক্রিয়া জানানোর একটি নীতি একটি পাসওয়ার্ড রিসেট বাধ্য করা উচিত, কারণ credential নিজেই ইতিমধ্যে burned হয়ে গেলে MFA একা সাহায্য করে না।

কেন স্থায়ী admin অ্যাক্সেস বড় সমস্যা

এমনকি airtight Conditional Access সহ, একটি অ্যাকাউন্ট যা স্থায়ীভাবে Global Administrator ধারণ করে তা directory-তে সাদা চোখে দেখা একটি লক্ষ্য। যে কেউ এটি compromise করে তারা অতিরিক্ত কোনো ধাপ ছাড়াই পূর্ণ tenant নিয়ন্ত্রণ উত্তরাধিকার করে। PIM "স্থায়ী" অংশটি সরিয়ে দেয়।

PIM দিয়ে, admin roles eligible হিসাবে বরাদ্দ করা হয় active নয়। ব্যবহারকারীকে স্পষ্টভাবে role সক্রিয় করতে হবে, যা একটি প্রয়োজনীয় justification, ঐচ্ছিক approval workflow, MFA পুনরায়-নিশ্চিতকরণ এবং একটি সময়-সীমাবদ্ধ window — সাধারণত 1 থেকে 8 ঘন্টা — ট্রিগার করে যার পরে role স্বয়ংক্রিয়ভাবে deactivate হয়। কেউই, অ্যাকাউন্ট মালিক সহ, standing Global Admin নেই যদি না তারা সক্রিয়ভাবে এটি ব্যবহার করছে।

ন্যূনতম PIM কনফিগারেশন যা সত্যিই ব্যবহারযোগ্য

• Helpdesk Administrator-এর উপরে প্রতিটি role: eligible, স্থায়ী নয়।
• Global Administrator এবং Privileged Role Administrator: একটি দ্বিতীয় admin থেকে অনুমোদন প্রয়োজন, শুধু self-activation নয়।
• Activation MFA প্রয়োজন, কোনো ব্যতিক্রম নেই।
• সর্বাধিক 4 ঘন্টার activation সময়কাল লোকেদের genuinely আলাদা কাজের সেশনের জন্য পুনরায় সক্রিয় করতে বাধ্য করে, যা cleaner audit trails ও তৈরি করে।
• সমস্ত eligible assignments এ প্রতি 90 দিনে access reviews — অ্যাকাউন্টগুলি একটি প্রকল্পের জন্য যোগ করা হয় এবং অন্যথায় কখনও সরানো হয় না।

দলগুলি এটি কোথায় ভুল করে

সবচেয়ে সাধারণ ব্যর্থতা নীতির ডিজাইন নয়, এটি exclusion list। একটি Conditional Access নীতি ক্রমবর্ধমান "এই ব্যবহারকারীদের বাদ দিন কারণ অ্যাপ MFA সমর্থন করে না" গ্রুপ সহ অবশেষে অর্ধেক tenant বাদ দেয়। exclusions ট্র্যাক করুন একটি backlog আইটেম হিসাবে একটি owner এবং একটি removal তারিখ সহ, একটি permanent bucket নয়।

দ্বিতীয় ব্যর্থতা হল break-glass অ্যাকাউন্ট যা actually পরীক্ষা করা হয় না। দুটি জরুরি অ্যাকাউন্ট, Conditional Access এবং PIM থেকে বাদ দেওয়া, দীর্ঘ random পাসওয়ার্ড offline সংরক্ষিত এবং যেকোনো সাইন-ইনে alerting — এবং কেউ ত্রৈমাসিক এতে লগইন করার চেষ্টা করা উচিত যাতে নিশ্চিত করা যায় যে তারা এখনও কাজ করে।

Conditional Access এবং PIM একটি compliance audit-এর জন্য একটি checkbox নয়। তারা একটি phished credential-এর মধ্যে পার্থক্য একটি inconvenience এবং এটি একটি সম্পূর্ণ tenant compromise। যদি আপনি একটি Blue Team build-out-এর অংশ হিসাবে identity controls mapping করছেন, Korra Studio-এর Cloud এবং Blue Team সেগমেন্টগুলি detection দিকটি কভার করে — Identity Protection ঝুঁকি ইভেন্টগুলি Sentinel-এ actually কেমন দেখায় এবং কীভাবে impossible PIM activation patterns-এ সতর্ক করতে হয়।