سرویس‌دهندگان کلاود دیوار دفاعی قوی‌تری از یک مرکز داده سازمانی رده متوسط دارند. البته باید هم چنین باشد، زیرا کوچک‌ترین خللی می‌تواند مشتریان بسیار زیادی را تحت تأثیر قرار دهد. در این میان، Cloud Security Alliance، نُه تهدید مهم در این حوزه را بررسی کرده ‌است که در ادامه می‌خوانید.

در گذشته‌ای نه چندان دور، سپردن داده‌های حیاتی شرکت به یک سرویس عمومی کلاود، برای بیش‌تر مدیران آی‌تی یک تصور دیوانه‌وار بود.«داده‌های من؟ آن بیرون، روی یک پلتفرم مشترک در مرکز داده‌ای که هرگز ندیده‌ام؟ این بیش‌تر شبیه شوخی است!» اما گرایش‌ها تغییر کرده ‌است. دسترس‌پذیری و امنیت سرویس‌دهندگان کلاود افزایش مداومی داشته است. این افزایش تا به آن‌جا رسیده است که احتمال وقوع اختلال یا حمله خرابکارانه موفق در مراکز داده معمولی بسیار بیش‌تر از این احتمال در دژ سترگ سرویس‌دهندگان عظیم کلاود به‌نظر می‌رسد.

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

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

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

نُه اصل بدنامِ اتحاد امنیت کلاود
اتحاد امنیت کلاود Cloud Security Alliance) در سال 2008 و با هدف ارتقای سطح امنیت کلاود شکل گرفت. فهرست اعضای آن شامل گروه متنوعی از شرکت‌های شاخص فناوری می‌شود؛ از فروشندگان سنتی نرم‌افزار همچون مایکروسافت و اوراکل گرفته تا سرویس‌دهندگان کلاود، مانند آمازون و گوگل. این بنیاد در سال 2013 سندی منتشر کرد که آن را «نُهِ بدنام» نامید این سند! شامل9 تهدید اصلی در محاسبات ابری می‌شود و بر اساس نظرسنجی از متخصصان صنعت نوشته شده است. در ادامه تهدیدهای مذکور را مطالعه خواهید کرد که تفسیر نگارنده نیز در هر مورد آمده است.

رخنه در داده‌ها
طبیعی است که امنیت داده در این فهرست مقام نخست را دارد.  زیرا ترس از افشای داده‌ها همواره نخستین عامل بازدارنده رواج کلاود بوده است.  در یک سطح، راه‌حل این مشکل آسان است: آرایه کاملی از گزینه‌های رمزنگاری قدرتمند. مقاله راجر گرایمز (Roger Grimes)، با نام «Practical encryption solutions» این گزینه‌ها را مرور کرده است. حبس کردن داده‌ها در صندوقچه رمزنگاری فقط بخشی از ماجرا است. کلیدهای رمزنگاری ممکن است در دستان نابابی بیفتد. باید تمهیدات مناسبی برای کنترل دسترسی و مجوزدهی اندیشید تا اطمینان حاصل شود که فقط افراد مجاز به داده‌ها دسترسی دارند. علاوه بر این، باید روش مناسبی برای نظارت بر داده به کار گرفته شود تا چرخه‌ای که طی می‌کند به‌خوبی مدیریت شود و این‌که تحت چه شرایطی داده‌ها می‌توانند در یک کلاود مشترک ذخیره شوند.

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

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

در یکی از پژوهش‌های شرکت سیمانتک که در سال 2013 انجام شد، از 3200 شرکت مشارکت‌کننده در نظرسنجی، 43 درصد اعلام کردند داده خود را در کلاود از دست داده‌اند و مجبور به بازیابی از نسخه پشتیبان شده‌اند. داده‌ها در کلاود نیز باید مانند داده‌ها روی هر سیستم دیگری محافظت شوند.

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

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

رابط‌های ناامن
رابط‌های کاربری یا رابط‌های برنامه کاربردی (API) کلاود، امکان یکپارچه‌سازی با راهکارهای SSO (سرنام Single Sign-On) را فراهم می‌کنند، همچنین یکپارچه‌سازی داده یا فرآیند، با دیگر سرویس‌های کلاود نیز وجود دارد. اما رابط‌های مذکور هدف‌هایی بالقوه برای حمله نیز هستند. سرویس‌دهندگان برای تأمین امنیت API، کلیدهای API یا توکن‌هایی به کاربران می‌دهند که برای ایجاد ارتباط باید تأیید اعتبار شوند. اگر یک API ضعف امنیتی داشته باشد، یک مهاجم می‌تواند با حمله DoS سرویس کلاود را غیر قابل استفاده کند. با وجود این‌که API دسترسی به همه توابع کلاود را فراهم می‌کند، اگر در خطر قرار گیرد، ممکن است حتی مهاجم را قادر سازد داده‌های حساس را برباید.

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

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

سوءاستفاده از سرویس
سرویس‌دهندگانی همچون آمازون (Web Services)خدماتی ارائه می‌دهند که تا پیش از این وجود نداشت: توانایی به‌کارگیری قدرت محاسباتی کلان به صورت بی‌درنگ برای هر حجم کاری قابل تصوری، پرداخت فقط برای منابع کلاود مورد نیاز و سپس بستن حساب سرویس کلاود. چنین امکانی مثلاً برای محاسبات ایده‌آل است. اما این امکان، فرصتی نیز برای تبه‌کاران مجازی در جهت انجام کارهای سنگین دیگر فراهم می‌کند: شکستن رمزنگاری. علاوه بر این، سرویس‌های کلاود ممکن است آشیانه بات‌نت‌ها، حمله‌های DDoS و حمله‌های تبه‌کارانه دیگری شود که به قدرت کلان احتیاج دارند.

تلاش ناکارآمد
کلاود به اعتماد میان سرویس‌دهنده و مشتری نیاز دارد. نام‌های بزرگ صنعت کلاود به لطف کاهش مستمر خطاها و فجایع، موفق به جذب اعتماد عمومی شده‌اند؛ اگرچه رسوایی NSA بسیاری از مشتری‌ها (به‌ویژه اروپایی‌ها) را دچار تردید کرد، با پدیدار شدن سرویس‌دهندگان کوچک‌تر و کم‌تر شناخته‌شده، ناآگاهی عمومی، نیاز به اعتماد را به امری حیاتی تبدیل کرده است؛ بسیاری از مشتریان سازمانی در خرج چنین اعتمادی شک دارند. مسئله مهم دیگر، مانایی کسب‌وکار سرویس‌دهنده است: یکی از پژوهش‌های اخیر گارتنر پیش‌بینی می‌کند که در میان صد سرویس‌دهنده برتر، یکی از هر چهار سرویس‌دهنده IaaS تا پایان سال 2015 دیگر وجود نخواهند داشت؛ عمدتاً هم به دلیل این‌که شرکتی بزرگ‌تر آن‌ها را خریداری می‌کند.
یکی از بزرگ‌ترین عوامل بازدارنده در استفاده از محاسبات ابری، ناتوانی مشتری‌ها در زمینه نظارت مستمر بر زیرساخت‌های امنیتی و آمادگی سرویس‌دهنده است. البته معیارها و استانداردهایی وجود دارد؛ معیارهایی از قبیل Security Trust & Assurance Registry (از اتحاد امنیت کلاود)، Trust & Assurance Registry ،Cloud Computing Security Reference Architectur (از بنیاد ملی استانداردها و فناوری)، SSAE 16 (از بنیاد CPA امریکا) یا استاندارد 27001 (از ISO/IES). هیچ مشتری‌ای نمی‌تواند پیش از خرید از سرویس‌دهی کامل 24.7 سرویس‌دهنده اطمینان یابد، اما گاهی به مشتریان امتیاز بررسی دقیق و اجازه بازرسی فیزیکی از تجهیزات داده می‌شود.  مسلم است که تصریح امکان استرداد و غرامت در قرارداد برای مشتری سودمند است. اما از طرف دیگر، هیچ قراردادی نمی‌تواند دزدی یا از بین رفتن داده‌های حیاتی را کاملاً جبران کند.

آسیب‌پذیری فناوری اشتراکی
کلاود بر اساس این ایده شکل گرفته است که چندین مشتری، زیرساخت یکسانی را به اشتراک بگذارند؛ مفهومی که با نام «multitenancy» شناخته می‌شود. چنان‌که گزارش «نُهِ بدنام» قید می‌کند: «اجزای شالوده‌ای که این زیرساخت را شکل می‌دهند (پردازنده مرکزی، پردازنده گرافیکی و ...)، به شکلی طراحی نشده‌اند که دارایی‌های اختصاصی و ایزوله‌شده را در یک معماری چندگانه فراهم کنند.» یک سرویس‌دهنده باید امکانات نظارتی و کنترلی را طوری به کار گیرد که از چنین ضعف‌های بالقوه‌ای سوءاستفاده نشود و نیز هکرهایی را که با هدف آسیب‌رساندن به دیگر مشتری‌ها حساب باز می‌کنند، ناکام بگذارد. یکی از موارد مهم در حوزه ضعف‌های بالقوه امنیتی، در سطح هایپروایزر قرار دارد، زیرا چنین ضعف‌هایی از نظر تئوری می‌توانند یک مهاجم را قادر سازند چندین ماشین مجازی را در میان چندین حساب در خطر قرار دهد. محققان در سال 2012، تروجانCrisis را کشف کردند که نسخه تحت ویندوز آن توانایی آلوده کردن ماشین‌های مجازی VMware را داشت. کمی پس از آن، در همان سال، یک مقاله از دانشگاه کارولینای شمالی توضیح داد که چگونه یک ماشین مجازی می‌تواند با استفاده از اطلاعات side-channel timing کلیدهای خصوصی نهفته را بیرون بکشد، کلیدهایی که مورد استفاده ماشین‌های مجازی دیگر روی همان سرور هستند. در هر حال، تا کنون هیچ رخنه‌ای منسوب به حمله‌های مبتنی بر هایپروایزر گزارش نشده است.

 همین امر نیز باعث شده است برخی ادعا کنند که ترس از چنین خطرهایی اغراق‌شده به شمار می‌آید.