بسم الله الرحمن الرحیم

اطمینان به کلود

آموزش کلودسیم  CloudSim

فصل بیستم

اطمینان و چگونگی  وجود اطمینان و ایجاد امنیت

 Athman Bouguettaya و همکارانشان [26]  سعی در ارائه راه‌هایی داشتند که بتواند امنیت را به‌وسیله وب‌سرویس ایجاد و اعتماد مشتری را جلب کنند

طبق نظر ایشان اگر وب‌سرویس‌هایی بسازیم که چند خاصیت داشته باشند ما می‌توانیم امنیت را برقرار کنیم

1- result accuracyیا دقت درنتیجه: یعنی بتوانیم پاسخ‌های دقیق و صحیحی از وب‌سرویس‌ها دریافت کنیم. انجام این کار بسیار مشکل است چراکه نمی‌دانیم استفاده‌کنندگان و ارائه‌دهندگان چطور می‌توانند بفهمند که دقیقاً چه چیزی را از یکدیگر می‌خواهد تا ما بتوانیم معنای پاسخ صحیح را به دست آوریم ولی درهرحال باید استانداردی بین کلود و کاربران برای پاسخ دقیق به یکدیگر ایجاد شود

2- در دسترس بودن: در محیط‌های ابری باید سرویس‌ها تضمین‌شده باشد اما از آنجایی که کلود محیطی دینامیک است این کار سخت اما شدنی است و می‌توانیم سیستم‌های مدیریتی به وجود آوریم تا در دسترس بودن وب‌سرویس‌ها را تضمین کنند

3- تخمین ، ارزیابی و ذخیره‌سازی: به ازاء هر اتفاقی که قرار است رخ دهد باید ابتدا تخمین و ارزیابی از کاری که مشتری می‌خواهد انجام دهد داشته باشیم و تا بتوانیم با توجه به وضعیت موجود خروجی مناسبی به او بدهیم سپس اقدام به انجام عمل کاربر کنیم. برای مثال در سیستم‌عامل داس تا زمانی که فضا برای ذخیره‌سازی بود عمل کپی انجام می‌شد و زمانی که فضا به اتمام می‌رسید کار متوقف می‌شد ولی در سیستم‌عامل‌های بعدی ابتدا چک می‌شود که آیا فضا برای ذخیره‌سازی وجود دارد؟ سپس اقدام به عمل کپی می‌شود و یا پیامی را به کاربر نشان می‌دهیم.

4- بازخوردهای قابل‌قبول: برای این‌که بتوانیم  قسمت امنیتی خوبی را به وب‌سرویس ارائه کنیم باید بازخوردهایی بدهند که فقط افراد خاص را در برنگیرند و همه مشتری‌ها را در نظر بگیرند. کما این‌که مشتری‌ها دیتا یا استفاده خاصی از کلود نداشته باشند. اگر همیشه به مشتری بازخوردی را ارائه کنیم که وی انتظار دارد، مشتری همیشه راضی خواهد بود و این باعث اعتمادسازی و فرهنگ‌سازی می‌شود.

5- سیستم ذخیره‌سازی و امنیت را پخش‌کنیم یعنی به ازاء کاربران مختلف ،سرورها مختلفی داشته باشیم و سروری با سرویس‌هایش امنیت فلان کاربر را تأمین کند

ایجاد امنیت با ابر هیبرید

  Martin Gilje Jaatun و همکارانشان [27] سعی کرده‌اند باواسط قرار دادن یک ابر ، امنیت و اعتماد را فراهم کنند.

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

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

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

در مرحله بعد از ابر هیبرید برای ابر واسط استفاده کرده است و تمام نرم‌افزارهای لازم برای کاربر را ابر هیبرید به‌عنوان واسط مدیریت کند. اما این‌که چطور ابر هیبرید باید این کار را انجام دهد هیچ اشاره‌ای نشده.

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

بسم الله الرحمن الرحیم

اطمینان به کلود

آموزش کلودسیم  CloudSim

فصل بیستم

اطمینان و چگونگی  وجود اطمینان و ایجاد امنیت

 Athman Bouguettaya و همکارانشان [26]  سعی در ارائه راه‌هایی داشتند که بتواند امنیت را به‌وسیله وب‌سرویس ایجاد و اعتماد مشتری را جلب کنند

طبق نظر ایشان اگر وب‌سرویس‌هایی بسازیم که چند خاصیت داشته باشند ما می‌توانیم امنیت را برقرار کنیم

1- result accuracyیا دقت درنتیجه: یعنی بتوانیم پاسخ‌های دقیق و صحیحی از وب‌سرویس‌ها دریافت کنیم. انجام این کار بسیار مشکل است چراکه نمی‌دانیم استفاده‌کنندگان و ارائه‌دهندگان چطور می‌توانند بفهمند که دقیقاً چه چیزی را از یکدیگر می‌خواهد تا ما بتوانیم معنای پاسخ صحیح را به دست آوریم ولی درهرحال باید استانداردی بین کلود و کاربران برای پاسخ دقیق به یکدیگر ایجاد شود

2- در دسترس بودن: در محیط‌های ابری باید سرویس‌ها تضمین‌شده باشد اما از آنجایی که کلود محیطی دینامیک است این کار سخت اما شدنی است و می‌توانیم سیستم‌های مدیریتی به وجود آوریم تا در دسترس بودن وب‌سرویس‌ها را تضمین کنند

3- تخمین ، ارزیابی و ذخیره‌سازی: به ازاء هر اتفاقی که قرار است رخ دهد باید ابتدا تخمین و ارزیابی از کاری که مشتری می‌خواهد انجام دهد داشته باشیم و تا بتوانیم با توجه به وضعیت موجود خروجی مناسبی به او بدهیم سپس اقدام به انجام عمل کاربر کنیم. برای مثال در سیستم‌عامل داس تا زمانی که فضا برای ذخیره‌سازی بود عمل کپی انجام می‌شد و زمانی که فضا به اتمام می‌رسید کار متوقف می‌شد ولی در سیستم‌عامل‌های بعدی ابتدا چک می‌شود که آیا فضا برای ذخیره‌سازی وجود دارد؟ سپس اقدام به عمل کپی می‌شود و یا پیامی را به کاربر نشان می‌دهیم.

4- بازخوردهای قابل‌قبول: برای این‌که بتوانیم  قسمت امنیتی خوبی را به وب‌سرویس ارائه کنیم باید بازخوردهایی بدهند که فقط افراد خاص را در برنگیرند و همه مشتری‌ها را در نظر بگیرند. کما این‌که مشتری‌ها دیتا یا استفاده خاصی از کلود نداشته باشند. اگر همیشه به مشتری بازخوردی را ارائه کنیم که وی انتظار دارد، مشتری همیشه راضی خواهد بود و این باعث اعتمادسازی و فرهنگ‌سازی می‌شود.

5- سیستم ذخیره‌سازی و امنیت را پخش‌کنیم یعنی به ازاء کاربران مختلف ،سرورها مختلفی داشته باشیم و سروری با سرویس‌هایش امنیت فلان کاربر را تأمین کند

ایجاد امنیت با ابر هیبرید

  Martin Gilje Jaatun و همکارانشان [27] سعی کرده‌اند باواسط قرار دادن یک ابر ، امنیت و اعتماد را فراهم کنند.

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

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

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

در مرحله بعد از ابر هیبرید برای ابر واسط استفاده کرده است و تمام نرم‌افزارهای لازم برای کاربر را ابر هیبرید به‌عنوان واسط مدیریت کند. اما این‌که چطور ابر هیبرید باید این کار را انجام دهد هیچ اشاره‌ای نشده.

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

ریسک‌ها در محیط ابری

جناب Victor C.M. Leung و[28] Min Chen به بررسی ریسک‌های موجود در محیط ابری پرداخته‌اند و سپس نتیجه‌گیری کرده‌اند که آیا محیط ابری قابل‌اعتماد هست یا خیر. انواع ریسک‌ها شامل:

1- شامل ریسک‌هایی که مربوط به ارگان‌های مختلف هستند 1- ریسک‌های سازمان‌های دولتی 2- صنایعی که کلود را ارائه می‌کنند 3- متخصصانی که ابر را ارائه می‌کنند 4- نوع بیزینس کلود خود ریسک است

2-  ریسک‌های عملیاتی: شامل 1- مدیریت سطح‌بندی سرویس‌ها 2- مبانی مالی 3- دیتاها و نرم‌افزارهای قابل‌حمل 4- کاربران سیستم باعث به وجود آمدن ریسک می‌شوند 5- قابلیت اطمینان به سرویس‌ها موجبات ریسک را به وجود میاورد

3-  ریسک‌هایی که با تکنیکال به وجود میاید: 1- کیفیت  داده و محافظت از آن 2- کارایی سیستم 3- جامعیت سیستم

4- ریسک حقوقی: 1- خصوصی‌سازی داده‌ها 2- حقوقی معنوی (فکر، ایده و ذهنیت) 3- قراردادی که شخص به‌واسطه آن از کلود استفاده می‌کند.

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

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

در مرحله بعد 295 نفر از متخصصان کیفیت بالای IT جهت بررسی کلود در اختیار گرفتند و نتیجه بررسی این گروه این شد که ساخت یک ایمیل ساده در کلود هزینه‌ای حداقل 0.2 درصد بیشتر از افراد عادی است آن‌هم برای افرادی با این سطح تخصص. پس وقتی برای این افراد متخصص این‌قدر هزینه در برداشته ، برای افراد عادی بیشتر خواهد بود، و در حدود سه هفته کار این افراد متخصص، به ازای هر نفر به‌طور متوسط 39 مشکل وجود داشته است، پس کلاً این سؤال مطرح می‌شود که چرا باید از کلود که هم هزینه بیشتری دارد هم مشکلات بیشتری استفاده کرد؟

در پایان پیشنهادشده که از کلود استفاده کنید اما به هیچ‌وجه به آن اعتماد نکنید و یا به‌صورت تخصصی از آن استفاده نکنید.

بررسی ریسک‌ها در کلود

Carmen Fernandez-Gago و همکارانشان  [29]معتقدند برآورد ریسک در کلود باید انجام پذیرد سپس به این نتیجه رسید که آیا می‌توان از کلود استفاده کرد یا خیر.

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

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

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

  Steven Furnellو همکارانشان [30] سعی کردند به‌وسیله peer to peer کردن سرویس‌های کلود، اعتماد و امنیت را دران ایجاد کنند.

روش کار به این صورت است که به هرکدام از کاربر یک ای دی تخصیص می‌دهیم و هر سرویس را بر روی دستگاه‌های مختلفی به اسم Node تفکیک می‌کنیم. پس ما یک Uid داریم که مربوط به کاربران است و یک Nids که مربوط به نودهای مختلف است. حالا هر سرویس را به یکی از این نودها نسبت می‌دهیم، حالا هرگاه کسی خواست از یکی از این سرویس‌ها استفاده کند، به ازاء هر Uid یک Nid را به سرور می‌دهیم که فقط به آن سرور اجازه می‌دهد این سرویس را به آن Uid ارائه دهد و این درواقع یک peer to peer مجازی است که یک سری محدودیت را به وجود میاورند و دسترسی به‌کلود را به سمتی می‌برند که هر کاربر بتواند درخواست بدهد و پاسخ بگیرد. سادگی و کارآمد بودن از ویژگی‌های این روش است و بعضی سرویس‌های آمازون از این طریق ارائه می‌شوند. ولی با محدودیتی که ایجاد کردیم درواقع کلود را به سیستم مدیریت سرویس تبدیل کردیم تا کلود به معنای عام که دست کاربر باز است تا کاربر بدون محدودیت از امکانات استفاده کند.

  پیشگیری از وقوع جرائم و ایجاد اعتماد به‌وسیله ایجاد قوانین در کلود

Serge Gutwirth و همکارانشان [31] سعی کرده‌اند مسئله امنیت و اعتماد را به‌وسیله پیشگیری از ارتکاب جرم و مسائل حقوقی بررسی کنند.

یکی از راه‌های امنیت این نیست که عملیات امنیتی انجام دهیم، راه بهتر این است که پیشگیری انجام دهیم

یکی از قوانینی که در اروپا به‌زودی شاهد آن خواهیم بود، از دو بعد جرم است 1- جرم تکنیکی 2- جرم انسانی

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

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