الذكاء الاصطناعي

AWS وKeyfactor تؤمّنان هوية وكلاء الذكاء الاصطناعي عبر بنية X.509

تواجه أنظمة الذكاء الاصطناعي متعددة الوكلاء تحديات أمنية كبيرة في إثبات هوية الوكلاء ومنع انتحال الشخصية. تحل هذه المعمارية المشكلة عبر دمج بنية المفاتيح العامة X.509 مع خدمات AWS.

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 20 أكتوبر 2026 · آخر تحديث: 20 أكتوبر 2026 · 5 دقائق قراءة

AWS وKeyfactor تؤمّنان هوية وكلاء الذكاء الاصطناعي عبر بنية X.509 — الصورة: AWS Machine Learning Blog

تحدي هوية وكلاء الذكاء الاصطناعي

مع تزايد وصول وكلاء الذكاء الاصطناعي إلى قواعد البيانات وواجهات برمجة التطبيقات (APIs) والعمليات التجارية الحساسة، أصبح إثبات الهوية المشفرة عبر بنية المفاتيح العامة X.509 (PKI) متطلباً حيوياً. تكمن المشكلة الأساسية في إثبات أي وكيل هو الذي أرسل الطلب، ومنع انتحال الشخصية بين الوكلاء، والتأكد من أن كل وكيل يعمل نيابة عن مستخدم مصرح به فقط. الطرق التقليدية مثل مشاركة مفاتيح API بين المكونات أو تمرير رموز OAuth عبر سلاسل الوكلاء لا تلبي متطلبات الثقة الصفرية التي تتطلبها عمليات النشر المؤسسية.

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

حل معماري مرجعي مشترك

تعرض AWS في مدونتها الرسمية كيفية معالجة هذه الفجوة باستخدام منصة Keyfactor EJBCA مع خدمات AWS. EJBCA هي منصة PKI تدعم النشر عالي التوفر، وأتمتة واجهات برمجة التطبيقات (REST API)، والتحقق من بروتوكول حالة الشهادة عبر الإنترنت (OCSP). تستخدم المعمارية المرجعية أربع آليات أمنية مكملة: أولاً، توفر أظرفة الطلبات الموقعة دليلاً مشفرياً على الحيازة في كل استدعاء للوكيل. ثانياً، تمنح ادعاءات التفويض الموقعة من المستخدم الوكلاء صلاحية العمل دون مشاركة بيانات الاعتماد. ثالثاً، تحد رموز RFC 8693 ذات النطاق المحدد للجمهور من نطاق التعرض في حالة تسريب أي رمز. رابعاً، يضمن فحص إلغاء OCSP الفوري انتشار تغييرات بيانات الاعتماد فوراً عبر جميع الوكلاء.

تستخدم الحل Amazon Bedrock للاستدلال على نماذج اللغة الكبيرة من خلال AWS Strands Agents SDK. بينما تستخدم هذه المعمارية المرجعية قاعدة بيانات كمورد محمي، فإن نمط المصادقة نفسه ينطبق على أي خادم أداة متوافق مع MCP. تتوفر أكواد المصدر الكاملة لجميع الأمثلة في مستودع GitHub المرافق. توفر Keyfactor منصة إدارة هوية الآلات المعتمدة على نطاق واسع، وتستخدمها أكثر من 1500 عميل مؤسسي حول العالم، وتغطي قطاعات الخدمات المالية والرعاية الصحية والتصنيع والحكومة.

دور منصة Keyfactor EJBCA

EJBCA Enterprise هي منصة سلطة الشهادات (CA) وPKI من Keyfactor، مصممة للنشر عالي التوفر وأتمتة REST API. تتوفر كمنتج مؤسسي، وتوفر EJBCA إصدار شهادات X.509، والتحقق من OCSP، وتوزيع قوائم إلغاء الشهادات (CRL)، وإدارة دورة حياة الشهادات الكاملة عبر كل من وحدة تحكم الويب وواجهة REST API. تدعم EJBCA النشر في الموقع، أو في الحاويات، أو على Amazon Elastic Compute Cloud (Amazon EC2).

تجمع الشراكة بين AWS وKeyfactor بين خدمات AWS المُدارة (مثل Amazon Bedrock، وAWS Secrets Manager، وAmazon RDS) مع بنية تحتية لـ PKI تدعم إدارة دورة حياة الشهادات، والتسجيل الآلي، والإلغاء الفوري. يعالج هذا المزيج فجوة في منظومة وكلاء الذكاء الاصطناعي؛ فبينما توفر AWS طبقات الحوسبة والتخزين والاستدلال بالذكاء الاصطناعي، توفر Keyfactor طبقة الهوية المشفرة التي تربط الوكلاء ببيانات اعتماد قابلة للتحقق وقابلة للإلغاء وقصيرة العمر. توضح هذه المعمارية المرجعية المشتركة، التي طورها مهندسو AWS وKeyfactor تعاونياً، كيفية دمج هذه التقنيات.

طبقات المصادقة الثلاثية

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

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

تدفق تسجيل الدخول وإصدار الشهادات

تبدأ العملية بخطوة تسجيل الدخول، حيث يثبت المستخدم هويته عبر ثلاث آليات ثم يفوض الصلاحيات لوكلاء الذكاء الاصطناعي دون مشاركة بيانات اعتماد المستخدم. هذا الفصل حاسم: يتلقى الوكلاء دليلاً على التفويض دون أن يحملوا أبداً المفتاح الخاص للمستخدم أو رمز OAuth الكامل للجلسة. أولاً، يصادق التطبيق المستخدم مقابل Keycloak باستخدام منح كلمة مرور OAuth 2.0، ليحصل على رمز وصول كامل للجلسة ورمز تحديث. فورياً بعد ذلك، يقوم التطبيق بتبادل رمز RFC 8693 للحصول على رمز ذي نطاق مصغر. يكون جمهور هذا الرمز مقيداً بخادم MCP فقط، ويُسلَّم هذا الرمز المحدود للوكلاء. إذا تم تسريبه عن غير قصد، فلا يمكنه الوصول إلى أي خدمة أخرى في المؤسسة.

ثانياً، يولّد التطبيق زوج مفاتيح RSA بحجم 2048 بت أو أكثر محلياً، ويقدم طلب توقيع شهادة (CSR) إلى EJBCA عبر نقطة نهاية REST API الخاصة بـ pkcs10enroll. توقّع EJBCA الطلب وتعيد الشهادة. يجمع التطبيق الشهادة والمفتاح الخاص في حاوية PKCS12 ويخزنها في AWS Secrets Manager. لا يغادر المفتاح الخاص حدود التطبيق أبداً؛ فهو لا يُرسل إلى EJBCA، ولا يُشارك مع الوكلاء، مما يعزز الأمان بشكل كبير.