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

ملخص

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

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

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

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

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

المساءلة من خلال التحكم العملي

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

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

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

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

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

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

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

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

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

التقاضي يمكن أن يؤثر على السجل لكن لا ينبغي أن يحل محل أدلة التحكم. أمر مرحلة pleadings في التقاضي متعدد المناطق الخاص بـ 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 كدرس القصة. هذا صحيح جزئيًا وما زال غير كافٍ. إحراج العملاء علنًا لا يعطل كلمات المرور المسربة، أو يعيد تصميم الإعدادات الافتراضية، أو يسلم حزم أدلة. يمكن أن يجعل العملاء يخفون التكوينات الضعيفة حتى يكشف حادث عنها.

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

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

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

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

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

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

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

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

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

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

ما لا نستنتج

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

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

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