نصب روی سرور خودتان یا ابری: داده‌های پروژه کجا بماند

معمولاً این سؤال را کسی می‌پرسد که مسئول امنیت است، نه تیم نرم‌افزار: «داده‌های پروژه دقیقاً کجا نگه‌داری می‌شود؟» و تیمی که سال‌ها با یک ابزار ابری کار کرده، تازه آن روز متوجه می‌شود جوابش را نمی‌داند. ابزار مدیریت پروژه را معمولاً کسی انتخاب کرده که می‌خواست کار تیم مرتب شود، نه کسی که به محل داده فکر می‌کرد.

ولی روی کارت‌های یک تیم نرم‌افزاری چیزهایی هست که بیشتر از «فهرست کارها» است: نام مشتری‌ها، اسکرین‌شات صفحه‌هایی با دادهٔ واقعی، آدرس سرورها، و گاهی، متأسفانه، رمز عبور. این مقاله کمک می‌کند تصمیم بگیرید این اطلاعات کجا بماند: روی سرویس ابری خارجی، روی سرویسی که در داخل ایران میزبانی می‌شود، یا روی سرور خودتان.

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

سه گزینه، نه دو

بحث معمولاً به «ابری یا روی سرور خودمان» خلاصه می‌شود، ولی برای تیم ایرانی سه گزینهٔ واقعی وجود دارد:

• سرویس ابری خارجی. نرم‌افزار به‌عنوان سرویس (SaaS) که سرورهایش خارج از ایران است. شما فقط کاربرید؛ نگه‌داری، به‌روزرسانی و نسخهٔ پشتیبان با فروشنده است.
• سرویس ابری با میزبانی داخلی. همان مدل SaaS، ولی سرورها در ایران‌اند و فروشنده ایرانی است.
• نصب روی سرور خودتان (On-premises). نرم‌افزار روی سروری نصب می‌شود که در شبکهٔ شما و زیر کنترل شماست. داده از شبکه بیرون نمی‌رود، ولی همهٔ مسئولیت‌های فنی هم با شماست.

تعریف مرجع این مدل‌ها را مؤسسهٔ ملی استاندارد و فناوری آمریکا (NIST) در سند کوتاهی دربارهٔ رایانش ابری آورده است؛ اگر لازم است با واحد امنیت یا حقوقی سازمان دربارهٔ این گزینه‌ها با زبان مشترک حرف بزنید، آن سند نقطهٔ شروع خوبی است.

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

پیش از مقایسهٔ گزینه‌ها، بدانید از چه چیزی محافظت می‌کنید. بیست کارت تصادفی از بردهای فعال باز کنید و بشمارید چند تا از این‌ها را دارند:

• نام یا اطلاعات تماس مشتری‌ها
• اسکرین‌شات یا فایل با دادهٔ واقعی کاربران
• آدرس سرور، نام دیتابیس یا ساختار شبکه
• رمز عبور، توکن یا کلید (که نباید باشد، ولی اغلب هست)
• جزئیات قرارداد، قیمت یا برنامهٔ تجاری
• گزارش آسیب‌پذیری‌های امنیتی هنوز رفع‌نشده

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

مقایسهٔ سه گزینه

سرویس ابری خارجی: راحت، با دو سؤال جدی

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

اگر با این گزینه می‌مانید، دست‌کم منظم از داده‌هایتان خروجی بگیرید و بدانید آن خروجی دقیقاً چه چیزی را دارد و چه چیزی را ندارد. مقایسهٔ کامل‌تر ابزارها را در ترلو، جیرا یا ابزار ایرانی؟ نوشته‌ام.

ابری داخلی: پرسش‌هایی که باید از فروشنده بپرسید

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

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

سؤال آخر شاید فنی به نظر برسد، ولی مهم‌ترین است. اگر کنترل دسترسی فقط در رابط کاربری باشد، هر کسی که بداند درخواست را چطور مستقیم بفرستد، چیزهایی را می‌بیند که نباید ببیند.

روی سرور خودتان: چه چیزی واقعاً به عهدهٔ شماست

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

• نسخهٔ پشتیبان. روزانه، روی دیسک یا سروری جدا از سرور اصلی، و با آزمون بازیابی دوره‌ای. نسخهٔ پشتیبانی که هرگز بازیابی نشده، فقط یک امید است. راهنمای برنامه‌ریزی برای پیشامد NIST برای همین بخش مرجع خوبی است.
• به‌روزرسانی. هم خود نرم‌افزار و هم سیستم‌عامل و دیتابیس زیر آن. سروری که سال‌ها به‌روزرسانی نشده، از سرویس ابری خارجی امن‌تر نیست.
• دسترسی از بیرون. اگر دورکار دارید، باید راه امنی برای دسترسی‌شان بسازید، مثل VPN سازمانی؛ باز کردن مستقیم سرور به اینترنت چیزی است که باید آگاهانه و با محافظت تصمیم بگیرید.
• گواهی TLS و پایش. اینکه سرور بالا باشد، دیسکش پر نشود و کسی بفهمد اگر از کار افتاد.
• سرویس‌های بیرونی. هر قابلیتی که به سرویس بیرون از شبکه وابسته است، مثل ارسال پیامک یا ایمیل، را جدا بسنجید و بدانید چه چیزی از آن راه بیرون می‌رود.

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

چطور تصمیم بگیرید

این سؤال‌ها را به ترتیب جواب دهید؛ معمولاً تا سؤال سوم تصمیم روشن می‌شود:

1. آیا قرارداد یا کارفرما محل داده را تعیین کرده؟ اگر بله، گزینه‌ها همان‌هایی است که قرارداد اجازه می‌دهد.
2. آیا کسی در سازمان هست که نگه‌داری سرور، نسخهٔ پشتیبان و به‌روزرسانی را واقعاً بر عهده بگیرد؟ اگر نه، نصب روی سرور خودتان را کنار بگذارید یا اول این نیرو را پیدا کنید.
3. آیا تیم به اینترنت بین‌الملل وابستگی‌ای دارد که بخواهید کمش کنید؟ اگر بله، یکی از دو گزینهٔ داخلی.
4. داده‌ها چقدر حساس‌اند؟ نتیجهٔ تمرین بیست کارت را اینجا بگذارید.
5. اگر روزی بخواهید ابزار را عوض کنید، داده‌ها چطور بیرون می‌آیند؟ این سؤال در هر سه گزینه لازم است. اگر از ابزار دیگری می‌آیید، راهنمای مهاجرت از ترلو نشان می‌دهد این کار در عمل چه شکلی دارد.

بردماگ هر دو مدل داخلی را دارد: میزبانی روی سرورهای ما در ایران، یا نصب روی سرور خود مشتری (Windows Server با IIS و SQL Server) که در آن هیچ دادهٔ پروژه‌ای از شبکهٔ مشتری بیرون نمی‌رود. در هر دو حالت، کسی که عضو یک برد نیست، آن برد و کارت‌ها، کامنت‌ها و پیوست‌هایش را از سرور دریافت نمی‌کند؛ این کنترل در سرور انجام می‌شود، نه فقط با پنهان کردن در رابط کاربری.

چک‌لیست، هر گزینه‌ای که انتخاب کردید

1. کارت‌هایی را که رمز عبور یا توکن دارند پیدا کنید، پاکشان کنید و آن رمزها را عوض کنید.
2. بدانید نسخهٔ پشتیبان کجاست، هر چند وقت گرفته می‌شود و آخرین بار کی بازیابی آزمایش شده.
3. فهرست کسانی که به برد دسترسی دارند را مرور کنید و کسانی را که دیگر در پروژه نیستند حذف کنید.
4. یک بار خروجی کامل داده‌ها را امتحان کنید تا بدانید راه خروج واقعاً کار می‌کند.
5. جواب سؤال «داده‌های پروژه کجاست؟» را در یک پاراگراف بنویسید، تا دفعهٔ بعد که واحد امنیت پرسید، آماده باشد.

جمع‌بندی

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

منابع و مطالعهٔ بیشتر

• NIST SP 800-145: The NIST Definition of Cloud Computing — تعریف مرجع مدل‌های سرویس و استقرار ابری، برای گفت‌وگوی دقیق با واحد امنیت.
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems — راهنمای برنامه‌ریزی نسخهٔ پشتیبان و بازیابی، برای وقتی که مسئولیتش با خودتان است.
• On-premises software — Wikipedia — مفهوم نرم‌افزار نصب‌شده در محل و مقایسه‌اش با مدل ابری.
• Data sovereignty — Wikipedia — اینکه چرا محل فیزیکی داده آن را تابع قوانین همان کشور می‌کند.