مکانیسم مدل مسئولیت مشترک در فضای ابری: چه کسی مسئول امنیت چه چیزی در IaaS، PaaS و SaaS است؟

هنگامی که یک شرکت عملیات خود را به فضای ابری منتقل می‌کند، اغلب در بروشورهای بازاریابی وعده یک آرمان‌شهر امن و بی‌نقص داده می‌شود که در آن ارائه‌دهنده بار سنگین را به دوش می‌کشد. اما واقعیت امنیت ابری بسیار ظریف‌تر است و بر اساس تقسیم کار سخت‌گیرانه‌ای به نام مدل مسئولیت مشترک عمل می‌کند. برای رهبران فناوری اطلاعات و توسعه‌دهندگان، فرض اینکه ارائه‌دهنده ابری همه چیز را ایمن می‌کند، یک تصور غلط خطرناک است که اغلب منجر به نقض‌های فاجعه‌بار داده می‌شود. ریسک‌ها بسیار زیادند: سطل‌های ذخیره‌سازی ابری با پیکربندی نادرست و حقوق دسترسی بیش از حد مجاز، به طور معمول توسط عوامل تهدید مورد سوءاستفاده قرار می‌گیرند و سازمان‌ها را مسئول عواقب آن می‌سازند.[9]

برای پیمایش در این چشم‌انداز، باید درک کرد که امنیت ابری یک مشارکت است. قانون اساسی، همانطور که توسط ارائه‌دهندگان بزرگی مانند آمازون وب سرویسز (AWS)، مایکروسافت آژور (Microsoft Azure) و گوگل کلود (Google Cloud) مشخص شده است، این است که ارائه‌دهنده مسئول «امنیت خودِ ابر» است، در حالی که مشتری مسئول «امنیت در داخل ابر» است. این بدان معناست که ارائه‌دهنده مراکز داده فیزیکی، سخت‌افزار و زیرساخت شبکه‌بندی بنیادی را ایمن می‌کند. با این حال، مشتری باید آنچه را که در آن محیط قرار می‌دهد، ایمن کند.[1][2][3]

خط دقیق تقسیم این مسئولیت‌ها بسته به نوع سرویس ابری مورد استفاده تغییر می‌کند: زیرساخت به عنوان سرویس (IaaS)، پلتفرم به عنوان سرویس (PaaS) یا نرم‌افزار به عنوان سرویس (SaaS). در مدل IaaS، مانند سرویس EC2 آمازون یا ماشین‌های مجازی آژور، مشتری حداکثر میزان کنترل و در نتیجه حداکثر میزان مسئولیت امنیتی را حفظ می‌کند. ارائه‌دهنده امنیت سرورهای فیزیکی و هایپروایزرها را تضمین می‌کند، اما مشتری باید سیستم عامل مهمان (guest OS) را وصله کند، فایروال‌های مجازی را پیکربندی نماید و برنامه‌هایی را که در بالای آن اجرا می‌شوند، مدیریت کند.[1][2]

با حرکت به سمت PaaS، ارائه‌دهنده بار عملیاتی بیشتری را بر عهده می‌گیرد. سرویس‌هایی مانند گوگل اپ انجین (Google App Engine) یا پایگاه داده Azure SQL، سیستم عامل و زیرساخت زیرین را انتزاعی می‌کنند. در اینجا، ارائه‌دهنده سیستم عامل را وصله می‌کند و موتور پایگاه داده را نگهداری می‌نماید. با این حال، مشتری همچنان کاملاً مسئول امنیت کد برنامه خود، پیکربندی ویژگی‌های امنیتی پلتفرم و مهم‌تر از همه، خودِ داده‌ها است. مواد بازاریابی اغلب از این نکته چشم‌پوشی می‌کنند و این تصور را ایجاد می‌کنند که PaaS یک راه‌حل «تنظیم کن و فراموش کن» است، اما آسیب‌پذیری‌های سطح برنامه همچنان مشکل مشتری باقی می‌مانند.[2][3]

در بالاترین سطح، نرم‌افزار به عنوان سرویس (SaaS) قرار دارد که شامل برنامه‌های سازمانی رایجی مانند مایکروسافت ۳۶۵، Salesforce یا گوگل وُرک‌اسپیس می‌شود. در این مدل، ارائه‌دهنده تقریباً کل پشته فناوری را مدیریت می‌کند: زیرساخت مرکز داده فیزیکی، سیستم عامل زیرین، خودِ کد برنامه و کنترل‌های شبکه. این مدل عمداً به گونه‌ای طراحی شده که کمترین دخالت عملیاتی را برای مشتری داشته باشد و به سازمان‌ها اجازه می‌دهد بدون هیچ سربار عملیاتی از نرم‌افزار استفاده کنند. با این حال، حتی در یک محیط SaaS که کاملاً مدیریت می‌شود، مشتری هرگز به طور کامل از تمام مسئولیت‌های امنیتی مبرا نیست؛ واقعیتی که اغلب سازمان‌ها را غافلگیر می‌کند.[2][3]

در هر سه مدل استقرار – IaaS، PaaS و SaaS – حوزه‌های امنیتی خاص و غیرقابل مذاکره‌ای وجود دارند که تحت هیچ شرایطی به ارائه‌دهنده ابری منتقل نمی‌شوند. حیاتی‌ترین این تعهدات دائمی مشتری، حاکمیت داده و مدیریت هویت و دسترسی (IAM) است. طبق گفته اتحاد امنیت ابری (CSA) و آژانس امنیت ملی (NSA)، مشتری همیشه مسئول اصلی طبقه‌بندی داده‌های خود، رمزگذاری مناسب آن‌ها در حالت سکون و در حال انتقال، و تعیین دقیق اینکه چه کسی یا چه چیزی اجازه دسترسی به آن‌ها را دارد، است.[5][6]

مدیریت هویت و دسترسی عملاً به مرز امنیتی جدید در رایانش ابری مدرن تبدیل شده است. در حالی که ارائه‌دهندگان ابری ابزارهای IAM بسیار قوی و دقیق ارائه می‌دهند، پیکربندی صحیح آن‌ها برای اعمال اصل کمترین امتیاز (least privilege) کاملاً بر عهده مشتری است. اگر یک مدیر سازمانی به طور تصادفی دسترسی خواندن عمومی به یک سطل S3 آمازون حاوی سوابق حساس مشتری بدهد، اقدامات امنیتی فیزیکی قدرتمند AWS کاملاً بی‌ربط خواهند بود؛ داده‌ها صرفاً به دلیل پیکربندی نادرست مشتری افشا شده‌اند. NSA به صراحت هشدار می‌دهد که این نوع سیاست‌های IAM با پیکربندی نادرست، به طور مداوم جزو آسیب‌پذیری‌های ابری هستند که بیشتر توسط عوامل تهدید پیشرفته مورد سوءاستفاده قرار می‌گیرند.[1][3][6]

مؤسسه ملی استانداردها و فناوری (NIST) راهنمایی‌های گسترده و بنیادی در مورد کنترل دسترسی در سیستم‌های ابری ارائه می‌دهد و بر ضرورت مطلق معماری کمترین امتیاز و نظارت مستمر تأکید می‌کند. چارچوب NIST یک تمایز حیاتی را برجسته می‌کند: در حالی که ارائه‌دهنده ابری مکانیسم‌های فنی و APIها را برای کنترل دسترسی فراهم می‌کند، مشتری باید سیاست‌های تجاری واقعی را تعریف کند. این امر مستلزم درک عمیق و مداوم از نقش‌های داخلی سازمان و حداقل دسترسی خاص مورد نیاز برای عملکرد هر کاربر انسانی و حساب سرویس خودکار است.[4]

امنیت نقاط پایانی (Endpoint security) یکی دیگر از مسئولیت‌های ثابت و غیرقابل انتقال مشتری در کل طیف ابری است. چه یک کارمند در حال دسترسی به یک ماشین مجازی IaaS بسیار سفارشی شده باشد یا یک برنامه استاندارد SaaS، دستگاه‌های فیزیکی مورد استفاده – لپ‌تاپ‌های شرکتی، تلفن‌های هوشمند شخصی یا تبلت‌ها – باید به شدت توسط سازمان مشتری ایمن شوند. یک نقطه پایانی به خطر افتاده می‌تواند به راحتی توسط یک مهاجم برای دور زدن کنترل‌های امنیتی پیچیده ابری، به ویژه در محیط‌هایی که احراز هویت چند عاملی (MFA) به طور سخت‌گیرانه در تمام نقاط دسترسی اعمال نمی‌شود، مورد استفاده قرار گیرد.[2][7]

پیچیدگی ذاتی مدل مسئولیت مشترک در محیط‌های چند ابری (multi-cloud) مدرن بیشتر تشدید می‌شود. امروزه، سازمان‌ها به ندرت به یک ارائه‌دهنده واحد متکی هستند و اغلب به صورت استراتژیک AWS را برای قدرت محاسباتی خام، Azure را برای برنامه‌های هویت سازمانی و Google Cloud را برای تجزیه و تحلیل داده‌های پیشرفته ترکیب می‌کنند. هر ارائه‌دهنده ظرافت‌ها، تنظیمات پیش‌فرض و اصطلاحات خاص خود را برای مسئولیت مشترک دارد، که تیم‌های امنیتی سازمانی را ملزم می‌کند تا به طور همزمان بر چندین چارچوب متمایز مسلط شوند. شرکت Wiz، یک شرکت برجسته امنیت ابری، اشاره می‌کند که این تکه‌ته‌شدگی اغلب منجر به شکاف‌های خطرناک در دید و وضعیت‌های امنیتی ناسازگار در محیط‌های ابری مختلف می‌شود.[8]

برای کاهش مؤثر این ریسک‌های فزاینده، سازمان‌ها باید رویکردی بسیار فعال و خودکار را در قبال امنیت ابری اتخاذ کنند. این تحول با درک واضح و مستند از ماتریس مسئولیت مشترک خاص برای هر سرویس ابری در حال استفاده آغاز می‌شود. تیم‌های امنیتی باید به سرعت از دفاع‌های سنتی مبتنی بر محیط شبکه فراتر رفته و ابزارهای امنیتی بومی ابری، مانند راه‌حل‌های مدیریت وضعیت امنیت ابری (CSPM)، را به طور کامل بپذیرند. این ابزارها به طور مداوم محیط‌های پیچیده را برای پیکربندی‌های نادرست خطرناک و نقض‌های انطباق در زمان واقعی نظارت می‌کنند.[7][8]

علاوه بر این، مفهوم در حال تکامل «سرنوشت مشترک» (shared fate)، که اخیراً توسط گوگل کلود معرفی و ترویج شده است، تلاش می‌کند مدل سنتی مسئولیت مشترک را مدرن‌سازی کند. سرنوشت مشترک به این معناست که ارائه‌دهنده ابری نقش فعال‌تر و سرمایه‌گذاری‌شده‌تری در کمک به مشتریان برای ایمن‌سازی محیط‌هایشان ایفا می‌کند، و راهنمایی‌های تجویزی برای استقرار، پیکربندی‌های پیش‌فرض امن و حتی مشارکت‌های تخصصی بیمه سایبری ارائه می‌دهد. در حالی که این امر به طور گسترده به عنوان یک گام مثبت رو به جلو تلقی می‌شود، متخصصان امنیتی شکاک سریعاً متذکر می‌شوند که سرنوشت مشترک از نظر قانونی مسئولیت را منتقل نمی‌کند؛ مشتری در نهایت همچنان مسئول هرگونه نقض داده ناشی از آن است.[3]

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