روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ امروز، برخی انواع مجازی‌سازی یا کانتینرسازی را می‌توان در راهکارهای بزرگ آی‌تی یافت. کانتینرها در طول توسعه سیستم، نصب، نگهداری و استفاده از آن مزایای زیادی ارائه می‌دهند. آنها توسعه سریعتر را موجب شده و در هزینه‌ها و حفظ سایر منابع صرفه‌جویی می‌کنند. در عین حال بسیاری از راهکارهای امنیتی که روی سرورهای فیزیکی و مجازی کار می کنند مستقیماً روی کانتینترها کارایی ندارند. چه ریسک‌هایی را شرکت‌ها باید موقع پیاده‌سازی کانتینرسازی در نظر گرفته و چه اقداماتی برای محافظت از زیرساخت کانتینر لازم است؟ با ما همراه بمانید.
مزایای کانتینرسازی در بخش توسعه و عملکرد
یک کانتینر محیطی است ایزوله برای اجرای اپ واحد که ابزارهای سطح کرنلِ سیستم عامل آن را ساخته‌اند. تصویر کانتینتر شامل هم اپ و هم تنظیمات لازم و اجزای کمکی می‌شود که موجب شده توسعه‌دهندگان بتوانند هر چیزی را که در کانتینر نیاز دارند پک کنند. آن‌هایی که از چنین کانتینری استفاده می‌کنند عملکرد آن را آسانتر از زیرساخت‌های قدیمی می‌دانند. افزون بر این، ایزولاسیون تا حد زیادی تأثیر اپ‌های کانتینرسازی‌شده را روی همدیگر کاهش می‌دهد. بنابراین در زیرساخت کانتینر برای شکست دلایل کمتری وجود دارد و در عین حال ادمین‌ها نظارت بیشتری روی ماجرا خواهند داشت. کانتینترسازی فناوری سبک‌تری نسبت به مجازی‌سازی است: کانتینترها سخت‌افزار را شبیه‌سازی نمی‌کنند و نیازی هم به تأمین کل محتواهای ماشین مجازی نیست- مشخصاً سیستم عامل مهمان. در بسیاری از موارد ورک‌لودهای کانتینترسازی‌شده را راحت‌تر می‌شود مقیاس کرد. بی‌شک، شایع‌ترین ابزار برای ایجاد و ذخیره تصاویر کانتینر، Docker است و این درحالیست که ارکستراسیون ورک‌لود کانتینر اغلب با Kubernetes، Docker Swarm یا Red Hat OpenShift پیاده‌سازی می‌شود. کانتینرسازی بخش کلیدی توسعه مدرن آی‌تی است. بسیاری از اپ‌ها در معماری میکروسرویس توسعه داده می‌شوند: ویژگی‌های جداگانه اپ بزرگ به میکروسرویس‌هایی اختصاص دارند که از طریق APIها با سایر اجزا در ارتباطند. نمونه‌اش ویدیو پلیر در یک شبکه اجتماعی یا روی پروسه پرداخت یک فروشگاه آنلاین. این میکروسرویس‌ها اغلب بعنوان کانتینرها ارائه می‌شوند و به توسعه‌دهندگان اجازه می‌دهند تا چرخه توسعه و تحویل مخصوص به خود را داشته باشند.
کانتینرها کاملاً با متدولوژی مدرن CI/CD (ادغام پیوسته/تحویل مستمر) مطابقت دارند، بنابراین به‌روزرسانی‌های برنامه سریعتر و با کاهش مقادیر باگ منتشر می‌شوند. این رویکرد یک چرخه توسعه کوتاه، تیم‌هایی که به صورت موازی روی همان کد کار می‌کنند و خودکارسازی اقدامات معمول را در نظر می‌گیرد.
Containerization در خط لوله CI/CD همچنین کارایی خط لوله را بهبود می بخشد: سیستم CI/CD از تصاویر ظرف به عنوان الگو استفاده می‌کند و ساخت را به عنوان یک تصویر آماده برای استقرار ارائه می‌دهد. نکته کلیدی این است که به‌روزرسانی‌ها به جای اینکه در یک کانتینر موجود و عملیاتی مستقر شوند در قالب تصاویر جدید ارائه می‌شوند. این امر سرعت آماده‌سازی و اشکال‌زدایی نسخه را افزایش، نیازهای زیرساخت توسعه دهنده و مشتری را کاهش می‌دهد، ثبات عملیاتی را بهبود بخشیده و مقیاس‌بندی برنامه را آسان تر می‌کند. با ادغام صحیح الزامات امنیتی کانتینر در فرآیندهای توسعه و ساخت، یک شرکت گام بزرگی به سوی اجرای کامل DevSecOps برمی دارد.
تهدیدهای هسته‌ای در زیرساخت کانتینتر
سیستم میزبان، محیط های کانتینرسازی و اپ‌های کانتینرسازی‌شده همگی در معرض بیشترِ ریسک‌های امنیت اطلاعات معمول مانند آسیب‌پذیری‌هایی در اجزا، تنیظیات ناامن و غیره قرار دارند. عاملین مخرب همین الانش هم دارند فعالانه همه موارد بالا را اکسپلویت می‌کنند. برای مثال 1650 تصویر کانتینر با بدافزار در ذخیره عمومی داکر هاب پیدا شد. در موردی مشابه، تصاویر مخرب یک سالی بدون اینکه شناسایی شوند باقی ماندند. کمپین‌های مخرب شناخته شده‌ای وجود دارند که از Docker API برای ایجاد کانتینرهای مخرب در سیستم های هدفمند، غیرفعال کردن سیستم های نظارت و شرکت در استخراج استفاده می‌کنند. در حمله دیگری، عوامل تهدید به دنبال خوشه‌های Kubernetes با PostgreSQL اشتباه پیکربندی شده بودند. یکی دیگر از مشکلات رایج این است که تصاویر کانتینر قدیمی که دارای آسیب پذیری‌های شناخته شده‌ای مانند Log4shell هستند، می‌توانند برای مدتی طولانی در مخازن ذخیره شوند. همچنین، توسعه دهندگان به طور منظم کلیدهای API و سایر اسرار را در کانتینرها به جا می‌گذارند. با نظام‌بندی تهدیدات هر عنصر در سیستم کانتینری‌سازی، این طرحِ تا حدودی ساده‌شده را بدست می‌آوریم:
کانتینرها و محافظت با استفاده از ابزارهای سنتی امنیتی
بسیاری از لایه‌های دفاعی که برای ماشین‌های مجازی خوب کار کردند نمی‌توانند روی امنیت کانتینتر پیاده شوند. معمولاً (آنطور که می‌شود آن را در ماشین مجازی انجام داد) ممکن نیست عامل EDR را داخل کانتینتر اجرا کرد. علاوه بر این، آنچه در کانتینر اتفاق می‌افتد توسط سیستم‌های قدیمی امنیتی روی سیستم میزبانی قابلیت تحلیل تمام عیار شدن ندارد. از این رو، برای مثال شناسایی نرم‌افزارهای مخرب و آسیب‌پذیر داخل کانتینر مشکل‌ساز است؛ درست همانطور که به کار بردن ابزارهای محافظتی مانند WAF در اپ‌های کانتینرسازی‌شده مشکل‌ساز است. ترافیک بین کانتینرها اغلب از طریق یک شبکه مجازی در سطح ارکستر انجام می شود و ممکن است برای ابزارهای امنیتی شبکه قابل دسترسی نباشد. حتی در سیستم عامل میزبان، یک عامل حفاظتی تطبیق‌نشده می‌تواند منجر به کاهش عملکرد یا پایداری برنامه‌های کاربردی کانتینری مستقر شده شود. امنیت خوشه باید در سطح میزبان مطابق با محیط ارکستراسیون خاص و ماهیت بار کاری کانتینر ارائه شود. همچنین مسائل خاصی وجود دارد که باید برای محیط‌های کانتینر مورد توجه قرار گیرد - مانند جلوگیری از اجرای کانتینرهای غیرقابل اعتماد، جستجوی اسرار در کانتینرها، و محدود کردن ترافیک شبکه برای هر کانتینر خاص بر اساس عملکرد آن. همه اینها فقط در راهکارهای تخصصی مانند Kaspersky Container Security در دسترس هستند.
محاظفت با ابزارهای بومی چطور؟
به نظر می‌رسد همه فروشندگان کلیدی کانتینرسازی به سختی برای بهبود امنیت محصولات خود تلاش می‌کنند. برای مثال، ابزارهای بومی Kubernetes می‌توانند برای پیکربندی سهمیه‌های منابع و سیاست‌های گزارش‌گیری و همچنین پیاده‌سازی RBAC (کنترل دسترسی مبتنی بر نقش) با اصل حداقل امتیاز استفاده شوند. با این حال، کلاس‌های کاملی از وظایف امنیت اطلاعات وجود دارد که با ابزارهای بومی قابل حل نیستند - مانند نظارت بر فرآیندهای داخل یک کانتینر در حال اجرا، تجزیه و تحلیل آسیب‌پذیری، بررسی انطباق با سیاست‌های امنیت اطلاعات و بهترین شیوه‌ها و موارد دیگر. اما مهمتر از همه، یک سیستم امنیتی کانتینر بالغ و کامل باید از محافظت در مراحل اولیه کانتینرسازی اطمینان حاصل کند: توسعه، تحویل و ذخیره‌سازی. برای دستیابی به این هدف، امنیت کانتینری باید در فرآیند توسعه تعبیه و با ابزارهای توسعه‌دهنده یکپارچه شود.
چطور محافظت کانتینر بخشی از DevSecOps می‌شود؟
رویکرد DevOps به دلیل رشد تقاضا برای امنیت و قابلیت اطمینان اپلیکیشن به DevSecOps تکامل یافته است. الزامات امنیت اطلاعات کلیدی برای اینکه امنیت را بخش اورگانیک توسعه کنند به طور خودکار در همه فازهای آماده‌سازی اپ و تحویل (تا آنجا که ممکن بوده) چک شدند. محیط‌های کانتینر این امر را تسهیل می‌کنند.
مرحله برنامه‌ریزی: ایمن سازی VCS و عملیات رجیستری. در اوایل چرخه توسعه، توسعه‌دهندگان نرم‌افزار اجزایی را انتخاب می‌کنند، از جمله اجزای کانتینری که قرار است در برنامه مستقر شوند. سیستم امنیتی باید تصاویر رجیستری را برای به روز بودن اسکن و فایل های پیکربندی (IaC مشخصاً Dockerfile) را برای خطاها و تنظیمات ناامن تجزیه و تحلیل کند. تصاویر پایه مورد استفاده در توسعه باید از نظر آسیب‌پذیری‌ها، بدافزارها، اسرار و موارد مشابه اسکن شوند. با انجام این کار، توسعه‌دهندگان به طور قابل توجهی خطرات به خطر افتادن زنجیره تامین را کاهش می‌دهند.
فاز ساخت و تست: امنیت‌دهی به عملیات‌های مستمر یکپارچه‌سازی. در این فاز لازم است تضمین دهیم هیچ محرمانه‌ای، نسخه‌های آسیب‌پذیر آرشیوها یا بدافزار وارد تصویر نشده و همه جنبه‌های امنیت اطلاعات که می‌توانند تحلیل شوند با الزامات رگولاتورها و خود شرکت در هماهنگی هستند. در صورت نقض خط‌مشی‌ها، ساخت اپ موفقیت‌آمیز تکمیل نخواهد شد. این کار با یکپارچه‌سازی سیستم امنیت کانتینر با پلت‌فرم CI/CD میسر می‌شود خواه Jenkins باشد و خواه Gitlab یا CircleCI. همراه با تست استاتیک و پویا امنیت برنامه (AppSec)، این معیار چیزی است که DevSecOps را از سایر رویکردهای توسعه متمایز می‌کند.
مرحله تحویل و استقرار: امنیت در سطح تحویل مداوم. تصاویری که عملیاتی شده‌اند باید هم از نظر یکپارچگی و هم مطابقت کامل با سیاست‌های اتخاذشده اسکن شوند. اگر وضعیت مستلزم یک استثنا باشد (مثلاً یک آسیب‌پذیری منتشر شده است اما هنوز اصلاح نشده است)، باید همیشه مستند و دارای محدودیت زمانی باشد.
مرحله عملیات: حفاظت از ارکستر و کانتینرهای در حال اجرا. راه‌اندازی و کنترل عملیات کانتینرها. این مرحله خطرات مرتبط با آسیب‌پذیری در محیط زمان اجرا یا پیکربندی نادرست آن را به حداقل می‌رساند. مهمتر از آن، تنها در اینجا امکان تشخیص ناهنجاری‌های مختلف در عملکرد برنامه، مانند بار محاسباتی بیش از حد یا ارتباطات غیرمنتظره با سایر کانتینرها و شبکه به عنوان یک کل وجود دارد. این مرحله همچنین بر سفارشی‌سازی امن خود ارکستراتور و همچنین دسترسی به آن نظارت می‌کند. برای امنیت کانتینر، عملیات بومی با ارکستراتور Kubernetes یا OpenShift در اینجا حیاتی است. در عین حال، خود سیستم عامل میزبان نباید بدون محافظت رها شود.
برای کار در این مراحل، خود سیستم امنیتی کانتینر باید چند جزئی باشد. تصویر، عناصر اصلی Kaspersky Container Security و رابطه آنها با پلت‌فرم کانتینری و پلت‌فرم CI/CD را نشان می‌دهد.
چه اقدامات محافظتی برای هر جزء محیط کانتینر باید انجام داد؟
بیایید به فهرست دقیق‌تری از اقدامات حفاظتی که باید برای هر جزء در سیستم کانتینری‌سازی اعمال شود تا امنیت آن را جامع توصیف کنیم، نگاه کنیم.
عنصر مرکزی سیستم امنیتی، اسکن عمیق و جزء به جزء تصاویر است. سیستم امنیتی نیاز دارد با رجیستری‌های کلیدی مانند DockerHu، GitLab Registry یا JFrog Artifactory یکپارچه شود (هم در بخش عمومی و هم سازمانی) و نیز مرتباً تصاویر استفاده‌شده را بنابر خط‌مشی‌های شرکت اسکن کند. هر اسکن داخل فهرست برای خود مهم است اما پروفایل ریسک و مشخصات اپ‌ها شرکت به شرکت متفاوت است پس شاید برای مثال ممکن باشد استفاده از تصاویر با آسیب‌پذیری‌هایی که درجه حیاتی بودن پایینی دارند مجاز خوانده شود. همچنین بسته به خط‌مشی‌های امنیتی وضع‌شده، توصیه‌های CIS Kubernetes یا پایگاه‌های داده مختلف آسیب‌پذیری بتواند کلیدی باشد. تصاویر کانتینری که اسکن نمی‌شوند یا به سادگی برای مدیران پرچم گذاری می‌شوند یا در مراحل بعدی توسعه و استقرار مسدود می‌شوند.
گروه دوم، به همان اندازه مهم و خاص، ابزارهای حفاظتی در مرحله استقرار کانتینر و راه اندازی عمل می‌کنند. اول از همه، کانتینرهایی که با خط مشی ها مطابقت ندارند و در لیست های مورد اعتماد قرار نمی‌گیرند، از اجرای آنها جلوگیری می‌شود. حفاظت از محیط زمان اجرا بدون بازرسی خود ارکستر ناقص است. این به شناسایی خطاهای پیکربندی، عدم انطباق با سیاست‌های امنیتی و تلاش های غیرمجاز برای تغییر پیکربندی کمک می‌کند. هنگامی که کانتینرها در حال اجرا هستند، نظارت بر فعالیت ارکستراتور تشخیص و توقف فعالیت مشکوک را در داخل و بین خوشه ها ممکن می‌سازد.
برخی تسک‌های ماتریس را نمی‌شود به هیچ راهکاری واگذار کرد. اینها شامل انتخاب اولیه سازه سیستم عامل امن و مینیمال می‌شود که برای اجرای ورک‌لودهای کانتینر و نیز تسک مهم گروه‌بندی کانتینر به کار گرفته می‌شوند. برای حفاظت لایه‌ای مناسب و مدیریت راحت، کانتینرهای در حال اجرا باید روی میزبان‌ها گروه‌بندی شوند تا اطلاعات با الزامات امنیتی خاص جدا از اطلاعات با نیازهای امنیتی پایین‌تر پردازش شوند. پیاده‌سازی در اینجا به ارکستراتور مورد استفاده بستگی دارد، اما در هر صورت، در درجه اول تمرینی در ارزیابی ریسک و مدل‌سازی تهدید است.
به طور کلی، وظایف حفاظت از کانتینرهای متعددی وجود دارد، و تلاش برای حل هر یک از آنها به صورت مجزا، با ابزار شخصی یا پیکربندی دستی، باعث افزایش هزینه‌ها می‌شود. از این رو، محیط‌های کانتینری متوسط و بزرگ به راهکارهای امنیتی جامع نیاز دارند که عمیقاً با پلت‌فرم کانتینری‌سازی، خط لوله CI/CD و ابزارهای امنیت اطلاعات مورد استفاده در شرکت ادغام شده‌اند.
کار متخصصین امنیت اطلاعات با موارد زیر ساده می‌شود:
ادغام با SIEM و کانال‌هایی مخصوص اطلاع دادن در مورد مسائل شناسایی‌شده، اسکن منظم و خودکار همه تصاویر در مقابل پایگاه داده به روز آسیب‌پذیری‌ها (مانند NVD)، کارایی پذیرش موقت ریسک‌های امنیت اطلاعات و لاگ پرجزئیات رخدادهای مدیریتی در سیستم محافظت از محیط کانتینرسازی‌شده.
چطور Kaspersky Container Security امنیت را برقرار می‌کند؟
راهکار جامع ما با طراحی از زیرساخت کانتینر محافظت می‌کند: اجزای آن کل چرخه عمر برنامه‌های کاربردی کانتینری را - از توسعه تا عملیات روزمره، ایمن می‌کند. اسکنر اختصاصی با تصاویر کانتینر کار کرده و محافظت ایستا را فراهم می‌کند. عامل KCS که به عنوان یک ظرف جداگانه تحت کنترل ارکستراتور اجرا می‌شود، از میزبان‌ها در محیط زمان اجرا و محیط ارکستراسیون به عنوان یک کل محافظت می‌کند. همزمان، مؤلفه مرکزی Kaspersky Container Security این بخش‌ها را ادغام و یک رابط مدیریتی فراهم می‌کند.
پلت‌فرم با کارایی بالا محافظت قوی برای خوشه‌های K8s با صدها نود ارائه می‌دهد.
اولین نسخه از Kaspersky Container Security که محافظت هسته‌ای برای محیط‌های کانتینر را پیاده‌سازی می‌کند هم‌اکنون موجود است و ما به توسعه محصول و بسط دادن کارایی آن در آینده متعهدیم.
منبع: کسپرسکی آنلاین (ایدکو)
کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.
