خادم MCP لديك آمن. لكن سجل المعاملات الذي يستند إليه ليس كذلك.

في مقال نُشر مؤخرًا هنا على Unite.AI، عرض Gil Feig ست ممارسات مثلى لبناء خادم MCP آمن. وهي نصائح سليمة، وينبغي لكل من يطرح خادم MCP أن يتبعها. ونصيحته بمنح كل تكامل «دورًا خاصًا به، محدد الصلاحيات بدقة ولا يتجاوز الأذونات المطلوبة» صائبة تمامًا. لكنها تفترض أيضًا أن النظام في الطرف الآخر يتيح أدوارًا محددة بدقة. وهذا يكشف عن افتراض أوسع نادرًا ما يُصرَّح به: أن بالإمكان تأمين الأنظمة التي يتصل بها الخادم وفق المستوى نفسه.

لكن ذلك لا يتيسر غالبًا في برمجيات الأعمال. أدير فريق الهندسة المسؤول عن طبقة تكامل تتصل بـ32 نظامًا للمحاسبة وتخطيط موارد المؤسسات، مع خادم MCP اختياري في أعلاها. ونرى باستمرار وكلاءً موثَّقين جيدًا، ومحدَّدي الصلاحيات بدقة، ومسجَّلين على نحو جيد من جانبنا، يكتبون في أنظمة لا تملك أي وسيلة لمعرفة أن وكيلًا شارك في الأمر أصلًا.

يتناول هذا المقال النصف الآخر من المشكلة: ما الذي تتيحه الأنظمة الخلفية فعلًا، وما الذي يمكنك التحكم فيه من طبقة التكامل، وأين تنتهي حدود ذلك التحكم.

عند أي نقطة يتوقف مواصفات MCP عن التغطية

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

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

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

ما الذي تتيحه الأنظمة الخلفية فعلًا

هذه صورة الأنظمة الـ32 للمحاسبة وتخطيط موارد المؤسسات التي نتصل بها، كما تبدو من منظور جهة التكامل.

ثلثها لا يستخدم OAuth إطلاقًا

يستخدم 21 نظامًا من أصل 32 نظام OAuth. أما الأنظمة الـ11 الأخرى فتعتمد على بيانات اعتماد ثابتة: مفاتيح API، أو اسم مستخدم وكلمة مرور، أو مجموعة من رمزين. وبعض هذه المفاتيح لا تنتهي صلاحيتها أبدًا. ويوثّق أحد الأنظمة واسعة الاستخدام رموز API لديه على أنها غير محدودة الصلاحية ما دام المستخدم موجودًا.

صلاحية طويلة وإمكانات محدودة للإلغاء

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

وبمجرد إصدار اعتماد، يبرز السؤال: من يستطيع تعطيله؟ والمعيار الخاص بذلك، إلغاء رموز OAuth (RFC 7009)، معتمد منذ عام 2013. ومع ذلك، لا توفر نحو أربعة أنظمة من كل عشرة أي وسيلة تقنية لجهة التكامل لإلغاء بيانات الاعتماد. وينطبق ذلك على جميع الأنظمة التي تستخدم مفاتيح API. ولا يبقى سوى مطالبة العميل بإلغاء الوصول يدويًا.

نطاقات صلاحيات عامة وغياب هوية الوكيل

ترث معظم المفاتيح الثابتة ببساطة كامل صلاحيات المستخدم الذي أنشأها؛ ولا تتيح سوى أنظمة قليلة تقييد المفتاح ليقتصر على نقاط نهاية محددة. وتدعم أنظمة OAuth كثيرة تحديد نطاقات للصلاحيات، لكنها تكون عامة عادةً، من قبيل «المحاسبة، قراءة وكتابة». ولم نعثر في أي من الأنظمة الـ32 على وسيلة لتسجيل كل من الوكيل والشخص الذي يعمل نيابةً عنه في المعاملة نفسها عبر API. إذ تظهر الوكلاء الخارجيون إما باسم المستخدم الذي ربطهم بالنظام أو باسم مستخدم نظام عام. ومن اللافت أن أحد المورّدين، حين أدمج وكلاء في منتجه، كما فعلت Microsoft في Business Central، منحهم حسابات مستخدمين مخصصة. وهذا هو النهج نفسه الذي أوصي به أدناه، لكنه مخصص لوكلاء المورّد نفسه.

ما الذي تستطيع طبقة التكامل فرضه

لا يعني أي مما سبق الاستسلام. فبين الوكيل ونظام المحاسبة، يمكنك التحكم في كل شيء تقريبًا:

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

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

أين تتوقف حدودها

ما لا يمكنك فعله هو مدّ هذه الطبقة إلى ما وراء حدود النظام. وهناك ثلاثة أمور تنهار عندها.

الإسناد

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

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

مبدأ أقلّ الامتيازات

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

إلغاء الصلاحيات

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

الحل العملي: مستخدم مخصص للوكيل

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

ينجح هذا الحل مع كل نظام يتيح إنشاء مستخدمين، ويوفر ثلاث مزايا لا تستطيع طبقة التكامل توفيرها:

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

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

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

الحل البنيوي: الهوية المفوضة

الحل الصحيح موجود بالفعل على الورق. تبادل الرموز في OAuth 2.0 (RFC 8693) يميّز بين انتحال الهوية والتفويض. ففي حالة التفويض، يحتفظ الوكيل بهويته الخاصة، ويسجل الرمز أنه يتصرف نيابةً عن شخص ما، عبر الادعاء «act».

وعند تطبيق ذلك على المحاسبة، فهذا يعني أن:

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

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

ما ينبغي فعله قبل أن يتعامل وكيل مع دفتر الأستاذ

إذا كنتم تربطون وكلاء بأنظمة المحاسبة أو تخطيط موارد المؤسسات، فإليكم قائمة تحقق موجزة:

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

الحد الفاصل هو بيت القصيد

تأمين خادم MCP الخاص بك أمر ضروري، لكنه لا يكفي. وتتحدد سلامة الوكيل الذي يكتب في دفتر الأستاذ عند الحد الفاصل بين طبقتك ونظام السجل المعتمد، وهذا الحد تحدده الأنظمة اليوم، لا أنت.

الخبر الجيد أن الفجوة محددة بوضوح. فالمعايير موجودة، لكن ما ينقص هو دعمها في الأنظمة التي تحفظ السجلات.