5 نکته و ترفند برای بهبود امنیت بومی در ابر


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

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

Cloud Native چیست؟

برنامه های ابری طبیعی برای ابر طراحی شده اند و اغلب کل چرخه عمر نرم افزار – توسعه ، استقرار ، آزمایش و به روزرسانی – در یک فضای ابری رخ می دهد. ابر به ابر عمومی محدود نمی شود. این می تواند به معنای یک ابر ترکیبی با منابع محلی از راه دور یا یک معماری چند ابر با بیش از یک ارائه دهنده ابر باشد.

تعریف Cloud Native Computing Foundation (CNCF) سه ابزاری را مشخص می کند که باید برای فناوری های رایانش ابری استفاده شوند. اینها ظرف سازی ، معماری ریز سرویس و ارکستراسیون پویا هستند. کانتینر سازی به معنای این است که این نرم افزار با وابستگی های خود کامل شده و در نتیجه قابل حمل و مقیاس پذیری است. ارکستراسیون پویا شامل استفاده از ابزارهایی مانند Kubernetes برای مدیریت ظروف در ابر است. و معماری ریز سرویس وظیفه بهینه سازی منابع را دارد. ظروف را می توان با ویژگی های بدون سرور ، یکی دیگر از طعم های رایج فناوری رایانش ابری ، جایگزین کرد.

چالش هایی برای امنیت بومی در ابر

برنامه های ابری در ابر ، زیرساخت ها و امنیت برنامه ها را با چالش های اساسی مواجه می کند. در اینجا چند چالش اساسی آورده شده است.

سایت های متعدد بیمه

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

مدل های مختلف معماری

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

چهارشنبه در شار

محیط های عمومی و خصوصی در ابر دائما در حال تغییر هستند. چرخه انتشار سریع نرم افزار به این معنی است که هر یک از اجزای برنامه ریز خدمات می توانند روزانه به روز شوند. علاوه بر این ، اتخاذ شیوه هایی مانند تغییرناپذیری و زیرساخت ها مانند کد (IaC) به این معنی است که برنامه ها به طور مداوم در حال تخریب و بازآفرینی هستند. ممکن است تیمهای امنیتی بدون تأخیر در چرخه انتشار ، امنیت این استقرارها را دشوار کنند.

چگونه می توان از برنامه های خود در ابر محافظت کرد

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

Shift Security چپ

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

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

بخش دیگری از مشکل این است که سازمانها از ابزار CI / CD (به عنوان مثال Jenkins ، Azure DevOps و Bamboo) برای توسعه مداوم ، آزمایش و راه اندازی برنامه ها استفاده می کنند. هنگام استفاده از کانتینرها برای استقرار برنامه ها در cloud cloud ، توسعه دهندگان از تصاویر پایه بازیابی شده از حافظه محلی یا مخازن عمومی استفاده می کنند ، اما اغلب بدون بررسی اینکه آیا این تصاویر دارای آسیب پذیری های امنیتی هستند.

یک راه حل این است که به تیم امنیتی خود ابزاری برای جلوگیری از تصاویر غیر قابل اعتماد در لوله کشی CI / CD و همچنین سازوکارهایی برای جلوگیری از مشکلات امنیتی در کد قبل از اجرای آن در تولید ارائه دهید. با اسکن نقاط ضعف ، اسرار و بدافزارهای تصویری در ابتدای فرآیند توسعه ، توسعه دهندگان می توانند در استفاده از استانداردهای امنیتی مشارکت کنند.

محافظت از محیط را در سطح عملکرد و ظرف اعمال کنید

در برنامه های بدون سرور ، سیستم به چندین بخش تقسیم می شود و اجزای سازنده را که از منابع مختلف باعث فعال شدن رویدادها می شوند ، فراخوانی می کند. این به اهداف مهاجم تنوع بیشتری در اهداف و بردارهای بیشتری برای فعالیتهای مخرب می دهد.

یک روش مهم استفاده از API ها و ابزارهای محافظت از برنامه های طراحی شده برای محیط ابری است. علاوه بر این ، رویکرد کلی استفاده از محافظت از محیط در سطح عملکرد است – شناسایی توابعی که توسط منبع متفاوتی نسبت به حد معمول تحریک می شوند و نظارت بر ناهنجاری ها در محرک های رویداد.

در یک محیط کانتینر دار ، توجه به امنیت در بسیاری از سطوح مهم است – صفحه کنترل ارکستر ، میزبانهای فیزیکی ، کف و ظروف. بهترین روشهای امنیتی برای ارکسترر مانند Kubernetes شامل جدا کردن گره ها ، محدود کردن و نظارت بر ترافیک کانتینرها و استفاده از احراز هویت شخص ثالث برای سرور API است.

حداقل نقش ها و امتیازات

تعاملات متعدد و مکرر بین منابع محلی در ابر وجود دارد. امکان اختصاص یک مجموعه منحصر به فرد از مجوزها به هر ویژگی یا ظرف بدون سرور ، فرصتی عالی برای بهبود امنیت فراهم می کند.

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

وابستگی های کاربردی امن

ویژگی های بدون سرور و کد برنامه اغلب شامل بسته های وابستگی است که از مخازنی مانند npm یا PyPI بازیابی می شوند.

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

مسئولیت مشترک امنیتی

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

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

نتیجه

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

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

ما امیدواریم که این بینش ها و بهترین روش ها به شما کمک کند تا یک انتقال ایمن و مطمئن به مدل ابر داشته باشید.


درباره نویسنده: گیلاد دیوید مایان نویسنده فناوری است که با بیش از 150 شرکت فناوری از جمله SAP ، Imperva ، Samsung NEXT ، NetApp و Ixia کار کرده است ، و تولید محتوای فنی و متفکرانه رهبری است که راه حل های فنی را برای توسعه دهندگان و رهبری IT روشن می کند. امروز او سر می زند سئو چابک، آژانس بازاریابی پیشرو در صنعت فناوری.

LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/

یادداشت ویراستار: نظرات بیان شده در این مقاله مهمان صرفاً نظرات نویسندگان است و لزوماً منعکس کننده نظرات Tripwire، Inc نیست.

Author: morteza

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *