بررسی روش های ایمن سازی زیرساخت اکتیو دایرکتوری

سرویس اکتیو دایرکتوری به عنوان زیرساخت اصلی اکثر سازمان های مالی و بانکی سراسر جهان معرفی گردیده است که دارای ملاحظات قابل توجهی در زمینه امنیت کاربران در منابع سازمان می باشد. به دلیل حساسیت و اهمیت سرویس فوق، امنیت اطلاعات در ساختار از اهمیت بالایی برخوردار است. بدلیل اهمیت موضوع فوق، در این مقاله به روشهای ایمن سازی این ساختار پرداخته خواهد شد.

لیست موارد
این لیست شامل 24 مورد اصلی بوده که در ابتدای امر به معرفی آنها پرداخته و سپس توضیح مربوط به هرکدام از آنها ارائه خواهد شد. لازم به ذکر است که اکثر موارد موجود در لیست فوق در حال حاضر در اغلب سازمان ها پیاده سازی گردیده اند.

  1. مستند سازی موجودیت ها
  2. کنترل نمودن بار مدیریتی
  3. محدود کردن تعداد کاربران Admin
  4. آزمایش و تست تنظیمات Group Policy
  5. استفاده از حساب های کاربری مجزا برای موارد مدیریتی
  6. محدود کردن عضویت در گروه های Built-in
  7. استفاده از ترمینال سرور مجزا برای موارد مدیریتی
  8. غیرفعال نمودن کاربر Guest و تغییر نام کاربر Administrator
  9. محدود کردن دسترسی به کاربران Administrator
  10. مراقبت از رمزعبور DSRM
  11. پیاده سازی سیاست های رمزعبور قدرتمند
  12. محافظت از رمز عبور حساب های کاربری سرویس
  13. اطمینان از ایمن بودن هر کنترل کننده دامنه (DC) به صورت فیزیکی
  14. کمینه سازی سرویس های غیر ضروری و پورتهای باز
  15. امن نمودن منبع زمان کنترل کننده دامنه (DC)
  16. ممیزی رخدادهای مهم
  17. استفاده از IPSec
  18. ذخیره نکردن مقادر Hash پروتکل LAN Manager
  19. مدیریت وصله های ترمیمی
  20. عدم دسترسی به اینترنت برای سرویس های حساس
  21. تمهیدات لازم جهت ایمن سازی میزبانهای مدیریتی (Administrative Hosts)
  22. استفاده از تکنیک Authentication Mechanism Assurance
  23. محدود نمودن نرم افزارهای اجرایی بر روی کنترل کننده های دامنه با استفاده از Applocker
  24. اعطای سطح دسترسی برحسب روشهایی مانند RBAC

logo-active-directoryجزئیات

مستند سازی موجودیت ها
اولین قدم در زمینه ایمن سازی زیرساخت اکتیو دایرکتوری مستند سازی پیکربندی موجود است. اگرچه این مرحله ممکن است تا حدودی پیش پا افتاده به نظر برسد، اما تا زمانی که نقطه حال حاضر پروژه مشخص و شفاف نباشد، امکان حرکت به جلو موجود نخواهد بود. یکی از نقاط مناسب برای شروع این فعالیت، ساختارهای سطح بالا مانند Forest و پیکربندی دامنه ها، مستند سازی توپولوژی سایت ها مانند لیست کردن سایت ها می باشد. مستند سازی سیاست های دامنه (GPO) نیز از جمله مواردی است که رعایت نمودن آن بسیار ضروری بوده و در ساختار حائز اهمیت می باشد. این سند علاوه بر اینکه مواردی مانند سیاست های مرتبط به رمزعبور (Password Policies) و سیاست های ممیزی (Audit Policies) را ارائه می دهد، باید امکان بررسی اینکه سیاست های فوق به چه کسانی اعمال شده و کدام گروه از کاربران امکان تغییر آن را دارند را فراهم آورد.
همچنین باید تمام تغییرات اعمال شده مانند تغییرات Schema به طور کامل مستند سازی شوند. علاوه بر موارد فوق باید نام کنترل کننده دامنه (DC)ها، نسخه سیستم عامل آنها، نرم افزارهای امنیتی مانند آنتی ویروس، نحوه تهیه نسخه پشتیبان ذکر گردند تا در موقعیت های حیاتی، کمبود این اطلاعات احساس نشود.

کنترل نمودن بار مدیریتی
در صورتی که به زیرساخت اکتیودایرکتوری مانند یک هرم بنگریم، امنیت در آن دقیقا از نقاط بالایی شروع شده و برقرار می گردد. کنترل نمودن وظایف مدیریتی هر دامنه مهم ترین و شاید دشوارترین مرحله در برقراری امنیت باشد. پیشنهاد می گردد دسترسی های مدیریتی هر دامنه و گروه مدیریت آن دامنه (Domain Admins) در اختیار مدیران Forest باشد تا از بروز نا همسانی در ساختار جلوگیری شود. باید در نظر داشت که دسترسی مدیریتی به حتی یک کنترل کننده دامنه (DC) در دامنه ها ممکن است موجب بروز نا همسانی گردد. در صورتی که مدیریت دامنه ها در اختیار گروه مجزایی قرار دارد، باید رابطه ای نزدیک با آن گروه ایجاد شده و قوانین و مقرراتی برای مدیریت ارائه گردد تا تمام گروههای مدیریتی از این مقررات یکسان تبعیت نمایند.

محدود کردن تعداد کاربران Admin
در تمام مدت باید در نظر داشت که تعداد کاربران گروه Admin در ساختار کمینه گردد. اگرچه ساختار امنیتی اکتیو دایرکتوری حال حاضر با ساختار گذشته خود در NT کاملا متفاوت بوده و دارای تغییرات زیادی می باشد اما همچنان یک نقطه ضعف اصلی در این ساختار به چشم می خورد که آن عدم امکان مدیریت کامل یک کنترل کننده دامنه (DC) بدون نیاز به عضویت در گروه Domain Admin می باشد. تحت هیچ شرایط پیشنهاد نمی گردد که وظایف مدیریتی خاص هر کنترل کننده دامنه (DC) به عهده گروه و افرادی واگذار گردد که در آینده مجبور باشیم آنها را به عضویت در گروه Domain Admins در آوریم. به جای اعطای سطح دسترسی Domain Admin به اپراتورهای رایانه راه حلی مناسبی با ترکیبی از نر افزارهای موجود در بازار و پیاده سازی سیاست های امنیتی ارائه کنید.

آزمایش و تست تنظیمات Group Policy
تنظیمات و سیاست های دامنه (GPO) به دلیل اهمیت بالایی که در امنیت ساختار دارند باید حتما به صورت تست پیاده سازی شوند تا از صحت عملکرد آنها اطمینان حاصل شود. همچنین پیشنهاد می شود سیاست هایی که در دامنه اعمال شوند را ابتدا در OU های خاص اعمال کرده و پس از بررسی نتایج و مثبت بودن آن، در کل دامنه اعمال گردد.

استفاده از حساب های کاربری مجزا برای موارد مدیریتی
بعد از اینکه تعداد کاربران Administrator در ساختار کمینه گردید، باید اطمینان حاصل کرد که تمام کاربرانی که فعالیتی انجام می دهند که نیاز به سطح دسترسی بالاتری دارند، باید از حساب کاربری خاص دیگری، مجزا از حساب کاربری خود به این منظور استفاده نمایند. این حسابهای کاربری مجزا باید از روش نامگذاری متفاوتی استفاده نموده و در OU مشخصی قرار داشته باشند تا بتوان به راحتی به آن ها سیاست های خاصی اعمال گردد. همچنین می توان این کاربران را گروه بندی کرده و با نامگذاری خاص مانند HQAccount Admins مشخص نماییم و بعد از آن گروه ذکر شده را به عضویت Account Operators در آوریم.

محدود کردن عضویت در گروه های Built-in
سناریویی را در نظر بگیرید که یک کاربر با سطح دسترسی مدیریتی غیر مجاز (Rogue Administrator) خود را به عضویت گروه مدیران دامنه (Domain Admins) در آورد. در آن صورت قادر خواهد بود تا مقاصد خرابکانه خود را پیاده سازی نماید. استفاده از سیاست های موجود برای کنترل نمودن این امر مانند RestrictedrGroups این اطمینان را به ما می دهد که کاربرانی که عضو گروههای حساس مانند Domain Admins و Schema Admins هستند به صورت دائم و در فاصله های زمانی 5 دقیقه ای مجددا بررسی می شوند و درصورت اضافه شدن شخص دیگری به این گروه ها، لیست به حالت پیش فرض خود بازگردد.

استفاده از ترمینال سرور مجزا برای موارد مدیریتی
بدلیل دسترسی بالای کاربران مدیر به کنترل کننده دامنه (DC)ها ، توپولوژی سایت ها و Schema پیشنهاد می شود که کاربران فوق از یک سیستم مرکزی جهت اتصال به رایانه های Server استفاده نمایند. پیاده سازی این روش باعث بوجود آمدن یک نقطه مرکزی جهت ارتباطات می شود. اما نکته ای که باید در این روش مورد توجه قرار گیرد این است که سیستم فوق باید از لحاظ امنیتی کاملا واکسینه شده و فایل های بروزرسانی سیستم عامل به طور متناوب بر روی سیستم نصب شده و نرم افزارهای امنیتی سیستم کاملا بروز باشد.

غیرفعال نمودن کاربر Guest و تغییر نام کاربر Administrator
این اقدام یکی از اقدامات اصلی جهت ایمن سازی ساختار اکتیو دایرکتوری بر علیه حملات هکر ها می باشد. علاوه بر غیرفعال نمودن کاربر Guest و تغییر نام کاربر Administrator، فیلد Description انها نیز باید تغییر گردند تا نشان دهنده سطح دسترسی هر کدام از آنها نباشد.

محدود کردن دسترسی به کاربران Administrator
علاوه بر گروه مدیران دامنه (Domain Admins) کاربران عضو گروه مدیران محلی نیز از اهمیت بالایی برخوردار هستند. باید اطمینان حاصل نمود که رمز عبور کاربران فوق نیز در اختیار همه قرار نگیرد و تنها کاربرانی که مجاز به مدیریت سیستم ها هستند دارای رمز عبور باشند.

مراقبت از رمزعبور DSRM
این رمز عبور که منحصرا به هر کدام از کنترل کننده دامنه (DC) ها اختصاص داده می شود، از اهمیت ویژه ای در اکتیو دایرکتوری برخوردار است. بهترین پیشنهاد برای ایمن سازی این رمز عبور راهکاری به جز تغییر متوالی این رمز عبور در فاصله های زمانی مشخص نیست چرا که فاش شدن این رمز عبور می تواند روند دستیابی به پایگاه داده اکتیودایرکتوری (NTDS.DIT) بسیار هموار سازد.

پیاده سازی سیاست های رمزعبور قدرتمند
اگرچه تاکنون هر کدام از ما به قابلیت ها و امنیت یک رمز عبور قدرتمند پی برده ایم، درک مفهوم این موضوع و مجاب کردن کاربران به استفاده از رمز عبور قدرتمند کار دشواری خواهد بود. اما با توجه به اینکه امنیت در ساختار از اهمیت بسیار بالاتری برخورداد است، باید در مجاب کردن کاربران به استفاده از رموز عبور قدرتمند و پیچیده کوشش ورزید.

محافظت از رمز عبور حساب های کاربری سرویس
همانطور که از نام این حساب های کاربری پیداست، برای راه اندازی سرویس های مورد نیاز در ساختار مانند SQL و غیره از این حساب های کاربری استفاده می شود. اما نکته ای که از لحاظ امنیتی در این حسابهای کاربری حائز اهمیت است Expire شدن رمزعبور این حسابهای کاربری است. اکثر مدیران عموما برای حساب های کاربری مرتبط به سرویس امکان Expire شدن آنها را غیر فعال می کنند تا درگیر تعویض متناوب رمز عبور نشوند. اگر چه رویارویی با این مشکل دشواری های خاص خود را دارد، اما راهکارهایی به منظور ایمن سازی این حساب های کاربری پیشنهاد می شود. برای این منظور میتوان تمام حساب های کاربری مرتبط به سرویس ها را در یک گروه واحد و OU مجتمع کرده و سیاست Allow Logon Locally را برای رایانه Server های برنامه های کاربردی غیر فعال نموده و Log on as service را فعال نمایید.

اطمینان از ایمن بودن هر کنترل کننده دامنه (DC) به صورت فیزیکی
با توجه به اینکه کنترل کننده دامنه (DC)ها بعد فیزیکی اکتیو دایرکتوری هستند که در سرتاسر Forest پراکنده هستند محافظت فیزیکی از کنترل کننده دامنه (DC) جزو لاینفک برقراری امنیت در ساختار اکتیو دایرکتوری هستند. به دلیل اینکه کنترل کننده های دامنه (DC) پایگاه داده اکتیو دایرکتوری (NTDS.DIT) را در اختیار دارند، دسترسی فیزیکی به این پایگاه داده و استفاده از نرم افزارهای مخرب، احتمال فاش شدن نام های کاربری و رمز عبور را افزایش می دهند.

کمینه سازی سرویس های غیر ضروری و پورتهای باز
علاوه بر بستن پورتهای غیر ضروری اقداماتی نیز باید در جهت جلوگیری از حملات DoS بر روی کنترل کننده های دامنه (DC) اعمال گردد.روشهای زیادی موجود است تا کنترل کننده دامنه (DC) را مورد حمله DoS قرار دهد و از دور خارج کند. یکی از این روشها پر کردن فضای دیسک کنترل کننده دامنه (DC) است. این روش با ساخت پی در پی اشیا در اکتیودایرکتوری و بالابردن حجم NTDS.DIT انجام می شود. علاوه بر اینکه فایل NTDS.DIT باید در پارتیشن ای قرار گیرد که فضای خالی زیادی داشته باشد، باید با استفاده از دستورات DSMOD PARTITION و DSMOD QUOTA میزان رشد پایگاه داده را تعریف نماییم تا از ایجاد بی رویه اشیا در اکتیو دایرکتوری جلوگیری نماییم.
یکی دیگر از حملات DoS که بر روی کنترل کننده دامنه (DC) انجام می پذیرد، ارسال سیل فایل (File Flooding) به پوشه SYSVOL می باشد که باعث از کار افتادگی کنترل کننده دامنه (DC) خواهد شد. در این مورد خاص امکان تعریف Quota وجود ندارد اما میتوان با تعریف نمودن مقداری از فضای پوشه SYSVOL به عنوان فضای رزرو مانع از بوجود آمدن این مشکل شد. در صورت بوجود آمدن مشکل و پر شدن فضای دیسک می توان فضای رزرو شده را پاک کرد تا فضای خالی ایجاد گردد. این امکان با استفاده از دستور FSUTIL FILE CREATENEW انجام می شود.

امن نمودن منبع زمان کنترل کننده دامنه (DC)
بدلیل وابستگی شدید سرویس اکتیو دایرکتوری به پروتکل Kerberos ، این سرویس به شدت به اختلاف زمان حساس می باشد. به صورت پیش فرض کنترل کننده دامنه (DC) موجود در ریشه اصلی Forest مسئولیت همسان سازی زمان سایر کنترل کننده های دامنه (DC) را بر عهده دارد. این بدین معنی است که سایر کنترل کننده های دامنه (DC) ها زمان خود را با کنترل کننده دامنه (DC) اصلی موجود در ریشه تنظیم می کنند تا از عدم اختلاف زمانی در ساختار جلوگیری شود. باید در نظر داشت، حال که کنترل کننده دامنه (DC) موجود در ریشه Forest به عنوان منبع اصلی رمان در کل ساختار به ایفای نقش می پردازد، زمان خود را با یک منبع خارج از سازمان تنظیم می نماید. آیا این منبع زمانی که در خارج از سازمان قرار دارد امن است؟

ممیزی رخدادهای مهم
باید قابلیت ممیزی (Audit) رخدادهای مهم را در سطح دامنه فعال کرده تا امکان ثبت آن رخدادها برای تمام سیستم ها به وجود آید. پیشنهاد می شود ثبت رخدادهای مرتبط با احراز هویت های ناموفق و موفق، دسترسی به فایلها و پوشه های حساس و تغییرات GPO تنظیم گردد.

استفاده از IPSec
پیاده سازی IPSec برای ارتباطات بین کلاینت و کنترل کننده دامنه (DC) اگرچه کار پیچیده ای بوده و نیازمند صرف زمان قابل توجهی می باشد، امکان پیاده سازی آن برای ارتباطات بین کنترل کننده دامنه (DC) به میزان قابل توجهی آسان تر می باشد. از این پروتکل برای ارتباطات بین کنترل کننده های دامنه (DC) استفاده نمایید.

ذخیره نکردن مقادیر Hash پروتکل LAN Manager
با توجه به قدیمی بودن پروتکل LM و ساختار ضعیف آن، باید هرچه سریعتر ساختار خود را از این ضعف امنیتی رها کنید. بسیاری از حملات مرتبط به رمز عبور با حمله به Hash این پروتکل شروع شده و با استنتاج نتایج بدست آمده به پروتکل های دیگری مانند NTLM حمله می نمایند. سیاست امنیتی که باید در این سناریو مورد بازبینی قرار گیرد Do Not Store LAN Manager Hash Value on Next Password Change می باشد. همچنین سیاست امنیتی دیگری که باید مورد توجه قرار گیرد سیاست Send NTLMv2 Response Only, Refuse LM and NTLM است. اکثز کلاینت ها میتوانند تنظیم گردند تا از NTLMv2 به عنوان پروتکل اصلی استفاده نمایند، اگرچه پیاده سازی این سیاست های امنیتی نیاز به تست در محیط آزمایشی و اطمینان حاصل نمودن از صحت عملکرد آنها می باشد.

مدیریت وصله های ترمیمی
بسیاری از حملاتی که به سرویس های یک سازمان انجام می شود بدلیل به روز نبودن آن سرویس از وصله های ترمیمی می باشد. سازمانهای کوچک ازابزار WSUS برای مدیریت و گسترش دادن وصله های ترمیمی و سازمانهای بزرگ از نرم افزارهای مدیریتی مثل SCCM برای این منظور استفاده می کنند. بدون توجه به مکانیزمی که برای گسترش وصله های ترمیمی به سرورها و ایستگاهای کاری استفاده می شود، باید آنها را برای سیستمهای با امنیت بالا مانند کنترل کننده های دامنه جدا کنید.

عدم دسترسی به اینترنت برای سرویس های حساس
بدلیل اینکه اکثر حملاتی که به سازمان صورت می پذیرد از نقاطی خارج از سازمان انجام می شود، میتوان نتیجه گرفت که اینترنت دروازه حملات به داخل سازمان می باشد. برای رفع این مشکل امنیتی بهتر است که دسترسی به اینترنت را برای سیستم های حساس محدود نمایید. دلیلی قابل توجیهی برای اینکه کنترل کننده های دامنه به اینترنت متصل باشند وجود ندارد.

تمهیدات لازم جهت ایمن سازی میزبانهای مدیریتی (Administrative Hosts)
پیشنهاد می شود میزبانهایی که دارای بار عملیاتی و مدیریتی حساس هستند برای احراز هویت کاربران، علاوه بر رمز عبور از تکنولوژی های دیگری مانند Smartcard استفاده نمایند. همچنین میتوان از طریق پیاده سازی سیاست های امنیتی (GPO) مشخص کرد که چه کسانی قادر به استفاه از آن سیستم به صورت محاوره ای (Interactive) هستند تا مانع دسترسی افراد غیر مجاز به آن میزبان گردد.

استفاده از تکنیک Authentication Mechanism Assurance
با استفاده از قابلیت جدید اضافه شده در Windows Server 2008 R2 که با نام Authentication Mechanism Assurance شناخته می شود، می توان دسترسی به منابع را بر حسب نوع احراز هویت کاربران کنترل نمود. به عنوان مثال سناریویی را در نظر بگیرید که در آن کاربر می تواند با استفاده از کارت هوشمند و یا نام کاربری و رمز عبور مورد احراز هویت قرار بگیرد. این قابلیت به راهبران این اجازه را میدهد که سطع وسیعی از دسترسی ها را بر حسب نوع اهمیت و محرمانگی داده ها تعیین نمایند. به عنوان نمونه اگر کاربر فوق با استفاده از کارت هوشمند مورد احراز هویت قرار گرفت به داده های حساس تری دسترسی داشته باشد تا در حالتی که همان کاربر با استفاده از نام کاربری و رمز عبور وارد دامنه شده باشد.

محدود نمودن نرم افزارهای اجرایی بر روی کنترل کننده های دامنه با استفاده از Applocker
قابلیت Applocker یک کنترل کننده نرم افزار های اجرایی بر روی ویندوز می باشد که به صورت پیش فرض نصب شده ولی غیرفعال می باشد. این قابلیت به راهبران اجازه می دهد که لیستی موسوم به “لیست سفید” تهیه کرده که در آن نرم افزارهایی که مجاز به اجرا بر روی کنترل کننده های دامنه هستند تعریف می گردند و هرگونه نرم افزار که خارج از لیست فوق باشد اجازه اجرا نخواهد داشت. پس از پیاده سازی کامل کنترل کننده های دامنه و نصب نرم افزار های مورد نیاز از قبیل نرم افزار های امنیتی ضد ویروس، نرم افزار های مانیتورینگ و سایر نرم افزارها، پیشنهاد می شود که لیستی از نرم افزارهای نصب شده تهیه کرده و آن را به Applocker ارائه دهید. در اینصورت در شرایطی که دسترسی غیرمجاز به هر نحوی بر روی کنترولرهای دامنه انجام گیرد، شخص مهاجم اجازه نصب و احرای نرم افزارهای خارج از لیست را نخواهد داشت.

اعطای سطح دسترسی برحسب روشهایی مانند RBAC
پیشنهاد می شود راهبرانی که در سطح دامنه مشغول فعالیت هستند را با توجه به موقعیت شغلی آنها دسته بندی کرده و دسترسی های لازم را بر اساس موقعیت شغلی به آنها اعمال نماییم. به عنوان مثال راهبرانی که وظیفه مدیریت نام های کاربری و رمز عبور را بر عهده دارند را در گروهی به نام Account_Admins قرار داده و سطوح دسترسی مورد نیاز را با استفاده از تکنیک Delegation به آن گروه اعمال نمایید.

commentنتیجه گیری
با توجه به گسترش روزافزون استفاده از سرویس Active Directory در سازمان ها و اهمیت امنیت در این ساختار، در این مقاله سعی گردید تا راهکارهایی به منظور ایمن سازی امنیت در اکتیو دایرکتوری ارائه گردد. این مقاله در 24 بند طراحی گردیده است که رعایت نمودن بندهای فوق الذکر امنیت ساختار را تا حد مطلوبی بالا برده و مانع از مشکلات احتمالی که در اثر دسترسی های غیرمجاز ایجاد می شوند خواهد گردید.

دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.