إن جدار الحماية الأمني التقليدي هو أثر من عصور البنية الأحادية (Monolithic). في معماريات السحابة الأصلية الحديثة، حيث يتم تفكيك التطبيقات إلى مئات الخدمات المصغرة المؤقتة، فإن مفهوم "الشبكة الداخلية الموثوقة" قد تلاشى فعليًا. هنا تأتي الثقة الصفرية (Zero Trust): إطار عمل أمني قائم على مبدأ "لا تثق أبدًا، دائمًا تحقق". بينما شاع استخدام شبكات الخدمات مثل Istio و Linkerd لتأمين الاتصال بين الخدمات باستخدام الأمان المتبادل لطبقة النقل (mTLS) كافتراضي، فإن الاعتماد على التشفير وحده لم يعد كافيًا لضمان وضع أمني قوي للثقة الصفرية.
يستكشف هذا المقال التحول الحاسم من الأمن المعتمد على الشبكة إلى الأمن المعتمد على الهوية. سنفحص لماذا يُعد mTLS مجرد أساس، وكيف يعد تنفيذ التحكم في الوصول القائم على الهوية (IBAC) بدقة أمرًا جوهريًا لتأمين التطبيقات الموزعة الحديثة.
قيود mTLS في معمارية الثقة الصفرية
لا شك أن mTLS هو العمود الفقري للاتصال الآمن بين الخدمات المصغرة. فهو يضمن مصادقة العميل والخادم لبعضهما البعض باستخدام الشهادات، مما يخلق نفقًا مشفرًا يمنع التنصت وهجمات الرجل في المنتصف. ومع ذلك، فإن mTLS يصدق في المقام الأول من موجود في نقطة نهاية الشبكة (instance الخدمة)، وليس ماذا يُسمح لتلك الخدمة بفعله.
تخيل سيناريو حيث ينجح طرف خبيث في اختراق خدمة واجهة أمامية، أو حيث يمنح مطور عن طريق الخطأ خدمة صلاحيات مفرطة. بمجرد دخول الخدمة المخترقة إلى الشبكة والحصول على شهادات سارية المفعول، يمكنها التواصل مع الخدمات الأخرى عبر نفق mTLS. بدون ضوابط إضافية، يكتسب المهاجم فعليًا هوية خدمة الواجهة الأمامية ويمكنه الوصول إلى أي مورد خلفي كانت الواجهة الأمامية مسموحًا لها بالوصول إليه. هذه هي مشكلة "الشبكة المسطحة" التي لا يمكن لـ mTLS حلها بمفرده.
التحكم في الوصول القائم على الهوية: الطبقة التالية
لتحقيق الثقة الصفرية الحقيقية، يجب أن نتجاوز المصادقة الشبكية إلى التفويض القائم على الهوية. في سياق الخدمات المصغرة، تمتد الهوية لتشمل ما هو أبعد من بيانات اعتماد المستخدم؛ فهي تشمل هوية الخدمة، وسياق الطلب، وبيانات عمل العمل (workload metadata).
يتطلب التحكم الفعال في الوصول القائم على الهوية:
- هوية العمل (Workload Identity): يتم التعامل مع كل حاوية أو Pod ككيان فريد له هوية محددة.
- سياسات واعية بالسياق (Context-Aware Policies): لا تستند قرارات الوصول إلى المصدر والوجهة فقط، بل أيضًا إلى العملية، وطريقة HTTP، وحتى سمات الحمولة (payload attributes).
- بيانات اعتماد قصيرة الأجل: منع تجميع بيانات الاعتماد من خلال استخدام رموز مؤقتة بدلاً من حسابات الخدمة طويلة الأجل.
تفرض شبكات الخدمات الحديثة هذه السياسات عبر وكلاء الجوار (sidecar proxies) الذين يعترضون حركة المرور. بدلاً من السماح بجميع حركة المرور داخل النطاق (namespace)، يقوم الوكيل بتقييم الطلب مقابل سياسة صارمة تحددها الإدارة.
تنفيذ السياسات الدقيقة باستخدام OPA والتفويض
بينما توفر شبكات الخدمات طبقة النقل، فإن محركات السياسات مفتوحة المصدر مثل وكيل السياسة المفتوح (OPA) المدمج مع Kubernetes يتيح التفويض الديناميكي القائم على الهوية. يتيح هذا النهج تعريف قواعد معقدة تتجاوز بكثير قوائم السماح/الرفض البسيطة.
على سبيل المثال، قد تسمح لـ payment-service باستدعاء inventory-service فقط عندما تكون طريقة HTTP هي GET ويأتي الطلب من order-processor في النطاق production، بينما يتم رفض طلبات POST أو الطلبات القادمة من staging.
إليك مثال لكيفية ظهور مثل هذه السياسة في مورد Kubernetes AuthorizationRequest الذي يتعامل معه وكيل جانبي من OPA أو امتداد لشبكة الخدمات:
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
metadata:
name: service-mesh-authorization
spec:
user: system:serviceaccount:payments:payment-service
groups:
- system:authenticated
resourceAttributes:
namespace: inventory
verb: get
resource: pods
name: inventory-data-pod
status:
allowed: true
reason: "Policy: payment-service can GET inventory pods only in production namespace"
في شبكة الخدمات الإنتاجية، يتم غالبًا ترجمة هذا المنطق إلى فلاتر Envoy أو سياسات الشبكة الأصلية (مثل AuthorizationPolicy الخاص بـ Istio)، مما يضمن قيام وكيل الجوار (sidecar proxy) بإسقاط الحزمة فورًا إذا لم تتطابق الهوية والسياق مع السياسة.
التحديات العملية وأفضل الممارسات
إن تنفيذ التحكم في الوصول القائم على الهوية ليس خاليًا من التحديات. تتطلب تعقيدات إدارة الهويات لمئات الخدمات المؤقتة سلطة إصدار شهادات (CA) قوية وإدارة دورة حياة آلية. تظهر أدوات مثل SPIFFE (SPIFFE IDs) و SPIRE كمعايير حاسمة لإصدار وإدارة هذه الهويات قصيرة الأجل.
علاوة على ذلك، يجب على المطورين تبني عقلية "الرفض كافتراضي". عند نشر خدمة مصغرة جديدة، افترض أنها تملك صفر صلاحيات حتى يتم منحها صراحة. غالبًا ما يتطلب هذا إعادة هيكلة كبيرة لأنظمة CI/CD الحالية لضمان أن تكون السياسات خاضعة للتحكم في الإصدارات ويتم اختبارها جنبًا إلى جنب مع كود التطبيق.
الخاتمة
تعد الثقة الصفرية في الخدمات المصغرة رحلة وليست وجهة. بينما يوفر mTLS طبقة التشفير الأساسية ومصادقة الشبكة، فهو مجرد الخطوة الأولى. يعتمد الأمن الحقيقي على التحكم في الوصول القائم على الهوية الذي يتحقق من نية وسياق كل طلب.
من خلال دمج شبكات الخدمات مع محركات السياسات الديناميكية وهويات العمل الموحدة، يمكن للمنظمات بناء وضع أمني مرن حيث لا يمكن لخدمة واحدة مخترقة أن تتسبب في انهيار شامل للاختراق. بالنسبة للمطورين من المستوى المتوسط والمتقدم، يجب أن ينصب التركيز الآن من مجرد تمكين mTLS إلى التعريف الصارم وإنفاذ من يمكنه فعل ماذا، وتحت أي ظروف.