التحكم في الوصول القائم على الأدوار (RBAC)

ما التحكم في الوصول القائم على الأدوار (RBAC) في الكريبتو؟

التحكم في الوصول القائم على الأدوار (RBAC) هو نموذج أمني يمنح الأذونات للأدوار بدلًا من تعيين كل إذن مباشرةً لكل مستخدم أو محفظة أو حساب خدمة أو عقد ذكي أو مشغّل.

يساعد RBAC في الكريبتو على تحديد الجهات التي يمكنها سك التوكنات أو إيقاف العقود مؤقتًا أو إدارة الخزائن أو الموافقة على السحوبات أو نشر الترقيات أو الوصول إلى لوحات التحكم أو تدوير المفاتيح أو تشغيل المدققين أو تغيير إعدادات البروتوكول.

يعرّف مسرد NIST لمصطلح RBAC هذا النموذج بأنه تحديد الإجراءات المسموح بها على الموارد بحسب الأدوار، بدلًا من هويات الأفراد.

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

ويحصل كل دور على الأذونات اللازمة لأداء مهامه فقط.

بعد ذلك، تُسند الأدوار إلى المستخدمين أو المحافظ أو الروبوتات أو الخوادم أو العقود.

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

قد يؤدي تصميم ضعيف للتحكم في الوصول إلى تعطل النظام بالكامل بسبب كلمة مرور مسرّبة أو مفتاح API مخترق أو موظف داخلي خبيث أو محفظة مسؤول مسروقة.

تعريف مبسط للتحكم في الوصول القائم على الأدوار (RBAC)

التحكم في الوصول القائم على الأدوار (RBAC) هو أسلوب لإدارة الأذونات عبر إسناد المستخدمين أو الحسابات إلى أدوار تتضمن حقوق وصول محددة مسبقًا.

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

فمثلًا، قد يُسمح لموقّع الخزينة بالموافقة على المدفوعات، لكن لا يُسمح له بنشر ترقيات العقود الذكية.

وقد يُسمح لمطوّر العقود الذكية بجدولة الترقيات، لكن لا يُسمح له بتحريك أموال الخزينة.

وقد يُسمح لموظف الدعم بعرض حالة الحساب، لكن لا يُسمح له بتغيير إعدادات السحب.

وقد يُسمح لمشغّل المدقق بإعادة تشغيل البنية التحتية، لكن لا يُسمح له بالوصول إلى المفاتيح الخاصة بالخزينة.

يحد هذا الفصل من الضرر الذي قد يسببه اختراق حساب واحد.

الفكرة الأساسية لـ RBAC بسيطة: امنح كل دور الحد الأدنى المفيد من الأذونات، ولا تسنده إلا إلى الأشخاص أو الأنظمة التي تحتاج إليه فعلًا.

أهمية RBAC في العملات المشفرة

تنبع أهمية RBAC في العملات المشفرة من أن عمليات البلوكشين غالبًا ما تتضمن إجراءات عالية القيمة يصعب التراجع عنها.

إذا استطاع الحساب الخطأ سك التوكنات أو ترقية العقود أو تغيير الرسوم أو إيقاف السحوبات أو نقل الأموال، فقد يتكبد المستخدمون خسائر كبيرة.

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

ويحتاج كل نظام من هذه الأنظمة إلى تفويض صارم للصلاحيات.

يساعد RBAC الفرق على تجنب منح صلاحيات المسؤول الواسعة لكل من يعمل في المشروع.

كما يساعدها على إثبات من كان مخولًا بتنفيذ الإجراءات الحساسة.

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

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

آلية عمل RBAC

يبدأ RBAC بتحديد الموارد التي تحتاج إلى حماية.

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

بعد ذلك، يحدد الفريق الإجراءات التي يمكن تنفيذها على تلك الموارد.

وقد تشمل الإجراءات القراءة والكتابة والموافقة والإلغاء والسك والحرق والإيقاف المؤقت والترقية والسحب والنشر والتدوير والتوقيع والإعداد.

ثم يجمع الفريق هذه الإجراءات ضمن أدوار.

وأخيرًا، تُسند الأدوار إلى المستخدمين أو المحافظ أو حسابات الخدمة أو العقود.

عندما يحاول أحد تنفيذ إجراء ما، يتحقق النظام مما إذا كان ذلك الطرف يملك الدور المطلوب.

إذا كان الدور يتضمن الإذن، يُسمح بالإجراء؛ وإذا لم يتضمنه، يرفضه النظام.

المكونات الأساسية لـ RBAC

المكونات الرئيسية لـ RBAC هي الأطراف والأدوار والأذونات والموارد والجلسات والسياسات.

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

الدور مجموعة مسماة من الأذونات.

الإذن إجراء معتمد على مورد.

المورد هو الشيء الخاضع للحماية.

الجلسة هي الاستخدام النشط لدور واحد أو أكثر من قبل طرف.

السياسة هي مجموعة القواعد التي تحدد كيفية إنشاء الأدوار وإسنادها ومراجعتها وإزالتها.

عندما تُصمم هذه المكونات جيدًا، يسهل RBAC إدارة التحكم في الوصول وتدقيقه.

RBAC في العقود الذكية

يُستخدم RBAC على نطاق واسع في العقود الذكية للتحكم في الوظائف ذات الصلاحيات الخاصة.

فمثلًا، قد يتضمن عقد توكن دورًا للمُصدِر مخولًا بإنشاء توكنات جديدة.

وقد يتضمن عقد الحوكمة دورًا للمُنفِذ يستطيع تنفيذ المقترحات المعتمدة.

وقد يتضمن عقد الجسر دورًا للمرحّل يستطيع تقديم الرسائل التي تم التحقق منها.

وقد يتضمن بروتوكول DeFi دورًا للحارس يستطيع إيقاف الوظائف الخطرة مؤقتًا أثناء الطوارئ.

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

وتشرح وثائق واجهة AccessControl البرمجية لدى OpenZeppelin آلية للتحكم في الوصول القائم على الأدوار داخل كل عقد، تتيح إنشاء أدوار هرمية متعددة وإسنادها إلى حسابات عدة.

لهذا السبب، يُعد RBAC نمطًا أساسيًا في العقود الذكية المخصصة للإنتاج.

RBAC مقارنةً بالعقود الذكية من نوع Ownable

Ownable نمط بسيط للتحكم في الوصول، يمنح حساب مالك واحدًا صلاحيات إدارية.

أما RBAC فهو أكثر مرونة، لأنه يتيح إنشاء أدوار مختلفة بأذونات مختلفة.

قد يكون Ownable مناسبًا للاختبارات السريعة أو العقود الصغيرة جدًا.

لكن أنظمة الكريبتو المخصصة للإنتاج غالبًا ما تتجاوز التحكم من مالك واحد، لأن حسابًا واحدًا لا ينبغي أن يتحكم في كل إجراء حساس.

فمثلًا، لا ينبغي أن يُمنح الحساب الذي يوقف البروتوكول تلقائيًا صلاحية سك التوكنات أو سحب أموال الخزينة.

كما لا ينبغي أن يُمنح الحساب الذي يرقّي العقد تلقائيًا صلاحية تغيير معايير المخاطر.

يدعم RBAC فصل المهام.

ويقلل هذا الفصل احتمال أن يؤدي اختراق مفتاح واحد إلى اختراق البروتوكول بالكامل.

RBAC ومبدأ الحد الأدنى من الصلاحيات

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

ويُعد RBAC من أكثر الطرق العملية لتطبيق هذا المبدأ.

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

هذا المبدأ بالغ الأهمية في الكريبتو، لأن الوصول غير الضروري قد يؤدي إلى عواقب كارثية.

لا ينبغي لمطور يحتاج إلى صلاحية القراءة فقط أن يتمكن من نقل الأموال.

ولا ينبغي لروبوت مراقبة أن يتمكن من تغيير ملكية العقد.

ولا ينبغي لموظف دعم أن يتمكن من تعطيل وسائل حماية السحب.

يحوّل مبدأ الحد الأدنى من الصلاحيات RBAC من قائمة أذونات إلى ضابط أمني فعلي.

RBAC وفصل المهام

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

فمثلًا، قد ينشئ دور طلب سحب، ويراجعه دور آخر، ثم توافق عليه محفظة متعددة التوقيع.

وقد يقترح دور ترقية عقد ذكي، ويدققها دور آخر، وينفذها دور ثالث بعد فترة تأخير ملزمة.

يقلل ذلك مخاطر المطلعين ومخاطر اختراق الحسابات.

كما يصعّب الاحتيال، لأن التنفيذ يتطلب تعاون أدوار مستقلة متعددة.

يفيد فصل المهام في الكريبتو في إدارة الخزائن وتشغيل الجسور وإدارة المدققين وتوقيع الإصدارات وسك التوكنات والاستجابة للطوارئ.

يجعل RBAC هذا الفصل ممكنًا عبر تقسيم الأذونات إلى أدوار محددة بوضوح.

تتجنب العمليات القوية في مجال الكريبتو منح دور واحد سيطرة غير محدودة على الأموال والشفرة والبنية التحتية في الوقت نفسه.

RBAC والمحافظ متعددة التوقيع

تتطلب المحفظة متعددة التوقيع موافقات متعددة قبل تنفيذ المعاملة.

يمكن استخدام RBAC والمحافظ متعددة التوقيع معًا، لكنهما ليسا الشيء نفسه.

يحدد RBAC الأذونات التي يمتلكها كل طرف.

أما المحفظة متعددة التوقيع، فتحدد عدد الموقّعين المعتمدين الذين يجب أن يوافقوا قبل إرسال المعاملة.

قد يُسمح لدور الخزينة بإنشاء طلب دفع، لكن المحفظة متعددة التوقيع قد تظل تشترط موافقة عدة موقّعين عليه.

وقد يُسمح لدور مسؤول البروتوكول بجدولة ترقية، بينما تؤخر فترة التأخير الملزمة والمحفظة متعددة التوقيع التنفيذ النهائي وتوافقان عليه.

يوفر الجمع بينهما ضوابط أقوى من استخدام أي منهما بمفرده.

ينبغي عادةً الجمع بين RBAC والمحافظ متعددة التوقيع والفترات الزمنية الملزمة والمراقبة وقواعد الحوكمة الواضحة في أنظمة الكريبتو ذات القيمة العالية.

RBAC وDAO

يمكن لمنظمات DAO استخدام RBAC لإدارة الصلاحيات المفوضة.

قد تنشئ DAO أدوارًا للجان الخزينة ومراجعي المنح ومجالس الأمان وحراس البروتوكول ومشرفي المجتمع أو المسؤولين التقنيين.

تساعد هذه الأدوار DAO على التحرك بسرعة أكبر من التصويت المجتمعي الكامل على كل مهمة صغيرة.

لكن يجب أن تكون الأدوار المفوضة محدودة وشفافة.

ينبغي أن يكون لكل دور في DAO نطاق واضح وتاريخ انتهاء وآلية مساءلة ومسار لإلغاء الصلاحيات.

إذا تمكنت لجنة من نقل الأموال أو ترقية العقود من دون رقابة كافية، فقد تصبح DAO لامركزية بالاسم فقط.

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

ينبغي أن يجعل RBAC الجيد في DAO الصلاحيات واضحة لحاملي التوكن والمستخدمين.

RBAC ومنصات الكريبتو

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

قد تشمل الأدوار محلل امتثال ومراجع سحوبات ومشغّل محفظة ومدير خزينة ودعم العملاء ومهندسًا ومستجيبًا للحوادث ومدققًا ومسؤول نظام.

ينبغي أن يقتصر وصول كل دور على ما يحتاج إليه لأداء عمله.

قد يتمكن دور الدعم من عرض حالة التذاكر، لكن لا ينبغي له الموافقة على عمليات السحب الكبيرة.

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

قد يجهز مشغّل الخزينة التحويلات، لكن لا ينبغي له تنفيذها بمفرده.

يساعد RBAC على الحد من التهديدات الداخلية والأخطاء التشغيلية.

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

RBAC وأمان API

تعتمد منتجات الكريبتو بدرجة كبيرة على واجهات API للمحافظ وأدوات التداول ولوحات التحكم وأنظمة الحفظ وإعداد التقارير وإدارة الحسابات.

يكتسب RBAC أهميته في واجهات API، لأن المصادقة وحدها لا تثبت أن المستخدم مخول بتنفيذ الإجراء المطلوب.

توضح إرشادات OWASP بشأن الخلل في التفويض على مستوى الكائنات API1:2023 أن المهاجمين قد يستغلون واجهات API عبر التلاعب بمعرّفات الكائنات عندما لا تتحقق نقاط النهاية من الأذونات بشكل صحيح.

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

ينبغي الجمع بين RBAC والتفويض على مستوى الكائن، كي يتحقق النظام من دور المستخدم ومن الكائن المحدد الذي يحاول الوصول إليه.

لا ينبغي لمستخدم يحمل دور «عميل» قراءة سجلات جميع العملاء.

كما لا ينبغي لمسؤول API تجاوز مسارات الموافقة من دون تسجيل ذلك والخضوع للرقابة.

يتطلب الأمان القوي لواجهات API في الكريبتو الجمع بين RBAC والتفويض على مستوى الكائنات وحدود معدل الطلبات وسجلات التدقيق وضوابط الجلسات الصارمة.

RBAC والخلل في التفويض على مستوى الوظائف

يحدث الخلل في التفويض على مستوى الوظائف عندما يتمكن المستخدم من استدعاء وظيفة لا يُفترض أن يُسمح له باستخدامها.

قد يعني ذلك في الكريبتو تمكّن مستخدم عادي من الوصول إلى نقطة نهاية إدارية أو أداة تجاوز السحب أو التحكم في إدراج التوكنات أو وظيفة محفظة داخلية.

يصنف مشروع OWASP لأهم 10 مخاطر أمان في واجهات API لعام 2023 الخلل في التفويض على مستوى الوظائف ضمن الفئات الرئيسية لمخاطر أمان API.

يساعد RBAC على منع هذه المشكلة عبر اشتراط الدور المناسب قبل تنفيذ الوظائف الحساسة.

لكن RBAC لا يعمل إلا إذا تحققت كل وظيفة حساسة فعلًا من الأذونات.

فقد يؤدي نسيان فحص واحد إلى إتاحة وظيفة قوية للمستخدمين الخطأ.

ينبغي للمطورين اختبار التفويض في كل نقطة نهاية ووظيفة في العقد الذكي.

وينبغي أن تعتبر مراجعات الأمان غياب فحوصات التفويض مشكلة حرجة.

RBAC وبنية Kubernetes التحتية

تشغّل فرق كثيرة في مجال الكريبتو بنيتها التحتية على Kubernetes أو أنظمة سحابية مشابهة.

يتحكم RBAC في Kubernetes بمن يستطيع قراءة موارد المجموعة أو إنشاؤها أو تحديثها أو حذفها أو إدارتها.

توضح الوثائق الرسمية لـ RBAC في Kubernetes أن RBAC ينظم الوصول إلى موارد الحاسوب أو الشبكة استنادًا إلى أدوار المستخدمين داخل المؤسسة.

في بيئة الكريبتو، قد تؤثر أذونات Kubernetes في المحافظ والعقد وخدمات التوقيع وأنظمة RPC وقواعد البيانات وأدوات المراقبة بشكل غير مباشر.

قد يصبح حساب خدمة يملك أذونات واسعة في المجموعة مدخلًا إلى المفاتيح الخاصة أو أسرار الإنتاج.

وقد يغيّر مهندس يملك صلاحيات واسعة بصفته مسؤولًا عن المجموعة البنية التحتية المهمة عن طريق الخطأ.

ينبغي لـ RBAC حماية أحمال العمل ومساحات الأسماء والأسرار وخطوط النشر وحسابات الخدمة.

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

RBAC والبنية التحتية للمدققين

تحتاج أنظمة المدققين ومشغلي العقد والتخزين إلى ضوابط وصول صارمة.

قد يتولى دور مراقبة سلامة العقدة.

وقد يتولى دور آخر إعادة تشغيل الخدمات.

وقد يتولى دور ثالث إدارة إعدادات التوقيع.

وقد يتولى دور آخر بيانات اعتماد السحب أو الضوابط المرتبطة بالخزينة.

ينبغي عدم دمج هذه الأدوار من دون سبب قوي.

لا ينبغي لأداة المراقبة أن تملك صلاحية تصدير المفاتيح الخاصة.

كما لا ينبغي أن يحصل مشغّل المدقق تلقائيًا على صلاحية الوصول إلى محافظ خزينة الأعمال.

يقلل RBAC نطاق الضرر عند اختراق حساب مشغّل أو خادم أو نص برمجي آلي.

RBAC وإدارة المفاتيح الخاصة

المفاتيح الخاصة من أكثر الأصول حساسية في أنظمة الكريبتو.

ينبغي لـ RBAC التحكم في الجهات التي تستطيع إنشاء المفاتيح أو الوصول إليها أو تدويرها أو الموافقة عليها أو استخدامها أو استردادها.

ينبغي فصل الوصول إلى المفاتيح عن الموافقة على المعاملات كلما أمكن.

لا ينبغي لمن يستطيع الموافقة على معاملة أن يتمكن تلقائيًا من تصدير مفتاح التوقيع.

ولا ينبغي لنظام يوقّع المعاملات أن يملك تلقائيًا صلاحية تغيير سياسة المحفظة.

يمكن لوحدات أمان الأجهزة والمحافظ متعددة التوقيع ومحركات السياسات وأنظمة إدارة المفاتيح دعم ضوابط شبيهة بـ RBAC.

ينبغي أن يكون لكل مفتاح مالك وسياسة أدوار وآلية تدوير وخطة طوارئ لإلغاء الصلاحيات.

يكون RBAC أكثر فاعلية عندما يُسجل استخدام المفاتيح وتتم مراجعته ويقتصر على مسارات عمل محددة.

RBAC وترقيات العقود الذكية

تتطلب العقود الذكية القابلة للترقية عناية خاصة عند إعداد RBAC.

قد تغير الترقية منطق البروتوكول أو التعامل مع الأصول أو الرسوم أو الأذونات أو سلوك السحب.

قد يصبح دور الترقية الخاضع لضوابط ضعيفة من أخطر الأدوار في البروتوكول.

يفصل RBAC الجيد للترقيات بين الاقتراح والمراجعة والموافقة والجدولة والتنفيذ.

وقد تمنح الفترة الزمنية الملزمة المستخدمين وقتًا لفحص الترقية قبل سريانها.

وقد تشترط المحفظة متعددة التوقيع موافقة عدة موقّعين موثوقين قبل التنفيذ.

وقد يتولى مجلس الأمان التصحيحات الطارئة، لكن ينبغي أن تكون صلاحيات الطوارئ محدودة النطاق.

ينبغي للمستخدمين التحقق من الجهات التي تستطيع ترقية العقود وما إذا كان لديهم وقت كافٍ للخروج قبل حدوث التغييرات.

RBAC وسك التوكنات

يُعد سك التوكنات من أوضح الأمثلة على أهمية RBAC.

إذا تضمن عقد التوكن دورًا للمُصدِر، فبإمكان هذا الدور إنشاء معروض جديد.

قد يؤدي اختراق دور المُصدِر إلى تخفيف حصص حاملي التوكن والإضرار بالسيولة وتقويض ثقة السوق.

ينبغي تقييد السك بسقوف العرض أو قواعد الحوكمة أو الفترات الزمنية الملزمة أو موافقات المحافظ متعددة التوقيع أو الجداول الآلية، متى أمكن.

ولا ينبغي أن يتحكم دور المُصدِر في وظائف غير مرتبطة بالسك إلا عند الضرورة.

يوازي إلغاء أدوار المُصدِر القديمة في أهميته منح أدوار جديدة.

ينبغي مراقبة عمليات السك علنًا عندما يكون التوكن متاحًا على الشبكة الرئيسية.

يساعد RBAC الواضح للسك المستخدمين على فهم كيفية تغير معروض التوكن.

RBAC وأدوار الإيقاف الطارئ

تستخدم بروتوكولات كريبتو كثيرة أدوار الإيقاف الطارئ لوقف النشاط الخطر أثناء الاستغلال أو العطل الشديد.

قد يوقف دور الإيقاف الإيداعات أو السحوبات أو التحويلات أو المبادلات أو السك أو الاقتراض أو وظائف أخرى.

قد يحمي هذا الدور المستخدمين أثناء الطوارئ.

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

ينبغي أن يكون دور الإيقاف الجيد محدودًا وموثقًا وخاضعًا للمراقبة والضوابط الموثوقة.

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

ينبغي تحديد شروط تفعيل أدوار الطوارئ وإلغاء تفعيلها.

يساعد RBAC على جعل صلاحيات الطوارئ محددة بدلًا من أن تكون غير محدودة.

RBAC وإدارة الخزينة

قد تحتفظ خزائن الكريبتو بعملات أصلية أو أصول مستقرة أو توكنات حوكمة أو NFT أو توكنات أصول حقيقية أو أموال تشغيلية.

يساعد RBAC على تحديد الجهات التي تستطيع اقتراح تحركات الخزينة والموافقة عليها وتنفيذها وتسجيلها وتدقيقها.

قد يقترح دور المنح المدفوعات، لكن لا ينفذها.

وقد يجهز دور الشؤون المالية التقارير، لكن لا يتجاوز موافقات المحفظة متعددة التوقيع.

وقد يوافق موقّع الخزينة على المعاملات، لكن لا يغيّر مجموعة الموقّعين بمفرده.

وقد يطّلع دور التدقيق على النشاط من دون تغيير الأموال.

تقلل هذه البنية احتمال السرقة والأخطاء.

ينبغي دعم RBAC الخاص بالخزينة بحدود للإنفاق ومحاكاة للمعاملات وقوائم عناوين مسموح بها ومراجعات دورية.

RBAC ودعم العملاء

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

قد يتيح دور الدعم عرض التذاكر وحالات المعاملات ومعلومات حساب محدودة.

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

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

يحمي ذلك المستخدمين من الهندسة الاجتماعية وإساءة الاستخدام الداخلي.

ينبغي أن يحد RBAC الخاص بالدعم أيضًا من الوصول إلى المعلومات الشخصية المحددة للهوية.

ينبغي تسجيل جميع إجراءات الدعم لمراجعتها.

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

RBAC وعمليات الامتثال

قد تحتاج فرق الامتثال إلى مراجعة المعاملات أو فحص المحافظ أو التحقيق في التنبيهات أو تقييد النشاط وفق المتطلبات القانونية.

يساعد RBAC على تحديد ما تستطيع أدوار الامتثال رؤيته وتنفيذه.

قد يراجع محلل الامتثال التنبيهات، لكن لا يسحب الأموال.

وقد يوافق مدير الامتثال على قيود معينة، لكن لا ينشر تغييرات في العقود الذكية.

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

تحمي هذه القيود المستخدمين والمؤسسة معًا.

ينبغي أن تكون ضوابط الامتثال شفافة حيثما كان ذلك مناسبًا، وأن تُوثق داخليًا.

قد يدعم RBAC الضوابط القانونية من دون منح صلاحيات تقنية غير ضرورية للموظفين غير التقنيين.

RBAC وسجلات التدقيق

تسجل سجلات التدقيق من نفذ الإجراء ومتى نفذه ومن أين.

يصبح RBAC أقوى بكثير عندما يُسجل كل إجراء ينفذه أي دور.

قد توضح السجلات من منح دورًا أو ألغاه أو وافق على سحب أو غيّر سياسة أو نشر شفرة أو وصل إلى بيانات حساسة.

من دون سجلات، قد تعجز الفرق عن التحقيق في الحوادث.

ينبغي لأنظمة الكريبتو حماية سجلات التدقيق من العبث.

ينبغي أن تؤدي الإجراءات عالية المخاطر إلى تنبيهات.

ينبغي أن تقارن المراجعات المنتظمة بين الأدوار المسندة ومتطلبات العمل الفعلية.

قد يتحول RBAC من دون سجلات تدقيق إلى جدول أذونات لا يتحقق منه أحد.

RBAC ومراجعة الأدوار

مراجعة الأدوار هي فحص دوري للجهات التي تملك كل دور وما إذا كانت لا تزال بحاجة إليه.

ينبغي لفرق الكريبتو مراجعة الأدوار بعد تغييرات التوظيف ومغادرة الموظفين وتغييرات الموردين والحوادث والتدقيق وإطلاق المنتجات.

ينبغي إزالة الأدوار القديمة بسرعة عندما يغيّر الأشخاص وظائفهم أو يغادرون المؤسسة.

ينبغي أن تنتهي الأدوار المؤقتة تلقائيًا متى أمكن.

ينبغي أن تخضع الأدوار ذات الصلاحيات الخاصة لمراجعة أشد من أدوار القراءة فقط.

وينبغي مراجعة حسابات الخدمة والروبوتات كما تُراجع حسابات المستخدمين.

ينبغي أن تشمل المراجعات الأذونات على السلسلة وخارجها.

تنشأ إخفاقات أمنية كثيرة بسبب عدم إلغاء صلاحيات الوصول القديمة.

RBAC وحسابات الخدمة

حسابات الخدمة حسابات غير بشرية تستخدمها التطبيقات أو الروبوتات أو النصوص البرمجية أو خدمات البنية التحتية.

وهي شائعة في أنظمة الكريبتو، لأن كثيرًا من المهام مؤتمتة.

قد يحتاج روبوت مراقبة الأسعار إلى صلاحية القراءة.

وقد تحتاج خدمة ترحيل المعاملات إلى صلاحية البث.

وقد يحتاج خط نشر إلى صلاحية تحديث عقود التجهيز.

ومن الأخطاء الخطيرة منح حسابات الخدمة أدوارًا إدارية واسعة لمجرد التسهيل.

ينبغي أن تكون لحسابات الخدمة أذونات محدودة وتدوير للمفاتيح وقواعد انتهاء صلاحية وقيود شبكية ومراقبة.

إذا كان الروبوت يحتاج إلى قراءة الأرصدة فقط، فلا ينبغي أن يتمكن من نقل الأموال.

تحتاج الهويات الآلية إلى الانضباط نفسه في RBAC الذي تحتاج إليه هويات البشر.

RBAC والتفويض على مستوى الكائنات

يحدد RBAC ما إذا كان الدور يستطيع تنفيذ إجراء، بينما يحدد التفويض على مستوى الكائن ما إذا كان يستطيع تنفيذ ذلك الإجراء على كائن بعينه.

هذا التمييز مهم في واجهات API ولوحات التحكم الخاصة بالكريبتو.

قد يُسمح لمستخدم يحمل دور العميل بعرض تفاصيل الحساب، لكن حسابه هو فقط.

وقد يُسمح لمشغّل الخزينة بعرض طلبات الدفع، لكن للخزينة التي يديرها فقط.

وقد يُسمح لمفوّض DAO بالتصويت، لكن بوزن التصويت المسند إلى تلك المحفظة فقط.

تحذر OWASP من ضرورة مراعاة فحوصات التفويض على مستوى الكائن في كل وظيفة تصل إلى مصدر بيانات باستخدام معرّف يقدمه المستخدم.

لا يكفي RBAC وحده إذا لم يُتحقق من ملكية الكائن.

تجمع الأنظمة الآمنة بين التحقق من الدور والتحقق من المورد المحدد.

RBAC والتحكم في الوصول القائم على السمات

يمنح التحكم في الوصول القائم على السمات، المعروف غالبًا باسم ABAC، صلاحيات الوصول استنادًا إلى السمات لا إلى الأدوار وحدها.

وقد تشمل السمات موقع المستخدم أو درجة مخاطر المحفظة أو الوقت أو الجهاز أو حجم المعاملة أو نوع الأصل أو حالة KYC أو سياق الطلب.

يكون RBAC أبسط لأنه يستخدم أدوارًا محددة مسبقًا.

وقد يكون ABAC أكثر مرونة لأنه يراعي الظروف.

قد تستخدم منصة كريبتو RBAC لأذونات الوظائف الأساسية وABAC للضوابط القائمة على المخاطر.

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

يمكن استخدام RBAC وABAC معًا.

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

RBAC والتحكم في الوصول القائم على السياسات

يستخدم التحكم في الوصول القائم على السياسات قواعد رسمية لتحديد ما إذا كان ينبغي السماح بالوصول.

قد يكون RBAC جزءًا من نظام قائم على السياسات.

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

يفيد ذلك في عمليات الكريبتو التي يعتمد فيها القرار على السياق.

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

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

لكن يجب أن تكون السياسات مفهومة وقابلة للاختبار.

وقد تنشئ السياسة المربكة ثغرات خفية في التفويض.

RBAC والثقة الصفرية

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

يدعم RBAC الثقة الصفرية عبر اشتراط أذونات صريحة لكل إجراء حساس.

لا ينبغي للمطور داخل شبكة الشركة أن يحصل تلقائيًا على صلاحية الوصول إلى الإنتاج.

ولا ينبغي لخادم داخل حساب سحابي أن يحصل تلقائيًا على صلاحية الوصول إلى مفاتيح التوقيع.

ولا ينبغي لعنوان محفظة سجّل الدخول مرة واحدة أن يحصل على صلاحيات المسؤول إلى الأبد.

تتطلب الثقة الصفرية أيضًا التحقق المستمر والتسجيل وفحوصات الأجهزة وحدود الجلسات والحد الأدنى من الصلاحيات.

لا يمثل RBAC نموذج الثقة الصفرية بأكمله، لكنه من مكوناته الأساسية.

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

RBAC في أنظمة المحافظ والحسابات

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

قد ينشئ شخص معاملة ويوافق عليها شخص آخر، بينما يقتصر دور شخص ثالث على عرض الأرصدة.

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

قد يشمل RBAC في المحافظ حدود الإنفاق وقوائم العناوين المسموح بها والموافقات القائمة على الأدوار وقيود الأجهزة وسياسات المعاملات.

تفيد هذه الضوابط خصوصًا في عمليات الخزينة والحفظ الذاتي للمؤسسات.

لكن يجب دعم RBAC في المحافظ بإدارة آمنة للمفاتيح.

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

ينبغي إنفاذ RBAC القوي في المحافظ عبر بنية التوقيع، لا عبر واجهة المستخدم وحدها.

RBAC في الجسور

غالبًا ما تتطلب جسور الكريبتو أدوارًا للمرحّلين والحراس والمدققين ومطوري الترقيات والمسؤولين عن الإيقاف ومستجيبي الطوارئ.

تتسم صلاحيات RBAC في الجسور بحساسية بالغة، لأن الجسور قد تتحكم في كميات كبيرة من الأصول المقفلة أو الممثلة.

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

ينبغي فصل أدوار الجسر ومراقبتها بعناية.

ولا ينبغي أن يتحكم دور التحقق من الرسائل تلقائيًا في الترقيات.

كما لا ينبغي أن يتمكن دور الإيقاف الطارئ تلقائيًا من نقل الأموال المقفلة.

ينبغي أن تخضع أدوار الترقية لفترات تأخير ملزمة وموافقات متعددة التوقيع متى أمكن.

ينبغي لمستخدمي الجسر التحقق من توثيق صلاحيات الأدوار قبل الوثوق به.

RBAC في الرول أب وشبكات Layer 2

غالبًا ما تستخدم الرول أب وشبكات Layer 2 أدوارًا للمُسلسِلات ومقدمي المقترحات والمعترضين والمُثبِتين والحراس ومطوري الترقيات ومديري الجسور.

تؤثر هذه الأدوار في استمرارية التشغيل ومقاومة الرقابة وتقديم البراهين والترقيات والسحوبات.

قد يجعل دور المُسلسِل المركزي الشبكة سريعة، لكنه قد ينشئ مخاطر في ترتيب المعاملات.

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

وقد يوقف دور الحارس النظام مؤقتًا أثناء الطوارئ، لكنه قد يقيد نشاط المستخدمين أيضًا.

ينبغي الإفصاح بوضوح عن RBAC في الرول أب، لأن المستخدمين بحاجة إلى معرفة الجهات التي تستطيع تغيير النظام.

قد تجعل الفترات الزمنية الملزمة والمراقبة العامة هذه الأدوار أكثر أمانًا.

ينبغي ألا تصرف الرسوم المنخفضة انتباه المستخدمين عن مخاطر الأذونات والترقية.

RBAC في الأصول الحقيقية المرمزة

غالبًا ما تحتاج الأصول الحقيقية المرمزة إلى أدوار للمُصدِرين ووكلاء التحويل ومراجعي الامتثال وأمناء الحفظ والمدققين ومسؤولي الاسترداد.

قد تتحكم هذه الأدوار في السك والحرق وقيود التحويل وتقارير الاحتياطيات وموافقات الاسترداد وأهلية المستخدمين.

قد يساعد RBAC على تطبيق المتطلبات القانونية والتشغيلية.

لكنه قد ينشئ مركزية أيضًا، لأن بعض الأدوار قد تجمد التحويلات أو تحظر العناوين.

ينبغي للمستخدمين معرفة ما إذا كان للأصل أدوار تستطيع تقييد الملكية أو الاسترداد.

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

غالبًا ما يكون RBAC ضروريًا للأصول المنظمة.

والسؤال المهم هو ما إذا كانت صلاحيات الأدوار معلنة وتخضع لحوكمة مسؤولة.

خطوات تطبيق RBAC

الخطوة الأولى هي إعداد قائمة بكل إجراء حساس في النظام.

والثانية هي تجميع الإجراءات في أدوار وفق مهام العمل الفعلية.

والثالثة هي إزالة الأذونات غير الضرورية من كل دور.

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

والخامسة هي إضافة مسارات موافقة للإجراءات عالية المخاطر.

والسادسة هي تسجيل كل إسناد للأدوار وكل إجراء ذي صلاحيات خاصة.

والسابعة هي مراجعة الأدوار بانتظام.

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

أفضل ممارسات RBAC لفرق الكريبتو

طبّق مبدأ الحد الأدنى من الصلاحيات على كل دور.

افصل المهام المتعلقة بالخزينة والترقيات والعمليات والدعم.

استخدم المحافظ متعددة التوقيع والفترات الزمنية الملزمة للأدوار عالية المخاطر.

استخدم التوقيع المدعوم بالأجهزة أو أنظمة إدارة المفاتيح الآمنة للحسابات ذات الصلاحيات الخاصة.

سجّل جميع عمليات منح الأدوار وإلغائها والموافقات والإجراءات الحساسة.

راجع إسناد الأدوار بعد تغييرات الفريق والحوادث.

اختبر منطق التحكم في الوصول قبل النشر على الشبكة الرئيسية.

وثّق صلاحيات الأدوار كي يفهم المستخدمون والمدققون نموذج الثقة.

أفضل ممارسات RBAC للعقود الذكية

عرّف الأدوار كثوابت واضحة الأسماء.

احمِ كل وظيفة ذات صلاحيات خاصة بفحوصات الأدوار.

خصص غرضًا محدودًا لكل دور.

تجنب استخدام دور مسؤول افتراضي واحد لجميع الإجراءات طويلة الأجل من دون ضمانات.

استخدم محافظ متعددة التوقيع لحاملي الأدوار ذات الصلاحيات الخاصة.

أضف فترات تأخير ملزمة للتغييرات الخطرة متى أمكن.

أصدر أحداثًا عند منح الأدوار أو إلغائها أو استخدامها في إجراءات مهمة.

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

أخطاء RBAC

من الأخطاء الشائعة منح جميع الموظفين صلاحية المسؤول لمجرد التسهيل.

ومنها أيضًا نسيان إلغاء الأدوار بعد مغادرة أحد أعضاء الفريق.

ومنها السماح لدور واحد بسك التوكنات وترقية العقود وإيقاف التحويلات ونقل الأموال.

ومنها التحقق من الدور من دون التحقق من الكائن المحدد الذي يجري الوصول إليه.

ومنها منح الروبوتات وحسابات الخدمة أذونات مفرطة.

ومنها إنشاء أدوار طوارئ من دون حدود واضحة.

ومنها الاعتماد على الواجهة الأمامية وحدها لإنفاذ الأذونات، مع غياب الفحوصات الفعلية في العقد الذكي أو API.

ومنها عدم تسجيل تغييرات الأدوار.

إشارات تحذيرية في RBAC

من الإشارات التحذيرية أن يتحكم مفتاح خاص واحد في دور المسؤول.

ومنها عقد ذكي يستطيع فيه الدور نفسه سك التوكنات وحرقها وإيقافها وترقية العقود وسحب الأموال.

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

ومنها واجهة API يكشف فيها تغيير معرّف في الطلب بيانات مستخدم آخر.

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

ومنها جسر لا تتضح فيه صلاحيات المرحّلين أو الحراس أو مطوري الترقيات.

ومنها لجنة DAO تستطيع إنفاق أموال الخزينة من دون حدود معلنة.

ومنها نظام أدوار بلا مراجعة أو انتهاء صلاحية أو سجلات تدقيق.

فوائد RBAC

الفائدة الأولى لـ RBAC هي تبسيط إدارة الأذونات.

والثانية هي تقليل الضرر الناجم عن اختراق الحسابات.

والثالثة هي وضوح فصل المهام.

والرابعة هي تسهيل التدقيق.

والخامسة هي دعم نمو الفريق على نحو أفضل.

والسادسة هي تعزيز التحكم في إدارة العقود الذكية.

والسابعة هي جعل عمليات الخزينة والبنية التحتية أكثر أمانًا.

تزداد أهمية هذه الفوائد في الكريبتو، لأن الإخفاقات الأمنية قد تنقل قيمة حقيقية بسرعة وبصورة دائمة.

قيود RBAC

قد يصبح RBAC معقدًا أكثر من اللازم إذا أنشأ المشروع أدوارًا كثيرة جدًا.

وقد تصبح صلاحياته واسعة أكثر من اللازم إذا لم تُصمم الأدوار بعناية.

وقد يفشل إذا نسي المطورون إنفاذ فحوصات الأدوار في الشفرة.

وقد يفشل إذا لم تُلغَ الأدوار القديمة.

وقد يفشل إذا تحكم دور مسؤول واحد في جميع الأدوار الأخرى من دون ضمانات.

وقد يفشل إذا شارك المستخدمون الحسابات أو المفاتيح الخاصة.

وقد يفشل عند غياب التفويض على مستوى الكائنات.

يُعد RBAC ضابطًا قويًا، لكن يجب تنفيذه واختباره ومراقبته وصيانته.

RBAC وثقة المستخدمين

غالبًا ما يتعذر على المستخدمين رؤية جميع الأذونات الداخلية في شركة كريبتو أو بروتوكول.

لكن العقود الذكية العامة ووثائق الحوكمة وتقارير الأمان والإفصاحات عن التدقيق قد توضح صلاحيات الأدوار المهمة.

يسهل تقييم المشروع عندما يشرح الأدوار بوضوح.

أما إخفاء الصلاحيات الإدارية فيزيد مخاطر الثقة.

ينبغي للمستخدمين السؤال عمن يستطيع ترقية العقود أو إيقاف التحويلات أو سك التوكنات أو تغيير الرسوم أو تجميد الأصول أو نقل أموال الخزينة.

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

تساعد شفافية RBAC المستخدمين على تقييم اللامركزية والسلامة التشغيلية.

تتعزز الثقة عندما تكون حدود الأذونات واضحة ومحدودة.

مفاهيم خاطئة شائعة حول RBAC

من المفاهيم الخاطئة الشائعة أن وجود الأدوار يجعل النظام آمنًا بالكامل.

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

ومن المفاهيم الخاطئة أيضًا أن RBAC يقتصر على الشركات ولا يشمل العقود الذكية.

تحتاج العقود الذكية أيضًا إلى أذونات قائمة على الأدوار للسك والإيقاف والترقية وتنفيذ الحوكمة.

ومن المفاهيم الخاطئة أن دور مسؤول واحد يكفي لأنظمة الكريبتو المخصصة للإنتاج.

قد يؤدي دور إداري واسع واحد إلى نقطة إخفاق منفردة خطرة.

ومن المفاهيم الخاطئة أن RBAC يحل محل المحافظ متعددة التوقيع.

يعالج RBAC والمحافظ متعددة التوقيع مشكلتين مختلفتين، وغالبًا ما يكون الجمع بينهما هو الأفضل.

أهمية التحكم في الوصول القائم على الأدوار (RBAC) للإجابات ومحركات البحث

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

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

كما يبحث الناس عن RBAC لفهم أذونات العقود الذكية.

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

وقد يبحث الناس عن RBAC لتقييم مخاطر منصة أو بروتوكول.

والإجابة المفيدة هي أن RBAC القوي يقلل نقاط الإخفاق المنفردة، بينما قد يخفي RBAC الضعيف صلاحيات إدارية خطرة.

والدرس الأساسي لمستخدمي الكريبتو بسيط.

لا يحمي RBAC أنظمة الكريبتو إلا عندما تكون الأدوار محدودة وشفافة وخاضعة للمراقبة ومدعومة بإدارة قوية للمفاتيح وضوابط للموافقة.

الأسئلة الشائعة

ماذا يعني التحكم في الوصول القائم على الأدوار (RBAC)؟

يعني التحكم في الوصول القائم على الأدوار (RBAC) إسناد الأذونات إلى أدوار، ثم منح المستخدمين أو الحسابات تلك الأذونات عبر إسنادهم إلى الأدوار.

إلى ماذا يشير الاختصار RBAC؟

يشير RBAC إلى Role-Based Access Control.

لماذا يُعد RBAC مهمًا في الكريبتو؟

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

كيف يُستخدم RBAC في العقود الذكية؟

تستخدم العقود الذكية RBAC لتقييد الوظائف ذات الصلاحيات الخاصة بالحسابات التي تملك أدوارًا محددة، مثل المُصدِر أو المسؤول عن الإيقاف أو مطور الترقية أو الحارس أو المرحّل أو المسؤول.

ما الفرق بين RBAC وOwnable؟

يمنح Ownable عادةً التحكم لحساب مالك واحد، بينما يتيح RBAC إنشاء أدوار متعددة بأذونات مختلفة.

ما الحد الأدنى من الصلاحيات في RBAC؟

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

ما الدور في RBAC؟

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

ما الإذن في RBAC؟

الإذن هو القدرة على تنفيذ إجراء محدد على مورد محمي.

هل يمنع RBAC جميع عمليات الاختراق في الكريبتو؟

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

لماذا تُعد محفظة مسؤول واحدة خطرة؟

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

هل ينبغي استخدام RBAC مع المحافظ متعددة التوقيع؟

نعم، ينبغي غالبًا إخضاع الأدوار عالية المخاطر لمحافظ متعددة التوقيع وفترات زمنية ملزمة ومسارات للموافقة.

ما أحد الأخطاء الشائعة في RBAC؟

من الأخطاء الشائعة منح عدد كبير من المستخدمين أو حسابات الخدمة أو أدوار العقود الذكية صلاحيات إدارية واسعة.

كيف يمكن للمستخدمين تقييم مخاطر RBAC؟

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

الخاتمة

يُعد التحكم في الوصول القائم على الأدوار (RBAC) نموذجًا أمنيًا أساسيًا لأنظمة العملات المشفرة، إذ يحدد من يستطيع تنفيذ ماذا عبر العقود الذكية وواجهات API والمحافظ والخزائن والبنية التحتية للمدققين والجسور ومنظمات DAO والمنصات الداخلية.

يعزز RBAC الأمان عبر إسناد الأذونات إلى الأدوار، بدلًا من منح كل شخص أو حساب صلاحيات مباشرة ومخصصة.

وهو يدعم الحد الأدنى من الصلاحيات وفصل المهام وقابلية التدقيق ومسارات العمل التشغيلية الأكثر أمانًا.

في العقود الذكية، يمكن لـ RBAC التحكم في السك والإيقاف والترقية وتنفيذ الحوكمة والجسور والاستجابة للطوارئ.

وفي البنية التحتية خارج السلسلة، يمكن لـ RBAC حماية واجهات API والخوادم ومجموعات الحوسبة السحابية وأدوات الدعم وأنظمة إدارة المفاتيح وعمليات الخزينة.

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

تنبع أكبر مخاطر RBAC من الأدوار الإدارية المفرطة الصلاحيات وغياب فحوصات التفويض والصلاحيات القديمة والوصول المفرط لحسابات الخدمة وصلاحيات الترقية المخفية.

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