RBAC مقابل ABAC: اختيار نموذج التحكم في الوصول لوكلاء الذكاء الاصطناعي

ما هو RBAC فعلياً؟

يقوم التحكم في الوصول القائم على الدور (RBAC) بوضع طبقة مسمات بين الأشخاص والصلاحيات. أنت لا تمنح "Priya" القدرة على قراءة مجموعة أسرار مباشرة، بل تُعرّف دوراً يُسمى "Secret Group Viewer" يحتوي على تلك الصلاحية، ثم تُعين "Priya" في هذا الدور.

يتكون نموذج التحكم في الوصول القائم على الدور من ثلاثة عناصر رئيسية:

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

ولكن نقطة الضعف تكمن أيضاً في هذه الوساطة. فالأدوار هي مجموعات ثابتة. إذا كانت الصلاحية يجب أن تُطبق فقط من عنوان IP خاص بالشركة، أو فقط على السجلات الموجودة في المنطقة الجغرافية الخاصة بمقدم الطلب، فإن RBAC البسيط لا يمكنه التعبير عن ذلك. وتستجيب الفرق لذلك بإنشاء المزيد من الأدوار: analyst-eu، وanalyst-eu-readonly، وanalyst-eu-readonly-prod. يُعرف هذا بـ انفجار الأدوار (Role explosion)، وهو السبب الأكثر ذكراً الذي يدفع المؤسسات للبحث عن ABAC.

ما هو ABAC فعلياً؟

يزيل التحكم في الوصول القائم على السمات (ABAC) الحزمة المسمات. وبدلاً من السؤال عن الدور الذي تحمله الجهة، فإنه يقيّم تعبير السياسة وقت الطلب بناءً على أربع فئات من السمات:

تقرأ السياسة شيئاً مثل: السماح بالقراءة عندما تكون subject.department == resource.owning_team و resource.classification != "restricted" و env.network == "corp". يُعد NIST SP 800-162 المرجع الأساسي لذلك؛ وفي الممارسة العملية، يُقدم ABAC كلفة سياسات مثل XACML أو Rego أو Cedar خلف خدمة التفويض.

ABAC أكثر تعبيراً بشكل يعتد به. يمكن لقاعدة واحدة مكتوبة بعناية أن تحل محل مئة دور، وتتعامل مع العلاقات التي لا يمكن لـ RBAC التعبير عنها على الإطلاق: مثل "الطبيب المعين لهذا المريض".

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

مقارنة سريعة بين RBAC وABAC

هناك أمر يخفيه هذا الجدول: يتطلب ABAC شرطاً أساسياً وهو سمات موثوقة. فالسياسة المستندة إلى resource.data_region تكون بجودة انضباط عملية الترميز (Tagging) التي تملأ هذا الحقل فقط. معظم المؤسسات التي تجرب ABAC تكتشف أن لديها مشكلة في البيانات غير المعلمة قبل أن تصبح لديها مشكلة في التفويض. كما أن النموذجين ليسا متعارضين — الشكل الشائع في البيئات الإنتاجية هو استخدام RBAC كعمود فقري مع إضافة بعض شروط السمات فوقه.

أين تخطئ الفرق؟

التعامل مع انفجار الأدوار كسبب لتغيير النموذج. انفجار الأدوار هو عادةً مشكلة في تحديد النطاق (Scoping)، وليس فشلاً في النموذج نفسه. إذا كان لديك analyst-team-a، وanalyst-team-b، وanalyst-team-c، فأنت لا تحتاج إلى سمات — بل تحتاج إلى دور analyst واحد مربوط بشكل منفصل بموارد كل فريق. معظم المشاكل المعزوة إلى RBAC تأتي من منح الصلاحيات على مستوى المستأجر (Tenant) بأكمله بينما كان ينبغي ربطها بمورد واحد.

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

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

منح الصلاحيات للمستخدم البشري وتجاهل الوكيل. كل عناصر التحكم على الجانب البشري تعتبر صورية إذا كان الوكيل الذي قاموا ببنانه يعمل باستخدام رمز خدمة (Service token) مشترك يملك وصولاً على مستوى المستأجر بأكمله.

هل تريد رؤية الوصول المحدد بنطاق في الممارسة العملية؟

قم بتشغيل TrueFoundry واقصر منح الدور على مورد واحد بدلاً من المستأجر بأكمله — يستغرق الأمر حوالي دقيقتين.

ابدأ مجاناً

لماذا تبدو وكلاء الذكاء الاصطناعي وكأنها الحالة المثالية لاستخدام ABAC؟

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

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

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

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

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

كيف يعمل هذا في TrueFoundry؟

تطبق TrueFoundry نموذج RBAC مع ربط أدوار محدد بنطاق الموارد. هي ليست محرك سياسات ABAC، ومن المهم أن نكون واضحين بشأن ذلك. يجيب النموذج على سؤال واحد: من يمكنه فعل ماذا، وأين؟

• الـ Subject (الجهة) هي الهوية التي تتلقى الوصول: مستخدم، أو فريق، أو حساب افتراضي (Virtual Account)، أو وكيل.
• الـ Resource (المورد) هو الشيء الذي يتم الوصول إليه: حساب مزود نموذج، أو سيرفر MCP، أو وكيل، أو عنقود (Cluster)، أو مساحة عمل (Workspace)، أو مستودع، أو مجموعة أسرار.
• الـ Role (الدور) هو مجموعة مسمات من الإجراءات المسموح بها.

إن تعيين دور لجهة معينة على مورد ما ينشئ ربط دور (Role binding). وتتم إدارة الوصول بشكل مستقل عن تكوين المورد، بحيث يمكنك تغيير من يملك الوصول دون إعادة نشر أي شيء.

يتم منح الصلاحيات من المورد نفسه — افتح قائمة النقاط الثلاث الخاصة به وحدد Access Control:

ثم اختر جهة واحدة أو أكثر ودوراً. تعرض القائمة الإجراءات التي يتضمنها كل دور، حتى ترى ما تمنحه قبل إتمامه:

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

ثلاثة نطاقات، وليس نطاقاً واحداً

تعمل الأدوار في ثلاثة نطاقات، وفهم الفارق بينها يمثل المهارة الأساسية:

لا يمكن تعديل دوري Admin و Read-Only Member. بينما يمكن تعديل دور Member — وهو الحد الأدنى الذي يحصل عليه كل مستخدم، والذي يتضمن افتراضياً فقط: cluster:ReadCluster، و environment:ListEnvironments، و settings:ListSettings، و user:ListUsers، و repository:CreateRepository، و secret-group:CreateSecretGroup، و agent:CreateAgent. وهو لا يصل إلى أي نموذج فردي، أو سيرفر MCP، أو مساحة عمل — حيث تأتي تلك الصلاحيات من روابط الموارد أو عضوية الفريق.

أدوار الفريق هي الأقرب هنا إلى شرط السمات، والمقارنة مفيدة. يحمل دور Team Member صلاحية virtual-account:ReadVirtualAccount، وهي محددة بنطاق الحسابات الافتراضية المملوكة للفريق الذي ينتمي إليه المستخدم بالفعل. الصلاحية متطابقة للجميع؛ لكن مجموعة الكائنات التي تصل إليها تختلف من شخص لآخر.

هذا تحديد لنطاق الملكية، وليس ABAC: لا توجد تعبيرات سياسة، ولا تقييم للسمات، بل مجرد علاقة ثابتة بين الفريق وما يملكه. يغطي هذا الحالة الشائعة التي تدفع الناس نحو السمات، ويبقى سهلاً للقراءة.

أدوار مخصصة لصلاحيات دقيقة الحبيبات

عندما تكون أدوار المستأجر المدمجة واسعة جداً أو ضيقة جداً، يمكنك بناء دورك الخاص من كتالوج الصلاحيات. تتبع كل صلاحية صيغة resource:Action، ومجموعة حسب نوع المورد:

تحكم قاعدة واحدة متى يتم استخدام هذا: تطبق صلاحيات الدور المخصص عبر جميع الموارد من النوع المحدد. فالدور المخصص الذي يحتوي على mcp-server:ReadMcpServer يصل إلى كل سيرفر MCP، وليس لسيرفرات مختارة. بالنسبة لمورد واحد، استخدم صفحة Access Control الخاصة بذلك المورد بدلاً من ذلك. عدم فهم هذا العكس هو كيف يتحول الدور المخصص لسيرفر واحد بهدوء إلى صلاحية قراءة على مستوى المستأجر بأكمله.

البوابات السياقية، المحددة بدقة

تضيف TrueFoundry مراعاة السياق في أربعة أصلية. لا يُعد أي منها سياسات سمات، وكل منها قابل للفحص:

الآلية الثانية تقوم بمعظم العمل الذي يتوقعه الناس من ABAC. عندما يستدعي الوكيل أداة لمستخدم معين عبر OAuth الخاص بذلك المستخدم، فإن الخدمة الخارجية تقيّم الصلاحيات الحقيقية للمستخدم. أنت لم تقم بنمذجة قوائم التحكم بالوصول (ACLs) الخاصة بـ GitHub داخل محرك سياسات لديك؛ بل قمت بالتفويض إلى النظام الذي يملكها، وتلك النسخة لا يمكن أن تصبح قديمة. يتأسس نموذج التحكم في الوصول لـ MCP مباشرة على هذا المبدأ.

حد واحد يجب مراعاته: تمنح رموز الحسابات الافتراضية (Virtual Account tokens) كل طلب وصولاً متطابقاً. هي مناسبة للاتصالات بين الخدمات (Service-to-service) وغير مناسبة عندما تكون الصلاحيات لكل مستخدم مهمة.

مثال عملي بطريقتين

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

منح مدقق حسابات وصولاً للقراءة فقط. قم بتعيين دور Read-Only Member من Access > Users. هذا دور مدمج على مستوى المستأجر، يوفر وصولاً للقراءة فقط عبر أنواع الموارد المدعومة، ولا يمكن تعديله — وهذا هو المغزى، لأن دور التدقيق الذي يمكن توسيعه بهدوء ليس دور تدقيق حقيقي. لمجموعة من المدققين، قم بتعيينه لفريق ليرثه جميع الأعضاء الجدد. إذا كان ينبغي للمدقق رؤية موارد محددة فقط، فتجاهل دور المستأجر تماماً واقصر منح دور المشاهد أو الوصول على كل مورد بمفرده.

السماح للأفراد بإنشاء سيرفرات MCP دون منحهم دور Admin. الدافع التلقائي هو منح دور Admin، لأن إنشاء سيرفر يتطلب صلاحية يفتقر إليها دور Member. بدلاً من ذلك، أنشئ دوراً مخصصاً يحتوي بدقة على mcp-server:CreateMcpServer:

ثم قم بتعيينه من Access > Users أو Access > Teams:

السلوك المترتب هو الجزء الأكثر أهمية. تتيح صلاحية Create MCP Server لشخص ما إنشاء سيرفر جديد. ولكنها لا تمنح الوصول إلى السيرفرات الحالية. بعد إنشاء سيرفر، يمنح المالك نفسه دور MCP Server Manager من صفحة Access Control الخاصة بذلك السيرفر.

سلطة الإنشاء وسلطة الوصول مفصلتان، ولا تتداخل أحدهما مع الأخرى. كان بإمكان سياسة ABAC التعبير عن الأمر نفسه، في قاعدة يتوجب عليك قراءتها بعناية للتأكد منها. لكنها هنا عبارة عن صفين في جدولين. يتوسع هذا النمط لأسفل أيضاً: للسماح للجميع برؤية عناصر التحكم في البوابة دون منحهم دور Admin، قم بتعديل دور Member وأضف gateway-controls:ListGatewayControls.

هل أنت مستعد لتحديد نطاق أول وكيل لديك؟

أنشئ دوراً مخصصاً، واربطه بسيرفر MCP واحد، وشاهد بالضبط ما يمكن لوكيلك الوصول إليه.

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

نقاط هامة يجب معرفتها

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

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

أدوار المستأجر تندمج مع أدوار المستأجر الخاصة بالفريق. يحمل المستخدم دور مستأجر واحد معين مباشرة. إذا كان ينتمي أيضاً إلى فريق يحمل دور مستأجر، فإن صلاحياته الفعالة هي اتحاد الاثنين — لذا فإن السلطة الحقيقية للمستخدم ليست مرئية في سجل المستخدم الخاص به بمفرده. يمكن إنشاء الفرق يدوياً، أو توفيرها من IdP الخاص بك عبر SCIM، أو تطبيقها باستخدام tfy apply على ملف YAML للفريق، ويمكن أن ترتبط قيمة ادعاء (Claim) IdP مباشرة بفريق.

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

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

الخاتمة

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

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

هذا ما تطبقه TrueFoundry، وتسميته RBAC بدلاً من شيء أكثر تعقيداً هو المغزى الأساسي. عندما تسأل مراجعة الوصول القادمة عما يمكن لهذا الوكيل الوصول إليه، يجب أن تكون الإجابة قائمة، وليس إثباتاً منطقياً.

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

البدء مجاني