مدل امنیتی مبتنی بر محیط محصور (Perimeter) در عصر معماریهای بومی ابری فرو ریخته است. با مهاجرت سازمانها به میکروسرویسها، سطح حمله به صورت نمایی گسترش مییابد. ارتباط سرویس با سرویس، که زمانی در شبکه خصوصی ایمن فرض میشد، اکنون به یک برداشت آسیبپذیری حیاتی تبدیل شده است. پیادهسازی معماری Zero Trust دیگر یک انتخاب نیست؛ بلکه یک ضرورت است. این پست بررسی میکند که چگونه میتوان با پیادهسازی Mutual TLS (mTLS) برای احراز هویت و سیاستهای مجوز پویا برای کنترل دسترسی دقیق، Zero Trust را در میکروسرویسها اعمال کرد.
چرا Zero Trust برای میکروسرویسها اهمیت دارد؟
در محیط میکروسرویسها، سرویسها در چندین گره توزیع شدهاند و اغلب از خوشهها یا ابرهای مختلف عبور میکنند. فرض اینکه «داخل شبکه به معنای ایمنی است» کشنده است. اگر مهاجم بتواند یک پاد (Pod) را نفوذ کند، میتواند به صورت افقی حرکت کرده و به پایگاههای داده حساس یا سایر سرویسهای حیاتی دسترسی پیدا کند. Zero Trust بر اصل «هرگز اعتماد نکن، همیشه تأیید کن» عمل میکند. هر درخواست، صرفنظر از مبدأ، باید قبل از اعطای دسترسی، احراز هویت و مجوزدهی شود.
دو ستون این استراتژی در زمینه سرویس مش (Service Mesh)، هویت (که از طریق mTLS اثبات میشود) و سیاست (که از طریق قوانین پویا اعمال میشود) هستند. بدون mTLS، سرویسها نمیتوانند هویت طرف مقابل را به صورت رمزنگاری شده تأیید کنند. بدون مجوزدهی پویا، حتی سرویسهای تأیید شده ممکن است امتیازات بیش از حد داشته باشند.
پیادهسازی Mutual TLS (mTLS)
mTLS با الزام به ارائه گواهینامه توسط هر دو طرف (کلاینت و سرور)، فرآیند دستدادن TLS استاندارد را گسترش میدهد. این کار تضمین میکند که هویت هر دو طرف با استفاده از یک مرجع گواهی مورد اعتماد (CA) تأیید میشود. در محیط کوبرنیتس (Kubernetes)، این امر معمولاً توسط یک سرویس مش مانند Istio یا Linkerd مدیریت میشود که چرخش و تزریق خودکار گواهینامهها را انجام میدهد.
پیکربندی mTLS در Istio شامل تعریف یک سیاست PeerAuthentication است. این اطمینان حاصل میکند که تنها درخواستهای دارای گواهینامه معتبر پذیرفته میشوند.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: "default"
namespace: "prod-ns"
spec:
mtls:
mode: STRICT
# این تضمین میکند که تمام ترافیک ورودی به این نامفضا باید رمزنگاری شده باشد
# و هر دو طرف باید از طریق mTLS احراز هویت شوند.پس از اعمال mTLS، هویت سرویس مستقیماً از نام عمومی (CN) یا نام جایگزین موضوع (SAN) در گواهینامه کلاینت استخراج میشود. به عنوان مثال، یک درخواست از payment-service گواهینامهای را حمل میکند که هویت در آن به صراحت ذکر شده است، که خطر جعل IP را از بین میبرد.
سیاستهای مجوزدهی پویا
در حالی که mTLS تأیید میکند که «چه کسی» درخواست را ارسال میکند، تعریف نمیکند که «چه کاری» مجاز به انجام آن هستند. یک payment-service ممکن است نیاز به تماس با inventory-service داشته باشد، اما هرگز نباید به admin-service دسترسی داشته باشد. اینجاست که سیاستهای مجوزدهی وارد عمل میشوند. به جای لیستهای سفید ایستا، سیاستهای پویا امکان کنترل دقیق بر اساس هویت سرویس، نامفضاهای مبدأ و حتی ویژگیهای خاص در زمینه درخواست را فراهم میکنند.
با استفاده از AuthorizationPolicy، میتوانید قوانینی را تعریف کنید که ترافیک را به شدت محدود کنند. برای مثال، میتوانید محدودیت را برای api-gateway اعمال کنید تا تنها روشها و مسیرهای HTTP خاصی را مجاز بداند.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "allow-payment-to-inventory"
namespace: "prod-ns"
spec:
selector:
matchLabels:
app: inventory-service
action: ALLOW
rules:
- from:
- source:
principals:
- "cluster.local/ns/prod-ns/ sa/payment-service"
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/v1/inventory/*"]این پیکربندی تضمین میکند که حتی اگر payment-service نفوذ شود، مهاجم نمیتواند به سایر بخشهای inventory-service یا هر سرویس دیگری که قانون مجوزدهی صریحی ندارد، دسترسی پیدا کند. سیاست در گیتوی ورودی یا پراکسی سایدکار قبل از اینکه ترافیک هرگز به کد برنامه برسد، ارزیابی میشود.
ملاحظات و چالشهای عملی
پیادهسازی این معماری نیازمند برنامهریزی دقیق است. اولین چالش، مدیریت چرخه عمر گواهینامهها است. اگر چرخش گواهینامهها خودکار نباشد، سرویسها از دسترس خارج میشوند. دوم، عیبیابی مشکلات اتصال میتواند دشوار باشد وقتی همه چیز رمزنگاری شده است؛ اطمینان حاصل کنید که خط لوله لاگگیری شما، متادیتای سرویس مش را ثبت میکند. در نهایت، سیاستهای پویا میتوانند پیچیده شوند. با یک پیشفرض «مسدود کردن همه» شروع کنید و به تدریج مسیرهای ترافیک شناخته شده و معتبر را در لیست سفید قرار دهید تا از خرابیهای تصادفی جلوگیری شود.
نتیجهگیری
امنسازی میکروسرویسها نیازمند تغییر از دفاع محیطی به امنیت مبتنی بر هویت است. با ترکیب Mutual TLS برای احراز هویت قوی هویت سرویس و سیاستهای مجوزدهی پویا برای کنترل دسترسی دقیق، سازمانها میتوانند به طور مؤثر یک معماری Zero Trust را پیادهسازی کنند. این رویکرد به طور قابل توجهی شعاع انفجار احتمالی نقضها را کاهش میدهد و اطمینان حاصل میکند که ارتباط سرویس با سرویس در یک فضای دیجیتال در حال خصمانه شدن، امن باقی میماند. با رشد زیرساخت شما، بهروز نگه داشتن این سیاستها کلید حفظ یک وضعیت امنیتی مقاوم است.