برای سالها، مدل امنیتی غالب برای سیستمهای توزیعشده، رویکرد «قلعه و خندق» بود. ما محیط شبکه خود را با فایروالها و سیستمهای تشخیص نفوذ تقویت کردیم، با این اعتماد که هر چیزی در داخل دیوارهای قلعه ایمن است. با این حال، ظهور میکروسرویسها این مرزها را فرسوده کرده است. با وجود صدها سرویس موقتی که به صورت پویا با یکدیگر ارتباط برقرار میکنند، مفهوم یک شبکه داخلی قابل اعتماد دیگر امکانپذیر نیست. یک سرویس داخلی که مورد نفوذ قرار گرفته است، میتواند به همان اندازه ویرانگر باشد که یک نفوذ خارجی.
اینجاست که معماری Zero Trust (ZTA) ضروری میشود. اصل اساسی Zero Trust ساده اما عمیق است: هرگز اعتماد نکنید، همیشه تأیید کنید. در زمینه میکروسرویسها، این بدان معناست که هر تعامل سرویس-به-سرویس را طوری در نظر بگیرید که از یک شبکه غیرقابل اعتماد سرچشمه گرفته است. این پست به بررسی چگونگی پیادهسازی عملی این اصول میپردازد و بر TLS متقابل (mTLS) و فناوریهای Service Mesh تمرکز دارد.
تغییر از شبکه به هویت
در یک برنامه مونولیتیک سنتی، احراز هویت اغلب بر اساس موقعیت شبکه درخواست تکیه داشت. در یک محیط میکروسرویس، سرویسها در نامفضاهای (namespaces)، گرهها (nodes) و احتمالاً ارائهدهندگان ابری مختلف مستقر میشوند. آدرسهای IP موقتی هستند و برای تصمیمگیریهای اعتماد قابل اعتماد نیستند. بنابراین، Zero Trust مرز اعتماد را از شبکه به هویت منتقل میکند.
هر درخواست باید بر اساس هویت فرستنده و گیرنده احراز هویت و مجوزدهی شود. این امر نیازمند یک سیستم مدیریت هویت و دسترسی (IAM) قوی است که به شدت با لایه ارتباطی یکپارچه شده باشد. ما از رویکرد «چه کسی درخواست میدهد؟» (آدرس IP) به سمت «این بار کاری خاص چیست؟» (حساب سرویس/هویت) حرکت میکنیم.
اجرای رمزنگاری با mTLS
مهمترین جزء فنی Zero Trust در میکروسرویسها، اطمینان از رمزنگاری تمام ترافیک در حال انتقال است، حتی بین سرویسهای داخلی. این امر از طریق TLS متقابل (mTLS) حاصل میشود. برخلاف TLS استاندارد که در آن مشتری هویت سرور را تأیید میکند، mTLS از هر دو طرف میخواهد که گواهینامه ارائه دهند. این امر اطمینان حاصل میکند که نه تنها دادهها رمزنگاری شدهاند، بلکه شریک ارتباطی نیز همان کسی است که ادعا میکند.
مدیریت دستی گواهینامهها برای صدها سرویس از نظر عملیاتی کابوس است. اینجاست که یک Service Mesh، مانند Istio یا Linkerd، بینظیر میشود. این ابزار عملیات رمزنگاری را به یک پراکسی جانبی (sidecar proxy) واگذار میکند و به توسعهدهندگان اجازه میدهد کد برنامه را بنویسند بدون اینکه نگران مدیریت چرخه عمر گواهینامهها باشند.
پیادهسازی عملی: تزریق Sidecar در Istio
بیایید یک مثال عملی با استفاده از Istio، یک Service Mesh پیشرو، بررسی کنیم. با فعالسازی تزریق خودکار sidecar، اطمینان حاصل میکنیم که هر pod مستقر شده در نامفضا به طور خودکار یک کانتینر پراکسی به آن تزریق میشود. این پراکسی تمام ترافیک ورودی و خروجی را مداخله میکند، سیاستها را اجرا میکند و mTLS را مدیریت مینماید.
اولین قدم، فعالسازی TLS متقابل در سراسر کل شبکه (mesh) است. این پیکربندی اطمینان حاصل میکند که هیچ ترافیک متنی ساده (plaintext) بین سرویسها مجاز نیست.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICTحالت STRICT حیاتی است. این حالت هر اتصالی را که گواهینامه مشتری معتبر ارائه ندهد، رد میکند. اگر یک سرویس مخرب تلاش کند بدون اعتبارنامههای مناسب با یک سرویس محافظتشده ارتباط برقرار کند، اتصال بلافاصله قطع خواهد شد.
کنترل دسترسی دقیق با سیاستهای مجوز
رمزنگاری به تنهایی کافی نیست؛ ما باید همچنین کنترل کنیم که چه کسی میتواند با چه کسی صحبت کند. Zero Trust از دسترسی کمترین امتیاز (least-privilege) حمایت میکند. صرفاً به این دلیل که یک سرویس میتواند به سرویس دیگری متصل شود، به این معنی نیست که به طور پیشفرض باید این کار را انجام دهد.
ما میتوانیم این مورد را با استفاده از منابع AuthorizationPolicy اجرا کنیم. برای مثال، ممکن است یک سیاست تعریف کنیم که فقط به frontend-service اجازه دسترسی به api-gateway را بدهد، در حالی که دسترسی مستقیم از سایر سرویسها را مسدود میکند.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-frontend-to-gateway
namespace: production
spec:
selector:
matchLabels:
app: api-gateway
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/frontend-service"]در این مثال، فیلد principals به هویت حساب سرویس ارجاع میدهد. این اطمینان حاصل میکند که حتی اگر مهاجم یک pod با همان آدرس IP یا نام میزبان را مورد نفوذ قرار دهد، نمیتواند به دروازه دسترسی یابد مگر اینکه توکنهای هویت معتبر را در اختیار داشته باشد.
نتیجهگیری
پیادهسازی Zero Trust در ارتباطات میکروسرویس یک راهاندازی یکباره نیست، بلکه یک فرآیند مستمر از تأیید هویت و اجرای سیاستهای کمترین امتیاز است. با بهرهگیری از ابزارهایی مانند Service Meshها، توسعهدهندگان میتوانند پیچیدگی امنیت را از کد برنامه به لایه زیرساخت منتقل کنند. این امر به تیمها اجازه میدهد تا برنامههای مقاوم و امنی بسازند که میتوانند هم در برابر حملات خارجی و هم نفوذهای داخلی مقاومت کنند. با رشد زیرساخت شما، به یاد داشته باشید که اعتماد هرگز فرض نمیشود؛ بلکه همیشه از طریق تأیید به دست میآید.