الإجابة المختصرة
إن هندسة الهوية في Salesforce ليست مشروعًا تقنيًا لمرة واحدة، بل هي طبقة تحكم مستمرة يوميًا: من يصل، بأي هوية، بأي صلاحيات، وماذا يحدث عندما لا يُسمح له بالوصول. يبدو الاختيار بين SAML وOIDC، بين JIT وSCIM، وبين سياسة المصادقة متعددة العوامل (MFA) على مستوى موفر الهوية (IdP) أو فرضها داخليًا في Salesforce – كل ذلك يبدو تفاصيل إعدادات. لكن في الواقع، هذه القرارات تحدد المدة الزمنية المستغرقة لحجب وصول موظف مفصول، وأي جزء من هذه الحوادث سيكتشف فقط أثناء التدقيق.
النهج الصحيح لا يبدأ بالبروتوكول، بل بسؤالين: من هو مصدر الحقيقة لهوية المستخدم، وما هو الحد الأقصى للوقت المسموح به بين حدث إنهاء الخدمة (Offboarding) وحجب الوصول الفعلي. ومن هنا تُستمد جميع القرارات الأخرى – نوع الاتحاد (Federation)، طريقة توفير الحسابات (Provisioning)، سياسة الجلسات (Session Policy)، وعملية الوصول الطارئ (Break Glass).
المنظمات التي تتساءل أيضًا عن الصلاحيات نفسها وليس فقط المصادقة، ستجد المزيد في نموذج صلاحيات Salesforce.
خارطة قرارات Identity في Salesforce: أربع طبقات
| الطبقة | السؤال الذي يجب حسمه | الخيارات الرئيسية | العواقب في حال اتخاذ قرار خاطئ |
|---|---|---|---|
| الاتحاد والمصادقة | من هو موفر الهوية (IdP) وكيف يثق به Salesforce | SAML 2.0, OIDC, المصادقة المفوّضة (Delegated Authentication) | تسجيل دخول مزدوج، عدم تطابق السمات (Attributes)، اختراق الثقة |
| توفير الحسابات ودورة حياتها | كيف يُنشأ المستخدم ويُحدّث ويُلغى | توفير الحسابات في الوقت المناسب (JIT Provisioning), SCIM, الإنشاء اليدوي | حسابات يتيمة، استمرار الوصول بعد المغادرة |
| الجلسة والمصادقة متعددة العوامل (MFA) | أين يتم تطبيق مستوى المصادقة ومدة الجلسة | MFA في IdP, MFA داخلي في Salesforce, سياسات الجلسة | تجاوز MFA عبر مسار بديل، جلسة لا تنتهي أبدًا |
| الوصول الطارئ (Break Glass) والتدقيق | ماذا يحدث عند تعطل الدخول الموحد (SSO) ومن يدقق في الاستثناءات | مستخدم طوارئ محكوم، سجلات الدخول (Login History), مراقبة الأحداث (Event Monitoring) | اعتماد كلي على IdP، عدم القدرة على التحقيق بأثر رجعي |
SAML مقابل OIDC: ليس سؤالًا عن "الأحدث"
لا ينبغي أن يستند الاختيار بين البروتوكولين إلى الاتجاهات، بل إلى البنية التحتية الحالية. يعمل SAML مع XML والتأكيدات الموقعة (Signed Assertions)، وهو شائع في المنظمات التي تستخدم خدمات اتحاد Active Directory (Active Directory Federation Services) أو لديها موفر هوية (IdP) قديم يُستخدم بالفعل لعشرات الأنظمة الأخرى. OIDC مبني على OAuth 2.0، وهو أخف وزنًا في الصيانة، ومريح بشكل خاص عندما يحتاج نفس موفر الهوية إلى خدمة مستهلكي واجهة برمجة التطبيقات (API) الحديثة بالإضافة إلى دخول المستخدمين.
الخطأ الشائع هو الاختيار بناءً على ما يبدو "متقدمًا" دون التحقق من السمات (Attributes) التي يرسلها موفر الهوية (IdP) الحالي بالفعل، وكيف يتم ربطها بـ Salesforce (اسم المستخدم، معرف الاتحاد Federation ID، الملف الشخصي Profile، مجموعة الصلاحيات Permission Set Group). يؤدي ربط السمات الخاطئ في مرحلة الإعداد غالبًا إلى تصحيح يدوي لعشرات المستخدمين في بيئة الإنتاج، وليس مجرد تغيير إعداد.
نقطة غالبًا ما تُنسى: حتى عند اختيار OIDC أو SAML، من الجيد التخطيط لتسجيل الدخول الذي يبدأ من موفر الهوية (IdP-Initiated) مقابل تسجيل الدخول الذي يبدأ من مزود الخدمة (SP-Initiated) بشكل منفصل – تنشأ بعض حوادث الأمان الشائعة من بقاء تسجيل الدخول الذي يبدأ من مزود الخدمة مفتوحًا على الرغم من أن عملية تسجيل الدخول بأكملها قد تم تصميمها ليتمها فقط عبر بوابة موفر الهوية.
JIT Provisioning مقابل SCIM: متى لا يكون "في لحظة الدخول" كافيًا
تقوم آلية التوفير في الوقت المناسب (JIT Provisioning) بإنشاء أو تحديث المستخدم في Salesforce عند أول تسجيل دخول، وفقًا للبيانات الواردة من موفر الهوية (IdP) في تأكيد SAML (SAML Assertion) أو رمز OIDC (OIDC Token). هذا مريح، ومنخفض التكلفة في التنفيذ، ويكفي لمعظم المنظمات التي يتصل فيها المستخدمون بانتظام.
المشكلة: JIT لا يحل مشكلة إلغاء توفير الحسابات (Deprovisioning). إذا تمت إزالة موظف من موفر الهوية (IdP) ولكنه لا يقوم بتسجيل الدخول بعد ذلك، يظل حسابه نشطًا في Salesforce إلى أجل غير مسمى، لأنه لا يوجد حدث يؤدي إلى التحديث. هنا يأتي دور SCIM (System for Cross-domain Identity Management) – فهو يسمح بالمزامنة الاستباقية من موفر الهوية (IdP) إلى Salesforce، بما في ذلك إلغاء التنشيط الفوري عند إزالة المستخدم من المصدر.
القاعدة العملية: إذا كان لدى المنظمة متطلب إنهاء خدمة (Offboarding) خلال ساعات وليس أيام – مثل المقاولين، الموظفين المؤقتين، الوصول إلى البيانات الحساسة – فإن SCIM ليس "ميزة إضافية مرغوبة" بل هو متطلب امتثال. إذا كانت وتيرة تغيير الموظفين بطيئة وتشمل حوكمة البيانات بالفعل مراجعة ربع سنوية للوصول، فإن JIT وحده قد يكون كافيًا بشرط أن يكون مصحوبًا بعملية يدوية موثقة للحجب الفوري.
يجب دائمًا تقييم تخطيط توفير الحسابات (Provisioning) بناءً على تعقيد الأتمتة المحيطة به – على سبيل المثال عندما تتضمن Flow منطقًا لتعيين الصلاحيات أثناء إنشاء المستخدم، حيث تكون المقارنة في Flow مقابل Apex ذات صلة بشأن تحديد موضع الكود المخصص.
MFA وسياسة الجلسات: طبقتان، لا طبقة واحدة
من الأخطاء الشائعة الاكتفاء بالمصادقة متعددة العوامل (MFA) المطبقة في موفر الهوية (Identity Provider) وافتراض أنها تغطي جميع مسارات الوصول إلى Salesforce. في الواقع، طالما كان هناك مستخدم يمكنه الاتصال مباشرة عبر login.salesforce.com – على سبيل المثال، تكامل، مستخدم واجهة برمجة التطبيقات (API User)، أو مدير يمتلك صلاحية وصول احتياطية – فإن سياسة MFA منفصلة مطلوبة ومحددة داخل Salesforce نفسها (التحقق من الهوية Identity Verification، مستويات أمان الجلسة Session Security Levels).
إلى جانب ذلك، تحدد سياسة الجلسة أمورًا يسهل إهمالها: مهلة الجلسة (Session Timeout)، "فرض تسجيل الخروج عند انتهاء مهلة الجلسة" ("Force logout on session timeout")، نطاقات عناوين IP لتسجيل الدخول (Login IP Ranges)، وجلسة عالية الضمان (High Assurance Session) الإلزامية للعمليات الحساسة (مثل تغيير الصلاحيات أو تصدير كميات كبيرة من البيانات). المنظمة التي تُفعل MFA قويًا ولكنها تترك مهلة الجلسة على الإعداد الافتراضي وهو ساعتان، تفتح نافذة زمنية يحتفظ فيها جهاز كمبيوتر مسروق بوصول نشط لفترة تتجاوز المعقول بكثير.
Break Glass والتدقيق: عندما يتعطل الدخول الموحد، من يدخل؟
الاعتماد الكامل على موفر هوية (IdP) خارجي يخلق نقطة فشل واحدة: إذا تعطل موفر الهوية أو كان هناك خطأ في إعداد الاتحاد (Federation)، لا يمكن لأحد تسجيل الدخول، بما في ذلك من يجب أن يقوم بإصلاح المشكلة. الحل الشائع هو مستخدم "Break Glass" – وهو حساب مسؤول فائق بصلاحيات إدارية عليا مع مصادقة مستقلة (لا تعتمد على الدخول الموحد SSO)، كلمة مرور تُدار في خزنة (Vault) وليس في ذاكرة شخص، ومصادقة متعددة العوامل (MFA) منفصلة.
من المهم التمييز: "Break Glass" ليس "بابًا خلفيًا مريحًا" – بل هو آلية طوارئ محكومة. يجب أن يؤدي استخدامه إلى تشغيل تنبيه تلقائي، ويجب مراجعته في غضون يوم عمل بواسطة طرف آخر غير من استخدمه. العديد من المنظمات تنشئ هذا المستخدم بشكل صحيح ولكنها تنسى التحكم المستمر – كلمة المرور ليست متاحة دائمًا، وصلاحياته واسعة جدًا افتراضيًا.
سيناريو تنظيمي: فشل عملية إنهاء الخدمة في شركة تأمين متوسطة الحجم
لنفترض شركة تأمين تضم ستمائة موظف، تستخدم Okta كموفر للهوية (Identity Provider) وإعداد SAML مع Salesforce تم إنشاؤه قبل حوالي ثلاث سنوات. يعتمد توفير الحسابات (Provisioning) بالكامل على JIT: عندما يقوم موظف جديد بتسجيل الدخول للمرة الأولى، يتم إنشاء مستخدم له بملف تعريف (Profile) ومجموعة صلاحيات (Permission Set Group) وفقًا للمجموعة التي ينتمي إليها في Okta.
في إحدى الحالات، تم فصل ممثل خدمة عملاء بعد ظهر يوم جمعة. قام فريق تكنولوجيا المعلومات بتعطيله في Okta على الفور. ولكن في الواقع، نظرًا لعدم وجود آلية SCIM أو Webhook لمزامنة إلغاء التنشيط مع Salesforce، ظل حساب المستخدم نشطًا هناك – ونظرًا لأن جلسته كانت نشطة بالفعل منذ الصباح ولم يتم إعداد "Force logout on session timeout"، استمر في الوصول إلى النظام حتى بعد الفصل، إلى أن لاحظ شخص ما الأمر في مراجعة الوصول الأسبوعية يوم الاثنين.
الحل الذي تم تطبيقه لم يكن انتقالًا كاملاً إلى SCIM (الذي كان سيتطلب مشروعًا منفصلًا وميزانية تكامل)، بل دمجًا فوريًا لثلاثة إجراءات: تفعيل "Force logout on session timeout" لجميع الملفات الشخصية الحساسة، وتقصير مهلة الجلسة (Session Timeout) من 120 دقيقة إلى 30 دقيقة للمناصب التي تتعامل مع العملاء، وإضافة خطوة تلقائية في عملية إنهاء الخدمة التنظيمية تُنفذ إلغاء تنشيط مباشر في Salesforce كإجراء مستقل وليس فقط نتيجة غير مباشرة لتعطيل الحساب في Okta. ظل SCIM هدفًا للربع التالي، مصحوبًا بالفعل بميزانية وموافقة، ولكن الثغرة الخطيرة تم إغلاقها في غضون أسبوع.
المخاطر الشائعة والإجراءات الوقائية
| الخطر | كيف يظهر عمليًا | الإجراء الوقائي |
|---|---|---|
| الاعتماد الكلي على JIT دون إلغاء توفير الحسابات | بقاء المستخدمين الذين غادروا نشطين إلى أجل غير مسمى | إضافة خطوة إنهاء خدمة مستقلة في Salesforce، لا تعتمد على المزامنة |
| MFA في IdP فقط | المستخدمون المسؤولون عن التكامل والمسؤولون يتجاوزون MFA عبر تسجيل الدخول المباشر | سياسة MFA داخلية في Salesforce لجميع أنواع المستخدمين |
| مهلة جلسة طويلة جدًا | جهاز كمبيوتر مسروق أو جلسة منسية مفتوحة تحافظ على الوصول لساعات | تقصير المهلة (Timeout) وفرض تسجيل الخروج (Force Logout) للملفات الشخصية الحساسة |
| Break Glass بدون رقابة | استخدام حساب الطوارئ لا يُكتشف في الوقت المناسب | تنبيه تلقائي ومراجعة خلال يوم عمل لأي استخدام |
| ربط سمات (Attributes) خاطئ من IdP | يحصل المستخدم على ملف تعريف (Profile) أو دور (Role) غير صحيح عند تسجيل الدخول الأول | اختبار كامل لربط السمات في بيئة Sandbox قبل التغيير في الإنتاج |
قائمة التحقق لإنشاء أو مراجعة هندسة الهوية (Identity Architecture)
- ☐ تحديد موفر هوية (Identity Provider) واحد كمصدر للحقيقة، ومعرفة ما يحدث عند تعطله.
- ☐ اختيار بروتوكول (SAML أو OIDC) بناءً على البنية التحتية الحالية وليس بناءً على توجهات.
- ☐ التحقق من ربط السمات (Attributes) بين موفر الهوية (IdP) والملف الشخصي (Profile)/مجموعة الصلاحيات (Permission Set Group) في Sandbox.
- ☐ تحديد سياسة واضحة: JIT فقط، أو JIT مع SCIM وفقًا لمتطلبات إنهاء الخدمة (Offboarding).
- ☐ فرض MFA داخل Salesforce أيضًا، وليس فقط في موفر الهوية (IdP).
- ☐ تحديد مهلة الجلسة (Session Timeout) وفرض تسجيل الخروج (Force Logout) وفقًا لحساسية الملف الشخصي (Profile).
- ☐ وجود مستخدم "Break Glass" محكوم، مع MFA منفصل وكلمة مرور محفوظة في خزنة.
- ☐ عملية إنهاء الخدمة (Offboarding) تتضمن خطوة مستقلة لإلغاء التنشيط في Salesforce.
- ☐ مراجعة سجلات الدخول (Login History) ومراقبة الأحداث (Event Monitoring) بانتظام.
- ☐ وجود خطة اختبار دورية (Access Review) لا تعتمد فقط على ذاكرة قسم تكنولوجيا المعلومات.
كيف نقيس فعالية الهندسة المعمارية؟
المقياس الرئيسي ليس "هل SSO نشط" بل هو وقت الاستجابة بين حدث في مصدر الحقيقة وتغيير مماثل في Salesforce: كم من الوقت ينقضي بين إزالة مستخدم في موفر الهوية (IdP) وإلغاء تنشيطه الفعلي. مقياس تكميلي هو نسبة عمليات تسجيل الدخول التي تتم عبر مسار غير متوقع (تسجيل دخول مباشر Direct Login بدلاً من عبر موفر الهوية)، والتي يجب أن تقترب من الصفر باستثناء حالات "Break Glass" الموثقة. مقياس ثالث هو تكرار مراجعة الصلاحيات مقابل الوضع الفعلي – ليس كل تغيير تنظيمي يأتي عبر موفر الهوية (IdP)، وبالتالي فإن المراجعة ربع السنوية تظل ضرورية حتى مع التوفير التلقائي الكامل للحسابات.
لتنفيذ أو مراجعة هندسة الهوية في بيئة Salesforce قائمة، يمكن التقدم من خلال خدمة هندسة إدارة علاقات العملاء (CRM Architecture). المنظمات التي تستكشف أيضًا الربط مع أنظمة تخطيط موارد المؤسسات (ERP) وأنظمة الرواتب كجزء من الصورة الشاملة للهوية ستجد معلومات إضافية في ربط Salesforce بأنظمة تخطيط موارد المؤسسات (ERP)، وصورة معمارية أوسع في دليل هندسة إدارة علاقات العملاء (CRM Architecture Guide).
الخلاصة
تُبنى هندسة الهوية في Salesforce مرة واحدة ولكن تُختبر يوميًا من خلال الحوادث الفردية – موظف يغادر، جلسة تنسى أن تُغلق، تكامل يتجاوز المصادقة متعددة العوامل (MFA). القرارات الرئيسية (SAML مقابل OIDC، JIT مقابل SCIM، MFA المزدوج، Break Glass المحكوم) لا يجب أن تُستمد من إعدادات IdP الافتراضية، بل من وقت الاستجابة المطلوب لحجب الوصول ومستوى حساسية المعلومات المكشوفة. المنظمات التي تخطط لهذه الطبقة مسبقًا، بدلاً من اكتشاف الثغرات في مراجعة أو بعد حادث أمني، توفر تكلفة الإصلاح وكذلك المخاطر المتعلقة بالسمعة والتنظيم.