معماری اعتماد صفر: پیاده‌سازی امنیت مبتنی بر هویت در میکروسرویس‌ها

مدل امنیتی سنتی مبتنی بر محیط، که اغلب به عنوان معماری قلعه و خندق تصور می‌شود، منسوخ شده است. در محیط‌های مدرن بومی ابری، بارهای کاری موقتی هستند، مرزهای شبکه محو شده و تهدیدات از خارج و داخل شبکه سرچشمه می‌گیرند. این تغییر نیازمند حرکت به سمت معماری اعتماد صفر (ZTA) است. در این زمینه، «هرگز اعتماد نکن، همیشه تأیید کن» نه تنها یک شعار، بلکه یک الزام مهندسی اساسی است.

از شبکه‌محور به هویت‌محور

به طور تاریخی، کنترل دسترسی بر اساس آدرس‌های IP و مناطق شبکه استوار بود. اگر درخواستی از شبکه محلی شرکت (LAN) سرچشمه می‌گرفت، مورد اعتماد قرار می‌گرفت. در یک محیط میکروسرویس، این رویکرد شکست می‌خورد. کانتینرها به صورت افقی مقیاس‌پذیر هستند، پاد‌های موقتی به طور مداوم IP خود را تغییر می‌دهند و سرویس‌ها در سراسر شبکه‌های عمومی و خصوصی با یکدیگر ارتباط برقرار می‌کنند.

اعتماد صفر تمرکز را از شبکه به هویت موجودی که درخواست را ارسال می‌کند، تغییر می‌دهد. چه آن موجود یک کاربر، یک برنامه یا سرویس دیگری باشد، باید قبل از دسترسی به هرگونه داده، احراز هویت، مجز‌سازی و به طور مداوم اعتبارسنجی شود. این مفهوم که اغلب به عنوان «پراکسی آگاه از هویت» یا «TLS دوطرفه (mTLS)» شناخته می‌شود، تضمین می‌کند که حتی اگر یک سرویس مورد حمله قرار گیرد، مهاجم نمی‌تواند به راحتی به سایر سرویس‌ها نفوذ کند، زیرا مدارک مناسب را ندارد.

نقش مش سرویس

پیاده‌سازی دستی اعتماد صفر برای هر میکروسرویس مستعد خطا و غیرقابل مقیاس‌بندی است. اینجاست که مش‌های سرویس مانند Istio یا Linkerd به عنوان اجزای زیرساخت حیاتی ظاهر می‌شوند. یک مش سرویس لایه زیرساخت اختصاصی برای ارتباط سرویس با سرویس فراهم می‌کند که رمزنگاری، احراز هویت و مجوزدهی را به صورت شفاف مدیریت می‌کند، بدون اینکه نیاز به تغییر در منطق برنامه باشد.

مکانیزم اصلی برای امنیت مبتنی بر هویت در یک مش سرویس، TLS دوطرفه (mTLS) است. برخلاف TLS استاندارد که در آن فقط سرور هویت خود را به مشتری ثابت می‌کند، mTLS از هر دو طرف می‌خواهد که گواهی‌نامه ارائه دهند. در اکوسیستم میکروسرویس‌ها، این گواهی‌نامه‌ها معمولاً توسط یک مرجع صدور گواهی (CA) که توسط صفحه کنترل مش سرویس مدیریت می‌شود، صادر می‌گردند.

پیاده‌سازی عملی با Istio

بیایید نگاهی بیندازیم که چگونه می‌توان سیاست mTLS سخت‌گیرانه را در یک مش سرویس Istio اعمال کرد. به طور پیش‌فرض، بسیاری از خوشه‌ها در حالت «PERMISSIVE» (تسهیل‌گر) عمل می‌کنند که اجازه ترافیک متن ساده و TLS را می‌دهد. برای داشتن یک وضعیت اعتماد صفر واقعی، باید حالت «STRICT» (سخت‌گیرانه) را اعمال کنیم.

پیکربندی YAML زیر یک سیاست PeerAuthentication را تعریف می‌کند که بر کل فضای نام اعمال شده و نیاز دارد تمام ترافیک ورودی و خروجی رمزنگاری و احراز هویت شوند:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

علاوه بر این، برای اطمینان از اینکه سرویس‌ها فقط می‌توانند با همکاران مجاز ارتباط برقرار کنند، یک AuthorizationPolicy پیاده‌سازی می‌کنیم. این کار با رد هرگونه ترافیکی که به صراحت با قوانین تعریف شده مطابقت ندارد، از حرکت جانبی جلوگیری می‌کند.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: production
spec:
  selector:
    matchLabels:
      app: frontend-service
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["cluster.local/ns/default/sa/backend-service"]

در این مثال، frontend-service تنها در صورتی درخواست‌ها را می‌پذیرد که از حساب backend-service سرچشمه گرفته باشند که از طریق یک JWT امضا شده تأیید می‌شود. هر منبع دیگری رد می‌شود، حتی اگر در همان خوشه کوبرنترز باشد.

اعتبارسنجی مداوم و هویت‌های با عمر کوتاه

یک پیاده‌سازی قوی اعتماد صفر فراتر از احراز هویت در مرحله دست‌دادن اولیه می‌رود. این فرآیند شامل اعتبارسنجی مداوم اعتماد است. معماری‌های هویت‌محور مدرن از گواهی‌نامه‌های با عمر کوتاه (مثلاً معتبر برای ۱ تا ۲ ساعت) که توسط یک CA توزیع‌شده صادر می‌شوند، استفاده می‌کنند. این کار دامنه آسیب ناشی از گواهی‌نامه فاش شده را به حداقل می‌رساند. اگر کلید خصوصی نشت کند، به سرعت منقضی می‌شود و پنجره فرصت برای مهاجم را محدود می‌کند.

علاوه بر این، یکپارچه‌سازی با ارائه‌دهندگان هویت خارجی (IdPs) امکان کنترل دسترسی دقیق‌تر را بر اساس ویژگی‌های کاربر، نقش‌ها و زمینه فراهم می‌کند. این موضوع به ویژه برای دروازه‌های API که میکروسرویس‌های داخلی را به مصرف‌کنندگان خارجی نمایش می‌دهند، اهمیت ویژه‌ای دارد.

نتیجه‌گیری

پیاده‌سازی اعتماد صفر در میکروسرویس‌ها یک سفر است، نه یک مقصد. این کار نیازمند تغییر فرهنگی به سمت دفاع در عمق و پذیرش ابزارهای هویت‌محور مانند مش‌های سرویس است. با اعمال mTLS دوطرفه، سیاست‌های مجوزدهی سخت‌گیرانه و اعتبارسنجی‌های با عمر کوتاه، سازمان‌ها می‌توانند سطح حمله خود را به طور قابل توجهی کاهش داده و از حرکت جانبی جلوگیری کنند. با حرکت بیشتر به سمت عصر محاسبات توزیع‌شده، هویت را به عنوان محیط جدید در نظر گرفتن دیگر اختیاری نیست—بلکه برای معماری نرم‌افزار مقاوم ضروری است.