الملخص
يُزعم أن إحدى بورصات العملات المشفرة المعروفة باسم NCX تركت مثيل MongoDB داخليًا مكشوفًا على الإنترنت العام دون مصادقة. كان يمكن الوصول إلى قاعدة البيانات لأشهر، وكانت تحتوي على حوالي 1 جيجابايت من البيانات وأكثر من 5 ملايين سجل، وتضمنت أسماء ورسائل بريد إلكتروني وتواريخ ميلاد وروابط مستندات "اعرف عميلك" وكلمات مرور مجزأة وبذور/عناوين URL للمصادقة الثنائية ومفاتيح واجهة برمجة التطبيقات الداخلية وسجل عناوين IP وعناوين محفظة الحسابات وسجلات المعاملات.(المراجعة الأمنية اليومية) هذا ليس مجرد "تسريب لمعلومات التعريف الشخصية". إنه سطح اختراق كامل: سرقة الهوية، والاحتيال في "اعرف عميلك"، والاستيلاء على الحسابات، والاستهداف على السلسلة، والتعرض التنظيمي، والتزامات الاستجابة للحوادث بموجب أنظمة حماية البيانات الحديثة التي تتطلب الإفصاح في غضون 72 ساعة.(اللائحة العامة لحماية البيانات العامة)
تتناول هذه المقالة الاختراق على غرار NCX من زاويتين:
- الاختبار الهجومي / واقع الفريق الأحمر - كيف يتحول سوء التكوين هذا إلى استغلال نشط.
- الامتثال والاستجابة - ما هو المطلوب منك فعله بمجرد أن تعرف أنك فقدت السيطرة على بيانات هوية العميل والأسرار متعددة العوامل.
سنقوم أيضًا بتخطيط كيف يمكن لمنصة اختبار هجومية مستمرة مثل Penligent أن تكشف وتحاكي أنماط الفشل الدقيقة هذه قبل أن يقوم المنظم أو المهاجم أو الصحفي بذلك.
نظرة عامة على الحادث: ما الذي تسرب ولماذا هو مهم
المشكلة المبلغ عنها بسيطة في صياغتها ووحشية في عواقبها: مثيل MongoDB متصل بالإنترنت بدون مصادقة. ويمكن لأي شخص يعرف (أو يمكنه تخمين/مسح) عنوان IP والمنفذ أن يتصفح المجموعات بنص عادي.(المراجعة الأمنية اليومية)
أنواع البيانات المكشوفة
وفقًا للإفصاح، احتوت مجموعة بيانات NCX (لكل سجل، على ملايين الصفوف):
- الاسم الكامل / البريد الإلكتروني / تاريخ الميلاد
- روابط صورة "اعرف عميلك" أو روابط المستندات (جواز السفر، مسح ضوئي لبطاقة الهوية)
- قيم المصادقة الثنائية الأولية وعناوين URL للتسجيل
- كلمات مرور مجزأة
- سجل عناوين IP والبيانات الوصفية لتسجيل الدخول
- مفاتيح واجهة برمجة التطبيقات الداخلية/رموز الخدمة
- عناوين المحفظة، وسجل الإيداع/السحب، ونشاط السلسلة
- إشارات حالة الحساب (حظر / تجميد / خطر)
- سجلات تذاكر الدعم
هذا أمر سيء بشكل غير عادي لثلاثة أسباب:
- الاستيلاء على الهوية على نطاق واسع
إذا كان لدى أحد المهاجمين اسمك القانوني + DoB + صورة جواز السفر، فيمكنه فتح حسابات في مكان آخر، أو "استرداد الحساب" باستخدام الهندسة الاجتماعية، أو تمرير "اعرف عميلك" في أماكن أضعف. هذه هي ميزة سرقة الهوية في الكتاب المدرسي.(المراجعة الأمنية اليومية) - تجاوز MFA من خلال التعرُّض البذرة 2FA
إذا تم تخزين وتسريب بذور كلمة المرور لمرة واحدة المستندة إلى الوقت (TOTP)، يمكن للمهاجم إنشاء رموز 2FA صالحة عند الطلب وتسجيل الدخول بصفتك - حتى لو لم تشارك كلمة المرور الخاصة بك. إن بذور المصادقة الثنائية المخترقة هي في الأساس "رموز جلسة مخبوزة مسبقًا".المراجعة الأمنية اليومية) - استهداف الحراسة + الاستهداف على السلسلة
تسمح عناوين المحفظة وتاريخ المعاملات للخصم بتحديد المستخدمين الذين يحركون الحجم الفعلي. يمكن بعد ذلك تصيد تلك الأهداف ذات القيمة العالية ("تم حظر السحب الخاص بك، يرجى التوقيع هنا") أو تبديل بطاقة SIM. لقد رأينا منصات التشفير تحذر المستخدمين المخترقين من توقع التصيد الاحتيالي المخصص باستخدام هذا الأسلوب بالضبط.(المراجعة الأمنية اليومية)
مشكلة عدم الاستجابة
وأفادت التقارير أن الباحثين الذين عثروا على MongoDB المفتوح حاولوا الكشف المسؤول عدة مرات ولم يتلقوا ردًا في الوقت المناسب(المراجعة الأمنية اليومية)
من وجهة نظر تنظيمية، هذا أمر كارثي: تتوقع أنظمة اللائحة العامة لحماية البيانات والعديد من السلطات الوطنية لحماية البيانات الاحتواء السريع، والحفاظ على الأدلة، وإخطار الجهات التنظيمية بالاختراق في غضون 72 ساعة، وفي كثير من الحالات، إخطار المستخدم إذا كان الخطر على المستخدمين مرتفعًا.(اللائحة العامة لحماية البيانات العامة)

سلسلة الهجمات: كيف يحول الفريق الأحمر "فتح حساب MongoDB" إلى اختراق كامل للحساب
هذا القسم مكتوب على شكل سرد لاختبار الاختراق، لأن هذه هي الطريقة التي سيسير بها المهاجم (أو المختبر المسؤول).
الخطوة 1: تعداد MongoDB المكشوف
- تفحص المنافذ مساحات واسعة من مساحة العنوان السحابي لمنافذ MongoDB الكلاسيكية (27017/27018).
- انتزاع حالة الشعار / الخادم لتأكيد الوصول غير المصادق عليه.
- قائمة قواعد البيانات والمجموعات (
db.getCollectionNames()إلخ). - تخلص من المجموعات عالية القيمة:
المستخدمون,المصادقة,كايك,المحفظة,المعاملات,مفاتيح apiKeys,التذاكر.
بعبارة أخرى، هذا ليس "يوم صفر". إنه سوء تهيئة على مستوى التسعينيات: قاعدة بيانات على الإنترنت، بدون مصادقة، بدون جدار حماية. تحذر CISA و NIST مرارًا وتكرارًا من أن مخازن البيانات المكشوفة على الإنترنت دون مصادقة تظل واحدة من أكثر نقاط الدخول إلى الاختراق شيوعًا.(المفوضية الأوروبية)
إليك جلسة زائفة مبسطة قد يقوم أحد المهاجمين بتشغيلها من صندوق اختبار (لا تقم بتشغيلها على أنظمة لا تملكها أو لديك إذن بتقييمها؛ إذ أن إجراء وصول غير مصرح به غير قانوني):
# اكتشف مضيفي MongoDB المفتوحين (مثال على المنطق فقط)
nmap -p 27017 --open -oG mongo_hosts.txt
# الاتصال بمضيف مكتشف بدون بيانات اعتماد
mongosh -المضيف :27017 --Eval "db.adminCommand('listDatabases')"
# تعداد المجموعات في قاعدة بيانات مستهدفة
mongosh -المضيف :27017 --الإصدار "استخدام ncx_users؛ db.getCollectionNames()"
# تفريغ المستندات المتعلقة بالمستخدمين
mongosh -المضيف :27017 --الإصدار "استخدام ncx_users؛ db.users.find().limit(5).pretty()"
بالنسبة للفريق الأحمر الحقيقي، هذه هي رهانات الطاولة. أما بالنسبة للجهة التنظيمية أو محامي المدعي، فهذا دليل دامغ على أن النظام لم يكن لديه "ضوابط أمنية معقولة".
الخطوة 2: حصاد الأسرار ومواد التصديق
بمجرد دخولك إلى الداخل، يسحب المهاجم
كلمة_كلمة_التجزئةأو ما يعادلهاtotp_seed/2ألف_سرمفتاح_مفتاح_API/api_secret- عناوين URL لملف "اعرف عميلك
هذه هي الجائزة الكبرى. يمكن اختراق تجزئات كلمات المرور دون اتصال بالإنترنت؛ وتتيح لك بذور TOTP صك رموز MFA صالحة؛ ويمكن لمفاتيح واجهة برمجة التطبيقات التحدث إلى المسؤول الداخلي أو إلى خلفيات التداول.
وقد لاحظ الباحثون الأمنيون وفرق DFIR مرارًا وتكرارًا أن بذور المصادقة الثنائية (2FA) المسربة وبيانات اعتماد واجهة برمجة التطبيقات "القابلة لإعادة الاستخدام" هي غنيمة عالية القيمة لأنها تتحول إلى استيلاء مباشر على الحسابات وحركة جانبية.(المراجعة الأمنية اليومية)
الخطوة 3: محاكاة الاستيلاء على الحساب
باستخدام اسم مستخدم/بريد إلكتروني + كلمة مرور (أو تجزئة مخترقة دون اتصال بالإنترنت) + بذرة TOTP مسروقة، يمكن للمهاجم إنشاء رموز صالحة مكونة من 6 أرقام محليًا. وهذا يعني تسجيل الدخول الكامل دون لمس هاتف الضحية.
إذا كانت الصرافة تدعم إعادة تعيين كلمة المرور عن طريق البريد الإلكتروني بالإضافة إلى المصادقة الثنائية (2FA)، وكلاهما مخترق، يمكن للمهاجم أن يحجب المستخدم بالكامل. هذا السيناريو - تجاوز المصادقة الآلية باستخدام بيانات TOTP المسروقة أو بيانات إعادة تعيين العامل - هو بالضبط السبب في أن أدلة الاستجابة لخرق التشفير تخبر المستخدمين المتأثرين بتدوير بيانات الاعتماد على الفور، وإعادة تسجيل المصادقة الآلية، ومراقبة عمليات السحب.(CCN.com)
الخطوة 4: اعرف عميلك وإساءة استخدام الهوية
نظرًا لأن روابط صور "اعرف عميلك" وعمليات مسح الهوية كانت واضحة (أو خلف عناوين URL قابلة للتخمين/طويلة العمر)، يمكن للمهاجمين استخدامها:
- لفتح حسابات صرافة جديدة في مكان آخر كشخص آخر;
- إلى دعم العملاء في الخدمات الأخرى ("سأرسل لك جواز سفري الآن، من فضلك افتح القفل");
- لمخادعة المستخدمين ذوي القيمة العالية بتفاصيل شخصية للغاية ("مرحبًا، وفقًا لـ AML، قمنا بتجميد السحب الخاص بك...").
نحن نرى بالفعل منصات التشفير تحذر علنًا من أن تسريبات "اعرف عميلك" تصبح وقودًا للتصيد الاحتيالي والاحتيال المصمم خصيصًا.(المراجعة الأمنية اليومية)

الخطوة 5: الاستهداف على السلسلة
تخبرك عناوين المحفظة وسجلات المعاملات من الذي يحرك بالفعل حجمًا كبيرًا. هذه القائمة ذهبية لـ
- التصيد الاحتيالي ("التحقق من الأمان"),
- تهديدات الابتزاز
- هجمات إزالة الغبار وعمليات الاحتيال لاختطاف الموافقات (وقّع على هذا، تخسر الأموال).
لقد تحول المهاجمون من "سرقة كلمات المرور الخاصة بالتبادل" إلى "تسليح البيانات الوصفية المالية المسربة" لأنها تتوسع وتصبح أفضل من الناحية الاجتماعية.(المراجعة الأمنية اليومية)
قائمة المراجعة الدفاعية والعلاجية (التقنية)
هذا هو ما يجب أن تفعله NCX (أو أي بورصة عملات رقمية أو محفظة تكنولوجيا مالية أو منصة "اعرف عميلك") فور اكتشاف تسريب مفتوح في MongoDB.
خط الأساس لأمن قاعدة البيانات
- اقتل التعرض العام الآن:: إزالة المثيل من التوجيه العام أو قفله خلف قواعد جدار الحماية/وصول VPC فقط.
- طلب المصادقة:: تمكين مصادقة MongoDB والوصول المستند إلى الأدوار؛ وعدم السماح بالقراءة المجهولة من الإنترنت.
- TLS في كل مكان:: فرض النقل المشفر، وليس النص العادي.
- مبدأ الامتيازات الأقل:: يجب أن ترى الخدمات المصغرة التي تواجه المستخدم فقط المجموعات التي يحتاجها تمامًا.
- التسجيل والتنبيه:: ربط سجلات التدقيق المستمرة بشأن محاولات الوصول والاستعلامات الشاذة. ويتوقع المعهد الوطني للمعايير والتكنولوجيا والابتكار والتكنولوجيا والهيئات التنظيمية في الاتحاد الأوروبي وجود سجلات تبين من قام بالوصول إلى ماذا ومتى وأثناء وبعد الاختراق.(المفوضية الأوروبية)
الحوكمة السرية والمفتاح
- تدوير مفاتيح API وجدت في مكب النفايات، افترض أنها مخترقة.
- إبطال صلاحية "عناوين URL الخاصة" طويلة الأمد إلى صور "اعرف عميلك"؛ انقل تلك الأصول خلف عناوين URL الموقّعة قصيرة الأجل مع ACL صارمة (مثل عناوين URL S3 الموقّعة مسبقًا مع انتهاء الصلاحية على نطاق الدقائق، وحدود IP، والتدقيق).
- تحصين واجهات برمجة التطبيقات الإدارية الداخلية التي يمكن أن تصيبها المفاتيح المسربة: على سبيل المثال تتطلب TLS متبادلة، وقوائم IP المسموح بها، وموقف الجهاز.
2 المصادقة الثنائية/إعادة تعيين المصادقة الثنائية على نطاق واسع
- تعامل مع جميع بذور TOTP المكشوفة على أنها محروقة. فرض إعادة التسجيل للحسابات المتأثرة.
- تتطلب إعداد 2FA جديد مع بذور جديدة لا يتم تخزينها في نص عادي.
- بالنسبة للحسابات عالية المخاطر (على سبيل المثال الأرصدة الكبيرة)، أضف التحقق التدريجي مؤقتًا لعمليات السحب وتغيير كلمات المرور. تشجع فرق الأمن وحتى الجهات التنظيمية على "الاحتكاك التكيفي" بعد الاختراق في العمليات عالية القيمة.(CCN.com)
معالجة بيانات "اعرف عميلك
- انقل مستندات "اعرف عميلك" إلى تخزين مشفّر مع تحكم صارم في الوصول ورموز استرجاع قصيرة الأجل، وليس روابط عامة دائمة.
- إضافة تسجيل الوصول في طبقة الكائن (من شاهد جواز السفر X في الوقت Y).
- تقليل الاحتفاظ - يتطلب النظام الأوروبي العام لحماية البيانات (GDPR) تقليل البيانات وتحديد الغرض منها. إذا لم تكن بحاجة إلى مسح كامل الدقة لجواز السفر إلى الأبد، فلا تحتفظ به إلى الأبد.(اللائحة العامة لحماية البيانات العامة)
الطب الشرعي + نظام الاستجابة للحوادث
- التقط صورة لقطات لقاعدة البيانات المكشوفة للأدلة.
- التقاط سجلات الوصول قبل/بعد الإزالة لإعادة بناء الجدول الزمني.
- بدء سير عمل الإخطار بالاختراق:
- إخطار هيئة حماية البيانات في غضون 72 ساعة من علمك بالأمر، إلا إذا كان بإمكانك إثبات انخفاض المخاطر;
- إخطار المستخدمين المتأثرين "دون تأخير لا مبرر له" إذا كان هناك خطر كبير عليهم (سرقة الهوية، والاستيلاء على الحساب مؤهل بوضوح).(اللائحة العامة لحماية البيانات العامة)
- توثيق سلسلة العهدة بأكملها. تتوقع منك كل من اللائحة العامة لحماية البيانات ومعظم شركات التأمين السيبراني أن تحتفظ بالأدلة وخطوات المعالجة.(بيركنز كوي)
فيما يلي جدول زمني مبسط للإصلاح يتوقع تنفيذه في أول 48 ساعة بعد اكتشافه:
| النافذة الزمنية | الإجراء |
|---|---|
| أول 2-4 ساعات | قم بسحب قاعدة البيانات من الإنترنت/جدار الحماية الخاص بها، والتقاط الأدلة والبدء في تسجيل كل شيء. |
| أول 12 ساعة الأولى | إبطال مفاتيح واجهة برمجة التطبيقات، وإبطال عناوين URL المكشوفة، وتجميد عمليات السحب عالية المخاطر. |
| أول 24 ساعة الأولى | فرض إعادة تعيين كلمة المرور + المصادقة الثنائية للحسابات المكشوفة؛ تفعيل الاحتكاك التكيّفي. |
| خلال 48 ساعة | مسودة إخطار الجهة التنظيمية، مسودة إخطار العميل، موجز قانوني وامتثال. |
| ≤72 ساعة (نافذة اللائحة العامة لحماية البيانات) | إخطار السلطة المعنية + المستخدمين المتأثرين، وتقديم ملخص للحادث + التخفيف من آثاره. |
تدعو الهيئات التنظيمية مثل DPAs في الاتحاد الأوروبي و ICO في المملكة المتحدة صراحةً إلى أن الإبلاغ عن الاختراق للسلطات يجب أن يحدث بشكل عام في غضون 72 ساعة من العلم به، ويجب أن تكون مستعدًا أيضًا لإخطار الأفراد المتضررين إذا كان هناك "خطر كبير" عليهم.(اللائحة العامة لحماية البيانات العامة)
تخطيط الامتثال: اللائحة العامة لحماية البيانات، و SOC 2 / SOC 3، والتوقعات الخاصة بالتشفير
اللائحة العامة لحماية البيانات / حماية البيانات على غرار الاتحاد الأوروبي
بموجب المادة 33 والمادة 34 من اللائحة العامة لحماية البيانات (GDPR)، إذا تعرضت لخرق للبيانات الشخصية يهدد حقوق الأشخاص وحرياتهم، يجب عليك
- إخطار السلطة الإشرافية في غضون 72 ساعة من علمها بالأمر، و
- إبلاغ المستخدمين المتأثرين "دون تأخير لا مبرر له"، واصفًا ما تم كشفه وما تقوم به حيال ذلك(اللائحة العامة لحماية البيانات العامة)
بالنسبة للعملات المشفرة، فإن تسريب مستندات اعرف عميلك + مستندات الهوية + البيانات الوصفية لتسجيل الدخول + بذور المصادقة الثنائية (2FA) هو أمر "عالي الخطورة" على الأفراد. فهو يتيح الاحتيال في الهوية، والخسارة المالية، والهندسة الاجتماعية - لن يقبل المنظمون السكوت.
ضوابط نمط SOC 2 / SOC 3
في لغة SOC 2 / SOC 3 (الأمان والتوافر والسرية)، تعد قاعدة بيانات الإنتاج المفتوحة وغير المصادق عليها انتهاكًا مباشرًا للتحكم في الوصول وأمن الشبكة وتوقعات إدارة التغيير. لا يمكنك اجتياز تدقيق SOC الناضج إذا كانت "معلومات التعريف الشخصية والأسرار الهامة للعميل على عنوان IP عام بدون مصادقة".
الإخطار بالاختراق والثقة في التشفير
تقع بورصات العملات المشفرة في منطقة غريبة: فبعضها ليست بنوكًا مرخصة بالكامل، ولكنها لا تزال تتعامل مع أموال العملاء وجوازات السفر وبيانات مكافحة غسل الأموال/ اعرف عميلك. وهذا يعني:
- يتم الحكم عليك مثل أمين الحفظ في مجال التكنولوجيا المالية (حماية أرصدة العملاء، ومنع الاحتيال) ومثل مراقب البيانات (حماية البيانات الشخصية، والإبلاغ عن الانتهاكات).(المراجعة الأمنية اليومية)
- إذا لم تقم بالإخطار، فأنت لا تخاطر فقط بالغرامات. أنت تخاطر بإلحاق ضرر دائم بالعلامة التجارية داخل مجتمعات العملات الرقمية، التي أصيبت بجنون العظمة بالفعل بعد سنوات من الاختراقات وسحب البساط من البورصة.(CCN.com)
كيفية التقاط حالات فشل "فئة NCX" قبل أن يفعل الإنترنت (Penligent View)
دعونا نكون صريحين: "MongoDB عام بدون مصادقة يكشف أكثر من 5 ملايين سجل" هو نوع من الأشياء التي يجب أن تكتشفها حلقة اختبار هجومية لائقة قبل وقت طويل من قيام الصحفيين بذلك.(المراجعة الأمنية اليومية)
بنليجنت (https://penligent.ai/) يتعامل مع هذا الأمر كاختبار عدائي آلي مستمر وآلي - أي فريق أحمر دائم التشغيل. إليك كيف يتم ذلك:
رسم خرائط الأصول ومراقبة التعرض
يقوم وكلاء Penligent باستمرار بتعيين سطح الهجوم الخارجي (نطاقات IP السحابية، والنطاقات الفرعية، والخدمات المسربة) والإبلاغ عن مخازن البيانات التي تواجه الإنترنت مثل MongoDB وRedis وElasticsearch ودلاء تخزين الكائنات غير المصادق عليها، وما إلى ذلك. هذه هي بالضبط فئة التهيئة الخاطئة التي أدت إلى انكشاف NCX.(المراجعة الأمنية اليومية)
محاكاة اكتشاف البيانات الحساسة/محاكاة اكتشاف المفاتيح
ضمن النطاق المصرح به، يحاول Penligent تحديد "جواهر التاج" عالية القيمة في الخدمات المكشوفة:
- بذور 2FA/TOTP
- مفاتيح API ورموز الخدمة المميزة
- روابط أو مجموعات مستندات "اعرف عميلك
- البيانات الوصفية للمحفظة/السحب
تقوم المنصة بعد ذلك ببناء مسار استغلال ("باستخدام هذه البذرة يمكننا إنشاء رموز MFA"، "باستخدام هذا المفتاح يمكننا الوصول إلى واجهة برمجة التطبيقات الداخلية للمشرف")، وهو ما قد يفعله المهاجمون الحقيقيون - ولكن يفعلون ذلك في صندوق رمل خاضع للرقابة بدلاً من اختطاف الحسابات فعلياً. وهذا يخلق سرداً للمخاطر مدعوماً بالأدلة يمكن لفرق الأمن أن تنقله إلى القيادة.
اختبار مسار MFA ومسار الانسحاب
يستطيع Penligent محاكاة الاستيلاء المشروط على الحساب: "إذا قام أحد المهاجمين بسرقة هذه البذور، هل يمكنه تسجيل الدخول؟ هل يمكنهم الانسحاب دون مراجعة يدوية؟ هل يمكنهم إعادة تعيين البريد الإلكتروني؟ يمنحك ذلك قائمة إصلاحات مرتبة بدلاً من دوامة الذعر.
الإبلاغ عن الامتثال
وأخيرًا، يقوم Penligent بتعيين النتائج إلى واجبات الخرق خلال 72 ساعة من اللائحة العامة لحماية البيانات (GDPR) وفشل التحكم في SOC 2 / SOC 3 ومخاطر حفظ التشفير. هذا مهم لأنك لا تحتاج فقط إلى إصلاح الخلل - بل تحتاج إلى إثبات أن لديك عملية واتخذت إجراءات، ويمكنك إطلاع المنظمين على ذلك.(اللائحة العامة لحماية البيانات العامة)
في الممارسة العملية، هذا هو الفرق بين "لم يكن لدينا أي فكرة عن أن قاعدة البيانات الخاصة بنا كانت عامة لأشهر" و "لدينا اكتشاف مستمر، واكتشفناه، واحتويناه، وإليك السجل".
الأسئلة المتداولة (للأمان وحوكمة الحوكمة والهندسة)
Q1. ما هو الخطأ الأكثر شيوعًا في MongoDB الذي يؤدي إلى خروقات مثل NCX؟
MongoDB قابل للتوجيه العام بدون مصادقة وبدون ACL للشبكة. في كثير من الأحيان يتم ترقية مثيلات التطوير/الاختبار إلى "prod مؤقت" ولا يتم إغلاقها أبدًا. لقد حذر CISA/NIST لسنوات من أن قواعد البيانات المكشوفة بدون مصادقة هي سبب متكرر للتسريبات واسعة النطاق.(المفوضية الأوروبية)
Q2. إذا تسربت بذرة 2FA / TOTP، هل يمكن للمهاجم تسجيل الدخول باسمي؟
نعم، إذا كان لدى المهاجم أيضًا اسم المستخدم/البريد الإلكتروني الخاص بك وإما كلمة المرور الخاصة بك أو تجزئة مخترقة. باستخدام البذور، يمكنهم إنشاء رموز صالحة مكونة من 6 أرقام إلى ما لا نهاية. هذا هو السبب في أن إرشادات ما بعد الاختراق تقول دائمًا: إعادة تعيين MFA، وليس كلمة المرور فقط.(المراجعة الأمنية اليومية)
Q3. كيف يجب تخزين صور "اعرف عميلك" ومسح الهوية؟
يجب أن تكون مشفرة، ويمكن التحكم في الوصول إليها، ولا يمكن استرجاعها إلا من خلال عناوين URL موقعة قصيرة الأجل مرتبطة بجلسة مصادقة - وليس روابط ثابتة تعيش إلى الأبد. يجب تسجيل كل وصول. تتوقع اللائحة العامة لحماية البيانات أيضًا "تقليل البيانات إلى الحد الأدنى": لا تحتفظ ببيانات شخصية أكثر مما تحتاج إليه.(اللائحة العامة لحماية البيانات العامة)
Q4. ما السرعة التي يتعين علينا قانونًا إخطار الجهات التنظيمية والمستخدمين بها؟
بموجب الأنظمة المماثلة للائحة العامة لحماية البيانات، يجب عليك عمومًا إخطار السلطة المعنية في غضون 72 ساعة من علمك بحدوث خرق يشكل خطرًا على الأفراد، ويجب عليك إبلاغ المستخدمين المتأثرين "دون تأخير لا مبرر له" إذا كان الخطر الذي يتعرضون له كبيرًا(اللائحة العامة لحماية البيانات العامة)
خلاصة القول
"سوء تكوين MongoDB" يبدو وكأنه خطأ مبتدئ. في التشفير، إنه أمر وجودي.
عندما تسرب أكثر من 5 ملايين سجل مستخدم مع معرفات KYC وكلمات المرور المجزأة وسجلات IP والمحافظ وحتى بذور TOTP، فأنت لا تسرب رسائل البريد الإلكتروني فقط - أنت تسرب الهوية والسيولة والثقة.(المراجعة الأمنية اليومية)
من وجهة نظر الفريق الأحمر، هذا مسار شبه تلقائي للاستيلاء على السلطة.
من من وجهة نظر الامتثال، إنها ساعة تنظيمية لا يمكنك إيقافها.(اللائحة العامة لحماية البيانات العامة)
هذا هو السبب في أن الاختبار الهجومي المستمر والآلي والقائم على الأدلة (اكتشاف الأصول ← محاكاة الاستغلال ← محاكاة الاستغلال ← تعيين الامتثال) أصبح إلزاميًا بسرعة لأي منصة تشفير تخزن "اعرف عميلك" وتحتفظ بأموال المستخدمين. وإذا كنت مستخدمًا في بورصة تعرضت لاختراق كهذا؟ قم بتغيير كلمات المرور، وقم بتدوير المصادقة الثنائية (2FA)، وافترض أن التصيد الاحتيالي المستهدف قادم، وفكر بجدية في المغادرة.(CCN.com)

