پرسش واقعی پشت این انتخاب چیست؟
بحث استقرار داخلی در برابر ابری معمولاً با پرسش «کدام امنتر است؟» شروع میشود، و این پرسش نادرستی است. هیچکدام ذاتاً امنتر نیستند؛ هرکدام سطح حملهٔ متفاوتی دارند و مسئولیت امنیت را به جای متفاوتی منتقل میکنند.
پرسش درست دو بخش دارد. اول: کدام دسته از دادههای سازمان مشمول الزام قانونی یا سیاست داخلی برای عدم خروج از مرز سازماناند؟ دوم: آیا سازمان توان عملیاتی نگهداری یک سامانهٔ زنده را دارد — یعنی وصلهگذاری منظم، پایش، پشتیبانگیری آزمودهشده و پاسخ به رخداد در ساعات غیراداری؟
پاسخ به این دو پرسش تقریباً همیشه انتخاب را روشن میکند. آنچه تصمیم را سخت نشان میدهد، پرسیدن آنها بهصورت مبهم است: «دادههای ما حساس است» گزارهٔ عملیاتی نیست؛ «مصوبههای کمیتهٔ اعتباری نباید از شبکهٔ داخلی خارج شوند» هست.
طبقهبندی داده چطور تصمیم را ساده میکند؟
بیشتر سازمانها با یک برچسب واحد به همهٔ دادهها نگاه میکنند و بنابراین ناچارند سختگیرانهترین الزام را به همه چیز تعمیم دهند. اما در عمل، سه یا چهار طبقه کافی است: دادهای که خروجش ممنوع است، دادهای که خروجش مشروط است، و دادهای که هیچ محدودیتی ندارد.
این تفکیک معماریهای ترکیبی را ممکن میکند: پردازش و نگهداری طبقهٔ نخست درون سازمان و استفاده از سرویس ابری برای بقیه. هزینهٔ چنین معماریای بیشتر از یک انتخاب یکدست است، اما معمولاً کمتر از تعمیم سختگیرانهترین الزام به کل سازمان.
نکتهٔ مهم این است که طبقهبندی باید بر مبنای پیامد افشا انجام شود، نه بر مبنای واحد تولیدکننده. صورتجلسهٔ یک کمیتهٔ اعتباری و صورتجلسهٔ کمیتهٔ رفاه هر دو صورتجلسهاند و پیامد افشایشان یکی نیست.
هزینهٔ واقعی استقرار داخلی چقدر است؟
هزینهٔ سختافزار و پروانه، بخش قابل پیشبینی و معمولاً کوچکتر ماجراست. آنچه در برآوردها جا میماند، هزینهٔ عملیات است: نگهداری نسخه، وصلهٔ امنیتی، پایش ظرفیت، پشتیبانگیری و مهمتر از همه، آزمودن بازیابی. پشتیبانی که هرگز بازیابیاش آزموده نشده، پشتیبان نیست.
به این باید هزینهٔ در دسترس بودن را افزود. سامانهای که تیم فناوری سازمان تنها در ساعات اداری پشتیبانی میکند، عملاً یک سامانهٔ ساعات اداری است. اگر انتظار میرود در شب و تعطیلات هم کار کند، شیفت و آمادگی پاسخ به رخداد هزینهٔ ثابت جدیدی است.
و در نهایت، هزینهٔ عقبماندن از نسخهها. یک استقرار داخلی که هجده ماه بهروزرسانی نشود، هم قابلیتهای جدید را از دست میدهد و هم به مجموعهای از آسیبپذیریهای شناختهشده تبدیل میشود. تعهد بهروزرسانی باید در همان بودجهٔ اولیه دیده شود.
در چه شرایطی استقرار ابری پاسخ درستی نیست؟
نخست، وقتی الزام قانونی صریحی برای اقامت داده وجود دارد. در چنین حالتی بحث اقتصادی موضوعیت ندارد و تنها پرسش باقیمانده این است که استقرار داخلی چگونه به بهترین شکل انجام شود.
دوم، وقتی سازمان تعهد قراردادی به مشتریان خود داده که دادههایشان از زیرساخت مشخصی خارج نمیشود. این حالت در پیمانکاران بخش دولتی و برخی نهادهای مالی رایج است و نقض آن ریسک قراردادی است، نه فقط ریسک امنیتی.
سوم، وقتی اتصال شبکهای پایدار در محل استفاده وجود ندارد — پالایشگاه، سایت عملیاتی دورافتاده، یا مرکز درمانی با محدودیت شبکه. اینجا مسئله حاکمیت داده نیست، در دسترس بودن است، و پاسخ ممکن است استقرار داخلی یا معماری با قابلیت کار در حالت قطع باشد.
یک چارچوب تصمیمگیری عملی چه شکلی دارد؟
چهار پرسش، به همین ترتیب، پاسخ را میسازد. یک: آیا الزام قانونی یا قراردادی برای اقامت داده وجود دارد؟ اگر بله، بحث تمام است. دو: کدام طبقه از داده مشمول این الزام است و سهمش از کل چقدر است؟ اگر سهم کوچک است، معماری ترکیبی را بسنجید.
سه: آیا سازمان تیمی دارد که بتواند نگهداری، وصله و پاسخ به رخداد را در تعهد سطح خدمت مورد انتظار انجام دهد؟ اگر پاسخ منفی است، استقرار داخلی یک ریسک امنیتی است، نه یک کنترل امنیتی. چهار: هزینهٔ سهسالهٔ هر دو گزینه را با احتساب عملیات مقایسه کنید، نه هزینهٔ سال اول را.
داناوی هر دو مسیر را پشتیبانی میکند — نسخهٔ ابری و نسخهٔ سرور اختصاصی که در آن هیچ دادهای سازمان را ترک نمیکند — اما انتخاب میان آنها تصمیمی است که باید پیش از انتخاب هر سامانهای گرفته شود و بر پایهٔ همین چهار پرسش.
