ملخص
- حدود الحملة المؤكدة:أرجع Mandiant حملة مدفوعة ماليًا إلى UNC5537، وقال إن كل حادثة في الحملة تعامل معها مباشرة كانت ناتجة عن بيانات اعتماد عملاء مخترقة. لم يجد أي دليل على أن الوصول غير المصرح به للعملاء نشأ عن اختراق بيئة Snowflake المؤسسية. وقالت Snowflake أيضًا إنها لم تجد أي دليل على ثغرة أو سوء تكوين أو اختراق منصتها تسبب في النشاط.
- سلسلة التحكم المرصودة:الحسابات الناجحة كانت تفتقر إلى المصادقة متعددة العوامل، واحتفظت ببيانات اعتماد مكشوفة في سجلات سارقي المعلومات السابقة، وتفتقر إلى قوائم السماح الشبكية. ثم استخدم المهاجمون عملاء Snowflake المدعومين وعمليات SQL لحصر البيانات ومرحلتها وضغطها وتنزيلها. تم إخطار حوالي 165 مؤسسة بأنها قد تكون مكشوفة؛ هذا ليس عددًا مؤكدًا من الاختراقات أو الأشخاص أو السجلات.
- نتيجة المسؤولية المشتركة:يتحكم العملاء في مستخدميهم وأدوارهم وتناوب كلمات المرور وتسجيل MFA وسياسات الشبكة ونظافة نقاط النهاية وتقليل البيانات. تتحكم Snowflake في الحمايات الموجودة وكيفية تقديمها وجعلها افتراضية، وما هي الإشارات عبر العملاء التي يمكن للمنصة رؤيتها، ومدى سرعة وصول التحذيرات والسلوك الأساسي الأقوى إلى القاعدة المثبتة. هذه المسؤوليات متزامنة، وليست متنافية.
- نتيجة السيادة:اختيار منطقة Snowflake يحدد مكان تخزين الحساب والحوسبة؛ توثيق Snowflake ينص صراحة على أنه لا يحد من وصول المستخدم. في هذه الحملة، يمكن لهوية صالحة تحويل مجموعة بيانات مخزنة إقليميًا إلى نسخة تم تنزيلها. محلية البيانات دون ضوابط الهوية والخروج والأدلة هي قرار توزيع، وليست تحكمًا كاملاً في السيادة.
لم يثبت اختراق المنصة، لكن علاقة الخدمة اختبرت
الانضباط الأول في هذه القضية هو المفردات. مثيل عميل Snowflake لم يكن نفس بيئة Snowflake المؤسسية أو منصة الإنتاج المشتركة. الشخص الذي لديه بيانات اعتماد صالحة يمكنه دخول حساب عميل دون عبور مستأجر آخر، أو استغلال ثغرة برمجية، أو الحصول على حساب مسؤول لدى المزود، أو كسر البنية التحتية التي تفصل العملاء. الأدلة العامة تدعم اختراق حساب العميل. لا تدعم اختراقًا تقنيًا على مستوى المنصة بأكملها.
تقرير Mandiant عن حملة UNC5537مباشر بشكل غير معتاد في هذه النقطة. لكل حادثة مرتبطة بالحملة تعاملت معها Mandiant نفسها، كان السبب الجذري هو بيانات اعتماد عملاء مخترقة. لم يجد تحقيقها أي دليل على أن الوصول غير المصرح به لحسابات العملاء نشأ عن اختراق بيئة Snowflake المؤسسية. إشعار Snowflake الخاصبالتحقيق والتشديدفصل أيضًا حسابات العملاء المستهدفة عن منصة الإنتاج وأعطى العملاء استعلامات ومؤشرات للتحقيق في بيئاتهم الخاصة. عززت CISA هذا التوجيه فيتنبيه 3 يونيو 2024.
تلك النتيجة السلبية مهمة. تسمية الحدث باختراق منصة Snowflake يمكن أن توحي بأن عيبًا في الكود المشترك أو البنية التحتية فتح كل مستأجر، أو أن Snowflake فقدت بيانات اعتماد رئيسية فتحت العملاء. السجل المدروس لا يثبت أيًا من ذلك. كما ستحجب الإجراءات التي يحتاج العملاء لاتخاذها فورًا: تحديد المستخدمين الذين يعتمدون فقط على كلمة المرور، تناوب بيانات الاعتماد، فحص سجل تسجيل الدخول والاستعلام، تقييد الشبكات، تقليل صلاحيات الدور، والحفاظ على الأدلة.
الخطأ المعاكس هو اعتبار غياب اختراق المنصة كغياب سؤال مساءلة المزود. الخدمة السحابية ليست مجرد قرص محايد يضع عليه العميل بتاتك. Snowflake بنت وشغّلت نقاط نهاية المصادقة التي قبلت بيانات الاعتماد، والواجهات التي استخدمها المهاجمون، ومحرك الاستعلام الذي عالج أوامرهم، والقياس عن بُعد الذي سجل الجلسات، وضوابط المنتج التي كان يمكن أن تتطلب عاملًا ثانيًا أو تقيد أصل الشبكة. Snowflake كانت لديها أيضًا رؤية عبر العملاء لا يمتلكها أي عميل فردي. حقيقة أن تحكمًا حاسمًا كان قابلًا للتكوين من قبل العميل تحدد من كان لديه واجب تشغيلي لتكوينه.
لا تجيب عما إذا كانت الإعدادات الافتراضية للمزود، والتحذيرات، والكشف، والإنفاذ كانت متناسبة مع تركيز البيانات على خدمته.
السؤال المفيد هو بالتالي أضيق من "من اخترق؟" وأوسع من "من سُرقت كلمة مروره؟" إنه: في كل خطوة من السرقة السرية إلى البيانات المحملة، أي ممثل يمكنه منع أو كشف أو إيقاف أو إعادة بناء أو التحذير من الإجراء؟ المساءلة تتبع التحكم في تلك الخطوات.
الحملة جمعت سرقة أجهزة طرفية قديمة مع سلطة سحابية حالية
حصلت Mandiant أولاً على معلومات استخباراتية في أبريل 2024 بخصوص سجلات قاعدة بيانات تم تتبعها لاحقًا إلى مثيل Snowflake لضحية. ذلك الضحية استعان بـ Mandiant، التي خلصت إلى أن المتسلل استخدم بيانات اعتماد سُرقت سابقًا بواسطة برمجيات سرقة المعلومات. الحساب المعني لم يكن لديه MFA مفعل. في 22 مايو، بعد تحديد معلومات استخباراتية تشير إلى حملة أوسع، اتصلت Mandiant بـ Snowflake وبدأت إخطار الضحايا المحتملين. نشرت Snowflake توجيهات الكشف والتشديد للعملاء في 30 مايو. بحلول تقرير يونيو، كانت Mandiant وSnowflake قد أخطروا حوالي 165 مؤسسة قد تكون مكشوفة.
كل مصطلح في تلك الجملة الأخيرة يحتاج إلى حماية من التضخيم. "تقريبًا" يشير إلى تقدير. "قد تكون مكشوفة" تصف مجموعة إخطار، وليس 165 نتيجة تحقيقية. "مؤسسات" لا تعني حسابات أو قواعد بيانات أو أشخاص أو سجلات. بعض المؤسسات قد تدير حسابات Snowflake متعددة، وحساب واحد قد يحمل بيانات عن عدد أكبر بكثير من السكان. التقرير لا يعطي إجماليًا على مستوى الحملة للمؤسسات المؤكدة، أو الأفراد المتأثرين، أو البايتات المُصدّرة، أو مدفوعات الابتزاز.
تاريخ بيانات الاعتماد يشرح كيف يمكن لتسجيل دخول سحابي في 2024 أن يبدأ بعدوى جهاز طرفية قبل سنوات. وجدت Mandiant أن معظم بيانات الاعتماد التي استخدمها UNC5537 كانت موجودة في مخرجات سارقي المعلومات السابقة، مع أول عدوى مرتبطة لوحظت في نوفمبر 2020. على الأقل 79.7 في المئة من الحسابات التي استخدمها الفاعل كان لديها تعرض سابق لبيانات الاعتماد. هذه النسبة تنطبق على الحسابات المستخدمة من قبل الفاعل في الحملة المحللة، وليس على جميع عملاء Snowflake أو جميع المؤسسات المخطرة البالغ عددها 165.
ثلاثة شروط حولت باستمرار بيانات الاعتماد المكشوفة إلى وصول فعّال. الحسابات المتأثرة لم تكن مهيأة بـ MFA. كلمات المرور الموجودة في سجلات سارقي المعلومات بقيت صالحة، أحيانًا لسنوات. مثيلات العملاء المتأثرة تفتقر إلى قوائم السماح الشبكية التي تقيد الاتصالات إلى مصادر موثوقة. لا شيء من هذه الشروط هو استغلال جديد. معًا شكلت مسار ترخيص دائم: معرفة محدد الحساب واسم المستخدم وكلمة المرور الصالحة؛ الاتصال من نظام يتحكم به المهاجم؛ تلقي جلسة؛ وراثة الدور المعين؛ الاستعلام عن أي شيء قد يقرأه ذلك الدور.
البعد الطرفي كان أيضًا أكثر توزيعًا مما توحي به سردية الكمبيوتر المحمول التقليدي للموظف. في عدة تحقيقات، وجدت Mandiant عدوى سارق المعلومات السابقة على أنظمة مقاولين استخدمت أيضًا للأنشطة الشخصية، بما في ذلك الألعاب أو التنزيلات المقرصنة. جهاز المقاول يمكن أن يكون خارج أسطول نقاط النهاية المدارة للعميل بينما يحمل بيانات اعتماد لعدة عملاء. يمكن أن يحمل أيضًا حسابًا إداريًا لأن المقاولين المتخصصين غالبًا ما يتم توظيفهم لبناء أو تشغيل منصات البيانات. العميل الذي أنشأ المستخدم يظل مسؤولاً عن الهوية وصلاحياتها، لكن التعرض قد يكون غير مرئي لأدوات نقاط النهاية الخاصة بالعميل.
هذا مضاعف تبعية سحابية. بيانات الاعتماد تُسرق من نقطة نهاية واحدة، ربما خارج أسطول Snowflake أو مالك البيانات. يتم قبول بيانات الاعتماد بواسطة خدمة عالمية. الدور قد يصل إلى مستودع موحد يحتوي على سنوات من السجلات من عدة أنظمة أعمال. المهاجم لم يعد بحاجة لاختراق تلك الأنظمة المصدر واحدًا تلو الآخر. القيمة التحليلية التي جعلت المستودع مفيدًا للعميل جعلت أيضًا الوصول الناجح قيمًا لفاعل ابتزاز.
المهاجمون يتحملون المسؤولية المباشرة عن سرقة وشراء واختبار واستخدام بيانات الاعتماد؛ دخول بيئات العملاء دون إذن؛ أخذ البيانات؛ ومحاولة البيع أو الابتزاز. وصف إخفاقات التحكم التي جعلت هذه الجرائم ممكنة لا يخفف من تلك المسؤولية. إنه يشرح لماذا نجحت نفس التقنية الإجرامية على نطاق واسع وأين يمكن تقليل التكرار.
الميزات المدعومة أصبحت مسارًا لسرقة البيانات
الحملة لم تتوقف عند المصادقة. لاحظت Mandiant الوصول عبر Snowsight وSnowSQL وبرامج التشغيل وأدوات قواعد البيانات. قام الفاعل بإدراج المستخدمين والأدوار والجلسات وأسماء المؤسسات وقواعد البيانات والمخططات والجداول. استخدم عمليات SQL مألوفة لاختيار البيانات، وإنشاء مراحل مؤقتة، ونسخ مخرجات الاستعلام إلى ملفات مضغوطة، واسترداد تلك الملفات إلى جهاز محلي. في عدة حالات، ظهرت أوامر مماثلة عبر بيئات عملاء مختلفة.
هذا التسلسل يجعل الحادث مفهومًا كوظائف عادية تُستخدم بهوية غير مصرح بها:
- اسم مستخدم وكلمة مرور صالحان للعميل أسسا جلسة.
- الجلسة ورثت الأدوار وصلاحيات الكائنات المعينة من قبل العميل.
- الاستطلاع حدد الجداول القيمة والمراحل المتاحة.
- الاستعلامات حددت السجلات التي كان الدور مسموحًا له بقراءتها.
- المراحل المؤقتة و
COPY INTOحولت النتائج إلى ملفات قابلة للتنزيل. GETنقل الملفات إلى عميل يتحكم به المهاجم.
لا خطوة في تلك السلسلة تطلبت عطلًا في قاعدة البيانات. لهذا السبب، التشفير في حالة السكون، رغم ضرورته، لم يكن التحكم الحاسم. توثيق التشفير الشامل لـ Snowflakeيقول إن بيانات العميل مشفرة في حالة السكون وتحت TLS أثناء النقل، لكنه يشرح أيضًا أن Snowflake تفك تشفير البيانات أثناء إجراء التحويلات أو عمليات الجدول وتسمح للمستخدمين بتفريغ وتنزيل النتائج. التشفير يحمي الملفات والنقل من الأطراف التي تفتقر إلى التفويض أو المفاتيح. لا يمنع هوية مقبولة بدور مسموح من طلب الخدمة لإرجاع نتائج قابلة للقراءة.
نفس المبدأ ينطبق على المفاتيح المدارة من قبل العميل. تحكم المفتاح يمكن أن يعالج سيناريوهات المزود والتخزين والإبطال، لكن الحساب الجاري يجب أن يستخدم هيكل مفاتيحه لخدمة الاستعلامات المصرح بها. ما لم تكن سياسة المفتاح مرتبطة بقرار منفصل يرفض الجلسة أو العملية، لا يمكن لقاعدة البيانات تمييز مالك الحساب من متسلل استوفى سياسة المصادقة المهيأة من قبل المالك.
تصميم الدور بالتالي تحكم في نصف القطر بعد تسجيل الدخول. نموذج التحكم في الوصول الحالي لـ Snowflakeيدعم ضوابط الوصول القائمة على الأدوار والوصول التقديري، والملكية، والتسلسل الهرمي للأدوار، وصلاحيات الكائنات. بيانات اعتماد مخصصة فقط لقاعدة بيانات ضيقة أو عرض تقدم عواقب مختلفة عن تلك التي تحملACCOUNTADMIN، أو استخدام واسع للمستودع، أو وصول انتقائي عبر مجموعات البيانات الخام. حساب خدمة يستخدم لتكامل لا يجب أن يرث المدى الاستكشافي لمسؤول بشري. دور المقاول المؤقت يجب أن ينتهي مع التعاقد بدلاً من البقاء خاملاً بكلمة مرور صالحة.
سياسات حماية البيانات يمكن أن تضيق النتيجة حتى عند اختراق الدور. توثيق تصنيف البيانات الحساسة لـ Snowflakeيربط اكتشاف الأعمدة الشخصية والحساسة مع سياسات الإخفاء والوصول إلى الصفوف. هذا وصف للقدرة الحالية، وليس دليلاً على أن كل عميل متأثر قد صنف أو أخفى بياناته في 2024. إنه يطرح سؤال التصميم: هل عرض العميل جداول تاريخية كاملة لهويات كانت تحتاج فقط إلى مجاميع، أو أقسام حديثة، أو حقول موسمة، أو عروض معتمدة؟
التصدير هو في حد ذاته وظيفة أعمال مميزة ويجب حوكمته على هذا الأساس. مستودع البيانات غالبًا ما يحتاج إلى تفريغ ضخم لخطوط الأنابيب المشروعة، والنسخ الاحتياطية، وتدريب النماذج، والأنظمة النهائية. الحظر الشامل نادرًا ما يكون واقعيًا. لكن إنشاء مرحلة، تفريغ نتيجة كبيرة بشكل غير عادي، أو استخدام عميل وأصل شبكة غير مألوف يجب أن يكون قابلاً للرصد، وبالنسبة لمجموعات البيانات عالية المخاطر، قد يبرر الموافقة، أو حدود المعدل، أو قيود الوجهة، أو رفع سريع الصلاحية، أو دور تصدير منفصل. أوامر الحملة كانت عادية بما يكفي للتنفيذ، لكنها غير عادية بما يكفي في السياق لتستحق قرارًا أمنيًا سريعًا.
العميل يمتلك الإعداد؛ Snowflake تملك الأساس
MFA هي اختبار المسؤولية المشتركة الأكثر حدة لأن كلا الجانبين يمكن أن يذكر حقيقة صحيحة. مسؤول العميل كان قادرًا ومتوقعًا منه تمكينها. Snowflake قدمت MFA منذ 2015 وسياسات الشبكة منذ 2016. في الوقت نفسه، الحسابات الناجحة في 2024 كانت قادرة على المصادقة دون MFA، مما يعني أن الأساس الفعّال للخدمة سمح بمسار يعتمد فقط على كلمة المرور لتلك الحسابات.
الفرق بين التوفر والإنفاذ ليس دلاليًا. ميزة أمنية يمكن أن تكون مجانية وموثقة وموصى بها ومع ذلك غائبة عن الجلسات المهمة. المسؤولون يواجهون تكاملات قديمة، ومستخدمي خدمة غير تفاعليين، ومقاولين، وحسابات طوارئ، وعملاء متعددين، وخوف من الإغلاق. هذه القيود تشرح احتكاك التبني؛ لا تبرر ترك الوصول البشري المميز يعتمد على كلمة مرور قابلة لإعادة الاستخدام. كما تعطي المزود معلومات مطلوبة لبناء أدوات الترحيل، وفصل الهويات البشرية وهويات الخدمة، وجعل الاستثناءات واضحة.
بعد الحملة، تحرك Snowflake العلني من التوصية نحو إعدادات افتراضية أقوى. إعلان تعهد التصميم الآمن بطبيعته في يوليو 2024أكد على ضوابط سياسة MFA وفحوصات Trust Center. في سبتمبر 2024، قالت Snowflakeسيتم إنفاذ MFA افتراضيًاللمستخدمين البشريين في الحسابات التي تم إنشاؤها من أكتوبر 2024، مع التوصية بـ SSO مع MFA موفر الهوية للبشر ومصادقة OAuth أو مفتاح زوجي للخدمات. الفرق بين الحسابات الجديدة والحالية مهم. الإعداد الافتراضي الآمن يحمي الإنشاء المستقبلي؛ لا يلغي تلقائيًا كل مسار كلمة مرور موروث في القاعدة المثبتة.
لاحقًا، قدمت Snowflakeحماية كلمات المرور المسربة، التي تستخدم خلاصات معلومات استخباراتية لاختبار كلمات المرور المبلغ عنها كمسربة في عملية تحافظ على الخصوصية وتعطيل كلمة المرور عندما يتم تأكيد أنها لا تزال صالحة. هذا التحكم من جانب المزود يعالج مباشرة إحدى مزايا UNC5537: بيانات اعتماد سارقي المعلومات القديمة التي بقيت قابلة للاستخدام. كما أنه دليل على أن المسؤولية المشتركة يمكن أن تتطور. لا يزال لدى العملاء إدارة الهويات والتناوب، لكن المزود يمكنه استخدام الاستخبارات عبر الخدمات لجعل كلمة المرور المسروقة تتوقف عن العمل قبل أن يجدها كل عميل بشكل مستقل.
توثيق سياسة المصادقة الحالييسمح للمسؤولين بالتحكم في الطرق والعملاء المسموح بها ويتطلب MFA على مستوى الحساب أو المستخدم. كما يحذر من أن قيود نوع العميل هي بأفضل جهد ويجب ألا تكون الحدود الأمنية الوحيدة. توجيه المفتاح الزوجي الحالييعطي مستخدمي الخدمة بديلاً لكلمات المرور الثابتة. هذه الصفحات تصف القدرات المتاحة بحلول 2026؛ يجب ألا تُقرأ بأثر رجعي كدليل على الميزات الدقيقة أو الإعدادات الافتراضية أو حالة الإنفاذ لكل عميل في أبريل 2024.
المعايير تساعد في شرح سبب انتماء الإعدادات الافتراضية للمزود داخل التحليل. إرشادات NIST الحالية للمصادقة وإدارة المصادقتتعامل مع كلمات المرور كغير مقاومة لإعادة التشغيل وتحدد مقاومة التصيد كخاصية بروتوكول لا تعتمد على يقظة المستخدم. تعهد CISA لعام 2024 بالتصميم الآمن بطبيعتهيحدد تحديدًا MFA الافتراضي والإشارات المستمرة للمنتج ودعم SSO الأساسي ونشر مقاييس التبني كطرق يمكن بها لمصنعي البرامج زيادة استخدام MFA بشكل قابل للقياس. وقعت Snowflake هذا التعهد الطوعي بعد الحملة. التعهد ليس حكمًا قانونيًا على تصميم Snowflake لعام 2024، لكنه يرفض فكرة أن تقديم مربع اختيار يستنفد دور المزود.
الأساس المسؤول يميز أنواع الهوية. يجب على المسؤولين البشريين استخدام MFA مقاوم للتصيد أو هوية موحدة محكومة بقوة. يجب أن تستخدم أعباء العمل بيانات اعتماد عمل يمكن نطاقها وتدويرها وإسنادها دون التظاهر بأن روبوتًا يمكنه الرد على إشعار دفع. يجب أن يكون وصول الطوارئ نادرًا ومراقبًا ومحدود الوقت ومختبرًا. يجب أن تكون هويات المقاولين ذات مالك وانتهاء صلاحية ووضع جهاز معتمد وعدم إعادة استخدام بيانات الاعتماد عبر العملاء. كل استثناء يجب أن يظهر في لوحة معلومات مقامها هو جميع الهويات، وليس فقط الموظفين النشطين.
سياسة الشبكة كانت بوابة ثانية، وليس بديلاً عن الهوية
العامل الثالث المتكرر لـ Mandiant كان غياب قوائم السماح الشبكية. لذلك يمكن استخدام بيانات اعتماد صالحة من بنية تحتية ليس لديها سبب تجاري للوصول إلى مستودع العميل. القيود الشبكية لن تصلح كلمة مرور مسروقة، لكنها يمكن أن تجعل تلك الكلمة مرور غير كافية من مصدر غير موثوق.
توثيق سياسة الشبكة الحالي لـ Snowflakeيجعل الإعداد الافتراضي صريحًا: بدون سياسة، يمكن للمستخدمين الاتصال من أي كمبيوتر أو جهاز. يمكن للعملاء السماح أو حظر نطاقات IP ونقاط النهاية الخاصة، وتطبيق الضوابط على مستوى الحساب أو المستخدم، وتقييد الوصول إلى المراحل الداخلية بتكوين إضافي. يمكن للاتصال الخاص وضوابط الوصول العام أن تزيد من صلابة الحسابات عالية الحساسية.
العميل يعرف مكاتبه المعتمدة وأعباء العمل السحابية والشبكات الخاصة الافتراضية والمقاولين ونقاط نهاية التكامل، لذا يجب على العميل تحديد قائمة السماح القابلة للاستخدام. Snowflake لا يمكنها استنتاج كل مصدر شرعي دون تعطيل الأعمال. لكن المزود يتحكم في الوصول الافتراضي، وصيغة السياسة، والقدرة على محاكاة التغيير، وحماية الإغلاق، والتسجيل، وما إذا كان المسؤول محذرًا عندما لا توجد سياسة حساب. المنصة يمكنها الحفاظ على اختيار العميل مع جعل الوصول العام غير المقيد استثناءً مرئيًا ومحدود الوقت بدلاً من حالة مستقرة صامتة.
للقواعد الشبكية أيضًا حدود. المهاجمون قد يحصلون على جلسة من جهاز مقاول معتمد، أو يمرون عبر VPN مؤسسي مسموح، أو يخترقون عبء عمل داخل السحابة المسموح بها، أو يسرقون رمزًا بعد المصادقة. المؤسسات الكبيرة قد يكون لها عناوين صادرة متغيرة تجعل القوائم الثابتة صعبة. الاتصال الخاص يمكن أن يستبعد أدوات SaaS التي لا تدعمه. هذه أسباب لربط الضوابط الشبكية بهوية قوية وكشف سلوكي، وليس أسبابًا لحذفها.
الحملة تظهر قيمة البوابات المستقلة. تناوب كلمة المرور كان سيبطل بيانات الاعتماد التاريخية. MFA كانت ستتطلب عاملاً آخر. سياسة الشبكة كانت سترفض المصادر غير المألوفة. أقل صلاحية كانت ستقلل البيانات المرئية. ضوابط التصدير كانت يمكن أن تقطع الكشف. التوقيت القصير للكشف كان يمكن أن يقلل وقت المكوث. لا إجراء واحد مثالي؛ المهاجم نجح حيث كانت عدة إجراءات غائبة أو متسامحة في نفس الوقت.
من أجل المساءلة، كل بوابة تحتاج إلى مالك ومقياس فعالية. "سياسة الشبكة مدعومة" هي حقيقة منتج. "كل حساب إنتاج لديه سياسة مختبرة تغطي الخدمة والمراحل الداخلية" هو نتيجة تشغيلية. "MFA متوفرة" هي حقيقة منتج. "لا يمكن لأي بشري مميز إنشاء جلسة بكلمة مرور قابلة لإعادة الاستخدام وحدها" هو نتيجة. المسؤولية المشتركة تصبح ذات معنى فقط عندما يظهر كلا الطرفين النتائج عند حدودهما.
المزود رأى حملة يمكن لكل عميل رؤيتها فقط كحادثة
العميل الفردي يستطيع فحص عمليات تسجيل الدخول الفاشلة والناجحة، والعملاء، وعناوين IP، ونص الاستعلام، والأدوار، والمراحل، ونقل البيانات. Snowflake يمكنها ربط الأنماط عبر الحسابات: نفس البنية التحتية، العملاء غير المعتادين، استطلاع متكرر، أوامر مرحلية مماثلة، زيادة في تسجيلات الدخول بكلمة مرور فقط، أو بيانات اعتماد مطابقة لخلاصات معلومات استخباراتية. هذا عدم التماثل هو أهم مسؤولية غير تعاقدية للمزود. تنشأ من تشغيل الخدمة على نطاق.
عرض LOGIN_HISTORY الحالي لـ Snowflakeيحتفظ بسنة من محاولات تسجيل الدخول ويتضمن المستخدم، عنوان IP المصدر، العميل المبلغ عنه، العاملين الأول والثاني، النجاح، وتفاصيل المخاطر ذات الصلة، مع زمن انتقال موثق. QUERY_HISTORYيحتفظ بسنة من نشاط الاستعلام ويربط الاستعلام بحدث المصادقة، الجلسة، المستخدم، الدور، النص، بايتات النتيجة، الصفوف المفرغة، والبايتات المرسلة عبر الشبكة. عملاء المؤسسات يمكنهم استخدام ACCESS_HISTORYلإعادة بناء الجداول والعروض والأعمدة والمراحل والسياسات والكائنات المعدلة التي تم الوصول إليها. تلك المخططات توفر المادة الخام لتحقيق عالي الجودة.
التاريخ الخام ليس نفس الكشف. يجب على العميل منح المحللين الوصول، أو تصدير البيانات أو الاستعلام عنها، وفهم السلوك الطبيعي، وكتابة التنبيهات، وتوجيهها، والاحتفاظ بها خارج النوافذ الأصلية إذا لزم الأمر، وتوفير فريق استجابة. زمن انتقال القياس عن بُعد البالغ ساعتين قد يكون مقبولاً للمراجعة بأثر رجعي لكنه بطيء جدًا لبعض قرارات التصدير الضخم. حدود إصدار المؤسسات على تاريخ الوصول على مستوى العمود يمكن أن تؤثر أيضًا على مدى دقة العميل في نطاق التعرض. يجب اختبار هذه الحقائق التشغيلية والمنتجات أثناء الشراء، وليس اكتشافها بعد سرقة.
نظام التحذير يجب أن يعمل على مستويين. على مستوى المستأجر، يحتاج العملاء إلى أحداث فورية قابلة للتصدير وضوابط لحظر النشاط أو تعليقه. على مستوى المزود، تحتاج Snowflake إلى تحليلات حملة وعملية ممارسة لإخطار العملاء بالأدلة الكافية للعمل. الإخطار المفيد يتضمن معرّفات الحساب والمستخدم، وأختام زمنية بالتوقيت العالمي المنسق، والبنية التحتية المصدر، وعامل المصادقة، ومعرفات الجلسة والاستعلام، والأوامر، والكائنات والأعمدة التي تم لمسها، وإجراءات المرحلة، وحجم النقل المقدر، وحالة الاحتواء، والثقة. "قد تكون مكشوفة" هي تسمية افتتاحية مناسبة فقط إذا تبعتها الأدلة اللازمة لحل الاحتمال.
التدخل من قبل المزود يحتاج أيضًا إلى حوكمة. حظر جلسة عميل تلقائيًا يمكن أن يقطع الإنتاج وقد يتجاوز السلطة التعاقدية للمزود. عدم التصرف يمكن أن يسمح بسرقة مستمرة. لذلك يجب أن يحدد التصميم عتبات المخاطر، والتعليقات المؤقتة، وقنوات تصعيد العملاء، وجهات اتصال الطوارئ، وعملية تجاوز سريعة مسبقًا. يجب على العملاء تسمية أشخاص يمكنهم تلقي تنبيه عالي الخطورة في أي ساعة وتفويض التعليق. يجب على المزود قياس الوقت من إشارة عبر الحسابات إلى اتصال العميل، والوقت للاحتواء، ونسبة العملاء المخطَرين الذين يمكنهم استرداد حزمة أدلة كاملة.
محلية البيانات لم تجعل الوصول محليًا
تسوق Snowflake وتوثق النشر الإقليمي لأن العملاء لديهم متطلبات زمن الانتقال والمرونة والخصوصية والتنظيم والسيادة. توثيق المناطق المدعومة لـ Snowflakeيقول إن كل حساب مستضاف في منطقة واحدة وأن البيانات تبقى في تلك المنطقة ما لم ينسخها المستخدم صراحةً أو ينقلها أو يكررها. نفس الصفحة تحتوي على الحد الحاسم: المناطق تحدد مكان تخزين البيانات وتوفير الحوسبة؛ لا تحد من وصول المستخدم إلى Snowflake.
هذا التمييز يحول سلسلة UNC5537 إلى قضية سيادة. قبل الاختراق، جداول العميل قد تكون مخزنة ومعالجة في موقع سحابي إقليمي محدد بعد اختيار الدولة. بعد المصادقة الناجحة، المهاجم يمكنه استعلام الحساب الإقليمي من مكان آخر، ومرحلة النتائج، وتنزيلها إلى عميل. لاحظت Mandiant النمط التقني للاسترجاع المحلي من المراحل المؤقتة. السجل العام للحملة لا يحدد بلد المصدر أو بلد الوجهة أو حالة النقل القانونية لكل ضحية، لذا لا يمكن دعم أي ادعاء عالمي بنقل غير قانوني عبر الحدود. الهندسة المعمارية تظهر مع ذلك أن محلية التخزين وحدها لا يمكنها إنفاذ محلية المستخدم.
المشاركة عبر المناطق والتكرار يخلقان مسار نقل مشروع منفصل. توجيه مشاركة Snowflake عبر المناطقيخبر المؤسسات بتأكيد القيود القانونية والتنظيمية قبل تكرار البيانات إلى منطقة أو دولة مختلفة. هذا نقل مخطط تحت إدارة العميل. التصدير القائم على بيانات الاعتماد مختلف: يمكن أن يخلق نسخة غير خاضعة للسيطرة خارج البيئة المختارة دون تغيير موقع الحساب المصدر. الجرد الذي يسجل فقط المنطقة المصدر سيستمر في قول "الاتحاد الأوروبي" أو "كندا" حتى بعد أن يزيل المهاجم نسخة.
سيادة البيانات بالتالي لها أربع طبقات على الأقل:
- التوزيع:أين يتم توفير موارد التخزين والحوسبة الرسمية.
- الوصول:أي الهويات البشرية والآلية يمكنها الاتصال، ومن أي أجهزة وشبكات وولايات قضائية.
- الحركة:أي الاستعلامات والتفريغات والمشاركات والتكرارات والموصلات والتنزيلات قد تنشئ نسخة أخرى.
- الأدلة والعلاج:ما إذا كانت المنظمة تستطيع إثبات مصدر الوصول، وما غادر، وأي الأشخاص أو السجلات المنظمة كانت متورطة، ومدى سرعة احتوائها وإخطارها.
المزود يتحكم في أجزاء مهمة من جميع الطبقات الأربع حتى عندما يختار العميل السياسة. يقدم المناطق ويحتفظ ببيانات الحساب فيها. يصادق الطلبات ويكشف ضوابط الشبكة. ينفذ أوامر التصدير ويسجل بيانات الاستعلام. لديه رؤية تهديد عبر العملاء ويمكنه تعطيل كلمات المرور المسربة. العميل يقرر أساسه القانوني، وفئات البيانات، والأدوار، والمصادر المسموح بها، والإخفاء، والاحتفاظ، والحركة المعتمدة. التزام الاستضافة الإقليمية دون هذه الضوابط التكميلية يمكن أن يلبي متطلبات موقع مركز بيانات ضيق مع ترك السلطة العملية لنسخ البيانات عالميًا مكشوفة.
لهذا السبب أيضًا يجب عدم الخلط بين التشفير والسيادة. التشفير يمكن أن يحمي كائنًا مخزنًا من مشغل البنية التحتية أو قارئ غير مصرح به على طبقة التخزين. التطبيق الذي يجب أن يحلل الكائن يجعل البيانات متاحة بالضرورة لسياق استعلام مصرح به. إذا كانت الثقة في الهوية ونطاق الدور ضعيفين، يمكن للتعايش المشفر أن يتعايش مع سرقة تشغيلية.
إفصاحات العملاء تظهر عواقب مختلفة، وليس اختراقًا واحدًا موحدًا
غالبًا ما توصف الحملة بأسماء عملاء بارزين، لكن لكل عميل سجله العام نطاقه وتواريخه وبياناته ومصطلحاته وثقته. من غير الآمن نقل حقائق شركة إلى أخرى أو تحويل ادعاء منتدى إجرامي إلى عدد سكاني موثوق.
صحيفة قضايا برلمانية لمكتب مفوض الخصوصية الكندي في أكتوبر 2025تحدد Snowflake كمزود الطرف الثالث الذي تستخدمه Ticketmaster، وتعطي نافذة حادث من 2 أبريل إلى 18 مايو 2024 لـ Ticketmaster Canada، وتقول إن المعلومات الشخصية للملايين، بما في ذلك الكنديين، كانت متورطة. كما تقول إن التحقيق ظل مفتوحًا وأن Ticketmaster Canada، كمراقب البيانات بموجب PIPEDA، كانت الكيان قيد التحقيق. هذا سياق تنظيمي مفيد، لكنه ليس نتيجة نهائية تحل كفاية الضمانات أو توقيت الإخطار أو المسؤولية.
هذه السجلات تعطي أربع قواعد انضباط. أولاً، استخدم إيداع عميل لذلك العميل فقط. ثانيًا، ميز بين قاعدة البيانات والحساب التنظيمي وتسجيل دخول المستهلك. ثالثًا، ميز بين حقول البيانات وعدد الأشخاص الممثلين بها. رابعًا، حافظ على الحقائق السلبية مثل "بدون محتوى رسالة" أو "حساب المستهلك لم يتأثر" جنبًا إلى جنب مع التأثير. تصبح المساءلة أقل مصداقية عندما يوسع التحليل الادعاءات المثيرة ويسقط القيود.
العميل ظل مسؤولاً عن البيانات والهويات التي فوضها
جانب العميل من المسؤولية المشتركة كبير. المنظمة أنشأت أو وافقت على مستخدمي Snowflake، واختارت مسارات المصادقة، وعينت الأدوار، وحملت البيانات، واحتفظت بالسجل، واختارت منطقة، وفعلت التكاملات، وقررت أي الموظفين والمقاولين يمكنهم الاستعلام عن المستودع. كما كانت لديها العلاقة الأساسية مع الأشخاص الممثلين في بياناتها وعادة ما تحتفظ بواجبات المراقب بموجب قانون الخصوصية المطبق.
كان بإمكان العميل مقاطعة الحملة المرصودة في عدة نقاط. كان بإمكانه تناوب كلمات المرور بعد التعرض الطرفي، وحظر حسابات الخدمة بكلمة مرور فقط، وطلب MFA للبشر، وتوحيد الوصول من خلال موفر هوية محكوم، وتقييد الشبكات، وإنهاء مستخدمي المقاولين، وتقليل منح الأدوار، وتصنيف وإخفاء الحقول الحساسة، وعزل صلاحية التصدير، ومراقبة سجل تسجيل الدخول والاستعلام، والتمرن على إخطارات المزود السحابي. بالنسبة لمجموعات البيانات المنظمة أو عالية التأثير، تلك واجبات تشغيلية أساسية، وليست تحسينات اختيارية مفوضة للمشتريات.
حوكمة نقاط النهاية والمقاولين تستحق اهتمامًا خاصًا. يجب ألا يصادق مستخدم بدور سحابي عالي التأثير من جهاز كمبيوتر شخصي غير مدار. يجب على المقاولين استخدام أجهزة افتراضية أو أجهزة يتحكم فيها العميل مع مراقبة نقاط النهاية حيثما أمكن. هويتهم يجب أن تكون فريدة لكل عميل، مرتبطة براعي، وتنتهي تلقائيًا. يجب على المنظمة البحث في خلاصات تعرض بيانات الاعتماد عن أنماط حسابات Snowflake الخاصة بها وفرض التناوب عند ظهور دليل، دون انتظار تأكيد سوء الاستخدام.
يجب اختبار أقل صلاحية مقابل البيانات، وليس المسمى الوظيفي. "محلل" قد يبدو غير إداري بينما يحتفظ بوصول انتقائي إلى كل صف في جدول عملاء أو موظفين أو معاملات. مراجعة الدور يجب أن تسأل عن أي الصفوف والأعمدة يمكن إرجاعها، وما إذا كانت المعرفات الخام مطلوبة، وما إذا كانت مجموعات النتائج الضخمة يمكن كتابتها إلى مراحل، وما إذا كانت الهوية قد تنشئ بيانات اعتماد أو تكاملات جديدة. الاستعلامات النموذجية تحت الدور هي دليل أقوى من اسم دور يبدو نظيفًا.
العملاء أيضًا يمتلكون جاهزية الاستجابة. يجب أن يكونوا قادرين على ربط مستخدم Snowflake بموظف أو مقاول، واستعلام بموضوعات البيانات المتأثرة، وتصدير باختصاص وتحليل إخطار. التواريخ المحلية لسنة واحدة قد تكون غير كافية للاحتفاظ القانوني الأطول أو الاكتشاف المتأخر، لذا يجب على العملاء عالي المخاطر دفق الأحداث ذات الصلة إلى متجر أمني مستقل. تنبيهات المزود تحتاج إلى مسار مختبر لفريق أمان العميل ومكتب الخصوصية ومالك الأعمال وصانع القرار التنفيذي.
Snowflake ظلت مسؤولة عن تقليل المخاطر على مستوى الخدمة
Snowflake لم تتحكم في البرامج الضارة على جهاز المقاول الشخصي أو قرار العميل بترك MFA معطلاً. لكنها تحكمت في ما إذا كانت كلمة المرور القديمة يمكن أن تبقى العامل الوحيد، وما إذا كانت المصادر غير المقيدة هي الإعداد الافتراضي الصامت، وما إذا كانت التكوينات الخطرة تنتج تحذيرات مستمرة، وما فعله المزود بعد أن لاحظ نمطًا عبر العملاء.
مساءلة المزود في هذه القضية لها ستة أجزاء.
الأساس الآمن.الوصول البشري المميز يجب ألا يعتمد على كلمة مرور قابلة لإعادة الاستخدام وحدها. هويات الخدمة يجب أن يكون لها نوع منفصل وطرق غير كلمة مرور مدعومة. الإعدادات الافتراضية الجديدة يجب أن تصل إلى الحسابات الحالية عالية المخاطر من خلال إنفاذ مرحلي واستثناءات صريحة ومساعدة في الترحيل بدلاً من حماية المستأجرين الجدد فقط.
رؤية التهيئة.يجب على المزود عرض مقام كامل لمسؤولي الأمان: البشر بدون MFA، ومستخدمي الخدمة القدماء بكلمات مرور، والحسابات الخاملة، والمستخدمين دون قيود شبكية، والأدوار المميزة، والحسابات التي تسمح بدخول عام. النتائج يجب أن تكون مرئية على مستوى المؤسسة وقابلة للتصدير للتدقيق.
الكشف عبر العملاء.البنية التحتية المعاد استخدامها، وبيانات الاعتماد المسربة، والعملاء غير المعتادين، وتسلسلات الاستطلاع، وإنشاء المراحل المؤقتة، والتصديرات الكبيرة يمكن أن تشكل إشارة حملة. يجب على المزود الكشف على طبقة الخدمة، والاتصال بالضحايا المحتملين، وتحديد متى يستدعي النشاط عالي الثقة حظرًا مؤقتًا.
القياس عن بُعد القابل للتنفيذ.يحتاج العملاء إلى أدلة المصادقة والاستعلام والكائن والمرحلة والنقل مع احتفاظ كافٍ وزمن انتقال منخفض بما يكفي لاحتواء سرقة نشطة. يجب ألا تصبح الأدلة عالية الدقة غير متوفرة بالضبط حيث تخزن الخدمة البيانات عالية التأثير.
التحذير والتنسيق.يجب أن ينتقل تنبيه العميل عبر طريق طوارئ معروف ويحمل أدلة، وليس مجرد نصيحة بمراجعة السجلات. يجب على المزود تتبع الإقرار والاحتواء والتعرض المتكرر، ودعم طلبات إنفاذ القانون والجهات التنظيمية دون تحويل الملاحظات غير المؤكدة إلى أعداد ضحايا مؤكدة.
التحقق بعد الحادث.الميزات والإعدادات الافتراضية المعلنة تحتاج إلى مقاييس تبني وفعالية. التغييرات اللاحقة لـ Snowflake نحو MFA الافتراضي، وتعطيل كلمات المرور المسربة، ونتائج Trust Center، وأنواع الهوية الأقوى تعالج المسار المرصود. سؤال المساءلة المتبقي هو التغطية: أي المستخدمين والعملاء محميون بالفعل، وما الاستثناءات المتبقية، وكم مرة يوقف التحكم محاولة حقيقية أو محاكاة؟
هذا التوزيع لا يجعل Snowflake مراقب البيانات لكل مجموعة بيانات عميل، ولا يجعل المزود مسؤولاً عن كل تهيئة عميل. إنه يعترف بأن شركة سحابية تربح من تركيز البيانات وتشغيل حد أمني. النطاق يخلق واجبات لا يمكن للمزود فقط أداؤها، خاصة الارتباط عبر المستأجرين وهندسة الأساس.
التقاضي اللاحق يختبر نفس الحدود دون حلها بعد
واجهت Snowflake والشركات المتأثرة دعاوى مدنية موحدة بعد الحوادث. في أمر محكمة فيدرالية بتاريخ 29 أكتوبر 2025، قضت محكمة مقاطعة مونتانا بأن المدعين من المؤسسات المالية قد أثاروا بشكل كافٍ نظريات إهمال معينة ضد Snowflake وTicketmaster لتجاوز طلبات الرفض. تعاملت المحكمة مع MFA الافتراضية المزعومة وإمكانية التوقع بأنها ذات صلة بالواجب والخرق والسببية في تلك المرحلة الإجرائية.
ذلك الأمر ليس نتيجة محاكمة بأن Snowflake أو Ticketmaster كانت مهملة. في طلب الرفض، تختبر المحكمة ما إذا كانت الادعاءات الموثوقة تشكل مطالبة معقولة؛ لا تحسم الأدلة المتنازع عليها، أو تحدد آلية الحادث النهائية لكل مدعي، أو تخصص الأضرار. نازعت Snowflake في الادعاءات وجادلت بأن فشل العملاء في تنفيذ MFA وسياسات الشبكة وغيرها من الضمانات تسبب في الضرر. الأمر مهم لأنه يظهر أن وصف MFA كإعداد عميل لم ينه تلقائيًا كل مطالبة بواجب المزود. إنه ليس بديلاً عن سجل الأسس النهائي.
التحقيق الكندي للخصوصية حمل توزيعًا مختلفًا. قال OPC إن Ticketmaster Canada بقيت المراقب وكانت الكيان قيد التحقيق، بينما اتصل المكتب بـ Snowflake للحصول على معلومات. هذا يعكس مبدأ خصوصية شائعًا: الاستعانة بمصادر خارجية للتخزين لا ينقل واجب المراقب في الحماية والإخطار. لا يعني أن مزود الخدمة ليس لديه واجبات تعاقدية أو تقنية أو قانونية خاصة به.
10-K الخاص بـ Snowflake اعترف بدعاوى قضائية عديدة وتحقيقات تنظيمية واستفسارات من المشرعين، لكنه لم يبلغ عن تخصيص نهائي عالمي للمسؤولية. اعتبارًا من تاريخ النشر، المصادر العامة التي تمت مراجعتها هنا لا تدعم إعلان أن Snowflake تم تبرئتها قانونيًا، أو أن كل عميل كان مخطئًا قانونيًا، أو أن محكمة أو جهة تنظيمية نهائية اعتمدت التوزيع التشغيلي لهذه المقالة.
المساءلة التشغيلية يمكن تقييمها قبل المسؤولية النهائية. هل كان الوصول بكلمة مرور فقط متوقعًا؟ نعم. هل كان بإمكان العميل طلب MFA وسياسات الشبكة؟ نعم. هل كان بإمكان Snowflake تصميم إعدادات افتراضية وكشف نشاط عبر العملاء؟ نعم. هل استغل المجرمون المسار الناتج عن قصد؟ نعم. هذه الافتراضات يمكن أن تتعايش. قانون الضرر والعقد والخصوصية والأوراق المالية قد يعين العواقب بشكل مختلف حسب الاختصاص والمدعي، لكن الهندسة لا يجب أن تنتظر حتى يفوز شعار واحد.
اختبار مسؤولية مشتركة قابل للقياس
أقوى رد ليس مخططًا آخر مع "عميل" على جانب و"مزود" على الجانب الآخر. إنه مجموعة من الضوابط يمكن إظهار تغطيتها وسلوك فشلها.
| سؤال التحكم | دليل العميل | دليل المزود |
|---|---|---|
| هل يمكن لإنسان استخدام كلمة مرور فقط؟ | جرد جميع المستخدمين البشريين، سياسة العامل و IdP، مالك الاستثناء وانتهاء الصلاحية | إعداد افتراضي مفروض، تغطية حسب عمر الحساب والعميل، محاولات كلمة مرور فقط محظورة |
| هل يمكن لهوية خدمة استخدام كلمة مرور بشرية؟ | جرد عبء العمل، تناوب المفتاح أو OAuth، المالك، نطاق الدور والشبكة | نوع خدمة منفصل، حظر كلمة المرور، مقاييس الترحيل والتوافق |
| هل يمكن لبيانات اعتماد مسروقة الاتصال من أي مكان؟ | سياسات شبكة حساب ومستخدم مختبرة، تغطية نقطة النهاية الخاصة، استثناءات معتمدة | تحذير على الحسابات غير المقيدة، محاكاة السياسة، إنفاذ آمن للإغلاق، حظر المصادر الخبيثة |
| هل يمكن لمستخدم واحد قراءة أو تصدير بيانات مفرطة؟ | اختبارات الدور إلى البيانات، الإخفاء، مرشحات الصفوف، فصل التصدير والموافقات | صلاحيات دقيقة، ضوابط المرحلة، قياس نقل، كشف تصدير عالي المخاطر |
| هل يمكن رؤية سرقة نشطة بسرعة؟ | قواعد SIEM، توجيه مأهول، نتائج تمرين، احتفاظ مستقل | تحليلات عبر الحسابات، زمن انتقال الكشف، اكتمال الحدث، نجاح الاتصال بالطوارئ |
| هل يمكن إعادة بناء التعرض؟ | ملكية الهوية، خريطة موضوع البيانات، دليل قانوني، سجلات محفوظة | ربط الجلسة بالاستعلام، تاريخ الكائن والعمود، دليل المرحلة والنقل، حزمة دليل المستأجر |
| هل الحساب الإقليمي يفرض السيادة؟ | الولايات القضائية المعتمدة للوصول، سجل الحركة، مراجعة التكرار والموصل | التزام المنطقة، دليل المصدر والوجهة، ضوابط الخروج، تحذيرات عبر المناطق |
| هل يعمل العلاج في الواقع؟ | نتائج مغلقة، استثناءات قديمة، اختبارات عينة | مقاييس التبني، مقاييس تشغيل التحكم، مراجعة الإيجابيات الخاطئة والتجاوز |
يجب أن يتلقى مجالس الإدارة النتائج بدلاً من جرد الميزات. المقاييس المفيدة تشمل النسبة المئوية للمستخدمين البشريين المحميين بـ MFA مقاوم للتصيد، عدد مستخدمي الخدمة القادرين على كلمة المرور، عمر كل استثناء طوارئ، النسبة المئوية للحسابات ذات سياسات الشبكة المختبرة، عدد هويات المقاولين المميزة بعد انتهاء الصلاحية، متوسط الوقت للتنبيه على المصادر غير المألوفة، الوقت لتعليق جلسة عالية الثقة، والوقت لإنتاج حزمة تعرض على مستوى الحقل.
يجب على Snowflake نشر التقدم الإجمالي حيث يمكنها ذلك دون كشف العملاء. تعهد CISA يتناول صراحة إحصاءات التبني حسب المستخدم ونوع MFA. بيان أن MFA متوفرة أقل إفادة من توزيع عمليات تسجيل الدخول بكلمة مرور فقط بمرور الوقت. بيان أن Trust Center مفعل أقل إفادة من عدد النتائج الحرجة التي تظل مفتوحة بعد فترة محددة. بيان أنه تم إخطار العملاء المشبوهين أقل إفادة من زمن انتقال الإخطار واكتمال حزمة الأدلة.
يجب على العملاء طلب نفس الصرامة من أنفسهم. المزود لا يمكنه إنقاذ منظمة تنشئ أدوارًا واسعة، وتتجاهل النتائج، وتبقي مستخدمي مقاولين قدامى، وليس لديها من يرد على اتصال الطوارئ. الغرض من الإعدادات الافتراضية الأقوى ليس نقل ملكية أمان العميل إلى Snowflake. إنه جعل الإغفالات المتوقعة أقل احتمالاً لأن تصبح سرقة بيانات جماعية.
ما لا يثبته السجل العام بعد
الأدلة قوية بما يكفي لإعادة بناء نمط الحملة، لكن ليس كل حادثة ضحية.
السجل العام لا يحدد جميع المنظمات المخطرة، أو يؤكد أن جميع الـ 165 تعرضوا لوصول غير مصرح به، أو يقدم إجماليًا نهائيًا للحملة للأفراد أو الجداول أو السجلات أو البايتات التي تم تنزيلها. لا يظهر أي الضحايا دفعوا مطالب الابتزاز أو ما إذا كان الحذف الموعود قد حدث.
لا ينشر نوع المستخدم، أو التسلسل الهرمي للأدوار، أو تاريخ MFA، أو تكوين الشبكة، أو مالك نقطة النهاية، أو تسلسل الجلسة، أو الأعمدة التي تم الوصول إليها، أو حجم التصدير لكل منظمة. نتائج أجهزة المقاولين من عدة تحقيقات لا يجب أن تنسب إلى كل ضحية. إحصائية تعرض بيانات الاعتماد 79.7 في المئة لا يجب تحويلها إلى نسبة ضحايا.
لا يثبت ثغرة برمجية، أو هروب عبر المستأجرين، أو اختراق منصة الإنتاج الخاصة بـ Snowflake، أو سرقة بيانات اعتماد رئيسية للمزود، أو الوصول إلى كل عميل Snowflake. الاستخدام المرصود للعملاء والأوامر المدعومة هو دليل على إساءة استخدام بيانات الاعتماد، وليس دليلاً على استغلال كود المنتج.
لا يثبت أن البيانات الإقليمية عبرت حدودًا وطنية في كل حادثة. الهندسة المعمارية سمحت بالوصول عن بعد والتنزيل المحلي؛ تحليل النقل القانوني سيتطلب حقائق المصدر والوجهة وموضوع البيانات والتعاقد والاختصاص لكل عميل.
لا يسمح بتعميم الحقول المحتملة لـ Ticketmaster أو نطاق تفاصيل المكالمات لـ AT&T أو أي عدد من منتدى إجرامي على عملاء آخرين. إيداع Live Nation لم يذكر Snowflake. إيداع AT&T لم يذكر Snowflake أو UNC5537. الارتباط الخارجي قد يكون ذا صلة بتحقيق إضافي، لكن يجب الاقتباس من الإيداعات لما تثبته فعليًا.
أخيرًا، توثيق Snowflake الحالي لا يثبت تشغيل الضوابط في أبريل ومايو 2024. الإعدادات الافتراضية اللاحقة لـ MFA، وحماية كلمات المرور المسربة، وكشف Trust Center، وسياسات المصادقة، وتغييرات الهوية قد تقلل التكرار، لكن الأدلة العامة على التبني وتغطية الاستثناء وأداء الكشف والفعالية المستقلة تبقى أكثر محدودية من أوصاف الميزات.
المسؤولية المشتركة يجب أن تبقى على قيد الحياة في اللحظة التي يتم فيها تجاهل التوصية
حملة Snowflake ليست مفهومة بشكل أفضل كمسابقة بين قصتين مطلقتين. قصة واحدة تقول إن المنصة اخترقت والمزود فشل وحده. الأدلة لا تدعمها. الأخرى تقول إن العملاء فقدوا كلمات المرور وبالتالي سؤال المزود مغلق. هذا غير مكتمل تقنيًا.
وجدت UNC5537 تقاطعًا قابلًا للتوسع بين اختراق نقاط النهاية والتركيز السحابي. كلمات المرور التاريخية بقيت صالحة. الهويات البشرية وهويات الخدمة لم تكن دائمًا منفصلة. بوابات MFA والشبكة كانت غائبة. وظائف الاستعلام والمرحلة المدعومة نقلت البيانات بسرعة. المزود يمكنه رؤية نمط عبر المستأجرين، بينما رأى كل عميل حسابه فقط. منطقة تخزين مختارة يمكن أن تمسك بيانات المصدر في مكانها حتى مع جلسة مصادقة أنشأت نسخة غير خاضعة للسيطرة في مكان آخر.
العملاء كان لديهم أوضح واجب لحوكمة مستخدميهم وأدوارهم ونقاط نهايةهم ومقاوليهم وبياناتهم. Snowflake كان لديها أوضح واجب لتأمين ومراقبة حدود الخدمة، وجعل الحمايات عالية القيمة سهلة وغير قابلة للتجنب بشكل متزايد، وكشف سلوك الحملة، وتوفير الأدلة. المهاجمون تحملوا المسؤولية المباشرة عن الأفعال الإجرامية. الجهات التنظيمية والمحاكم يجب أن تقيم الواجبات القانونية على الحقائق والقانون المطبق على كل منظمة. هذه التوزيعات تتداخل لأن الضوابط تتداخل.
اتجاه المنتج بعد الحملة يعترف ضمنيًا بالفجوة بين القدرة والنتيجة. MFA الافتراضي للمستخدمين البشريين الجدد، وتعطيل كلمات المرور المسربة، وسياسة المصادقة الأقوى، وهجرة مستخدمي الخدمة، ونتائج Trust Center تحرك الأمان أقرب إلى أساس المزود. لا تمحو مسؤولية العميل. تجعل النظام المشترك أقل اعتمادًا على كل مسؤول يجد ويمكّن كل خيار صحيح قبل اختبار كلمة مرور مسروقة.
هذا هو اختبار المساءلة الدائم لمنصة بيانات سحابية. افترض أن عميلًا سيفوّت تحذيرًا، وأن جهاز مقاول سيصاب، وأن بيانات اعتماد ستبقى صالحة، وأن مهاجمًا سيستخدم وظائف المنتج العادية. ثم اسأل ما إذا كان الإعداد الافتراضي يمنع تسجيل الدخول، وبوابة أخرى ترفض المصدر، والدور يكشف القليل، والتصدير يستدعي تدخلًا، والأدلة تصل إلى العميل في الوقت المناسب. المسؤولية المشتركة تكون ذات مصداقية فقط عندما تظل الخدمة قابلة للدفاع بعد خطأ متوقع من أحد الطرفين، وعندما يمكن لكلا الطرفين إثبات ما فعلاه قبل وبعده.