ما المقصود بتسجيل الدخول الموحد (SSO)؟ كيف يعمل SSO؟

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

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

ما المقصود بـ SSO (تسجيل الدخول الموحد)؟

إن تكنولوجيا تسجيل الدخول الموحد حل جزئي لمشكلة كلمة المرور التي تصيبنا في العمل وفي حياتنا الشخصية. تسمح لنا بتسجيل الدخول مرة واحدة إلى خادم المصادقة، والذي يصدر بعد ذلك شهادات نيابة عنا تعمل باعتبارها بيانات اعتماد تم التحقق منها للتطبيقات المُشاركة.

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

النقاط الرئيسة

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

شرح SSO

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

يقلل SSO من عدد أسماء المستخدمين وكلمات المرور التي تحتاج إلى معرفتها. كما أنه يمكن أن يخفض بشكل كبير من عدد المرات التي يطلب منك فيها تقديم بيانات اعتماد الهوية، مما يسهِّل استخدام مجموعة واسعة من التطبيقات ومن المرجح أن تنشئ كلمات مرور أقوى. من وجهة نظر مخططي تكنولوجيا المعلومات في المؤسسة، يتيح SSO لهم تحديث إجراءات الأمان ونشر آليات مُصادقة أكثر تقدمًا لاستخدامها بواسطة خادم المصادقة، مما يتيح لجميع التطبيقات المُشاركة التمتع بمصادقة أكثر أمانًا دون الحاجة إلى التعديل.

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

كيف يعمل SSO؟

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

تكون الشهادات صالحة لفترة زمنية معينة فحسب وتكون عادةً مرتبطة بالنظام الذي صدَّق المستخدمون الفرديون عليه بأنفسهم. للمشاركة، يجب كتابة التطبيقات بطريقة تمكِّنها من استخدام خدمة SSO. في المؤسسة، يختار مخططو تكنولوجيا المعلومات عادةً نموذج SSO واحد ثم يطلبون من التطبيقات استخدامه للتحقق من هويات الموظفين. قد تكون هذه مشكلة للتطبيقات القديمة والمتجانسة التي تنشئ مستودعات بيانات اعتماد المستخدم الخاصة بها أو التي قد لا تدعم بُنى SSO الشائعة.

أنواع تكوين SSO الشائعة

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

• SAML. تُعد لغة ترميز تأكيد الأمان مواصفات فنية تصف بنية المستند الذي يعمل على مصادقة المستخدمين على التطبيقات. يستخدم SAML معيار XML المقبول على نطاق واسع لتحديد بنية المستند الذي تنشئه خوادم الهوية—المعروفة أيضًا باسم موفري الهوية—وترسله إلى التطبيقات. تُسمى غالبًا هذه التطبيقات "موفري الخدمة" في لغة SSO. ينشئ أي موفر هوية يستخدم SAML بيانات اعتماد التصديق التي يمكن استخدامها بواسطة أي تطبيق على دراية بلغة SAML، مما يجعله خيارًا جيدًا لتطبيقات الإنترنت.

  لا توفر SAML آلية لضمان عدم تغيير معلومات التصديق التي يتلقاها التطبيق. يتم التعامل معها بواسطة تكنولوجيا أخرى.

• Kerberos. تم إنشاؤه في معهد ماساتشوستس للتكنولوجيا (MIT) في أواخر الثمانينات كجزء من مشروع أثينا، إذ يعد Kerberos بنية تصديق واعتماد كاملة. سعى مشروع أثينا إلى إنشاء شبكة من موارد الكمبيوتر المتاحة عالميًا لطلاب MIT في جميع أنحاء الحرم الجامعي. استخدم بروتوكول Kerberos في الأصل معيار تشفير البيانات (DES) لتشفير الرسائل التي تم تمريرها بين خوادم التصديق والتطبيقات. استخدم مفاتيح متماثلة 48 بت، مما يعني أن نفس المفتاح يُستخدم لتشفير الرسائل وفك تشفيرها. في ذلك الوقت، كان DES الشكل الأكثر أمانًا للتشفير المُتاح كمعيار يحتفظ به المعهد الوطني للمعايير والتكنولوجيا (NIST).

  في الوقت الحالي، يستخدم Kerberos معيار التشفير المُتقدم (AES)، الذي حل محل DES في معايير التشفير NIST. يحدد AES مفاتيح أطول—يصل طولها إلى 256 بت—ويسمح بجولات متعددة من التشفير، مما يجعل النظام صعب اختراقه للغاية.

  نظرًا إلى أن Kerberos يستخدم تشفير مفتاح متماثل، فإنه يتطلب من طرف ثالث موثوق به إدارة المفاتيح، مما يجعله أكثر ملاءمة لتطبيقات المؤسسة التي يمكن إنشاء نطاق استخدام بإحكام فيها، وتقتصر عادةً على شبكات LAN وشبكات VPN الخاصة بالمؤسسة. على الرغم من أنه يمكن استخدام Kerberos عبر الإنترنت، إذ لن يتم إنشاء أي مجال باستخدام معيار مصادقة مُختلف—تشفير المفتاح العام—لبدء العملية، إلا أنه نادرًا ما يتم استخدامه بهذه الطريقة. يمكن أن يتسخدم Kerberos تنسيق بيانات الاعتماد الخاصة به أو تكوينه لاستخدام SAML. لا يزال هذا شائعًا، بما في ذلك مع Microsoft، التي تعمل افتراضيًا على Kerberos بدلاً من نظام مصادقة NTLM الأقل أمانًا لشبكات المؤسسات.

• OAuth. بصفته إطار عمل اعتماد مفتوح لا يتضمن إطار عمل تصديق، فإن OAuth هو النظام الافتراضي عندما يحتاج تطبيق إنترنت إلى الوصول إلى موارد خدمة محمية نيابة عن مستخدم. يستخدم معظم موفري السحابة، بما في ذلك Oracle مع البنية التحتية من Oracle Cloud (OCI)، OAuth لإدارة الوصول إلى موارد السحابة لديهم. تقدم Oracle أيضًا المكتبات والخدمات التي تسهِّل على المطورين إنشاء تطبيقاتهم الخاصة التي تستخدم OAuth.

  فيما يلي المكونات الرئيسة لنظام OAuth:

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

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

• OpenID Connect (OIDC). يمثل OpenID Connect نظام إدارة الهوية الذي تم إنشاؤه للاستخدام مع نظام OAuth. توفر OIDC وOAuth معًا بيئة SSO كاملة للتطبيقات القائمة على الويب والأنظمة الأصلية للإنترنت، مثل تطبيقات الأجهزة المحمولة. بدلاً من استخدام SAML باعتبارها أساس لإرجاع معلومات بيانات الاعتماد، تستخدم OIDC مستند بلغة JSON المعروف باسم رموز الويب المميزة من JSON، الموضح أدناه، وبروتوكولات RESTful؛ كلاهما أصلي على الإنترنت وبسيط ليُستخدم من المطورين.

  بدلاً من استخدام تشفير المفتاح المتماثل مثل Kerberos، يستخدم OIDC تشفير المفتاح العام، الذي يفسح المجال بشكل أفضل للشبكات التي لا مجال لها مثل عبر الإنترنت.

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

  يتم عادةً تخزين المفاتيح الخاصة على جهاز المستخدم. تأتي معظم أجهزة الكمبيوتر المحمولة مزودة بشريحة مقاومة للتلاعب تستخدم تقنية "وحدة منصة موثوق بها" (TPM) لفك تشفير الرسائل المُخصصة للنظام. تستخدم هواتف Apple وAndroid أنظمة مُختلفة، لكنها متشابهة. ويطلق على نظام Apple اسم Secure Enclave، ويطلق على نظام Android اسم Android Knox. تتيح هذه التقنيات للجهاز توفير مُفتاحه العام لأي نظام يطلبه بشكل صحيح ويستخدم مفتاحه الخاص الذي لم يتم الكشف عنه مطلقًا لفك تشفير الرسائل التي يتلقاها.

  لا تحتاج ميزة هذه الأنظمة في جهاز ذلك المستخدم إلى معرفة أي شيء عن طريقة التعامل مع التشفير على أنظمته. أما العيب في أن كل جهاز يملكه المستخدم يكون له زوج مفاتيح عام/خاص فريد، لذا؛ تُعرف الأجهزة بشكل فردي في عملية التشفير. إذا فُقد أو سُرق كمبيوتر محمول أو هاتف، فلن يساعد نظام التشفير الخاص به في منع الوصول إذا كان اللص يعرف كلمة مرور المالك.

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

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

  نظرًا إلى أن تطبيقات SaaS أصبحت أكثر شيوعًا، فإن المؤسسات لديها خيار الانتقال إلى نظام مثل OAuth الأكثر استخدامًا على الإنترنت أو يتطلب أن تتوافق تطبيقات SaaS مع إطار eSSO الذي اختارته الشركة. يمكن استخدام SAML داخل شبكة المؤسسة وعبر الإنترنت. تدعم العديد من تطبيقات SaaS كلا إطاري تصديق المستخدم.

• SSO للويب من المحتمل أن تعمل تطبيقات الويب بشكل أفضل مع نظام OAuth أو تقتصر عليه لاعتماد نشاط المستخدم وOpenID Connect للتصديق على المستخدمين. نظرًا إلى أنه من المفترض أن يكون الإنترنت في النقل، يتم تعريف مكونات نظام SSO عبر الويب على أنها معيار IETF وبالتالي؛ تميل إلى العمل بطريقة يتوقعها مطورو الويب ويقدِّرونها. علاوة على ذلك، يقترن التصديق بإحكام بالاعتماد ويَستخدم طُرق وصول مثل بروتوكولات REST ومعايير المعلومات على أساس JSON لإنشاء نظام كامل وقابل للتوسُّع. تهدف أنظمة SSO عبر الويب أيضًا إلى العمل عبر المجالات وعلى نطاق واسع.

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

  نظرًا إلى استخدام LDAP لمنح الوصول إلى موارد الشبكة، فإنه يتضمن نظام تصديق المستخدم مع صلاحيات المستخدم المُخزَّنة على خادم LDAP. لا تظهر آليات مصادقة المستخدم بأنها قوية؛ على سبيل المثال، يرسل كلمات المرور عبر الشبكة في شكل نص واضح. قد يتم توفير التشفير بواسطة بروتوكول آخر، مثل SSL/TLS.

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

• JWT. إن رموز الويب المميزة لـ JSON مستندات مضغوطة تستخدم لنقل المعلومات بشكل آمن بين الأطراف بطريقة مُنظمة. إنها تلبي نفس الحاجة مثل مستندات SAML، لكن بتنسيق أوضح، مما يجعلها مناسبة للتضمين في عناوين URL. يتم توقيع رموز JWT بشكل مُشفر باستخدام تقنيات تشفير المفتاح العام لضمان الأصالة. في Open Authentication (Oath)، بمجرد مصادقة المستخدم، يرجع خادم الهوية رمز مميز لمعرف JSON.

  ترجع طلبات الاعتماد للوصول إلى الموارد المحمية لاحقًا رمز مميز للوصول من JSON، والذي يجب تضمينه بعد ذلك مع كل طلب إلى خادم الموارد. تنقل هذه المعاملات حالة العميل—في هذه الحالة، المصدق عليها والمصرح بها—باعتبارها جزء من كل طلب، مما يجعلها ما يسمى تبادلات RESTful. يُعد REST الذي يشير إلى "نقل الحالة التمثيلية"، مُفيدًا لأن خوادم الموارد لا تحتاج إلى إنشاء جلسات وصيانتها مع كل عميل يرغب في استخدام موارد الخادم.

  تمثل رموز JWT مستندات نصية واضحة، لذلك؛ يجب استخدامها عبر اتصالات مُشفرة ببروتوكول HTTPS. يتم عادةً تصميم الرموز المميزة بحيث لا تحتوي على بيانات حساسة، مثل معلومات التعريف الشخصية. نظرًا إلى توقيع كل رمز مميز وفقًا إلى X.509، وهو المعيار الدولي لتنسيق شهادات المفاتيح العامة، ويتم التحقق من صحة هذا التوقيع بواسطة خوادم الموارد للتأكد من عدم العبث بالرمز المميز. تُعد رموز JWT مكونات نظام تصديق واعتماد لـ OAuth/OpenID. تم تصميمها للاستخدام بواسطة تطبيقات الويب، والتوسُّع بشكل جيد، وتهدف إلى استخدامها عبر المجالات.

مزايا SSO

يميل مُتخصصو تكنولوجيا المعلومات والأمان إلى أن يكونوا مُعجبين بـ SSO؛ إذ يدركون أنه يعني مركزية مصادقة المستخدم وحماية المعلومات الحساسة المحتملة وإدارة التكامل مع أنظمة المؤسسة وتطبيقاتها. إنهم سعداء بشكل عام بمعالجة تدريب المستخدمين المطلوب والتعامل مع المراقبة والصيانة المستمرة. تلك نتيجة مُباشرة مع العديد من المزايا المهمة التي تأتي مصحوبة مع التكنولوجيا.

• الوصول المركزي. تبسِّط أنظمة SSO من عبء إدارة حسابات المستخدمين والوصول إلى العديد من التطبيقات التي تصيِّنها معظم المؤسسات وموفري سحابة الإنترنت. يمكن مَنح حق وصول المستخدم إلى جميع التطبيقات وإلغاؤه في موضع واحد. لذلك، على سبيل المثال، إذا ترك الموظف مؤسسة، فلن يحتاج المسئولون إلى حذف بيانات اعتماد الموظف لكل تطبيق على حدة. يمكن لمحترفي الأمان أيضًا إجراء تغييرات على أنظمة المصادقة في مكان واحد فقط، بدلاً من الحاجة إلى إجراء تغييرات على كل تطبيق.
• تحسين الأمان. يقلل SSO بشكل كبير من عدد أزواج اسم المستخدم وكلمة المرور التي يجب على الموظفين تثبيتها في الذاكرة. مع انخفاض هذا العبء، يصبح من المعقول خاصةً بالنسبة إلى المؤسسات، تحسين أمان تبادلات المصادقة مع المصادقة متعددة العوامل وسياسات كلمات المرور القوية.
• زيادة إنتاجية الموظفين. يواجه الموظفون صعوبة أقل في تذكر أسماء المستخدمين وكلمات المرور عند وجود SSO. بمجرد التصديق لهم، يمكن للأشخاص عادةً الوصول إلى التطبيقات دون إعادة التصديق. لذلك؛ يجب على SSO السماح للموظفين بالوصول إلى عملهم المقصود بسرعة أكبر. على حسب تفاصيل التنفيذ، قد يظل مطلوبًا منهم المصادقة على التطبيقات التي يستخدمونها، لكن على الأقل يتعين عليهم فحسب تذكُّر بيانات اعتماد SSO لديهم.
• تقليل الإجهاد المصاحب لإدخال كلمات المرور. دعونا نواجه الأمر، لا أحد يريد التعامل مع العشرات من أزواج أسماء المستخدم وكلمات المرور. يمكن أن تؤدي صعوبة تذكر كلمات المرور المُعقدة—خاصةً إذا كانت بحاجة إلى تغييرها بشكل متكرر—إلى الإحباط، كما يمكن أن تتسبب في استخدام الأشخاص كلمات مرور سهلة التخمين أو إعادة استخدام نفس كلمة المرور لحسابات مُتعددة أو استخدام طريقة الملاحظة اللاصقة لإدارة كلمات المرور. يخفف SSO عنك العبء.
• الامتثال التنظيمي. قد يخفف SSO من الامتثال التنظيمي عبر مزايا إدارة الوصول المركزية الموضحة سابقًا. كما يتم تبسيط المراجعة والمعالجة نظرًا إلى وجود إطار عمل SSO واحد فقط للتحقق منه.
• التكامل المُبسط. تدير المؤسسة النموذجية وحدات بيتابايت من البيانات المُخزَّنة في العديد من مثيلات قاعدة البيانات. ليس من الصعب تخيل قاعدة بيانات واحدة لبيانات التصنيع، وقاعدة بيانات أخرى لبيانات سلسلة التوريد، وغيرها للبيانات المالية وبيانات التسويق وبيانات المبيعات، وغير ذلك. من السهل أيضًا فهم مدى فائدة وصول مندوبي المبيعات إلى بيانات المخزون على سبيل المثال. يمكن لنظام CRM الوصول إلى هذه البيانات، لكن يجب أن يكون كل مندوب مبيعات معروفًا لقاعدة بيانات إدارة المخزون بالإضافة إلى نظام CRM لديه. يمكن أن يوفر SSO الهوية اللازمة التي تم التحقق منها من مقدم الطلب، ويمكن أن تساعد الرموز المميزة للوصول في تحديد البيانات التي يجب السماح للشخص في كل دور بعرضها. بدون SSO، يكون التكامل بين إدارة علاقات العملاء ونظام المخزون أصعب في الإنشاء والإدارة ويتضمن خطوة مصادقة أخرى للمستخدمين أو قد يشمل أمان أضعف لبيانات المخزون.
• تجربة مستخدم مُبسطة. يؤدي تقليل الحاجة إلى المصادقة عبر التطبيقات المؤسسية وتطبيقات الويب بشكل عام إلى تحسين في تجربة المستخدم. ولأن العديد من الأشخاص اعتادوا استخدام SSO عبر وجودهم الشخصي عبر الإنترنت، فيوجد غالبًا الحد الأدنى من التدريب المطلوب.

SSO والأمان: هل SSO آمن؟

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

SSO والخصوصية

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

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

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

حالات استخدام SSO

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

• تطبيقات المؤسسات. تدير المؤسسة عادةً العشرات إلى مئات التطبيقات، ويتطلب كل منها مصادقة المستخدمين. إن إنشاء أنظمة إدارة الهوية وصيانتها على أساس كل تطبيق ليس عمليًا للمستخدمين أو فِرق تكنولوجيا المعلومات. يوفر SSO طريقة لمصادقة الموظفين مرة واحدة ثم إدارة اعتمادهم لاستخدام الموارد على أساس تلك المصادقة لمرة واحدة.

  تكون تأكيدات المصادقة عادةً صالحة لفترة معينة فحسب وعلى نظام واحد. يمكن الاحتفاظ بمزيد من التفاصيل الدقيقة حول أدوار كل موظف داخل الشركة بواسطة SSO واستخدامه بواسطة التطبيقات أو أنظمة الاعتماد لتوفير وصول محدود إلى التطبيقات والبيانات والموارد الأخرى.

• التطبيقات المستندة إلى السحابة. بالنسبة إلى كل من استخدام الأعمال والمستهلكين، تأتي الأنظمة القائمة على السحابة مع احتياجات تعريف واعتماد مُختلفة مقابل أنظمة SSO المُخصصة للمؤسسة. بالنسبة إلى المستهلكين، قد تفرض الراحة أنه بمجرد مصادقة المستخدمين، فيمكنهم استخدام الخدمة دائمًا من ذلك الجهاز. بمجرد تسجيل الدخول إلى Gmail على سبيل المثال، فيمكنك استخدامه وتطبيقات Google الأخرى، مثل Docs أو Sheets دون إعادة المصادقة. في مجال الأعمال، يسمح موفرو الخدمات السحابية الذين يقدمون تطبيقات SaaS أو المنصات والبنية التحتية كخدمة أيضًا بالوصول الواسع إلى خدماتها بمجرد تأكيد هوية المستخدم. تُمثل المصادقة الخطوة الأولى في مُخطط اعتماد خدمة أكبر تتيح للمستخدمين تسجيل الدخول مرة واحدة واستخدام مجموعة واسعة من الخدمات. يعتمد الوصول إلى الخدمة على دور كل مستخدم لكل تطبيق—ربما يكون مسؤولاً عن تطبيق واحد ومطورًا في آخر ومستخدمًا نهائيًا في ثالث. يعتمد الوصول أيضًا على ما دفعت المؤسسة مقابله.

تنفيذ SSO

لا تدع عدم وجود خبرة أمان داخلية يثنيك عن اعتماد SSO. يوجد موفرو خدمات أمان مدارة وكذلك فِرق تنفيذ لموردي SSO لتقديم المساعدة. تختار العديد من الشركات استخدام خدمات SSO التي يقدمها موفرو الخدمات من جهات خارجية. تستفيد الشركة من الخبرة وميزات الأمان المُتقدمة وقابلية التوسع، ويمكن لفِرق تكنولوجيا المعلومات التركيز على المساعدة في تنمية الأعمال مع ترك إدارة SSO إلى الخبراء.

على مستوى عالٍ، يتطلب التنفيذ ثلاثة عناصر رئيسة.

1. اختيار أنظمة تصديق العميل وتوزيعها التي تجمع إدخال المستخدم النهائي بأمان، مثل اسم المستخدم وكلمة المرور. حتى داخل المؤسسة، يتم توفير هذه الأنظمة غالبًا باعتبارها صفحات ويب، لذلك؛ من السهل الحفاظ على توحيد عمليات المصادقة عبر الأجهزة. بشكل عام، يجب في المؤسسة أن يكون المستخدم إما على شبكة الشركة أو يصل إليها من خلال VPN. يسمح هذا المتطلب للمؤسسة بإنشاء نظام إدارة هوية واحد وموثوق به.
2. إعداد مدير المعرفات يصدِّق على المستخدمين ويُصدر الشهادات نيابة عن المؤسسة. في معظم المتاجر، يكون مدير المعرفات إما جزءًا من نظام يوفر أيضًا رموز مميزة للاعتماد خاصة بالمستخدم تتيح للتطبيقات معرفة ما يُسمح للفرد القيام به داخل التطبيق أو يرتبط ارتباطًا وثيقًا بخادم الاعتماد.
3. تكوين التطبيقات أو تعديلها لاستخدام الشهادات والرموز المميزة من SSO وأنظمة الاعتماد بدلاً من الاحتفاظ بنظام معرف المستخدم الخاص بها.

أفضل ممارسات SSO

سواء تُطبق داخل الشركة أو بمساعدة من جهة خارجية أو تستخدم نموذجًا كخدمة، فتوجد مفاتيح للنجاح. تشمل ما يلي:

1. التفويض بالمصادقة متعددة العوامل (MFA). مثلما يتيح SSO للمؤسسات فرض سياسات كلمات المرور من إطار عمل واحد، فإنه يمكن أيضًا السماح للمؤسسات بتنفيذ تقنية تعريف أقوى، والمعروفة بشكل جماعي باسم المصادقة متعددة العوامل. يمكن أن تشمل هذه العوامل البطاقات الذكية والتطبيقات التي تعمل عبر الهواتف الذكية وأشكال مُختلفة من المصادقة البيومترية وغيرها.
2. استخدام التحكم في الوصول المستند إلى الأدوار (RBAC). يحل تصديق المستخدمين جزء من مشكلة إدارة الوصول إلى موارد المؤسسة. يكمن التحدي الآخر في الحد من وصول المستخدمين إلى الموارد المسموح لهم باستخدامها فحسب. من خلال إنشاء مجموعات—مثل التسويق والإدارة المالية والتصنيع والمبيعات—ومن خلال إنشاء أدوار داخل كل مجموعة لأعضائها، يمكن ضبط التحكم في الوصول والاحتفاظ به في موقع مركزي يمكن إدارته.
3. مراجعة المعايير وتحديثها. يبسِّط وجود مصادقة تتمحور حول إطار واحد من الآليات إلى حد كبير عملية التدقيق وعملية إجراء التحديثات لتلبية المعايير الجديدة عند ظهورها.
4. تنفيذ إدارة الأدوار والأذونات. يفسح SSO المجال لفلسفة الثقة الصفرية. يمكن للمستخدمين الوصول إلى تلك الموارد المطلوبة صراحةً لأدوارهم فحسب والاطلاع على البيانات التي لهم إذن صريح برؤيتها فحسب.
5. الالتزام بقوانين خصوصية البيانات. لا يضمن استخدام إطار عمل SSO الامتثال إلى قوانين خصوصية البيانات، لكنه يمكن أن يجعل مثل هذا الامتثال أسهل بكثير لتحقيقه وتوضيحه.

التحكم في الوصول بأمان وسهولة باستخدام خدمات Oracle

هل تحتاج إلى إدارة هويات المستخدمين والوصول إلى البنية التحتية من Oracle Cloud (OCI) وعبر التطبيقات السحابية والمحلية؟ بالنسبة إلى المؤسسات التي تتبع إستراتيجية أمان الثقة الصفرية، توفر Oracle Cloud Infrastructure Identity and Access Management (IAM) أدوات الإدارة والتكامل التي تحتاجها.

هل مهتم بنظام المصادقة العالمية مع دعم المُصادقة متعددة العوامل؟ توفر Oracle Access Management نظامًا مرنًا يمكن تشغيله محليًا أو في السحابة. يمكن للمؤسسات تمكين هذه السياسات من اتباع المستخدم بغض النظر عن الجهاز والموقع للمساعدة في تأمين الوصول إلى البيانات من أي مكان، وفي أي وقت، من أي جهاز. إلى جانب MFA، تدعم مجموعة IAM من Oracle طريقة SSO للأجهزة الموثوق به وSSO للتطبيقات—كل ذلك ضروري لتحقيق مبادئ بنية الثقة الصفرية والتفويضات.

نظرًا إلى اعتماد الشركات على المزيد من التطبيقات، واستناد التطبيقات إلى المزيد من الخدمات ومصادر البيانات للقيام بعملها، تزداد صعوبة إدارة مصادقة المستخدم واعتمادها. تبسِّط أطر عمل SSO من الحياة لكل من المستخدمين النهائيين ومهندسي التطبيقات من خلال تبسيط عملية التصديق والاعتماد.

الأسئلة الشائعة حول SSO

ما الذي يشير إليه SSO؟

يشير SSO إلى تسجيل الدخول الموحد.

ما هو حساب SSO الخاص بي؟

يمثل حساب الدخول الموحد الخاص بك خدمة مصادقة مركزية تسمح لك باستخدام مجموعة واحدة من بيانات اعتماد الدخول للوصول إلى تطبيقات وأنظمة متعددة. يعني هذا أنه يتعين عليك تذكر اسم مستخدم وكلمة مرور واحدة فحسب للوصول إلى جميع الخدمات والموارد التي توفرها مؤسستك. تُبسِّط حسابات SSO من عملية تسجيل الدخول، وتحسِّن الأمان، وتسهِّل وصول المستخدمين إلى المعلومات والأدوات التي يحتاجون إليها للقيام بمهامهم.

ما المثال على SSO؟

في مساحة المستهلك، يمكن للمورِّدين الكبار مثل Amazon وGoogle وMeta وMicrosoft العمل باعتبارهم مصدر لبيانات اعتماد المستخدم للتطبيقات الأخرى. إذا تم عرض مربع حوار يتيح لك إدخال بيانات الاعتماد الخاصة بك أو تسجيل الدخول باستخدام إحدى الخدمات أعلاه، فيمكنك استخدام SSO.