فرض کنید فردا صبح وارد سازمان می‌شویم. سرورها روشن‌اند، شبکه کار می‌کند و VMها هم بالا هستند، اما Database مالی قابل استفاده نیست. سفارش‌های مشتری‌ها در دسترس نیستند و کسی نمی‌داند آخرین نسخه سالم اطلاعات کجاست.
در چنین شرایطی، در دسترس بودن زیرساخت چقدر به ادامه کار سازمان کمک می‌کند؟
من وقتی وضعیت حفاظت اطلاعات یک سازمان را بررسی می‌کنم، از همین‌جا شروع می‌کنم. داشتن سرور، Storage و نرم‌افزار Backup مهم است، اما باید بدانیم اگر اتفاقی افتاد، واقعاً چه داده ای را می‌توانیم برگردانیم و سرویس های حیاتی سازمان چه زمانی می‌تواند دوباره شروع به کار کند.
قبل از صحبت درباره راهکارها و محصولات، بیایید مشخص کنیم قرار است از چه چیزی محافظت کنیم.
وقتی می‌گوییم Data، درباره چه چیزی صحبت می‌کنیم؟
خیلی وقت‌ها با شنیدن Data، چند فایل یا یک Database به ذهنمان می‌رسد. اما در یک سازمان، دامنه آن خیلی گسترده‌تر است.
سابقه خرید مشتری، تراکنش‌های مالی، قراردادها، اطلاعات انبار، پرونده بیماران، نقشه‌های تولید و Source Code نرم‌افزارها، همگی بخشی از Data سازمان هستند. تنظیمات تجهیزات، اطلاعات Identity، Certificateها و کلیدهای Encryption هم ممکن است برای دسترسی به سرویس‌ها و راه‌اندازی مجدد آن‌ها ضروری باشند.
مثلاً ممکن است فایل Database را داشته باشیم، اما کلید لازم برای بازکردن آن در دسترس نباشد. یا VM یک Application را Restore کنیم، ولی سرویس به دلیل نبودن DNS یا Active Directory کار نکند.
برای همین، من ارزش Data را با تعداد Terabyteهای آن نمی‌سنجم. ممکن است یک Database کوچک برای ادامه فعالیت سازمان مهم‌تر از چندین Terabyte فایل قابل تولید مجدد باشد.
سخت‌افزار خراب را معمولاً می‌توان تعویض کرد. اما بازسازی سابقه چند سال تراکنش، اطلاعات مشتری‌ها یا دانش فنی سازمان، ممکن است بسیار پرهزینه یا حتی غیرممکن باشد. از دست رفتن این اطلاعات می‌تواند فروش، تولید، پاسخ‌گویی به مشتری و تعهدات سازمان را هم متوقف کند.
مفهوم Data Resiliency چیست؟
من Data Resiliency را توانایی سازمان برای محافظت از Data و حفظ یا بازگرداندن دسترسی قابل‌اعتماد به آن هنگام اختلال می‌دانم؛ طوری که فعالیت‌های ضروری سازمان بتوانند ادامه پیدا کنند.
این اختلال می‌تواند خرابی سخت‌افزار، اشتباه انسانی، حذف اطلاعات، خرابی یک سایت یا حمله Ransomware باشد.
قرار نیست فرض کنیم هیچ اتفاقی نمی‌افتد. باید برای اتفاق آماده باشیم، اثر آن را محدود کنیم، مسیر Recovery داشته باشیم و بعد از هر Incident هم طراحی و روش کارمان را اصلاح کنیم.
در عمل، داشتن چند نسخه از Data کافی نیست. باید بدانیم نسخه‌ها قابل استفاده‌اند، در زمان لازم در دسترس قرار می‌گیرند و همان اتفاقی که محیط اصلی را درگیر کرده، همه آن‌ها را هم از بین نمی‌برد.
گاهی Jobهای Backup همگی Successful هستند، اما هنگام Restore مشخص می‌شود یک Database درست برنمی‌گردد یا زمان Recovery بسیار بیشتر از تحمل سازمان است. برای من، نتیجه تست Recovery از تعداد Jobهای سبز مهم‌تر است.
برای بررسی این موضوع، سه حوزه را کنار هم می‌گذارم
در مسیری که برای Data Resiliency در نظر گرفته‌ام، سه حوزه اصلی داریم.
۱. Data Protection
۲. Disaster Recovery
۳. Cyber Recovery
این تقسیم‌بندی کمک می‌کند مسئولیت هر بخش را بهتر بفهمیم. البته این‌ها جزیره‌های جدا نیستند و تمام Data Resiliency هم به این سه عنوان محدود نمی‌شود. طراحی Availability، امنیت، کنترل دسترسی و توان تیم عملیاتی نیز روی نتیجه اثر دارند. بعضی محصولات هم در بیش از یک حوزه کاربرد دارند.
۱. حوزه Data Protection؛
نسخه قابل‌بازیابی از اطلاعات داریم؟
فرض کنید یک کاربر پوشه مهمی را حذف کرده، یک Update باعث خرابی Application شده یا Database دچار Corruption شده است.
در این شرایط باید بتوانیم به یک Recovery Point مناسب برگردیم.
در حوزه Data Protection درباره Backup، روش‌های Restore، Application Consistency، مدت نگهداری نسخه‌ها، کنترل دسترسی و محل نگهداری آن‌ها صحبت می‌کنیم. باید مشخص باشد از چه چیزی، با چه فاصله‌ای و برای چه مدتی محافظت می‌شود.
در مسیر محصولی این بخش، راهکارهایی مثل Veeam Backup & Replication، NetBackup و Commvault قرار می‌گیرند. محصولاتی مانند Dell PowerProtect Data Domain، HPE StoreOnce و راهکارهای Tape هم می‌توانند محل نگهداری نسخه‌های حفاظت‌شده باشند؛ هرکدام با معماری و کاربرد خودشان.
داشتن یک Backup Storage به‌تنهایی طراحی حفاظت را کامل نمی‌کند. نرم‌افزار، Policy، دسترسی‌ها، ظرفیت و تست Restore باید کنار هم دیده شوند.
۲. حوزه Disaster Recovery؛
اگر محیط اصلی از دسترس خارج شد، سرویس کجا اجرا می‌شود؟
حالا فرض کنید مشکل از یک فایل یا VM فراتر رفته و سایت اصلی سازمان از دسترس خارج شده است.
ممکن است Backup سالم داشته باشیم، اما برای برگرداندن همه سرویس‌ها به سخت‌افزار، Network و زمان زیادی نیاز داشته باشیم. اگر سازمان نتواند این مدت منتظر بماند، باید از قبل برای DR طراحی کرده باشیم.
در این حوزه، Replication بخشی از راهکار است. ظرفیت سایت مقصد، وابستگی Applicationها، ترتیب راه‌اندازی سرویس‌ها، تنظیمات Network و روش Failover و Failback هم باید مشخص باشد.
مثلاً بالا آمدن VM مربوط به Application فایده‌ای ندارد اگر Database یا سرویس Identity موردنیازش هنوز در دسترس نباشد.
در مسیر محصولی این بخش، راهکارهایی مانند VMware VCF Protection and Recovery، HPE Zerto و Dell RecoverPoint for Virtual Machines را بررسی می‌کنیم.
من آماده بودن DR را با موفقیت Replication تأیید نمی‌کنم. باید در تست عملی ببینیم سرویس در مقصد قابل استفاده است و تیم می‌تواند مراحل Recovery را اجرا کند.
۳. حوزه Cyber Recovery؛
اگر دچار حمله سایبری شدیم، تکلیف داده های ما چیست؟
در یک خرابی معمولی، ممکن است محیط مقصد همچنان سالم و قابل اعتماد باشد. اما در حمله سایبری، مهاجم می‌تواند Credentialهای مدیریتی را به دست آورده باشد، سراغ Backupها رفته باشد یا مدت‌ها قبل از شناسایی حمله، محیط را تغییر داده باشد.
اینجا داشتن سایت دوم هم به‌تنهایی جواب مسئله نیست. تغییرات مخرب ممکن است از طریق Replication به مقصد منتقل شده باشند.
در حوزه Cyber Recovery، باید نسخه‌های محافظت‌شده و مسیر Recovery مناسبی داشته باشیم که وابستگی آن به محیط آسیب‌دیده کنترل شده باشد. موضوعاتی مانند Immutability، Isolation، Cyber Vault، بررسی Recovery Pointها و تست در Clean Room در همین بخش مطرح می‌شوند.
یک نکته را هم باید دقیق بدانیم. Immutable بودن یک نسخه، سالم بودن محتوای آن را تضمین نمی‌کند؛ ممکن است از اطلاعاتی Backup گرفته باشیم که از قبل آسیب دیده‌اند.
در مسیر محصولی این حوزه، قابلیت‌های Recovery سایبری در اکوسیستم Veeam و VMware و راهکار Dell PowerProtect Cyber Recovery همراه با CyberSense قرار دارند. هدف، انتخاب Recovery Point قابل‌اعتماد و بازگرداندن کنترل‌شده سرویس با هماهنگی تیم Incident Response است.
از کجا بفهمیم چه راهکاری لازم داریم؟
من قبل از انتخاب محصول، از نیاز سرویس شروع می‌کنم.
باید بدانیم از دست رفتن چه مقدار اطلاعات قابل تحمل است و سرویس چه مدت می‌تواند متوقف بماند. مفهوم RPO به نقطه زمانی موردنیاز برای Recovery اطلاعات مربوط است و RTO هدف زمانی Recovery را مشخص می‌کند.
مثلاً برای یک سامانه سفارش‌گیری، ممکن است هدف این باشد که حداکثر ۱۵ دقیقه اطلاعات از دست برود و سرویس ظرف دو ساعت قابل استفاده شود. این اعداد فرضی‌اند؛ مقدار واقعی را باید با مسئول همان کسب‌وکار مشخص کنیم و بعد توان رسیدن به آن را تست کنیم.
برای حمله سایبری، علاوه بر این دو هدف، سالم و قابل‌اعتماد بودن Recovery Point هم تعیین‌کننده است. جدیدترین نسخه الزاماً مناسب‌ترین نسخه برای Recovery نیست.
اگر یک فایل حذف شد، باید مسیر Restore داشته باشیم. اگر سایت اصلی از دسترس خارج شد، باید بدانیم سرویس را کجا و چگونه اجرا می‌کنیم. اگر محیط در اختیار مهاجم بود، باید بتوانیم از مسیری کنترل‌شده به وضعیت قابل‌اعتماد برگردیم.
من وضعیت Data Resiliency سازمان را با پاسخ عملی به همین سناریوها می‌سنجم. Backup، سایت دوم و ابزار امنیتی هرکدام بخشی از کار را انجام می‌دهند. نتیجه زمانی قابل اتکاست که تیم در یک تست واقعی نشان بدهد اطلاعات لازم برمی‌گردند و سرویس دوباره قابل استفاده است.
در قسمتهای بعدی، در خصوص این سه حوزه اصلی به تفکیک و بیشتر صحبت خواهیم کرد.
