أذونات NestJS API: الأدوار ليست سوى بداية عزل المستأجر
افهم الفرق بين المصادقة والتحقق من الأدوار وملكية الموارد عند إنشاء واجهة برمجة تطبيقات أعمال تستخدمها العديد من المؤسسات.
مساحة عمل لتطوير البرمجيات توضح تطوير التطبيقات الخلفية.
هوية منفصلة عن إذن
تحدد المصادقة من يتعرف عليه التطبيق باعتباره المتصل. يحدد التفويض ما قد يفعله هذا المتصل. لا تعد الجلسة أو الرمز المميز الصالح إذنًا لقراءة كل سجل عميل. في واجهة برمجة تطبيقات الأعمال، قد يتمتع المستخدمون بقدرات مختلفة وينتمون إلى مؤسسات مختلفة. قم بتمثيل هذه الحقائق بوضوح قبل كتابة عمليات التحقق من المسار. يوفر NestJS وحدات بناء يمكنها دعم الترخيص، لكن إطار العمل لا يعرف حدود عملك. يجب أن يحدد التطبيق كيفية ارتباط الهوية التي تم التحقق منها بالعضويات والعمليات والموارد المحددة المطلوبة.
تحديد الأدوار من حيث المسؤوليات الحقيقية
الأدوار مثل المسؤول والوكيل والعارض تكون مفيدة فقط عندما تكون قدراتهم واضحة. اكتب مصفوفة إذن باستخدام إجراءات ملموسة: قم بدعوة زميل أو قراءة مشروع أو تغيير حالته أو تصدير المستندات. تجنب إنشاء دور جديد لكل استثناء صغير حتى يصبح من المستحيل التفكير في النموذج. تتطلب بعض القرارات سياقًا أكبر من تسمية الدور، مثل تعيين المشروع أو ملكيته. اجعل القواعد مفهومة لأصحاب المصلحة في الأعمال حتى يمكن مراجعة التغييرات دون الاعتماد كليًا على المعرفة المخفية داخل رمز وحدة التحكم.
لا تخلط بين مسؤول المستأجر ومسؤول عمومي
يجوز لمسؤول مؤسسة العميل إدارة المستخدمين داخل تلك المؤسسة دون الحصول على السلطة على النظام الأساسي بأكمله. اجعل هذا النطاق واضحًا في عمليات التحقق من البيانات والتفويض. لا تستخدم علامة مسؤول واحدة غامضة للحصول على امتيازات غير ذات صلة. تحتاج تغييرات العضوية وإزالة الحساب إلى سلوك محدد. اختبار ما إذا كان المستخدم الذي ينتمي إلى عدة مؤسسات يمكنه تبديل السياق بأمان. يجب أن يوجه السياق المحدد الطلب، بينما يتحقق الخادم بشكل مستقل من عضوية المتصل والعملية المسموح بها بدلاً من الثقة في معرف المؤسسة المقدم من المتصفح.
استخدم الحراس لإجراء الفحوصات المناسبة على مستوى الطلب
يمكن للحارس تحديد ما إذا كان الطلب سيصل إلى المعالج وفقًا لقواعد التطبيق. يعد هذا مكانًا مفيدًا للمصادقة العامة أو عمليات التحقق من القدرة، ولكن قرارات الموارد قد تتطلب بيانات يجب أن تقوم الخدمة بتحميلها بأمان. تجنب تشتيت القواعد غير المتوافقة بين وحدات التحكم والخدمات. حدد حدود ترخيص واضحة وأعد استخدامها عند الاقتضاء. يجب ألا يتجاوز المسار الآخر أو المهمة المجدولة أو المكالمة الداخلية عن طريق الخطأ قاعدة مهمة لمجرد أن التنفيذ الأصلي يفترض أن كل طلب سيدخل دائمًا من خلال طريقة تحكم معينة.
نطاق الوصول إلى البيانات إلى الموارد المعتمدة
القائمة التي تمت تصفيتها حسب المؤسسة لا تحمي نقطة نهاية التفاصيل التي تقبل أي معرف سجل. قم بتطبيق النطاق المناسب على عمليات القراءة والكتابة، بما في ذلك السجلات ذات الصلة ومراجع الملفات. قد يكون تحميل المورد أولاً والتحقق منه لاحقًا محفوفًا بالمخاطر إذا أدى التسجيل أو أي تأثير جانبي آخر إلى كشف المعلومات بينهما. تصميم مسار الوصول عمدا. اختبر كلاً من المعرف الذي ينتمي إلى مؤسسة أخرى وموردًا ينتمي إلى نفس المؤسسة ولكن خارج نطاق المسؤولية المسموح بها للمتصل. إن عزل المستأجر والحقوق الخاصة بالعملية يحل المشكلات ذات الصلة ولكن المختلفة.
التحقق من صحة العلاقات وكذلك المعرفات الفردية
قد يحتوي الطلب على معرف مشروع ومعرف مستند صالحين ولكن لا ينتميان معًا. التحقق من علاقتهم ونطاق الوصول قبل ربطهم أو تحديثهم. وينطبق الشيء نفسه على المكلف من مؤسسة أخرى أو فاتورة مرفقة بعميل غير ذي صلة. يمكن أن تدعم قيود قاعدة البيانات الاتساق، ولكنها لا تحل محل قرار التطبيق بشأن من يمكنه تنفيذ الإجراء. تعامل مع الموارد المتداخلة والعمليات المجمعة بعناية، نظرًا لأن عنصرًا واحدًا معتمدًا لا ينبغي أن يجعل المجموعة المختلطة بأكملها مقبولة.
حماية الصادرات والتحميلات والعمل في الخلفية
يجب أن يمتد التفويض إلى ما هو أبعد من نقاط نهاية JSON العادية. يمكن أن تكشف تنزيلات الملفات وفهارس البحث والصادرات معلومات أكثر من صفحة التفاصيل. يجب أن تحافظ عملية التصدير في الخلفية على النطاق المسموح به للطالب وأن تحدد ما يحدث إذا تغير الوصول قبل تسليم الملف. تحتاج الملفات التي تم تحميلها إلى عمليات التحقق من الملكية والسياق أيضًا. يمكننا تصميم قواعد الوصول المشتركة التي تستخدمها هذه المسارات باستمرار. الواجهة الأمامية التي تخفي زر التصدير لا تحمي الطلب المباشر إلى نقطة نهاية التصدير أو عنوان URL للتخزين غير المقيد الذي أنشأه العامل.
حافظ على حقائق الترخيص محدثة بما يكفي لمواجهة المخاطر
تضع بعض أنظمة الهوية معلومات الدور أو العضوية داخل الرمز المميز. قرر كيف تصبح التغييرات فعالة وما إذا كانت العملية الحساسة يجب أن تستشير الحالة الحالية من جانب الخادم. قد تستمر المطالبات المخزنة مؤقتًا لفترة طويلة بعد العضوية التي تم إبطالها. يعتمد التصميم المناسب على التشغيل وإعداد الهوية. قم بتوثيق المقايضة بدلاً من افتراض أن كل مطالبة موقعة تظل مناسبة إلى الأبد. راجع أيضًا استرداد الحساب وتدفقات الدعوات، حيث لا يزال من الممكن تقويض واجهة برمجة التطبيقات المحمية بعناية من خلال دعوة تمنح وصولاً أوسع مما يُسمح للمدعو بتقديمه.
مثال: يقوم الوكيل بتغيير معرف المشروع
يمكن للوكيل قراءة المشروع المعين داخل مؤسسته. يقومون بتعديل عنوان URL للإشارة إلى مشروع مملوك لعميل آخر. يجب أن ترفض واجهة برمجة التطبيقات العملية وفقًا لسياسة الاستجابة الخاصة بها ويجب ألا تُرجع الحقول الخاصة أو المرفقات أو المعاينة المفيدة. كرر التمرين مع مشروع في نفس المؤسسة التي لم يتم تعيين الوكيل لها، إذا كانت المهمة مهمة. يختبر هذا السيناريو البسيط ما إذا كان التطبيق يفرض حدود المورد الفعلية بدلاً من مجرد التحقق من أن المتصل لديه دور وكيل.
سجل القرارات دون تسريب بيانات العمل
يمكن لسجلات العمليات تسجيل المعرفات ذات الصلة ونتائج القرارات ومعلومات الارتباط، ولكن يجب تجنب المحتوى الحساس غير الضروري. لا يبرر الطلب المرفوض تفريغ السجل المطلوب بالكامل في تقرير خطأ. حدد من يمكنه الوصول إلى سجلات الأمان والتدقيق ومدة الاحتفاظ بها. يساعد التسجيل المفيد في التحقيق في حالة الرفض غير المتوقع أو إساءة الاستخدام المحتملة دون إنشاء مخزن بيانات ثانٍ غير خاضع للرقابة. يمكنك التمييز بين فشل المصادقة ورفض الإذن وخطأ التحقق من صحة الأعمال حتى تتمكن فرق الدعم من الاستجابة من خلال العملية المناسبة.
ورشة العمل: بناء مصفوفة الأذونات عبر المنظمات
قم بإنشاء مؤسستين للعملاء والعديد من المستخدمين والموارد بمسؤوليات مختلفة. يقوم التمرين بقراءة وتحديث وتصدير ودعوات باستخدام كل دور. قم بتضمين محاولة العلاقة بين المؤسسات والعضوية التي تم إبطالها بين تحميل الصفحة والإرسال. التحقق من البيانات والملفات الناتجة، وليس رمز الاستجابة فقط. أبقِ السيناريوهات مرتبطة بحدود عمل ذات معنى. يوفر هذا أساسًا قابلاً للصيانة لعمليات التحقق من الانحدار عند تقديم مسارات أو عمال جدد، دون كتابة اختبارات تكرر فقط الحالة الدقيقة المرئية بالفعل في تطبيق الحماية.
الأسئلة المتداولة
هل يضمن RBAC عزل المستأجر؟ تحتاج الأدوار إلى فحوصات للتنظيم ونطاق الموارد. هل الرمز الصالح كافٍ لكل طلب؟ يجب أن تكون مطالباتها مناسبة للتشغيل ومتطلبات الوصول الحالية. هل يمكن للترخيص أن يعيش فقط في الواجهة الأمامية؟ يجب على الواجهة الخلفية فرض ذلك. ما الذي يمكن أن يطوره Tuplify Studio؟ خدمات NestJS وواجهات برمجة تطبيقات العملاء والتطبيقات متعددة المؤسسات مع نماذج أذونات صريحة. ابدأ بمصفوفة واضحة وفحوصات تمثيلية للموارد قبل إضافة تسلسلات هرمية معقدة للأدوار أو الكشف عن المزيد من نقاط نهاية التكامل.
ما يمكننا تطويره لك
يقوم Tuplify Studio بتطوير واجهات برمجة التطبيقات NestJS والواجهات الخلفية للأعمال وبوابات المؤسسات المتعددة مع قواعد ترخيص واضحة وعمليات تكامل ومراقبة تشغيلية.
لنتحدث عن مشروعكللمزيد · الوثائق الرسمية
NestJS — AuthorizationTuplify Studio · أدلة تعليمية أُعدت بمساعدة الذكاء الاصطناعي. الأمثلة توضيحية.
