اليوم ، لدى أي مؤسسة دليل LDAP مليء بمستخدمي هذه المؤسسة. إذا نظرت عن كثب ، ستجد تطبيقًا واحدًا أو أكثر يستخدم نفس الدليل لـ "المصادقة". وعلامات الاقتباس ليست عرضية هنا ، لأن LDAP هو بروتوكول وصول إلى الدليل مصمم للقراءة والكتابة والبحث في خدمة الدليل. هذا ليس بروتوكول مصادقة. يشير المصطلح "مصادقة LDAP" ، بدلاً من ذلك ، إلى ذلك الجزء من البروتوكول (عملية الربط) ، والذي يحدد من أنت وحقوق الوصول التي لديك إلى معلومات الدليل.
بمرور الوقت ، أصبح LDAP خدمة مصادقة فعلية. أصبحت خدمات LDAP واسعة النطاق وذات الأسعار المعقولة ، مثل Active Directory ، معلمة لمطوري البرامج الذين يرغبون في دمج المصادقة في منتجاتهم. مكتبات عملاء LDAP متاحة لأي إطار تقريبًا ، والتكامل سهل التنفيذ نسبيًا.
ولكن على الرغم من حقيقة أن استخدام LDAP يمكن أن يساعد في حل مشكلة تطبيق مصادقة المستخدم في التطبيقات المختلفة للشركة ، فإنه يخلق العديد من المشاكل. بخلاف بروتوكولات المصادقة المصممة خصيصًا ، يؤدي استخدام LDAP إلى وجود ثغرات أمنية متعددة في المعلومات.
لفهم ماهية هذه الثغرات الأمنية ، تحتاج أولاً إلى فهم كيفية عمل مصادقة LDAP.
كيف يعمل مصادقة LDAP
تخيل الموقف التالي (إنه بعيد عن الواقع ، لكنه ينقل الجوهر تمامًا).
لنفترض أنني وضعت طلبية في متجر على الإنترنت بحيث يتم تسليمها إلى منزلي في غيابي. يصل الساعي ويترك ملاحظة أسفل الباب مع النص "أنا آسف ، لم نجد لك" ويطلب مني استلام الطلبية في أقرب نقطة التقاط في وقت مناسب. عند نقطة الالتقاط ، يسأل الموظف عن اسمي وعنواني ويطلب مفاتيح المنزل لتأكيد هويتي. ثم يأتي مسؤول خدمة التوصيل إلى منزلي ويفتح الباب بمفتاحي. يذهب إلى المنزل للتأكد من أنني أعيش هناك ، على سبيل المثال ، من الصور الفوتوغرافية على الحائط أو باسم المرسل إليه في المراسلات. بعد ذلك ، يعود الموظف إلى نقطة الإصدار ويبلغني أنه أكد هويتي بنجاح ، ويمكنني تلقي الطرود الخاصة بي! الصيحة!
بالإضافة إلى مشاكل اللوجستيات ، فإن هذا الموقف مليء بالقضايا الأخرى. ماذا لو قام المراجع عديمي الضمير بعمل نسخة من مفتاحي؟ أم أنه ترك المفتاح لفترة طويلة دون مراقبة ، وفعل أي شخص آخر؟ ماذا لو تعرض المختبر للهجوم وتم استخدام المفتاح الخاص بي؟ عندما أعطي مفتاح شقتي لشخص غريب ، لا أستطيع أن أكون متأكداً من حشمته وسلامتي.
لحسن الحظ ، في العالم الواقعي لدينا وثائق هوية ، على سبيل المثال ، رخصة القيادة أو جواز السفر ، والتي تصدرها الوكالات الحكومية ، وأصالتها ليست موضع شك. يمكنني تقديم هذه المستندات إلى شركة الشحن للحصول على هويتي الشخصية دون تسليم المفاتيح.
في عالم LDAP ، لا يزال يتعين علينا تمرير مفاتيحنا لفتح الباب نيابة عنا. ننقل كلمة المرور الخاصة بنا إلى جهة خارجية ، وهو يحاول اختراق خادم LDAP معها. إذا تمكن من الوصول ، فلا يمكننا التأكد من أن بيانات الاعتماد الخاصة بنا ليست عرضة للخطر. في هذه الحالة ، لن يحصل المهاجم فقط على القدرة على فتح باب LDAP ، ولكن أيضًا الوصول إلى أي تطبيق يستخدم نفس بيانات الاعتماد.
لحسن الحظ ، في عالم أكثر اكتمالا من المصادقة ، لدينا أيضا جوازات السفر ورخص القيادة! بروتوكولات المصادقة ، مثل Kerberos و SAML و OpenID Connect ، تصدر الرموز المميزة لأطراف ثالثة. تؤكد الرموز أنك الشخص الذي تدعي أنه لا توجد حاجة لنقل مفاتيحك إلى أي شخص. نظرًا لأن LDAP لم يتم تصميمه كبروتوكول مصادقة ، فهو يفتقر إلى الآليات المناسبة.
عيوب LDAP كنظام مصادقة
في عام 2007 ، أصدر Shumon Hack مقالًا عن الخيال العلمي (
نقاط ضعف LDAP كنظام مصادقة مركزي ) يصف فيه ثلاث مشكلات محددة عند استخدام LDAP كنظام مصادقة.
1. ربما لا يكون التطبيق آمنًا بدرجة كافية للتعامل مع بيانات الاعتماد
يؤكد المؤلف على أن حماية مجموعة صغيرة من خوادم المصادقة من الهجوم أسهل بكثير من حماية عدد كبير من خوادم التطبيقات.
بالنسبة للجزء الأكبر ، تخضع خوادم المصادقة ، كقاعدة عامة ، لإشراف وثيق من المتخصصين ذوي الخبرة الكبيرة في مجال أمن المعلومات.
من ناحية أخرى ، تتمتع خوادم التطبيقات بمستوى أمان مختلف تمامًا وهي أكثر عرضة لخطر التسوية. فهي أقل أمانًا ، وتعمل مع مجموعات البرامج الأكثر تعقيدًا ، ومن المحتمل أن تكون بها نقاط ضعف. وغالبًا ما يتم إدارتها بواسطة أشخاص ليس لديهم معرفة عميقة بالأمان. يعد بناء نظام الأمان الصحيح عملية معقدة يسهل فيها ارتكاب خطأ ما.
المشكلة هي أنه إذا تم اختراق خادم تطبيق واحد ، فسيتم أيضًا اختراق جميع بيانات الاعتماد التي استخدمها مالكوها أثناء الهجوم. أي نظام آخر يستخدم نفس دليل LDAP للمصادقة في خطر.
2. لا يمكن لخادم LDAP تأمين آلية المصادقة المستخدمة للحصول على بيانات الاعتماد
لا يمكن لخادم LDAP ضمان أمان المعاملة. على الرغم من أن خادم LDAP ، على سبيل المثال ، يمكنه فرض الربط عبر TLS لضمان عدم إرسال بيانات الاعتماد بنص واضح ، إلا أن الخادم نفسه لم يضطلع بأي دور في الحصول على بيانات الاعتماد من المستخدم. هناك خطر في أن يتلقى التطبيق كلمة مرور من خلال قناة غير آمنة.
3. يضطر المستخدم إلى مشاركة سر المصادقة مع طرف ثالث
يجب أن تظل كلمة مرور المستخدم أو سر المصادقة
سرًا . يجب أن يكون معروفًا فقط للمستخدم ونظام المصادقة. عند استخدام مصادقة LDAP ، يضطر المستخدم إلى مشاركة سره مع جهة خارجية حتى تتمكن من استخدام هذا السر للتفاعل مع دليل LDAP نيابة عن المستخدم.
من المهم الإشارة إلى أنه عند استخدام بروتوكولات المصادقة المصممة خصيصًا مثل Kerberos ، وحتى من بروتوكول NTLM السابق ، لا يتم نقل سر المستخدم عبر الشبكة. يستخدم كل من الجهاز العميل والخادم عمليات تشفير لإثبات لبعضهما البعض أنهما يحملان نفس السر ولا يقومان حتى بتبادل السر نفسه.
إلى نقاط Shumon Hook ، سأضيف وصفًا للعديد من الفروق الدقيقة في مصادقة LDAP ، استنادًا إلى تجربتي الخاصة. بادئ ذي بدء ، يتعلق الموضوع باستخدام Active Directory.
4. لا يعرف الكثير من المطورين ما يكفي من آليات LDAP لاستخدامه بشكل صحيح
تصف إحدى مشاركات
مدونتي السابقة كيف سمح الربط المجهول وغير المصادق بتجاوز مطوري التطبيقات وجعل المستخدمين غير المصرح لهم يتخطون. تعد القدرة على إجراء عملية ربط بدون مصادقة واحدة من التفاصيل الدقيقة للبروتوكول التي لا يعرفها حتى خبراء LDAP الأكثر خبرة.
ليس من السهل تنظيم الدلائل ويمكنها تخزين كمية هائلة من المعلومات التنظيمية وتوفير العديد من الطرق القابلة للتخصيص لتخزينها. لقد رأيت كثيرًا من الحالات التي افترض فيها مطور التطبيق وجود فئة أو سمة معينة من الكائنات ، وعندما لم يتم اكتشافها ، تعطل التطبيق. لمصادقة المستخدم ، لا ينبغي أن تكون معرفة بنية البيانات المخزنة في الدليل مطلوبة وتطبيقها. يجب أن يتم استخلاص بروتوكول المصادقة من تفاصيل مستودع تخزين الكائنات الموجود بمستوى أقل.
5. لا يقوم مسؤولو التطبيق في الغالب بتكوين عملاء LDAP بشكل صحيح
عند إدارة "Active Directory" في بيئة موزعة كبيرة ، هناك فارق بسيط واحد غير سارة: من الصعب تحديد التطبيقات المحددة التي تستخدم Active Directory كدليل LDAP ، وكيف قام مسؤولو التطبيق بالضبط بتكوين عميل LDAP.
فيما يلي أمثلة على أهوال التكوين الخاطئ.
- Hardcoding DN في التطبيقات أو باستخدام DN في عملية ربط. تحدث المشكلات دائمًا عند إعادة تسمية أو نقل الكائنات داخل الدليل ، وكل ذلك بسبب قيام شخص ما بالتشعب في مكان ما. (ملاحظة لأولئك الذين يقومون بعمليات ربط بسيطة مع Active Directory: ليست هناك حاجة لاستخدام DN. يوفر Active Directory أيضًا تنسيقات DN بديلة أكثر موثوقية من استخدام التنسيق التقليدي).
- بالنسبة لعملية الربط ، لا يتم استخدام حساب خدمة ، ولكن يتم استخدام حساب شخصي للمطور أو المسؤول (تخيل ما سيحدث عندما يغادر مالك الحساب الشركة).
- إرسال كلمات المرور بنص واضح إلى المنفذ 389.
- هناك تطبيقات لا يلزم فيها تحديد خانة الاختيار "التحقق من صحة الشهادة" عند الاتصال بـ AD باستخدام TLS (المنفذ 636). لماذا هذا مقبول عموما؟ كيف يمكنني تمرير كلمة المرور إلى خدمة تابعة لجهة خارجية دون الاقتناع بأصالتها؟
جعل عمل عميل LDAP أمرًا سهلاً. لكن حقيقة أنه يعمل لا يعني أن التكوين صحيح.
6. تعد مصادقة LDAP وخدمات المصادقة الحديثة حصرية بشكل متبادل
يجب أن يعتمد أي تطبيق يستخدم LDAP للمصادقة دائمًا على أسماء المستخدمين وكلمات المرور. من المستحيل تقريبًا محاولة تنفيذ التقنيات الحديثة ، مثل المصادقة متعددة العوامل وتسجيل الدخول الموحد (إلا إذا كنت ستقوم بتنفيذ التقنيات الخاصة بك ، والتي هي في حد ذاتها فكرة سيئة). يلتزم FIDO Alliance بجعل كلمات المرور من مخلفات الماضي ، وسيكون كل تطبيق يستخدم مصادقة LDAP عقبة أمام سياسة خالية من كلمة المرور.
ما هي الخيارات؟
يمكن لتطبيقات الويب اليوم الاستغناء عن مصادقة LDAP. هناك العديد من بروتوكولات مصادقة الويب الرائعة ، مثل SAML و WS-Federation و OpenID Connect ، والتي لا تتطلب بيانات اعتماد المستخدم للعمل مع تطبيقات الطرف الثالث. توفر منتجات لا حصر لها هذه الخدمات ، بما في ذلك خدمة اتحاد Active Directory (المضمنة في Windows Server) أو خدمات الجهات الخارجية مثل Microsoft Azure AD و Okta و Ping وغيرها. إذا لم يكن لدى مؤسستك IdP متحد ، فإن أول ما عليك فعله هو تنفيذه.
الشيء الرئيسي الذي يجب الانتباه إليه عند اختيار برنامج جديد هو دعم بروتوكولات المصادقة الحديثة. حتى إذا كان العمل يحتاج إلى التطبيق هنا والآن ، فلا تتعجل في اختيار حل ، خاصةً إذا كان هذا الخيار مقصورًا فقط على المنتجات ذات مصادقة LDAP. يجدر محاولة توصيل البائع المختار بالحاجة إلى تحسين المنتج باستخدام بروتوكولات مصادقة أكثر حداثة. ربما سيستمع وينقح خطته التنموية.
يتزايد عدد تطبيقات سطح المكتب مع "عميل كثيف" يدعم بروتوكولات المصادقة الحديثة ، وهذا في الواقع اتجاه بهيج. كانت هذه التطبيقات عادةً معقل مصادقة LDAP. يسهل عدد متزايد من أدوات تطوير البرامج (SDK) ، مثل مكتبة مصادقة Microsoft (MSAL) ، للمطورين إضافة دعم لخدمات المصادقة الحديثة إلى تطبيقاتهم المحمولة وتطبيقات سطح المكتب.
في النهاية ، تجدر الإشارة إلى أنه في واقع اليوم ، لا تدعم جميع التطبيقات بروتوكولات المصادقة الحديثة ، وربما لا تكون كذلك. قد لا يكون تطبيق الحظر الكامل على مصادقة LDAP ممكنًا في أي مؤسسة. ومع ذلك ، لا ينبغي بأي حال من الأحوال تشجيع مصادقة LDAP داخل المنظمة. يجب النظر في استخدام LDAP فقط في حالة عدم وجود خيارات أخرى.