المدوّنة · 19 سبتمبر 2023 · Steve Simpson · الهوية

نظرة معمّقة في أمان Salesforce: شرح المصادقة والتفويض

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

الأساسيات: المصادقة والتفويض

المصادقة (authentication) هي عملية التحقق من أن الكيان، سواء كان مستخدمًا في متصفح أو آلة تصل إلى النظام، هو فعلًا من يدّعي أنه هو. أما التفويض (authorization) فيحدد الإجراءات التي يُسمح للكيان المُصادَق عليه بتنفيذها داخل Salesforce. وكلاهما بالغ الأهمية لضمان بقاء بيانات Salesforce آمنة، وألا يصل إليها إلا المستخدمون والكيانات المصرّح لهم.

من المتصفحات إلى واجهات API: فهم نقاط الدخول

تضمن Salesforce أن تستخدم كل حركة البيانات الواردة SSL وTLS لنقل البيانات بأمان. (سنتناول هذين المصطلحين بالتفصيل في مقالة قادمة.)

عندما تتخيّل كيف تدخل البيانات إلى Salesforce، تصوّر مسارين رئيسيين:

مباشرةً عبر متصفح يستخدمه مستخدم
عبر تطبيق عميل API، مثل تطبيق جوّال أو خادم آخر

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

[caption id="" align=“alignnone” width=“1800”] مخطط يوضح الطرق المختلفة التي يمكن للأنظمة الخارجية أن تصل بها إلى Salesforce Core [/caption]

لنفصّل ذلك أكثر:

الوصول عبر المتصفح

للبشر الذين يتعاملون مع Salesforce عبر متصفح:

[caption id="" align=“alignnone” width=“1840”] تدفقات المصادقة من المتصفح إلى Salesforce [/caption]

طبقات أمان إضافية للمصادقة: المصادقة متعددة العوامل (MFA)، ونطاقات IP، والشهادات من جهة العميل.
موفّرو الهوية: يمكن أن تعمل Salesforce بوصفها موفّر الهوية (Identity Provider، IDP) للتحقق من صحة هوية المستخدم. وبعد المصادقة، يقدّم خادم Salesforce رمز جلسة (session token) إلى مثيل ORG الخاص بالعميل.
موفّر هوية من طرف ثالث: بدلًا من Salesforce، يمكن لموفّر هوية من طرف ثالث، مُعدّ في علاقة SSO مع Salesforce، أن يتولى المصادقة. في هذه الحالة يرسل موفّر الهوية تأكيد SAML (SAML assertion) إلى Salesforce، التي تُصدر رمز الجلسة بعد التحقق منه.

بعد ذلك، تتحكم آليات التفويض في الوصول إلى الصفحات والموارد.

وصول عملاء API

للآلات التي تحاول الوصول إلى Salesforce:

[caption id="" align=“alignnone” width=“1820”] عمليات عميلة تُصادِق للوصول إلى واجهات Salesforce API [/caption]

تدفقات OAuth: يمكن للآلات أن تستخدم واحدًا من تدفقات OAuth المتعددة للحصول على الوصول، من تدفق خادم الويب (web server flow) المناسب لخوادم الويب الخارجية إلى تدفق بيانات اعتماد العميل (client credentials flow)، وكثير غيرهما بينهما. ولكل تدفق تسلسله وغرضه الخاص.

إنشاء الجلسة: بعد المصادقة، يسلّم خادم المصادقة في Salesforce رمز جلسة يمنح عميل API الوصول إلى موارد Salesforce.

ثم يأتي دور قواعد التفويض.

الخلاصة: كيف يترابط كل ذلك

مهما كانت نقطة الوصول، متصفحًا أو عميل API، فإن العملية تشمل:

الأمان على مستوى النقل: استخدام TLS، مع إمكانية إضافة طبقات مثل القائمة البيضاء لعناوين IP والشهادات من جهة العميل لتعزيز الأمان.

المصادقة: في هذه الخطوة يُتعرَّف على المستخدم أو النظام. وهنا يأتي دور عناصر مثل MFA أو موفّري الهوية من طرف ثالث.

إصدار رمز الجلسة: بعد المصادقة، يتلقى الكيان رمز جلسة يعمل كجواز سفر إلى موارد Salesforce.

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

بهذه المعرفة الأساسية، نحن مستعدون للتعمق أكثر في دقائق أمان Salesforce في مقالاتنا القادمة. تابعنا لفحص أكثر تفصيلًا لكل مكوّن ذُكر أعلاه.

شكرًا لك على القراءة، وأرجو أن تكون قد وجدت المقالة مفيدة. تابع الحلقة القادمة لمزيد من الأفكار حول أمان Salesforce.