هسته معماری امنیت ابری، تبدیل اهداف انتزاعی محرمانگی، یکپارچگی و در دسترس بودن به یک پیاده سازی امنیت ابری ملموس است. سازمان‌های فناوری اطلاعات به یک طراحی معماری نیاز دارند که تمام حوزه‌های امنیتی فنی مرتبط را پوشش دهد، بنابراین عوامل ورودی خاص شرکت را در نظر گرفته و چرخه حیات نیازمندی‌های معماری امنیتی را مدیریت می‌کند.
امنیت ابری: یک مسئولیت مشترک
Google Cloud Platform (GCP)، Microsoft Azure، Amazon AWS: همه فروشندگان برجسته ابر دارای تیم‌های امنیتی فناوری اطلاعات بزرگ هستند. آنها از سرمایه گذاری های مداوم خود در امنیت تمجید می کنند. بنابراین، چرا یک سازمان فناوری اطلاعات باید به امنیت محیط ابری خود اهمیت دهد؟
فروشندگان ابر با برجسته کردن مدل‌های مسئولیت مشترک با چنین تصورات غلط مبارزه می‌کنند. این مدل‌ها وظایف امنیتی را که ارائه‌دهنده ابر آدرس می‌دهد و وظایفی که مشتریان در قبال خودشان بر عهده دارند را مشخص می‌کنند. در اصل: فروشندگان ابر خدمات ابری ایمن (د) ارائه می دهند. مشتریان آنها آنها را به صورت راه حل جمع آوری می کنند. مشتریان باید از پیکربندی ایمن منابع فردی خود، راه حل های مختلف آنها که از چنین منابعی تشکیل شده است و خود محیط ابری اطمینان حاصل کنند. برای رسیدن به این هدف، معماران امنیت ابری نقش مهمی ایفا می کنند.
حوزه های فنی در امنیت ابری
معماران امنیتی تصمیمات طراحی مختلفی را برای راه اندازی ابر سازمان خود می گیرند (شکل 1). طراحی می کنند امنیت شبکه و حفاظت محیطی با فایروال ها و مناطق شبکه. آنها برای محافظت از یک شرکت در برابر مهاجمان خارجی و بخش بندی شبکه های سازمانی حیاتی هستند. دومی سطح حمله را برای حملات خودی کاهش می دهد و در صورت نفوذ هکرها مانع از حرکت جانبی می شود. بنابراین، هکرهای موفق نمی توانند به راحتی از یک سرور به سرور دیگر بپرند زیرا فایروال ها و تنظیمات شبکه آنها را متوقف می کنند.
شکل 1: موضوعات اصلی برای معماری امنیت ابری
یکی دیگر از موضوعات طراحی این است مدیریت هویت و دسترسی. این سؤال واضح را پوشش می دهد که آیا برای مثال از Google’s Cloud Identity، نصب اولیه اکتیو دایرکتوری مایکروسافت، یا یک Azure Active Directory بومی ابری استفاده کنیم. همچنین موضوعات پیشرفته‌ای مانند احراز هویت کاربران برنامه (مثلاً صدها هزار مشتری که بخشی از خود شرکت نیستند) یا محافظت از حساب‌های کاربری ممتاز و حساب‌های فنی را پوشش می‌دهد. به علاوه، جدیدترین مفاهیم احراز هویت بدون رمز عبور یا اعتماد صفر وجود دارد. تمام این تصمیمات طراحی مختص یک سازمان است. عدم شفاف سازی یا راه حل ها باعث هرج و مرج می شود، اگرچه هرج و مرج یک مزیت دارد: چنین نقص هایی به سرعت قابل شناسایی هستند.
سومین و آخرین بخش طراحی امنیت ابری را پوشش می دهد ابزارها و خدمات امنیتی نمونه ها هستند تشخیص حادثه، مدیریت حادثه، تشخیص بدافزار یا مدیریت وصله. معماران تصمیم می گیرند که آیا روی 3 سرمایه گذاری کنند یا خیرسوم ابزار حزب، به ابزارهای بومی ابری تکیه کنید، یا ریسک را بپذیرید و روی یک راه حل سرمایه گذاری نکنید. با این حال، فقدان ابزار مسائل قابل مشاهده بلافاصله ایجاد نمی کند. بنابراین، معماران و مدیران ممکن است بر این نیاز نظارت کنند تا زمانی که یک هکر بدون توجه به آن نفوذ کند.
سخت شدن گروه دوم مباحث معماری امنیتی را تشکیل می دهد. مانند ابزار و خدمات، سخت شدن ناکافی به راحتی قابل مشاهده نیست، به خصوص بدون یا قبل از حادثه. با این وجود، این یک فعالیت ضروری برای همه منابع ابری یا انواع منابعی است که مهندسان برای ساخت و اجرای برنامه های خود نیاز دارند. منابع نمونه ماشین های مجازی، کانتینرها، پیشنهادات پایگاه داده به عنوان سرویس مانند Cosmos DB و ذخیره سازی اشیا مانند AWS S3 هستند. یکی از اقدامات نمونه برای سخت‌سازی یک نوع منبع، جلوگیری از ایجاد ماشین‌های مجازی با آدرس‌های IP عمومی است. این اقدام سطح حمله را برای هکرهایی که سعی در نفوذ از اینترنت دارند کاهش می دهد.
سخت شدن بر اساس دستورالعمل های خاص شرکت برای پیکربندی انواع منابع مختلف و پیاده سازی و اجرای واقعی است. این شامل تصمیمات استراتژیک در مورد گزارش دادن منابع غیر منطبق یا حتی مسدود کردن ایجاد آنها است. مانند ابزارهای امنیتی ناکافی، سخت شدن از دست رفته بر موفقیت راه اندازی محیط ها و برنامه های ابری تأثیر نمی گذارد. می تواند ماه ها مورد توجه قرار نگیرد و مهاجمان می توانند از چنین آسیب پذیری هایی سوء استفاده کنند. دهه گذشته ثابت کرد که بسیاری از نشت‌های شدید داده در فضای ابری نتیجه مهاجمان باهوش نبوده است. اغلب، شرکت ها داده های خود را – به طور ناخواسته – در اختیار اینترنت قرار می دادند. اگر مهندسان شما بتوانند اطلاعات حساسی را بدون توجه به آن در وب قرار دهند، مقصر دانستن دیگران دشوار است. بنابراین، مدیران عامل، مدیران ارشد اجرایی و CISO باید از معماران امنیت ابری خود یک سوال ساده بپرسند: رویکرد شما برای ابزار امنیتی – و سخت‌تر کردن خدمات ابری چیست؟
تشریح الزامات و معماری های امنیت ابری
فروشندگان ابر یک جعبه ابزار فنی و مفهومی برای معماری امنیتی ارائه می دهند (شکل 2). از نظر فنی، آنها موارد مختلفی را ارائه می دهند ابزارها و خدمات امنیتیبه عنوان مثال، برای شناسایی تنظیمات اشتباه یا حملات. از جنبه مفهومی منتشر می کنند بهترین شیوه ها و دستورالعمل های پیکربندی خاص فروشنده. Google یک وب‌سایت مرکز بهترین شیوه‌های امنیتی Google Cloud را اجرا می‌کند، شبیه به بهترین شیوه‌ها و الگوهای امنیتی Azure مایکروسافت. مرکز امنیت اینترنت نمونه ای از انتشارات سازمانی است معیارهای صنعت با پیشنهادات اجرایی فنی مشخص بنابراین، چرا سازمان‌های فناوری اطلاعات علاوه بر همه این دستورالعمل‌ها و ابزارها، به معمار(های) امنیت ابری خود نیاز دارند؟
شکل 2: تدوین الزامات امنیت ابری خاص سازمان
پاسخ واضح است: خیاطی. خیاطی به معنای تطبیق مفاهیم کلی با یک زمینه خاص شرکت است. این کار معمولی معماران امنیت ابری است.
چهار عامل برای خیاطی اهمیت ویژه ای دارد:
- اشتهای ریسک نقض اطلاعات در یک بانک یا بیمه درمانی شدیدتر از یک فروشگاه آنلاین صابون است. در حالی که “اشتهای ریسک” انتزاعی به نظر می رسد، بر سیاست های امنیتی داخلی شرکت یا الزامات نظارتی تأثیر می گذارد. آنها استانداردهایی را تعریف می کنند، به عنوان مثال، برای رمزگذاری، که طراحی ابری سازمان را هدایت می کند.
- خدمات امنیتی موجود بیشتر پروژه‌های ابری سبز نیستند، اما می‌توانند (و باید) بر روی یک مجموعه نرم‌افزاری و خدمات موجود ایجاد شوند. شرکت‌ها مجوزهایی برای محصولات امنیتی دارند و تیم‌هایی را راه‌اندازی می‌کنند که از آنها استفاده می‌کنند، به عنوان مثال، بدافزار یا تشخیص آسیب‌پذیری. بنابراین، انگیزه استفاده از ابزارهای بومی ابری بین سازمان‌ها به شدت متفاوت است.
- منظره معماری. 100٪ فقط با یک فروشنده ابری، بدون ردپای در محل، بدون خدمات ابری دیگر، و بدون نرم افزار دیگر به عنوان یک سرویس – این ممکن است رویای این ارائه دهنده ابر خاص باشد. فقط واقعیت امروز نیست. بنابراین، اتصالات ابری ورودی و خروجی چالش های امنیتی معمولی در شبکه و لایه کنترل دسترسی هستند. ترکیب زیرساخت به عنوان یک سرویس و پلت فرم به عنوان یک سرویس حتی در یک فروشنده ابری چالش دیگری را ایجاد می کند. در نتیجه، شرکت‌هایی با استفاده از ابر متفاوت، تنظیمات امنیتی ابری متفاوتی دارند.
- فن آوری های مهندسی تعداد زیاد خدمات، سخت‌تر کردن تمام خدمات ابری را که فروشندگان در اختیار مشتریان خود قرار می‌دهند، غیرممکن می‌سازد. بنابراین، معماران امنیت ابری باید اولویت ها را تعیین کنند. آنها باید بدانند که برنامه های کاربردی موجود به کدام سرویس های ابری نیاز دارند و توسعه دهندگان ممکن است به زودی از کدام سرویس ها استفاده کنند.
اینها چهار دلیل اصلی هستند که تنظیمات امنیت ابری بین سازمان‌های فناوری اطلاعات متفاوت است. با این حال، معماری امنیت ابری یک فعالیت یک بار نیست. این یک کار مداوم و همیشه جوان کننده مانند دایره زندگی است.
چرخه حیات معماری امنیت ابری
نقل قول معروف بنجامین فرانکلین، «تغییر تنها عامل ثابت زندگی است. توانایی فرد برای انطباق با آن تغییرات، موفقیت شما را در زندگی تعیین می کند.» باید شعار هر معمار امنیت ابری باشد. حتی طرح‌های امنیتی عالی برای محیط‌های ابری باید با دنیای در حال تغییر سازگار شوند (شکل 3): وقتی مقررات سخت‌تر می‌شوند، مجوزها و قراردادها برای خدمات امنیتی موجود منقضی می‌شوند، اشتهای ریسک کاهش می‌یابد، فروشندگان ابری پیشنهادات جدیدی را در بازار عرضه می‌کنند و فناوری‌های جدید محبوبیت پیدا می‌کنند. توسعه دهندگان اینها برخی از تغییراتی است که معماران امنیتی هنگام درک سازمانی که برای آن کار می کنند و به طور مداوم پیشرفت فنی را مشاهده می کنند، متوجه آن می شوند. با این حال، عوامل دیگری نیز باعث تغییرات در معماری امنیتی می شوند.
شکل 3: سخت شدن امنیت ابر – چشم انداز چرخه حیات
عامل دوم این است بازخورد، عمدی یا غیر عمدی. بررسی های امنیتی یا آزمون‌های قلم – بنابراین درخواست از متخصصان خارجی – یک رویکرد کلاسیک برای افزایش اعتماد به وضعیت امنیتی سازمان و شناسایی شکاف‌ها است. فنی داخلی ممیزی ها در همان دسته قرار می گیرند، به طوری که خودکار بررسی های پیکربندی توسط سرویس هایی مانند مرکز امنیت GCP یا Microsoft Defender. شرکت ها آنها را می خواهند زیرا این اقدامات به بهبود کمک می کند.
شکل دوم – و بسیار ناخواسته – بازخورد از آن ناشی می شود هکرها. سازمان‌های فناوری اطلاعات ممکن است بر اساس آلارم‌های ابزارهای بومی ابری مانند Security Center یا Defender، از 3 متوجه آنها شوند.سوم ابزارهای امنیتی مهمانی، یا به طور تصادفی. حملات موفقیت‌آمیز و شکست‌خورده هر دو نشانه‌هایی را ارائه می‌کنند که وضعیت امنیتی سازمان ممکن است جایی برای بهبود داشته باشد.
نتیجه گیری: معماری امنیت ابری تلاش قابل توجهی در هنگام راه اندازی یک محیط ابری جدید است. پس از آن، این یک کار مداوم برای بازنگری مستمر و بهبود وضعیت امنیت ابری سازمان است، حتی پس از یک «برو زنده» که بسیار جشن گرفته شده است!