ملخص
يجب إضافة نظام سجل مصادقة موحد إلى Discourse يخزن أحداث المصادقة من جميع طرق المصادقة الممكّنة للتحليل واستكشاف الأخطاء وإصلاحها.
التفاصيل
سنوفر مزود تسجيل مصادقة سيقوم “كل” نظام مصادقة بالربط به وإرسال الأحداث إليه.
على سبيل المثال، قد يحتوي مزود تسجيل الدخول المحلي على القائمة التالية (غير مكتملة) من الأحداث:
- فشل شخص ما من [IP] في تسجيل الدخول كمستخدم
fhqwhgadsالذي لا وجود له - فشل شخص ما من [IP] في تسجيل الدخول كمستخدم
supermathie، وتم تقييده - فشل شخص ما من [IP] في تسجيل الدخول كمستخدم
supermathie، ولكنه قدم كلمة مرور غير صالحة - نجح شخص ما من [IP] في تسجيل الدخول كمستخدم
supermathie، وقدم كلمة مرور صالحة - فشل شخص ما من [IP] في تسجيل الدخول كمستخدم
supermathie، وقدم كلمة مرور صالحة، ولكنه يتطلب MFA للمتابعة - فشل شخص ما من [IP] في تسجيل الدخول كمستخدم
supermathie، وقدم كلمة مرور صالحة، وقدم رمز TOTP غير صالح - نجح شخص ما من [IP] في تسجيل الدخول كمستخدم
supermathie، وقدم كلمة مرور صالحة، وقدم رمز TOTP صالح لرمزvault-work
المشكلة في الاعتماد على السجلات الحالية (سجلات الويب) هي أنه باستثناء السجل المقيد، فإنها جميعًا تبدو متطابقة تمامًا ([200] POST /session HTTP/1.1). لا يوجد معنى يصل إلى السجل.
مخاوف
هناك قلق بشأن الأحداث المجهولة التي تنشئ إدخالات سجل وموازنة ذلك مع اكتشاف الأحداث المثيرة للاهتمام من وجهة نظر تحليل SIEM، على سبيل المثال هجمات رش كلمات المرور.
تسجيل كل شيء يعني أن أي شخص على الإنترنت يمكنه حشو سجلاتك … ولكن من المشكوك فيه ما إذا كانت هذه مشكلة بالفعل أم لا. لاحظ الاحتفاظ أدناه - ربما يتم الاحتفاظ بالفشل لفترة زمنية أقصر داخل سجل التطبيق.
ينشأ سؤال مماثل حول السجلات المستندة إلى الرموز المميزة لمرة واحدة، على سبيل المثال تسجيل الدخول عبر البريد الإلكتروني. من المحتمل ألا تكون الرموز غير الصحيحة “مثيرة للاهتمام” للتسجيل، ولكن الرموز المعاد استخدامها بالتأكيد كذلك، سواء من سياق SIEM أو دعم المستخدم.
أسئلة
الاحتفاظ: الاحتفاظ بكل شيء إلى الأبد؟ 30 يومًا؟ 90 يومًا؟ مسح الأحداث المجهولة بشكل أسرع؟
مصادقة مفتاح API: هل يجب تسجيل المكالمات باستخدام مفاتيح API سيئة للمستخدم أو المسؤول هنا؟ ربما - سيساعد ذلك في تصحيح الأخطاء.
ما مدى قابلية التكوين؟ على سبيل المثال، تشغيل سجلات التصحيح على كل شيء أو على مزود واحد فقط؟
اعتبارات التنفيذ
يجب أن يكون التنفيذ مرنًا بما يكفي للسماح بإضافة مزود تخزين أحداث آخر إلى خط أنابيب التسجيل. قد يكون مثال على هذا المزود ملف سجل خام، أو قائمة انتظار رسائل، أو مخزن S3. التفاصيل الدقيقة لمثل هذا المزود خارج نطاق هذا الموضوع، ولكن يجب أن يكون التنفيذ مرنًا بما يكفي بحيث يمكن للمكون الإضافي التسجيل لتلقي السجلات عند إنشائها.
خلفية
طلب منا أحد العملاء هذا بغرض تغذية الأحداث إلى SIEM الخاص بهم وأدركنا أنها فجوة في ميزات Discourse.
خلال المناقشة الداخلية، اكتشفنا أيضًا أن هذه المعلومات ستكون مفيدة لمسؤولي الموقع ومناصري الدعم لدينا حيث قد تكون سجلات المصادقة في أماكن مختلفة ويجب على المرء معرفة مكان البحث عنها. هذا يعتمد على المعرفة الشخصية وسيسهل السجل المركزي هذا العبء بشكل كبير.
ستكون الطريقة الملائمة لعرض هذه السجلات من وحدة تحكم rails مفيدة لنا ولمسؤولي الموقع.