- Zero Trust یک مدل امنیتی است که تبلیغات زیادی را به همراه داشته است – اما علیرغم سر و صدای بازاریابی، ارزش ملموس و فوری برای سازمان های امنیت محور دارد.
- در هسته خود، Zero Trust مجوز را از «یک بار در محیطی تأیید کنید» به «در همه جا، هر زمان تأیید کنید» منتقل می‌کند.
- برای انجام این کار، Zero Trust ما را ملزم می کند که در مفهوم هویت تجدید نظر کنیم و از هویت های مبتنی بر مکان مانند آدرس های IP دور شویم.
- پذیرندگان Kubernetes در هنگام پیاده سازی Zero Trust در لایه شبکه، به لطف مش های سرویس مبتنی بر sidecar، که احراز هویت و مجوز را در دقیق ترین سطح بدون نیاز به تغییرات برنامه ارائه می کنند، دارای مزیت متمایز هستند.
- در حالی که مش های سرویس می توانند کمک کنند، امنیت Kubernetes همچنان یک موضوع پیچیده و ظریف است که نیاز به درک چندین لایه از پشته (stack (دارد.
Zero Trust یک مدل امنیتی قدرتمند است که در خط مقدم شیوه های امنیتی مدرن قرار دارد. بنابراین، Zero Trust دقیقاً چیست، و کاربرد آن برای Kubernetes، به معنای واقعی چیست؟ در این مقاله، ما به بررسی چیستی Zero Trust از منظر مهندسی می‌پردازیم و یک چارچوب اساسی برای درک پیامدهای آن برای اپراتورهای Kubernetes و تیم‌های امنیتی به طور یکسان ایجاد خواهیم کرد.
مقدمه
اگر در حال ساختن نرم‌افزار ابری مدرن هستید، چه با Kubernetes یا چیز دیگری، احتمالاً اصطلاح « Zero Trust » را شنیده‌اید. مدل امنیت Zero Trust به قدری مهم شده است که دولت فدرال ایالات متحده به آن توجه ویژه کرده است: کاخ سفید اخیراً یادداشتی را صادر کرده است که در آن استراتژی Zero Trust فدرال را تعیین می کند که از تمام آژانس های فدرال ایالات متحده می خواهد تا استانداردهای امنیتی ویژه Zero Trust را تا پایان سال مالی 2024 ایجاد کنند; به دنبال آن نیز وزارت دفاع یک معماری مرجع Zero Trust ایجاد کرد. و آژانس امنیت ملی یک راهنمای سخت‌سازی Kubernetes را منتشر کرد که به‌طور خاص بهترین شیوه‌ها امنیت Zero Trust را در Kubernetes توصیف می‌کرد.
با چنین سروصدایی، Zero Trust مطمئناً توجه بازاریابی زیادی را به خود جلب کرده است. اما علیرغم سر و صدا، Zero Trust فقط یک اصطلاح خالی نیست – بلکه نشان دهنده برخی از ایده های عمیق و تحول آفرین برای آینده امنیت است. بنابراین، به طور مشخص، Zero Trust چیست و چرا ناگهان اینقدر مهم است؟ و Zero Trust به طور خاص برای کاربران Kubernetes چه معنایی دارد؟
Zero Trust چیست؟
همانطور که انتظار دارید، Zero Trust اساساً به اعتماد مربوط می شود. این مدلی برای پرداختن به یکی از سؤالات اصلی امنیت است: آیا X مجاز است به Y دسترسی پیدا کند؟ به عبارت دیگر، آیا به X برای دسترسی به Y اعتماد داریم؟
«صفر» در Zero Trust ، البته، کمی اغراق آمیز است. برای اینکه نرم افزار کار کند، بدیهی است که چیزی باید به چیز دیگری اعتماد کند. بنابراین Zero Trust به معنای حذف کامل اعتماد نیست، بلکه کاهش آن به حداقل های ضروری (اصل شناخته شده حداقل دسترسی) و اطمینان از اجرای آن در هر نقطه است.
این ممکن است به نظر عقل سلیم باشد. اما مانند بسیاری از ایده‌های جدید در فناوری، بهترین راه برای درک Zero Trust این است که بفهمیم نسبت به چه چیزی واکنش نشان می‌دهد. Zero Trust عبارت است از رد این ایده که امنیت محیطی کافی است. در مدل امنیت محیطی، شما یک “پوسته سخت” را در اطراف اجزای حساس خود پیاده سازی می کنید. به عنوان مثال، ممکن است یک فایروال در اطراف دیتاسنتر خود داشته باشید که وظیفه دارد ترافیک و کاربران بد را دور نگه دارد. این مدل که گاهی رویکرد قلعه نامیده می‌شود، حس شهودی دارد: دیوارهای قلعه برای دور نگه داشتن کاربران بد وجود دارد. اگر در داخل قلعه هستید، پس طبق تعریف،شما کاربرخوبی هستید.
مدل Zero Trust می گوید که امنیت محیطی دیگر کافی نیست. با توجه به Zero Trust ، حتی در محدوده امنیتی، همچنان باید کاربران، سیستم ها و ترافیک شبکه را غیرقابل اعتماد تلقی کنید. معماری مرجع وزارت دفاع آمریکا آن را به خوبی خلاصه می‌کند:
هیچ کاربر، سیستم، شبکه یا سرویسی که در خارج یا در محدوده امنیتی کار می‌کند قابل اعتماد نیست. در عوض، ما باید هر چیزی و هر کسی را که برای ایجاد دسترسی تلاش می‌کند تأیید کنیم. این یک تغییر پارادایم چشمگیر در فلسفه ای است که چگونه زیرساخت، شبکه‌ها و داده‌های خود را ایمن می‌کنیم، از تأیید یک بار در محیط به تأیید مستمر هر کاربر، دستگاه، برنامه کاربردی و تراکنش
البته، Zero Trust به معنای دور انداختن فایروال های شما نیست – دفاع عمیق جزء مهم هر استراتژی امنیتی است. همچنین به این معنا نیست که ما باید سایر مؤلفه‌های مهم امنیت، مانند ثبت رویداد و مدیریت زنجیره تأمین را نادیده بگیریم. Zero Trust به سادگی از ما می خواهد که بررسی اعتماد خود را از “یک بار در محیط” به “هر زمان، همه جا” منتقل کنیم. با این حال، برای انجام صحیح این کار، باید در برخی از مفروضات اساسی در مورد معنای «اعتماد» و نحوه درک آن تجدید نظر کنیم.
هویت
یکی از فوری ترین پیامدهای Zero Trust این است که نحوه تفکر و تخصیص هویت، به ویژه هویت سیستم را تغییر می دهد.
در مدل محیطی، موقعیت مکانی شما در واقع هویت شماست. اگر در داخل فایروال هستید، به شما اعتماد شده است و اگر خارج از آن هستید، خیر. بنابراین سیستم های مبتنی بر محیط می توانند دسترسی به سیستم های حساس را بر اساس مواردی مانند آدرس IP مشتری امکان پذیر کنند.
در دنیای Zero Trust ، این دیگر کافی نیست. آدرس IP شما فقط نشان دهنده مکان است و بنابراین دیگر برای تعیین اینکه آیا برای دسترسی به یک منبع خاص ،به شما اعتماد شده کافی نیست. در عوض، ما به شکل دیگری از هویت نیاز داریم: یکی از راه‌های اصلی، به حجم کاری، کاربر یا سیستم وابسته است. و این هویت باید به نحوی قابل تأیید باشد که خود نیازی به اعتماد به شبکه نداشته باشد.
این یک نیاز بزرگ با پیامدهای بسیار است. سیستم‌هایی که امنیت شبکه را فراهم می‌کنند اما به شناسه‌هایی از شبکه مانند آدرس‌های IP، مانند IPSec یا Wireguard متکی هستند، که برای Zero Trust کافی نیستند.
خط مشی
با استفاده از مدل جدید هویت خود، اکنون به روشی نیاز داریم تا بفهمیم هر هویتی چه نوع دسترسی دارد. در رویکرد محیطی که در بالا توضیح داده شد، اعطای دسترسی کامل به یک منبع حساس، به طیفی از آدرس‌های IP ، رایج است. به عنوان مثال، ممکن است فیلتر آدرس IP را برای اطمینان از اینکه فقط آدرس های IP از داخل فایروال مجاز به دسترسی به یک سرویس حساس هستند تنظیم کنیم. در Zero Trust ، به جای آن باید حداقل سطح دسترسی لازم را اعمال کنیم. دسترسی به یک منبع باید تا حد امکان ، بر اساس هویت و همچنین سایر عوامل مرتبط، محدود باشد.
در حالی که کد برنامه ما می تواند خود این تصمیمات مجوز را اتخاذ کند، در عوض ما معمولاً آن را با نوعی خط مشی مشخص شده در خارج از برنامه ضبط می کنیم. داشتن یک خط مشی صریح به ما این امکان را می دهد که بدون تغییر کد برنامه، دسترسی را بررسی و تغییر دهیم.
در سرویس اهداف Zero Trust ما، این سیاست ها می توانند بسیار پیچیده باشند. ممکن است سیاستی داشته باشیم که دسترسی به یک سرویس را فقط به سرویس‌های تماس گیرنده محدود می‌کند که نیاز به دسترسی به آن دارند (یعنی استفاده از هویت حجم کاری در هر دو طرف). ما ممکن است آن را بیشتر اصلاح کنیم و فقط به رابط های خاص (مسیرهای HTTP، روش های gRPC) در آن سرویس اجازه دسترسی داشته باشیم. ما ممکن است آن را حتی بیشتر اصلاح کنیم و دسترسی را بر اساس هویت کاربر مسئول درخواست، محدود کنیم. هدف، در همه موارد، حداقل دسترسی است – سیستم ها و داده ها باید فقط در صورت لزوم در دسترس باشند.
اجرا
در نهایت، Zero Trust مستلزم آن است که ما ،هم احراز هویت (تأیید هویت) و هم مجوز (تأیید اینکه خط مشی اجازه عمل را می‌دهد) را در دقیق‌ترین سطح ممکن انجام دهیم. هر سیستمی که اجازه دسترسی به داده ها یا محاسبات را می دهد، باید مرزی امنیتی از محیط به پایین تا اجزای جداگانه اعمال کند.
مشابه سیاست، این اجرا به طور ایده آل و به طور یکنواخت در سراسر پشته انجام می شود. به جای اینکه هر جزء از کد اجرایی سفارشی خود استفاده کند، استفاده از یک لایه اجرایی یکنواخت امکان ممیزی را فراهم و نگرانی های توسعه دهندگان برنامه را از نگرانی های اپراتورها و تیم های امنیتی جدا می کند.
Zero Trust برای Kubernetes
در مواجهه با این الزام که باید هویت را از اصول اولیه بازنگری کنیم، اعتماد را در قالب سیاست‌های بیان خودسرانه تقویت کنیم، و زیرساخت‌های خود را با مکانیسم‌های اجرایی جدید در هر سطح نفوذ دهیم، طبیعی است که لحظه‌ای دچار ترس شویم .و آیا اشاره شد که باید این کار را تا سال 2024 انجام دهیم؟
خبر خوب این است که برای کاربران Kubernetes، حداقل، برخی از جنبه های اتخاذ Zero Trust به طور قابل توجهی آسان تر است. با همه مشکلات و پیچیدگی‌هایش، Kubernetes یک پلتفرم با دامنه صریح، یک مدل امنیتی کاملاً تعریف شده و مکانیسم‌های واضح برای گسترش است. این باعث می شود که این منطقه ،برای پیاده سازی های Zero Trust مفید باشد.
یکی از مستقیم‌ترین راه‌ها برای مقابله با شبکه‌های Zero Trust در Kubernetes استفاده از مش سرویس است. مش سرویس از مفهوم قدرتمند “sidecar” Kubernetes استفاده می کند، که در آن کانتینرهای پلت فرم می توانند به صورت پویا در زمان استقرار در کنار کانتینرهای برنامه ، به عنوان شکلی از اتصال دیرهنگام عملکرد عملیاتی وارد شوند.
مش های سرویس از این رویکرد sidecar برای اضافه کردن پروکسی ها به پادهای برنامه در زمان اجرا و سیم کشی این پروکسی ها برای مدیریت تمام ترافیک ورودی و خروجی استفاده می کنند. این به مش سرویس اجازه می دهد تا ویژگی ها را به گونه ای ارائه دهد که از کد برنامه جدا شده است. این تفکیک نگرانی‌ها بین برنامه و پلتفرم برای ارزش پیشنهادی یک سرویس مش است: البته، این ویژگی‌ها می‌توانند مستقیماً در برنامه پیاده‌سازی شوند، اما با جداسازی آنها، به تیم‌های امنیتی و توسعه‌دهندگان اجازه می‌دهیم تا به طور مستقل از یکدیگر تکرار کنند، در حالی که هنوز در راستای هدف مشترک یک برنامه کاربردی امن اما با امکانات کامل کار می کنند.
از آنجایی که سرویس مش شبکه پیش‌فرض به برنامه را مدیریت می‌کند، در موقعیت مناسبی قرار دارد تا نگرانی‌های Zero Trust را برطرف کند:
- هویت بار کاری را می توان از هویت pod’s در Kubernetes به جای آدرس IP آن استخراج کرد.
- احراز هویت را می توان با بسته بندی اتصالات در TLS متقابل انجام داد، نوعی از TLS که در آن هویت در هر دو طرف اتصال با استفاده از اثبات رمزنگاری تأیید می شود.
- خط مشی مجوز را می توان در اصطلاحات Kubernetes بیان کرد، به عنوان مثال، از طریق تعاریف منابع سفارشی (CRD)، که خط مشی را صریح و از برنامه جدا می کند.
- از همه مهمتر، اجرا در سطح pod های فردی به طور یکنواخت در سراسر پشته (stack) انجام می شود. هر pod احراز هویت و مجوز خود را انجام می دهد، به این معنی که هرگز به شبکه اعتماد نمی شود.
اینها با هم اکثریت اهداف Zero Trust ما را (حداقل برای کلاستر های Kubernetes!) ارائه می‌کنند. ما به جای هویت شبکه، هویت حجم کاری داریم. اجرا در گران‌ترین سطح – pod – و یک روش ثابت و یکنواخت برای اعمال احراز هویت و مجوز در سراسر stack ها، بدون تغییر برنامه.
در چارچوب اصلی، پیاده‌سازی مش سرویس‌های مختلف، مبادلات متفاوتی را ارائه می‌کنند. به عنوان مثال، Linkerd یک شبکه خدمات منبع باز و پروژه فارغ‌التحصیل از Cloud Native Computing Foundation است که یک پیاده‌سازی را ارائه می‌کند که در درجه اول بر سادگی تمرکز دارد و هویت حجم کاری را مستقیماً از حساب‌های خدمات Kubernetes ترسیم می‌کند تا “config zero” را در TLS متقابل پیش فرض، فعال کند. به طور مشابه، میکرو پروکسی‌های مبتنی بر Rust Linkerd یک پیاده‌سازی مینیمالیستی را با Zero Trust ارائه می‌کنند.
البته، فقط افزودن مش سرویس به کلاستر چاره نیست. پس از نصب، کار تعریف، به‌روزرسانی و ارزیابی سیاست‌های مجوز باید انجام شود. اپراتورهای کلاستر باید مراقب باشند تا اطمینان حاصل کنند که همه غلاف های تازه ایجاد شده با جزء کناری آنها جفت می شوند. و البته، خود مش سرویس باید مانند هر نرم افزار روی کلاستر نگهداری، نظارت و به روز نگه داشته شود. در هر صورت، مفید باشد یا خیر، مش سرویس تغییری را از یک ترافیک پیش‌فرض رمزگذاری‌نشده و احراز هویت نشده در کلاستر، به ترافیک پیش‌فرض رمزگذاری‌شده و احراز هویت شده با هویت‌های بار کاری قوی و یک سیستم مجوز غنی ارائه می‌کند – گامی بزرگ به سوی Zero Trust.
نتیجه
Zero Trust یک مدل امنیتی قدرتمند است که در خط مقدم اقدامات امنیتی مدرن قرار دارد. اگر بتوانید سر و صدای بازاریابی پیرامون آن را کاهش دهید، استفاده از Zero Trust مزایای عمیق و مهمی دارد. و در حالی که Zero Trust مستلزم تغییرات اساسی در ایده‌های اصلی مانند هویت است، کاربران Kubernetes اگر بتوانند یک شبکه خدماتی را اتخاذ کنند و از امنیت شبکه صرفاً مبتنی بر محیط به «تأیید مستمر هر کاربر» ،دستگاه، برنامه کاربردی و تراکنش تغییر مسیر دهند، دست‌کم از قدرت بالایی برخوردار هستند.
