سری وبلاگ KCSA قسمت 1: بررسی اجمالی امنیت بومی Cloud

در بخش اول این مجموعه وبلاگ، با اولین هدف دامنه برای گواهینامه Kubernetes و Cloud Security Associate (KCSA) آشنا خواهید شد.

امنیت ارائه دهنده ابر

وقتی صحبت از امنیت ابری می شود، دو نکته مهم وجود دارد – مسئولیت شما بر عهده چه چیزی است و ارائه دهنده ابر مسئول چه چیزی است. این مدل مسئولیت مشترک نامیده می شود.

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

ارائه دهنده ابر مسئول امنیت سخت افزار اساسی است. به عنوان مثال، سرورهایی که Azure روی آنها اجرا می شود، نگرانی شما نیست. با این حال، قوانین شبکه/فایروال که به ماشین های مجازی شما متصل هستند نگرانی شما هستند.

در مورد آن اینگونه فکر کنید – اگر می توانید به آن دسترسی داشته باشید، این نگرانی شماست. شما نمی توانید وارد یک مرکز داده Azure شوید و سرور را لمس کنید. با این حال، می توانید به Azure وارد شوید و شبکه مناسبی را راه اندازی کنید. این اساس مدل مسئولیت مشترک است.

در زیر دو پیوند برای نحوه تفکر AWS در مورد امنیت و نحوه تفکر Azure در مورد امنیت وجود دارد.

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

امنیت زیرساخت

وقتی صحبت از امنیت زیرساخت ها می شود، مشابه امنیت خوشه ای خواهد بود. ابر مسئول قسمت های خاصی است و شما به عنوان مهندس مسئول قسمت های خاصی هستید.

به عنوان مثال، یکی از بهترین اقدامات زیرساختی در مورد Kubernetes، رمزگذاری Etcd (ذخیره داده Kubernetes) است. اگر خودتان میزبان Kubernetes هستید، می توانید این کار را انجام دهید. اگر Kubernetes در فضای ابری با یک سرویس Kubernetes مدیریت شده میزبانی شود، به Etcd دسترسی نخواهید داشت، به این معنی که نمی توانید آن را ایمن کنید.

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

1. از دسترسی مناسب به سرور API اطمینان حاصل کنید. به‌طور پیش‌فرض، بسیاری از خدمات مدیریت‌شده Kubernetes یک آدرس IP عمومی را در خوشه شما قرار می‌دهند. می توانید این را خاموش کنید.
2. ماشین‌های مجازی که گره‌های کارگر شما روی آن‌ها اجرا می‌شوند را می‌توان از طریق سیاست‌ها و کنترل‌های شبکه محافظت کرد. به یاد داشته باشید، گره‌های کارگر متصل به مجموعه خدمات مدیریت‌شده Kubernetes شما فقط ماشین‌های مجازی هستند و ماشین‌های مجازی قابل کنترل هستند.
3. کمترین امتیاز برای سرور API. همه اعضای تیم شما برای دسترسی به سرور API به مجوزهای RBAC نیاز ندارند و برخی ممکن است فقط به دسترسی خاصی نیاز داشته باشند (مانند فقط خواندن).

امنیت خوشه

هنگامی که به چگونگی ایمن کردن یک خوشه فکر می کنید، آن را به دو قسمت تقسیم می کنید:

• خود خوشه.
• برنامه های کاربردی داخل خوشه

در سطح کلاستر در فضای ابری، چون توسط ابر مدیریت می شود، در واقع همه چیز به دادن مجوزها و دسترسی مناسب برمی گردد. در مورد آن با کمترین امتیاز فکر کنید. همه نیازی به دسترسی برای مقیاس بندی خوشه یا دسترسی به سرور API ندارند. برخی از مهندسان ممکن است فقط به دسترسی خواندن به خوشه های تولید نیاز داشته باشند و سایر مهندسین ممکن است به مجوز کامل برای خوشه های تولید نیاز داشته باشند. امنیت کلاستر در فضای ابری به اطمینان حاصل می شود که هر کسی که دسترسی دارد 1) فقط به دسترسی مناسبی که نیاز دارد و 2) به منابع و خوشه های مناسب دسترسی دارد.

چند پروتکل امنیتی خاص کلاستر دیگر که باید در مورد آنها فکر کنید عبارتند از:

1. محدود کردن استفاده از منابع در خوشه
2. زمینه های امنیتی در مشخصات پاد شما.
3. محدود کردن دسترسی به شبکه
4. ثبت حسابرسی فعال شد.

از منظر کاربردی، به سه بخش تقسیم می شود:

• دسترسی به برنامه.
• آنچه که Pods از دیدگاه شبکه به آن دسترسی دارد.
• رمزگذاری مناسب

اولین قدم این است که به RBAC فکر کنید. چگونه مجوزهای شما به طور فعال برای Pods شما اختصاص داده می شود؟ آیا یک حساب سرویس مناسب برای استقرار Pods شما وجود دارد و آیا مجوزهای مناسبی دارد؟ آیا کاربران/مهندسینی که نیاز به دسترسی به پادهای شما دارند، دسترسی مناسبی دارند و با کمترین امتیاز تعریف شده اند؟

مرحله دوم این است که تأیید کنید Pods شما به چه چیزی دسترسی دارد. به طور پیش فرض، شبکه Pod یک شبکه مسطح است. به این معنی، همه پادها می‌توانند بدون در نظر گرفتن فضای نامی که به طور پیش‌فرض در آن قرار دارند، با سایر پادها صحبت کنند. به همین دلیل، می‌خواهید از داشتن سیاست‌های شبکه مناسب و همچنین اطمینان از اینکه کانتینرهای در حال اجرا در داخل Pods با زمینه‌های امنیتی مناسب پیکربندی شده‌اند، اطمینان حاصل کنید. در کنار آن، یکی از بزرگترین نگرانی های کلی (و نگرانی های امنیتی) محدودیت های منابع است. اجازه ندهید که پادهای شما به هر تعداد که می خواهند به منابع (CPU، حافظه، حافظه) دسترسی داشته باشند. یک محدودیت/درخواست بسته به CPU/حافظه تنظیم کنید.

مرحله سوم اطمینان از رمزگذاری مناسب است. اگر از یک Ingress Controller استفاده می کنید، مطمئن شوید که TLS فعال است. برای شبکه Pod، به یک CNI مبتنی بر امنیت مانند Cilium یا Calico فکر کنید. همچنین می توانید یک Service Mesh را برای قابلیت های mTLS پیاده سازی کنید. برای Kubernetes Secrets، مطمئن شوید که Etcd آنها را به درستی رمزگذاری می کند (زیرا به طور پیش فرض اینطور نیست) یا از یک پلتفرم شخص ثالث مانند HashiCorp Vault استفاده می کنید.

امنیت کانتینر

هنگام ایمن کردن یک Pod در خارج از لایه شبکه، به تصویر کانتینر و خود کانتینر می رسد.

اولین قدم این است که یک تصویر ظرف را به درستی اسکن کنید. قبل از اینکه هر چیزی مستقر شود، همیشه باید اسکن کنید. چند ابزار خوب برای این منظور Kubescape و Checkov هستند. به عنوان مثال، Kubescape تصاویر کانتینر را بر اساس معیارهای CIS اسکن می کند.

گام بعدی امضای تصاویر ظرف است تا قابل اعتماد باشند. شما می توانید در مورد فرآیند کامل اینجا بیشتر بخوانید: https://www.aquasec.com/cloud-native-academy/supply-chain-security/container-image-signing/

مرحله سوم اطمینان از دسترسی مناسب به کانتینرها است. همانطور که چند بار در بالا ذکر شد، مجوزهای مناسب و RBAC باید در بالای ذهن شما باشد.

آخرین مرحله این است که اطمینان حاصل کنید که از یک زمان اجرای کانتینر مناسب با ایزوله استفاده می کنید. این احتمال وجود دارد که شما چیز زیادی از این را در فضای ابری نبینید، اما می توانید از یک API Kubernetes برای مدیریت آن استفاده کنید. https://kubernetes.io/docs/concepts/containers/runtime-class/

امنیت کد

وقتی کد را ایمن می‌کنید، به احتمال زیاد قبل از اینکه به Kubernetes برسد، این کار را انجام می‌دهید. همانطور که در حال انجام تست های واحد، آزمایش های ساختگی، و تست های یکپارچه سازی هستید، اسکن های امنیتی را در برابر کد انجام خواهید داد (خوب، امیدوارم انجام دهید).

یکی از محبوب ترین ابزارهای اسکن امنیتی Sonarqube است. این به احتمال زیاد در امتحان نخواهد بود، اما هنوز هم خوب است بدانید.

برای امنیت کد در مورد Kubernetes، به موارد زیر فکر کنید:

1. دسترسی TLS برای هر ارتباطی که باید از طریق TCP/IP رخ دهد.
2. اطمینان حاصل کنید که برنامه ها فقط به پورت های خاصی که ضروری هستند دسترسی دارند.
3. کد خود را با یک ابزار شخص ثالث (مانند Sonarqube) اسکن کنید و از آنالیز کد استاتیک استفاده کنید.
4. حملات علیه کد خود را در یک محیط کنترل شده با استفاده از کاوش پویا آزمایش کنید. می توانید در مورد چند روش برای انجام این کار در اینجا بیاموزید: https://owasp.org/www-project-zap/