أنماط تنفيذ TLS المتبادل ‏(mTLS)

يقتصر TLS القياسي على مصادقة الخادم لدى العميل عبر شهادة. أما Mutual TLS (mTLS) فيوسّع ذلك بحيث يقدّم الطرفان الشهادات ويتحقق كل منهما من شهادة الآخر. ويقدّم العميل شهادة العميل بعد أن يطلبها الخادم (عبر CertificateRequest في مصافحة TLS). ويتحقق الخادم من شهادة العميل مقابل CA موثوقة. وتشكّل mTLS أساس الشبكات عديمة الثقة: فبدل الاعتماد على أمان محيط الشبكة، تصادق الخدمات على بعضها تشفيريًا في كل اتصال. وتنفّذ شبكات الخدمات مثل Istio وLinkerd وConsul Connect تقنية mTLS بشفافية بين الخدمات المصغّرة.

توسّع مصافحة mTLS في TLS 1.3 على النحو التالي: بعد ServerHello وشهادة الخادم ورسالة Finished، يرسل الخادم رسالة CertificateRequest التي تحدد جهات إصدار الشهادات المقبولة وخوارزميات التوقيع. ويردّ العميل برسالة Certificate (سلسلة شهادات العميل) ورسالة CertificateVerify (توقيع على سجل المصافحة باستخدام المفتاح الخاص للعميل). ويتحقق الخادم من سلسلة شهادة العميل مقابل مخزن CA الموثوقة لديه، ويتحقق من توقيع CertificateVerify. وإذا نجح التحققان، يصبح الاتصال موثّقًا بشكل متبادل. ولا يستطيع العميل تزوير CertificateVerify من دون المفتاح الخاص المطابق للشهادة.

في بيئات شبكات الخدمات، تُصدر شهادات العملاء عادةً عن طريق CA داخلية. ويستخدم Istio معرّفات SPIFFE ‏(Secure Production Identity Framework for Everyone)‏ SVIDs: إذ تحصل كل حمولة عمل على شهادة تتضمن SPIFFE URI SAN ‏(Subject Alternative Name) مثل spiffe://cluster.local/ns/default/sa/payment-service. وتكون هذه الشهادات قصيرة العمر (24 ساعة)، ويجري تدويرها تلقائيًا بواسطة مستوى التحكم في الشبكة (istiod). أما في mTLS الموجّه للمستخدم (مثل VPN للمؤسسات أو عملاء API)، فقد تصدر الشهادات عن CA مؤسسية بمدد صلاحية أطول، وقد تُسلَّم عبر MDM ‏(Mobile Device Management) إلى أجهزة الموظفين.

يتضمن التحقق من mTLS من جانب الخادم عدة خطوات: (1) التحقق من السلسلة — التحقق من أن سلسلة شهادة العميل تصل إلى CA جذر موثوقة في مخزن CA الخاص بعملاء الخادم. (2) التحقق من مدة الصلاحية — التأكد من أن الشهادة غير منتهية الصلاحية وأنها سارية المفعول. (3) التحقق من الإبطال — التحقق عبر OCSP أو CRL من أن الشهادة لم تُبطَل. (4) مطابقة SAN/CN — استخراج مطالبة الهوية من SAN في الشهادة (SPIFFE URI أو اسم DNS أو البريد الإلكتروني). (5) التفويض — التحقق من أن الهوية التي تمت مصادقتها مخوّلة للوصول إلى المورد المطلوب. وتتطلب الخطوتان 4 و5 منطقًا على مستوى التطبيق يتجاوز إعداد TLS الأساسي.

تلغي الشهادات قصيرة العمر الحاجة إلى الإبطال الصريح: فإذا انتهت صلاحية الشهادة خلال 24 ساعة، تكون فترة تأثير الاختراق محدودة. ويتطلب التدوير ما يلي: (1) التدوير المسبق — إصدار شهادة جديدة قبل انتهاء صلاحية القديمة (التدوير عند بلوغ 80% من مدة الصلاحية). (2) الاستبدال من دون توقف — يجب أن تقبل الخدمة الشهادات القديمة والجديدة معًا خلال فترة الانتقال. (3) إعادة التحميل التدريجية — يجب أن تعيد حزمة TLS تحميل بيانات الاعتماد من دون إسقاط الاتصالات القائمة (nginx: nginx -s reload؛ Envoy: dynamic xDS certificate update). وتعمل SPIFFE Workload API، التي ينفذها SPIRE، على أتمتة تسليم الشهادات وتدويرها عبر واجهة API لمقبس نطاق Unix.

تُنفّذ Istio بروتوكول mTLS بشفافية عبر وكلاء Envoy الجانبيين الذين يُحقنون في كل pod. وتعمل طبقة التحكم (istiod) باعتبارها جهة إصدار شهادات (CA)، باستخدام شهادة وسيطة موقّعة من CA الجذر للشبكة. ويتلقى الوكيل الجانبي لكل pod هوية SPIFFE SVID عبر واجهة برمجة التطبيقات SDS (Secret Discovery Service). وتُهيّئ سياسات PeerAuthentication وضع mTLS: STRICT (يُشترط mTLS)، أو PERMISSIVE (يُقبل كل من mTLS والنص العادي، لأغراض الترحيل)، أو DISABLE. وتحدد موارد AuthorizationPolicy الخدمات التي يُسمح لها بالتواصل، بعد التحقق منها مقابل هوية SPIFFE الموجودة في شهادة العميل. ويطبّق هذا نموذج انعدام الثقة داخل المجموعة من دون إجراء تغييرات على شفرة التطبيق.

بالنسبة إلى عملاء API الخارجيين، يوفر mTLS مصادقة أقوى من مفاتيح API أو رموز OAuth. ويحتفظ العميل بمفتاح خاص في وحدة تخزين آمنة (مثل HSM أو مخزن مفاتيح نظام التشغيل أو مفتاح برمجي محمي بعبارة مرور). وتكون شهادة العميل مثبتة على CA المتوقع لنقطة نهاية API. وتتم مصادقة كل طلب API على مستوى TLS، من دون الحاجة إلى ترويسة Authorization منفصلة. وتطبّق كل من API Shield من Cloudflare وشهادات العميل في AWS API Gateway وmTLS لحسابات الخدمة في Google Cloud هذا النموذج. ويمكن استخدام مفتاح API مخترق من أي مكان، أما المفتاح الخاص لـ mTLS إذا اختُرق، فيلزم كذلك سرقة الجهاز الذي يشغّل العميل.

تواجه عمليات نشر mTLS عدة تحديات تشغيلية. (1) توزيع الشهادات — إيصال شهادات العملاء إلى جميع الخدمات بأمان، خصوصًا في البيئات الديناميكية التي تتوسع فيها pods أو تتقلص. (2) اختراق CA — إذ إن CA الداخلي هدف عالي القيمة؛ وإذا اختُرق، تُبطل جميع شهادات الخدمات. وتخفف وحدات CA المدعومة بـ HSM وCA الجذرية غير المتصلة بالإنترنت من هذا الخطر. (3) تصحيح الأخطاء — تكون حركة مرور mTLS المشفرة غير واضحة لأدوات تصحيح الأخطاء المعتادة؛ لذا يلزم استخدام أدوات مراقبة شبكة الخدمات مثل Jaeger وKiali. (4) توافق الأجهزة الوسيطة — تتسبب وكلاء فحص TLS في تعطيل mTLS ما لم تُهيّأ صراحةً لتمرير شهادات العملاء. (5) حوادث انتهاء صلاحية الشهادات — قد يؤدي فشل التدوير إلى انقطاع كامل للخدمة.

يحدد SPIFFE (Secure Production Identity Framework for Everyone) معيارًا لهوية أعباء العمل باستخدام X.509 SVIDs. أما SPIRE (SPIFFE Runtime Environment) فهو التنفيذ المرجعي. ويعمل SPIRE Server باعتباره سلطة تسجيل وCA. وتعمل SPIRE Agents على كل عقدة، وتتحقق من هوية عبء العمل باستخدام مُصدّقات العقد (AWS instance identity وKubernetes service account JWT وTPM) ومُصدّقات أعباء العمل (Unix PID وبيانات تعريف وقت تشغيل الحاوية). وتسلّم Workload API هويات SVID إلى أعباء العمل عبر مقبس نطاق Unix باستخدام واجهة gRPC بسيطة. ويتكامل SPIRE مع Envoy وNginx وشبكات الخدمات الرئيسية باعتباره مصدرًا للشهادات.

في عمليات نشر mTLS عالية الأمان، ينبغي أن توجد المفاتيح الخاصة في وحدات أمان الأجهزة (HSMs) بدلًا من مخازن المفاتيح البرمجية. وتحمّل مكتبة TLS (OpenSSL وBoringSSL) المفتاح الخاص عبر واجهة PKCS#11، التي تعيد توجيه عمليات التوقيع إلى HSM. ولا يغادر المفتاح الخاص حدود HSM مطلقًا بصيغة نصية واضحة. وتشمل خيارات HSM السحابية AWS CloudHSM وAzure Dedicated HSM وGoogle Cloud HSM. وبالنسبة إلى mTLS على مستوى الأجهزة (IoT والحواسيب المحمولة للمؤسسات)، يوفر TPM 2.0 وظيفة مشابهة؛ إذ يكون مفتاح عميل TLS مرتبطًا بـ TPM، ويتطلب التوقيع تفويض TPM، ما يجعل استخراج المفتاح من جهاز مخترق بالغ الصعوبة.

يتطلب اختبار mTLS أدوات تدعم تقديم شهادة العميل. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. ولاختبار شبكة الخدمات، يعرض istioctl proxy-config secret pod/name الشهادة الحالية ووقت انتهائها. نفّذ kubectl exec داخل pod ثم استخدم curl للوصول إلى نقطة إدارة الوكيل الجانبي (localhost:15000) لفحص المستمعين النشطين وإعداد mTLS الخاص بهم. وينبغي أن يتحقق اختبار التدوير الآلي من بقاء الاتصالات مستقرة أثناء أحداث تدوير الشهادات.

ما الخطوة الإضافية التي يضيفها mTLS مقارنةً بـ TLS القياسي؟

يضيف mTLS مصادقة شهادة العميل إلى TLS، إذ يتحقق الطرفان من شهادتي أحدهما الآخر. وتوفر SPIFFE SVIDs هوية موحّدة لأعباء العمل عبر SPIFFE URIs في حقول SAN للشهادات. وتنفّذ Istio بروتوكول mTLS بشفافية عبر الوكلاء الجانبيين Envoy، مع وضعي STRICT وPERMISSIVE. وتلغي الشهادات قصيرة العمر (24 ساعة) الحاجة إلى الإبطال وتحد من مدة التعرض للاختراق. ويؤتمت SPIRE إصدار الشهادات وتدويرها عبر Workload API. وينبغي أن توجد مفاتيح mTLS الخاصة في HSMs أو TPMs ضمن عمليات النشر عالية الأمان. وتشمل التحديات التشغيلية حماية مفاتيح CA، وتوافق الأجهزة الوسيطة، والتدوير من دون توقف.