محل ذخیره داده در سرویس ابری کجاست؟ ریسک‌های پنهان ابرهای خارجی برای شرکت‌های ایرانی

مقدمه

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

در نگاه اول ممکن است تصور کنیم محل فیزیکی سرورها اهمیت چندانی ندارد؛ زیرا کاربران از طریق اینترنت به اطلاعات خود دسترسی دارند و ارائه‌دهنده سرویس ابری نیز مسئول نگهداری زیرساخت است. اما در عمل، محل ذخیره داده می‌تواند روی امنیت اطلاعات، امکان دسترسی به سرویس، الزامات قانونی، بازیابی اطلاعات و حتی ادامه فعالیت یک کسب‌وکار تأثیر مستقیم داشته باشد.

چرا باید بدانیم داده‌های شرکت دقیقاً کجا ذخیره می‌شوند؟

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

شناخت محل ذخیره داده به سازمان کمک می‌کند بداند اطلاعاتش تحت چه حوزه قضایی قرار دارد، چه محدودیت‌هایی ممکن است بر دسترسی به آن اعمال شود و در صورت بروز مشکل چه گزینه‌هایی برای انتقال یا بازیابی اطلاعات در اختیار دارد.

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

محل ذخیره داده در سرویس ابری به چه معنا است؟

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

به همین دلیل، برای درک دقیق محل ذخیره داده باید با سه مفهوم مهم یعنی Data Residency، Data Sovereignty و Data Localization آشنا شویم. این مفاهیم به یکدیگر نزدیک هستند، اما هرکدام جنبه متفاوتی از محل، قانون و کنترل داده را توضیح می‌دهند.

Data Residency چیست؟

Data Residency یا «اقامت داده» به محل جغرافیایی اشاره دارد که داده به‌صورت فیزیکی یا منطقی در آن ذخیره می‌شود. به زبان ساده، Data Residency پاسخ این سؤال است:

داده‌های ما در کدام کشور یا منطقه نگهداری می‌شوند؟

برای مثال، یک سرویس ابری ممکن است به مشتری اجازه دهد هنگام ایجاد سرور یا فضای ذخیره‌سازی، یک Region در آلمان، هلند، آمریکا یا سنگاپور انتخاب کند. این انتخاب معمولاً مشخص می‌کند که بخش اصلی ذخیره داده در کدام زیرساخت انجام شود.

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

به همین دلیل، سازمان‌ها نباید تنها به محل سرور اصلی توجه کنند و بهتر است سیاست‌های ارائه‌دهنده درباره Backup، Replication و انتقال داده بین دیتاسنترها را نیز بررسی کنند.

Data Sovereignty چیست؟

Data Sovereignty یا «حاکمیت داده» به این موضوع اشاره دارد که داده ذخیره‌شده تحت قوانین و مقررات کدام کشور قرار می‌گیرد.

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

برای مثال، اگر داده‌های یک شرکت در دیتاسنتری در یک کشور دیگر نگهداری شوند، ممکن است قوانین آن کشور درباره حریم خصوصی، دسترسی نهادهای قضایی، نگهداری سوابق یا انتقال اطلاعات بر آن داده اعمال شود.

Data Sovereignty برای کسب‌وکارهایی که با اطلاعات حساس، داده مشتریان، اطلاعات مالی یا اسناد سازمانی کار می‌کنند اهمیت زیادی دارد. در چنین شرایطی، شرکت باید بداند داده‌هایش نه‌تنها کجا نگهداری می‌شوند، بلکه تحت چه چارچوب قانونی قرار دارند.

این موضوع برای شرکت‌های ایرانی پیچیدگی بیشتری دارد؛ زیرا علاوه بر قوانین کشور میزبان، سیاست‌های داخلی ارائه‌دهنده سرویس و محدودیت‌های ناشی از تحریم یا کنترل صادرات نیز ممکن است بر دسترسی به داده تأثیر بگذارد.

Data Localization چیست؟

Data Localization یا «بومی‌سازی داده» زمانی مطرح می‌شود که قوانین یا مقررات یک کشور الزام کنند برخی انواع داده باید در داخل مرزهای همان کشور ذخیره یا پردازش شوند.

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

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

Data Localization معمولاً در حوزه‌هایی مانند بانکداری، سلامت، دولت الکترونیک، زیرساخت‌های حیاتی و حفاظت از اطلاعات شخصی اهمیت بیشتری پیدا می‌کند.

تفاوت Data Residency، Data Sovereignty و Data Localization

اگرچه این سه مفهوم معمولاً در کنار هم استفاده می‌شوند، تفاوت آن‌ها را می‌توان به شکل ساده این‌گونه بیان کرد:

• Data Residency می‌گوید داده در کجا ذخیره شده است.
• Data Sovereignty مشخص می‌کند داده تحت قوانین کدام کشور قرار دارد.
• Data Localization تعیین می‌کند آیا قانون الزام کرده است داده

داده‌های شما واقعاً در کدام کشور نگهداری می‌شوند؟

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

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

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

Region و Data Center چه تفاوتی دارند؟

در سرویس‌های ابری معمولاً با دو مفهوم Region و Data Center روبه‌رو می‌شویم.

Data Center یا دیتاسنتر، یک مرکز فیزیکی شامل سرورها، تجهیزات شبکه، سیستم‌های ذخیره‌سازی، برق و زیرساخت‌های ارتباطی است. هر دیتاسنتر در یک موقعیت جغرافیایی مشخص قرار دارد.

اما Region معمولاً محدوده جغرافیایی بزرگ‌تری است که می‌تواند شامل یک یا چند دیتاسنتر مستقل باشد. ارائه‌دهندگان بزرگ Cloud برای افزایش پایداری، کاهش تأخیر و ایجاد افزونگی، زیرساخت خود را در چند Region و چند Availability Zone تقسیم می‌کنند.

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

در نتیجه، زمانی که یک سازمان یک Region را انتخاب می‌کند، محل اصلی ذخیره داده تا حد زیادی مشخص می‌شود، اما هنوز باید بررسی شود که ارائه‌دهنده Cloud برای Replication، Backup یا سرویس‌های مدیریتی از مناطق دیگری نیز استفاده می‌کند یا خیر.

Backup و Replica ممکن است در کشور دیگری باشند

یکی از مهم‌ترین نکاتی که در بررسی محل ذخیره داده باید در نظر گرفته شود، محل نگهداری نسخه‌های پشتیبان و Replicaها است.

بسیاری از سرویس‌های ابری برای افزایش دسترس‌پذیری و جلوگیری از از دست رفتن اطلاعات، داده‌ها را در چند سیستم یا دیتاسنتر کپی می‌کنند. این فرآیند معمولاً تحت عنوان Replication شناخته می‌شود.

Replication می‌تواند در چند حالت انجام شود:

• داخل همان دیتاسنتر
• بین چند Availability Zone
• بین چند دیتاسنتر
• بین چند Region جغرافیایی

اگر Cross-Region Replication فعال باشد، ممکن است نسخه‌ای از اطلاعات سازمان در کشور یا منطقه‌ای متفاوت از سرور اصلی ذخیره شود.

همین مسئله درباره Backup نیز وجود دارد. ممکن است سرور اصلی در یک کشور قرار داشته باشد اما ارائه‌دهنده، نسخه‌های پشتیبان را در زیرساخت دیگری نگهداری کند.

به همین دلیل، هنگام بررسی سیاست ذخیره داده یک Cloud Provider باید مشخص شود که Backup و Replica دقیقاً در کدام Region یا کشور قرار می‌گیرند و آیا مشتری امکان کنترل این محل را دارد یا خیر.

نقش CDN در محل ذخیره داده

CDN یا Content Delivery Network برای افزایش سرعت دسترسی کاربران، محتوا را روی سرورهای مختلف در نقاط متعدد جهان توزیع می‌کند.

فایل‌هایی مانند:

• تصاویر
• فایل‌های CSS
• JavaScript
• ویدئو
• فایل‌های دانلودی
• نسخه Cache شده صفحات

ممکن است روی Edge Serverهای مختلف در کشورهای گوناگون ذخیره شوند.

در این شرایط، حتی اگر سرور اصلی وب‌سایت در یک کشور مشخص قرار داشته باشد، بخشی از داده‌های آن ممکن است از طریق CDN در ده‌ها کشور Cache شود.

البته این موضوع الزاماً به این معنی نیست که تمام اطلاعات حساس شرکت در CDN ذخیره می‌شوند. نحوه Cache شدن اطلاعات به تنظیمات CDN و نوع سرویس بستگی دارد. با این حال، سازمان باید مشخص کند چه نوع داده‌ای اجازه دارد از طریق CDN توزیع شود.

اطلاعات حساس، داده‌های شخصی یا پاسخ‌های API نباید بدون بررسی دقیق سیاست Cache روی شبکه‌های توزیع محتوا قرار بگیرند.

Object Storage نیز می‌تواند محل جداگانه‌ای داشته باشد

بسیاری از سازمان‌ها فایل‌های خود را مستقیماً روی سرور اصلی ذخیره نمی‌کنند و از Object Storage استفاده می‌کنند.

سرویس‌هایی مانند Object Storage معمولاً برای نگهداری موارد زیر استفاده می‌شوند:

• فایل‌های کاربران
• تصاویر و ویدئوها
• Backup
• آرشیوها
• Logها
• فایل‌های نرم‌افزار
• داده‌های حجیم

در بسیاری از Cloud Providerها، Object Storage یک سرویس مستقل از Compute است. بنابراین ممکن است سرور مجازی در یک Region و Object Storage در Region دیگری قرار داشته باشد.

اگر محل ذخیره داده برای سازمان اهمیت حقوقی یا امنیتی دارد، Region مربوط به Object Storage نیز باید به‌صورت جداگانه بررسی شود.

سرویس‌های جانبی می‌توانند داده را به نقاط دیگری منتقل کنند

یکی دیگر از بخش‌هایی که معمولاً در بررسی محل ذخیره داده نادیده گرفته می‌شود، سرویس‌های جانبی هستند.

یک زیرساخت Cloud ممکن است علاوه بر سرور اصلی از سرویس‌های متعددی استفاده کند، از جمله:

• سیستم مانیتورینگ
• مدیریت Log
• ابزارهای تحلیل رفتار کاربران
• سرویس‌های ایمیل
• سیستم پشتیبانی مشتریان
• مدیریت خطا و Crash Reporting
• سیستم Backup
• ابزارهای امنیتی
• سرویس‌های احراز هویت

هرکدام از این سرویس‌ها ممکن است بخشی از اطلاعات سازمان را دریافت، پردازش یا ذخیره کنند.

برای مثال، یک ابزار Error Monitoring ممکن است هنگام ثبت خطا اطلاعاتی از درخواست کاربر، آدرس IP یا بخشی از Payload را نیز دریافت کند. اگر زیرساخت این سرویس در کشور دیگری باشد، بخشی از داده سازمان عملاً از محیط اصلی خارج شده است.

یک نمونه ساده از مسیر واقعی داده

فرض کنید یک شرکت سرور اصلی خود را در یک Region اروپایی راه‌اندازی کرده است.

ساختار آن ممکن است به این شکل باشد:

Web Server: آلمان
Database: آلمان
Object Storage: هلند
Backup: فنلاند
CDN: چندین کشور در اروپا و آسیا
Monitoring: آمریکا
Email Service: ایرلند

در ظاهر ممکن است مدیر شرکت تصور کند تمام اطلاعات در آلمان ذخیره می‌شوند؛ در حالی که در عمل چند سرویس مختلف در چند حوزه جغرافیایی با داده‌های سازمان در ارتباط هستند.

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

چگونه محل واقعی ذخیره داده را مشخص کنیم؟

برای مشخص کردن محل واقعی اطلاعات، بهتر است یک Data Map برای زیرساخت تهیه شود. در این نقشه باید مشخص شود هر نوع داده از چه مسیری عبور می‌کند و در چه سرویس‌هایی ذخیره یا پردازش می‌شود.

برای هر سرویس حداقل این پرسش‌ها باید پاسخ داده شوند:

• داده اصلی در کدام Region ذخیره می‌شود؟
• Backup در کجا نگهداری می‌شود؟
• آیا Cross-Region Replication فعال است؟
• Object Storage در کدام منطقه قرار دارد؟
• CDN چه داده‌هایی را Cache می‌کند؟
• Logها به کدام سرویس ارسال می‌شوند؟
• سرویس‌های جانبی در چه کشورهایی فعالیت می‌کنند؟
• آیا امکان محدود کردن محل پردازش یا ذخیره داده وجود دارد؟

پاسخ به این سؤالات تصویر بسیار دقیق‌تری از محل واقعی اطلاعات سازمان ارائه می‌دهد.

در نهایت، زمانی می‌توان با اطمینان گفت داده‌های یک شرکت کجا قرار دارند که علاوه بر سرور اصلی، Backup، Replica، CDN، Object Storage و تمام سرویس‌های جانبی نیز بررسی شده باشند. در معماری‌های Cloud، ذخیره داده معمولاً یک نقطه مشخص نیست؛ بلکه زنجیره‌ای از سرویس‌ها و زیرساخت‌های مختلف است که باید به‌صورت یکپارچه ارزیابی شوند.

ریسک‌های پنهان ابرهای خارجی برای شرکت‌های ایرانی

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

بخش مهمی از این ریسک‌ها مستقیماً به ذخیره داده مربوط می‌شوند. مسئله فقط این نیست که اطلاعات سازمان در کدام دیتاسنتر قرار دارد؛ بلکه باید بررسی شود در صورت محدود شدن حساب، قطع دسترسی یا مشکل در پرداخت، آیا شرکت همچنان می‌تواند به داده‌های خود دسترسی داشته باشد و آن‌ها را به زیرساخت دیگری منتقل کند یا خیر.

ریسک تحریم و مسدود شدن سرویس

یکی از مهم‌ترین ریسک‌ها برای شرکت‌های ایرانی، تغییر در محدودیت‌های ارائه سرویس به کاربران یا کسب‌وکارهای مرتبط با ایران است.

ممکن است یک سرویس ابری در زمان ثبت‌نام و استفاده اولیه در دسترس باشد، اما در آینده سیاست‌های داخلی شرکت، مقررات بین‌المللی یا الزامات حقوقی تغییر کنند. در چنین شرایطی، امکان دارد ارائه برخی خدمات محدود شود یا حساب مشتری نیاز به بررسی بیشتری پیدا کند.

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

برای کاهش این ریسک، سازمان نباید تنها نسخه فعال داده‌های خود را در یک Cloud Provider نگهداری کند. وجود Backup مستقل و قابل بازیابی روی زیرساختی خارج از ارائه‌دهنده اصلی اهمیت زیادی دارد.

ریسک تعلیق یا حذف حساب کاربری

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

در چنین شرایطی، اولین پرسش این نیست که «چرا حساب بسته شده است؟» بلکه باید پرسید:

اگر همین امروز دسترسی حساب متوقف شود، آیا هنوز به داده‌های خود دسترسی داریم؟

اگر تمام ذخیره داده، Backup، Database و Object Storage سازمان تحت همان حساب قرار داشته باشند، تعلیق حساب می‌تواند دسترسی به چندین بخش زیرساخت را به‌صورت هم‌زمان مختل کند.

به همین دلیل، سازمان‌ها باید از قبل مشخص کنند:

• چه داده‌هایی خارج از Provider اصلی Backup می‌شوند؟
• چه مدت برای بازیابی سرویس نیاز دارند؟
• آیا Export کامل اطلاعات ممکن است؟
• آیا حساب جایگزین یا زیرساخت ثانویه وجود دارد؟
• اطلاعات ضروری برای Migration در جایی مستقل نگهداری می‌شوند یا خیر؟

ریسک محدود شدن دسترسی به پنل یا API

در زیرساخت‌های مدرن، مدیریت Cloud فقط از طریق یک پنل گرافیکی انجام نمی‌شود. بسیاری از عملیات به API، CLI، Automation و ابزارهای Infrastructure as Code وابسته هستند.

اگر دسترسی به پنل یا API محدود شود، ممکن است تیم فنی نتواند عملیات مهمی مانند موارد زیر را انجام دهد:

• ایجاد یا حذف ماشین مجازی
• دریافت Snapshot
• مدیریت Firewall
• تغییر DNS
• دریافت Backup
• مدیریت Object Storage
• تغییر دسترسی کاربران
• اجرای فرآیند Migration

حتی اگر سرویس همچنان روشن باشد، محدودیت در لایه مدیریتی می‌تواند تیم فنی را در شرایط بحرانی با مشکل مواجه کند.

از منظر ذخیره داده، این موضوع زمانی خطرناک‌تر می‌شود که برای دریافت Backup یا Export اطلاعات نیز به همان API یا پنل وابسته باشیم.

در نتیجه، بخشی از برنامه مدیریت ریسک باید شامل روش‌های مستقل برای بازیابی یا استخراج داده باشد.

ریسک عدم امکان پرداخت و تمدید

یکی از ریسک‌های عملیاتی مهم برای شرکت‌های ایرانی، وابستگی به روش‌های پرداخت بین‌المللی است.

ممکن است در مقطعی سرویس بدون مشکل کار کند اما تمدید آن به دلایلی مانند تغییر روش پرداخت، محدود شدن کارت، تغییر شرایط Provider یا مشکل در واسطه پرداخت امکان‌پذیر نباشد.

اگر سازمان برای ذخیره داده و اجرای سرویس‌های حیاتی به آن Provider وابسته باشد، مشکل پرداخت می‌تواند مستقیماً به ریسک توقف سرویس تبدیل شود.

برای مثال، سازمانی را در نظر بگیرید که موارد زیر را روی یک سرویس ابری نگهداری می‌کند:

• سرورهای Production
• Database
• Backup
• Object Storage
• DNS
• Monitoring

اگر تمدید حساب با مشکل مواجه شود، ممکن است چندین سرویس حیاتی به‌صورت هم‌زمان تحت تأثیر قرار بگیرند.

برای کاهش این ریسک، تیم IT باید از قبل بداند در صورت عدم امکان تمدید چه مدت زمان برای انتقال سرویس‌ها در اختیار دارد و داده‌ها از چه مسیری قابل بازیابی هستند.

ریسک انتقال اجباری یا ناگهانی داده

یکی دیگر از سناریوهایی که باید در برنامه تداوم کسب‌وکار در نظر گرفته شود، نیاز ناگهانی به انتقال داده از یک Provider است.

این انتقال ممکن است به دلایل مختلف انجام شود:

• تغییر سیاست‌های ارائه‌دهنده
• افزایش شدید هزینه
• محدود شدن سرویس
• تغییر Region
• پایان همکاری با Provider
• مشکلات حقوقی
• مشکلات پرداخت
• نیاز به انتقال به زیرساخت داخلی

در چنین شرایطی، حجم و ساختار ذخیره داده اهمیت زیادی پیدا می‌کند.

انتقال چند گیگابایت اطلاعات معمولاً ساده است، اما انتقال چند ترابایت Object Storage، چند Database بزرگ و تعداد زیادی Backup می‌تواند زمان‌بر و پرهزینه باشد.

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

بزرگ‌ترین خطر؛ نداشتن Exit Strategy

بسیاری از سازمان‌ها هنگام انتخاب Cloud Provider فقط درباره شروع همکاری تصمیم می‌گیرند و برای پایان همکاری برنامه مشخصی ندارند.

در حالی که یکی از مهم‌ترین پرسش‌ها باید این باشد:

اگر فردا مجبور شویم این Provider را ترک کنیم، چگونه سرویس و داده‌های خود را منتقل خواهیم کرد؟

یک Exit Strategy مناسب باید حداقل شامل این موارد باشد:

• Backup مستقل از Provider
• مستندات معماری
• فهرست کامل سرویس‌های وابسته
• روش Export داده‌ها
• برنامه Migration
• زمان تخمینی انتقال
• زیرساخت جایگزین
• فرآیند تغییر DNS
• اولویت سرویس‌های حیاتی

در این شرایط، ذخیره داده باید به‌گونه‌ای طراحی شود که خروج از Provider امکان‌پذیر باشد و داده‌ها در قالب‌های قابل انتقال نگهداری شوند.

وابستگی کامل به یک Provider، ریسک را چند برابر می‌کند

اگر Compute، Database، Backup، DNS، Monitoring و Object Storage همگی روی یک Provider قرار داشته باشند، یک مشکل در سطح حساب می‌تواند چندین سرویس را هم‌زمان تحت تأثیر قرار دهد.

به همین دلیل، برای سرویس‌های حیاتی بهتر است حداقل بخشی از فرآیند Backup و بازیابی مستقل از زیرساخت اصلی باشد.

هدف الزاماً استفاده هم‌زمان از چند Cloud Provider نیست. مهم‌تر این است که سازمان در شرایط بحرانی بتواند به داده‌های اصلی خود دسترسی پیدا کند و زیرساخت را روی محیط دیگری بازیابی کند.

برای شرکت‌های ایرانی، ذخیره داده روی ابر خارجی باید همراه با یک برنامه مشخص برای Backup مستقل، Migration و بازیابی اضطراری باشد. مزایای Cloud زمانی ارزشمند هستند که سازمان در کنار استفاده از آن‌ها، کنترل واقعی بر داده‌های خود را نیز حفظ کند.

ریسک‌های حقوقی و حاکمیت داده

یکی از مهم‌ترین موضوعاتی که هنگام انتخاب سرویس ابری باید بررسی شود، وضعیت حقوقی داده‌ها است. بسیاری از سازمان‌ها محل ذخیره داده را صرفاً یک تصمیم فنی می‌دانند، در حالی که محل نگهداری اطلاعات می‌تواند تعیین کند چه قوانین، مقررات و الزامات قضایی بر آن‌ها اثر بگذارند.

در یک معماری ابری، ممکن است شرکت ارائه‌دهنده در یک کشور ثبت شده باشد، دیتاسنتر در کشور دیگری قرار داشته باشد و بخشی از Backup یا سرویس‌های جانبی نیز در منطقه‌ای متفاوت فعالیت کنند. همین موضوع باعث می‌شود تعیین چارچوب حقوقی حاکم بر داده همیشه ساده نباشد.

داده تحت قوانین کدام کشور قرار می‌گیرد؟

یکی از اولین سؤالاتی که هر سازمان باید مطرح کند این است:

اطلاعات ما تحت قوانین کدام کشور نگهداری و پردازش می‌شوند؟

پاسخ به این سؤال همیشه فقط به محل دیتاسنتر بستگی ندارد. عوامل مختلفی می‌توانند در تعیین چارچوب حقوقی مؤثر باشند، از جمله:

• محل ثبت شرکت ارائه‌دهنده سرویس
• محل فیزیکی دیتاسنتر
• Region انتخاب‌شده
• محل پردازش داده
• محل نگهداری Backup
• شرایط قرارداد سرویس
• قوانین کشور محل فعالیت مشتری
• قوانین مربوط به انتقال داده بین کشورها

برای مثال، ممکن است محل اصلی ذخیره داده در یک کشور اروپایی باشد، اما شرکت ارائه‌دهنده Cloud در کشور دیگری ثبت شده باشد. در چنین شرایطی، بررسی صرف محل سرور برای درک کامل وضعیت حقوقی کافی نیست.

سازمان باید Terms of Service، Privacy Policy، Data Processing Agreement و سایر مستندات قراردادی ارائه‌دهنده را نیز بررسی کند تا مشخص شود رابطه حقوقی طرفین بر اساس چه قوانینی تعریف شده است.

دسترسی دولت‌ها و نهادهای قضایی به داده

یکی از نگرانی‌های مهم در حوزه حاکمیت داده، امکان درخواست دسترسی به اطلاعات توسط نهادهای قانونی و قضایی است.

ارائه‌دهندگان Cloud معمولاً موظف‌اند در چارچوب قوانین قابل اعمال، به برخی دستورات قانونی معتبر پاسخ دهند. نوع درخواست، فرآیند بررسی و میزان اطلاعات قابل ارائه به قوانین حوزه قضایی مربوط بستگی دارد.

از این منظر، ذخیره داده در یک کشور خارجی به این معنا است که سازمان باید علاوه بر سیاست‌های امنیتی Provider، محیط حقوقی آن کشور را نیز در ارزیابی ریسک خود در نظر بگیرد.

این موضوع به‌ویژه زمانی اهمیت بیشتری پیدا می‌کند که داده شامل اطلاعات حساس باشد، مانند:

• اطلاعات شخصی مشتریان
• اطلاعات مالی
• اسناد سازمانی
• قراردادها
• اطلاعات کارکنان
• مالکیت فکری
• اطلاعات محرمانه تجاری

در چنین مواردی، رمزنگاری داده و مدیریت صحیح Encryption Key می‌تواند لایه مهمی از کنترل را در اختیار سازمان قرار دهد.

تعارض قوانین محلی با قوانین کشور میزبان

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

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

همچنین ممکن است مقررات یک کشور برای انتقال برخی انواع داده به خارج از مرزهای آن محدودیت ایجاد کند.

به همین دلیل، سازمان‌هایی که داده‌های حساس یا گسترده مشتریان را پردازش می‌کنند باید پیش از انتخاب محل ذخیره داده مشخص کنند:

• آیا انتقال این داده به کشور دیگر مجاز است؟
• آیا محدودیتی برای مدت نگهداری داده وجود دارد؟
• فرآیند حذف داده چگونه انجام می‌شود؟
• آیا Backupهای حذف‌شده نیز پس از مدتی پاک می‌شوند؟
• چه قوانینی بر درخواست دسترسی به داده حاکم هستند؟
• در صورت اختلاف، مرجع رسیدگی کدام کشور خواهد بود؟

این بررسی برای سازمان‌های فعال در چند کشور اهمیت بیشتری دارد.

مسئولیت شرکت در برابر داده مشتریان

استفاده از یک Cloud Provider معمولاً مسئولیت سازمان را در قبال داده مشتریان از بین نمی‌برد.

یکی از اشتباهات رایج این است که تصور شود چون اطلاعات روی زیرساخت یک شرکت بزرگ Cloud نگهداری می‌شود، تمام مسئولیت امنیت و حفاظت از داده نیز بر عهده همان Provider است.

در عمل، مسئولیت‌ها معمولاً بین مشتری و ارائه‌دهنده تقسیم می‌شوند.

Provider ممکن است مسئول امنیت بخش‌هایی مانند:

• دیتاسنتر
• زیرساخت فیزیکی
• شبکه پایه
• سخت‌افزار
• لایه‌های مشخصی از پلتفرم

باشد، در حالی که سازمان همچنان مسئول مواردی مانند این موارد است:

• مدیریت حساب‌های کاربری
• تعیین سطح دسترسی
• حفاظت از رمزهای عبور و API Key
• پیکربندی صحیح سرویس‌ها
• رمزنگاری
• Backup
• کنترل دسترسی به داده
• مدیریت اطلاعات مشتریان

بنابراین انتخاب Provider معتبر به‌تنهایی برای کاهش ریسک ذخیره داده کافی نیست.

قرارداد با Cloud Provider را جدی بگیرید

بخش مهمی از وضعیت حقوقی داده در قرارداد و شرایط استفاده از سرویس تعریف می‌شود.

سازمان‌ها بهتر است پیش از انتقال اطلاعات حساس، مواردی مانند این موارد را بررسی کنند:

• مالکیت داده متعلق به چه کسی است؟
• Provider چه مجوزی برای پردازش داده دارد؟
• داده در چه کشورهایی پردازش می‌شود؟
• Subprocessorها چه شرکت‌هایی هستند؟
• در صورت پایان سرویس چه اتفاقی برای داده می‌افتد؟
• مدت نگهداری Backup چقدر است؟
• فرآیند حذف دائمی داده چیست؟
• در صورت درخواست نهاد قانونی چه رویه‌ای وجود دارد؟
• مسئولیت Provider در صورت Incident چگونه تعریف شده است؟

برای سرویس‌های مهم، بهتر است این موارد فقط توسط تیم فنی بررسی نشوند و تیم حقوقی یا مسئول Compliance سازمان نیز در تصمیم‌گیری مشارکت داشته باشد.

رمزنگاری می‌تواند بخشی از کنترل داده را حفظ کند

یکی از راه‌های کاهش ریسک‌های مرتبط با حاکمیت داده، رمزنگاری اطلاعات است.

داده می‌تواند در چند مرحله رمزنگاری شود:

• Data at Rest
• Data in Transit
• Backup
• Object Storage
• Database

اما مسئله مهم فقط فعال بودن Encryption نیست؛ بلکه مالکیت و کنترل Encryption Key نیز اهمیت دارد.

اگر Provider هم داده و هم کلید رمزگشایی را در اختیار داشته باشد، سطح کنترل سازمان با حالتی که کلیدها به‌صورت مستقل مدیریت می‌شوند متفاوت است.

در سرویس‌های حساس، استفاده از مدل‌هایی مانند Customer Managed Keys یا نگهداری کلیدها در سیستم مستقل می‌تواند کنترل بیشتری روی ذخیره داده ایجاد کند.

حاکمیت داده فقط یک مسئله حقوقی نیست

Data Governance یا حاکمیت داده مجموعه‌ای از سیاست‌ها و فرآیندهایی است که مشخص می‌کند داده چگونه ایجاد، ذخیره، استفاده، منتقل و حذف شود.

یک سیاست مناسب حاکمیت داده باید مشخص کند:

• چه نوع داده‌ای داریم؟
• هر داده چقدر حساس است؟
• کجا اجازه داریم آن را ذخیره کنیم؟
• چه کسانی اجازه دسترسی دارند؟
• چه مدت باید نگهداری شود؟
• چه زمانی باید حذف شود؟
• Backup آن در کجا قرار دارد؟
• در صورت خروج از Provider چگونه منتقل می‌شود؟

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

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

شما همیشه کنترل کامل روی داده ندارید

یکی از مهم‌ترین سوءبرداشت‌ها درباره سرویس‌های ابری این است که تصور کنیم چون داده متعلق به سازمان است، پس کنترل کامل آن نیز همیشه در اختیار سازمان قرار دارد.

در بسیاری از سرویس‌ها، از نظر قراردادی مالکیت اطلاعات همچنان متعلق به مشتری است، اما کنترل عملیاتی روی ذخیره داده می‌تواند به زیرساخت، ابزارها، APIها و سیاست‌های ارائه‌دهنده وابسته باشد.

به همین دلیل باید میان «مالکیت داده» و «کنترل واقعی روی داده» تفاوت قائل شد.

ممکن است سازمان مالک اطلاعات باشد، اما نتواند آن‌ها را در هر زمان، با هر فرمت یا با سرعت موردنیاز خود از سرویس خارج کند.

چه کسی مالک واقعی داده است؟

در اغلب سرویس‌های حرفه‌ای Cloud، داده‌های مشتری از نظر قراردادی متعلق به خود مشتری باقی می‌مانند. اما این موضوع به این معنا نیست که Provider هیچ نقشی در نحوه دسترسی، پردازش یا نگهداری آن‌ها ندارد.

ارائه‌دهنده سرویس معمولاً برای ارائه خدمات، مجوزهای مشخصی برای پردازش، انتقال، Backup یا Replication اطلاعات دریافت می‌کند.

به همین دلیل، هنگام بررسی شرایط ذخیره داده باید به مواردی مانند این موارد توجه شود:

• مالکیت داده در قرارداد چگونه تعریف شده است؟
• Provider چه مجوزی برای پردازش اطلاعات دارد؟
• آیا داده برای اهداف دیگری نیز پردازش می‌شود؟
• آیا Subprocessorهای دیگری به داده دسترسی دارند؟
• پس از پایان قرارداد، داده تا چه مدت نگهداری می‌شود؟
• حذف دائمی اطلاعات چگونه انجام می‌شود؟

مالکیت حقوقی مهم است، اما برای مدیریت ریسک کافی نیست. چیزی که اهمیت بیشتری دارد این است که سازمان در عمل تا چه اندازه بتواند داده خود را دریافت، منتقل، حذف یا بازیابی کند.

آیا می‌توانید همه داده را Export کنید؟

یکی از مهم‌ترین سؤالات هنگام انتخاب Cloud Provider این است:

آیا در صورت نیاز می‌توان تمام اطلاعات را از سرویس خارج کرد؟

بسیاری از سرویس‌ها امکان Export ارائه می‌دهند، اما این قابلیت ممکن است محدودیت‌هایی داشته باشد.

برای مثال، ممکن است بتوان فایل‌های اصلی را دانلود کرد اما Export کامل شامل این موارد نباشد:

• Metadata
• تنظیمات سرویس
• Permissionها
• Logها
• Snapshotها
• تاریخچه تغییرات
• Policyها
• Secretها
• تنظیمات شبکه
• اطلاعات Monitoring

در نتیجه، خروج کامل از یک سرویس همیشه به معنای دانلود فایل‌ها نیست.

برای زیرساخت‌های پیچیده، باید مشخص شود آیا تمام اجزای مربوط به ذخیره داده و پیکربندی سرویس قابل انتقال هستند یا خیر.

علاوه بر این، محدودیت‌هایی مانند سرعت خروج داده، حجم اطلاعات و هزینه انتقال نیز باید بررسی شوند.

اگر سازمان چندین ترابایت داده داشته باشد، Export اطلاعات می‌تواند زمان‌بر و پرهزینه باشد.

Vendor Lock-in چیست؟

Vendor Lock-in به شرایطی گفته می‌شود که یک سازمان به سرویس‌ها، فناوری‌ها یا ساختار اختصاصی یک Provider به اندازه‌ای وابسته شود که انتقال به ارائه‌دهنده دیگر دشوار، پرهزینه یا زمان‌بر باشد.

Vendor Lock-in فقط به ذخیره داده مربوط نمی‌شود و می‌تواند در چند لایه ایجاد شود.

برای مثال:

• Database اختصاصی Provider
• APIهای اختصاصی
• سرویس‌های Serverless
• Object Storage با قابلیت‌های اختصاصی
• سیستم IAM اختصاصی
• ابزارهای Monitoring
• Queue و Messaging
• سیستم Backup اختصاصی
• سرویس‌های AI یا Analytics

هرچه معماری بیشتر به سرویس‌های اختصاصی Provider وابسته باشد، مهاجرت دشوارتر خواهد شد.

برای مثال، انتقال یک ماشین مجازی استاندارد معمولاً ساده‌تر از انتقال یک معماری متشکل از چندین سرویس اختصاصی Managed است.

Backup شما کجاست؟

یکی از مهم‌ترین بخش‌های هر استراتژی ذخیره داده، محل نگهداری نسخه‌های پشتیبان است. بسیاری از سازمان‌ها تصور می‌کنند وقتی Cloud Provider از اطلاعات آن‌ها Backup می‌گیرد، دیگر نگرانی خاصی وجود ندارد. اما اگر Backup در همان حساب، همان Region یا حتی همان Provider نگهداری شود، بخشی از ریسک همچنان باقی می‌ماند.

Backup زمانی ارزش واقعی دارد که در شرایط بحرانی نیز قابل دسترسی و بازیابی باشد.

خطر Backup در همان Provider

فرض کنید تمام زیرساخت یک شرکت روی یک Cloud Provider قرار دارد و نسخه‌های پشتیبان نیز روی همان سرویس نگهداری می‌شوند.

در این حالت ممکن است موارد زیر همگی تحت یک حساب قرار داشته باشند:

• Virtual Machine
• Database
• Object Storage
• Snapshot
• Backup
• DNS
• Monitoring

اگر مشکل در سطح یک سرور اتفاق بیفتد، Backup همان Provider می‌تواند بسیار مفید باشد. اما اگر مشکل در سطح حساب، Region یا خود ارائه‌دهنده رخ دهد، شرایط متفاوت خواهد بود.

برای مثال، اگر حساب کاربری تعلیق شود، ممکن است دسترسی به سرور اصلی و Backup به‌صورت هم‌زمان محدود شود.

در چنین شرایطی، وجود Backup الزاماً به معنی امکان بازیابی اطلاعات نیست.

این یکی از دلایلی است که در طراحی ذخیره داده نباید نسخه اصلی و تمام Backupها به یک نقطه وابسته باشند.

ضرورت Backup مستقل

Backup مستقل یعنی حداقل یک نسخه از اطلاعات خارج از زیرساخت اصلی نگهداری شود.

این نسخه می‌تواند در یکی از محل‌های زیر قرار داشته باشد:

• Cloud Provider دیگر
• دیتاسنتر دیگر
• Object Storage مستقل
• زیرساخت داخلی سازمان
• سیستم Backup اختصاصی

هدف این نیست که حتماً تمام اطلاعات در چند Cloud مختلف هم‌زمان فعال باشند. هدف این است که در صورت از دست رفتن Provider اصلی، داده حیاتی همچنان در دسترس باشد.

برای مثال، اگر سرویس اصلی روی یک Cloud خارجی قرار دارد، می‌توان Backup روزانه Database و فایل‌های اصلی را روی یک Object Storage مستقل نگهداری کرد.

در چنین مدلی، حتی اگر دسترسی به Cloud اصلی از بین برود، امکان بازیابی اطلاعات روی زیرساخت جدید وجود خواهد داشت.

قانون 3-2-1 Backup چیست؟

یکی از شناخته‌شده‌ترین اصول در طراحی Backup، قانون 3-2-1 است.

این قانون پیشنهاد می‌کند:

3 نسخه از داده داشته باشید

یعنی داده اصلی به همراه حداقل دو نسخه Backup نگهداری شود.

از 2 نوع رسانه یا محل ذخیره‌سازی متفاوت استفاده کنید

برای مثال، یک نسخه روی Storage اصلی و نسخه دیگر روی Object Storage یا سیستم Backup مستقل قرار گیرد.

حداقل 1 نسخه خارج از محل اصلی نگهداری شود

این نسخه نباید تحت همان نقطه خرابی قرار داشته باشد.

در محیط‌های Cloud می‌توان این مدل را به شکل زیر پیاده کرد:

• نسخه اصلی روی Cloud Provider A
• Backup اول روی Storage مستقل
• Backup دوم روی Cloud Provider B یا زیرساخت داخلی

این مدل باعث می‌شود خرابی یک سرویس یا Provider به معنی از دست رفتن کامل ذخیره داده نباشد.

Backup خارج از Cloud Provider اصلی

برای شرکت‌هایی که از ابر خارجی استفاده می‌کنند، داشتن حداقل یک Backup خارج از Cloud Provider اصلی اهمیت بیشتری دارد.

این Backup باید در شرایطی قابل استفاده باشد که:

• حساب Provider اصلی مسدود شده باشد
• Region در دسترس نباشد
• API قطع شده باشد
• پرداخت سرویس امکان‌پذیر نباشد
• حساب حذف شده باشد
• سرویس موردنظر متوقف شده باشد

نکته مهم این است که Backup مستقل نباید برای بازیابی به ابزار اختصاصی همان Provider وابسته باشد.

برای مثال، اگر Backup فقط در قالب یک Snapshot اختصاصی ذخیره شده باشد که تنها داخل همان Cloud قابل Restore است، در سناریوی خروج از Provider کاربرد محدودی خواهد داشت.

برای داده‌های حیاتی بهتر است نسخه‌ای در قالب‌های عمومی و قابل‌انتقال نگهداری شود.

برای مثال:

• SQL Dump برای Database
• فایل‌های استاندارد برای Object Storage
• Archive برای فایل‌های سرور
• Export قابل استفاده برای Configuration
• نسخه مستندشده از تنظیمات شبکه و سرویس‌ها

فقط Backup نگیرید؛ Restore را هم آزمایش کنید

یکی از اشتباهات متداول این است که سازمان گزارش موفقیت Backup را دریافت می‌کند و تصور می‌کند اطلاعات قابل بازیابی هستند.

اما Backup موفق و Restore موفق دو موضوع متفاوت هستند.

ممکن است Backup وجود داشته باشد اما:

• فایل خراب باشد
• رمزنگاری آن قابل بازیابی نباشد
• Credential موردنیاز در دسترس نباشد
• نسخه با سیستم جدید سازگار نباشد
• بخشی از داده‌ها Backup نشده باشند

به همین دلیل، فرآیند Restore باید به‌صورت دوره‌ای آزمایش شود.

در واقع، کیفیت استراتژی ذخیره داده را نباید فقط با تعداد Backupها سنجید؛ بلکه باید بررسی کرد سازمان با چه سرعت و دقتی می‌تواند سرویس را از روی آن‌ها بازیابی کند.

Disaster Recovery در ابر خارجی چه چالش‌هایی دارد؟

Backup تنها یکی از اجزای Disaster Recovery است.

Disaster Recovery یا بازیابی پس از بحران، مجموعه فرآیندها و زیرساخت‌هایی است که برای بازگرداندن سرویس‌های سازمان پس از یک اختلال جدی استفاده می‌شود.

این اختلال می‌تواند ناشی از موارد مختلف باشد:

• خرابی دیتاسنتر
• حمله سایبری
• حذف اطلاعات
• مشکل شبکه
• خطای انسانی
• مسدود شدن حساب
• قطع دسترسی به Cloud Provider

برای شرکت‌های ایرانی، سناریوی Disaster Recovery باید علاوه بر مشکلات فنی، ریسک‌های دسترسی و محدودیت‌های بین‌المللی را نیز در نظر بگیرد.

RPO و RTO چیست؟

دو شاخص مهم در Disaster Recovery عبارت‌اند از RPO و RTO.

RPO یا Recovery Point Objective مشخص می‌کند سازمان حداکثر چه مقدار از داده جدید را می‌تواند از دست بدهد.

برای مثال، اگر RPO برابر با یک ساعت باشد، سیستم Backup باید به‌گونه‌ای طراحی شود که در بدترین حالت حداکثر یک ساعت داده از دست برود.

اگر Backup فقط روزی یک‌بار گرفته شود، دستیابی به RPO یک‌ساعته امکان‌پذیر نیست.

RTO یا Recovery Time Objective مشخص می‌کند سرویس پس از وقوع بحران حداکثر در چه مدت باید دوباره فعال شود.

برای مثال:

• RTO برابر با 30 دقیقه
• RTO برابر با 4 ساعت
• RTO برابر با 24 ساعت

هرچه RPO و RTO کمتر باشند، زیرساخت Backup و Disaster Recovery معمولاً پیچیده‌تر و پرهزینه‌تر خواهد بود.

بنابراین طراحی ذخیره داده باید بر اساس اهمیت هر سرویس انجام شود.

یک وب‌سایت اطلاع‌رسانی ممکن است RTO یک‌روزه را بپذیرد، اما یک سامانه فروش آنلاین یا سرویس مالی ممکن است نیاز به بازیابی در چند دقیقه داشته باشد.

بازیابی در شرایط تحریم

برای یک شرکت ایرانی، سناریوی Disaster Recovery نباید فقط خرابی فنی را در نظر بگیرد.

باید این سؤال نیز مطرح شود:

اگر Cloud Provider اصلی قابل دسترسی نباشد، آیا هنوز می‌توانیم سرویس را بازیابی کنیم؟

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

• وارد حساب شود
• پرداخت انجام دهد
• API را فراخوانی کند
• Snapshot ایجاد کند
• Backup دانلود کند
• سرویس جدید ایجاد کند

در چنین شرایطی، Disaster Recovery باید مستقل از Provider اصلی طراحی شده باشد.

اگر تمام اطلاعات موردنیاز برای بازیابی داخل همان Cloud قرار داشته باشند، فرآیند بازیابی عملاً متوقف می‌شود.

به همین دلیل، اطلاعات حیاتی مرتبط با ذخیره داده، Backup، مستندات و Credentialهای ضروری باید به‌صورت امن و مستقل نیز نگهداری شوند.

دسترسی اضطراری به زیرساخت

در زمان بحران، تیم فنی باید بتواند بدون وابستگی به یک شخص یا یک سیستم خاص به زیرساخت ضروری دسترسی پیدا کند.

برای این منظور بهتر است موارد زیر از قبل مشخص باشند:

• حساب‌های Emergency Access
• روش بازیابی MFA
• کلیدهای SSH اضطراری
• دسترسی به Domain Registrar
• دسترسی مستقل به DNS
• اطلاعات Backup
• کلیدهای رمزنگاری
• مستندات شبکه
• اطلاعات Credential Vault

یکی از ریسک‌های مهم این است که تمام دسترسی‌های حیاتی در یک Password Manager یا Identity Provider قرار داشته باشند که خود آن نیز به زیرساخت اصلی وابسته است.

در طراحی Disaster Recovery باید بررسی شود که تیم در شرایط قطع کامل سرویس اصلی همچنان بتواند به ابزارهای ضروری دسترسی داشته باشد.

سناریوی قطع کامل سرویس‌دهنده

یکی از بهترین روش‌ها برای ارزیابی آمادگی سازمان، طراحی یک سناریوی ساده است:

فرض کنید از همین لحظه Cloud Provider اصلی کاملاً در دسترس نیست.

در این شرایط تیم باید بداند:

1. آخرین Backup سالم کجاست؟
2. چگونه می‌توان آن را دریافت کرد؟
3. زیرساخت جایگزین کجاست؟
4. چه کسی مسئول راه‌اندازی آن است؟
5. Database چگونه Restore می‌شود؟
6. فایل‌ها چگونه منتقل می‌شوند؟
7. DNS چگونه تغییر می‌کند؟
8. Secretها و Certificateها از کجا دریافت می‌شوند؟
9. سرویس‌ها با چه اولویتی راه‌اندازی می‌شوند؟
10. بازیابی کامل چقدر زمان می‌برد؟

اگر پاسخ این سؤالات مشخص نباشد، Disaster Recovery هنوز بیشتر یک مفهوم است تا یک برنامه عملیاتی.

Disaster Recovery باید مستند و آزمایش شود

وجود Backup، Server دوم یا Cloud Provider جایگزین به‌تنهایی کافی نیست.

سازمان باید یک Runbook مشخص برای بازیابی داشته باشد.

این Runbook می‌تواند شامل موارد زیر باشد:

• فهرست سرویس‌های حیاتی
• ترتیب بازیابی
• محل Backupها
• Credentialهای موردنیاز
• مسئول هر مرحله
• روش Restore Database
• روش Restore فایل‌ها
• تنظیم DNS
• تست سلامت سرویس
• فرآیند بازگشت به حالت عادی

این برنامه باید به‌صورت دوره‌ای آزمایش شود.

در تست Disaster Recovery بهتر است سناریوهایی مانند قطع Provider اصلی، از دست رفتن Database یا عدم دسترسی به حساب Cloud شبیه‌سازی شوند.

نتیجه تست نیز باید ثبت شود تا مشخص شود RPO و RTO واقعی سازمان با اهداف تعیین‌شده مطابقت دارند یا خیر.

در نهایت، هدف اصلی Disaster Recovery این است که ذخیره داده و سرویس‌های حیاتی سازمان حتی در بدترین سناریوها قابل بازیابی باشند. برای شرکت‌هایی که از ابر خارجی استفاده می‌کنند، این موضوع اهمیت بیشتری دارد؛ زیرا سناریوی بحران ممکن است فقط یک خرابی فنی نباشد و محدودیت دسترسی، پرداخت یا حساب کاربری را نیز شامل شود.

چک‌لیست ارزیابی سرویس ابری خارجی

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

چک‌لیست زیر می‌تواند به سازمان کمک کند قبل از انتخاب سرویس، ریسک‌های اصلی را شناسایی کند.

داده کجا ذخیره می‌شود؟

اولین سؤال باید درباره محل واقعی ذخیره داده باشد.

صرف انتخاب یک Region برای پاسخ به این سؤال کافی نیست. باید مشخص شود داده‌های مختلف سازمان دقیقاً در چه مناطقی نگهداری یا پردازش می‌شوند.

موارد زیر را بررسی کنید:

• Region اصلی سرورها کجاست؟
• Database در چه کشوری قرار دارد؟
• Object Storage در کدام Region نگهداری می‌شود؟
• Logها کجا ذخیره می‌شوند؟
• Replicaها در چه مناطقی قرار دارند؟
• آیا داده بین Regionهای مختلف منتقل می‌شود؟
• سرویس‌های جانبی اطلاعات را در چه کشورهایی پردازش می‌کنند؟

اگر سازمان با اطلاعات حساس، مالی یا اطلاعات مشتریان کار می‌کند، پاسخ دقیق به این سؤال اهمیت بیشتری دارد.

Backup کجاست؟

پس از مشخص شدن محل اصلی ذخیره داده، باید محل Backup را بررسی کرد.

یکی از مهم‌ترین اشتباهات این است که سرور اصلی و تمام نسخه‌های پشتیبان روی همان Provider نگهداری شوند.

از ارائه‌دهنده یا تیم فنی بپرسید:

• Backup در همان Region نگهداری می‌شود یا Region دیگری؟
• آیا Backup در Provider دیگری نیز وجود دارد؟
• امکان دانلود مستقل Backup وجود دارد؟
• Backup در چه قالبی ارائه می‌شود؟
• آیا بدون دسترسی به Provider اصلی قابل Restore است؟
• مدت نگهداری Backup چقدر است؟
• آخرین تست Restore چه زمانی انجام شده است؟

برای سرویس‌های حیاتی، حداقل یک Backup مستقل از Cloud Provider اصلی توصیه می‌شود.

چه کسی به داده دسترسی دارد؟

محل ذخیره داده تنها بخشی از مسئله است. باید مشخص شود چه اشخاص و سرویس‌هایی امکان دسترسی به اطلاعات را دارند.

این بررسی باید شامل کاربران داخلی و Provider باشد.

در سطح سازمان بررسی کنید:

• چه افرادی Administrator هستند؟
• دسترسی Root یا Full Access در اختیار چه کسانی است؟
• آیا Principle of Least Privilege رعایت شده است؟
• آیا MFA فعال است؟
• دسترسی‌های قدیمی و بلااستفاده حذف می‌شوند؟
• فعالیت مدیران ثبت و Audit می‌شود؟

در سطح Cloud Provider نیز بهتر است بررسی شود:

• کارکنان Provider تحت چه شرایطی می‌توانند به داده دسترسی داشته باشند؟
• آیا دسترسی‌ها Log می‌شوند؟
• چه Subprocessorهایی با داده در ارتباط هستند؟
• آیا مشتری امکان مدیریت Encryption Key را دارد؟

هرچه داده حساس‌تر باشد، کنترل دسترسی باید دقیق‌تر طراحی شود.

آیا امکان Migration وجود دارد؟

یکی از اصلی‌ترین معیارهای انتخاب سرویس ابری، امکان خروج از آن است.

قبل از انتقال ذخیره داده و سرویس‌های مهم، بررسی کنید آیا در آینده می‌توانید بدون وابستگی شدید به Provider، اطلاعات را منتقل کنید یا خیر.

سؤالات مهم عبارت‌اند از:

• آیا امکان Export کامل داده وجود دارد؟
• داده با چه فرمتی Export می‌شود؟
• Metadata نیز قابل دریافت است؟
• Database را می‌توان به سرویس دیگری منتقل کرد؟
• Snapshotها فقط در همان Provider قابل استفاده هستند؟
• برای خروج داده هزینه جداگانه دریافت می‌شود؟
• محدودیت سرعت انتقال وجود دارد؟
• APIهای لازم برای Migration در دسترس هستند؟

همچنین باید بررسی شود چه مقدار از معماری به سرویس‌های اختصاصی Provider وابسته است.

هرچه وابستگی به سرویس‌های Proprietary بیشتر باشد، احتمال Vendor Lock-in نیز بیشتر خواهد بود.

آیا سرویس برای کاربران ایرانی محدودیت دارد؟

برای شرکت‌های ایرانی این سؤال باید پیش از خرید و پیش از انتقال داده بررسی شود.

صرف امکان ثبت‌نام یا خرید سرویس به این معنا نیست که استفاده بلندمدت بدون محدودیت خواهد بود.

باید Terms of Service، سیاست‌های مربوط به کشورها و محدودیت‌های قانونی Provider بررسی شوند.

موارد مهم عبارت‌اند از:

• آیا ارائه سرویس به ایران محدود شده است؟
• آیا استفاده توسط شرکت‌های ایرانی مجاز است؟
• احراز هویت چه شرایطی دارد؟
• آیا IP ایران محدود شده است؟
• آیا پرداخت از برخی کشورها محدود است؟
• آیا برخی سرویس‌ها برای کاربران ایرانی غیرفعال هستند؟
• Provider در چه شرایطی می‌تواند حساب را تعلیق کند؟

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

در صورت مسدود شدن حساب چه برنامه‌ای داریم؟

این شاید مهم‌ترین سؤال کل چک‌لیست باشد.

سناریو را ساده در نظر بگیرید:

اگر فردا حساب Cloud Provider مسدود شود، سازمان چه کاری انجام می‌دهد؟

پاسخ نباید در زمان بحران طراحی شود.

از قبل باید مشخص باشد:

• آخرین Backup مستقل کجاست؟
• آیا می‌توان بدون ورود به حساب اصلی به Backup دسترسی داشت؟
• زیرساخت جایگزین کجاست؟
• Database چگونه Restore می‌شود؟
• DNS چگونه منتقل می‌شود؟
• Certificateها کجا نگهداری می‌شوند؟
• Secretها و Passwordها در دسترس هستند؟
• چه کسی مسئول اجرای Migration است؟
• سرویس‌های حیاتی با چه ترتیبی بازیابی می‌شوند؟
• RTO مورد انتظار چقدر است؟

اگر پاسخ این سؤالات مشخص نباشد، سازمان هنوز برای قطع Provider آماده نیست.

وضعیت Encryption را بررسی کنید

برای ذخیره داده حساس، باید مشخص شود اطلاعات چگونه رمزنگاری می‌شوند.

حداقل سه بخش باید بررسی شوند:

• Encryption in Transit
• Encryption at Rest
• Encryption of Backups

در سرویس‌های حساس همچنین باید مشخص شود کلیدهای رمزنگاری در اختیار چه کسی هستند.

اگر Cloud Provider هم داده و هم تمام کلیدهای رمزنگاری را در اختیار داشته باشد، سطح کنترل سازمان کمتر از حالتی است که Customer Managed Key استفاده می‌شود.

SLA و تعهدات Provider را بررسی کنید

SLA یا Service Level Agreement مشخص می‌کند Provider چه سطحی از دسترس‌پذیری را تضمین می‌کند.

اما فقط عدد Availability را بررسی نکنید.

موارد زیر نیز اهمیت دارند:

• نحوه محاسبه Downtime
• شرایط دریافت Service Credit
• زمان پاسخ Support
• سطح Support در شرایط Critical
• تعهد Provider در برابر از دست رفتن داده
• سیاست مربوط به Incident
• نحوه اطلاع‌رسانی درباره Outage

همچنین باید مشخص شود SLA واقعاً با نیاز کسب‌وکار شما سازگار است یا خیر.

هزینه خروج داده را فراموش نکنید

انتقال داده به Cloud معمولاً ساده است، اما خارج کردن آن ممکن است هزینه داشته باشد.

هزینه Data Egress در برخی سرویس‌ها می‌تواند هنگام Migration به عدد قابل توجهی برسد.

قبل از انتقال حجم بالای ذخیره داده بررسی کنید:

• هزینه خروج هر گیگابایت چقدر است؟
• آیا بین Regionها هزینه انتقال وجود دارد؟
• آیا API Request هزینه دارد؟
• آیا Download Backup هزینه جداگانه دارد؟
• انتقال چند ترابایت داده چه هزینه‌ای ایجاد می‌کند؟

این هزینه باید از ابتدا در Exit Strategy لحاظ شود.

یک امتیاز ریسک برای Provider تعریف کنید

برای تصمیم‌گیری بهتر می‌توان هر Provider را بر اساس معیارهای مشخص امتیازدهی کرد.

برای مثال:

معیار	وضعیت
محل ذخیره داده مشخص است	بله / خیر
Backup مستقل دارد	بله / خیر
Export کامل داده ممکن است	بله / خیر
محدودیت کاربران ایرانی مشخص است	بله / خیر
Encryption مناسب دارد	بله / خیر
SLA مناسب ارائه می‌کند	بله / خیر
Migration Plan وجود دارد	بله / خیر
Backup خارج از Provider وجود دارد	بله / خیر
Vendor Lock-in پایین است	بله / خیر
Disaster Recovery تست شده است	بله / خیر

اگر پاسخ تعداد زیادی از این موارد «خیر» یا «نامشخص» باشد، استفاده از آن Provider برای سرویس‌های حیاتی ریسک بالاتری خواهد داشت.

چک‌لیست نهایی قبل از انتقال داده

پیش از انتقال یک سرویس مهم به Cloud خارجی، حداقل باید بتوانید به این سؤالات پاسخ مشخصی بدهید:

• داده‌های ما دقیقاً کجا هستند؟
• چه قوانینی بر آن‌ها اعمال می‌شوند؟
• Backup کجا نگهداری می‌شود؟
• آیا Backup خارج از Provider داریم؟
• چه کسانی به داده دسترسی دارند؟
• آیا تمام داده قابل Export است؟
• هزینه خروج داده چقدر است؟
• آیا Migration آزمایش شده است؟
• اگر حساب مسدود شود چه می‌کنیم؟
• اگر Provider کاملاً قطع شود چه می‌کنیم؟

اگر سازمان پاسخ روشنی برای این موارد داشته باشد، تصمیم درباره استفاده از ابر خارجی از یک انتخاب صرفاً فنی به یک تصمیم آگاهانه در مدیریت ریسک تبدیل می‌شود.

در نهایت، انتخاب Cloud Provider مناسب فقط به این بستگی ندارد که چه مقدار CPU، RAM یا فضای ذخیره‌سازی ارائه می‌کند. برای سرویس‌های سازمانی، مهم‌تر این است که ذخیره داده تحت چه شرایطی انجام می‌شود، چه میزان کنترل روی آن وجود دارد و در صورت بروز بحران تا چه اندازه می‌توان اطلاعات را مستقل از Provider بازیابی یا منتقل کرد.

چگونه ریسک استفاده از ابر خارجی را کاهش دهیم؟

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

هدف اصلی این است که سازمان به شکلی از Cloud استفاده کند که ذخیره داده و ادامه فعالیت کسب‌وکار به یک Provider واحد وابسته نباشد.

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

نگهداری Backup مستقل

اولین و مهم‌ترین اقدام، داشتن Backup مستقل از Cloud Provider اصلی است.

اگر سرور، Database و Backup همگی در یک Provider قرار داشته باشند، یک مشکل در سطح حساب یا سرویس‌دهنده می‌تواند دسترسی به همه آن‌ها را هم‌زمان مختل کند.

بهتر است حداقل یک نسخه از داده‌های حیاتی در زیرساخت دیگری نگهداری شود.

این زیرساخت می‌تواند شامل موارد زیر باشد:

• Cloud Provider دیگر
• Object Storage مستقل
• دیتاسنتر داخلی
• زیرساخت On-Premise
• سرویس Backup اختصاصی

برای مثال، اگر زیرساخت اصلی روی Cloud Provider A قرار دارد، می‌توان Backup روزانه Database و فایل‌های مهم را روی Provider B نگهداری کرد.

نکته مهم این است که Backup مستقل باید بدون نیاز به حساب Provider اصلی قابل دریافت و Restore باشد.

همچنین بهتر است حداقل یکی از نسخه‌های Backup در قالبی عمومی و قابل‌انتقال نگهداری شود تا فرآیند ذخیره داده به فرمت اختصاصی یک سرویس وابسته نباشد.

طراحی Multi-Cloud

یکی دیگر از روش‌های کاهش وابستگی، استفاده از معماری Multi-Cloud است.

در این مدل، سازمان از بیش از یک Cloud Provider استفاده می‌کند.

برای مثال:

• سرویس اصلی روی Provider A
• Backup روی Provider B
• DNS روی سرویس مستقل
• Object Storage روی زیرساخت دیگر

Multi-Cloud الزاماً به این معنا نیست که تمام زیرساخت باید هم‌زمان روی چند Cloud فعال باشد.

در بسیاری از سازمان‌ها، مدل ساده‌تری کافی است؛ به این شکل که سرویس اصلی روی یک Provider قرار دارد اما Backup، DNS یا زیرساخت Disaster Recovery به Provider دیگری منتقل شده است.

این کار باعث می‌شود یک Provider به Single Point of Failure تبدیل نشود.

برای طراحی Multi-Cloud باید تا حد امکان از فناوری‌های استاندارد استفاده شود.

برای مثال:

• Container
• Kubernetes
• PostgreSQL
• MySQL
• Terraform
• S3-Compatible Storage

استفاده از استانداردهای قابل‌انتقال می‌تواند انتقال ذخیره داده و سرویس‌ها بین Providerهای مختلف را ساده‌تر کند.

Encryption قبل از Upload

یکی از راه‌های افزایش کنترل روی اطلاعات، رمزنگاری داده قبل از ارسال آن به Cloud است.

در این مدل، داده پیش از Upload رمزنگاری می‌شود و نسخه رمزنگاری‌شده روی زیرساخت Provider قرار می‌گیرد.

این روش به‌خصوص برای اطلاعات حساس مناسب است، مانند:

• Backup
• اسناد داخلی
• اطلاعات مالی
• داده مشتریان
• آرشیوهای سازمانی

حتی اگر Provider قابلیت Encryption at Rest داشته باشد، رمزنگاری سمت مشتری می‌تواند یک لایه امنیتی اضافه ایجاد کند.

تفاوت مهم این دو مدل در محل انجام Encryption است.

در Encryption سمت Provider، سرویس‌دهنده معمولاً بخشی از فرآیند مدیریت رمزنگاری را کنترل می‌کند.

اما در Client-Side Encryption، داده قبل از رسیدن به زیرساخت Provider رمزنگاری شده است.

این روش می‌تواند سطح کنترل سازمان بر ذخیره داده را افزایش دهد.

البته استفاده از Client-Side Encryption نیازمند مدیریت صحیح کلیدها است. اگر کلید رمزنگاری از دست برود، ممکن است خود سازمان نیز دیگر قادر به بازیابی اطلاعات نباشد.

نگهداری کلیدهای رمزنگاری خارج از Provider

رمزنگاری زمانی ارزشمند است که مدیریت کلیدها نیز به‌درستی انجام شود.

اگر داده و کلید رمزگشایی هر دو در یک Cloud Provider نگهداری شوند، همچنان وابستگی زیادی به همان Provider وجود خواهد داشت.

برای داده‌های حساس می‌توان کلیدهای اصلی را در زیرساخت مستقل نگهداری کرد.

برای مثال:

• Hardware Security Module
• Key Management System مستقل
• Secret Management Platform
• زیرساخت داخلی سازمان

در برخی معماری‌ها نیز می‌توان از مدل‌هایی مانند Customer Managed Keys یا Bring Your Own Key استفاده کرد.

هدف این است که Provider میزبان داده، الزاماً کنترل کامل کلیدهای رمزگشایی را در اختیار نداشته باشد.

این موضوع به‌خصوص در معماری‌هایی که ذخیره داده حساس روی Cloud انجام می‌شود اهمیت زیادی دارد.

با این حال، سازمان باید برای Backup کلیدها نیز برنامه مشخص داشته باشد. از دست رفتن کلید می‌تواند عملاً معادل از دست رفتن داده باشد.

مستندسازی Migration Plan

بسیاری از شرکت‌ها می‌دانند که در صورت نیاز «می‌توانند» سرویس را منتقل کنند، اما فرآیند دقیق این انتقال مستند نشده است.

این موضوع در زمان بحران مشکل‌ساز می‌شود.

Migration Plan باید مشخص کند اگر سازمان مجبور به ترک Provider شود، چه اقداماتی باید انجام شود.

این برنامه بهتر است حداقل شامل موارد زیر باشد:

• فهرست سرویس‌های فعلی
• حجم داده‌ها
• محل Backup
• وابستگی بین سرویس‌ها
• ترتیب Migration
• Provider جایگزین
• روش Export داده
• روش Restore
• تغییر DNS
• انتقال Certificate
• انتقال Secretها
• مسئول هر مرحله

همچنین باید مشخص شود انتقال ذخیره داده چه مدت زمان نیاز دارد.

برای مثال، انتقال 100 گیگابایت داده با انتقال 20 ترابایت اطلاعات شرایط کاملاً متفاوتی دارد.

هزینه Data Egress نیز باید در Migration Plan محاسبه شود.

Migration Plan را فقط روی کاغذ نگه ندارید

یک برنامه مهاجرت تا زمانی که آزمایش نشده باشد، قابل اتکا نیست.

سازمان بهتر است به‌صورت دوره‌ای بررسی کند آیا واقعاً می‌تواند بخشی از سرویس را روی زیرساخت دیگری راه‌اندازی کند یا خیر.

برای مثال می‌توان آزمایش کرد:

• Export Database
• انتقال Object Storage
• Restore Backup
• ساخت VM جایگزین
• اجرای Application روی Provider دیگر
• تغییر DNS آزمایشی

این تست‌ها معمولاً نقاط ضعفی را آشکار می‌کنند که در مستندات دیده نمی‌شوند.

ممکن است مشخص شود یک API اختصاصی، یک Secret فراموش‌شده یا یک سرویس Managed باعث شده Migration بسیار سخت‌تر از چیزی باشد که تصور می‌شد.

تست دوره‌ای Disaster Recovery

داشتن Disaster Recovery Plan به‌تنهایی کافی نیست.

این برنامه باید به‌صورت دوره‌ای آزمایش شود.

در یک DR Test می‌توان سناریویی مانند این را شبیه‌سازی کرد:

Cloud Provider اصلی کاملاً از دسترس خارج شده است.

تیم باید بدون استفاده از سرویس اصلی تلاش کند سیستم را بازیابی کند.

در این آزمایش باید موارد زیر بررسی شوند:

• Backup قابل دریافت است؟
• Backup سالم است؟
• Database Restore می‌شود؟
• Application اجرا می‌شود؟
• Secretها در دسترس هستند؟
• DNS قابل تغییر است؟
• Certificateها موجود هستند؟
• زیرساخت جایگزین ظرفیت کافی دارد؟
• زمان بازیابی چقدر است؟

نتیجه این تست باید با RPO و RTO تعیین‌شده مقایسه شود.

اگر هدف RTO چهار ساعت بوده اما بازیابی واقعی 12 ساعت طول کشیده است، برنامه Disaster Recovery نیاز به اصلاح دارد.

وابستگی‌های حیاتی را از هم جدا کنید

یکی از روش‌های مؤثر کاهش ریسک این است که همه اجزای حیاتی زیرساخت تحت یک Provider یا یک حساب قرار نگیرند.

برای مثال ممکن است سازمان این ساختار را داشته باشد:

Compute: Provider A
Backup: Provider B
DNS: Provider C
Domain Registrar: Provider D
Secret Management: سرویس مستقل

در این شرایط، اگر Provider A با مشکل مواجه شود، هنوز امکان دسترسی به Domain، DNS، Backup و اطلاعات ضروری وجود دارد.

این تفکیک می‌تواند ریسک ناشی از قطع کامل یک سرویس‌دهنده را کاهش دهد.

داده‌های حیاتی را طبقه‌بندی کنید

همه اطلاعات سازمان ارزش و حساسیت یکسانی ندارند.

به همین دلیل لازم نیست برای تمام داده‌ها از گران‌ترین معماری Backup و Disaster Recovery استفاده شود.

بهتر است داده‌ها در چند سطح دسته‌بندی شوند.

برای مثال:

Critical Data

اطلاعاتی که از دست رفتن آن‌ها می‌تواند فعالیت کسب‌وکار را متوقف کند.

Sensitive Data

اطلاعات مشتریان، مالی یا محرمانه.

Operational Data

اطلاعاتی که برای اجرای روزمره سرویس لازم هستند.

Archive Data

اطلاعاتی که کمتر استفاده می‌شوند و معمولاً RTO طولانی‌تری دارند.

بر اساس این دسته‌بندی می‌توان سیاست ذخیره داده، Backup و Disaster Recovery متفاوتی برای هر گروه تعریف کرد.

یک معماری مقاوم، معماری بدون Cloud نیست

کاهش ریسک ابر خارجی به این معنا نیست که سازمان باید از Cloud صرف‌نظر کند.

Cloud همچنان می‌تواند مزایای مهمی مانند مقیاس‌پذیری، سرعت راه‌اندازی، تنوع سرویس و کاهش هزینه زیرساخت ایجاد کند.

مسئله اصلی نحوه وابستگی به Cloud است.

معماری مناسب باید به شکلی طراحی شود که اگر یک Provider از دسترس خارج شد، سازمان همچنان بتواند به داده‌های حیاتی خود دسترسی پیدا کند و سرویس را در محیط دیگری بازیابی کند.

در نهایت، مهم‌ترین اصل در کاهش ریسک ابر خارجی این است که کنترل ذخیره داده، Backup، کلیدهای رمزنگاری و مسیر مهاجرت فقط در اختیار یک Provider نباشد. هرچه سازمان گزینه‌های بیشتری برای بازیابی و جابه‌جایی داده داشته باشد، وابستگی و ریسک عملیاتی آن کمتر خواهد بود.

جمع‌بندی

استفاده از سرویس‌های ابری خارجی می‌تواند مزایای زیادی برای کسب‌وکارها داشته باشد، اما زمانی که موضوع ذخیره داده مطرح می‌شود، انتخاب Provider نباید فقط بر اساس قیمت، منابع یا امکانات فنی انجام شود.

شرکت‌ها باید بدانند داده‌هایشان دقیقاً در کدام کشور ذخیره می‌شود، Backup در کجا قرار دارد، چه قوانینی بر اطلاعات حاکم است و در صورت محدود شدن حساب یا قطع دسترسی چه گزینه‌هایی برای بازیابی و انتقال داده در اختیار دارند.

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

به همین دلیل، استفاده ایمن از ابر خارجی نیازمند مجموعه‌ای از اقدامات پیشگیرانه است؛ از جمله نگهداری Backup مستقل، کاهش Vendor Lock-in، رمزنگاری داده، مدیریت مستقل کلیدها، مستندسازی Migration Plan و تست دوره‌ای Disaster Recovery.

در نهایت، هدف این نیست که از Cloud خارجی استفاده نکنیم؛ بلکه باید معماری را به شکلی طراحی کنیم که کنترل واقعی ذخیره داده همچنان در اختیار سازمان باقی بماند. اگر فردا Provider اصلی از دسترس خارج شود، یک زیرساخت حرفه‌ای باید بتواند بدون وابستگی کامل به همان سرویس‌دهنده، داده‌های حیاتی را بازیابی و فعالیت کسب‌وکار را ادامه دهد.