‏ادمین Intune همون‌قدر خطرناکه که Domain Admin

این مقاله بخش اول یه سری دوقسمتیه از Carlos Perez در TrustedSec که سراغِ یه نقطه‌کورِ امنیتی می‌ره: نقش‌های مدیریتیِ پلتفرم‌های مدیریت دستگاه. نویسنده که تو تیم واکنش به حادثه (Incident Response) کار می‌کنه می‌گه به‌جای این‌که فقط روی چطورِ حمله‌ها تمرکز کنه، بیشتر به چرا اصلاً این حمله‌ها ممکن می‌شن فکر می‌کنه و جوابش همین نقش‌های نادیده‌گرفته‌شده‌ست.

نکتهٔ اصلی اینه: وقتی حرف از نقش‌های پرقدرت می‌شه، همه فوری یادِ Domain Admin و Tenant Global Admin می‌افتن، ولی کسی که MDM (مدیریت دستگاه‌های موبایل) مثل Intune رو اداره می‌کنه عملاً قدرتی هم‌سطح اون‌ها داره و خیلی وقت‌ها بیشتر. به گفتهٔ نویسنده، یه ادمین Intune می‌تونه روی همهٔ دستگاه‌های ثبت‌شده اسکریپت اجرا کنه که با دسترسیِ SYSTEM بالا می‌آد، baseline‌های امنیتی و قوانین فایروال رو عوض کنه، نرم‌افزار (از جمله ابزارهای امنیتی) رو بی‌صدا نصب یا حذف کنه و از همه مهم‌تر، دستورِ پاک‌سازیِ کامل (remote wipe) رو روی کلِ ناوگان دستگاه‌ها بفرسته.

نویسنده می‌گه الگوی تکراری‌ای که تو ده‌ها محیط دیده همینه: حساب‌های مدیریتی از حساب کاریِ روزمره جدا نیستن (همون حسابی که ایمیل و فیشینگ می‌گیره)، ورک‌استیشنِ مدیریتیِ اختصاصی (PAW) وجود نداره، نقشِ ادمین دائماً فعاله نه به‌صورت به‌موقع (JIT)، و قابلیتِ تأیید چندادمینه (Multi-Admin Approval) برای کارهای مخرب فعال نیست. یه نکتهٔ خطرناکِ دیگه هم app registrationهای پراختیار در Entra ID هستن که با مجوزهای Graph مثل DeviceManagementConfiguration.ReadWrite.All عملاً کنترلِ کاملِ Intune رو دارن و معمولاً برای اتوماسیون ساخته شدن و بعد فراموش شدن.

به گفتهٔ نویسنده این فقط مشکلِ Intune نیست؛ همین ریسک برای SCCM/MECM، Jamf Pro، VMware Workspace ONE، مدیریتِ دستگاهِ Google Workspace، ادمین‌های مجازی‌سازی مثل vCenter و Hyper-V، ادمین‌های خط لولهٔ CI/CD و ادمین‌های زیرساختِ بک‌آپ هم صدق می‌کنه. نویسنده می‌گه همهٔ این نقش‌ها باید شناسایی، فهرست و مثل Domain Admin کنترل بشن.

بخش عملیِ مقاله مجموعه‌ای از توصیه‌هاست. اول از همه این‌که نقش ادمین Intune باید Tier 0 حساب بشه، هم‌سطحِ Global Admin. بعدش MFAِ مقاومِ در برابر فیشینگ مثل کلیدهای FIDO2 یا احرازِ گواهی‌محور، چون پراکسی‌های فیشینگِ adversary-in-the-middle می‌تونن توکنِ نشست رو بعد از MFAِ معمولی بدزدن. مهم‌ترین کنترل به نظر نویسنده، فعال‌کردنِ Multi-Admin Approval برای کارهای مخربه؛ این‌طوری یه حساب لو رفته نمی‌تونه به‌تنهایی دستور wipe بده و درخواست تا تأییدِ یه ادمینِ دوم تو صف می‌مونه و به تیم فرصتِ واکنش می‌ده.

بقیهٔ توصیه‌ها هم همین خط رو ادامه می‌دن: استفاده از PIM برای فعال‌سازیِ زمان‌دارِ نقش‌ها (JIT) همراه با نقش‌های سفارشیِ کم‌اختیار و scope tag (JEA) تا دامنهٔ خرابی محدود بمونه، محدودکردنِ دسترسی به پورتالِ Intune با Conditional Access فقط از روی دستگاه‌های سازگار و PAW، نگه‌داشتنِ حداقل دو PAW که یکی‌شون از MDM خارج باشه تا یه wipeِ سراسری مسیرِ بازیابی رو از بین نبره، ممیزیِ منظمِ app registrationهای Graph و چرخشِ مرتبِ secretها، سفت‌کردنِ استقرارِ اسکریپت و سیاست با امضای کد و workflowِ تأیید، سخت‌کردنِ ثبت دستگاه (enrollment)، و در آخر مانیتورینگ و هشدار روی کارهای پرریسک تو SIEM مثل Microsoft Sentinel. نویسنده می‌گه این‌ها اختیاری نیستن، بلکه حداقلِ معماریِ لازم برای دووم آوردن در برابر یه حملهٔ امروزیه.

نکات کلیدی:

• نقشِ ادمینِ پلتفرم‌های MDM مثل Intune عملاً قدرتی هم‌سطح یا بیشتر از Domain Admin داره ولی معمولاً تو مدل تهدید جا می‌مونه.
• یه حساب لو رفتهٔ ادمین Intune می‌تونه اسکریپتِ SYSTEM پخش کنه و کلِ ناوگان دستگاه‌ها رو remote wipe کنه.
• app registrationهای Graph با مجوزِ DeviceManagement*.ReadWrite.All کنترلِ کاملِ Intune رو دارن و اغلب فراموش می‌شن.
• مهم‌ترین کنترل‌ها: رفتارِ Tier 0، MFAِ مقاومِ فیشینگ، Multi-Admin Approval برای wipe، و دسترسیِ به‌موقع (PIM/JIT) با نقش‌های کم‌اختیار.
• این ریسک فقط Intune نیست؛ SCCM، Jamf، vCenter، خط لولهٔ CI/CD و زیرساختِ بک‌آپ هم همین‌طورن.