الأمن السيبراني 2 دقائق للقراءة

دليل متعمق للمطورين: تكوين TLS المتبادل (mTLS) بين الخدمات المصغرة للمصادقة والتشفير

PROFSCODE Ekibi 21 يوليو 2026
Paylaş:
تنفيذ اتصال آمن شامل باستخدام TLS المتبادل (mTLS) في معماريات الخدمات المصغرة

مقدمة: أهمية الاتصال الآمن في الخدمات المصغرة

بينما تعمل الخدمات المصغرة على تعزيز قابلية التوسع ومرونة معماريات البرمجيات الحديثة، أصبح ضمان الاتصال الآمن بين الخدمات تحديًا معقدًا. تقليديًا، يقوم TLS أحادي الاتجاه (أمان طبقة النقل) بتشفير الاتصال من العميل إلى الخادم والتحقق من هوية الخادم. ومع ذلك، في معماريات الخدمات المصغرة، فإن مصادقة الطرفين (الخدمات التي تعمل كعميل وخادم) لبعضهما البعض أمر أساسي لتطبيق مبادئ "الثقة المعدومة" (Zero Trust) ومنع هجمات القنوات الجانبية المحتملة.

في هذا الدليل، سنتعلم خطوة بخطوة كيفية تنفيذ TLS المتبادل (mTLS)، وهو أحد أكثر الطرق فعالية لإنشاء مصادقة متبادلة وقوية مع اتصال مشفر شامل بين خدماتك المصغرة. هدفنا ليس فقط تشفير البيانات ولكن أيضًا التحقق رياضيًا من موثوقية كلتا الخدمتين المتواصلتين.

ما هو TLS المتبادل (mTLS) ولماذا هو حاسم للخدمات المصغرة؟

TLS المتبادل (mTLS) هو امتداد لبروتوكول TLS القياسي. في TLS العادي، عندما يتصل عميل (مثل متصفح الويب) بخادم (مثل موقع ويب)، يثبت الخادم هويته للعميل فقط عبر شهادته الرقمية. في mTLS، هذه العملية ثنائية الاتجاه: بعد أن يتحقق العميل من هوية الخادم، يطلب الخادم أيضًا من العميل تقديم شهادته الرقمية الخاصة ويتحقق منها. وبالتالي، يؤكد كل من الخادم والعميل موثوقية بعضهما البعض بشكل متبادل.

يمكن تلخيص الأهمية الحيوية لـ mTLS في معماريات الخدمات المصغرة في عدة نقاط:

  • مصادقة قوية: يوفر آلية مصادقة أقوى بكثير باستخدام شهادات التشفير بدلاً من مجرد المصادقة القائمة على كلمة المرور/مفتاح API.
  • هندسة الثقة المعدومة: تمكن من تطبيق مبادئ "الثقة المعدومة"، حيث لا يُوثق في كل خدمة افتراضيًا، ويتطلب كل اتصال مصادقة وتفويضًا.
  • أمان الشبكة الداخلية: يوفر حماية ضد هجمات القنوات الجانبية أو الوصول غير المصرح به للخدمة داخل الشبكة الداخلية. حتى إذا اخترق مهاجم شبكتك، فسيتم منع وصوله إلى الخدمات المحمية بواسطة mTLS.
  • سلامة البيانات وسريتها: يضمن سرية البيانات وسلامتها عن طريق تشفير جميع الاتصالات بين الخدمات من طرف إلى طرف.

كيف يعمل mTLS: تدفق الاتصال خطوة بخطوة

تتضمن عملية المصافحة (handshake) لـ mTLS الخطوات التالية:

  1. يبدأ العميل الاتصال: يرسل العميل طلب اتصال TLS (Client Hello) إلى الخادم.
  2. يقدم الخادم شهادته: يستجيب الخادم بشهادته الرقمية وسلسلة الشهادات ومجموعات التشفير المفضلة لديه (Server Hello, Certificate, Server Key Exchange). في هذه المرحلة، يرسل الخادم أيضًا طلب شهادة العميل (Certificate Request).
  3. يتحقق العميل من الخادم: يتحقق العميل من هوية الخادم بمقارنة شهادة الخادم بقائمة المراجع المصدقة (CAs) الموثوق بها لديه.
  4. يقدم العميل شهادته: يستجيب العميل بشهادته الرقمية الخاصة وسلسلة الشهادات والتوقيع الرقمي (Certificate, Client Key Exchange, Certificate Verify).
  5. يتحقق الخادم من العميل: يتحقق الخادم من هوية العميل بمقارنة الشهادة التي قدمها العميل بقائمة المراجع المصدقة (CAs) الموثوق بها لديه.
  6. يتم إنشاء اتصال آمن: بعد أن يتحقق الطرفان بنجاح من هويات بعضهما البعض، يتفقان على مفتاح جلسة مشفرة، ويبدأ الاتصال الآمن.

خطوات التنفيذ: إعداد البنية التحتية الخاصة بنا لـ mTLS

في هذا القسم، سنتناول الخطوات العملية بدءًا من إنشاء مرجع مصدق (CA) أساسي ووصولاً إلى إنشاء شهادات للخدمات وتكوينها على Nginx.

1. إنشاء مرجع مصدق (CA)

لننشئ مرجع مصدق جذري (Root CA) ستثق به جميع خدماتنا. سيقوم هذا المرجع المصدق بتوقيع شهادات الخادم والعميل على حد سواء.

# إنشاء مفتاح للمرجع المصدقopenssl genrsa -aes256 -out ca.key 4096# إنشاء شهادة جذرية باستخدام مفتاح المرجع المصدقopenssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/C=TR/ST=Istanbul/L=Istanbul/O=MyCompany/OU=Security/CN=Root CA"

تُنشئ هذه الخطوات ملفي ca.key (المفتاح الخاص للمرجع المصدق) و ca.crt (الشهادة العامة للمرجع المصدق). سيتم قبول ملف ca.crt كملف موثوق به من قبل جميع الخدمات.

2. إنشاء شهادة خادم

الآن لننشئ شهادة لخدمة الخادم لدينا (على سبيل المثال، بوابة API أو خدمة مصغرة) التي سيتم حمايتها بواسطة mTLS.

# إنشاء مفتاح للخادمopenssl genrsa -out server.key 2048# إنشاء طلب توقيع شهادة (CSR) للخادمopenssl req -new -key server.key -out server.csr -subj "/C=TR/ST=Istanbul/L=Istanbul/O=MyCompany/OU=Backend/CN=api.mycompany.com"# توقيع طلب توقيع الشهادة (CSR) بواسطة المرجع المصدق وإنشاء شهادة الخادمopenssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256 -extfile 
subjectAltName=DNS:api.mycompany.com,IP:127.0.0.1

هنا، يتم إنشاء ملفي server.key (المفتاح الخاص بالخادم) و server.crt (شهادة الخادم الموقعة بواسطة المرجع المصدق). تأكد من أن حقل CN (الاسم الشائع) يتطابق مع اسم نطاق الخادم. يُعد subjectAltName (SAN) مهمًا أيضًا.

3. إنشاء شهادة عميل

لننشئ شهادة لخدمة العميل لدينا التي ستتواصل بشكل آمن مع الخادم.

# إنشاء مفتاح للعميلopenssl genrsa -out client.key 2048# إنشاء طلب توقيع شهادة (CSR) للعميلopenssl req -new -key client.key -out client.csr -subj "/C=TR/ST=Istanbul/L=Istanbul/O=MyCompany/OU=Frontend/CN=client-service"# توقيع طلب توقيع الشهادة (CSR) بواسطة المرجع المصدق وإنشاء شهادة العميلopenssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365 -sha256

نتيجة لهذه الخطوات، يتم الحصول على ملفي client.key و client.crt.

4. تكوين mTLS من جانب الخادم في Nginx

لنقم بتكوين Nginx للتحقق من الشهادات من العميل. أضف كتلة server التالية إلى ملف تكوين Nginx الخاص بك:

server {    listen 443 ssl;    server_name api.mycompany.com;    ssl_certificate /etc/nginx/ssl/server.crt;    ssl_certificate_key /etc/nginx/ssl/server.key;    # شهادة المرجع المصدق للتحقق من شهادة العميل    ssl_client_certificate /etc/nginx/ssl/ca.crt;    # طلب والتحقق من شهادة العميل    ssl_verify_client on;    location / {        # إعادة توجيه الطلب بعد التحقق الناجح        proxy_pass http://backend_service;        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header X-Forwarded-Proto $scheme;    }    error_page 495 496 497 =403 /403.html;    location = /403.html {        return 403 "403 Forbidden: Client Certificate Required";    }}

في هذا التكوين، نحدد شهادة المرجع المصدق الموثوق بها باستخدام ssl_client_certificate ونفرض التحقق من شهادة العميل باستخدام ssl_verify_client on. إذا فشل التحقق، سيعيد Nginx خطأ 400 (طلب سيئ) أو 403 بناءً على التكوين الخاص بك.

5. طلب mTLS من جانب العميل باستخدام cURL

لنرسل طلبًا إلى خادم Nginx الخاص بنا باستخدام شهادات العميل:

curl --cert client.crt --key client.key --cacert ca.crt https://api.mycompany.com/secure-endpoint

في هذا الأمر:

  • --cert client.crt: الشهادة العامة للعميل.
  • --key client.key: المفتاح الخاص بالعميل.
  • --cacert ca.crt: شهادة المرجع المصدق التي ستُستخدم للتحقق من شهادة الخادم.

إذا تم إنشاء جميع الشهادات وتكوينها بشكل صحيح، فسيكون الطلب ناجحًا. وإلا، ستتلقى خطأ في مصافحة TLS.

أفضل الممارسات وإجراءات الأمان الإضافية

  • تغيير الشهادات: جدد الشهادات بانتظام قبل انتهاء صلاحيتها. تبسط أدوات إدارة الشهادات التلقائية هذه العملية.
  • أمان المرجع المصدق (CA): قم بتخزين المفتاح الخاص للمرجع المصدق الجذري (Root CA) في بيئة آمنة للغاية وقيد الوصول فقط لعمليات توقيع الشهادات.
  • إلغاء الشهادات: قم بإلغاء الشهادات التي تم اختراقها أو لم تعد مستخدمة باستخدام قوائم إبطال الشهادات (CRL) أو بروتوكول حالة الشهادة عبر الإنترنت (OCSP).
  • مجموعات التشفير القوية: على خوادمك مثل Nginx، قم بتمكين مجموعات تشفير TLS القوية فقط وقم بتعطيل المجموعات الضعيفة.
  • إدارة الشهادات المركزية: في بيئات الخدمات المصغرة الكبيرة، فكر في استخدام حلول متخصصة (مثل بنية PKI التحتية) للإدارة المركزية والآمنة للشهادات والمفاتيح الخاصة.

الخاتمة

يُعد TLS المتبادل (mTLS) آلية قوية تعزز بشكل كبير أمان الاتصال بين الخدمات في معماريات الخدمات المصغرة. باتباع الخطوات الواردة في هذا الدليل، يمكن للمطورين إعداد البنية التحتية الخاصة بهم لـ mTLS وإنشاء قنوات اتصال مشفرة شاملة ومصادقة متبادلة تتوافق مع مبادئ "الثقة المعدومة". تذكر أن الأمان عملية مستمرة، والانتباه المنتظم لإدارة الشهادات وتغييرها وإلغائها أمر بالغ الأهمية للحفاظ على متانة أنظمتك.

العودة إلى المدونة

التعليقات (0)

لا توجد تعليقات بعد. كن أول من يعلق!

إرسال التعليق