رایانش ابری و مسئله امنیت- قسمت دوم

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

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

 

Cloud-Computing

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

وقتی که درباره نقش مجازی سازی در پردازش ابری فکر می کنید، باید مسائل مهم امنیتی زیادی را در نظر بگیرید. شاید مهم ترین مسئله ای که در محیط حقیقی دیده نمی شود، زمانی اتفاق میافتد که Hypervisor خودش در معرض خطر باشد. Hypervisor به تمام سیستم عامل های اجرا شده در زیرساخت ابر، دسترسی دارد. زمانیکه درباره گسترش ابر فکر می کنید (که می تواند راه اندازی صدها یا دهها هزار ماشین مجازی اجرا باشد.) در صورتیکه شبکه ایزوله نشده باشد، به خطر افتادن Hypervisor می تواند اثرات مخرب و گسترده ای را به وجود آورد.

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

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

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

دو نکته مهمی که باید توجه کرد، راجع به چگونگی هماهنگی سیستم عامل ها برای تخصیص مجدد منابع است:

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

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

برای مثال زمانی که کدی از کاربر به صورت Clear Text گرفته می شود، بافرهای حافظه استفاده شده برای ضبط و انتقال آن پسورد، به منظور احراز هویت باید به عنوان قسمتی از پروسه احراز هویت پاک شوند. اگر شما این کار را انجام ندهید ریسک بزرگی کرده اید. شما می توانید این عملیات را به عنوان "Atomic Operation" انجام دهید، یعنی اگر عملیات Fail شد به حالت قبلی برگردد.

موضوع دیگر اینکه چه حملاتی در شبکه بین سیستم عامل هایی که روی سرور یکسان یا کلاستر هستند وجود دارد؟ آیا می توانید آنها را شناسایی کنید؟ این مشکل پابرجاست مگر اینکه بتوانید ترافیکی که از هر یک از ماشین ها عبور می کند را ببینید، شما نمی توانید مطمئن باشید که هیچ ترافیکی بین ماشین ها وجود ندارد حتی اگر کنترل های امنیتی در محل قرار داده باشید. چندین راه حل وجود دارد که می تواند موثر باشد. اول اینکه کاربر ماشین مجازی می تواند به سادگی فیلترینگ یا فایروالینگ ترافیک را بر مبنای سیستم عامل فراخوانی کند. و دیگر اینکه شما می توانید نمونه های مجازی جدیدی روی مدیریت شبکه سنتی و راه حل مانیتورینگ، گسترش دهید. نظیر Cisco 1000V

اگر شما ارتباطات چندگانه و ماشین های مجازی عملیاتی داشته باشید که نیاز دارند به صورت پویا جهت Load Balance منتقل شوند، چه مسئله ای پیش می آید؟ اگر که IP Adress VMها تغییر کند، هنگامی که آنها از یک هاست به هاست دیگر منتقل شوند و آدرس دهی استاتیک برای قوانین فایروال استفاده شود، ممکن است فیلترینگ فایروال دچار مشکل شود. برای مجازی سازی شبکه نیاز است که یک اینترفیس برای VM فراهم شود. اینترفیس ممکن است یک کارت شبکه مجازی مالتی پلکس با همه امکانات سوئیچینگ و روتینگ به کار گرفته شده در شبکه اصلی، باشد.

اکثر Hypervisor در سطح Enterprise (برای مثال، Hyper-V) سوئیچ های مجازی دارند (همچنین فایروال های مجازی را پشتیبانی می کنند) که بین کارت شبکه Physical سرور و کارت شبکه مجازی VMها قرار داده شده است. اساس ابر باید برای تغییراتی که برای مکان VM ساخته و فعال شده اند، پیش بینی شده باشد یا حداقل، مسیر ارتباط قابل دسترس یا غیر قابل دسترس بین آنها مشخص شده باشد.

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

برای این منظور، جدای از زیرساخت لایه Core به پشتیبانی Vlanها نیاز داریم که روی سرورهای مجازی Host اعمال شوند. خوشبختانه راه حل های Enterprise شبیه Hyper-v و ESX این موضوع را پشتیبانی می کنند. اگرچه این راه حل به قابلیت گستردگی Vlan برای پشتیبانی از ابرهای پویای بزرگ بستگی دارد. و نیز با معرفی سیستم Center Virtual Machine Manager 2012 این پشتیبانی را خواهید داشت و این می تواند با سیستم مدیریت شبکه فعلی و Hypervisor ترکیب شود (SCVMM از Hyper-V و ESX و Xen پشتیبانی می کند.)

آخرین مرحله از نقطه نظر امنیتی این است که شرکت های سازنده برای گرفتن گواهی نامه های امنیتی محصولاتشان تلاش کنند. آنها می دانند که مجازی سازی، زیرساخت مدیریتی را پیچیده تر می کند و وقتی که شما جنبه های دیگر پردازش ابری را معرفی می کنید، اتوماسیونی عظیم برای پشتیبانی، Elasticity و On-Demand Self-Service مورد نیاز است. به دلیل همین اتوماسیون و مقیاس، شما برای مدیریت خطر در محیط ابری مجازی شده توسط معماری، طراحی و مدیریت به تلاشی بیشتر از قبل احتیاج دارید. اتوماسیون مدیریت محیط ابری مجازی سازی شده شما را قادر می سازد تا امنیت بیشتری داشته باشید، به این دلیل که محیط ابر را از ابتدا تا انتها یکپارچه می کند.

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TechnoratiSubmit to TwitterSubmit to LinkedIn

برچسب ها: VLAN, رایانش ابری چیست, رایانش ابری و مسئله امنیت, Hypervisor, Citrix XenServer, Hyper-V, Public Cloud, Private Cloud, Cloud Computing