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

الملخص

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

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

المبدأ الأول هو الحفاظ على حدود الحملة بدقة. قال تقرير Mandiant الصادر في يونيو 2024 إن الوصول غير المصرح به في الحوادث التي تعاملت معها نجم عن بيانات اعتماد العملاء المخترقة، ولم تجد أي دليل على اختراق بيئة Snowflake المؤسسية. كما وجهت إرشادات Snowflake للعملاء، والتي عززتها CISA علىhttps://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access، العملاء إلى التحقيق في وصول المستخدم غير المصرح به وتعزيز ضوابط الهوية والشبكة. لا يثبت السجل الذي تمت مراجعته وجود استغلال لمنصة Snowflake، أو هروب عبر المستأجرين، أو سرقة بيانات اعتماد رئيسية للمزود.

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

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

ينص الإيداع السنوي لشركة Snowflake للسنة المالية 2025 علىhttps://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htmعلى موقف الشركة من المسؤولية المشتركة ويصف العواقب القانونية والتنظيمية والمتعلقة بالسمعة بعد نشاط 2024. الإيداع هو تمثيل من الشركة، وليس حكماً. ومع ذلك، فهو ذو صلة لأن Snowflake نفسها أفصحت عن أن الحملة أثرت على مخاطر الأعمال بما يتجاوز أي مستأجر عميل واحد. أصبحت المسؤولية المشتركة قضية شركة عامة.

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

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

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

هذا التمييز أساسي للإصلاح. لم يكن التشفير أثناء السكون هو الحاجز الحاسم. تصف وثائق التشفير الشامل من Snowflake علىhttps://docs.snowflake.com/en/user-guide/security-encryption-end-to-endالتشفير أثناء السكون وأثناء النقل، ولكنها تشرح أيضاً أنه يجب استخدام البيانات أثناء عمليات الجدول ويمكن تفريغها وتنزيلها بواسطة المستخدمين المصرح لهم. يمكن للمهاجم الذي يستوفي مصادقة الحساب ويرث دوراً أن يطلب من الخدمة نتائج قابلة للقراءة. التشفير ليس بديلاً عن ضمان الهوية، وتصميم الأدوار، والتحكم في التصدير، والكشف.

تحدد ضوابط الوصول مدى التأثير بعد تسجيل الدخول. يصف نظرة عامة على ضوابط الوصول في Snowflake علىhttps://docs.snowflake.com/en/user-guide/security-access-control-overviewالأدوار والامتيازات والملكية والتسلسل الهرمي. تختلف بيانات الاعتماد المسروقة المخصصة بوصول ضيق عن تلك المخصصة بامتيازات قراءة واسعة أو إدارة الحساب. حساب الخدمة المُعد لخط أنابيب يختلف عن مسؤول متعاقد. مبدأ الامتياز الأقل ليس شعاراً؛ إنه الفرق بين جلسة معادية تعيد طريقة عرض واحدة وجلسة معادية تتجول عبر جداول العملاء الرئيسية.

يمكن أن يقلل تصنيف البيانات وإخفائها من العواقب. يربط توثيق تصنيف البيانات الحساسة في Snowflake علىhttps://docs.snowflake.com/en/user-guide/classify-introاكتشاف الأعمدة الحساسة بسياسات الإخفاء والوصول إلى الصفوف. هذا لا يثبت أن العملاء المتضررين كانوا يمتلكون هذه الضوابط. إنه يُظهر مساراً للإصلاح: يجب على العملاء تحديد الحقول الشخصية والمنظمة، وعرض طرق العرض بدلاً من الجداول الخام حيثما أمكن، وفصل أدوار التصدير عن أدوار القراءة العادية.

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

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

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

أعلنت Snowflake في سبتمبر 2024 علىhttps://www.snowflake.com/en/blog/multi-factor-identification-default/تغييراً في وضع المنتج. قالت إن MFA ستُفرض افتراضياً للمستخدمين البشر في الحسابات المنشأة اعتباراً من أكتوبر 2024، ولن تخضع حسابات الخدمة لهذا المطلب المحدد. كما أعلنت عن متطلبات كلمات مرور أقوى لكلمات المرور المنشأة حديثاً والمعدلة. هذا إصلاح ذو مغزى لأنه يغير المسار الافتراضي للحسابات المستقبلية.

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

يمنح توثيق سياسة المصادقة في Snowflake علىhttps://docs.snowflake.com/en/user-guide/authentication-policiesالمسؤولين ضوابط على أساليب المصادقة والعملاء وموفري الهوية وتسجيل MFA. يمنح توثيق مصادقة زوج المفاتيح علىhttps://docs.snowflake.com/en/user-guide/key-pair-authحسابات الخدمة بديلاً عن كلمات المرور الثابتة. تضع هذه الضوابط واجبات على العملاء، ولكنها تحدد أيضاً سطح إصلاح المزود: يجب أن يجعل المنتج الأنماط الجيدة أسهل، والاستثناءات السيئة مرئية، والترحيل أقل خطورة.

يساعد إرشاد الهوية الرقمية من NIST علىhttps://pages.nist.gov/800-63-4/sp800-63b.htmlفي صياغة النتيجة. كلمات المرور ليست مقاومة لإعادة التشغيل. الطرق المقاومة للتصيد أو المرتبطة تشفيرياً تقلل من قيمة كلمة المرور المسروقة. بالنسبة لعملاء Snowflake، يعني ذلك أنه يجب على المسؤولين البشريين الانتقال عبر هوية موحدة أو MFA قوي، بينما يجب على مستخدمي الخدمة استخدام بيانات اعتماد أعباء عمل محدودة النطاق تدور ويمكن تعطيلها دون انتحال شخص.

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

أكثر إصلاح مباشر للمزود بعد حملة بيانات اعتماد مسروقة ليس محاضرة حول إعادة استخدام كلمات المرور. إنه جعل كلمات المرور المسربة المعروفة تتوقف عن العمل. قالت Snowflake في إعلان ديسمبر 2024 علىhttps://www.snowflake.com/en/blog/leaked-password-protection/إنها ستقوم تلقائياً بتعطيل كلمات المرور المكتشفة على الويب المظلم من خلال عملية تحافظ على الخصوصية عندما يتم تأكيد تسربها وأنها لا تزال صالحة. يعالج هذا الضبط الميزة المركزية للحملة: بيانات الاعتماد المسروقة قبل فترة طويلة من 2024 ظلت مقبولة من قبل الخدمة.

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

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

يؤطر تعهد CISA "آمن حسب التصميم" علىhttps://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdfهذا التمييز. يطلب من المصنعين الانتقال إلى ما وراء الضوابط الاختيارية نحو نتائج قابلة للقياس مثل تفعيل MFA الافتراضي ومقاييس التبني. وضع إعلان تعهد Snowflake في يوليو 2024 علىhttps://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/الشركة ضمن هذا الالتزام العام. التعهد طوعي وليس حكماً قانونياً على الحملة. إنه ذو صلة لأنه يحدد نوع الدليل الذي يجب أن يتوقعه العملاء بعد الحدث.

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

حددت Mandiant غياب قوائم السماح بالشبكة كأحد العوامل المتكررة. ينص توثيق سياسة الشبكة في Snowflake علىhttps://docs.snowflake.com/en/user-guide/network-policiesعلى الوضع الافتراضي العملي: بدون سياسة، يمكن للمستخدمين الاتصال من أي جهاز كمبيوتر أو جهاز. يمكن للعملاء تقييد الوصول حسب مواقع الشبكة المسموح بها أو المحظورة واستخدام أنماط الاتصال الخاص لحدود أقوى.

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

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

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

بيانات المراقبة هي حد الدليل

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

توفر LOGIN_HISTORY علىhttps://docs.snowflake.com/en/sql-reference/account-usage/login_historyمحاولات تسجيل الدخول مع معلومات IP المصدر والعميل والنجاح والعامل. توفر QUERY_HISTORY علىhttps://docs.snowflake.com/en/sql-reference/account-usage/query_historyنشاط الاستعلام والمستخدم والدور ونص الاستعلام وحجم النتيجة والصفوف التي تم تفريغها والبايتات المرسلة عبر الشبكة. يمكن أن تساعد ACCESS_HISTORY علىhttps://docs.snowflake.com/en/sql-reference/account-usage/access_historyفي إعادة بناء الوصول إلى الكائنات والأعمدة للطبعات المؤهلة. يصف توثيق مركز الثقة (Trust Center) علىhttps://docs.snowflake.com/en/user-guide/trust-center/overviewفحوصات الوضع واكتشافات MFA وسياسات الشبكة وتسجيلات الدخول المشبوهة وعناوين IP غير العادية وعمليات النقل الكبيرة.

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

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

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

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

يمكن أن يكون اختيار منطقة Snowflake مهماً لوقت الاستجابة، والمرونة، والخصوصية، والمشتريات. يقول توثيق المناطق المدعومة علىhttps://docs.snowflake.com/en/user-guide/intro-regionsإن الحساب مستضاف في منطقة واحدة وأن البيانات تبقى هناك ما لم يقم المستخدمون بنسخها أو نقلها أو نسخها احتياطياً بشكل صريح. كما ينص على الحد الرئيسي: اختيار المنطقة لا يحد من وصول المستخدم إلى Snowflake.

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

يحذر إرشاد المشاركة عبر المناطق في Snowflake علىhttps://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.htmlالعملاء من تأكيد القيود القانونية والتنظيمية قبل نسخ البيانات إلى منطقة أو بلد آخر. يتعلق هذا الإرشاد بالحركة المعتمدة. يختلف التصدير القائم على بيانات الاعتماد لأنه يمكن أن ينشئ نسخة غير خاضعة للرقابة خارج المنطقة المختارة دون تغيير منطقة الحساب المصدر. يمكن أن يكون جرد البيانات الذي يسجل المنطقة المصدر فقط دقيقاً ومع ذلك غير مكتمل بعد التصدير.

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

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

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

قال إيداع Live Nation في مايو 2024 علىhttps://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htmإن الشركة حددت نشاطاً غير مصرح به في بيئة قاعدة بيانات سحابية تابعة لجهة خارجية تحتوي بشكل أساسي على بيانات Ticketmaster، وأن جهة إجرامية عرضت لاحقاً بيانات مستخدم مزعومة للبيع. لم يسمِّ الإيداع Snowflake أو يقدم عدداً مؤكداً للأشخاص المتضررين.

وصفت صفحة حادثة Ticketmaster Canada علىhttps://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incidentقاعدة بيانات سحابية معزولة تابعة لجهة خارجية، وحقولاً محتملة لبعض مشتري التذاكر في أمريكا الشمالية، وحددت أن حسابات عملاء Ticketmaster لم تتأثر. حدد مفوض الخصوصية الكندي لاحقاً Snowflake كمزود لـ Ticketmaster في إحاطة برلمانية علىhttps://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/، مشيراً أيضاً إلى أن التحقيق لا يزال مفتوحاً وأن Ticketmaster Canada لا تزال المتحكم قيد المراجعة.

وصف إيداع AT&T في يوليو 2024 علىhttps://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htmوصولاً غير قانوني إلى مساحة عمل AT&T على منصة سحابية تابعة لجهة خارجية وتسريب سجلات تفاعلات المكالمات والرسائل النصية. لم يسمِّ الإيداع Snowflake. إنه مفيد لفهم حادثة مساحة عمل سحابية مفصح عنها لجهة خارجية وحدود حقولها، وليس كإسناد مستقل.

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

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

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

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

• نشأت الطباعة مع اختراع الحروف المتحركة على يد يوهانس غوتنبرغ في القرن الخامس عشر.
• تشمل العناصر الرئيسية اختيار الخط، وتباعد الحروف (kerning)، وتعقب المسافات (tracking)، وتباعد الأسطر (leading).
• الطباعة الجيدة تعزز القراءة وتنقل المزاج أو النغمة في التصميم.

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

المساءلة بالسيطرة العملية

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

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

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

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

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

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

يجب أن يتضمن سجل الإصلاح عشر نتائج على الأقل.

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

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

يمكن أن تؤثر الدعاوى القضائية على السجل ولكن لا ينبغي أن تحل محل أدلة الضبط. الأمر في مرحلة المرافعة في دعوى Snowflake متعددة المناطق علىhttps://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdfسمح بالمضي قدماً في بعض الادعاءات أثناء معاملتها بموجب المعايير الإجرائية. هذا ليس حكماً نهائياً بالمسؤولية. إنه يظهر أن المحاكم قد تفحص إعدادات المزود الافتراضية وقابلية التوقع والسببية حتى عندما تبدأ القصة العامة ببيانات اعتماد العملاء.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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