یک تصمیم اساسی برای معماران امنیت ابری این است که تا چه حد به ابزارهای امنیتی مبتنی بر ابر ارائه دهنده ابر خود تکیه کنند، خواه AWS، GCP، Azure یا هر ارائه دهنده دیگری باشد. “تا حد امکان” آرزوی مهندسان ابر است، در حالی که متخصصان امنیت تمایل دارند فروشندگان امنیتی شخص ثالث را ترجیح دهند. بسیاری از متخصصان امنیتی ابزارهای مدیریت آسیب‌پذیری، ضد بدافزار یا جلوگیری از از دست دادن داده‌ها را برای سال‌ها پیاده‌سازی کردند و با آنها کار کردند. چرا از ابزارهای مشابه در ابر استفاده نمی کنید؟ این تضاد فرهنگ‌ها است و شش پایان‌نامه زیر برای کمک به حرکت از تصمیم‌گیری مبتنی بر احساسات به تصمیم‌گیری معماری مبتنی بر واقعیت طراحی شده‌اند.
پایان نامه 1: فروشندگان ابر نه خیریه هستند و نه ابرقهرمان – آنها نابغه بازاریابی هستند
ارائه دهندگان ابری می دانند که چگونه می توانند مطبوعات خوبی داشته باشند. در سال 2021، مایکروسافت وعده 20 میلیارد دلار سرمایه گذاری در حوزه امنیت در پنج سال آینده را داد. آیا بخش‌های فناوری اطلاعات باید امنیت مایکروسافت را پیاده‌سازی کنند و هیچ چیز دیگری؟ در اینجا سه فکر وجود دارد:
- در مورد خدمات امنیت ابری هیچ ناهار رایگانی وجود نخواهد داشت. شرکت ها برای ایجاد بازپرداخت (بالاتر) سرمایه گذاری می کنند. ارائه‌دهندگان ابری که مبالغ هنگفتی را برای خدمات ساختمانی هزینه می‌کنند، باید آنها را با درآمد مشتری بازپرداخت کنند.
- فروشندگان امنیت ده ها سال است که در بازار هستند و به طور مداوم نرم افزار خود را بهبود می بخشند. در مقابل، ارائه‌دهندگان ابری در حال مهندسی از صفر هستند یا فروشندگان موجود را به دست می‌آورند – سرمایه‌گذاری‌های پرهزینه برای رسیدن به زمان قبل از اینکه بتوانند نوآوری کنند.
- سرمایه‌گذاری 4 میلیارد دلاری مایکروسافت در سال در مقایسه با فروشندگان سنتی، سال‌های نوری دورتر از فروشندگان سنتی نیست: Symantec بیش از 4 میلیارد دلار درآمد در سال 2019 گزارش کرد، McAfee حدود 1.6 میلیارد دلار در سال 2020، و Fortinet گزارش 4 میلیارد دلار در سال 2022 گزارش کرد. با این حال، درآمد و سرمایه‌گذاری یکسان نیستند. “سرمایه گذاری” یک اصطلاح مبهم است. این همه چیز از مهندسی گرفته تا بازاریابی، خرید، و آموزش و مشاوره «رایگان» مشتری، حتی هزینه‌های عملیاتی خاص را پوشش می‌دهد.
پیام این پایان نامه اول ساده است: هنوز از فروشندگان امنیتی دست نکشید. ارائه دهندگان ابری بازیگران مهمی در تجارت امنیتی هستند و ممکن است غالب شوند. با این حال، در حال حاضر، به طور پیش فرض خیلی زود است که فرض کنیم، که ارائه دهندگان ابر ابزارهای بهتر یا مقرون به صرفه تری دارند.
پایان نامه 2: خدمات امنیتی Cloud-Native ایجاد یا بدتر کردن Cloud Lock-In ها
ابزار امنیتی بومی ابری می‌تواند مانع از انتقال بار کاری از یک ارائه‌دهنده ابری به دیگری (قفل کردن) شود. چنین قفل‌های ارائه‌دهنده ابر ممکن است الزامات نظارتی را نقض کند یا با استراتژی‌های فناوری اطلاعات در تضاد باشد که ضرورت تغییر ابرها با تلاش قابل مدیریت را برجسته می‌کند. قفل کردن می تواند به روش های مختلفی انجام شود:
- ابزارهای امنیتی مرتبط با حجم کاری ماشین‌های مجازی (VM) و کانتینرها را با مشاهده آنها در زمان اجرا و بررسی حجم کاری قبل از استقرار بازرسی و محافظت کنید. اسکن ضد بدافزار یا آسیب‌پذیری نمونه‌های معمولی هستند. استفاده از ابزارهای Cloud-Native برای این اهداف مستلزم نیاز به انتخاب ابزارهای جایگزین و ادغام آنها هنگام تغییر ابر است. همچنین، این ابزارها به دلیل مشکلات احتمالی قابلیت همکاری (مثلاً ناشی از عواملی که روی ماشین‌های مجازی کار می‌کنند) می‌توانند کار اضافی و عوارضی را برای تیم‌های برنامه ایجاد کنند.
- ویژگی های امنیتی خاص فروشنده ابر خطرات خاص یک ابر خاص را بررسی کنید. هنگام تغییر ابر، قوانین و ابزارهای قدیمی در این زمینه منسوخ می شوند. به عنوان مثال، در صورت جایگزینی توابع Azure با AWS Lambda، بخش‌های فناوری اطلاعات باید راه‌حل‌های کاملاً جدیدی را برای AWS Lambda مهندسی و راه‌اندازی کنند، خواه اجرای فعلی آنها برای توابع Azure با ابزارهای تولیدکننده ابری یا امنیتی کار کند.
- ابزارهای امنیتی عمومی راه حل هایی بدون یکپارچگی فشرده یا تعامل با برنامه ها یا یک ابر خاص هستند. یک مثال بارز ابزار مدیریت رویداد و اطلاعات امنیتی یک شرکت (SIEM) است. می تواند در هر فضای ابری یا داخلی اجرا شود. با این حال، فرض کنید یک شرکت یک راه حل SIEM بومی ابری را انتخاب کرده و اکنون تمام حجم کاری خود را به یک ارائه دهنده ابر دیگر منتقل می کند. در این صورت، شرکت باید ابزارهای امنیت عمومی بومی ابری خود را با راه حل های امنیتی جدید برای شناسایی و پیاده سازی جایگزین کند. در مقابل، ابزارهای فروشنده امنیتی شخص ثالث که بر روی ماشین‌های مجازی یا کانتینرها اجرا می‌شوند، به تلاش کمتری برای مهاجرت نیاز دارند و بنابراین، قفل کمتری برای فروشنده ابری دارند.
شکل 1 – انواع ابزار امنیتی از منظر قفل
پایان نامه 3: روشن کردن همه چیز یک استراتژی امنیتی نیست
خرج کردن 300 دلار در یک فروشگاه مواد غذایی تضمین کننده یک شام لوکس نیست. مواد باید با هم تناسب داشته باشند و شما باید طرز پخت را بلد باشید. همین امر در مورد سرویس های امنیتی ابری نیز صدق می کند. روشن کردن همه، امنیت کافی را تضمین نمی کند. تا به حال، ارائه دهندگان ابر بر مزایای (پرداخت اضافی برای) هر سرویس امنیتی جدید تأکید می کنند و مسئولیت مشتری خود را برای راه اندازی ایمن ابری برجسته می کنند. هیچ ارائه‌دهنده‌ی ابری به شما قول نمی‌دهد با روشن کردن همه سرویس‌هایش به اندازه کافی ایمن باشید. بنابراین، بخش‌های فناوری اطلاعات باید به شناسایی ریسک‌های اصلی خود ادامه دهند و راه‌حل‌های مناسبی را برای کاهش آنها انتخاب کنند، نه اینکه در ویژگی‌های سرویس‌های امنیتی مربوط به ابری که به راحتی فعال می‌شوند و توسط فروشندگان ابری تبلیغ می‌شوند گم شوند.
پایان نامه 4: مقایسه مدل های خدمات و هزینه، نه اعداد بدون زمینه
مقایسه مزایا و هزینه‌های اولیه و مداوم دو یا چند راه‌حل فناوری اطلاعات همیشه دشوار بود – مقایسه خدمات ابری و نرم‌افزار شخص ثالث بعد دیگری را اضافه می‌کند. برای راه‌حل‌های امنیتی، یکی از چالش‌ها درک تهدیدها و خطرات راه‌حل‌های مورد بررسی و جامعیت آنهاست. آیا راه حل جلوگیری از از دست دادن داده فقط به ایمیل یا ترافیک HTTP نگاه می کند؟ آیا راه حل می تواند ارتباطات رمزگذاری شده یا پیوست های ایمیل را مدیریت کند؟
دوم، شرکت ها باید فرآیندهای عملیاتی و هزینه های مربوط به اجرای آنها را با یک راه حل خاص درک کنند. آیا یک پشتیبان تکنسین IT جوان می تواند قوانین فایروال را پیکربندی و مدیریت کند یا به دو معمار ارشد امنیتی نیاز دارید؟ برای راه حل DLP، نسبت مثبت کاذب بسیار مهم است. اگر این ابزار فقط ده حادثه در روز ایجاد کند، هزینه های کارکنان کمتر از 1000 مثبت کاذب است.
دسته هزینه بعدی پیکربندی و ادغام راه حل با بقیه معماری فناوری اطلاعات و هزینه های نگهداری مداوم (“مدیریت برنامه”) را پوشش می دهد. این دسته هزینه برای راه‌حل‌های خود میزبانی و ابری اعمال می‌شود. در مقابل، یک دسته هزینه بین راه حل های خود میزبان و راه حل های ابری متفاوت است. فرض کنید یک بخش فناوری اطلاعات نرم افزار خود میزبانی می کند، چه در فضای ابری و چه در محل. در این مورد، سخت افزار، منابع محاسباتی، و هزینه های مربوط به سیستم عامل، هزینه های مجوز و تعمیر و نگهداری، و تلاش های عملیات برنامه وجود دارد. در مقابل، هزینه خدمات برای خدمات امنیتی بومی ابری همه این هزینه ها را پوشش می دهد.
بنابراین، درک هزینه ها و منافع دشوار است، اما مقوله های ذکر شده و تجسم در شکل 2 ساختار مفیدی را ارائه می دهند.
شکل 2 – تجزیه و تحلیل هزینه و فایده برای فروشندگان و خدمات امنیتی
پایان نامه 5: تمایز راه حل ها برای حجم کار اصلی و موضوعات طاقچه
به عنوان یک قاعده کلی، ابزارهای فروشنده امنیتی شخص ثالث با هزینه ثابت بالاتری نسبت به سرویس‌های بومی ابری به دلیل تلاش‌های یکپارچه‌سازی و عملیات برنامه ارائه می‌شوند. آنها برای خدمات بومی ابری به سادگی وجود ندارند یا بسیار کمتر هستند. فرض کنید یک شرکت فقط دو برنامه لینوکس را اجرا می کند. بقیه حجم کار روی هزاران ماشین مجازی ویندوز است. در چنین زمینه‌ای، ابزارهای بومی ابری ممکن است راه‌حل مؤثری برای بار کاری لینوکس باشند. در مقابل، راه حل های امنیتی شخص ثالث خود میزبان ممکن است گزینه ای برای حجم کار اصلی ویندوز باشد. پیام اصلی: ابزارهای بومی ابری، از نظر هزینه، غیرقابل رقیب هستند.
پایان نامه 6: اجازه ندهید یک استراتژی امنیتی امروز امنیت ابری شما را مسدود کند
ابزارهای امنیتی Cloud-Native بسیار سریعتر، حداقل به طور ابتدایی، نسبت به راه حل های امنیتی شخص ثالث راه اندازی و اجرا می شوند. ممکن است ویژگی‌ها محدود باشد و به دلیل کمبود رابط‌ها، ادغام و اتوماسیون، ممکن است به کارکنان اضافی نیاز باشد. با این حال، یک راه حل امنیتی سریع و کثیف بهتر از عدم محافظت است. «سریع و کثیف» با مدیریت و کاهش ریسک‌های امنیتی فعالانه، با محیط ابری جدید به‌سرعت زندگی می‌کند.
سه نقطه عطف هنگام راه اندازی یک محیط ابری جدید بسیار مهم هستند:
- نهایی کردن طراحی و پیاده سازی راه اندازی ابر (بدون ویژگی های امنیتی)،
- آماده سازی ابزار امنیتی برای محیط ابری جدید و
- استقرار برنامه های کاربردی در محیط ابری جدید.
در حالت ایده‌آل، توسعه معماری امنیتی و پیاده‌سازی ابزار به موازات راه‌اندازی محیط ابری اجرا می‌شود و امکان استقرار برنامه‌ها و استفاده مفید از ابر را بلافاصله پس از اتمام نصب فراهم می‌کند (شکل 3).
شکل 3 – ترتیب ایده آل محیط ابری و راه اندازی ابزار امنیتی که امکان شروع زودهنگام استقرار برنامه ها و استفاده از ابر را فراهم می کند.
در واقعیت، پیاده سازی ابزار امنیتی اغلب دیرتر از راه اندازی محیط ابری به پایان می رسد. دلایل معمول این امر عبارتند از:
- محدودیت های ساختاری طراحی ابر تمایل دارد در طول پروژه تغییر کند که نیاز به انطباق ابزار امنیتی دارد.
- ابزارهای امنیتی شخص ثالث استقرار آنها بر روی ماشین های مجازی یا کانتینرها به یک محیط ابری بالغ نیاز دارد. بعلاوه، هنگام راه اندازی نرم افزار (جدید) در یک محیط جدید، تلاش های اضافی معمولی وجود دارد.
شرکت‌ها می‌توانند با اتکای موقت به سرویس‌های امنیتی ابری به‌عنوان یک راه‌حل تاکتیکی، بر تأخیرهای ناشی از ابزارهای امنیتی شخص ثالث آماده (اما نه به دلیل محدودیت‌های ساختاری) غلبه کنند. ماهیت پرداختی و استفاده سریع آنها گزینه های تاکتیکی کاملی را برای آنها ایجاد می کند. به موازات آن، مهندسان بر روی ابزارهای امنیتی استراتژیک کار می کنند که شرکت وقتی آماده استفاده هستند، آنها را تغییر می دهد (شکل 4).
شکل 4 – تمایز بین راه‌حل‌های امنیتی ابری تاکتیکی و استراتژیک برای اطمینان از اجرای زنده و در عین حال ایمن
راه‌حل‌های تاکتیکی در مقابل راه‌حل‌های استراتژیک، ابزارهای فروشنده امنیت داخلی در مقابل ابزارهای امنیتی شخص ثالث و بسیاری ابعاد دیگر اهمیت دارند. طراحی یک معماری امنیتی برای محیط های ابری یک پازل پیچیده است. برای اکثر معماران امنیتی سرگرم کننده و برای دیگران آزاردهنده است. در هر صورت، این شش پایان نامه می توانند به غلبه بر تضاد فرهنگ ها بین متخصصان ابر و امنیت هنگام انتخاب بین راه حل های تامین کننده امنیت داخلی و شخص ثالث کمک کنند.