التفويض دقيق التحديد: ما مدى الدقة الكافي؟

ما يعنيه التفويض دقيق التحديد فعلياً

يدور التفويض دقيق التحديد (Fine-Grained Authorization) حول حجم الشيء الذي تتخذ قراراً بشأنه، وليس الآلية التي تتخذ القرار بها. يسأل التفويض عام التحديد (Coarse Authorization): "هل يمكن لهذه الهوية استخدام بوابة الذكاء الاصطناعي؟" بينما يسأل التفويض دقيق التحديد: "هل يمكن لهذه الهوية استدعاء الأداة delete_issue على خادم Linear MCP، في الوقت الحالي، لهذا الشخص تحديداً؟"

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

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

كما أن الدقة هي بُعد منفصل عن الاختيار بين RBAC (التحكم في الوصول المستند إلى الأدوار) و ABAC (التحكم في الوصول المستند إلى السمات). إذ يمكن للأدوار العادية التعبير عن أذونات دقيقة للغاية إذا قمت بتقييد النطاقات بإحكام، وقد تكون سياسات السمات عامة ومبهمة للغاية. فالنموذج هو طريقة اتخاذ القرار، أما الدقة فهي موضوع القرار نفسه.

التكلفة التي لا يحسب لها أحد حساباً

إليك الحسابات: أربعون مهندساً وإذن واحد على مستوى البوابة يمنح مراجعة الوصول 40 حالة للتحقق منها. قم بتحديد النطاق لكل مورد عبر 12 خادم MCP وسيكون لديك 480 حالة. قم بالتخصيص لكل أداة بمعدل 25 أداة لكل خادم وستحصل على 12,000 خلية. أضف إلى ذلك الموافقة لكل استدعاء، وسيتوقف موضوع المراجعة عن كونه شبكة بيانات — بل يصبح سجل أحداث.

لا أحد يدقق 12,000 خلية. وبدلاً من ذلك، يحدث الخطر الحقيقي للدقة المفرطة:

• يتم تقريب النموذج وتجاوز تفاصيله. يتوقف المراجعون عن التحقق من الخلايا ويبدأون في التحقق من أسماء الأدوار، مما يؤدي إلى انحراف الأذونات الأساسية دون ملاحظتها.
• يبني شخص ما مخرج طوارئ. يظهر حساب خدمة مشترك بجميع الصلاحيات واسعة النطاق، لأن المسار الصحيح يتطلب ثلاث موافقات وتذكرة دعم. تصبح كل أدوات التحكم في المسار الدقيق مجرد ديكور.
• تتراكم الأذونات الممنوحة. تكون الأذونات دقيقة التحديد صغيرة فردياً، فلا يشعر أحد بعبء ترك أحدها نَشِطاً. بينما تُسحب الأذونات عامة التحديد لأنها واضحة للعيان.
• يتحول طابور الموافقات إلى مجرد موافقة صورية (Rubber Stamp). عندما تضع بوابة على كل شيء، ينقر الموافقون دون قراءة — وهو أسوأ من عدم وضع أي بوابة، لأن هناك سجيلاً موقعاً ينص الآن على أن بشرياً قد وافق.

لذا فإن القيد الحقيقي هو الإمكانية الفعلية للإجابة (Answerability). عند أي درجة، يجب أن تجيب عن ثلاثة أسئلة دون تشغيل مهمة معالجة: من يمكنه الوصول إلى هذا المورد، ماذا يمكنهم أن يفعلوا به، ومتى كانت آخر مرة قاموا فيها بذلك. إذا كسرت ذلك، فقد اشتريت الدقة على حساب الرؤية والشفافية.

لهذا السبب أيضاً ليست أذونات الحد الأدنى من الامتيازات (Least Privilege Permissions) والدقة القصوى نفس الهدف. فالحد الأدنى من الامتيازات يمنح سلطة لا تزيد عما تتطلبه المهمة؛ ولا يعني تقطيعها إلى أجزاء دقيقة لمجرد أن النظام يسمح بذلك. الدور الذي يحمل الأذونات السبعة التي تتطلبها المهمة بالضبط يمثل الحد الأدنى من الامتيازات. أما سبعمائة إذن منفصل تضاف إلى نفس السلطة فهي مجرد تكلفة باهظة.

سلم الدقة

أربع درجات، من عام التحديد إلى دقيقه، ولكل منها مهمة محددة. القاعدة هي الجلوس على أدنى درجة تحتوي على المخاطر.

هناك خاصيتان تجعلان هذا النظام سلماً تدرجياً وليس مجرد قائمة خيارات.

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

كل درجة هي شكل مختلف من السجلات. الدرجتان 1 و 2 هما جدولان تقرأهما. والدرجة 3 هي قائمة تقارنها مع الربع السابق. والدرجة 4 هي سجل عينات تجري فحصها. ومعاملة الدرجة 4 كجدول هي الطريقة التي تنتهي بالفرق إلى وجود مائتي سياسة لا يمكن لأحد تلخيصها.

أين تخطئ الفرق في هذا الشأن

استخدام الدرجة 1 للقيام بمهمة الدرجة 2. الخطأ الأكثر شيوعاً بفارق كبير. يحتاج شخص ما إلى خادم MCP واحد، فيحصل على دور على مستوى المستأجر يحتوي على mcp-server:ReadMcpServer — والذي يصل إلى كل خادم MCP في المستأجر. يبدو الإذن الممنوح ضيقاً لأن قائمة الأذونات قصيرة، ولكنه ليسكذلك في الحقيقة.

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

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

عدم إعادة مراجعة الدرجات الدقيقة أبداً. تراجع الأذونات عامة التحديد لأنها لافتة للنظر. أما الأداة التي تم تمكينها لترحيل استثنائي منذ ثمانية أشهر فهي غير مرئية. قم بتدقيق قوائم الأدوات الممكنة بنفس الوتيرة التي تدقق بها الأدوار.

هل تريد رؤية السلم في وحدة تحكم واحدة؟

حدد نطاق دور لمورد واحد، ثم عطل أداة عليه — في غضون خمس دقائق من البداية للنهاية.

ابدأ مجاناً

كيف يعمل السلم في TrueFoundry

تطبق TrueFoundry الدرجات الأربع جميعها. يتكون ربط الأدوار (Role Binding) من فاعل (Subject) (مستخدم، أو فريق، أو حساب افتراضي، أو وكيل) بالإضافة إلى مورد (Resource) ودور (Role)، وتدار بشكل مستقل عن تهيئة المورد — بحيث يمكنك تغيير من يمكنه الوصول إلى شيء ما دون إعادة نشره.

الدرجة 1 — القدرة على مستوى المستأجر

هناك ثلاثة أدوار مدمجة للمستأجر: Admin (تحكم كامل، غير قابل للتعديل)، و Member (الخط الأساسي الافتراضي القابل للتعديل)، و Read-Only Member (للقراءة فقط، وثابت أيضاً).

عندما تكون هذه الأدوار واسعة جداً أو ضيقة جداً، يمكنك بناء دور مخصص من Access > Custom Roles. الكتالوج هو جوهر الأذونات دقيقة التحديد هنا: كل إدخال هو مفتاح resource:Action مجمع حسب نوع المورد، وتخبرك التسمية بمدى الدقة الموجودة قبل تصميم أي شيء.

إن إنشاء خادم MCP وإدارته هما مفتاحان منفصلان. وتمنح هذه الانقسامات تصميم نموذج التفويض الدقة القابلة للاستخدام.

تحكم هذه الدرجة قاعدة واحدة: تطبق أذونات الدور المخصص على جميع الموارد من النوع المحدد. بالنسبة لمورد واحد، استخدم صفحة Access Control الخاصة بذلك المورد. وإن الفهم الخاطئ لهذا هو نفسه الفشل المذكور أعلاه في "قيام الدرجة 1 بمهمة الدرجة 2".

الدرجة 2 — أدوار لكل مورد

افتح قائمة النقاط الثلاث للمورد واختر Access Control.

اختر الفاعلين ودوراً. يعرض الدرج الإجراءات التي يتضمنها كل دور، حتى ترى الإذن الممنوح أولاً.

تعتمد الأدوار على المورد: Manager و User على حساب المزود؛ و MCP Server Manager، و MCP Server User، و MCP Server Approver على خادم MCP؛ و Agent Manager و Agent Access على الوكيل؛ ومستويات المسؤول والأعضاء والمشاهدين على العناقيد (Clusters) ومساحات العمل (Workspaces). يفضل منح الأذونات لفريق على منحها لشخص واحد — حيث يرثها الموظفون الجدد مستقبلاً، ويبقى جدول الأذونات قصيراً بدرجة كافية لقراءته. تم بناء نموذج التحكم في الوصول لـ MCP على هذه الدرجة.

الدرجة 3 — لكل أداة داخل المورد

هذه هي الدرجة التي تصل إليها الفرق في النهاية وتكون الوكلاء بأشد الحاجة إليها. في خادم MCP البعيد أو المُدار بواسطة TrueFoundry، تتحكم علامة التبويب Tools في الأدوات القابلة للاستدعاء.

تُحذف الأدوات المعطلة من استجابات tools/list ولا يمكن استدعاؤها. وكلا النصفين مهمان: فالنموذج لا يمكنه اختيار ما لا يراه أبداً، وترفض البوابة الاستدعاء إذا طلب شيء ما ذلك على أي حال.

يحدد مفتاح التبديل Enable new tools by default الخط الأساسي، وهو خيار تصميمي حقيقي. في حالة التفعيل (On)، تكون القائمة قائمة حظر (Denylist) وتظهر أدوات المورد الجديدة تلقائياً. وفي حالة التعطيل (Off)، تكون قائمة سماح (Allowlist) وتبقى الأدوات الجديدة مخفية حتى يقوم شخص ما بتمكينها. وقائمة السماح هي الخيار الصحيح لأي شيء يمس بيئة الإنتاج.

يقوم خيار Edit Tool بعمل أكثر دقة. فإلى جانب تجاوز الوصف، يمكنك ضبط MCP Tool Annotations على None، أو Read-only، أو Destructive، مما يحدد readOnlyHint أو destructiveHint.

هذا التوضيح (Annotation) هو التسمية التي تقرأها الدرجة 4، بحيث يصبح التصنيف لمرة واحدة سياسة مستمرة دون الحاجة لتسمية الأدوات مرتين.

الدرجة 4 — الموافقة لكل استدعاء

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

يحدد قرصان مدى الدقة، ولكليهما قواعد أسبقية موثقة:

تقتصر الأذونات الممنوحة على طالب الخدمة بالإضافة إلى الخادم والأداة المحددين، ولا يتم مشاركتها بين المستخدمين. يعمل الموافقون من قائمة الطلبات المعلقة (Pending Requests)، التي تظهر الأداة، والسياسة، وطالب الخدمة، ونافذة الصلاحية، ووسائط الأداة (Tool Arguments).

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

إذا لم يكن للخادم المسمى بواسطة سياسة ما أي مساهمين بصفة موافق (Approver)، فإن مسؤولي المستأجر فقط هم من يمكنهم اتخاذ القرار — وهي طريقة هادئة لتوجيه كل موافقة إلى ثلاثة أشخاص مثقلين بالأعمال.

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

مثال عملي: القراءة مقابل الاستخدام في مجموعة أسرار

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

تنظم مجموعة الأسرار الأسرار المرتبطة ببعضها بحيث تدير الوصول مرة واحدة، وليس لكل سر. عند حفظ سر، تذهب القيمة إلى مدير الأسرار الخاص بك — AWS SSM، أو GCP Secret Manager، أو HashiCorp Vault، أو Azure Vault — وتخزن TrueFoundry اسماً مؤهلاً بالكامل (FQN) تشير إليه من عمليات النشر، وتثبيت وحدات التخزين، والتكاملات، ومفاتيح API لنماذج البوابة.

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

صف Viewer هو النتيجة المرجوة. يمكن لشخص ما رؤية أن stripe-live-key موجود هنا — وهو ما يكفي لمراجعة ما يعتمد عليه المشروع — دون أن تظهر القيمة على شاشته. ويجعل كتالوج الأذونات نفس الفصل صريحاً: secret-group:ReadSecretGroup يعرض المجموعة، و secret-group:ReadData يقرأ القيم. مفاتيح مختلفة، لذا يمكن لدور مخصص أن يحمل أحدهما دون الآخر.

تنبيهان، لأن المستندات هنا أضيق من المفهوم. يتمتع مسؤول المستأجر بالوصول إلى جميع مجموعات الأسرار افتراضياً؛ وبالنسبة للأعضاء والفرق، يمكنك تعيين دور في كل مجموعة بشكل فردي. وتدرج قائمة أدوار الموارد دوراً رابعاً، Secret Group Access، إلى جانب Admin و Editor و Viewer — لكن صفحة إدارة الأسرار توثق الثلاثة المذكورة أعلاه فقط، لذلك لن نخبرك بما يمنحه الدور الرابع. تحقق من وحدة التحكم الخاصة بك قبل بناء عملية عليه.

يتعمم هذا النمط. أينما كان للمورد وصف وحمولة (Payload)، ابحث عن مفاتيح منفصلة تغطي كلاً منهما — تمتلك المستودعات نفس الفصل بين ReadRepository و ReadData — وامنح الوصف دون الحمولة أينما كان ذلك كافياً.

هل أنت مستعد للفصل بين القراءة والاستخدام؟

أنشئ مجموعة أسرار، وامنح صلاحية Viewer لزميل في الفريق، وشاهد القيم وهي تبقى مخفية.

ابدأ مجاناً على TrueFoundry

مشكلات وأخطاء شائعة تستحق المعرفة

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

تعديل الدور الافتراضي للفريق يغيره لجميع الفرق. يتم تعديل Team Member و Team Manager تحت Access > Default Roles، والتغيير يكون عاماً. إن إضافة virtual-account:ManageVirtualAccount حتى يتسنى لفريق واحد استرداد الرموز المميزة يمنح تلك القدرة في كل فريق. يبقى الأشخاص محصورين في فرقهم الخاصة، لكن القدرة تنتشر. إنه تغيير من الدرجة 1 يرتدي ثوب الدرجة 2.

الموافقة المعلقة هي استجابة ناجحة وليست خطأ. بينما يكون الطلب معلقاً، ترجع البوابة نتيجة JSON-RPC مع isError: false و _meta.approval_status: "pending"، ويطلب نصها من المستدعي الانتظار. والوكيل الذي يتحقق فقط من وجود أخطاء يتعامل معها كنتيجة أداة حقيقية ويستمر في التنفيذ. اقرأ _meta.approval_status وأعد المحاولة.

قراءات ذات صلة

• التحكم في الوصول لـ MCP: تأمين وكلاء الذكاء الاصطناعي باستخدام بوابة MCP — الدرجتان 2 و 3 لأدوات الوكيل
• ما هو تفويض MCP؟ — كيف تصل القرارات إلى استدعاء الأداة
• التحكم في الوصول لـ MCP للمؤسسات — الحفاظ على سهولة قراءة السلم عبر العديد من الخوادم
• مصادقة API و RBAC في بوابة الذكاء الاصطناعي — أين تفرض الأذونات الممنوحة على حركة المرور الحية
• خوادم MCP الافتراضية — تكوين مساحة أدوات منسقة من عدة خوادم

الخلاصة

يتم تسويق التفويض دقيق التحديد كمؤشر ترفعه للأعلى. ولكنه في الحقيقة سلم تصعده بعناية، وتتوقف عندما تتوقف المخاطر عن الارتفاع بدلاً من التوقف عندما تنفد خيارات المنصة.

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

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

حدد نطاق وكيلك الأول على TrueFoundry

البداية مجانية