لزوم توجه به امنیت در هنگام طراحی
میکروسرویس‌ها قابلیت‌های قدرتمندی در زمینه توسعه انعطاف‌پذیر نرم‌افزارها ارائه کرده‌اند، با این‌حال، موجی از پیچیدگی‌های امنیتی را نیز پدید آورده‌اند. واقعیت این است که تعداد بسیار زیاد نمونه‌ها، کانتینرها، درخواست‌های شبکه و داده‌های بلادرنگ در معماری میکروسرویس، اتخاد یک استراتژی امنیتی کارآمد را دشوار می‌کنند. کار با میکروسرویس‌ها و کانتینرها در محیطی مثل جعبه شن (Sandbox) ساده است، اما مشکلات امنیتی با ورود برنامه‌ها به دنیای واقعی پدیدار می‌شوند. به همین دلیل، قبل از این‌که به سراغ آماده‌سازی میکروسرویس‌های کانتینری بروید، پیشنهاد می‌کنیم به ۱۱ اصل امنیتی که در این مقاله به آن‌ها اشاره می‌کنیم، دقت کنید.
داده‌ها و تامین امنیت آن‌ها
امنیت داده‌ها، حیاتی است. در یک سیستم میکروسرویس، داده‌ها در مکان‌هایی ذخیره‌سازی می‌شوند که به‌طور مکرر در حال انتقال هستند و بخش‌های مختلفی از یک سیستم به آن‌ها دسترسی دارند. بنابراین، در هنگام انتقال یا ذخیره‌سازی داده‌ها باید تمهیدات لازم برای محافظت از آن‌ها را اعمال کنید. بسته به پلتفرم مدیریتی که از آن استفاده می‌کنید، راه‌کارهای مختلفی برای محافظت از داده‌ها وجود دارد. به‌طور مثال، Google Cloud
از ترکیب روش‌های رمزگذاری، مثل پروتکل TLS، BoringSSL و مرجع صدور گواهی (CA) استفاده می‌کند. TLS و لایه سوکت‌های امن (SSL) استانداردهای صنعتی برای تامین امنیت شبکه هستند. گوگل این استانداردهای باز را گسترش داده تا کارآمدی پلتفرم ابری خود را به حداکثر برساند.
علاوه بر این، گوگل از مرجع صدور برای احراز هویت ارتباطات بین سرویسها استفاده می‌کند. مدیریت صحیح اطلاعات حساس مثل رمزهای عبور، توکن‌ها و کلیدهای دسترسی در میکروسرویس‌ها اهمیت زیادی دارد. سیستم‌های مدیریت کانتینر، ویژگی‌های کارآمدی در اختیار تیم‌های توسعه قرار می‌دهند که نظارت دقیق بر اعتبارنامهها یکی از آن‌ها است. این ویژگی‌ها از اصل حداقل امتیاز استفاده می‌کنند و کلیدهای دسترسی منحصر‌به‌فردی ارائه می‌دهند که فقط برای مدت کوتاهی فعال هستند. در نتیجه، اطلاعات امنیتی به‌روز می‌مانند و اگر بخشی از سیستم در معرض خطر قرار بگیرد، این شانس را دارید تا وضعیت سیستم را در حالت پویا نگه دارید. با وجود مزایای بالقوه‌ای که میکروسرویس‌ها ارائه می‌دهند، در صورت استفاده غیراصولی از پارادایم فوق مشکلات امنیتی عمیقی به‌وجود می‌آیند.
چالش‌های امنیتی رایج پیرامون میکروسرویس‌ها
ماهیت توزیع‌شده میکروسرویس‌ها پیچیدگی‌ها و مشکلات امنیتی خاصی را پدید آورده که تیم‌های توسعه چاره‌ای جز رسیدگی به آن‌ها ندارند. از چالش‌های امنیتی مهم پیرامون میکروسرویس‌ها به موارد زیر باید اشاره کرد:
- گستردگی ابعاد یک حمله هکری: تکثیر رابط‌های ارتباطی در یک برنامه کاربردی مبتنی بر میکروسرویس، باعث آسیب‌پذیری سرویسها در برابر حمله‌های هکری می‌شود. به‌طوری‌که هر API و کانال ارتباطی یک بردار حمله بالقوه ایجاد می‌کند که توسعه‌دهندگان باید آسیب‌پذیری‌های آن‌را شناسایی و برطرف کنند.
- عدم تحلیل دقیق گزارش‌ها: یک برنامه کاربردی مبتنی بر میکروسرویس دارای سرویس‌های بدون حالت توزیع‌شده است که از طریق فناوری‌های ناهمگن توسعه می‌یابند. از این‌رو، گزارش‌ها قالب یکسانی ندارند یا به یک روش تولید نمی‌شوند. همچنین، این امکان وجود دارد که این سرویسها در موقعیت‌های جغرافیایی مختلفی پراکنده شده و با یک‌دیگر در تعامل باشند. برای حل مشکل عدم تحلیل دقیق گزارش‌ها، باید سیستم متمرکزی برای جمع‌آوری گزارش‌ها ایجاد شود تا تحلیل‌گران امنیتی بتوانند رویدادهایی را که در پلتفرم‌های مختلف و متفاوت رخ می‌دهند و مرتبط با یک‌دیگر هستند بدون مشکل تحلیل کنند.
- تست ضعیف: توسعه‌دهندگان میکروسرویس‌ها می‌توانند سرویسها را مستقل از یک‌دیگر ایجاد، مستقر و مدیریت کنند، به این معنا که توانایی استقرار نهایی سرویسها بدون آزمایش آن‌ها را دارند، همین مسئله باعث می‌شود تا سرویس‌های آلوده به آسیب‌پذیری‌های امنیتی منتشر شوند. درست است که یکی از بزرگ‌ترین مزایای برنامه‌های کاربردی مبتنی بر میکروسرویس، آزادی عمل در انتشار نسخه‌های مختلفی از یک سرویس و چابکی در روند انجام کارها است، اما انتشار بدون آزمایش مشکلات امنیتی زیادی به‌وجود می‌آورد.
- پیچیدگی مکانیزم تحمل خطا: مکانیزم تحمل خطا در یک برنامه مبتنی بر میکروسرویس در مقایسه با یک برنامه یکپارچه رویکرد پیچیده‌تری دارد. هنگامی که تعداد سرویس‌هایی که از طریق شبکه در ارتباط هستند افزایش می‌یابند، پیچیدگی افزایش می‌یابد و احتمال بروز خطا بیشتر می‌شود. اگر یک میکروسرویس نتواند به‌درستی با خرابی‌ها مقابله کند، ممکن است عملکرد یک بخش از برنامه یا حتا کل برنامه را با مشکل روبه‌رو کرده و آن‌را بی‌ثبات کند.
چرا میکروسرویس‌ها به نگرش ذهنی متفاوتی نیاز دارند؟
میکروسرویس‌ها تا حد زیادی چالش‌های امنیتی مبتنی بر پارادایم‌های برنامه‌نویسی سنتی یا یکپارچه را برطرف می‌کنند، اما چالش‌های خاص خود را دارند. ماهیت اساسی میکروسرویس‌ها بر اساس تجزیه یک برنامه به مولفه‌های جداگانه استوار است. در یک برنامه یکپارچه، همه مولفه‌ها به‌شکل داخلی کار می‌کنند و با هم ارتباط برقرار می‌کنند. با توجه به این‌که مولفه‌های یک برنامه میکروسرویس قابلیت تعامل با محیط‌های درون و برون سازمانی را دارند، نظارت و حفظ امنیت این مدل برنامه‌ها کار ساده‌ای نیست.
چالش‌های حفظ امنیت در معماری میکروسرویس‌ها
در معماری یکپارچه، در بیشتر موارد، یک نقطه شکست وجود دارد که می‌تواند عملکرد یک برنامه کاربردی را مختل کند. در معماری میکروسرویس‌ها، مولفه‌های برنامه جدا از یک‌دیگر عمل می‌کنند، در نتیجه یک رخنه امنیتی به‌سرعت کل برنامه را تحت تاثیر قرار نمی‌دهد. با این وجود، هنوز هم باید انتظار داشته باشید با چالش‌های امنیتی پیچیده‌ای روبه‌رو شوید. یک چالش بزرگ این است که یک سرویس با انواع مختلفی از بردارهای حمله روبه‌رو می‌شود. هنگامی که یک برنامه کاربردی از ده‌ها میکروسرویس مختلف تشکیل شده باشد، سخت است که نظارت دقیقی بر جنبه‌های مختلف برنامه اعمال کنید.
- چالش اول این است که یک برنامه مبتنی بر میکروسرویس می‌تواند از 10 کانتینر استفاده کند؛ این حرف بدین معنا است که شما باید بر ده مولفه مختلف به‌جای یک مولفه واحد نظارت کنید. اگر کانتینرهای مرتبط با برنامه به‌شکل پیوسته تغییر کنند، این چالش نظارتی چند برابر می‌شود.
- چالش دوم محیط ناآشنایی است که قرار است برنامه در آن مستقر شود.
- برخلاف چتر امنیتی مشخص و یکپارچه‌ای که یک دیوارآتش برای یک برنامه واحد ارائه می‌دهد، چنین مرز قطعی‌ای در مورد برنامه‌های میکروسرویس ابرمحور وجود ندارد.
- چالش سوم در مورد احراز هویت و کنترل دسترسی است. با توجه به این‌که ارزیابی محیطی که قرار است نرم‌افزار در آن مستقر شود سخت است، در نتیجه اعمال محدودیت برای کاربرانی که امکان دسترسی به برنامه‌های میکروسرویس را دارند سخت خواهد بود. همچنین، کاربران ممکن است نیاز نداشته باشند به تک تک مولفه‌های برنامه دسترسی داشته باشند، بنابراین، فرآیند تخصیص مجوزها باید به‌شکل دقیقی انجام شود.
یازده اصل کلیدی تامین امنیت میکروسرویس‌ها
هیچ راهکار مشخص و جامعی برای محافظت از برنامه‌های میکروسرویس وجود ندارد، اما می‌توانید با اتخاذ استراتژیهای خاص و پیکربندی درست میکروسرویس‌ها، امنیت آن‌ها را بهبود بخشید. واقعیت این است که بیشتر شرکت‌ها از فرصت مهاجرت به میکروسرویس‌ها به‌دلیل مزایای فراوان آن‌ها مانند استقرار سریع‌تر و افزایش استقلال در توسعه سرویسها استقبال می‌کنند. با این حال، مهاجرت از معماری یکپارچه به معماری میکروسرویس، مسئله نظارت و مدیریت بر معماری برنامه را به‌شکل قابل توجهی تغییر می‌دهد.
1. توجه به امنیت در هنگام طراحی
هنگامی که قصد ایمن‌سازی برنامه‌های مبتنی بر معماری میکروسرویس‌ها را دارید، نباید تنها به‌فکر به‌کارگیری فناوری‌های امنیتی باشید. برای موفقیت در این زمینه، تیم‌های توسعه و عملیات باید بر مبنای اصول دوآپس با یک‌دیگر و کارشناسان بخش امنیت اطلاعات در تعامل باشند. تنها در این صورت است که اطلاعات دقیقی درباره نحوه اجرای درست فرآیندهای امنیتی و کاهش مخاطرات امنیتی به‌دست می‌آید. این رویکرد که به‌عنوان DevSecOps شناخته می‌شود، بر این مسئله تاکید دارد که تیم‌های توسعه نرم‌افزار و عملیات به‌جای این‌که پس از شروع مرحله تولید با کارشناسان امنیتی مشورت کنند باید از همان ابتدای طراحی به تعامل با آن‌ها بپردازند.
2. از داده‌ها محافظت کنید
همیشه از بهترین استراتژیهای دفاعی برای ایمن نگه داشتن اطلاعات استفاده کنید و از پروتکل HTTPS برای ایمن‌سازی داده‌های در حال انتقال و رمزگذاری داده‌هایی که ذخیره‌سازی شده‌اند، استفاده کنید. HTTPS از حریم خصوصی و یکپارچگی داده‌های ارسال‌شده از طریق اینترنت با رمزگذاری اتصال محافظت می‌کند. علاوه بر این، می‌توانید از سرآیند پاسخ HTTP Strict Transport Security استفاده کنید تا به مرورگرها بگویید که فقط از طریق پروتکل HTTPS به نقاط پایانی دسترسی داشته باشند. همچنین، توصیه می‌شود، قبل از انجام هر اقدامی داده‌ها را رمزگذاری کنید و تا زمانی که نیاز ندارید رمزگشایی نکنید تا شانس دسترسی غیرمجاز به داده‌ها را کم کنید.
3. از دروازه واسط برنامه‌نویسی کاربردی (API gateway) استفاده کنید
در یک برنامه کاربردی مبتنی بر طراحی درست میکروسرویس‌ها، کاربران سرویس به‌شکل مستقیم با میکروسرویس‌ها ارتباط برقرار نمی‌کنند. در مقابل، به یک دروازه API که یک نقطه ورودی واحد برای تبادل ترافیک است، متصل می‌شوند و از آن طریق با میکروسرویس‌های مختلف ارتباط برقرار می‌کنند. دروازه API از مکانیزم احراز هویت مبتنی بر توکن برای مدیریت اعتبارنامهها به‌منظور دسترسی به سرویسها و نحوه تعامل سرویسها با داده‌ها استفاده می‌کند. از آن‌جایی که کاربران به‌شکل مستقیم به سرویسها دسترسی ندارند، نمی‌توانند به سوءاستفاده از سرویسها بپردازند. برای بهبود امنیت، پیشنهاد می‌شود دروازه API را پشت دیوارآتش قرار دهید تا یک لایه حفاظتی مضاعف ایجاد شود. همچنین، اطمینان حاصل کنید که همه میکروسرویس‌های مورد استفاده در یک برنامه بر مبنای اصول امنیتی توسعه پیدا کرده‌اند. شکل ۱، نحوه تعریف میکروسرویس‌ها و نحوه قرار دادن آن‌ها در پشت دیوارآتش و دروازه API را نشان می‌دهد.
شکل 1
4. اجرای مکانیزم محدودیت نرخ
محدود کردن نرخ، تضمین می‌کند یک برنامه کاربردی حداکثر n درخواست را در مدت زمان مشخصی می‌پذیرد و پردازش می‌کند. مکانیزم فوق مانع از آن می‌شود تا هکری به یک برنامه متشکل از سرویس‌های مختلف که هر یک اعتبارنامه‌های خاص خود را دارند، دسترسی پیدا کرده و به سوءاستفاده از آن‌ها بپردازد. همچنین، محدود کردن نرخ، یک راهکار قدرتمند برای مقابله با حمله‌های انکار سرویس و عدم دسترسی به سرویسها است. به‌طور معمول، شما باید محدودیت نرخ را در دروازه API پیاده‌سازی کنید.
5. از استراتژی دفاع در عمق استفاده کنید
دفاع در عمق یک استراتژی امنیتی قدرتمند است که در آن یک برنامه کاربردی متشکل از چند لایه کنترل امنیتی است. به‌طوری که سرویس‌های حساس توسط لایه‌های امنیتی مختلفی محافظت می‌شوند، بنابراین یک مهاجم بالقوه که از یکی از میکروسرویس‌های برنامه سوءاستفاده کرده، نمی‌تواند به میکروسرویس دیگر یا لایه‌های دیگر برنامه حمله کند. اصل مهمی که باید به آن دقت کنید این است که نباید به یک مکانیزم امنیتی به‌ظاهر قدرتمند وابسته باشید. از تمام تدابیر امنیتی که در اختیار دارید برای ساخت لایه‌های امنیتی بین میکروسرویس‌های خود و مهاجمان احتمالی استفاده کنید. به‌طور مثال، اگر در گذشته یک دیوارآتش تحت شبکه قدرتمند مستقر کرده‌اید، در ادامه باید از دیگر مکانیزم‌های امنیتی مثل توکن‌ها استفاده کنید، آدرس‌های میکروسرویس‌های حساس را خصوصی نگه دارید و یک لایه نظارتی قوی پیاده‌سازی کنید تا توانایی شناسایی رفتارهای ناهنجار را داشته باشید.
6. تفکیک
تفکیک یکی از اصول اصلی و مهم معماری میکروسرویس‌ها است. هر سرویس باید مستقل از دیگر سرویسها توسعه پیدا کرده، آزمایش، مستقر، مقیاس‌بندی و نگه‌داری شود. این فرآیند تفکیک باید به پایگاه داده
نیز گسترش پیدا کند. به‌طور معمول، هر میکروسرویس، کپی مخصوص‌به‌خود از داده‌ها دارد. این جداسازی تضمین می‌کند که اگر یک میکروسرویس به خطر افتاد، قادر نخواهد بود داده‌های میکروسرویس دیگری را خراب کرده یا افشا کند. مزیت دیگری که روش فوق دارد این است که اگر میکروسرویسی خراب شود، عملکرد دیگر میکروسرویس‌ها را مختل نمی‌کند.
7. ایمن‌سازی باید در سطح کانتینر انجام شود
برنامه‌های میکروسرویس اغلب از کانتینرها برای استقرار استفاده می‌کنند. کانتینرها میزبان ایمیج‌هایی هستند که ممکن است آلوده به آسیب‌پذیری‌های امنیتی باشند. به همین دلیل باید در فواصل منظم زمانی اسکن شوند تا مطمئن شوید ایمیج‌های بدون آلودگی در اختیار دارید. علاوه بر این، برای ایمن‌سازی کانیتنرها بهتر است از اصل حداقل امتیاز پیروی کنید. برای انجام این کار، باید دسترسی به منابع را محدود کرده و استفاده از منابع را مدیریت کنید. به بیان دقیق‌تر، دسترسی به یک منبع تنها باید بر مبنای نیاز انجام شود. علاوه بر این، نباید اطلاعات محرمانه در کانتینر ذخیره‌سازی کنید.
8. همه‌چیز را زیر نظر داشته باشید
توسعه‌دهندگان و کارکنان امنیتی باید در مورد نحوه نظارت دائمی و خودکار بر برنامه‌های مبتنی بر میکروسرویس‌ها برای مقابله با تهدیدات احتمالی، از ابزارهای تخصصی استفاده کنند. برای این منظور، ابزارهای نظارتی، مثل Prometheus و InfluxDB در دسترس تیم‌های توسعه و امنیت قرار دارند که امکان نظارت متمرکز را ارائه می‌دهند. همچنین، اسکن خودکار کدها و بهروزرسانی مداوم کدها ضروری است. تیم‌های دوآپس و امنیت باید برای نظارت بر کدها و جلوگیری از هرگونه دسترسی غیرمجاز به سورس‌‌کدهای برنامه، خط‌مشی‌های تعریف‌شده مشخصی داشته باشند.
9. DevSecOps را پیاده‌سازی کنید
در حالت ایده‌آل، قبل از اتخاذ معماری‌ای که قصد دارید پروژه را بر مبنای آن کامل کنید، مبحث امنیت را به‌دقت ارزیابی کنید. اگر چالش‌های امنیتی را قبل از کدنویسی مورد بررسی قرار دهید، می‌توانید مشکلات امنیتی را به‌درستی ارزیابی کرده و راهکار مناسبی برای حل آن‌ها ارائه کنید. این‌جا است که ایده DevSecOps مطرح می‌شود. با توجه به این‌که، معماری میکروسرویس‌ها در محیط دوآپس رشد کرده است، به بهترین شکل از DevSecOps پشتیبانی می‌کند. لازم به توضیح است که در محیط DevSecOps هر متخصصی ضمن رسیدگی به مسئولیت‌های محوله، وظیفه رسیدگی به یک چالش امنیتی را بر عهده دارد. فرهنگ DevSecOps به این نکته اشاره دارد که همه افراد سازمان در قبال تامین امنیت یک محصول، مسئول هستند.
10. با اتخاذ خط‌مشی‌های امنیتی چندگانه از برنامه محافظت کنید
در فضای رایانش ابری، ارائه‌دهندگانی مثل AWS مسئولیت تامین امنیت و دیوارآتش را بر عهده می‌گیرند. با این حال، سازمان‌ها نباید تنها به اقدامات امنیتی ارائه‌دهنده ابر متکی باشند. شما باید یک استراتژی دفاعی عمیق اتخاذ کنید که چند لایه امنیتی برای جلوگیری از حملات ایجاد کند.
لایه دفاعی به این نکته اشاره دارد که هنگام تعامل محیط داخلی با هرگونه دسترسی خارجی به بهترین شکل از آن محافظت کند. نکته مهمی که برخی برنامه‌نویسان نسبت به آن کم‌توجهی می‌کنند این است که اگر هر یک از مولفه‌های برنامه شما به یک شبکه عمومی متصل شوند، یک شکاف امنیتی ایجاد می‌کنند. به‌طور مثال، در بیشتر موارد کانتینرها از یک مخزن عمومی استفاده می‌کنند که مستعد حمله‌های سایبری هستند.
لایه امنیتی بعدی تشخیص است. تیم‌ها باید یک فرآیند نظارت عادی را برنامه‌ریزی کنند و گزارش‌های تولید‌شده درباره رخدادها را که اشاره به هرگونه تهدید بالقوه برای برنامه کاربردی دارند ارزیابی کنند.
Docker Security Scanning و CoreOS Clair از ابزارهایی هستند که می‌توانند در این زمینه راهگشا باشند.
کنترل دسترسی، به‌عنوان یک سد دفاعی دیگر قادر به محافظت از برنامه‌های کاربردی مبتنی بر میکروسرویس‌ها است. اگرچه ممکن است پیاده‌سازی آن فرآیند سختی باشد، اما تخصیص دقیق و درست مجوزهای کنترل، تضمین می‌کنند که فقط کاربران شناخته‌شده به بخش‌های مناسب دسترسی خواهند داشت.
اگر تصور می‌کنید که رعایت مباحث امنیتی میکروسرویس‌ها به نیروی انسانی بیشتری نیاز دارد، خودکارسازی یک راه‌حل جایگزین خوب در این زمینه است. خوشبختانه، ابزارهای خودکارسازی امنیتی مختلفی برای میکروسرویس‌ها عرضه شده‌اند که توانایی اعمال نظارت خودکار روی کانتینرها را دارند.
11. بهروزرسانی را فراموش نکنید
بهروزرسانی برنامه‌ها یکی از موثرترین راهکارها برای مقابله با تهدیدات امنیتی است. حفاظت طولانی‌مدت از یک برنامه، رمز موفقیت است که نیازمند سخت‌کوشی و بهروزرسانی مداوم برنامه است. مدل‌سازی تهدید، روشی عالی برای ارزیابی وضعیت فعلی برنامه و اطمینان از تطابق آن با استانداردها است. رویکرد فوق به شما امکان می‌دهد چشم‌انداز دقیقی درباره نحوه دفاع از برنامه خود به‌دست آورید. مدل‌سازی تهدید، راهکاری عالی برای مشاهده انواع مختلف تهدیدات و نحوه تاثیر گذاری آن‌ها بر برنامه کاربردی است.
برای دستیابی به چنین سطحی از دفاع از برنامه کاربردی باید از فرهنگ DevSecOps و استراتژی دفاع در عمق استفاده کنید و پایه و اساس برنامه میکروسرویس خود را بر مبنای آن قرار دهید. با اعمال این تغییرات در سازمان، آمادگی لازم برای مقابله با تهدیداتی را که معماری میکروسرویس‌ها با آن روبه‌رو می‌شوند خواهید داشت.
کلام آخر
هنگامی که مبحث امنیت میکروسرویس‌ها را مورد بررسی قرار می‌دهید، معیارهای زیادی وجود دارد که باید در نظر بگیرید. از جمله این معیارها باید به معماری شبکه، پلتفرم کانتینر انتخاب‌شده و محل ذخیره‌سازی و دسترسی به داده‌ها اشاره کرد. درک این مسئله که چگونه این معیارها به اشکال مختلف بر امنیت برنامه‌ها تاثیرگذار هستند، باعث می‌شود مدیریت بر میکروسرویس‌ها و ایمن‌سازی آن‌ها به‌شکل بهتری انجام شود. اگر خط‌مشی‌های مشخصی برای رسیدگی به چالش‌های امنیتی میکروسرویس‌ها نداشته باشید، نکات ناپیدا و ناشناخته باعث می‌شوند هکرها به‌راحتی به سرویسها و ماژول‌های مختلف برنامه نفوذ کنند. در یک محیط اجرایی، کسب‌و‌کارها نمی‌توانند به‌شکل دستی خط‌مشی‌هایی برای تامین امنیت اعمال کنند. در چنین شرایطی از ابزارهایی مثل Project Calico استفاده می‌کنند که خط‌مشی شبکه‌محور دارند. Calico به توسعه‌دهندگان این امکان را می‌دهد که منابع هدف را تعریف کنند و فرآیند نظارت بر این بخش‌ها را خودکارسازی کنند. با افزودن یا حذف موارد جدید و برقراری ارتباط، ابزارهای نظارتی اطمینان می‌دهند که مشکل امنیتی ناشناخته‌ای وجود نخواهد داشت.
یک اکوسیستم کانتینری بالغ باید شامل مجموعه‌ای از ابزارهای امنیتی باشد که از یادگیری ماشین برای کشف و رسیدگی به مسائل امنیتی نوین استفاده می‌کنند. به‌طور معمول، این ابزارها به‌خوبی قابلیت ادغام با یک‌دیگر را دارند و دید جامع از امنیت برنامه‌های میکروسرویس ارائه می‌دهند. همچنین، آن‌ها با تجزیه‌و‌تحلیل خودکار داده‌ها در مقیاس بزرگ و شناسایی الگوهای مشکوک، مانع بروز طیف گسترده‌ای از حمله‌های سایبری می‌شوند. تیم‌های توسعه به ابزارهای امنیتی مبتنی بر یادگیری ماشین، مثل Twistlock و Aqua Security دسترسی دارند که توانایی شناسایی آسیب‌پذیری‌های مستتر در برنامه‌های میکروسرویس را دارند.
