فرض کنید یک تغییر اشتباه، باجافزار یا خرابی زیرساختی باعث شده چند Domain Controller از دسترس خارج شوند و بخشی از Objectها یا تنظیمات Active Directory نیز آسیب دیده باشند. در این شرایط، Recycle Bin یا یک Backup ساده از System State همیشه پاسخ کافی نیست؛ سازمان باید بداند دقیقاً چه چیزی را، از چه نقطهای و با چه ترتیب وابستگی بازیابی کند.
Active Directory Disaster Recovery با RecoveryManager Plus یعنی طراحی یک مسیر بازیابی برای Object، Attribute، GPO، Domain Controller و سناریوهای گستردهتر، با هدف کاهش RTO و جلوگیری از بازگرداندن خطا یا آلودگی به محیط Production.
چرا Active Directory یک سرویس عادی نیست؟
Active Directory به احراز هویت، Authorization، Group Policy، سرویسهای داخلی و بسیاری از Applicationها وابسته است. خرابی آن میتواند همزمان چند سرویس دیگر را نیز مختل کند. بنابراین DR برای AD باید در سطح Service Dependency دیده شود.
| سناریو | ریسک | نیاز بازیابی |
|---|---|---|
| حذف User یا Group | محدود | Object/Attribute Restore |
| خرابی GPO | متوسط تا بالا | GPO Rollback |
| خرابی DC | بالا | DC/System State Recovery |
| Corruption گسترده | بحرانی | Forest/Domain Recovery Plan |
| حمله باجافزاری | بحرانی | Clean Recovery + Validation |
Recycle Bin کجا کافی نیست؟
Recycle Bin برای برخی حذفهای تصادفی مفید است، اما برای Rollback گسترده، Attributeهای خاص، GPO، DC Recovery و سناریوهای پیچیدهتر محدودیت دارد. مقاله Active Directory Recycle Bin کافی نیست؛ چه زمانی RecoveryManager Plus لازم است؟ این تفاوت را دقیقتر توضیح میدهد.
RecoveryManager Plus چه نقشی دارد؟
ManageEngine RecoveryManager Plus برای Backup و Recovery سرویسهایی مانند Active Directory، Microsoft 365 و Exchange طراحی شده است. در AD، تمرکز اصلی روی Backup دورهای، Object-level Recovery، Attribute Rollback و سناریوهای بازیابی گستردهتر است.
Backup خوب بدون Recovery Plan کافی نیست
داشتن Backup فقط نیمی از مسئله است. باید بدانید:
- Backup سالم است یا نه؛
- آخرین نقطه قابل اعتماد کدام است؛
- چه Objectهایی باید اول برگردند؛
- Replication بعد از Restore چه رفتاری دارد؛
- آیا Backup قبل از Incident امنیتی گرفته شده است؛
- چه کسی اجازه اجرای Restore را دارد.
RPO و RTO برای Active Directory
RPO مشخص میکند چه مقدار Data Loss قابل قبول است و RTO زمان هدف برای بازگشت سرویس است. برای AD، این دو عدد باید با Business Impact تعیین شوند، نه صرفاً بر اساس ظرفیت Backup.
اگر تغییرات Identity در طول روز زیاد است، Backup روزانه ممکن است RPO کافی نداشته باشد. در مقابل، Backup بسیار پرتکرار بدون Retention و Storage Planning نیز عملی نیست.
Object-Level Recovery؛ بازیابی بدون بازگرداندن کل Domain
در بسیاری از Incidentها لازم نیست کل DC یا Domain Restore شود. اگر User، Group، OU یا Attribute خاصی حذف یا خراب شده باشد، بازیابی Granular سریعتر و کمریسکتر است.
GPO Recovery چرا حیاتی است؟
یک تغییر اشتباه در Group Policy میتواند روی صدها یا هزاران Endpoint اثر بگذارد. اگر نسخه سالم GPO موجود باشد، Rollback سریعتر از بازسازی دستی Policy است. برای کاهش ریسک تغییرات GPO، مقاله GPO Auditing در ADAudit Plus مکمل مناسبی است.
سناریوی باجافزار؛ Restore آلوده ممنوع
در Incident امنیتی، هدف فقط بازگشت سریع نیست. باید مطمئن شوید Backup مورد استفاده قبل از Compromise گرفته شده و Credentialها، Persistence Mechanismها یا تغییرات مخرب دوباره وارد محیط نمیشوند.
ترتیب پیشنهادی
- Containment و قطع مسیر گسترش؛
- تعیین زمان تقریبی Compromise؛
- انتخاب Backup سالم قبل از آن زمان؛
- Recovery در محیط کنترلشده؛
- اعتبارسنجی Object و Configuration؛
- Rotation Credentialهای حساس؛
- بازگرداندن سرویسها به ترتیب Dependency.
Forest Recovery چه زمانی مطرح میشود؟
در خرابیهای بسیار گسترده، ممکن است مسئله از یک Object یا DC فراتر رود و نیاز به بازسازی کنترلشده Domain/Forest باشد. چنین سناریویی باید از قبل مستند و تمرین شود؛ چون در زمان بحران، تصمیمگیری بدون Runbook احتمال خطا را بالا میبرد.
Dependency Mapping را فراموش نکنید
بسیاری از سرویسها به DNS، AD، Certificate، Database و Network وابستهاند. اگر ترتیب Recovery اشتباه باشد، ممکن است سرویس ظاهراً Restore شود اما Dependency لازم در دسترس نباشد.
تست Recovery دورهای
Backupی که Restore آن تست نشده، تضمین عملیاتی نیست. حداقل باید دورهای سناریوهای زیر تمرین شوند:
- Restore یک User؛
- Restore یک Group و Membership؛
- Rollback یک Attribute؛
- بازیابی GPO؛
- Recovery یک DC در محیط Test؛
- Tabletop Exercise برای Forest Recovery.
چه چیزی باید Audit شود؟
- چه کسی Restore را اجرا کرده است؛
- کدام Backup Point استفاده شده؛
- چه Objectهایی تغییر کردهاند؛
- چه زمانی Recovery کامل شده؛
- آیا Validation انجام شده؛
- آیا Credential Rotation لازم بوده است.
سناریو: حذف اشتباه OU
- تغییر شناسایی میشود.
- Incident ثبت میشود.
- آخرین Backup سالم انتخاب میشود.
- OU و Objectهای وابسته Granular Restore میشوند.
- Membership و Permissionها Validation میشوند.
- Replication بررسی میشود.
- Root Cause تغییر مشخص و کنترل Change اصلاح میشود.
سناریو: از دست رفتن Domain Controller
اگر یک DC از دست برود اما DCهای سالم دیگر وجود داشته باشند، Recovery Strategy با Forest Failure متفاوت است. تیم باید تشخیص دهد Rebuild، Restore یا Promotion مجدد کدام گزینه کمریسکتر است. Runbook باید این Decision Pointها را از قبل مشخص کند.
Backup Retention چگونه انتخاب شود؟
Retention باید با Risk و Change Rate هماهنگ باشد. نگه داشتن فقط چند Backup اخیر ممکن است در Incidentی که دیر تشخیص داده شده مشکلساز شود. در مقابل Retention بسیار بلندمدت بدون Policy هزینه Storage و پیچیدگی را بالا میبرد.
| نوع Backup | هدف |
|---|---|
| Frequent Short-term | تغییرات روزمره و حذف تصادفی |
| Daily | Recovery عملیاتی |
| Weekly/Monthly | Incidentهای دیرکشفشده و Audit |
اتصال Recovery به Change و Incident Management
هر Restore مهم باید به Incident و در صورت ایجاد تغییر Production به Change مرتبط باشد. این کار Traceability ایجاد میکند و مشخص میشود چه چیزی، چرا و توسط چه کسی بازگردانده شده است.
چکلیست آمادگی DR برای AD
- RPO و RTO تعریف شدهاند.
- Backup Schedule با Change Rate هماهنگ است.
- Retention چندلایه وجود دارد.
- Restore Granular تست شده است.
- GPO Recovery تمرین شده است.
- Runbook DC Failure وجود دارد.
- Forest Recovery Tabletop انجام شده است.
- Backup سالم قبل از Incident امنیتی قابل شناسایی است.
- Credential Rotation در سناریوهای امنیتی تعریف شده است.
- Audit و Approval Restore مشخصاند.
نکات کلیدی
- Backup بدون تست Restore کافی نیست.
- Granular Recovery از Restore گسترده کمریسکتر است.
- در حمله امنیتی باید Clean Backup انتخاب شود.
- RPO و RTO باید با Business Impact تعیین شوند.
- Forest Recovery باید قبل از بحران تمرین شود.
منابع
- ManageEngine RecoveryManager Plus — Product Overview
- RecoveryManager Plus — Help Documentation
- ManageEngine — Active Directory Backup and Recovery
سخن پایانی
Active Directory ستون هویت سازمان است و خرابی آن میتواند چند سرویس را همزمان از کار بیندازد. RecoveryManager Plus کمک میکند Backup و Restore از یک کار دستی پراکنده به فرآیندی قابلتست و قابلAudit تبدیل شود.
مدانت خدمات استعلام و خرید لایسنس RecoveryManager Plus، طراحی Backup Policy، RPO/RTO، تست Recovery، مهاجرت، آموزش و پشتیبانی ارائه میکند. برای استعلام لایسنس به فروش لایسنس ManageEngine مدانت یا تماس با مدانت مراجعه کنید.
