ابرها در خطرند!

سرويس‌دهندگان كلاود ديوار دفاعي قوي‌تري از يك مركز داده سازماني رده متوسط دارند. البته بايد هم چنين باشد، زيرا كوچك‌ترين خللي مي‌تواند مشتريان بسيار زيادي را تحت تأثير قرار دهد.

سرويس‌دهندگان كلاود ديوار دفاعي قوي‌تري از يك مركز داده سازماني رده متوسط دارند. البته بايد هم چنين باشد، زيرا كوچك‌ترين خللي مي‌تواند مشتريان بسيار زيادي را تحت تأثير قرار دهد. در اين ميان، 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 كليدهاي خصوصي نهفته را بيرون بكشد، كليدهايي كه مورد استفاده ماشين‌هاي مجازي ديگر روي همان سرور هستند. در هر حال، تا كنون هيچ رخنه‌اي منسوب به حمله‌هاي مبتني بر هايپروايزر گزارش نشده است.
 همين امر نيز باعث شده است برخي ادعا كنند كه ترس از چنين خطرهايي اغراق‌شده به شمار مي‌آيد.