Application Security

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

حاشیه‌ی شبکه سازمانی سال‌هاست که از بین رفته است. با پذیرش گسترده کانتینرسازی و میکروسرویس‌ها، برنامه‌ها در محیط‌های متعددی توزیع شده‌اند—در محل، ارائه‌دهندگان ابری و دستگاه‌های لبه. در این منظر، مدل امنیتی سنتی «قلعه و خندق» منسوخ شده است. تکیه بر موقعیت شبکه به عنوان نماینده‌ای برای اعتماد، یک خطای خطرناک است. در عوض، سازمان‌ها باید یک معماری اعتماد صفر (ZTA) را اتخاذ کنند که بر اساس اصل «هرگز اعتماد نکنید، همیشه تأیید کنید» عمل می‌کند.

اصول کلیدی اعتماد صفر در میکروسرویس‌ها

اعتماد صفر یک محصول یا فناوری واحد نیست؛ بلکه یک رویکرد استراتژیک برای ایمن‌سازی منابع ترکیبی است. برای میکروسرویس‌ها، سه ستون حیاتی هستند:

  1. تأیید صریح: احراز هویت و مجوزدهی بر اساس تمام نقاط داده موجود، از جمله هویت کاربر، هویت سرویس، موقعیت، سلامت دستگاه و رفتار سرویس.
  2. استفاده از دسترسی کمترین امتیاز: محدود کردن دسترسی کاربران با دسترسی به‌موقع و به‌اندازه (JIT/JEA)، سیاست‌های تطبیقی مبتنی بر ریسک و توکن‌سازی داده.
  3. فرض نفوذ: به حداقل رساندن شعاع انفجار و بخش‌بندی دسترسی. تأیید رمزنگاری سرتاسری و استفاده از get-analytics برای کسب دید نسبت به نفوذ.

در یک اکوسیستم میکروسرویس، این بدان معناست که سرویس A نمی‌تواند صرفاً به این دلیل که در همان خوشه یا فضای نام قرار دارد، با سرویس B ارتباط برقرار کند. هر درخواست باید صرف‌نظر از مبدأ آن، احراز هویت و مجوزدهی شود.

اجرای هویت: احراز هویت سرویس در برابر سرویس

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

پیاده‌سازی با Istio و Kubernetes

پیاده‌سازی mTLS به صورت دستی در سطح کد پیچیده و مستعد خطا است. در عوض، ما از یک مش سرویس مانند Istio استفاده می‌کنیم که ترافیک شبکه را مداخله کرده و سیاست‌های امنیتی را به طور خودکار اجرا می‌کند. در زیر نمونه‌ای از سیاست PeerAuthentication Istio آورده شده است که mTLS STRICT را برای یک فضای نام خاص اجرا می‌کند.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: sensitive-data
spec:
  mtls:
    mode: STRICT
    portLevelMtls:
      8080:
        mode: PERMISSIVE  # Fallback for legacy services

در این پیکربندی، هر سرویسی که تلاش کند بدون داشتن گواهی‌نامه مشتری معتبر روی پورت 443 یا 8080 در فضای نام sensitive-data ارتباط برقرار کند، رد خواهد شد. این کار یک تونل رمزنگاری شده و احراز هویت شده را برای تمام ترافیک داخلی ایجاد می‌کند.

مجوزدهی با جزئیات دقیق با AuthorizationPolicies

احراز هویت به سوال «شما کی هستید؟» پاسخ می‌دهد. مجوزدهی به سوال «چه کاری مجاز به انجام آن هستید؟» پاسخ می‌دهد. در یک مدل اعتماد صفر، ما باید سیاست‌های کنترل دسترسی با جزئیات دقیق تعریف کنیم. Istio به ما اجازه می‌دهد مشخص کنیم که کدام اصول منبع می‌توانند به کدام بارهای کاری و مسیرهای مقصد دسترسی داشته باشند.

فرض کنید فقط order-service باید بتواند payment-service را فراخوانی کند. ما می‌توانیم این مورد را با استفاده از یک AuthorizationPolicy اجرا کنیم.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-restrictions
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/order-service"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/pay/*"]

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

قابلیت مشاهده: حلقه بازخورد

اعتماد صفر یک راه‌حل تنظیم و فراموش کردن نیست. این نیاز به نظارت مداوم دارد. در یک معماری میکروسرویس، قابلیت مشاهده ستون فقرات امنیت است. با یکپارچه‌سازی با ابزارهایی مانند Prometheus، Grafana یا Jaeger، تیم‌ها می‌توانند جریان‌های ترافیک را تجسم کنند، ناهنجاری‌ها را تشخیص دهند و نفوذهای احتمالی را در زمان واقعی شناسایی کنند.

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

نتیجه‌گیری

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

Share: