در طول پنج سال گذشته، ما شاهد تغییرات فوق العاده ای در فناوری، پرسنل و شیوه های تجاری بوده ایم. ابر در حال حاضر به مدل صنعتی واقعی برای ارائه خدمات محاسباتی تبدیل شده است. تلفن همراه به رایج ترین مدل برای دسترسی به داده ها تبدیل شده است. پلتفرم‌های ابری روزانه میلیاردها دستگاه اینترنت اشیاء (IoT) را مدیریت می‌کنند و پیشرفت‌های جدید هیجان‌انگیزی مانند ریزسرویس‌ها در حال توسعه هستند تا مقیاس‌پذیری و کارایی غیرقابل تصوری را که قبلاً تصور نمی‌شد، ایجاد کنند.
با این حال، با معرفی ابر سازمانی، کنترل‌های حسابرسی جدید برای پرداختن به استفاده از این فناوری‌های جدید، مدل‌های خدمات جدید و تفاوت‌های ظریف جدید در نحوه اعمال کنترل‌های حسابرسی موجود در ابر مورد نیاز است.
کتاب سفید ارزیابی ریسک ابر سازمانی یک راهنمای ارزیابی مشترک است که راهنمایی های گام به گام را برای سازمان های سازمانی ارائه می دهد که خدمات خود را به ابر منتقل می کنند. این به سازمان‌های سازمانی کمک می‌کند تا یک استراتژی ابری ایجاد کنند که در بین صدها ارائه‌دهنده ابری آنها، هم در سطح محلی و هم در سطح بین‌المللی گسترش می‌یابد. من این امتیاز را داشتم که ریاست این کاغذ سفید ابری را بر عهده داشته باشم. نقش من به عنوان CISO در Domo، بزرگترین پلتفرم تجزیه و تحلیل ابری و با بیش از 25 درصد از 50 شرکت جهانی فورچون به عنوان مشتری، به من این امکان را داد که برخی از بهترین شیوه ها و درس های مهم صنعت را در این کاغذ سفید بگنجانم.
بهترین روش ها برای مدیریت رایانش ابری سازمانی
مقاله سفید مفهوم Common Cloud Controls را معرفی می کند. اینها حوزه‌های کنترل بالغ مرتبط با محیط‌های خدمات فناوری اطلاعات سنتی هستند که برای سرویس‌های مبتنی بر ابر نیز قابل اجرا هستند. این مکانیسم‌های حسابرسی بالغ در نظر گرفته می‌شوند (مثلاً محافظت در برابر ویروس، بررسی پس‌زمینه، و غیره) و صدها مورد از این کنترل‌های بالغ وجود دارد که بر روی ابر اعمال می‌شوند. سازمان ها می توانند به سادگی از ابزارهای حسابرسی موجود خود برای ارزیابی این کنترل ها استفاده کنند، مانند SOC II، ISO 27001، ارزیابی های مشترک AUP و غیره.
این فرآیند باید به سازمان اجازه دهد تا با استفاده از برنامه های ممیزی فعلی، بیش از 80 درصد از کنترل های ارائه دهنده ابر را به سرعت و کارآمد ارزیابی کند.
سپس نواحی کنترلی هستند که معمولاً تحت پوشش ISO 27001 یا SOC II نیستند (مثلاً چند اجاره، کانتینرسازی و غیره). کاغذ سفید آنها را Delta Cloud Controls می نامد و ده ها مثال عملی از نحوه ترکیب موثر این حوزه های کنترلی در استراتژی ابری سازمان و برنامه حسابرسی ارائه می دهد.
کتاب سفید ارزیابی ریسک ابر سازمانی شامل فهرست کامل بهترین شیوه‌ها، سوالاتی برای بحث با ارائه‌دهندگان ابر و درس‌های آموخته‌شده برای حوزه‌های کنترلی مرتبط با ابر است، اما ما مراحل ارزیابی کنترل ابری را در چند موضوع کلیدی که باید در نظر گرفته شوند، خلاصه کرده‌ایم:
مدیریت داده ها:
کنترل های هر یک از چهار لایه اصلی چیست؟ از آنجایی که همه سرویس های ابری عمومی در یک محیط ابری اجرا می شوند، زیرساخت های یکسانی را به اشتراک می گذارند.
به کنترل‌های تقسیم‌بندی و جداسازی داده‌ها در لایه‌های اصلی نگاه کنید: شبکه، فیزیکی، سیستم و برنامه، و هر یک از کنترل‌های بالا را در هر لایه ارزیابی کنید (به عنوان مثال، کنترل‌های جداسازی داده‌های ابری معمولاً در لایه فیزیکی ضعیف‌تر هستند یا وجود ندارند. ، مانند جایی که اغلب جداسازی فیزیکی وجود ندارد)، که نیاز به کنترل های سه لایه دیگر بسیار قوی تر دارد. توجه ویژه ای به کنترل های برنامه داشته باشید، زیرا این لایه ای است که اکثر کنترل های ابری حیاتی در آن قرار دارند.
همچنین، سازمان ها باید نقش و مسئولیت خود را به عنوان “کنترل کننده داده” و ارائه دهنده ابر به عنوان “پردازنده داده” را درک کنند. عدم درک اینکه چه کسی مسئول است یکی از دلایل اصلی حوادث امنیتی و حریم خصوصی است.
تعیین کنید که آیا به هر مشتری یک کلید رمزگذاری منحصر به فرد ارائه شده است یا اینکه آیا کلیدهای رمزگذاری مشترک هستند. کلیدهای مشتری منحصر به فرد یک کنترل قوی هستند که می توانند داده های ترکیبی را در پایگاه داده توسط مشتری دیگر غیرقابل خواندن کنند.
اطمینان حاصل کنید که داده های مشتری در ذخیره سازی و انتقال از طریق شبکه، در سراسر شبکه های خارجی و داخلی، به عنوان مثال، رمزگذاری شده است. ارائه‌دهنده خدمات ابری و زیرساخت‌های زیربنایی آنها (مانند AWS، Azure). رمزگذاری شبکه داخلی و مرکز داده به مرکز داده اهمیت فزاینده ای پیدا می کند. زیرا شبکه های خصوصی یا داخلی مستعد نفوذ غیرمجاز به شبکه هستند.
مدیریت مکان:
داده های من کجاست؟ این امر به ویژه برای ارائه دهندگان خدمات ابری که ممکن است مراکز داده و تیم های پشتیبانی در حوزه های قضایی متعدد قانونی داشته باشند بسیار مهم است.
مهم است که از ارائه دهندگان ابری خود بخواهید که همه مکان هایی را که در آن ذخیره، پردازش، انتقال یا دسترسی به داده های مشتری می کنند و اینکه آیا آنها به طور خاص در قرارداد تعریف شده اند را فهرست کنند. حصول اطمینان از اینکه قرارداد ابری همه کشورها یا حوزه های قضایی قانونی را که داده های شرکت در آنها ذخیره، پردازش یا به آنها دسترسی پیدا می کند، مستند می کند، برای کمک به سازمان ها برای برآوردن الزامات حریم خصوصی داده های داخلی مهم است. توجه به این نکته مهم است که دسترسی ساده به شبکه از طریق پشتیبانی از یک کشور دیگر اغلب مانند «ذخیره‌سازی داده» در آن کشور در نظر گرفته می‌شود، و به این ترتیب ممکن است طیف کاملی از الزامات امنیت و حفظ حریم خصوصی ذخیره‌سازی داده اعمال شود.
فرآیند ارزیابی باید شامل بررسی کامل هر گونه تضاد احتمالی در حریم خصوصی داده ها و الزامات قانونی کشورها باشد. یک مثال این است که اگر مشتری و ارائه‌دهنده ابر در ایالات متحده واقع شده باشند و ارائه‌دهنده چندین مرکز داده در ایالات متحده داشته باشد، ممکن است تضاد حریم خصوصی داده‌ها ایجاد شود، اما همچنین دارای یک مرکز داده در آلمان برای بازیابی بلایا و مقاوم‌سازی باشد. ایالات متحده ممکن است نیاز به حذف برخی از داده ها داشته باشد (به دلیل الزامات حفظ حریم خصوصی داده های ایالات متحده)، در حالی که قوانین آلمان ممکن است نیاز به حفظ داده ها (به عنوان مدرک در دادخواست بعدی) داشته باشد. در این سناریو، تضاد قوانین بین حوزه های قضایی می تواند یکپارچگی داده های مشتری را در معرض خطر قرار دهد.
مدیریت کاربر:
احراز هویت، مجوز و گزارش کاربر چگونه مدیریت می شود؟ یک مدل مدیریت کاربر یکپارچه جزء اصلی ابر از منظر تجاری، قابلیت استفاده و امنیت است.
شرکت‌هایی که از ابر استفاده می‌کنند می‌توانند برای ادغام راه‌حل‌های مدیریت هویت و گزارش موجود خود با راه‌حل‌های ارائه‌دهنده ابر به چالش کشیده شوند. اطمینان حاصل کنید که ارائه‌دهنده ابر از استانداردهای فدراسیون هویت مانند SAML یا OpenID پشتیبانی می‌کند تا از ادغام‌های فردی پرهزینه و یکباره جلوگیری کند.
هنگامی که کاربر احراز هویت شد، مرحله بعدی مجوز است. مهم است که ارائه‌دهنده ابر بتواند مجموعه‌ای از مجوزهای کاربر را حفظ کند تا کمترین امتیاز مشتری و الزامات تفکیک وظایف در محیط آن ارائه‌دهنده ابر برآورده شود.
همچنین، اطمینان حاصل کنید که تمام اقدامات کاربر نهایی، اعم از تایپ یا مرور، در فضای ابری ثبت شده است و یک API برای ادغام داده‌های گزارش مستقیماً در ابزارهای نظارت امنیتی مشتری وجود دارد. این برای مشتری مهم است که چندین ارائه دهنده ابر خود را از مرکز عملیات امنیتی مشتری (SOC) نظارت کند.
مدیریت تامین کننده:
چگونه به ارائه دهنده ابر خود امتیاز بدهم؟ مانند هر مدل ارائه‌دهنده‌ای، یک سازمان می‌تواند مسئولیت خدمات را برون‌سپاری کند، اما نه ریسک یا مسئولیت‌پذیری مرتبط.
یکی از پایه های ابر ماهیت انعطاف پذیر آن است که ریشه در نوآوری و تغییرات سریع دارد. به این ترتیب، مدل کلاسیک ارزیابی فروشنده شما یک بار در سال، برای ابر مقیاس نمی شود. در عوض، شرکت‌ها باید یک برنامه نظارت و مدیریت بر اساس تقاضای فروشنده بسازند که بر اساس سطح تغییرات مداوم در ابر است. در صورت امکان، این امر باید از ارائه‌دهنده ابری بخواهد که تعدادی محرک برای یک الزام اعلان ارائه کند، از جمله اعلان زمانی که کنترل‌های امنیت مواد تغییر می‌کنند، فروشندگان مربوطه ارائه‌دهنده ابر تغییر می‌کنند (به عنوان مثال، انتقال از AWS به Azure)، یا زمانی که شکاف‌های کنترلی تعریف‌شده خاصی (به عنوان مثال، یک آسیب پذیری خارجی سطح بالا برای مدت زمان مشخصی باز می ماند).
یکی از چالش ها این است که اطمینان حاصل شود که مزایای اجرای یک راه حل ابری با پیچیدگی انجام تجارت در فضای ابری جبران نمی شود. ارائه‌دهنده ابر باید یک نقطه تماس واحد، یک قرارداد واحد و یک نقطه پاسخگویی را برای مدیریت راه‌حل انتها به انتها، بدون توجه به خدمات اساسی که خودشان استفاده می‌کنند، ارائه دهد.
مهم است که از ذهنیت «خارج از دید، دور از ذهن» محافظت کنید: این هنوز داده ها و خدمات شما هستند، حتی اگر مستقیماً توسط ارائه دهنده ابر میزبان یا مدیریت شوند.
موارد فوق تنها برخی از بهترین روش‌هایی است که می‌توان در مقاله سفید منتشر شده اخیر درباره ارزیابی‌های مشترک ارزیابی ریسک ابر برای سازمان یافت. امیدوارم در راهنمای ارزیابی ریسک ابری ارزشی پیدا کرده باشید و به بخشی جدایی ناپذیر از جعبه ابزار مدیریت فروشنده ابری شما تبدیل شود. کل وایت پیپر را می توانید از اینجا دانلود کنید.