ServiceDesk Plus
امنیت میز خدمت به داشتن HTTPS یا یک رمز عبور پیچیده محدود نیست. در ServiceDesk Plus، امنیت از هویت کاربران و تفکیک دسترسی‌ها آغاز می‌شود و تا ارتباطات، پایگاه داده، فایل‌های ضمیمه، ردپای فعالیت، پشتیبان‌گیری و بازیابی خدمت ادامه پیدا می‌کند.
این راهنمای تألیفی مدانت بر پایه مشخصات امنیتی رسمی ManageEngine تنظیم شده است. علاوه بر تشریح قابلیت‌ها، پیامدهای عملی آن‌ها در استقرار سازمانی بررسی می‌شود. امکانات، الزامات لایسنس و محل دقیق تنظیمات ممکن است با Edition، نسخه، Build و مدل استقرار متفاوت باشد.
۱. امنیت ServiceDesk Plus در چه لایه‌هایی تعریف می‌شود؟
ServiceDesk Plus می‌تواند محل نگهداری درخواست‌های کاربران، اطلاعات دارایی‌ها، مکاتبات پشتیبانی، سوابق تغییرات و اسناد داخلی باشد. برای ایمن‌سازی چنین سامانه‌ای باید سه پرسش پاسخ روشن داشته باشند: چه کسی مجاز به مشاهده داده است؟ چه کسی حق تغییر آن را دارد؟ و پس از اختلال چگونه خدمت بازمی‌گردد؟
کنترل هویت، نقش، محدوده مشاهده و حفاظت از اسناد.
ردپای تغییرات، اعتبارسنجی ورودی و مجوز ویرایش داده.
بکاپ، Restore، Failover و پایش مستمر سرویس.
کنترل‌های اعلام‌شده از مرحله نصب تا ورود کاربر، انتقال اطلاعات و ذخیره‌سازی را پوشش می‌دهند. اما وجود یک قابلیت امنیتی به معنای فعال بودن و پیکربندی صحیح آن نیست. هر قابلیت باید در محیط واقعی آزموده شود.
| لایه | قابلیت شاخص محصول | وظیفه تیم بهره‌برداری |
|---|---|---|
| هویت | AD/LDAP، SAML 2.0، حساب محلی | چرخه عمر کاربر و لغو دسترسی |
| داده | AES-256، bcrypt، نقش‌های دسترسی | حفاظت از سرور، کلید و حساب مدیر |
| ارتباطات | HTTPS/TLS و ارتباط امن سرویس‌ها | گواهی معتبر، شبکه و پورت‌های مجاز |
| عملیات | Audit Trail، سیاست نشست و محدودسازی تلاش ورود | پایش و رسیدگی به رویداد مشکوک |
| تاب‌آوری | Backup، Restore و Failover | آزمون بازیابی و تعیین RPO/RTO |
۲. رمزنگاری داده؛ تفاوت AES-256، bcrypt و SHA-256
در صفحه رسمی ManageEngine از سه فناوری AES-256، bcrypt و SHA-256 نام برده شده است. این سه، روش‌های یکسانی نیستند: AES-256 الگوریتم رمزنگاری متقارن است؛ bcrypt برای هش‌کردن یک‌طرفه رمز عبور کاربرد دارد؛ SHA-256 نیز یک تابع هش رمزنگاری است. در طراحی سیاست امنیتی باید نقش هرکدام روشن باشد.
اطلاعات حساس در برنامه و دیتابیس
سازنده اعلام می‌کند برای حفاظت از داده‌های حساس از AES-256 استفاده می‌شود و برای هر نصب، کلید منحصربه‌فردی تولید می‌گردد. در شرح امنیت دیتابیس، اشاره مشخص به داده‌های شخصی و حساس وجود دارد؛ پس نباید فرض کرد همه ستون‌ها یا تمام دیسک به‌صورت یکسان رمز شده‌اند. رمزگذاری دیسک و محافظت از فایل‌های پشتیبان می‌تواند مکمل این سطح حفاظت باشد.
رمز عبور کاربران محلی با سازوکار مبتنی بر bcrypt ذخیره می‌شود. مدیر سامانه نباید بر مبنای این اطلاعات بتواند رمز اصلی کاربر را بازیابی کند. البته دسترسی غیرمجاز به فایل‌های تنظیمات، حساب سیستم‌عامل یا کلیدهای نصب همچنان خطرآفرین است و باید جداگانه کنترل شود.
امنیت ارتباط دیتابیس
در مدل Microsoft SQL Server می‌توان ارتباط ایمن با پایگاه داده را پیکربندی کرد. در توضیح رسمی، PostgreSQL همراه محصول برای دریافت اتصال از میزبان محلی طراحی شده است. اگر معماری شما دیتابیس جداگانه یا دسترسی شبکه‌ای دارد، محدودسازی دسترسی، مدیریت اعتبارنامه و حفاظت از مسیر انتقال باید بازطراحی شوند.
۳. احراز هویت، هویت متمرکز و کنترل مجوزها
در بسیاری از رخدادهای امنیتی، ضعف از خود الگوریتم رمزنگاری نیست؛ از حسابی شروع می‌شود که بیش از نیاز خود مجوز دارد یا پس از خروج کارمند فعال مانده است. ServiceDesk Plus روش‌های مختلفی برای ورود و احراز هویت فراهم می‌کند.
یکپارچگی Active Directory و LDAP
اتصال به Active Directory یا سرویس‌های سازگار با LDAP به استفاده از مخزن هویت سازمان کمک می‌کند. کاربر می‌تواند با هویت سازمانی شناسایی شود و مدیریت ورود و خروج کارکنان یکپارچه‌تر گردد. با این وجود، واردکردن کاربران از دایرکتوری به معنای تعیین خودکار حداقل مجوز برای آن‌ها نیست؛ دسترسی به درخواست‌ها و تنظیمات باید در خود سامانه کنترل شود.
SSO بر پایه SAML 2.0
در ورود یکپارچه SAML، ServiceDesk Plus به‌عنوان Service Provider با Identity Provider سازمان ارتباط دارد. کاربر پس از احراز هویت در سامانه هویت می‌تواند بدون ورود دوباره اعتبارنامه، به میز خدمت منتقل شود. گواهی‌ها، نشست‌ها، خروج کاربر و رفتار ورود در مرورگر باید در محیط آزمایشی بررسی شوند.
حساب محلی و سیاست رمز
سازنده امکان الزام تغییر رمز در اولین ورود، سیاست رمز عبور، محدودسازی تلاش‌های ناموفق و غیرفعال‌کردن ورودهای هم‌زمان را معرفی کرده است. این تنظیمات باید متناسب با الزامات سازمان و نیاز به حساب اضطراری طراحی شوند. حساب اضطراری اگر لازم است، نباید به یک مسیر ورود بدون نظارت تبدیل شود.
نقش‌ها و Audit Trail
Role-Based Access Control دسترسی را متناسب با وظیفه فرد محدود می‌کند. مجوز مشاهده درخواست، تغییر تنظیمات، مدیریت کاربران، گزارش‌گیری و دریافت پیوست بهتر است مستقل بررسی شود. Audit Trail نیز می‌تواند مشخص کند چه کسی چه عملی را در چه زمانی انجام داده است. وجود لاگ به‌تنهایی کافی نیست؛ باید برنامه بازبینی و پاسخ به هشدار هم وجود داشته باشد.
۴. امنیت انتقال داده میان کاربران، سرور و یکپارچگی‌ها
یک میز خدمت سازمانی معمولاً با مرورگر، دیتابیس، سامانه هویت، Endpoint Central، سرورهای راه دور، برنامه موبایل و محصولات مرتبط تبادل داده می‌کند. برای هر ارتباط، پروتکل انتقال، هویت طرف مقابل و مجوز دسترسی باید مشخص باشد.
از سرور برنامه، ارتباط‌های کنترل‌شده به دیتابیس، سامانه هویت، Endpoint Central و سرویس‌های مجاز برقرار می‌شود.
طبق توضیحات رسمی، رابط وب از HTTPS استفاده می‌کند؛ ارتباط با Endpoint Central و برخی سرورهای راه دور با روش‌های رمزگذاری و احراز هویت مبتنی بر کلید انجام می‌شود. در انتقال بسته‌های ZIP از سرور راه دور، محصول بررسی‌هایی برای کاهش خطر Zip Slip انجام می‌دهد. برنامه موبایل و محصولات یکپارچه نیز طبق معماری مرتبط، از ارتباط رمزگذاری‌شده و توکن استفاده می‌کنند.
برای هر Integration یک شناسنامه امنیتی بسازید: مبدأ، مقصد، پورت، نوع توکن یا اعتبارنامه، مالک، دسترسی‌ها و زمان بازبینی. بازماندن توکن‌های قدیمی یا پورت‌های غیرضروری با وجود HTTPS همچنان می‌تواند خطرساز باشد.
۵. تفکیک و حفاظت از داده‌ها در ESM
Enterprise Service Management امکان ایجاد میزهای خدمت جداگانه برای واحدهایی مانند فناوری اطلاعات، منابع انسانی، مالی و خدمات اداری را فراهم می‌کند. مستند رسمی، جداسازی داده‌ها در سطح ردیف‌های پایگاه داده را تشریح می‌کند؛ عملیات هر Service Desk به محدوده داده مربوط به همان واحد مقید می‌شود.
این تفکیک منطقی با اختصاص دیتابیس یا سرور فیزیکی کاملاً مستقل برای هر واحد یکسان نیست. دسترسی مدیران، مجوز فایل‌های ضمیمه، گزارش‌های خروجی و حساب‌های سطح زیرساخت همچنان باید ارزیابی شود. برای مقایسه معماری‌های چندواحدی، مقاله تفاوت ServiceDesk Plus و ESM را مطالعه کنید.
۶. سخت‌سازی وب، نشست کاربر و هدرهای پاسخ
HTTPS، گواهی معتبر و تنظیمات TLS مناسب از مهم‌ترین کنترل‌های راه‌اندازی هستند. مسیر دقیق Security Settings بسته به Build ممکن است متفاوت باشد. علاوه بر این، تنظیم هدرهای پاسخ HTTP می‌تواند رفتار امنیتی مرورگر را کنترل کند.
| هدر | هدف | احتیاط اجرایی |
|---|---|---|
Content-Security-Policy |
محدودکردن منابع مجاز اسکریپت و محتوا | سیاست نسخه‌های جدید از جمله 14920 به بعد با نسخه‌های قبلی فرق دارد؛ ابتدا در تست بررسی شود. |
Strict-Transport-Security |
الزام مرورگر به استفاده از HTTPS | قبل از includeSubDomains یا preload آمادگی همه زیردامنه‌ها بررسی شود. |
X-Content-Type-Options |
کاهش خطر تفسیر نادرست نوع محتوا | مقدار متداول nosniff است. |
X-Frame-Options |
کاهش خطر Clickjacking | با سیاست frame-ancestors در CSP سازگار باشد. |
Referrer-Policy |
کنترل اطلاعات ارجاع مرورگر | با نیاز حریم خصوصی سازمان تنظیم شود. |
Cache-Control |
کنترل نحوه کش شدن پاسخ‌ها | برای صفحات خصوصی یا گزارش‌های حساس، کش عمومی بدون ارزیابی مناسب نیست. |
Access-Control-Allow-Origin |
کنترل درخواست از مبدأهای دیگر | فقط مبدأهای مجاز و مورد اعتماد مشخص شوند. |
توجه به تغییر استانداردها: در سند رسمی هدرهای تاریخی X-XSS-Protection و Expect-CT نیز دیده می‌شود. این هدرها دیگر نباید ستون اصلی سخت‌سازی مرورگرهای مدرن تلقی شوند. پیشنهادهای فنی باید با وضعیت فعلی مرورگرها، Build نصب‌شده و مستندات روز تطبیق داده شوند.
کوکی، SameSite و زمان نشست
برای کوکی‌های حساس، ویژگی‌های Secure و HttpOnly اهمیت دارند. مقدار SameSite باید با سازوکار ورود یکپارچه سازگار باشد؛ انتخاب Strict یا Lax بدون آزمون ممکن است برخی جریان‌های SAML و OAuth را دچار مشکل کند. زمان انقضای نشست و قابلیت «مرا وارد نگه دار» نیز باید متناسب با سطح محرمانگی تعریف شوند.
۷. پیوست‌ها، فایل‌های خروجی و گزارش‌های حساس
فایل‌های ضمیمه ممکن است قرارداد، تصویر خطا، اطلاعات کاربر یا سند محرمانه باشند. در ServiceDesk Plus امکان فیلترکردن انواع فایل‌های بارگذاری‌شده و حفاظت رمزدار از پیوست‌ها در پیکربندی‌های مرتبط وجود دارد. بهتر است نوع فایل مجاز، مالک داده و مدت نگهداری آن از ابتدا مشخص شود.
گزارش‌های خروجی نیز می‌توانند حاوی فهرست دارایی، اطلاعات درخواست‌دهنده و جزئیات رخداد باشند. سازنده گزینه محافظت رمزدار برای فایل‌های خروجی و گزارش را توضیح داده است. علاوه بر رمز، مقصد ایمیل، مجوز دریافت گزارش و سیاست نگهداری نیز باید کنترل شود.
درباره هشدار آنتی‌ویروس: بسته‌بندی فایل ضمیمه به شکل ZIP گاهی می‌تواند هشدار اشتباه ایجاد کند. نباید همه هشدارها را بی‌بررسی نادیده گرفت؛ ابتدا باید مسیر، پردازش ایجادکننده و رفتار واقعی فایل ارزیابی شود.
۸. دسترس‌پذیری، پشتیبان‌گیری و بازیابی پس از بحران
Failover و تداوم خدمت
اگر میز خدمت از دسترس خارج شود، مدیریت رخدادهای دیگر نیز مختل می‌شود. ManageEngine قابلیت Fail Over Service را برای سناریوهای دسترس‌پذیری معرفی کرده و به همگام‌سازی داده میان سرور اصلی و سرور پشتیبان از یک مسیر امن اشاره می‌کند. پیش‌نیازها و امکان استفاده از این قابلیت باید با نسخه و لایسنس سازمان تطبیق داده شوند.
Backup و Restore
محصول امکان پشتیبان‌گیری دستی و زمان‌بندی‌شده را دارد. اطلاعات حساس در فایل پشتیبان مطابق سازوکار محصول محافظت می‌شوند و مدیر می‌تواند محل ذخیره‌سازی را مشخص کند. در سناریوی بازیابی، نصب نسخه سازگار با نسخه پشتیبان و بازگرداندن داده‌ها اهمیت دارد.
داشتن فایل Backup به معنی آمادگی برای بحران نیست. دو شاخص باید روشن باشند: RPO میزان داده قابل‌قبول برای از دست رفتن و RTO زمان قابل‌قبول برای بازگرداندن سرویس. محافظت بکاپ در برابر باج‌افزار، نگهداری خارج از سرور اصلی و آزمون Restore در محیط جدا توصیه می‌شود.
۹. تهدیدهای رایج و اقدامات پیشگیرانه
Brute Force و حدس رمز
محدودسازی تلاش‌های ناموفق، تعریف آستانه قفل حساب و سیاست رمز مناسب، ریسک ورود غیرمجاز را کاهش می‌دهد. رویدادهای ورود غیرعادی باید بررسی شوند.
Clickjacking، XSS و تزریق ورودی
اعتبارسنجی ورودی، کنترل مجوزها و سیاست امنیت محتوا دفاع‌های مکمل‌اند. اسکریپت‌های سفارشی، فرم ورود و شخصی‌سازی پورتال می‌توانند سطح خطر را افزایش دهند؛ هر کد سفارشی باید بازبینی و آزمایش شود.
لینک‌های بدون نیاز به ورود و Session Hijacking
زمان انقضای نشست، لینک‌های تأیید و مسیرهای بدون احراز هویت باید بررسی شوند. اگر مسیر بارگذاری اطلاعات دارایی یا تأیید از طریق لینک بدون ورود استفاده نمی‌شود، غیرفعال کردن آن طبق امکانات Build باید بررسی شود.
آپلود فایل، روش‌های HTTP و پیکربندی TLS
فیلتر پیوست، محدودسازی نوع فایل، مجوز محل ذخیره و ثبت رویدادهای آپلود مهم‌اند. مستند سازنده به روش‌هایی مانند TRACE، خطرهای TLS ضعیف و گزینه غیرفعال‌سازی HTTP Compression برای کاهش ریسک BREACH نیز می‌پردازد. اجرای دستورهای پیکربندی قدیمی بدون تأیید سازگاری نسخه، گزینه امنی نیست.
فهرست CVEهای برطرف‌شده
سند سازنده شناسه‌های آسیب‌پذیری متعددی را برای اجزای همراه محصول فهرست می‌کند. این فهرست نباید به معنای آسیب‌ناپذیر بودن تمام نسخه‌ها و Buildها در تمام زمان‌ها تعبیر شود. نتیجه ارزیابی امنیت باید بر Build واقعی، هشدارهای امنیتی روز، مؤلفه‌های نصب‌شده و آزمون معتبر متکی باشد.
۱۰. چک‌لیست عملی سخت‌سازی ServiceDesk Plus
برای هر کنترل، مالک اجرا، تاریخ بازبینی و مدرک اجرای آن را ثبت کنید. این چک‌لیست برای قبل از Go-Live یا بازبینی دوره‌ای مناسب است.
| اولویت | کنترل | شاهد اجرایی |
|---|---|---|
| بحرانی | ثبت Build و نصب اصلاحیه‌های امنیتی مرتبط | شماره نسخه و تاریخ Patch |
| بحرانی | HTTPS، گواهی معتبر و TLS مناسب | گزارش آزمون و تاریخ انقضا |
| بحرانی | تغییر رمزهای پیش‌فرض و بازبینی حساب مدیر | فهرست حساب‌های حساس |
| بحرانی | محدودسازی پورت‌های مدیریتی و دسترسی دیتابیس | ماتریس فایروال |
| بالا | ارزیابی AD/LDAP یا SSO | آزمون ورود و لغو دسترسی |
| بالا | سیاست رمز، قفل حساب و انقضای نشست | تصویر تنظیمات و نتیجه تست |
| بالا | محدودسازی نقش‌ها و Support Groupها | ماتریس Role/Group |
| بالا | آزمون دسترسی متقابل میان واحدهای ESM | تست با حساب هر واحد |
| بالا | بررسی Audit Trail و هشدارهای امنیتی | گزارش رخداد و بازبینی |
| بالا | فیلتر پیوست‌ها و حفاظت از فایل‌های حساس | آزمون آپلود و دریافت |
| بالا | حفاظت از گزارش‌های خروجی | نمونه فایل محافظت‌شده |
| بالا | Backup زمان‌بندی‌شده و آزمون Restore | گزارش بازیابی و RTO |
| متوسط | بازبینی CSP، HSTS، CORS و Cache-Control | گزارش هدرها و مرورگر |
| متوسط | بازبینی Secure، HttpOnly و SameSite | نتیجه آزمون نشست و SSO |
| متوسط | حذف Endpointهای بدون ورود غیرضروری | فهرست مسیرهای مجاز |
| متوسط | بازبینی Custom Trigger، Function و Page Script | موجودی کدهای سفارشی |
| متوسط | حفاظت از پوشه نصب و فایل تنظیمات | مجوزهای سیستم‌عامل |
| متوسط | بازبینی توکن‌ها و یکپارچگی‌های غیرفعال | شناسنامه ارتباطات |
در مستند رسمی آمده است که روی نصب‌های جدید از Build 14304 به بعد، محدودسازی مجوزهای فایل نصب به‌صورت خودکار اعمال می‌شود؛ اما در نصب‌های قدیمی ممکن است اقدام دستی لازم باشد. در هر حالت بررسی فعلی مجوزها ضروری است.
۱۱. سناریوی عملی؛ امنیت در سازمانی با IT، منابع انسانی و مالی
فرض کنید سازمانی با ۵۰۰ کارمند، ServiceDesk Plus را برای واحد IT مستقر کرده و حالا واحدهای منابع انسانی و مالی نیز به آن متصل شده‌اند. درخواست خرابی چاپگر و درخواست اصلاح حقوق سطح محرمانگی یکسانی ندارند. بنابراین طراحی امنیت نمی‌تواند فقط به انتخاب فرم و تکنسین محدود بماند.
- طبقه‌بندی داده: نوع اطلاعات قابل ثبت و مدت نگهداری درخواست و ضمیمه مشخص شود.
- مرزبندی نقش: تکنسین IT به‌صورت پیش‌فرض نباید به پرونده‌های حساس HR دسترسی داشته باشد.
- انتخاب معماری: بررسی شود Group و Role کافی‌اند یا Instance مستقل ESM مناسب‌تر است.
- حفاظت از تأییدها: لینک‌های Approval و فایل‌های خروجی از نظر دسترسی آزموده شوند.
- آزمون رخداد: خرابی سرور، افشای اعتبارنامه تکنسین و Restore بکاپ تمرین شود.
- کنترل تغییر: تنظیمات امنیتی ابتدا در محیط تست و سپس با برنامه بازگشت در تولید اعمال شوند.
این موضوع با ITSM نیز ارتباط مستقیم دارد: تغییر سیاست SSO باید از Change Management عبور کند، مؤلفه‌های سامانه در CMDB ثبت شوند و ورودهای غیرعادی در فرآیند Incident Management پیگیری شوند. امنیت در این نگاه بخشی از اداره مستمر خدمت است، نه یک چک‌لیست یک‌باره.
۱۲. چه کسی مسئول امنیت است؛ سازنده، سازمان یا مجری؟
سازنده مسئول طراحی محصول، اصلاح ضعف‌ها و انتشار به‌روزرسانی‌هاست. سازمان بهره‌بردار باید سیاست دسترسی، حفاظت زیرساخت، بکاپ و نظارت را اجرا کند. تیم استقرار نیز قابلیت‌های مناسب را با توجه به Build، معماری و ریسک سازمان پیکربندی و مستند می‌کند.
مدانت در مسیر انتخاب نسخه، ارزیابی معماری، طراحی نقش‌ها، استقرار، آموزش و بررسی کنترل‌های عملیاتی همراه سازمان است. این خدمات با قابلیت‌های ذاتی محصول یکسان نیستند و دامنه آن‌ها مطابق شرایط پروژه تعیین می‌شود. برای شناخت محصول به صفحه ServiceDesk Plus فارسی مدانت و برای آموزش به مرکز آموزش ServiceDesk Plus مراجعه کنید.
۱۳. پرسش‌های متداول درباره امنیت ServiceDesk Plus
آیا همه داده‌های دیتابیس با AES-256 رمز می‌شوند؟
سند رسمی به رمزگذاری اطلاعات شخصی و حساس اشاره دارد. این ادعا به معنای رمز بودن همه ستون‌ها یا تمام دیسک نیست.
آیا اتصال به Active Directory همه مجوزها را امن می‌کند؟
خیر. دایرکتوری هویت را مدیریت می‌کند؛ محدوده مشاهده و عملیات کاربران باید با Role و Group در سامانه کنترل شود.
آیا از SAML SSO پشتیبانی می‌شود؟
بله، در مشخصات رسمی پشتیبانی SAML 2.0 آمده است؛ پیش‌نیازهای Edition و Build باید کنترل شود.
آیا داده‌های ESM کاملاً از نظر فیزیکی جدا هستند؟
تفکیک اعلام‌شده در سطح منطقی و ردیف‌های دیتابیس است، نه لزوماً سرور یا دیتابیس فیزیکی مستقل.
آیا HTTPS برای امنیت کافی است؟
خیر. HTTPS فقط بخشی از محافظت انتقال است؛ مدیریت هویت، وصله‌ها، نقش‌ها، بکاپ و پایش هم لازم‌اند.
آیا هدرهای سند رسمی را می‌توان عیناً اعمال کرد؟
بدون آزمون توصیه نمی‌شود؛ برخی قدیمی و برخی وابسته به Build هستند و ممکن است SSO یا یکپارچگی‌ها را مختل کنند.
آیا داشتن Backup کافی است؟
خیر؛ فایل باید محافظت‌شده و قابل Restore باشد و بازیابی در محیط جدا آزمایش شده باشد.
از کجا ارزیابی امنیت یک نصب قدیمی را شروع کنیم؟
از Build و Patch، حساب‌های مدیر، TLS، اتصال دیتابیس، نقش‌ها، Integrations، آپلود و تست بازیابی.
منبع و مطالعه تکمیلی
مرجع این راهنما: ManageEngine — ServiceDesk Plus Security Specifications. برای وضعیت واقعی هر CVE یا تنظیم، به اسناد و هشدارهای امنیتی همان Build مراجعه کنید. این مقاله جایگزین ممیزی، آزمون نفوذ یا تعهد قراردادی امنیت نیست.
امنیت را از معماری درست آغاز کنید
در استقرار یا ارتقای ServiceDesk Plus، نسخه محصول، مدل هویت، محدوده کاربران، یکپارچگی‌ها و سناریوی بازیابی را در کنار هم بررسی کنید.
