ما هو AuthZ (التفويض)؟

ما هو AuthZ، وكيف يختلف عن AuthN؟#

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

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

كيف يعمل AuthZ؟#

التفويض منفصل عن المصادقة ولكن غالبًا ما يرتبط بها. فمثلاً، البروتوكولات المعيارية مثل OAuth 2.0، OIDC، و SAML تدمج آليات التفويض القائمة على الرموز.

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

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

إليك تدفق عام خطوة بخطوة لكيفية عمل التفويض:

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

لفهم تدفق طلب التفويض في OAuth 2.0 بالتفصيل، تحقق من طلب التفويض

ما هي أنواع التفويض؟#

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

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

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

1. الموضوعات: يمكن أن يكونوا مستخدمين أو كيانات غير بشرية، مثل user أو machine-to-machine application.
2. الأدوار: تمثل الوظائف أو المسؤوليات. مثال، admin member
3. الأذونات: تحدد ما هي الإجراءات المسموح بها على موارد معينة، مثل read: order.

التحكم في الوصول بالاعتماد على السمات وكيف يعمل#

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

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

يمكن تصميم السمات بالطرق التالية:

1. سمات المستخدم: الدور (مثلاً، “مدير”، “مهندس”)، الموقع (مثلاً، “الولايات المتحدة”، “أوروبا”).
2. سمات الموارد: نوع المستند (مثل، “تقرير مالي”، “ملف تصميم”)، مستوى التصنيف (مثل، “سري”).
3. سمات البيئة: وقت الوصول (مثل، “خلال ساعات العمل”)، نوع الجهاز (مثل، “كمبيوتر محمول الشركة”).

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

استخدامات AuthZ وأمثلة#

برمجيات B2C#

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

تطبيق B2B متعدد المستأجرين#

غالبًا ما تستخدم تطبيقات B2B بنية متعددة المستأجرين، حيث يمثل كل مستأجر منظمة. داخل المنظمة، هناك حاجة لأدوار مثل المسؤول والعضو. هنا يلعب التفويض (AuthZ) دورًا رئيسيًا في إدارة المستخدمين على مستوى المنظمة، غالبًا باستخدام التحكم في الوصول القائم على الأدوار (RBAC).

تفويض الجهاز للجهاز#

الاتصال بين الأجهزة يحدث مباشرة بين الخدمات دون تفاعل بشري. على سبيل المثال، الاتصال بخدمات API. غالبًا ما يتضمن الرموز (مثل، رموز الوصول لOAuth 2.0) لضمان الوصول الآمن والديناميكي والدقيق.

ما هي أفضل الممارسات لAuthZ؟#

إليك بعض أفضل الممارسات للتفويض (authZ) لضمان التحكم الآمن والفعال في الوصول:

• مبدأ الأقل امتيازًا

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

• استخدم التفويض القائم على الرموز

  يوفر التحكم في الوصول القائم على الرموز مزيدًا من المرونة والتحكم الدقيق أثناء الالتزام بالمعايير المفتوحة. استخدام الرموز الآمنة (مثل، OAuth 2.0، JWTs) لمنح وصول محدد الوقت والنطاق.

• المراجعة والرقابة بانتظام

  يعد مراجعة سجلات الوصول وسياسات التفويض بانتظام ضروريًا لاكتشاف الشذوذ أو الأذونات القديمة.

• تطبيق الفصل بين الواجبات

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

• دعم تعددية المستأجرين (إذا كان ذلك ممكنًا)

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

• إلغاء الوصول ديناميكيًا

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

ما الفرق بين AuthZ (التفويض) مقابل Auth (المصادقة)؟#

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

AuthN (المصادقة) يجيب على السؤال، “من أنت وأي هوية تمتلكها” وهو عملية التحقق من هوية مستخدم أو خدمة أو جهاز. تضمن المصادقة أن الكيان الذي يحاول الوصول إلى نظام أو مورد هو أصيل. تشمل الطرق الشائعة كلمات المرور، والقياسات الحيوية، والمصادقة ذات العاملين (2FA). على سبيل المثال، عند تسجيل الدخول إلى حساب باستخدام بريدك الإلكتروني وكلمة المرور، يؤكد النظام هويتك من خلال المصادقة.

AuthZ (التفويض) يجيب على السؤال، “ما الذي يسمح لك بفعله؟” وهي عملية منح أو رفض الوصول إلى الموارد بناءً على أذونات أو أدوار المستخدم. يحدث التفويض بعد المصادقة ويحدد ما هي الإجراءات التي يمكن للمستخدم المصادق عليه القيام بها. على سبيل المثال، بعد تسجيل الدخول، قد يكون للمستخدم الإداري حق الوصول لتعديل الإعدادات، بينما يمكن للمستخدم العادي فقط عرضها.

باختصار، تؤكد AuthN (المصادقة) الهوية، بينما تحدد AuthZ (التفويض) الوصول. تحدث المصادقة أولاً، تليها التفويض لضمان الاستخدام الآمن والمناسب للموارد.

بناء AuthZ (التفويض) باستخدام Logto#

تقدم Logto Cloud خدمات تفويض رئيسية بناءً على البروتوكولات المعيارية المفتوحة مثل OIDC، OAuth 2.0، و SAML. تشمل الميزات التحكم في الوصول القائم على الأدوار، المنظمات (تعددية المستأجرين)، و مطالبات الرموز المخصصة لتلبية احتياجات التفويض الخاصة بك من عدة مناظير.