cloudComputing

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

به خاطر داشته باشید که یک ابر ویژگی‌های زیر را دارا می‌باشد:

• Self-service
• Broad Network Access
• Elasticity
• Chargeback
• Resource pooling

ممکن است متوجه شده باشید که مجازی‌سازی هیچ یک از 5 مورد فوق نیست البته مجازی‌سازی دستیابی به قابلیت‌های فعال شده توسط هر یک از این موارد را بسیار آسان‌تر می‌کند. از آنجایی که ما به احتمال زیاد از یک یا چند پلتفرم مجازی‌سازی در دیتاسنترهای ابرمان استفاده می‌کنیم (ابر عمومی یا خصوصی یا هیبرید)، نیاز داریم تا بعضی از مسائل امنیتی مرتبط با مجازی‌سازی در ابر را مطرح کنیم. پیش از اینکه بتوانیم هوشمندانه درباره مسائل امنیتی مرتبط با مجازی‌سازی و پردازش ابری فکر کنیم باید بدانیم که مجازی‌سازی چگونه در یک محیط ابری مورد استفاده قرار می‌گیرد. یک ماشین مجازی (VM) نامیده می‌شود عموماً مثالی از یک سیستم عامل است که شامل تنظیمات و Image سیستم عامل است. Image سیستم عامل یک Snapshot از سرور است و فضایی از دیسک مجازی را اشغال می‌کند. شما به فرمی از تکنولوژی برای پشتیبانی ماشین‌های مجازی احتیاج دارید که این با Hypervisor انجام می‌شود. Hypervisor به ماشین مجازی، محیط سخت‌افزاری که بتواند در آن کار کند را ارائه می‌دهد. پلتفرم‌های مجازی‌سازی گوناگون، کاربردهای متفاوتی دارند. صرف‌نظر از شرکت‌های سازنده دو نوع استاندارد برای پلتفرم‌های مجازی وجود دارد که امروزه استفاده می‌شود.

Oracle VM VirtualBox, VMware Workstation, VMware Fusion, Parallels Desktop مثال‌هایی از نوع دوم Hypervisor هستند.

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

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

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

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

نکته دیگری که باید به خاطر بسپارید این است که مجازی‌سازی، روابط بین سیستم عامل و سخت افزاری که روی آن پیاده می‌شود را تغییر داده است. این نکته خود به خود ذهنیت قبلی شما، زمانی‌که یک سیستم عامل و برنامه‌ها را روی یک سرور فیزیکی نصب می‌کردید، از لحاظ امنیتی تغییر خواهد داد. اما این باور که آنچه می‌توان لمس یا احساس کرد، اصولاً امنیت بیشتری دارد، لزوماً صحیح نمی‌باشد. حال درباره کاربر و اینکه او راجع به امنیت لپ تاپی که به اینترنت متصل شده است، چگونه فکر می‌کند بیاندیشید. مفهومی که مجازی‌سازی در ذهن القا می‌کند یک تابلوی امنیتی از سیستم عامل است. وقتی که درباره نقش مجازی‌سازی در پردازش ابری فکر می‌کنید، باید مسائل مهم امنیتی زیادی را در نظر بگیرید. شاید مهم‌ترین مسئله‌ای که در محیط حقیقی دیده نمی‌شود، زمانی اتفاق می‌افتد که 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 مورد نیاز است. به دلیل همین اتوماسیون و مقیاس، شما برای مدیریت خطر در محیط ابری مجازی شده توسط معماری، طراحی و مدیریت به تلاشی بیشتر از قبل احتیاج دارید. اتوماسیون مدیریت محیط ابری مجازی‌سازی شده شما را قادر می سازد تا امنیت بیشتری داشته باشید، به این دلیل که محیط ابر را از ابتدا تا انتها یکپارچه می‌کند.

با نگاهی سریع، یک ابر (خصوصی یا عمومی) می‌بایستی 5 ویژگی زیر را داشته باشد تا بعنوان یک ابر در نظر گرفته شود:

• – On Demand Self Service

• – دسترسی به شبکه گسترده

• – به اشتراک گذاری منابع (Sharing of Pooled Resource)

• – انعطاف پذیری بلقوه (Rapid Elasticity)

• – مجموعه ای از خدمات (Metered Services)

مراکز داده سنتی ممکن است که برخی از ویژگی‌های ذکر شده را داشته باشند؛ اما بعید است که شامل همه‌ی ویژگی‌ها بشوند. و اگر مرکز داده ای تمام 5 ویژگی را بصورت یکپارچه در بر‌گیرد، موجب تعریفی از ابر می‌شود.

قبل از اینکه درگیر بحث امروز شویم که در مورد مسائل امنیتی و حفاظتی ابر خصوصی است، کمی در مورد ابر خصوصی مایکروسافت صحبت کنیم. ممکن است در مورد ابر خصوصی مایکروسافت مطالبی خوانده باشید و فکر کنید که ابر خصوصی مایکروسافت فقط در مورد Hyper-V و System Center Virtual Machine Manager است. هر چند که بخش‌های بسیار مهمی در ابر خصوصی مایکروسافت هستند اما به تنهایی کل ابر را تشکیل نمی‌دهند. در حالیکه مایکروسافت تلاش می‌کند پیام و هدفش را ساده نگاه دارد، اما آنچه که مشخص است این‌است که پیچیدگی ابر خصوصی مایکروسافت به Hyper-V و SCVMM ختم نمی‌شود. جزئیات پیچیدگی‌های ابر مایکروسافت در بحث امروز نمی‌گنجد اما اگر به این بحث علاقمندید، می‌توانید از مرجع “معماری ابر خصوصی” در TechNet سایت Wiki استفاده کنید.

امنیت در ابر بسیار شبیه به مرکز داده است. شما کماکان می‌بایست نگران امنیت، احراز هویت و دسترسی باشید و مسائل امنیتی را در هر لایه‌ای از شبکه رعایت کنید. هیچ چیز خاص و خارق العاده‌ای در مورد امنیت ابر خصوصی وجود ندارد. با این وجود، می‌بایستی به نکات منحصر بفردی در مورد ابر خصوصی برای اولویت‌های امنیتی خود، در مناطقی خاص توجه کنید. یکی از راه‌های تامین امنیت ابر توجه به 5 ویژگی اصلی ابر است. امنیت در جهانی از پردازش و محاسبات Self Service چگونه تامین می‌شود و چه تعریفی دارد؟ در مورد مسائل امنیتی دسترسی به شبکه‌ی گسترده چه باید کرد؟ امنیت فایل‌های به اشتراک گذاشته شده و منابع چه می‌شود؟ این‌ها مسائلی هستند که سعی داریم در بحث‌های آتی به آنها پاسخ دهیم.

چگونه امنیت ابر خصوصی را با وجود On Demand Self Service تامین کنیم؟

On Demand Self Service به مشتریان ابر خصوصی اجازه می‌دهد تا بر اساس نیاز و توانایی خود در پرداخت، از منابع، حافظه، Storage و … استفاده کنند. اگر در ابر خود SaaS یا PaaS را گسترش دهید، مشتریان شما نیز می‌توانند پلت فرم توسعه یافته و خدمات کامل شده را بدست آورند.

اثرات Self Service و تاثیر آن بر امنیت:

اولین چیزی که به ذهن می‌آید این حقیقت است که شما دیگر تحت کنترل کامل و محدود به Workload مرکز داده‌ی خود نیستید، یا حتی سیستم عامل‌های مورد استفاده در آن. بر خلاف مرکز داده‌ی قدیمی که سرورها در رک قرار داده می‌شد و سیستم عامل نصب می‌گردید، سپس نرم‌افزار Workload بر روی آنها نصب می‌شد با On Demand Self Service ابر خصوصی، مشتریان ابر شما قادر خواهند بود از هر سیستم عاملی فارغ از نوع سخت افزار در دسترس استفاده کنند و حتی نرم‌افزار خود را بسازند و همه این‌ها فقط به این بستگی دارد “که شما می‌خواهید چه خدماتی را به مشتریان خود ارائه دهید.”

با شرایط جدید دیگر نیازی نیست نگران این باشید که در مرکز داده شما در حال حاضر چه نرم افزارهایی اجرا می‌شوند و آیا خدماتی که ارائه می‌شوند Unaware Application هستند. با وجود ابر خصوصی نیاز به آزمون و خطا در رابطه با سازگاری نرم‌افزارها و سرویس‌های موجود ندارید، چون شما سیستم نظارتی خود را پیکربندی می‌کنید و می‌دانید که مشتریان از منابع موجود در ابر خصوصی شما چه استفاده‌ای می‌کنند. این بدین معنی است که شما نیاز به توجه بیشتری نسبت به نظارت (مانیتورینگ) و گزارشات و هشدارها دارید. زیرساخت ابر باید قادر باشد تا در صورتی که استفاده مشتریان موجب بروز مشکل در سامانه امنیتی ابر شود و عملی بر خلاف قوانین امنیتی حاکم برابر باشد؛ هشدار و گزارش ارائه دهد. علاوه بر این، شما نیاز به گزارش دهی روزانه و حتی دقیق‌تری دارید، به طوری که در صورت بروز هرگونه مشکل بتوانید علت رخداد را به روشنی بیابید و در صورت درخواست مشتری نیز (مبنی بر عملکرد و نوع استفاده) گزارش کاملی را ارائه کنید. ابزارهای نظارت، هشدار دهی و گزارش گیری نیز برای پشتیبانی از On Demand Self Service ابر خصوصی نیاز به بروزرسانی و یا جایگزینی دارند. بسیاری از ابزارهایی که امروزه استفاده می‌کنیم، برای مرکز داده که در آن IT بر کل زیرساخت سخت‌افزاری و نرم‌افزاری کنترل دارد، طراحی شده‌اند. در ابر خصوصی، عامل حیاتی On Demand Self Service این است که نیازی به تعامل میان مدیر شبکه و مشتریان ابر ندارد. کاربران فقط آنچه را که از لیست خدمات شما می‌خواهند را انتخاب می‌کنند، و تمام!

شما به ابزاری نیاز دارید تا از حجم کاری (Workload) سرویس جدیدی که ارائه می‌دهید آگاه شوید. در ابرهای خصوصی بزرگ می‌توان هزاران یا حتی ده‌ها هزار ماشین مجازی راه‌اندازی کرد که برخی از آنها پردازش‌هایی را انجام می‌دهند که موجب نابودی ابر می‌شود. (بواسطه سیاست‌ها و یا دخالت‌هایی که در بخش مربوط به کاربر صورت می‌گیرد.) در زمان گزارش‌گیری و نظارت احتمالاً مهمترین موضوعات مورد توجه، On Demand Self Service و ویژگی‌های ابر می‌باشد، اما چند مسئله دیگر نیز وجود دارد که شما باید در نظر بگیرید. برخی از آنها عبارتند از:

1.چطور در مورد نحوه و میزان دسترسی افراد به خدمات ابر تصمیم می‌گیرید؟

2.چگونه به تک‌تک افراد حق دسترسی به خدمات ابر را می‌دهید؟

3.آیا سیاست AAA (شناسایی، دسترسی و حساب کاربری) و زیرساخت ابر، قادر به حوزه‌بندی در دسترسی به خدمات ویژه می‌باشد یا هر‌کسی حق دسترسی به هر‌چیزی را در مجموعه خدمات ابر داراست؟

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

در ادامه نیز قصد داریم جزئیات بیشتری از ابر خصوصی مایکروسافت بعد از Windows Server 8 و مجموعه سازگار Windows Server 8 با محصولات System Center را ارائه دهیم. ما در مورد ویژگی Broad Network Access رایانش ابری و معرفی مسائل امنیتی مورد نظر شما، بحث خواهیم کرد. هنگامی که ما به دسترسی به شبکه گسترده رایانش ابری اشاره می‌کنیم، منظور ما منابعی به میزبانی ابر است که باید در دسترس هر دستگاه محاسباتی بدون در نظر گرفتن نوع و مکان اتصال به اینترنت، قرار بگیرد. از 5 ویژگی اساسی رایانش ابری، بیشتر دسترسی به شبکه گسترده (Broad Network Access) مورد بحث قرار دارد. دلیل آن هم این است که زمانی که شما در مورد ابر خصوصی فکر می‌کنید، اولین مورد برای استقرار ابر خصوصی، حفاظت از اطلاعات با ارزش خود به دور از دسترسی بسیاری از مردم در اینترنت است. به نظر می‌رسد در دیدگاه بسیاری از افراد، Broad Network Access در ابر عمومی نسبت به ابر خصوصی کاربردی‌تر باشد. با این حال، شما می‌توانید دیدگاه متفاوت‌تری نسبت به Broad Network Access داشته باشید.

مسائل کلیدی مربوط به دسترسی به شبکه گسترده و امنیت ابر خصوصی شامل موارد زیر می‌باشد:

• Perimeter network role and location
• Identity and Access Management -IdAM
• Authentication
• Authorization
• Role-based access control -RBAC
• Federation
• Logging and Auditing
• Public network connectivity
• Endpoint Protection Client Security