لقد واجهنا مشكلة أمنية خطيرة مع نظام الدعوات. أعتقد أنه يمكن تكرارها بسهولة. موقعنا يعتمد على الدعوات فقط. بالإضافة إلى ذلك، قمنا بتحديد “يجب الموافقة على المستخدمين” في الإعدادات.
أحد موظفينا أصدر دعوة بحد أقصى للاستخدام أكبر من 1، وبالتالي لم تكن مقيدة ببريد إلكتروني معين (مثال أدناه).
تم تداول رابط الدعوة هذا، وتمكن الأشخاص من التسجيل به. ومع ذلك، كنا نتوقع أنه عند تحديد “يجب الموافقة على المستخدمين” في الإعدادات، يجب على الموظفين الموافقة على أي شخص يستخدم تلك الدعوات “غير المقيدة بالبريد الإلكتروني”. بدلاً من ذلك، تم قبولهم جميعًا تلقائيًا، بغض النظر عمن لديه الرابط. لذلك يمكن لأي شخص استخدام الرابط ولا يمكننا التحقق من من يدخل به. يجب أن نكون قادرين على “التحقق الخلفي”، باستخدام مزيج من البريد الإلكتروني والاسم والحقول الأخرى التي أضفناها، وهي حقول إلزامية نطلبها للموافقة (بعد أن نتحقق).
هذا خلق مشكلة خطيرة حيث حصل شخص من منظمة أجنبية محظورة بشدة على هذا الرابط وسجل. اضطررت إلى حذف هذا الحساب على الفور. هذه ثغرة خطيرة بالنسبة لنا.
لذلك أجد أن خيار “يجب الموافقة على المستخدمين” مضلل بشكل خطير. حاليًا هذا الخيار لا قيمة له إذا كان موقعنا يعتمد على الدعوات فقط.
هل هناك طريقة للسماح للموظفين بالموافقة على شخص يستخدم رابط الدعوة الذي لم يتم تقييده بالبريد الإلكتروني؟ هذا يبدو طريقة منطقية لتمكين “يجب الموافقة على المستخدمين” عندما يكون الموقع يعتمد على الدعوات فقط.
إذا تم استخدام حساب مستخدم غير موظف لإنشاء دعوة، فهل سيتم وضع عمليات التسجيل عبر هذه الدعوة في قائمة المراجعة؟ إذا كان الأمر كذلك، فهو سلوك مقبول تمامًا ويمكنك استخدام حساب عادي وهمي لإنشاء الدعوة كحل بديل.
أعتقد أنه يجب أن يكون هناك على الأقل تحذير للمستخدمين من الموظفين، وسيكون من الرائع أن يتمكنوا من اختيار كيفية معاملة الأعضاء الجدد. استخدام مستخدم ثانٍ “عادي” سيكون حلاً التفافياً قبيحًا.
بالنظر إلى هذا الموضوع والمواضيع السابقة، يمكنني أن أرى أن الوظيفة الحالية هي “حسب التصميم” ولكنها لا تعكس التغييرات الجديدة على نظام الدعوة. لقد أصبح من السهل جدًا إنشاء روابط دعوة يمكن استخدامها من قبل أشخاص غير معروفين. يمكن الآن أيضًا إنشاء روابط الدعوة بشكل خطير من قبل الموظفين الذين يضيفون المدعوين إلى مجموعات يمكن أن يكون لها وصول إلى فئات آمنة على الموقع.
@Wall-E أنا حريص على فهم كيف تقع روابط الدعوة الخاصة بك في أيدي الأشخاص الذين لا ينبغي السماح لهم بالوصول إلى موقعك. من المفترض أن يعرف موظفو موقعك أن يكونوا حذرين من إنشاء روابط دعوة يمكن لأي شخص استخدامها ومشاركتها علنًا أو في إعدادات حيث سيتمكن الأشخاص الخطأ من استخدامها. إلى حد ما، فإن المشكلة التي تواجهها هي مشكلة تدريب للموظفين. لا تتردد في إرسال إجابتك إليّ عبر الرسائل الخاصة إذا كانت تحتوي على تفاصيل حساسة.
إذا كانت هناك روابط دعوة موجودة حاليًا تم اختراقها بطريقة ما، يمكنك حذفها وإنشاء روابط جديدة ومشاركتها بعناية أكبر في المستقبل. بصفتك مسؤولاً، يمكنك دائمًا البحث في صفحة الدعوات عن المستخدم لمعرفة من قام باسترداد دعواته. إذا كان لديك موظفون لا تثق بهم، يمكنك خفض صلاحياتهم إلى TL4 التي تتمتع بصلاحيات شبه مشرف.
أرى ثلاثة مسارات عمل ممكنة:
لا تفعل شيئًا. نظام الدعوة يعمل حسب التصميم، يحتاج الموظفون فقط إلى توخي الحذر مع روابط الدعوة الخاصة بهم. إذا اتخذنا هذا المسار، نقترح تغيير وصف إعداد المسؤول must approve users لجعله واضحًا تمامًا أن روابط الدعوة التي أنشأها المسؤولون تتجاوز هذا الإعداد.
يجب على الموظفين الموافقة على جميع حسابات المستخدمين الجديدة قبل السماح لهم بالوصول إلى الموقع. ملاحظة: تتجاوز الدعوات التي أنشأها الموظفون هذا الإعداد ولا تتطلب موافقة.
افعل (1) ولكن أضف أيضًا خطوة تحذير إضافية “هل أنت متأكد” عندما ينشئ المسؤولون رابط دعوة يمكن استخدامه للوصول الفوري إلى الموقع. فقط على المواقع التي تتطلب موافقة.
تغيير السلوك بحيث تعمل روابط الدعوة التي أنشأها المسؤولون بنفس طريقة الدعوات من غير المسؤولين وتحترم إعداد must approve users.
أتفق مع صاحب الموضوع بأن السلوك الحالي مضلل، ولديه القدرة على التسبب في مشاكل على المواقع عندما تكون الموافقة مطلوبة. المواقع التي تم تمكين هذا الإعداد فيها تكون حذرة بشكل إضافي وتحتاج إلى هذا المستوى الإضافي من التحكم فيمن يمكنه الوصول.
توصيتي بالتالي هي أن نختار الباب رقم ثلاثة - جعل جميع روابط الدعوة تعمل بنفس الطريقة وتحترم إعداد must approve users.
لا أعتقد أن هذا خطأ، ومع ذلك. إنه يعمل حسب التصميم. إعادة التصنيف كطلب ميزة.
أنا أيضًا أؤيد بشدة الخيار 3. أقوم ببناء مجتمع يمكن للأشخاص فيه التفكير بعمق أكبر في المشاعر وأعتقد أن إضافة هذا المستوى الإضافي من التحكم على روابط الدعوة المجهولة (لأنها غير مرتبطة بعنوان بريد إلكتروني أو هوية) يمكن أن يجعلني أشعر براحة أكبر بأن الأشخاص الذين أريدهم فقط هم من سينضمون.
أفترض أنه يمكنني التأكد من استخدام البريد الإلكتروني للدعوة بدلاً من رابط الدعوة المجهول، لكن الرابط يسهل مشاركته في واتساب أو منصات الاتصال الأخرى.
لذلك أنا أيضًا مع جعل روابط الدعوة المجهولة تحترم إعداد “يجب الموافقة على المستخدمين”.
أيضًا، أعتقد أنه إذا حدث الخيار رقم 3، فيمكن لنظام الدعوة أن يعمل تقريبًا كنظام طلب للمنتديات التي تقتصر على الدعوة فقط. في الوقت الحالي، لست متأكدًا من كيفية جعل الأشخاص يتقدمون للانضمام كأعضاء دون الحاجة إلى نموذج Google منفصل أو ما شابه. يمكن أن يؤدي هذا إلى تبسيط الأمر بطريقة ما، حيث يمكن أن تكون حقول المستخدم المخصصة هي نموذج الطلب - وهو ما أعتقد أن @Wall-E يحاول القيام به.
هذا ليس ما يدور حوله موضوعي. أنا أتحدث عن أن must_approve_users ليس له أي تأثير في مثيل خاص بالدعوات فقط. يجب أن يكون لتشغيله تأثير مختلف عن إيقافه. إذا لم يكن الأمر كذلك، فيجب توثيق أن هذا السلوك لا ينطبق على المثيلات الخاصة بالدعوات فقط. إذا فاتني ذلك في التوثيق، فهذه هي مسؤولية موظفينا بالفعل. ولكن إذا لم يكن الأمر كذلك، فإن هذه الميزة مضللة، ويجب إما إصلاحها، أو على الأقل توثيقها)، لأنها أضلت جميع موظفينا.
سأقتبس من أصحاب السلطة الذين يمكنهم إغلاقنا بسبب هذا الجانب، والذي يعتبر مشكلة أمنية في مؤسستنا: “إذا كان هذا النظام يمكنه السماح لشخص من منظمة غير مصرح بها بالدخول، فيجب عليك افتراض أنه سيفعل ذلك في النهاية، بغض النظر عن اجتهادك”. هذا هو بالضبط ما حدث. تم تمكين هذه “الميزة” (أقول، ليست ميزة لأن “must_approve_user” ليس لها أي تأثير في حالة الدعوة فقط)، وأصدرنا دعوة غير مقيدة للأشخاص الذين أردنا دعوتهم، وبشكل واضح، شارك أحد هؤلاء الأشخاص رابط الدعوة غير المقيد هذا مع منظمة أخرى.
بهذا أجيب أيضًا @tobiaseigen
لدينا اجتماعات ومؤتمرات، مع مئات الأشخاص أحيانًا من منظمات مصرح بها يُسمح لهم بالانضمام إلى منتدانا. ولكن بعضهم يأتي أحيانًا من منظمات أخرى غير مصرح لها بالانضمام إلى منتدانا (بسبب سياسات شاملة خارجة عن سيطرتنا).
انتشر رابط الدعوة هذا “بحريّة”، حتى مع اجتهاد الموظفين، حيث لا يمكننا التحكم فيما سيفعله الأشخاص “المصرح لهم ضمنيًا” بهذا الرابط؛ بحكم التعريف، هذا الرابط “غير مقيد”، لذا يمكنهم إرساله إلى أي شخص يريدون. لا يمكنني لوم موظفيّ على ذلك، لأنه إذا قلت إنه “حسب التصميم” هناك موافقة ضمنية، فهذا يعني أن رابط الدعوة غير المقيد هذا يمكن أن يصل إلى أي مكان، وبالتالي سيصل في النهاية. هذا هو بالضبط ما كان يتحدث عنه رؤساء قسم تكنولوجيا المعلومات لدينا، لأسباب وجيهة. كنا نعرف ذلك، ولذلك قمنا بتمكين “must_approve_users” ليكون بمثابة طبقة الأمان تلك التي اعتقدنا أنها موجودة.
أرى أن هناك سؤالًا حول ما إذا كانت هذه ميزة أم خطأ. أنا لست مبرمجًا محترفًا، هذا متروك لك لتقرره (أنا عالم فيزياء فلكية). أنا فقط أبلغكم عن “مشكلة” خطيرة سببتها لنا، على أمل أن يتم معالجتها حتى نتمكن من الاستمرار في استخدام هذه المنصة الرائعة.
أنا بالكامل مع الخيار 3، وكذلك مركز الأبحاث الخاص بنا، وموظفو منتدى الخاص بي. حتى إشعار آخر، تم توجيه الموظفين بعدم استخدام الدعوة غير المقيدة. وهذا يضيف عبئًا إضافيًا حيث يتعين عليهم الآن إضافة جميع عناوين البريد الإلكتروني الفردية للأشخاص الذين نريد دعوتهم (وفي المؤتمر، هناك أكثر من مئات المشاركين…). القيام بذلك في كل اجتماع، فعاليات، إلخ… سيضيف لزوجة عالية لنمونا، ويمكنني أن أتوقع مغادرة بعض الموظفين بسبب عبء العمل المضاف (معظمهم متطوعون، وجميعهم يعملون فوق طاقتهم في واجباتهم الأخرى).
للأسف، فعالياتنا المعتادة لا تمنحنا الوصول إلى ذلك. تُعامل قوائم جهات الاتصال هذه على أنها معلومات تعريف شخصية (PII) من قبل المنظمة المضيفة التي تستضيف المؤتمر/الاجتماع. حتى لو كان لدينا وصول، فإننا ببساطة لا نملك النطاق الترددي لاستخدام هذه الميزة. سيتعين علينا التواصل مع نقطة اتصال (POC)، والتي تكون دائمًا مرهقة للغاية (حتى لو سُمح لنا بالوصول إلى المعلومات)، لذا مرة أخرى، لزوجة عالية، بحلول الوقت الذي نحصل فيه على روابط الدعوة، يكون الحدث قد انتهى، وفقد الزخم (من قبل موظفينا، ومن قبل المدعوين المحتملين).
تم الإحاطة علماً. يمكن أن يكون هذا حلاً بديلاً. ولكنه يمثل عبئاً إضافياً على موظفينا، الذين لا يملكون الكثير من الوقت لمعالجة هذه الخطوة الإضافية. لذا، فهذا ليس مثالياً.
أنا أفهم أن هذا قد تسبب في بعض المشاكل لك ولمجتمعك، وأنا آسف لذلك!
في المستقبل، أنت الآن تعرف كيف يعمل الأمر، لذا يمكنك التأكد من أنك وزملائك المسؤولين والمشرفين ستستخدمون نظام الدعوة بحكمة!
سؤال الميزة مقابل الخطأ يتعلق بتحديد الأولويات - نحن نحاول إصلاح الأخطاء بسرعة، خاصة إذا كانت أخطاء أمنية! ولكن في هذه الحالة، الوظيفة هي نفسها كما كانت عليه لسنوات وهي مصممة بهذه الطريقة. أعتقد أنه يجب علينا تغييرها ولكنها ليست شيئًا يمكننا التخلي عن كل شيء وإصلاحه الآن.
سنمنح هذا بعض الوقت للآخرين لإبداء آرائهم حتى نتمكن من تحديد الاتجاه الذي نرغب في المضي فيه.
قد يكون هذا تغييرًا أكثر تعقيدًا اعتمادًا على كيفية مشاركة الوصي في العناصر المختلفة لهذه العملية ولكن خيارًا آخر، والذي سيعتمد أيضًا على 3، هو:
أضف خاصية منطقية إلى الدعوات نفسها لتجاوز موافقة المستخدم. ستكون هذه الخاصية معطلة افتراضيًا ولن يتم عرضها إلا في واجهة مستخدم إنشاء الدعوة عندما يكون must_approve_users ممكّنًا.
تعديل: في الواقع، بالنظر مرة أخرى إلى الكود الذي أشار إليه ديفيد، أعتقد أن الوصي لا يشارك على الإطلاق في تحديد ما إذا كان المستخدم المدعو يحتاج إلى الموافقة. يبدو أن هذا الجزء سيكون استبدالًا مباشرًا لـ invite.invited_by.staff? بشيء مثل invite.bypass_approval?
أتفهم تمامًا قيودك المتعلقة بتحديد الأولويات. أعتقد أن نسختنا في وضع غير شائع، حيث أن جميع نسخ Discourse التي أعرفها تأتي من منظمات لا تمتلك سياسات أمنية صارمة يجب علينا الالتزام بها. على سبيل المثال، كان التسجيل بالدعوة فقط قيدًا فرضته منظمتنا، ولم يكن من الممكن أن توجد نسختنا مع التسجيل الذاتي. مع التسجيل الذاتي، سيكون الأمر أسهل، ولن نحتاج إلى استخدام الدعوات غير المقيدة التي يمكن أن “تتسرب”.
