جعلت Snowflake الإصلاح القابل للتحقق اختبارًا للمسؤولية السحابية المشتركة

ملخص

• ذكرت Mandiant أن كل حادث من حملة Snowflake الذي تعاملت معه مباشرة يعود إلى بيانات اعتماد عملاء مخترقة، ولم تجد أي دليل على أن الوصول غير المصرح به نتج عن خرق لبيئة المؤسسة الخاصة بـ Snowflake. تقرير حملتها على الرابطhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
• لا تزال الحملة تختبر مسؤولية المزود لأن Snowflake كانت تتحكم في أسطح المصادقة، الإعدادات الافتراضية للمنتج، الإرشادات الأمنية، القياس عن بعد للحساب، أدوات سياسات الشبكة، فحوصات Trust Center، والتغييرات ما بعد الحملة التي لا يمكن لأي عميل فردي إنشاؤها بمفرده.
• الإصلاح القابل للتحقق يعني تغييرًا قابلاً للقياس: المصادقة متعددة العوامل الافتراضية للمستخدمين البشريين في الحسابات الجديدة، قواعد كلمات مرور أقوى، تعطيل تلقائي لكلمات المرور المسربة، حزم الأدلة للعملاء، ضوابط أصل الشبكة، ومقاييس الاعتماد التي تظهر تقليل المخاطر عبر القاعدة المثبتة.
• تظل مساءلة العميل كبيرة. يتحكم العملاء في إنشاء المستخدمين، منح الأدوار، تدوير كلمات المرور، تفعيل المصادقة متعددة العوامل في الحسابات الحالية، وصول المقاولين، قوائم السماح بالشبكة، تقليل البيانات، صلاحية التصدير، والجاهزية للتحقيق.

لم تثبت اختراق المنصة؛ ثبت أن الأساس كان متساهلاً

الانضباط الأول هو الحفاظ على حدود الحملة دقيقة. ذكر تقرير Mandiant في يونيو 2024 أن الوصول غير المصرح به في الحوادث التي تعاملت معها جاء من بيانات اعتماد عملاء مخترقة، وأنها لم تجد أي دليل على خرق لبيئة المؤسسة الخاصة بـ Snowflake. إرشادات Snowflake للعملاء، التي عززتها CISA على الرابط source: cisa.gov، وجهت العملاء بالمثل للتحقيق في وصول المستخدم غير المصرح به وتعزيز ضوابط الهوية والشبكة. السجل الذي تمت مراجعته لا يثبت وجود استغلال لمنصة Snowflake، أو هروب عبر المستأجرين، أو سرقة بيانات اعتماد رئيسية للمزود.

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

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

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

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

استخدم مسار الحملة وظائف عادية تحت هوية معادية

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

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

التحكم في الوصول حدد نصف قطر الانفجار بعد تسجيل الدخول. نظرة عامة على التحكم في الوصول لـ Snowflake على الرابط source: docs.snowflake.com تصف الأدوار والصلاحيات والملكية والتسلسل الهرمي. بيانات الاعتماد المسروقة التي لديها وصول ضيق تختلف عن تلك التي لديها صلاحيات قراءة واسعة أو إدارة حساب. حساب الخدمة المبني لخط أنابيب يختلف عن مسؤول متعاقد. الامتياز الأقل ليس شعارًا؛ إنه الفرق بين جلسة معادية تعيد منظرًا واحدًا وجلسة معادية تتجول عبر جداول العملاء الرئيسية.

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

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

توفر MFA أصبح نتائج MFA

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

إعلان Snowflake في سبتمبر 2024 على الرابط source: snowflake.com غير وضع المنتج. قال إن MFA سيتم فرضها افتراضيًا للمستخدمين البشريين في الحسابات المنشأة اعتبارًا من أكتوبر 2024 وأن مستخدمي الخدمة لن يخضعوا لهذا المطلب المحدد. كما أعلن عن متطلبات كلمة مرور أقوى لكلمات مرور المستخدمين المنشأة حديثًا والمعدلة. هذا إصلاح ذو معنى لأنه يغير المسار الافتراضي للحسابات المستقبلية.

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

توثيق سياسة المصادقة لـ Snowflake على الرابط source: docs.snowflake.com يعطي المسؤولين ضوابط على طرق المصادقة والعملاء وموفري الهوية وتسجيل MFA. توثيق مصادقة المفتاح العام على الرابط source: docs.snowflake.com يعطي حسابات الخدمة بديلاً لكلمات المرور الثابتة. هذه الضوابط تضع واجبات على العملاء، لكنها تحدد أيضًا سطح إصلاح المزود: يجب أن يجعل المنتج الأنماط الجيدة أسهل، والاستثناءات السيئة مرئية، والترحيل أقل خطورة.

إرشادات الهوية الرقمية من NIST على الرابط source: pages.nist.gov تساعد في ذكر النتيجة. كلمات المرور ليست مقاومة لإعادة التشغيل. الطرق المقاومة للتصيد أو المقيدة بالتشفير تقلل من قيمة كلمة المرور المسروقة. بالنسبة لعملاء Snowflake، هذا يعني أن المسؤولين البشريين يجب أن ينتقلوا إلى هوية موحدة أو MFA قوية، بينما يجب على مستخدمي الخدمة استخدام بيانات اعتماد عمل محددة النطاق تدور ويمكن تعطيلها دون انتحال شخصية شخص.

حظر كلمات المرور المسربة جعل المسؤولية المشتركة قابلة للقياس

أكثر إصلاح مباشر من المزود بعد حملة بيانات اعتماد مسروقة ليس محاضرة حول إعادة استخدام كلمة المرور. إنه جعل كلمات المرور المسروقة المعروفة تتوقف عن العمل. إعلان Snowflake في ديسمبر 2024 على الرابط source: snowflake.com قال إنها ستعطل تلقائيًا كلمات المرور المكتشفة على الويب المظلم من خلال عملية تحافظ على الخصوصية عند تأكيد تسريبها ولا تزال صالحة. هذا التحكم يعالج الميزة المركزية للحملة: بيانات الاعتماد المسروقة قبل 2024 بوقت طويل ظلت مقبولة من قبل الخدمة.

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

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

تعهد CISA للآمن بالتصميم على الرابط source: cisa.gov يؤطر هذا التمييز. يطلب من المصنعين تجاوز الضوابط الاختيارية نحو نتائج قابلة للقياس مثل MFA الافتراضية ومقاييس التبني. إعلان تعهد Snowflake في يوليو 2024 على الرابط source: snowflake.com وضع الشركة داخل هذا الالتزام العام. التعهد طوعي وليس حكمًا قانونيًا على الحملة. إنه ذو صلة لأنه يحدد نوع الأدلة التي يجب أن يتوقعها العملاء بعد الحدث.

سياسة الشبكة كانت بوابة ثانية

حددت Mandiant قوائم السماح بالشبكة المفقودة كعامل متكرر. توثيق سياسة الشبكة لـ Snowflake على الرابط source: docs.snowflake.com يذكر الإعداد الافتراضي العملي: بدون سياسة، يمكن للمستخدمين الاتصال من أي كمبيوتر أو جهاز. يمكن للعملاء تقييد الوصول من خلال مواقع الشبكة المسموح بها أو المحظورة واستخدام أنماط الاتصال الخاصة لحدود أقوى.

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

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

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

القياس عن بعد هو حدود الأدلة

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

LOGIN_HISTORY على الرابط source: docs.snowflake.com يوفر محاولات تسجيل الدخول مع مصدر IP والعميل والنجاح ومعلومات العامل. QUERY_HISTORY على الرابط source: docs.snowflake.com يوفر نشاط الاستعلام والمستخدم والدور ونص الاستعلام وحجم النتيجة والصفوف المفرغة والبايتات المرسلة عبر الشبكة. ACCESS_HISTORY على الرابط source: docs.snowflake.com يمكن أن يساعد في إعادة بناء وصول الكائنات والأعمدة للإصدارات المؤهلة. توثيق Trust Center على الرابط source: docs.snowflake.com يصف فحوصات الوضع واكتشافات MFA وسياسات الشبكة وعمليات تسجيل الدخول المحفوفة بالمخاطر وعناوين IP غير العادية والتحويلات الكبيرة.

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

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

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

توقف موقع البيانات عند الوصول

اختيار منطقة Snowflake يمكن أن يكون مهمًا للكمون والمرونة والخصوصية والمشتريات. توثيق المناطق المدعومة على الرابط source: docs.snowflake.com يقول إن الحساب مستضاف في منطقة واحدة وأن البيانات تبقى هناك ما لم ينسخها المستخدمون أو ينقلوها أو يكرروها بشكل صريح. كما يذكر الحد الرئيسي: اختيار المنطقة لا يحد من وصول المستخدم إلى Snowflake.

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

إرشادات المشاركة عبر المناطق لـ Snowflake على الرابط source: docs.snowflake.com تحذر العملاء من تأكيد القيود القانونية والتنظيمية قبل نسخ البيانات إلى منطقة أو دولة أخرى. تلك الإرشادات تتعلق بالحركة المعتمدة. التصدير القائم على بيانات الاعتماد مختلف لأنه يمكن أن ينشئ نسخة غير خاضعة للرقابة خارج المنطقة المحددة دون تغيير منطقة الحساب المصدر. جرد البيانات الذي يسجل فقط منطقة المصدر يمكن أن يكون دقيقًا ولا يزال غير مكتمل بعد التصدير.

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

حالات العملاء تظهر العواقب، وليس عددًا رئيسيًا واحدًا

شكل الحملة العام تأثر بإفصاحات الشركات المتأثرة. يجب أن يظل كل سجل ضمن حقائقه الخاصة.

إيداع Live Nation في مايو 2024 على الرابط SEC source قال إن الشركة حددت نشاطًا غير مصرح به في بيئة قاعدة بيانات سحابية تابعة لطرف ثالث تحتوي بشكل أساسي على بيانات Ticketmaster وأن جهة إجرامية عرضت لاحقًا بيانات مستخدم الشركة المزعومة للبيع. الإيداع لم يذكر Snowflake أو يقدم عددًا مؤكدًا من الأشخاص المتأثرين.

صفحة حادثة Ticketmaster Canada على الرابط source: help.ticketmaster.ca وصفت قاعدة بيانات سحابية تابعة لطرف ثالث معزولة، وحقول محتملة لبعض مشتري التذاكر في أمريكا الشمالية، والحدود بأن حسابات عملاء Ticketmaster لم تتأثر. مفوض الخصوصية الكندي حدد لاحقًا Snowflake كمزود لـ Ticketmaster في إحاطة برلمانية على الرابط source: priv.gc.ca، مع الإشارة أيضًا إلى أن التحقيق لا يزال مفتوحًا وأن Ticketmaster Canada لا تزال المتحكم قيد المراجعة.

إيداع AT&T في يوليو 2024 على الرابط SEC source وصف وصولًا غير قانوني إلى مساحة عمل AT&T على منصة سحابية تابعة لطرف ثالث وسرقة سجلات تفاعلات المكالمات والنصوص. الإيداع لم يذكر Snowflake. إنه مفيد لفهم حادثة مساحة عمل سحابية تابعة لطرف ثالث تم الكشف عنها وحدود حقولها، وليس كإسناد مستقل.

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

ملاحظة طباعية لحزم الأدلة

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

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

المساءلة بالتحكم العملي

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

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

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

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

الجهات التنظيمية وشركات التأمين وفرق المشتريات تتحكم في الحوافز. إرشادات سلسلة التوريد من NIST على الرابط source: csrc.nist.gov تدعم تعريف متطلبات الموردين متناسبة مع الأهمية. بالنسبة لمستودع البيانات، يعني ذلك أن العقود والتجديدات يجب أن تطلب مقاييس اعتماد MFA، استجابة كلمة المرور المسربة، حقول حزمة الأدلة، ضمانات الاحتفاظ، توقيت الإخطار، تصعيد الدعم، وضوابط الحركة الإقليمية. استبيان أمني يسأل فقط عما إذا كانت MFA موجودة سطحي جدًا بعد هذه الحملة.

ما الذي سيثبت الإصلاح الدائم

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

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

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

مشكلة القاعدة المثبتة

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

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

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

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

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

أدلة العميل يجب أن تربط السجلات التقنية بالأشخاص

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

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

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

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

الإصلاح لا يمكن أن يعتمد على عار العميل

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

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

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

يجب أن تطالب المشتريات بقياس عن بعد للإصلاح

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

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

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

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

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

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

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

ما لا ينبغي استنتاجه

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

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

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