DC ها یک Physical Storage را برای AD DS Datastore فراهم می‌کنند. علاوه بر آن؛ با فراهم سازی سرویس‌ها و داده‌ها به سازمان ها این اجازه را می دهند که به صورت موثر سرورها، Workstation ها، کاربران و نرم افزار ها را مدیریت نمایند. اگر یک نفوذگر با دسترسی بالا به DC ها متصل شود، آن کاربر اجازه دستکاری، تخریب و نابود سازی AD DS Database و در واقع تمامی سیستم ها و حساب‌های کاربری تحت مدیریت Active Directory را خواهد داشت. از انجائیکه DC ها قابلیت خواندن و نوشتن برروی AD DS Datastore را خواهند داشت، به خطر افتادن DC به این معنا خواهد بود که Active Directory Forest دیگر نمی‌تواند قابل اعتماد باشد مگر آنکه امکان Recover کردن با استفاده از یک Backup مناسب وجود داشته باشد. در بسیاری از سناریو های به مخاطره افتادن دامین کنترلر ها، بازگرداندن نسخ پشتیبان قادر به حل مشکلات ایجاد نمی باشد. در ادامه لیستی از برخی از اقدامات اولیه جهت امن سازی دامین کنترلر ها، ذکر شده است.

مدت زمانی که نفوذگر می‌تواند با سطح دسترسی بالا به Active Directory ارتباط داشته باشد اهمیت ندارد، بلکه نوع برنامه‌ریزی نفوذگر برای لحظه ای که دسترسی حاصل می شود حائز اهمیت می‌باشد. عموماً با توجه به میزان تخصص نفوذگر تغییرات و یا حتی خسارت‌های جبران ناپذیر به AD DS Datastore فقط بین چند دقیقه تا حداکثر یک ساعت انجام می‌پذیرد. لذا اتخاذ برنامه واکنش سریع به نفوذ امر دیگری است که اهمیت بسیار بالایی دارد.

۱- امنیت فیزیکی برای Domain Controller های مراکز داده

Physical Domain Controllers in Datacenter

در دیتاسنترها، DCهای فیزیکی باید در رک‌های اختصاصی و یا در بخش‌هایی جدا از مجموعه عمومی سرور‌ها نصب شوند. در صورت امکان DC ها باید با Trusted Platform Module (TPM) پیکربندی شده و تمام Volumeها با Bitlocker Drive Encryption رمزنگاری شوند. این امر باعث پایین آمدن Performance می‌شود، اما از Directory در مقابل خطراتی همچون خارج کردن دیسک از سرور محافظت می‌کند.

Bitlocker همچنین می‌تواند سیستم را در مقابل حملاتی همچون Rootkit ها محافظت کند. دلیل این امر این است که در صورت تغییر در فایل‌های بوت باعث رفتن سرور به حالت Recovery شده و بنابراین Original Binary می‌تواند Load شود.

Virtual Domain Controllers

در صورتیکه DCها به صورت مجازی پیاده سازی شده باشند، باید اطمینان حاصل کرد که بر روی Host‌های فیزیکی جداگانه به دور از سایر ماشین‌های مجازی قرار گرفته باشند. در صورتیکه از Third-Party Virtualization Platform ها استفاده گردد، بهتر است DC های مجازی را بر روی HyperV سرور‌ها در Windows Server 2012، پیاده سازی شود. این امر باعث کاهش سطح حملات خواهد شد. همچنین بهتر است Storage های DC‌های مجازی جداسازی شود، این امر از دسترسی Storage Administrator‌ها به فایل‌های ماشین مجازی جلوگیری می‌کند.

۲- امنیت فیزیکی برای Domain Controller های شعب

Physical Domain Controller

عموماً در محیط‌هایی که فقط چندین سرور قرار دارند، امنیت فیزیکی در سطحی همچون امنیت در دیتاسنتر نیست. Domain Controller ها باید با TPM و Bitlocker پیکربندی شوند. در صورتیکه DCها در اتاق‌های امن تر در Branch Office قرار نگرفته‌اند، بهتر است از Read-Only Domain Controllers (RODC)‌ها استفاده شود.

Virtual Domain Controller

در صورت امکان باید DCهای مجازی در Branch Office بر روی Physical Host‌های جداگانه ای قرار گیرند. در صورتیکه این امر محقق نمی شود باید TPM و Bitlocker بر روی Host ها فعال سازی شود. بر اساس اندازه و امنیت Branch Office بهتر است از RODC ها در Branch ها استفاده شود.

سایت های جانبی با امنیت فیزیکی پایین

در صورتیکه که زیرساخت شامل Location‌هایی باشد که تنها می‌توان یک سرور فیزیکی راه اندازی نمود، باید سروری که قابلیت اجرای Virtualization Workload را دارد در Remote Location راه اندازی شود. همچنین باید TPM و Bitlocker بر روی تمام Volume‌های سرور پیکربندی شود. در این سناریو باید یک RODC بر روی یکی از ماشین‌های مجازی راه‌اندازی شود.

۳- Domain Controllers Operating System

باید تمامی DCها به آخرین ورژن ویندوز سرور به‌روز رسانی گردند و DC‌ها با سیستم عامل‌های قدیمی از سرویس دهی خارج شوند. با به‌روز رسانی سرورها به سیستم عامل‌‌های به‌روز می‌توان از قابلیت‌های جدید و امنیت بالاتر آنها بهره‌مند گردید. DC ها باید به جای Upgrade شدن به صورت Fresh نصب و Promote شوند. با این روش می توان اطمینان حاصل نمود که فایل‌ها و تنظیمات قدیمی سهواً بر روی DC ها باقی نخواهد ماند.

۴- Secure Configuration of Domain Controller

از ابزارهای رایگان و بعضی از ابزارهائی که به صورت پیش فرض بر روی سیستم نصب شده‌اند، می توان برای ایجاد تنظیمات امنیتی پایه استفاده نمود.

۵- Security Configuration Wizard

تمامی DCها باید به محض ایجاد، Locked Down (قفل) شوند. این امر می تواند از طریق Security Configuration Wizard (که به صورت Native در ویندوز سرور، پیکربندیِ Service، Registry، System و WFAS Settings را بر روی DC ها عهده دار است)، محقق شود.

۶- AppLocker

Applocker و یا سایر نرم افزار های Whitelisting باید به منظور پیکربندی سرویس ها و نرم افزار هایی که مجاز به اجرا شدن بر روی DC ها می باشند، مورد استفاده قرار گیرند. این نرم افزار ها و سرویس ها باید تنها شامل موارد مورد نیاز برای کامپیوتر هایی که نقش AD DS را بر عهده دارند، باشد.

۷- RDP Restrictions

Object‌های Group Policy که به تمامی OUهای DC ها در Forest لینک شده‌اند، باید به گونه ای پیکربندی شوند تا اجازه RDP Connection تنها برای سیستم‌ها و کاربران Authorized شده صادر گردد. این امر از طریق ترکیب User Rightها و تنظیمات WFAS محقق شده و باید در GPO‌ها اجرایی شود.

۸- Patch and Configuration Management for Domain Controllers

اگرچه این نکته ممکن است تا حدی مغایر با منطق باشد، اما باید DCها و سایر بخش‌های بحرانی زیرساخت جدا از زیرساخت عمومی ویندوز Patch شوند. معمولا از Enterprise Configuration Management Softwareها برای تمامی کامپیوتر ها در زیرساخت مورد استفاده قرار می گیرد، به خطر افتادن Configuration Management Software، می تواند باعث به خطر افتادن و تخریب تمامی اجزای زیرساخت تحت مدیریت با آن نرم افزار شود. اما با جداسازی Patch & system Management برای DC ها می توان باعث کاهش نصب نرم افزار ها بر روی DC شد.

۹- Blocking Internet Access for Domain Controllers

یکی از بررسی‌هایی که معمولا به عنوان بخشی از Active Directory Security Assessment انجام می‌شود، استفاده و تنظیمات Internet Explorer در DC‌ها می‌باشد. IE و سایر Web Browser‌ها نباید در DC‌ها مورد استفاده قرار گیرند. همان طور که پیش تر اشاره شده است، Browse کردن اینترنت و یا اینترانت آلوده، با استفاده از اکانت با دسترسی بالا در زیرساخت ویندوز، خطرات عظیمی را برای امنیت سازمان به همراه خواهد داشت. مهاجمین می‌توانند با استفاده از بدافزارها به هر آنچه برای نابودی Active Directory نیاز دارند، دست یابند. استفاده از Internet Explorer در DC‌ها باید نه تنها از طریق Policy ها بلکه با استفاده از کنترل‌های تکنیکی ممنوع شود و DC ها نباید اجازه دسترسی به اینترنت را پیدا کنند. اگر DC ها نیازمند Replicate شدن در بین site ها باشند، باید یک کانکشن امن مابین سایت‌ها برقرار شود.

۱۰- Firewall Restriction

Firewall ها باید به منظور بلاک کردن کانکشن‌های outbound و inbound دامین کنترلر ها،به درستی پیکربندی شود. DC ها ممکن است نیازمند Replication مابین سایتها باشند و Firewall ها باید به گونه ای پیکربندی شوند که Interstice Communication با مشکل رو به رو نشود. Replication در صورت وجود Firewall دارای پیچیدگی های بسیاری می باشد و لازم است طراحی مناسب با توجه به ساختار شبکه صورت گیرد. (بیشتر بخوانید: Replication روی Firewall)

۱۱- Active Directory Quota

با استفاده از AD Quota می‌توان تعداد Objectهایی را که یک Security Principal وظیفه مالکیت و ایجاد آنها را بر عهده دارد، محدود کرد. از AD Quota می توان به منظور کاهش خطر حملات Denial OF Service (DoS) روی Directory Service استفاده نمود. به عنوان مثال می توان مالک یک Organizational Unit (OU) را محدود به ساخت تنها صد کاربر جدید نمود. در صورتیکه Security Principal که مجوز ایجاد Objectها را در Directory دارد، Compromise شود و AD Quota راه اندازی نشده باشد، مهاجم می تواند آن قدر Object ایجاد کند تا دیسکی که NTDIS.dit را در برگرفته است کاملا پر شود. با توجه به این موضوع می‌توان Directory Service را از حملات DoS محافظت نمود. AD Quota را می‌توان برای Security Principal‌ها در هر Directory Partition مشخص نمود. این Partition ها شامل Application Partition، Domain Partition و Configuration Partition می شود.

۱۲- Fine granted password policies for administrators

با استفاده از امکان Fine-Granted Passwords این امکان فراهم شده است تا کاربران با دسترسی های مدیریتی و Privilaged Users‌ها، دارای Password Policy‌های پیچده‌تر و مستحکم‌تری نسبت به کاربران نهایی باشند. علاوه بر آن، کاربرانی که عضو گروه‌های Local Administrators روی کامپیوتر‌های مختلفی از Domain می باشند نیز ، لازم است دارای Password Policy های مستحکم تری باشند.

۱۳- Active Directory Recycle Bin

آمار نشان می‌دهد، بیش از ۷۰% از دلایل Restore شدن اشیاء Active Directory به دلیل اشتباهات سهوی حذف اطلاعات صورت می‌گیرد. با این وجود استفاده از Active Directory Recycle Bin در حذف شدن های بدخواهانه نیز سبب ایجاد راهکار Recovery با هزینه و زمان کمتر می‌گردد.

۱۴- مدیریت Patch ها و به روز رسانی سیستم عامل

همواره لازم است به روز رسانی های سیستم عامل در بازه های زمان مناسب نصب گردند. سازمان‌های کوچک معمولا از Windows Update و یا Windows Server Update Service (WSUS) به منظور مدیریت و توسعه Update ها به سیستم عامل های ویندوز استفاده می‌کنند. این در حالیست که سازمان های بزرگ تر، از راهکار هایی مانند System Center Configuration Manager استفاده قرار می‌دهند. علاوه بر ایجاد مکانیزمی جهت Deploy کردن Updateهای سرورها، Workstationها، باید Deploymentهای جداگانه‌ای نیز برای سیستمهای Highly Secure مانند Domain Controllerها، Certificate Authorityها و Hostهای مدیریتی در نظر گرفته شود. با جداسازی این سیستم‌ها از زیرساخت عمومی تحت مدیریت، اگر نرم‌افزارهای مدیریتی و یا Service Accountها به خطر بیفتند، مشکل به سادگی در سیستم‌های Secure زیرساخت توسعه نمی‌یابد.

۱۵- استفاده از Smart Card

حتی اگر سازمان در حال حاضر از Smart Card به صورت عمومی استفاده نمی‌کند، باید برای Privileged Accountها، Hostهای مدیریتی امن اجرایی شود. Hostهای مدیریتی باید برای Log‌on با استفاده از Smart Card برای تمامی حساب های کاربری پیکربندی شوند.

Computer Configuration\Policies\Windows Settings\Local Policies\Security Options\Interactive logon: Require smart card

این تنظیمات باعث می‌شود در تمامی Interactive Logonها نیاز به وجود Smart Card باشد. باید Hostهای مدیریتی امن شده را به گونه‌ای پیکربندی نمود تا تنها به حساب‌های کاربری Authorized شده اجازه Logon داده شود.

Computer Configuration\Policies\Windows Settings\Local Policies\Security Settings\Local Policies\User Rights Assignment