ملخص

  • تعتبر حادثة LastPass لعام 2022 مهمة لأن البيانات المنسوخة لم تكن مجرد قاعدة بيانات دعم أو قائمة حسابات. وفقًا لتحديثات LastPass الخاصة، تضمنت بيئة التخزين السحابي التي تم الوصول إليها بيانات خزنة العملاء في نسخ احتياطية مشفرة وبيانات وصفية غير مشفرة، مما جعل مسألة التصحيح تعتمد على قوة كلمة المرور الرئيسية وإعدادات التشفير وسلوك العميل ومحاولات الهجوم اللاحقة.
  • المسألة المركزية للمسؤولية هي نقل التكاليف. يمكن لمدير كلمات المرور أن يقول بصدق إنه لا يعرف كلمة المرور الرئيسية للعميل ومع ذلك يترك العملاء مع سنوات من التصحيح: تدوير الأسرار عالية القيمة، مراقبة التصيد، فحص عناوين URL المخزنة، استبدال مفاتيح API، وتحديد ما إذا كانت كل كلمة مرور قديمة في الخزنة المنسوخة يجب اعتبارها مكشوفة محتملاً.
  • الملف العام متعدد الطبقات. تصف تحديثات LastPass تسلسل الحادثة والإجراءات الموصى بها. ثم نشر مكتب مفوض المعلومات في المملكة المتحدة وثائق إنفاذ بشأن LastPass UK Ltd. تصف مواقع التسوية مسارات الدعاوى الجماعية. تشرح إرشادات NIST وCISA وFTC الضوابط التي تهم عندما يحتفظ المنتج بأسرار العملاء الحساسة.
  • الحادثة لا تثبت أن كل خزنة قد تم فك تشفيرها، ولا ينبغي للتحليل المسؤول أن يدعي العكس. إنها تثبت أن سرقة النسخة الاحتياطية المشفرة تغير عبء الإثبات: يحتاج المستخدمون إلى أدلة على إعدادات التشفير، سياسة كلمة المرور الرئيسية، تعرض البيانات الوصفية، وقت الاكتشاف، وما إذا كانت التحسينات اللاحقة للمزود تقلل من نفس نمط الفشل.
  • يجب أن يفصل ملف مسؤولية ذو مصداقية بعد حادثة بيانات خزنة ما يتحكم فيه المزود، وما يتحكم فيه العملاء، وما وجده المنظمون، وما حلت التسويات، وما لا يزال غير معروف. بدون هذا الفصل، قد تصبح عبارة "صفر معرفة" شعارًا يخفي التكلفة العملية التي يتحملها المستخدمون.

لقد غيرت الحادثة معنى "مشفر"

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

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

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

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

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

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

العبء الأول هو الجرد في الخزنة

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

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

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

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

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

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

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