تأمين هوية وكيل الذكاء الاصطناعي باستخدام X.509 PKI على AWS

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

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

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

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

نبذة عن Keyfactor EJBCA

توفر Keyfactor منصة لإدارة هوية الأجهزة مح adopted على نطاق واسع تستخدمها أكثر من 1,500 عميل مؤسسي حول العالم، وفقًا لـ Keyfactor. تمتد هذه المؤسسات عبر الخدمات المالية والرعاية الصحية والتصنيع والحكومة. وتساعد Keyfactor المؤسسات على إنشاء الثقة التشفيرية والحفاظ عليها من خلال إدارة دورة حياة الشهادات وعمليات PKI وحوكمة هوية الأجهزة.

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 Relational Database Service (Amazon RDS)) وبنية تحتية لـ PKI تدعم إدارة دورة حياة الشهادات والتسجيل الآلي والإلغاء في الوقت الفعلي. يعالج هذا المزيج فجوة في منظومة وكلاء الذكاء الاصطناعي. فبينما توفر AWS طبقات الحوسبة والتخزين والاستدلال بالذكاء الاصطناعي، توفر Keyfactor طبقة الهوية التشفيرية التي تربط الوكلاء ببيانات اعتماد قابلة للتحقق وقابلة للإلغاء وقصيرة العمر. توضح هذه البنية المرجعية المشتركة، المطورة بالتعاون بين فرق الهندسة في AWS وKeyfactor، كيفية دمج هذه التقنيات. ويمكنك تكييف الأنماط المعروضة هنا مع نشراتك الخاصة متعددة الوكلاء.

نظرة عامة على الحل

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

يوضح الشكل 1 طبقات المصادقة الثلاث وكيفية تدفق بيانات الاعتماد بين المستخدم والوكلاء وخادم أداة MCP. يبين المخطط الفصل بين بيانات اعتماد المستخدم (التي تبقى في تدفق تسجيل الدخول)، وبيانات اعتماد الوكيل (المحددة النطاق لكل وكيل)، وسلسلة التفويض التي تربط بينها.

الشكل 1: معمارية مصادقة PKI ثلاثية الطبقات لأنظمة وكلاء الذكاء الاصطناعي على AWS

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

الشكل 2: تدفق حركة المصادقة من تسجيل دخول المستخدم عبر تفويض الوكيل واستدعاء الأداة وتنظيف الجلسة

خدمات AWS المستخدمة

تشكّل خدمات AWS التالية أساس البنية المرجعية.

شرح الحل

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

المتطلبات الأساسية

• حساب AWS نشط مع صلاحية الوصول إلى Amazon Bedrock وAmazon RDS for MySQL وAmazon SES وAWS Secrets Manager.
• Keycloak 26.2 أو أحدث (مطلوب لتبادل الرموز القياسي RFC 8693. تستخدم الإصدارات السابقة تبادلًا قديمًا غير متوافق).
• Keyfactor EJBCA Enterprise مع REST API V1 ومستجيب OCSP مُهيأ.
• شهادة مسؤول EJBCA API (api-admin.p12) لمصادقة REST API.
• بيئة تطوير Python 3.9+.
• الإلمام بشهادات X.509 وOCSP وOAuth 2.0 وتوقيعات RSA الرقمية ومخازن المفاتيح PKCS#12.

الخطوة 1: تسجيل دخول المستخدم وإصدار الشهادة وإنشاء التفويض

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

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

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

ثالثًا، يوقّع المفتاح الخاص للمستخدم على إقرار تفويض. هذا مستند JSON يسرد بصمات SHA-256 لشهادات الوكلاء الثلاثة جميعها، إلى جانب اسم الموضوع الخاص بالمستخدم ووقت الإصدار وتاريخ الانتهاء. يثبت هذا التفويض أن المستخدم فوّض هؤلاء الوكلاء المحددين بالعمل نيابةً عنه. يحمل الوكلاء هذا التفويض بدلاً من شهادة المستخدم.

# RFC 8693 Token Exchange - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
    original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
    username=username,
    user_cert_pem=user_cert,
    user_key_pem=private_key_pem,
    agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}

الخطوة 2: المظاريف الموقعة بين الوكلاء

عندما يقوم وكيل المنسّق بتوجيه طلب إلى وكيل فرعي (مثل وكيل MySQL أو وكيل Email)، فإنه لا يكتفي بتمرير شهادته للتعريف. بل يقوم بالتوقيع على حِمل الطلب بالكامل، بما في ذلك اسم الأداة والوسائط وطابع زمني وقيمة nonce عشوائية تشفيرياً، باستخدام مفتاحه الخاص مع RSA-PSS-SHA256. ويوفر المغلَّف الموقَّع الناتج إثبات الحيازة (proof-of-possession). ويمكن للوكيل المستقبل أن يتحقق من أن المتصل يحتفظ فعلاً بالمفتاح الخاص المطابق للشهادة المقدَّمة.

يقوم الوكيل المستقبل بست فحوصات للتحقق من صحة المغلَّف قبل معالجة الطلب:

1. التحقق من التوقيع: يثبت أن المرسل يمتلك المفتاح الخاص (إثبات الحيازة).
2. طابع زمني حديث: يجب أن يكون الغلاف ضمن ENVELOPE_MAX_AGE_SECONDS (الافتراضي 60 ثانية) من الوقت الحالي.
3. فرادة الـ nonce: يرفض ReplayCache أي nonce تمت رؤيته سابقًا، مما يمنع إعادة إرسال الطلب.
4. التحقق من سلسلة CA: يجب أن تنتهي شهادة المرسل إلى CA الموثوق (UserCA.pem).
5. مطابقة الدور: يجب أن تكون لاحقة الدور في CN للشهادة ضمن ALLOWED_CALLER_ROLES لهذا الوكيل.
6. فحص الإبطال عبر OCSP: يؤكد الفحص في الوقت الفعلي مقابل EJBCA أن الشهادة لم تُبطل.

إذا احتاج المنسق إلى إعادة إرسال نفس التوجيه (على سبيل المثال، بعد فشل عابر)، فيجب عليه إنشاء غلاف جديد بـ nonce جديد. لا يمكن إعادة استخدام الأغلفة القديمة، حتى من قبل المرسل الشرعي.

# Orchestrator signs request to sub-agent
envelope = sign_envelope(
    payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
    cert_pem=orchestrator_cert_pem,
    private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
    envelope,
    allowed_role="orchestrator-agent",
    ca_cert_pem=ca_pem,
    replay_cache=cache
)

الخطوة 3: مصادقة خادم MCP

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

تسلسل المصادقة:

1. التدقيق في الرمز: طلب POST إلى نقطة النهاية /token/introspect في Keycloak يتحقق من أن الرمز نشط وأن الجمهور (audience) الخاص به يحتوي على "mcp-server". يُرفض رمز جلسة كاملة بدون الجمهور الصحيح.
2. التحقق من الغلاف: يتم التحقق من غلاف الوكيل الموقّع من حيث صحة التوقيع، وطابع زمني حديث، وفرادة الـ nonce، وثقة سلسلة CA، وتطابق الدور (mysql-agentوالتأكد من عدم الإبطال عبر OCSP.
3. التحقق من التفويض: يتم التحقق من صحة إقرار تفويض المستخدم. يثبت التوقيع أن حامل مفتاح المستخدم أذن بهذا التفويض، ويظهر بصمة شهادة الوكيل المستدعي في القائمة المصرح بها، وتُفحص شهادة المستخدم عبر OCSP.
4. التحقق المتقاطع من الهوية: يجب أن يتطابق اسم المستخدم في الرمز، وموضوع التفويض، وبادئة CN في شهادة الوكيل جميعها. هذا يؤكد سلسلة هوية واحدة متسقة من المستخدم حتى تنفيذ الأداة.

# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])

الخطوة 4: منع إعادة الإرسال

كل غلاف موقّع يحمل nonce فريدًا، وهو سلسلة سداسية عشرية عشوائية تشفيريًا بطول 128 بت تُنشأ باستخدام وحدة secrets في بايثون. إن ReplayCache هو مخزن في الذاكرة آمن للتقنيات المتعددة يحفظ كل nonce حتى تنتهي نافذة صلاحيته (2x ENVELOPE_MAX_AGE_SECONDS). إذا ظهر نفس nonce في طلب ثانٍ، يتم رفض الغلاف فورًا، حتى لو كانت التوقيعية صالحة والطابع الزمني حديث.

يكمل التحقق من الطابع الزمني فحص الـ nonce. يجب أن يكون الطابع الزمني للغلاف ضمن ENVELOPE_MAX_AGE_SECONDS (الافتراضي 60 ثانية) من الوقت الحالي للخادم. معًا، تعالج هذه الآليات أربعة سيناريوهات للوصول غير المصرح به:

• إعادة الإرسال المسجلة: يلتقط مستخدم غير مصرح له غلافًا صالحًا ويعيد إرساله لاحقًا. تم رؤية الـ nonce مسبقًا.
• التسليم المتأخر: غلاف يعترض به أثناء النقل يصل بعد نافذة الحداثة. يفشل التحقق من الطابع الزمني.
• إعادة استخدام طلب قديم: غلاف قديم مخزّن مؤقتًا بواسطة وسيط (proxy) يُعاد إرساله. يفشل كلا فحصي الـ nonce والطابع الزمني.
• التزوير المسبق الحساب: لا يستطيع مستخدم غير مصرح له التنبؤ بالـ nonces المستقبلية لتوقيع الأغلفة مسبقًا.

الخطوة 5: توليد المفاتيح من جهة العميل

من الخصائص الأمنية الحرجة لهذه البنية أن المفاتيح الخاصة تُولَّد محليًا ولا تُرسل أبدًا إلى أي نظام خارجي. يولّد التطبيق أزواج مفاتيح RSA 2048+ باستخدام مكتبة Python cryptography. يقوم بإنشاء CSR يحتوي فقط على المفتاح العام ومعلومات الموضوع، ويرسل الـ CSR فقط إلى EJBCA عبر pkcs10enroll نقطة النهاية (endpoint).

يتحقق EJBCA من صحة الـ CSR، ويطبّق ملف تعريف الشهادة (صلاحية 7 أيام، قيود استخدام المفتاح)، ويوقّعه بمفتاح CA، ويعيد الشهادة الصادرة. ثم يجمع التطبيق المفتاح الخاص المحتفظ به محليًا مع الشهادة المُعادة في حاوية PKCS12 ويخزنها في AWS Secrets Manager.

يوفر هذا التصميم عدة خصائص أمنية:

• يُستخدم المفتاح الخاص للمستخدم فقط عند تسجيل الدخول لتوقيع تأكيد التفويض. ولا يُشارك أبدًا مع الوكلاء.
• يُستخدم المفتاح الخاص لكل وكيل من قبل ذلك الوكيل فقط لتوقيع الأغلفة. ولا يُشارك أبدًا بين الوكلاء.
• لا يرى EJBCA المفاتيح الخاصة ولا يخزنها أبدًا. فهو يعمل بشكل خالص كهيئة شهادات.
• إذا تعرض Secrets Manager لوصول غير مصرح به، فإن كلمة مرور PKCS12 (المخزنة بشكل منفصل) تضيف طبقة إضافية.
• يمكن تدوير مادة المفاتيح بشكل مستقل عبر إعادة التسجيل بـ CSR جديد عند تسجيل الدخول التالي.

الخطوة 6: تسجيل الخروج الكامل وإبطال بيانات الاعتماد

يؤدي تسجيل الخروج إلى سلسلة إبطال تُبطل فورًا جميع بيانات الاعتماد القائمة. تؤدي السلسلة إلى عدم بقاء أي بيانات اعتماد صالحة بعد الاكتمال:

1. إبطال شهادة المستخدم في EJBCA: هذا يُبطل فورًا جميع التفويضات القائمة، لأن التحقق من التفويض يفحص شهادة المستخدم عبر OCSP في الوقت الفعلي.
2. إبطال شهادات الوكيل الثلاث جميعها: هذا يُبطل جميع الأظرفة الموقعة القائمة، since envelope verification includes OCSP.
3. حذف جميع الأسرار من AWS Secrets Manager: باستخدام ForceDeleteWithoutRecovery للإزالة الفورية دون نافذة استرداد.
4. إنهاء جلسة Keycloak: يُبطل الرمز ذا النطاق المحدّد عبر نقطة نهاية إنهاء الجلسة.

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

اعتبارات الأمان

تعالج خيارات التصميم في هذه المعمارية عدة خصائص أمنية مهمة لنشر وكلاء متعددين في بيئة الإنتاج.

عزل المفتاح الخاص. يوجد المفتاح الخاص للمستخدم فقط أثناء مسار تسجيل الدخول ويُستخدم حصريًا لتوقيع التفويض. مفاتيح الوكلاء محددة النطاق لكل وكيل ولا تُشارك أبدًا. لا يعبر أي مادة مفاتيح حدود الثقة.

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

رموز محددة النطاق حسب الجمهور. ينتج تبادل الرموز وفق RFC 8693 رمزًا لا يقبله إلا خادم MCP. لا يمكن للرمز ذي النطاق المحدّد الذي يُكشف عن طريق الخطأ المصادقة عبر واجهات Keycloak الإدارية أو خدمات أخرى أو حتى مثيل خادم MCP مختلف.

منع إعادة التشغيل. يؤكد الجمع بين أرقام لمرة واحدة لكل طلب ونافذة نضارة مدتها 60 ثانية أن كل طلب ذو استخدام واحد ومحدد زمنيًا. إن ReplayCache آمن للخيوط ويُنظف ذاتيًا.

تصميم الفشل الآمن. يؤدي كل فشل في التحقق إلى رفض فوري. OCSP غير قابل للوصول: رفض. توقيع غير صالح: رفض. طابع زمني منتهي: رفض. رقم لمرة واحدة معاد تشغيله: رفض. جمهور خاطئ: رفض. لا يوجد تدهور رشيق لعمليات التحقق الأمنية.

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

سلسلة ثقة أحادية الاتجاه. تفرض خريطة ALLOWED_CALLER_ROLES أن orchestrator-agent فقط يمكنه استدعاء mysql-agent و email-agent. لا يمكن للوكلاء الفرعيين استدعاء بعضهم البعض، ولا يمكنهم الاتصال صعودًا بالمنسق، ولا يمكنهم انتحال هوية المستخدم.

اعتبارات حوكمة الذكاء الاصطناعي

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

• حدود الأدوات: يعمل وكيل الذكاء الاصطناعي ضمن قيود صارمة على الأدوات. يمكنه فقط استدعاء أدوات MCP المعرفة مسبقًا (execute_sql, describe_table, list_tables). لا يمكن للوكيل تنفيذ تعليمات برمجية عشوائية أو الوصول إلى موارد خارج نطاق شهادته.
• الإشراف البشري: تُسجَّل جميع إجراءات الوكلاء وتكون قابلة للتدقيق. يلتقط AWS CloudTrail استدعاءات واجهات AWS البرمجية، ويسجل خادم MCP كل استدعاء أداة تم التحقق منه مع سلسلة الهوية الكاملة (المستخدم، الوكيل، الطابع الزمني، والعملية).
• معالجة البيانات: تبقى استعلامات المستخدمين والنتائج داخل حدود الجلسة الموثّقة. يُقيّد الرمز المحدود بالنطاق الجماهيري الوصول إلى البيانات بمثيل خادم MCP المحدد.
• حدود السلوك القائمة على الشهادات: لا يمكن للوكلاء استدعاء الأدوات إلا إذا كانت بحوزتهم شهادات صالحة لها. لا يستطيع وكيل لا يملك mysql-agent شهادة الوصول إلى قاعدة البيانات، بغض النظر عما قد يولّده LLM من تعليمات.

توسيع المعمارية

يمكنك توسيع هذه المعمارية لدعم أنواع وكلاء إضافية والتوسع الأفقي وعزل المستأجرين المتعددين. تصف الفقرات التالية أكثر نقاط التوسع شيوعًا.

• لإضافة أنواع وكلاء جديدة، يكفي أن تضيف مدخلاً في ALLOWED_CALLER_ROLES. تُصدر الشهادات تلقائيًا عند تسجيل الدخول، ويتضمن إثبات التفويض (delegation assertion) ديناميكيًا بصمة الوكيل الجديد. لا تُلزم أي تغييرات على البنية التحتية.
• للتوسع الأفقي، يمكنك نشر مستجيب OCSP الخاص بـ EJBCA في وضع التوافر العالي خلف موازن تحميل. يدعم AWS Secrets Manager معدلات طلبات عالية مناسبة لحمل العمل هذا. ويمكن ReplayCache دعمه بواسطة Amazon ElastiCache للنشرات الموزعة.
• لتقوية المعمارية لبيئة الإنتاج، يمكنك استخدام مفاتيح توقيع EJBCA المدعومة بوحدة أمان الأجهزة (HSM) عبر AWS CloudHSM أو وحدة HSM محلية. يقلّل تثبيت استجابات OCSP (stapling) من زمن تأخير التحقق، وتوفر سجلات Certificate Transparency سجل تدقيق كاملاً للشهادات الصادرة.
• لعمليات النشر متعددة المستأجرين، يمكنك إنشاء جهات إصدار شهادات لكل مستأجر أو جهات تفويض لكل مستأجر لعزل المستأجرين تشفيريًا. وبالاقتران مع حسابات AWS لكل مستأجر، يوفر ذلك عزلًا قويًا بين المستأجرين.
• يمكنك أيضًا تعزيز هوية الوكيل القائمة على PKI بأدوار AWS Identity and Access Management (IAM). استخدم PKI للمصادقة بين الوكلاء و IAM لتفويض خدمات AWS. يعمل النظامان بشكل مستقل، مما يوفر دفاعًا متعدد الطبقات.

التنظيف

لتجنب الرسوم المستمرة، احذف الموارد التي تم إنشاؤها أثناء هذا العرض التوضيحي:

• احذف مثيل Amazon RDS for MySQL (أو مجموعة AWS CloudFormation إذا استخدمت الإعداد المبرمَج).
• احذف جميع الأسرار من AWS Secrets Manager، بما في ذلك شهادات المستخدمين وشهادات الوكلاء ضمن البادئة mcp/ .
• إزالة عنوان البريد الإلكتروني للمرسِل المُوثَّق من Amazon SES.
• إنهاء مثيلات Amazon EC2 التي تشغّل Keycloak وEJBCA (إذا تم نشرها لهذا العرض التوضيحي).
• إلغاء وحذف جميع شهادات الاختبار في EJBCA باستخدام وحدة تحكم المسؤول في EJBCA أو REST API.
• إزالة نطاق Keycloak (mcp-realm) والعملاء المرتبطين به.
• إذا كنت قد استخدمت الإعداد المبرمَج، فشغّل ./scripts/cleanup.sh (Linux) أو ./scripts/cleanup.bat (Windows) لأتمتة هذه الخطوات.

الخلاصة

في هذه المقالة، استعرضنا بنية مرجعية لتأمين اتصالات وكلاء الذكاء الاصطناعي باستخدام X.509 PKI مع Keyfactor EJBCA وخدمات AWS. تعالج هذه البنية الفجوة الأساسية في الهوية لأنظمة الذكاء الاصطناعي متعددة الوكلاء من خلال أربع آليات متكاملة:

• توفر مغلفات الطلبات الموقَّعة إثباتًا تشفيريًا للحيازة في كل استدعاء بين الوكلاء، مما يجعل من الصعب للغاية على طرف غير مصرَّح له انتحال هوية وكيل أو إعادة إرسال طلباته.
• تفصل تأكيدات التفويض الموقَّعة من قِبل المستخدم الترخيص عن مشاركة بيانات الاعتماد. يثبت الوكلاء أنهم مصرَّح لهم بالتصرف نيابةً عن المستخدم دون الاحتفاظ بالمفتاح الخاص للمستخدم أو رمز الجلسة الكامل.
• تحدد رموز RFC 8693 المحددة نطاق الجمهور نطاق التعرض من أي إفصاح عن الرموز إلى حدود خدمة واحدة.
• يؤكد التحقق في الوقت الفعلي من إبطال OCSP أن إبطال بيانات الاعتماد يسري فورًا في جميع أجزاء النظام. إبطال شهادة مستخدم واحد ينهي على الفور جميع صلاحيات الوكيل اللاحقة.

هذه البنية محايدة تجاه الأطر البرمجية. وبينما استعرضناها باستخدام AWS Strands Agents SDK وFastMCP، تنطبق أنماط PKI نفسها على LangChain وCrewAI وAutoGen أو أي إطار آخر متعدد الوكلاء يستخدم بروتوكولات الأدوات. مع تنامي انتشار وكلاء الذكاء الاصطناعي وحصولهم على إمكانية الوصول إلى عمليات أكثر حساسية بشكل متزايد، تنتقل بنية هوية الوكلاء من كونها اختيارية إلى كونها ضرورية.

للبدء مع هذه البنية المرجعية، راجع مستودع GitHub المرفق. لمزيد من المعلومات حول الخدمات المستخدمة، راجع الموارد التالية:

• Amazon Bedrock
• دليل مستخدم Amazon Bedrock
• Keyfactor EJBCA Enterprise
• مواصفات MCP
• AWS Strands Agents SDK
• تقديم Strands Agents، حزمة تطوير برمجيات مفتوحة المصدر لوكلاء الذكاء الاصطناعي (مقالة في مدونة AWS Open Source)

نبذة عن المؤلفين