استكشاف تعريف AuthZ، وAuthN مقابل AuthZ، وكيفية عمل AuthZ، وأفضل الممارسات للتفويض.
AuthZ هو اختصار ل التفويض. التفويض هو آلية منفصلة عن المصادقة. بينما تحدد المصادقة من أنت، يحدد التفويض ما إذا كان بإمكانك الوصول إلى موارد محددة والإجراءات التي يمكنك القيام بها عليها.
في أمثلة العالم الحقيقي، يمكن أن تشمل الموارد البرمجيات والأنظمة والمستندات والطلبات والأصول. يضيف التفويض طبقة إضافية من التحكم، تحدد من يمكنه الوصول إلى هذه الموارد وتحت أي شروط.
التفويض منفصل عن المصادقة ولكن غالبًا ما يرتبط بها. فمثلاً، البروتوكولات المعيارية مثل OAuth 2.0، OIDC، و SAML تدمج آليات التفويض القائمة على الرموز.
في نظام التفويض القائم على الرموز، يمنح خادم التفويض رمز وصول للمستخدمين. هذا الرمز، الذي يتضمن الأذونات، يحدد ما إذا كان بإمكان المستخدم الوصول إلى موارد معينة.
قد يكون تخصيص الأذونات مباشرة للمستخدمين غير فعال، خاصة عندما تكون هناك حاجة لشروط أكثر تفصيلاً. على سبيل المثال، قد يعتمد الوصول على ظروف معينة، مثل موقع المستخدم، مما يجعل سياسات التحكم في الوصول ضرورية لإدارة الأذونات بشكل أفضل.
إليك تدفق عام خطوة بخطوة لكيفية عمل التفويض:
لفهم تدفق طلب التفويض في OAuth 2.0 بالتفصيل، تحقق من طلب التفويض
التحكم في الوصول القائم على الأدوار (RBAC) يستخدم الأدوار لإدارة الوصول. يتم تعيين واحد أو أكثر من الأدوار المحددة مسبقًا لكل مستخدم، ويتضمن كل دور مجموعة من الأذونات. المفتاح لفهم RBAC هو فهم العلاقة بين الموضوعات (أو المستخدمين)، الأدوار، والأذونات.
لفهم كيفية عمل التحكم في الوصول القائم على الأدوار (RBAC)، تحتاج إلى معرفة:
user أو machine-to-machine application.admin memberread: order.
التحكم في الوصول بالاعتماد على السمات (ABAC) يستخدم على نطاق واسع في التفويض ويدعم السيناريوهات الأكثر تعقيدًا باستخدام سمات محددة لكيان، بجانب الأدوار فقط.
على سبيل المثال، تدير شركة منصة مشاركة مستندات عالمية حيث يحتاج الموظفون إلى وصول محكوم إلى الملفات الحساسة بناءً على دور وظيفي، الموقع، ومستوى تصنيف المستند.
يمكن تصميم السمات بالطرق التالية:
هناك أيضًا نماذج أخرى للتحكم في الوصول مثل التحكم في الوصول القائم على السياسات (PBAC). لكل نموذج نقاط قوة وضعف، ويعتمد اختيار النموذج على حالتك واستخدامك ومتطلباتك.
غالبًا ما تتطلب برمجيات B2C أدوارًا خاصة بناءً على احتياجات العمل. على سبيل المثال، قد يتضمن تطبيق إدارة متجر الكتب أدوارًا ذات مسؤوليات مختلفة، مثل إدارة الموارد والخدمات.
غالبًا ما تستخدم تطبيقات B2B بنية متعددة المستأجرين، حيث يمثل كل مستأجر منظمة. داخل المنظمة، هناك حاجة لأدوار مثل المسؤول والعضو. هنا يلعب التفويض (AuthZ) دورًا رئيسيًا في إدارة المستخدمين على مستوى المنظمة، غالبًا باستخدام التحكم في الوصول القائم على الأدوار (RBAC).
الاتصال بين الأجهزة يحدث مباشرة بين الخدمات دون تفاعل بشري. على سبيل المثال، الاتصال بخدمات API. غالبًا ما يتضمن الرموز (مثل، رموز الوصول لOAuth 2.0) لضمان الوصول الآمن والديناميكي والدقيق.
إليك بعض أفضل الممارسات للتفويض (authZ) لضمان التحكم الآمن والفعال في الوصول:
مبدأ الأقل امتيازًا
يضمن هذا تقليل خطر الوصول غير المصرح به أو الضرر من الحسابات التي تم اختراقها. يجب على المستخدمين والأنظمة الوصول فقط إلى الموارد والإجراءات اللازمة لدورهم.
استخدم التفويض القائم على الرموز
يوفر التحكم في الوصول القائم على الرموز مزيدًا من المرونة والتحكم الدقيق أثناء الالتزام بالمعايير المفتوحة. استخدام الرموز الآمنة (مثل، OAuth 2.0، JWTs) لمنح وصول محدد الوقت والنطاق.
المراجعة والرقابة بانتظام
يعد مراجعة سجلات الوصول وسياسات التفويض بانتظام ضروريًا لاكتشاف الشذوذ أو الأذونات القديمة.
تطبيق الفصل بين الواجبات
ابدأ بتطبيق الأذونات الدقيقة، مثل تحديد إجراءات وموارد محددة (مثل، القراءة، الكتابة، الحذف). عند إنشاء الأدوار، استخدم أسماء أدوار واضحة وفرض الفصل بين الواجبات للحد من خطر الاحتيال أو الأخطاء من مستخدم واحد.
دعم تعددية المستأجرين (إذا كان ذلك ممكنًا)
بالنسبة للأنظمة متعددة المستأجرين، يكون العزل بين المستأجرين مهمًا. من خلال دمجه مع التحكم في الوصول القائم على الأدوار، يمكنك تحقيق فصل موارد البيانات، والتأكد من أن الأدوار المناسبة يمكنها الوصول إلى الموارد فقط داخل مستأجرها. هذا يمنع الوصول العرضي أو الخبيث إلى موارد المستأجرين الآخرين.
إلغاء الوصول ديناميكيًا
عندما تقوم بتصميم نظام AuthZ الخاص بك، تأكد من أنه يمكن تحديث الأذونات أو إلغاؤها فورًا إذا تغيرت الظروف (مثلا، تحديثات الأدوار، أو إنهاء التوظيف). يمكن تحقيق ذلك من خلال الفحوصات الديناميكية للواجهة البرمجية، الويب هوك، أو طرق أخرى. الهدف هو منع الوصول غير المصرح به في الوقت الفعلي.
الفرق بين المصادقة والتفويض يكمن في الغرض والعملية داخل إدارة الهوية والوصول.
AuthN (المصادقة) يجيب على السؤال، “من أنت وأي هوية تمتلكها” وهو عملية التحقق من هوية مستخدم أو خدمة أو جهاز. تضمن المصادقة أن الكيان الذي يحاول الوصول إلى نظام أو مورد هو أصيل. تشمل الطرق الشائعة كلمات المرور، والقياسات الحيوية، والمصادقة ذات العاملين (2FA). على سبيل المثال، عند تسجيل الدخول إلى حساب باستخدام بريدك الإلكتروني وكلمة المرور، يؤكد النظام هويتك من خلال المصادقة.
AuthZ (التفويض) يجيب على السؤال، “ما الذي يسمح لك بفعله؟” وهي عملية منح أو رفض الوصول إلى الموارد بناءً على أذونات أو أدوار المستخدم. يحدث التفويض بعد المصادقة ويحدد ما هي الإجراءات التي يمكن للمستخدم المصادق عليه القيام بها. على سبيل المثال، بعد تسجيل الدخول، قد يكون للمستخدم الإداري حق الوصول لتعديل الإعدادات، بينما يمكن للمستخدم العادي فقط عرضها.
باختصار، تؤكد AuthN (المصادقة) الهوية، بينما تحدد AuthZ (التفويض) الوصول. تحدث المصادقة أولاً، تليها التفويض لضمان الاستخدام الآمن والمناسب للموارد.
تقدم Logto Cloud خدمات تفويض رئيسية بناءً على البروتوكولات المعيارية المفتوحة مثل OIDC، OAuth 2.0، و SAML. تشمل الميزات التحكم في الوصول القائم على الأدوار، المنظمات (تعددية المستأجرين)، و مطالبات الرموز المخصصة لتلبية احتياجات التفويض الخاصة بك من عدة مناظير.