مجله بلاگ
سخت‌سازی Active Directory؛ چک‌لیست عملی امنیت دامنه ویندوز
Active Directory در بسیاری از شرکت‌ها مرکز هویت و دسترسی است. ورود کاربران، دسترسی به فایل‌ها، اجرای نرم‌افزارها، تنظیمات رایانه‌ها و مجوز مدیران به سلامت دامنه وابسته است. به همین دلیل، یک حساب مدیریتی ضعیف یا Domain Controller به‌روزنشده می‌تواند مهاجم را از یک رایانه معمولی به کنترل گسترده شبکه برساند.
سخت‌سازی Active Directory یک پروژه یک‌مرحله‌ای نیست. این کار به فهرست دارایی، تفکیک حساب‌ها، مدیریت وصله، سیاست رمز، کنترل دسترسی مدیریتی، ثبت رخداد، بکاپ و آزمون بازیابی نیاز دارد. در این راهنما یک چک‌لیست عملی ارائه می‌کنیم که شرکت‌های کوچک و متوسط بتوانند آن را مرحله‌به‌مرحله اجرا کنند.
چرا Active Directory هدف مهم مهاجمان است؟
مهاجم پس از ورود اولیه معمولاً به‌دنبال Credential، نشست مدیریتی، حساب سرویس و مسیر حرکت جانبی می‌گردد. اگر یک مدیر دامنه با همان حساب روی رایانه کاربران کار کند، Credential او ممکن است در حافظه یا Cache دستگاه باقی بماند. اگر حساب سرویس رمز ثابت و مجوز زیاد داشته باشد، شکستن یا سرقت آن مسیر دیگری ایجاد می‌کند.
کنترل دامنه به مهاجم اجازه می‌دهد سیاست امنیتی را تغییر دهد، حساب بسازد، دسترسی فایل‌ها را توسعه دهد، ابزار دفاعی را تضعیف و باج‌افزار را در مقیاس بالا توزیع کند. مقاله واکنش به باج‌افزار در ۲۴ ساعت اول نشان می‌دهد چرا حفاظت از هویت و بکاپ در مهار حادثه حیاتی است.
معماری پایه امن برای دامنه
| حوزه | حداقل کنترل پیشنهادی | هدف |
|---|---|---|
| Domain Controller | حداقل دو DC، وصله‌شده و محدود | دسترس‌پذیری و کاهش ریسک تک‌نقطه‌ای |
| حساب مدیریتی | حساب جدا از کار روزمره | کاهش سرقت Credential |
| دسترسی مدیریتی | از Jump Server یا PAW | کنترل نشست‌های حساس |
| سرویس‌ها | gMSA یا رمز مدیریت‌شده | حذف رمز ثابت و مشترک |
| بکاپ | System State و نسخه مستقل | بازیابی دامنه پس از خرابی |
| لاگ | ارسال به مقصد مرکزی | تشخیص تغییر و سوءاستفاده |
گام اول: دامنه و دارایی‌های هویتی را مستند کنید
پیش از تغییر باید ساختار Forest، Domain، Site، OU، Trust، Domain Controller، DNS و سرویس‌های وابسته ثبت شود. نسخه سیستم‌عامل، نقش FSMO، وضعیت Replication، آدرس IP، محل فیزیکی یا Host مجازی و زمان آخرین بکاپ برای هر DC مشخص باشد.
فهرست حساب‌ها نیز اهمیت دارد: مدیران، کاربران غیرفعال، حساب‌های سرویس، پیمانکاران، حساب‌های Break Glass و گروه‌های حساس. گروه‌هایی مانند Domain Admins، Enterprise Admins، Schema Admins، Backup Operators و Account Operators باید عضو غیرضروری نداشته باشند.
مستندسازی فقط برای ممیزی نیست. هنگام خرابی یا مهاجرت، تیم باید بداند هر سرویس به کدام حساب و DNS وابسته است. در نصب و راه‌اندازی سرور سازمانی، تحویل نقشه نقش‌ها و حساب‌ها باید بخشی از خروجی پروژه باشد.
گام دوم: حساب‌های مدیریتی را از حساب روزمره جدا کنید
مدیر شبکه نباید با حساب Domain Admin ایمیل باز کند، وب‌گردی انجام دهد یا روی رایانه کاربران وارد شود. برای هر مدیر حداقل دو حساب تعریف کنید: یک حساب معمولی برای کار روزانه و یک حساب مدیریتی برای وظایف مشخص. نام‌گذاری باید قابل‌شناسایی باشد و استفاده از حساب مشترک ممنوع شود.
حساب‌های مدیریتی فقط روی سیستم‌های مجاز Login کنند. با Group Policy می‌توان Logon Locally، Remote Desktop و دسترسی شبکه را محدود کرد. برای عملیات حساس، استفاده از Privileged Access Workstation یا Jump Server مدیریت‌شده ریسک تماس Credential با Endpointهای عادی را کاهش می‌دهد.
گام سوم: اصل کمترین دسترسی را اجرا کنید
عضویت دائمی در Domain Admins برای بسیاری از وظایف لازم نیست. مدیریت کاربران، Help Desk، DNS، Backup و سرورهای مشخص می‌توانند با Delegation محدود انجام شوند. هر نقش باید فقط مجوز مورد نیاز خود را داشته باشد.
- Help Desk فقط Reset Password و Unlock حساب‌های OU مشخص را انجام دهد؛
- مدیر سرور عضو Local Administrators همان سرورها باشد، نه مدیر کل دامنه؛
- مدیر DNS فقط روی Zoneهای لازم مجوز داشته باشد؛
- پیمانکار دسترسی موقت، ثبت‌شده و دارای تاریخ انقضا بگیرد؛
- عضویت گروه‌های حساس به‌صورت ماهانه بازبینی شود.
این رویکرد با اصول Zero Trust در شبکه سازمانی هماهنگ است: هویت معتبر به‌تنهایی نباید مجوز گسترده و دائمی ایجاد کند.
گام چهارم: سیاست رمز و احراز هویت را اصلاح کنید
سیاست رمز باید طول مناسب، جلوگیری از رمزهای شناخته‌شده و کنترل Lockout داشته باشد. اجبار تغییر بسیار مکرر می‌تواند کاربران را به الگوهای قابل‌حدس سوق دهد؛ بنابراین تمرکز باید بر طول، یکتایی، جلوگیری از رمز افشاشده و تغییر هنگام شواهد خطر باشد.
برای مدیران و دسترسی‌های راه دور، احراز هویت چندمرحله‌ای در اولویت است. Active Directory سنتی به‌تنهایی MFA همه سناریوها را فراهم نمی‌کند و ممکن است به راهکار تکمیلی برای VPN، RDP Gateway، سرویس ابری یا ورود مدیریتی نیاز باشد.
حساب‌های Local Administrator نیز باید مدیریت شوند. استفاده از یک رمز یکسان در همه کلاینت‌ها حرکت جانبی را آسان می‌کند. Windows LAPS می‌تواند رمز محلی یکتا و چرخشی برای هر دستگاه ایجاد و دسترسی به آن را محدود کند.
گام پنجم: حساب‌های سرویس را ایمن کنید
حساب سرویس اغلب سال‌ها بدون تغییر باقی می‌ماند و مالک آن مشخص نیست. ابتدا سرویس، سرور، مجوز، آخرین استفاده و مالک تجاری هر حساب را ثبت کنید. حسابی که استفاده نمی‌شود پس از بررسی غیرفعال شود.
برای سرویس‌های سازگار، Group Managed Service Account یا gMSA انتخاب مناسبی است؛ زیرا مدیریت رمز را به دامنه می‌سپارد و نیاز به رمز ثابت را کاهش می‌دهد. حساب سرویس نباید اجازه Interactive Logon داشته باشد و فقط روی سرورهای لازم مجوز بگیرد.
Service Principal Name و Delegation نیز باید بازبینی شوند. تنظیم Kerberos Delegation گسترده می‌تواند مسیر سوءاستفاده ایجاد کند. Unconstrained Delegation فقط در صورت ضرورت اثبات‌شده باقی بماند.
گام ششم: Domain Controllerها را محدود و به‌روز نگه دارید
روی Domain Controller نرم‌افزار غیرضروری نصب نکنید. مرورگر، Office، ابزارهای عمومی و Agentهای ناشناخته سطح حمله را افزایش می‌دهند. دسترسی اینترنتی مستقیم نیز باید محدود باشد و Update از مسیر کنترل‌شده انجام شود.
وصله‌های سیستم‌عامل و اجزای هویتی را در چرخه منظم قرار دهید. ابتدا یک DC، سپس بررسی Replication، DNS، Kerberos و ورود کاربران، و بعد DC بعدی. مقاله مدیریت وصله‌های امنیتی روش حلقه آزمایشی، پنجره نگهداری و برنامه بازگشت را توضیح می‌دهد.
- از نصب هم‌زمان وصله روی همه DCها خودداری کنید؛
- سلامت Replication را پیش و پس از تغییر کنترل کنید؛
- فضای دیسک، Event Log و سرویس‌های AD DS و DNS را بررسی کنید؛
- زمان سیستم‌ها را با منبع معتبر همگام نگه دارید؛
- پروتکل‌ها و Cipherهای قدیمی را پس از آزمون غیرفعال کنید.
گام هفتم: Group Policy را تمیز و قابل‌کنترل کنید
GPOهای زیاد، بدون مالک و دارای تنظیم متناقض عیب‌یابی را دشوار می‌کنند. هر GPO باید نام روشن، توضیح، مالک، دامنه اثر و تاریخ بازبینی داشته باشد. از ویرایش بی‌هدف Default Domain Policy و Default Domain Controllers Policy خودداری و تنظیمات کاربردی را در GPOهای مستقل نگه دارید.
پیش از تغییر گسترده از GPO نسخه پشتیبان بگیرید و روی OU آزمایشی اجرا کنید. Resultant Set of Policy و گزارش GPResult نشان می‌دهند کدام تنظیم واقعاً اعمال شده است. Security Filtering و WMI Filter باید حداقلی و مستند باشند.
گام هشتم: پروتکل‌های قدیمی را شناسایی کنید
NTLM، SMB قدیمی، LDAP بدون امضا و پروتکل‌های رمزنگاری ضعیف ممکن است به‌دلیل نرم‌افزار Legacy فعال مانده باشند. غیرفعال‌سازی ناگهانی می‌تواند سرویس را مختل کند؛ بنابراین ابتدا مصرف آن‌ها را Audit کنید، وابستگی‌ها را بیابید و برنامه اصلاح بنویسید.
| مورد | اقدام اولیه | اقدام نهایی |
|---|---|---|
| SMBv1 | شناسایی دستگاه وابسته | حذف یا جایگزینی |
| NTLM | Audit رخدادها | محدودسازی مرحله‌ای |
| LDAP ساده | شناسایی Client | LDAP Signing/Channel Binding |
| TLS قدیمی | بررسی سازگاری | غیرفعال‌سازی نسخه ضعیف |
گام نهم: DNS و Replication را پایش کنید
Active Directory به DNS وابسته است. DNS اشتباه می‌تواند شبیه خرابی احراز هویت دیده شود. کلاینت‌های دامنه باید DNS داخلی را استفاده کنند و DNS داخلی درخواست‌های بیرونی را به Forwarder معتبر بفرستد. ثبت‌های قدیمی، Zone Transfer و Dynamic Update باید کنترل شوند.
خطاهای Replication، تأخیر Site Link، USN مشکل‌دار و Tombstone قدیمی می‌توانند ناسازگاری هویت ایجاد کنند. هشدار باید پیش از شکایت کاربر فعال شود. مانیتورینگ سرویس‌های هویتی بخشی از پایش زیرساخت است.
گام دهم: رویدادهای امنیتی مهم را جمع‌آوری کنید
لاگ Domain Controller باید به مقصد مرکزی ارسال شود تا مهاجم نتواند با حذف Event Log شواهد را از بین ببرد. حجم زیاد لاگ بدون سناریوی تشخیص مفید نیست. ابتدا رویدادهای باارزش را تعریف کنید:
- ایجاد، حذف یا فعال‌شدن حساب؛
- تغییر عضویت گروه‌های حساس؛
- ورود ناموفق گسترده یا Lockout غیرعادی؛
- تغییر GPO و Audit Policy؛
- درخواست Kerberos غیرعادی؛
- تغییر Trust، Replication یا تنظیم DNS؛
- استفاده از حساب مدیریتی روی Endpoint غیرمجاز.
هشدار باید مسئول رسیدگی، شدت، زمان پاسخ و روش Escalation داشته باشد. اگر صدها هشدار بدون مالک تولید شوند، رخداد واقعی میان نویز گم می‌شود.
گام یازدهم: بکاپ و بازیابی Active Directory را آزمایش کنید
Snapshot ماشین مجازی جایگزین بکاپ System State و برنامه بازیابی Forest نیست. نسخه پشتیبان باید مستقل، محافظت‌شده و دارای حساب مدیریت جدا باشد. حداقل یکی از DCها به‌صورت منظم System State Backup داشته باشد و نگهداری نسخه با RPO سازمان هماهنگ شود.
تیم باید تفاوت بازیابی غیرمعتبر و Authoritative Restore را بداند. سناریوی حذف تصادفی OU، خرابی یک DC و آسیب گسترده Forest با هم متفاوت‌اند. تمرین بازیابی در محیط ایزوله، اعتبار بکاپ و زمان واقعی بازگشت را مشخص می‌کند.
در طراحی بکاپ از اصول قانون ۳-۲-۱ استفاده کنید و دسترسی سرویس بکاپ را از حساب‌های معمول دامنه جدا نگه دارید.
برنامه اجرایی ۳۰، ۶۰ و ۹۰ روزه
۳۰ روز اول: دید و کاهش ریسک فوری
- فهرست DCها، مدیران و حساب‌های سرویس را تکمیل کنید؛
- کاربران غیرفعال و عضویت غیرضروری Domain Admins را بررسی کنید؛
- حساب مدیریتی را از حساب روزمره جدا کنید؛
- سلامت Replication، DNS، Patch و بکاپ را کنترل کنید؛
- LAPS و MFA برای نقاط پرریسک را برنامه‌ریزی کنید.
روز ۳۱ تا ۶۰: کنترل دسترسی و Legacy
- Delegation نقش‌ها را جایگزین مجوز گسترده کنید؛
- gMSA را برای سرویس‌های سازگار اجرا کنید؛
- مصرف NTLM، SMBv1 و LDAP ضعیف را Audit کنید؛
- GPOها را نام‌گذاری، مستند و آزمایش کنید؛
- لاگ‌های مهم را به مقصد مرکزی بفرستید.
روز ۶۱ تا ۹۰: تاب‌آوری و آزمون
- Jump Server یا PAW را برای مدیریت حساس فعال کنید؛
- دسترسی اضطراری و حساب Break Glass را آزمایش کنید؛
- بازیابی System State را در محیط ایزوله تمرین کنید؛
- سناریوی حمله به Credential را رومیزی اجرا کنید؛
- گزارش KPI و برنامه بازبینی فصلی بسازید.
شاخص‌های سنجش امنیت دامنه
- تعداد اعضای گروه‌های مدیریتی حساس؛
- درصد مدیرانی که حساب روزمره جدا دارند؛
- تعداد حساب سرویس با رمز ثابت یا منقضی‌نشونده؛
- سن آخرین وصله هر Domain Controller؛
- تعداد خطاهای Replication و DNS؛
- زمان غیرفعال‌کردن حساب نیروی جداشده؛
- تاریخ آخرین آزمون بازیابی موفق؛
- تعداد پروتکل Legacy و استثناهای بدون تاریخ پایان.
اشتباه‌های رایج در سخت‌سازی Active Directory
- استفاده روزمره از Domain Admin؛
- اشتراک حساب مدیریتی میان چند نفر؛
- اتکا به Snapshot به‌عنوان تنها بکاپ؛
- نصب ابزارهای عمومی روی Domain Controller؛
- غیرفعال‌سازی ناگهانی پروتکل Legacy بدون Audit؛
- نداشتن DC دوم یا آزمون Failover؛
- حساب‌های سرویس با رمز ثابت و مجوز زیاد؛
- لاگ‌گیری بدون هشدار و مسئول رسیدگی؛
- GPOهای بدون توضیح، مالک و نسخه پشتیبان.
پرسش‌های متداول
آیا دو Domain Controller برای شرکت کوچک لازم است؟
اگر احراز هویت، DNS و سرویس‌های اصلی به دامنه وابسته‌اند، DC دوم ریسک توقف ناشی از خرابی یا نگهداری را کاهش می‌دهد. هر دو باید مستقل، پایش‌شده و دارای بکاپ مناسب باشند.
آیا Domain Admin باید فقط برای نصب نرم‌افزار استفاده شود؟
خیر. نصب نرم‌افزار روی کلاینت معمولاً با مجوز Local Admin یا ابزار مدیریت مرکزی انجام می‌شود. Domain Admin باید برای عملیات محدود دامنه استفاده شود.
آیا تغییر دوره‌ای رمز حساب سرویس کافی است؟
خیر. مجوز، محل استفاده، امکان Interactive Logon و مالک حساب نیز باید کنترل شوند. در صورت امکان gMSA انتخاب بهتری است.
چطور بدون اختلال پروتکل‌های قدیمی را حذف کنیم؟
ابتدا Audit و گزارش مصرف را فعال کنید، Clientهای وابسته را اصلاح کنید، سپس محدودسازی را روی گروه آزمایشی و در نهایت کل دامنه اعمال کنید.
هر چند وقت یک‌بار گروه‌های مدیریتی بازبینی شوند؟
برای گروه‌های حساس بازبینی ماهانه مناسب است و پس از هر تغییر شغلی یا پایان همکاری باید فوری انجام شود. نتیجه بازبینی باید ثبت شود.
جمع‌بندی
امنیت Active Directory از چند کنترل هماهنگ ساخته می‌شود: حساب مدیریتی جدا، کمترین دسترسی، DC وصله‌شده، حساب سرویس مدیریت‌شده، GPO تمیز، حذف تدریجی پروتکل Legacy، لاگ متمرکز و بکاپ قابل‌بازیابی. اجرای مرحله‌ای این کنترل‌ها ریسک را کاهش می‌دهد و امکان عیب‌یابی را حفظ می‌کند.
اگر ساختار دامنه، حساب‌های مدیریتی و وضعیت بکاپ شما مستند نیست، ارزیابی اولیه می‌تواند مسیرهای پرریسک و اولویت اصلاح را مشخص کند. نصیر ارتباط می‌تواند ممیزی Active Directory، طراحی برنامه سخت‌سازی، اجرای کنترل‌ها و پایش دوره‌ای را در قالب خدمات سرور و پشتیبانی سازمانی انجام دهد.
