ملخص
- كشفت Rackspace عن حادثة فدية أثرت على بيئة Hosted Exchange الخاصة بها في ديسمبر ٢٠٢٢. وأشارتحديث ٦ ديسمبرإلى أن الحادثة تسببت في انقطاعات الخدمة لعملاء Hosted Exchange، مما دفع Rackspace إلى عزل البيئة وحفز دعم ترحيل العملاء إلى بيئات جديدة.
- أفادتحديث ٩ ديسمبرالصادر عن Rackspace ونموذج SEC 8-Kالمرتبط به أن CrowdStrike أكدت أن الحادثة تم احتواؤها بسرعة ومحدودة فقط بـ Hosted Exchange، وهو حل بريد إلكتروني مُدار يُستخدم بشكل أساسي من قبل الشركات الصغيرة والمتوسطة ويمثل حوالي ١ بالمائة من إيرادات Rackspace.
- كان الضرر الذي لحق بالعملاء أكبر مما يشير إليه حصة الإيرادات هذه. البريد الإلكتروني هو نظام تشغيل للشركات الصغيرة: الحصول على العملاء، والفواتير، والمواعيد النهائية القانونية، وجدولة المرضى، وموافقات الموردين، ورسائل الرواتب، وأحداث التقويم، والمرفقات، وسجلات العملاء، يمكن أن تكون جميعها داخل صناديق البريد المستضافة.
- دفعت Rackspace العملاء نحو الترحيل إلى Microsoft 365، وعززت طاقم الدعم، ثم وفرت لاحقًا استردادًا تدريجيًا للبيانات من خلال ملفات PST. وحذرتتحديثات الحالةمن أن الاسترداد يقتصر على بيانات البريد الإلكتروني التاريخية لـ Hosted Exchange قبل ٢ ديسمبر ٢٠٢٢، وأن بعض البريد الإلكتروني والبيانات الأخرى قد تظل غير متاحة.
- قالت إيداعات Rackspace اللاحقة لدى SEC إن أعمال Hosted Exchange قد توقفت، وتم نقل العديد من العملاء إلى Microsoft 365، ورفعت دعاوى قضائية، وسجلت Rackspace نفقات الحادثة، واستردادات التأمين، والتكاليف القانونية/المهنية المستمرة. وبالتالي أصبح الحادث سجل استمرارية ومسؤولية، وليس مجرد انقطاع في ديسمبر.
- إن سياق ثغرات Microsoft Exchange مهم، لكنه لا يمحو مساءلة المزود. نشرت Microsoft إرشادات وتحديثات لثغرات Exchange بما في ذلكCVE-2022-41040 و CVE-2022-41082، بينما ناقش التقارير العامة وتحليل البائعين لاحقًا OWASSRF و CVE-2022-41080. لا تزال Rackspace تسيطر على البيئة المستضافة، وقرارات التصحيح، والتخفيفات، وتصميم النسخ الاحتياطي، وعملية استرداد العملاء.
استضافة البريد كانت إيرادات صغيرة واعتمادًا كبيرًا
توضح الإيداعات العامة لـ Rackspace حقيقة واحدة: لم تكن Hosted Exchange خط أعمال كبيرًا لـ Rackspace. قال تحديث ٦ ديسمبر للحادثة إن أعمال Hosted Exchange حققت حوالي ٣٠ مليون دولار من الإيرادات السنوية في قطاع التطبيقات والمنصات المشتركة. وقال تحديث ٩ ديسمبر ونموذج 8-K إن الأعمال تمثل حوالي ١ بالمائة من إجمالي الإيرادات السنوية لـ Rackspace وتتكون أساسًا من الشركات الصغيرة والمتوسطة التي تستخدم المنتج فقط. بالنسبة للمستثمرين، ساعد ذلك في تأطير الأهمية المادية المالية. بالنسبة للعملاء، فقد أغفل النطاق الحي للاعتماد.
البريد الإلكتروني ليس تطبيقًا هامشيًا لشركة صغيرة. إنه المكان الذي تصل فيه أوامر الشراء، وتناقش فيه المواعيد القضائية، وتؤكد مواعيد المرضى، وتلاحق الفواتير، وتعالج طلبات الدعم، وتتبادل سجلات الموظفين، وتخزن وثائق التأمين، وتحدث مفاوضات الإيجار، ويرسل المقاولون من الباطن مرفقات، ويتوقع العملاء إجابات. غالبًا ما تكون بيانات التقويم وجهات الاتصال بنفس أهمية نصوص الرسائل. يمكن لشركة صغيرة أن تفقد الوصول إلى نظام CRM أو إضافة محاسبية ليوم واحد وترتجل. فقدان البريد الإلكتروني والتقويمات بدون مسار نسخ احتياطي نظيف يمكن أن يعطل كل علاقة تقريبًا في وقت واحد.
لهذا السبب تنتمي حادثة Rackspace إلى الاعتماد على الخدمات السحابية واستمرارية خدمات المؤسسات الصغيرة والمتوسطة. اختار العملاء مزودًا مُدارًا جزئيًا لأن تشغيل Exchange بأمان صعب. يتمتع Microsoft Exchange Server بتاريخ طويل من الاستهداف، والصيانة الأمنية ليست تافهة للمؤسسات الصغيرة. يعد المزود المستضاف بامتصاص هذا العبء التشغيلي: التصحيح، والمراقبة، والنسخ الاحتياطية، والتوفر، والدعم، والترحيل، والاستجابة للحوادث. عندما تتعطل بيئة ذلك المزود، لا يملك العملاء وصول المسؤول لاستعادتها بأنفسهم.
قال تحديث ٦ ديسمبر لـ Rackspace إنها استعانت بشركة رائدة في مجال الدفاع السيبراني، وعزلت بيئة Hosted Exchange، واعتقدت أن الحادث مقتصر على Hosted Exchange، وبدأت في التواصل مع العملاء لمساعدتهم على الترحيل إلى بيئة جديدة في أسرع وقت ممكن. وقالت أيضًا إن Rackspace عززت طاقم الدعم وستتخذ خطوات إضافية لتوجيه العملاء خلال العملية.
ربما كانت تلك الإجراءات ضرورية. كما أنها تظهر اختلال توازن القوى. يتحكم المزود في البيئة ويتحكم العميل فقط في الحلول البديلة. يمكن للعميل إعداد إعادة التوجيه إذا تم توجيهه، والترحيل إذا تم دعمه، وتنزيل ملفات PST المستعادة إذا تم توفيرها، والتواصل عبر قنوات بديلة. لا يمكنه استعادة البيئة المستضافة المشتركة، أو فحص مسار الفدية، أو إثبات سلامة صندوق البريد دون أدلة من المزود.
تسلسل الأحداث الزمني انتقل من الانقطاع إلى الفدية إلى الانتقال القسري
تسلسل الحالة العامة مهم لأن العملاء عانوا من عدم اليقين قبل أن يحصلوا على تفسير كامل. حافظت صفحة حالة النظام لـ Rackspace لاحقًا على التحديثات المبكرة. قال صفحة حالة مشكلات Hosted Exchange إن Rackspace أصبحت على علم بمشكلة تؤثر على Hosted Exchange يوم الجمعة، ٢ ديسمبر ٢٠٢٢، وقامت بشكل استباقي بإيقاف تشغيل البيئة وفصلها أثناء تقييم الخطورة، ثم قررت لاحقًا أنها حادثة أمنية. بحلول ٦ ديسمبر، أعلنت Rackspace علنًا عن الفدية.
هذا التسلسل ليس غير معتاد في الاستجابة للحوادث. قد ترى الفرق التقنية المبكرة فشل تسجيل الدخول، وتدهور الخدمة، ونشاط مشبوه، أو أنظمة تالفة قبل أن تتمكن من ذكر الفدية بأمان. ولكن بالنسبة للعملاء، كل ساعة من الغموض مهمة. تحتاج شركة محاماة تفتقد اتصالات المحكمة، وعيادة تفتقد رسائل المرضى، ومقاول يفتقد أسئلة المناقصة، أو بائع تجزئة يفتقد طلبات العطلات إلى معرفة ما إذا كان البريد الإلكتروني سيعود، وما إذا كانت الرسائل آمنة، وما إذا كان يجب تفعيل خدمة جديدة.
قال بيان Rackspace الصحفي الصادر في ٦ ديسمبر إنها كانت على تواصل مستمر مع عملاء Hosted Exchange لمساعدتهم على الترحيل إلى بيئة جديدة في أسرع وقت ممكن. كان تحديث ٩ ديسمبر أكثر وضوحًا: كانت Rackspace تنقل بنشاط العملاء المتأثرين إلى Microsoft Office 365، مع إكمال العديد منهم الترحيل بالفعل، وأتاحت موارد بما في ذلك طاقم دعم إضافي وفريق Microsoft Fast Track المكمل لقوى العمل Rackspace.
هذا الرد غير الحادث من حدث استعادة إلى حدث ترحيل. لم يكن العملاء ينتظرون فقط عودة الخدمة المستضافة. كانوا يتم نقلهم إلى منصة مختلفة. الترحيل في حالات الطوارئ صعب. يحتاج المسؤولون إلى حسابات جديدة، وسجلات المجال، وتغييرات DNS، وكلمات المرور، والأجهزة، وملفات تعريف Outlook، وإعادة تكوين البريد المحمول، وصناديق البريد المشتركة، وقوائم التوزيع، والتقويمات، والأذونات، والأرشيفات، وقواعد الاحتفاظ، ودعم المستخدم. كل مهمة يمكن إدارتها في ترحيل مخطط. أثناء انقطاع الفدية، تصبح عمل أزمة.
سؤال المساءلة الرئيسي ليس إذن ما إذا كان ينبغي على Rackspace قلب مفتاح أسرع. السؤال الأفضل هو ما إذا كانت الخدمة المستضافة مصممة بمخرج طوارئ موثوق: صادرات صندوق بريد محمولة، ونسخ احتياطية حالية، وأدلة تشغيل ترحيل مختبرة، وكافي دعم كافٍ، وسجلات ملكية خاصة بالعميل، وإرشادات تغيير DNS، وتوقعات واضحة لما يمكن استرداده من البريد التاريخي.
الاحتوائية حمت الشركة الأوسع، لكن العملاء ما زالوا يفقدون الخدمة
أكدت Rackspace على الاحتواء. قال تحديث ٩ ديسمبر إن CrowdStrike أكدت أن الإجراء السريع لفصل الشبكة واتباع خطط الاستجابة للحوادث سرعان ما احتوى الحادثة وحصرها حصريًا في Hosted Exchange. وقالت إنه لم تتأثر أي منتجات أو منصات أو حلول أو أعمال أخرى لـ Rackspace أو تعاني من توقف بسبب الحادثة. حمل نموذج SEC 8-K نفس الرسالة.
هذا التمييز مهم. قد يحتاج مزود يواجه فدية إلى عزل الأنظمة بقوة لوقف الانتشار. يمكن أن يكون الاحتواء قرارًا أمنيًا صحيحًا حتى عندما يزيد سوء التوفر للعملاء المتأثرين. المزود الذي يؤخر العزل للحفاظ على وقت التشغيل يمكن أن يجعل الاختراق أسوأ. المزود الذي يعزل بسرعة يمكن أن ينقذ بقية البيئة بينما يترك العملاء عالقين.
مشكلة المساءلة ليست أن Rackspace عزلت البيئة. المشكلة هي أن العزل كشف اعتماد العملاء على استرداد Rackspace المسيطر. قيل لعملاء Hosted Exchange الترحيل أو انتظار تدفقات العمل الاستردادية. لم يتمكنوا من اختيار لقطة احتياطية مختلفة، أو تركيب قاعدة البيانات الخاصة بهم، أو فحص خوادم Exchange مباشرة. بالنسبة للكثيرين، كان الأصل التشغيلي الأكثر أهمية محصورًا داخل عملية حوادث يسيطر عليها المزود.
هذا درس مركزي للخدمات السحابية. احتواء المزود واستمرارية العميل يمكن أن يتجهاها في اتجاهين متعاكسين. يحتاج المزود إلى إيقاف المهاجم والحفاظ على الأدلة. يحتاج العملاء إلى التواصل، وتدفق الرسائل، والبريد القديم، والتقويمات، وجهات الاتصال، وتقدير. يجب أن تخدم خطة الاستجابة للحوادث كلا الهدفين. إذا كانت الخطة تحمي فقط مؤسسة المزود وليس قدرة العملاء على مواصلة العمل، يكون المزود قد احتوى الحادث الأمني لكنه صدر الانقطاع التجاري.
تظهر تحديثات حالة Rackspace أنها حاولت إنشاء مسارات متوازية: ترحيل Microsoft 365 للبريد المستقبلي، واسترداد البيانات للبريد التاريخي، وموارد الدعم. كان هذا الفصل سليمًا. لكنه أظهر أيضًا حدود التصميم الأصلي. يمكن أن يستمر البريد المستقبلي فقط إذا هاجر العملاء أو أعادوا التوجيه. تطلب استرداد البريد التاريخي استخراجًا دقيقًا من بيئة Hosted Exchange وتوفر PST مرحلي. قد تظل بعض البيانات غير متاحة. تشير هذه الحقائق إلى أن المنتج لم يكن لديه نموذج تجاوز الفشل نظيف وشبه فوري لكل صندوق بريد عميل.
بالنسبة لمنتج بريد مستضاف قديم، قد لا يكون ذلك مفاجئًا. لكن عملاء المزود المُدار يحق لهم فهم مفاضلة الاستمرارية قبل الأزمة. إذا كان المنتج رخيصًا لأنه يفتقر إلى المرونة الحديثة، يجب أن يعرف العملاء. إذا لم تكن النسخ الاحتياطية خدمة ذاتية للعميل، يجب أن يعرف العملاء. إذا كانت حادثة الفدية قد تفرض الترحيل بدلاً من الاستعادة، يجب أن يعرف العملاء.
سياق ثغرات Microsoft Exchange حقيقي ولكن محدود
سياق ثغرات Exchange ضروري لحادثة Rackspace. نشرت Microsoft إرشادات حول ثغرات اليوم الصفري المبلغ عنها في Exchange Server في سبتمبر ٢٠٢٢. قالت مدونة MSRC إن Microsoft كانت على علم بهجمات محدودة موجهة تستخدم CVE-2022-41040 و CVE-2022-41082، وأن الوصول الموثق كان مطلوبًا، وأن عملاء Exchange Online لم يكونوا بحاجة إلى اتخاذ إجراء. أوصت Microsoft بشدة لاحقًا بتطبيق تحديثات Exchange Server لهذه الثغرات. وصف تحليل مدونة الأمان سلسلة SSRF وتنفيذ التعليمات البرمجية عن بعد وأشار إلى هجمات موجهة مبكرة.
حل تحديث الأمان لـ Exchange في ٨ نوفمبر ٢٠٢٢ KB5019758 من Microsoft العديد من ثغرات Exchange بما في ذلك CVE-2022-41040 و CVE-2022-41082 و CVE-2022-41080. يحدد صفحة NVD لـ CVE-2022-41080 أنها ثغرة رفع امتياز في Microsoft Exchange Server، بينما يحدد NVD لـ CVE-2022-41082 ثغرة تنفيذ تعليمات برمجية عن بعد ويلاحظ وجودها في كتالوج الثغرات المستغلة المعروفة التابع لـ CISA. يوجد كتالوج الثغرات المستغلة المعروفة التابع لـ CISA بالضبط لأن المؤسسات تكافح لتحديد أولويات الثغرات المستغلة بالسرعة الكافية.
ربط تحليل لاحق من طرف ثالث مسار استغلال ذي صلة، OWASSRF، بـ CVE-2022-41080 و CVE-2022-41082. وصف إيجاز تهديد OWASSRF من Unit 42 طريقة الاستغلال على أنها تستخدم OWA وتتجاوز التخفيفات السابقة المرتبطة بـ ProxyNotShell. أصبح تحليل CrowdStrike المنشور نفسه جزءًا من السجل الفني العام، على الرغم من أن مقالة Rackspace يجب أن تتجنب المبالغة بما يتجاوز بيانات Rackspace الرسمية والتقارير الموثوقة.
هذا السياق مهم لأن توقيت التصحيح، والتخفيفات، وغموض الثغرات صعبة. قد يواجه المزود المستضاف مخاطر التوافق، وتعطيل العملاء، وإرشادات تخفيف أولية غير مكتملة. لكن الصعوبة ليست إعفاءً من المساءلة. باعت Rackspace البريد المُدار. كانت تتحكم في ما إذا كانت خوادم Exchange مكشوفة أم مصححة أم مخففة أم مراقبة أم مجزأة أم معزولة. العملاء لم يتحكموا.
الاستنتاج الناضج متوازن. سيطرت Microsoft على منتج Exchange وتحديثات الأمان. سيطر المهاجمون على الاستغلال الخبيث ونشر الفدية. سيطرت Rackspace على البيئة المستضافة واستمرارية العملاء. سيطرة العملاء على القليل جدًا داخل تلك البيئة. تحليل المساءلة الذي يلقي اللوم على Microsoft فقط أو Rackspace فقط هو تحليل فظ للغاية. السجل الحقيقي يمتد عبر إرشادات تصحيح البائع، وتنفيذ المزود، واعتماد العميل.
توفر النسخ الاحتياطية أصبح خط الضرر العملي
بعد استعادة خدمة البريد الإلكتروني أو ترحيلها، السؤال التالي هو البريد القديم. صفحة حالة Rackspace كاشفة بشكل غير عادي في هذه النقطة. في ٢١ ديسمبر، قالت إن Rackspace أكملت التحضير لاسترداد بيانات البريد الإلكتروني للعملاء وستجعل بيانات البريد الإلكتروني التاريخية متاحة كملفات PST من خلال بوابة. في ٢٢ ديسمبر، قالت إن ملفات PST كانت متاحة للعملاء الذين تم استرداد أكثر من ٥٠ في المائة من صناديق بريدهم، وستكون الملفات متاحة من خلال بوابة العملاء لمدة ٣٠ يومًا. في ٢٧ ديسمبر، ذكرت العملاء بأن الاسترداد يقتصر على بيانات البريد الإلكتروني التاريخية لـ Hosted Exchange قبل ٢ ديسمبر ٢٠٢٢، وأن بعض البريد الإلكتروني والبيانات الأخرى قد تظل غير متاحة.
تحدد هذه التحديثات خط الضرر. العميل الذي هاجر بسرعة يمكنه استئناف البريد الجديد، لكن الرسائل القديمة والمرفقات وعناصر التقويم وجهات الاتصال لم تكن بالضرورة متاحة على الفور. البيانات بعد ٢ ديسمبر تعتمد على الترحيل أو إعادة التوجيه أو الخدمة البديلة أو خيارات الأرشفة. استمر استرداد البيانات التاريخية بشكل منفصل. قد تظل بعض العناصر غير متاحة. تتطلب ملفات PST التنزيل والتخزين وتحميل الأرشيف ودعم المستخدم.
بالنسبة للمستخدم الفردي، PST هو مجرد ملف أرشيف. بالنسبة للشركة، يمكن أن يصبح استرداد PST مشروعًا تشغيليًا يستمر لأسابيع. أي إصدارات صندوق البريد كاملة؟ أي صندوق بريد مشترك يتبع أي قسم؟ أين تذهب التقويمات؟ كيف يتم التعامل مع النسخ المكررة؟ كيف يتم الحفاظ على الإقامة القانونية وواجبات الاحتفاظ؟ ماذا لو ترك المستخدم الشركة أثناء الحادثة؟ ماذا إذا لم يتمكن العميل من التنزيل خلال فترة ٣٠ يومًا؟ ماذا إذا قام موظف بتحميل أرشيف في المستأجر الخطأ؟ ماذا إذا تم تخزين رسائل مميزة أو منظمة بشكل غير آمن أثناء الاسترداد الطارئ؟
لهذا السبب فإن تصميم النسخ الاحتياطي هو قضية مساءلة، وليست حاشية تقنية. يجب أن يعرف المزود المُدار ما إذا كان العملاء يمكنهم استرداد صناديق البريد بشكل مستقل، وعدد المرات التي يتم فيها اختبار النسخ الاحتياطية، وكيف تؤثر الفدية على سلامة النسخ الاحتياطي، وكيف يتم توثيق الصادرات الخاصة بالعميل، ومدة بقاء الملفات المستردة متاحة، وما الدعم الموجود للعملاء ذوي الواجبات الامتثالية. لا ينبغي للعملاء اكتشاف حدود النسخ الاحتياطي أثناء عدم اتصال صناديق بريدهم.
كانت لغة حالة Rackspace حذرة. لم تعد باسترداد كل شيء. وصفت عملية دقيقة وحذرت من الحدود. هذا الصراحة مهم. لكنه يؤكد أيضًا أن بعض العملاء واجهوا عدم يقين بشأن ما إذا كان تاريخهم سيعود. بالنسبة للشركات التي تحتوي رسائلها الإلكترونية على سجلات قانونية أو طبية أو محاسبية أو خدمة عملاء، يمكن أن يكون هذا عدم اليقين ضارًا مثل الانقطاع الأولي.
كان مسار الترحيل إنقاذًا ونهاية منتج في نفس الوقت
لم تقم Rackspace فقط باستعادة العملاء إلى نفس المنتج. تذكر إيداعاتها اللاحقة لدى SEC أنها أوقفت منصة Hosted Exchange المحلية ونقلت العديد من العملاء إلى Microsoft 365 من خلال اتفاقية إعادة بيع مع Microsoft. ينص نموذج 10-Q لسبتمبر ٢٠٢٣ على أن أعمال البريد الإلكتروني Hosted Exchange كانت حلاً مُدارًا مقدمًا للشركات الصغيرة والمتوسطة، ومثلت حوالي ١ بالمائة من الإيرادات السنوية، وتم احتواؤها بسرعة وقصرها على Hosted Exchange، وأن Rackspace أوقفت منصة Hosted Exchange المحلية.
هذا مهم لأن العملاء دخلوا في انقطاع وخرجوا من خط إنتاج. ربما كان الترحيل إلى Microsoft 365 معقولاً من الناحية الفنية والاستراتيجية. يمكن أن يوفر Microsoft 365 مرونة بريد سحابي حديث وضوابط أمان ونطاق تشغيلي لا يمكن لـ Hosted Exchange القديم مضاهاته. لكن الترحيل القسري تحت ضغط الفدية ليس مثل مشروع التحديث المخطط. قد يواجه العملاء تراخيص جديدة وتكوينًا وموقع بيانات وتدريبًا وامتثالاً وأسئلة إدارية وفوترة جديدة.
سؤال المساءلة ليس ما إذا كان Microsoft 365 وجهة سيئة. من المحتمل أنه كان مسارًا عمليًا لاستعادة تدفق البريد. السؤال هو ما إذا كان لدى العملاء إشعار كافٍ ودعم وأدلة استرداد عندما انتهت الخدمة القديمة فعليًا. المزود الذي يبيع منتجًا مستضافًا قديمًا عليه إدارة مخاطر نهاية العمر قبل الاختراق، ليس بعده. إذا أجبر الحادث قرارًا بنهاية العمر، يستحق العملاء وضوحًا بشأن أرصدة الخدمة وشروط العقد وتصدير البيانات وإعادة التوجيه واسترداد الأرشيف والالتزامات المستقبلية.
كما غير الترحيل حدود المسؤولية. بمجرد انتقال العملاء إلى Microsoft 365، سيطرت Microsoft على الكثير من منصة البريد الأساسية، ربما بقيت Rackspace كبائع إعادة بيع أو مزود دعم، وكان لدى العملاء خيارات إدارية جديدة. يمكن أن يحسن ذلك الأمان، لكنه يمكن أن يربك المساءلة إذا حدث خطأ ما. من يتعامل مع الدعم؟ من يتحكم في تكوين المستأجر؟ من يحتفظ بملفات PST القديمة؟ من يضمن استرداد صندوق البريد؟ من يفوتر؟ من يجيب على الجهات التنظيمية؟
غالبًا ما تعتمد الشركات الصغيرة والمتوسطة على المزودين على وجه التحديد لأنه ليس لديهم طاقم داخلي لتلك الأسئلة. يمكن أن يتركهم الترحيل الأزمي مع حسابات تعمل لكن إدارة فوضوية. الاسترداد الحقيقي يعني ليس فقط "عودة البريد الإلكتروني" ولكن "صناديق البريد والتقويمات والأرشيفات وإعادة التوجيه والاحتفاظ وملكية الدعم والفواتير كلها منطقية".
جودة الاتصال أصبحت جزءًا من الحادثة
ركزت التقارير العامة في ذلك الوقت بشكل كبير على الاتصال. ذكرت Axios إحباط العملاء وصعوبة الشفافية بعد الفدية في مقالها في ديسمبر ٢٠٢٢. قال كبير مسؤولي المنتجات في Rackspace، في الجوهر، إن الشركة أعطت الأولوية للدقة وكانت حذرة بشأن ما يمكنها قوله. هذا التوتر حقيقي. الإفراط في المشاركة أثناء حادثة فدية حية يمكن أن يكشف معلومات دفاعية، ويعطل المفاوضات أو التحقيقات، ويخلق تعرضًا قانونيًا. قلة التواصل تترك العملاء غير قادرين على العمل.
تظهر قضية Rackspace لماذا تكون تحديثات الحالة العامة غير كافية للخدمات المُدارة الحيوية للأعمال. يحتاج العملاء إلى أنواع مختلفة من المعلومات في أوقات مختلفة. في البداية، يحتاجون إلى معرفة ما إذا كان تدفق البريد معطلاً، وما إذا كانت الرسائل في قائمة انتظار أو مفقودة، وما إذا كان يجب استخدام قنوات بديلة. بمجرد تأكيد الفدية، يحتاجون إلى إرشادات الترحيل، وإرشادات DNS، وجهات اتصال الدعم، ونصائح الأمان. أثناء الاسترداد، يحتاجون إلى جداول زمنية PST، وتوقعات الاكتمال، وإجراءات التنزيل، ومعالجة الأرشيف. بعد الحادثة، يحتاجون إلى أدلة لشركات التأمين والجهات التنظيمية والعملاء ومجالس إدارتهم أو مالكيهم.
نشرت Rackspace تحديثات من خلال إصدارات المستثمرين وإيداعات SEC وصفحة الحالة. عززت الدعم وأشركت Microsoft Fast Track. هذه إجراءات ذات معنى. لكن وجود إحباط العملاء يظهر أن عبء الاتصال كان أكبر مما يمكن أن تحمله قنوات Rackspace العادية بسهولة. آلاف من الشركات الصغيرة والمتوسطة، كل منها لديه مستخدمون يسألون أين ذهب بريدهم الإلكتروني، تخلق عاصفة دعم.
هذا هو المكان الذي يجب أن يكون فيه تخطيط الحوادث عمليًا للغاية. يجب على المزود بناء قوالب رسائل مسبقة للمسؤولين والمستخدمين النهائيين والعملاء المنظمين وشركاء MSP والمديرين التنفيذيين. يجب أن يكون لديه قنوات اتصال بديلة لأن البريد الإلكتروني قد لا يكون متاحًا. يجب أن يكون لديه أدوات حالة الخدمة الذاتية التي لا تتطلب المنتج المتأثر. يجب أن يكون لديه طريقة للتحقق من مسؤولي العملاء قبل تسليم ملفات الاسترداد. يجب أن ينسق مع شركاء الترحيل الرئيسيين قبل الأزمة إذا كان المنتج القديم قد يحتاج إلى إخلاء طارئ.
السجل العام لا يثبت أن Rackspace تجاهلت هذه الواجبات. لكنه يظهر أن الاتصال الحي أصبح بُعدًا للحادثة. حدث فدية في البريد المستضاف لا يتعلق فقط بالتشفير أو الاستغلال؛ إنه يتعلق بآلاف الشركات التي تحتاج فجأة إلى تعليمات تشغيلية من نفس المزود في نفس الوقت.
البيانات المالية لم تسجل سوى جزء من التكلفة
تظهر الإفصاحات المالية لـ Rackspace التكلفة المؤسسية للحادثة. حذر تحديث ٦ ديسمبر من أن الحادثة قد تقاطع إيرادات Hosted Exchange وتخلق تكاليف استجابة إضافية. قال إصدار نتائج العام الكامل ٢٠٢٢ إن الشركة سجلت رسوم انخفاض قيمة كبيرة غير نقدية في الربع الرابع ٢٠٢٢، بما في ذلك انخفاض قيمة الشهرة في قطاع التطبيقات والمنصات المشتركة الناجم بشكل أساسي عن انخفاض القيمة السوقية بعد هجوم فدية Hosted Exchange.
قال 10-Q لعام ٢٠٢٣ إن Rackspace سجلت ٥ ملايين دولار من النفقات المتعلقة بحادثة Hosted Exchange للأشهر التسعة المنتهية في ٣٠ سبتمبر ٢٠٢٣، بما في ذلك تكاليف التحقيق والمعالجة والخدمات القانونية والمهنية وموارد الموظفين الإضافيين، مع تسجيل استرداد تأمين متوقع أو مستلم.
تلك الأرقام مهمة، لكنها ليست إجمالي الضرر الذي لحق بالعملاء. الفواتير المفقودة لشركة صغيرة، والمواعيد النهائية الفائتة، وتكاليف الاستشاريين الطارئين، والعمل الإضافي للموظفين، وفقدان العملاء، وتكاليف الخدمة البديلة، وعمل الامتثال لا تظهر بالضرورة في نفقات Rackspace. يمكن أن تقلل حصة المزود من الإيرادات من اعتماد العميل بمقدار درجة من حيث الحجم. منتج يمثل ١ في المائة من إيرادات المزود يمكن أن يمثل ١٠٠ في المائة من البريد الإلكتروني للعميل.
يجب أن يشكل هذا عدم التماثل مساءلة مزود الخدمة. ليست الأهمية المالية للمزود هي نفس الأهمية التشغيلية للعملاء. تجيب إيداعات الأوراق المالية على أسئلة المستثمرين. لا تجيب بشكل كامل على ما إذا كان مكتب محاماة قد فاتته اتصالات مميزة، أو ما إذا كانت عيادة قد أعادت جدولة المواعيد، أو ما إذا كان مقاول قد فقد مراسلات العطاءات، أو ما إذا كان محاسب يمكنه استرداد سجلات العملاء.
تظهر الإيداعات أيضًا بقايا قانونية. قال 10-Q لسبتمبر ٢٠٢٣ إن Rackspace اسميت في عدة دعاوى قضائية تتعلق بحادثة الفدية في ديسمبر ٢٠٢٢، تسعى للحصول على تعويض عادل وتعويضي، وأن Rackspace كانت تدافع بقوة عن القضايا. تلك الدعاوى هي مزاعم، وليست نتائج. لكن وجودها متوقع. العملاء الذين اشتروا بريدًا مُدارًا ثم فقدوا الوصول إلى البريد الإلكتروني ويقين استرداد البيانات سيبحثون عن مساءلة من خلال نظريات العقد أو الضرر أو المستهلك أو خسارة الأعمال.
حدود المقالة الصحيحة حذرة. لا ينبغي أن تعلن أن Rackspace مسؤولة قانونًا ما لم تقرر محكمة ذلك. يمكنها أن تقول إن السجل العام يظهر انقطاع الخدمة، والترحيل القسري، وقيود استرداد البيانات، ونفقات الحادثة، واستردادات التأمين، والدعاوى القضائية، وتوقف المنتج. هذا كافٍ لتحليل الحوكمة دون المبالغة في القانون.
تعرض بيانات العميل كان أصغر من تأثير الانقطاع، لكنه ليس غير ذي صلة
يتم تذكر حادثة Rackspace أحيانًا على أنها فشل في التوفر، لكن التقارير العامة وصفت أيضًا وصول البيانات لمجموعة فرعية من العملاء. ذكرت SecurityWeek في Rackspace يكمل التحقيق في هجوم الفدية أن Rackspace وجدت أن المهاجمين وصلوا إلى ملفات Personal Storage Table لـ ٢٧ عميلاً من بين ما يقرب من ٣٠,٠٠٠ عميل Hosted Exchange، مع الإشارة إلى عدم وجود دليل على سرقة البيانات الفعلية في ذلك الحساب. ذكرت Cybersecurity Dive أن Rackspace أكدت تورط فدية Play وأن المهاجمين استخدموا استغلالًا مرتبطًا بـ CVE-2022-41080، مع تأثر نسبة صغيرة من عملاء Hosted Exchange بالوصول إلى البيانات في تغطيتها في يناير ٢٠٢٣.
يجب أن تعامل المقالة تلك التقارير من طرف ثالث كمفيدة ولكن ثانوية مقارنة بالإصدارات الرسمية لـ Rackspace وإيداعاتها. ركزت إصدارات Rackspace الرئيسية العامة للمستثمرين على الفدية والاحتواء والعزل والترحيل وتأثير الأعمال. لم تنشر تقريرًا جنائيًا كاملًا بنفس الطريقة التي قد تنشرها مدونة بائع تقني. ومع ذلك، فإن إمكانية الوصول إلى أرشيف صندوق البريد تغير نموذج الضرر. يمكن أن تحتوي أرشيفات البريد الإلكتروني على بيانات شخصية ومرفقات وعقود ونماذج ضريبية وتفاصيل صحية ونصائح قانونية وبيانات اعتماد ومعلومات تجارية سرية.
الرقم ٢٧، إذا استخدم، لا يجب أن يقلل من الحادثة. الوصول إلى البيانات لمجموعة فرعية هو قضية خصوصية وسرية لهؤلاء العملاء. عدم توفر الخدمة لآلاف هو قضية استمرارية للسكان الأوسع. كلاهما يمكن أن يكون صحيحًا. العميل الذي تم الوصول إلى PST الخاص به يواجه مخاطر الكشف المحتملة. العميل الذي لم يتم الوصول إلى PST الخاص به قد لا يزال فقد أيامًا أو أسابيع من العمليات.
هذا الانقسام شائع في حالات الفدية. يمكن أن يكون نصف قطر توفر الانفجار أكبر بكثير من نصف قطر تسريب البيانات. غالبًا ما يدمج النقاش العام بينهما في رقم واحد، لكن العملاء يعانون من أضرار مختلفة. يجب أن توفر الاستجابة للحوادث إذن تحديدات خاصة بالعميل: هل توقفت الخدمة، هل تم استرداد بيانات صندوق البريد، هل تم الوصول إلى أي بيانات، ما الفترة المتأثرة، ما السجلات المعنية، ما الإشعارات المطلوبة، وما الأدلة التي تدعم هذه الإجابات؟
بدون أدلة خاصة بالعميل، تترك الشركات لتخمين. التخمين مكلف. يؤدي إلى الإفراط في الإشعار، وقلة الإشعار، وإعادة العمل غير الضرورية، وواجبات تنظيمية فائتة، وعدم ثقة يمكن تجنبه.
أرصدة الخدمة لا تستعيد الاستمرارية
غالبًا ما تتضمن عقود الخدمات المُدارة أرصدة للانقطاعات. يمكن أن تكون الأرصدة مفيدة. كما أنها غير كافية من الناحية الهيكلية لأحداث الاستمرارية الشديدة. إذا فقدت شركة صغيرة الوصول إلى البريد الإلكتروني خلال فترة حرجة، فإن الرصيد ضد رسوم الخدمة المستقبلية لا يستعيد الرسائل الفائتة، أو يعيد بناء ثقة العملاء، أو يسترجع المواعيد النهائية القانونية، أو يدفع العمل الإضافي للموظفين، أو يستبدل تكاليف الاستشارات.
ركزت مواد الحادثة العامة لـ Rackspace وإيداعاتها على دعم الترحيل واسترداد البيانات وتأثير الأعمال بدلاً من تحليل مفصل لأرصدة الخدمة العامة. هذا مناسب لمقالة حادثة لأن القضية الأعمق ليست صيغة الرصيد الدقيقة. إنها عدم التطابق بين سعر الاشتراك وقيمة الاعتماد. قد يتم تسعير البريد المستضاف لكل صندوق بريد شهريًا. يمكن أن يؤثر انقطاعه على تدفقات الإيرادات بأكملها.
هذا عدم التطابق هو السبب في أن عملاء SaaS المهمين يحتاجون إلى تخطيط استمرارية يتجاوز اتفاقية مستوى الخدمة الخاصة بالبائع. يجب أن تعرف الشركات الصغيرة والمتوسطة كيفية الوصول إلى العملاء إذا فشل البريد المستضاف، وكيفية الوصول إلى DNS المجال، وكيفية إعداد صناديق بريد طارئة، وكيفية الحفاظ على سجلات MX القديمة، وكيفية الاتصال بالموظفين خارج البريد الإلكتروني، وكيفية جمع الرسائل المرسلة أثناء الانقطاع، وكيفية تحديد أولويات الاسترداد. يجب على مزودي الخدمات المُدارة الحفاظ على وثائق المستأجر والمجال حتى يتمكنوا من مساعدة العملاء بسرعة. يجب على البائعين توفير أدلة تشغيل الترحيل الطارئ واختبارها.
لكن سيكون من غير العدل وضع كل العبء على الشركات الصغيرة والمتوسطة. يسوق المزود نفسه كخبرة مُدارة. يجب أن يصمم لواقع أن العملاء ليسوا خبراء Exchange. يتضمن ذلك خيارات نسخ احتياطي/تصدير واضحة، وأهداف استرداد شفافة، وعزل فدية مختبر، وقنوات إخطار العملاء مستقلة عن المنتج المتأثر، وحدود بلغة واضحة لما يمكن للمزود استرداده.
الأرصدة هي آلية محاسبية بعد الحادثة. الاستمرارية هي آلية هندسية وحوكمة قبل الحادثة. أظهرت حادثة Rackspace أي واحدة يحتاجها العملاء أكثر.
المنتجات القديمة تحتاج إلى حوكمة صادقة لمخاطر نهاية العمر
كانت Hosted Exchange موجودة في سوق يتحرك نحو Microsoft 365 وخدمات البريد السحابية الأخرى. يمكن أن تظل المنتجات القديمة قيمة للعملاء ذوي التفضيلات المحددة أو هياكل التكلفة أو النماذج الإدارية أو قيود الترحيل. لكن البنية التحتية القديمة يمكن أن تحمل مخاطر متراكمة: بنى أقدم، وتبعيات تصحيح معقدة، وتركيز هندسي أصغر، وحصة إيرادات متقلصة، ورغبة أقل في استثمار كبير في المرونة.
بيان Rackspace اللاحق بأنها أوقفت منصة Hosted Exchange المحلية هو إشارة حوكمة. إذا كان يمكن إيقاف المنتج بعد الحادثة، يحتاج العملاء والمزود على حد سواء إلى التساؤل عما إذا كان يجب أن تكون نهاية العمر قد حدثت في وقت سابق، أو بشكل أكثر تعمدًا، أو بحوافز ترحيل أقوى. ليس ذلك إلقاء لوم بأثر رجعي. إنه السؤال القياسي بعد فشل منتج قديم تحت هجوم نشط.
برنامج نهاية العمر الناضج لا يعلن ببساطة عن التقاعد. إنه يحدد العملاء، ويصنف المخاطر، ويقدم نوافذ ترحيل، ويقدم حوافز مالية، ويختبر أدوات الترحيل، ويوثق تصدير البيانات، ويعالج الاحتياجات التنظيمية، ويدرب طاقم الدعم، وينشئ مسارات تصعيد للعملاء الذين لا يمكنهم التحرك بسرعة. كما يذكر المخاطر المتبقية من البقاء. إذا بقي المنتج القديم متاحًا، قد يفترض العملاء أن المزود لا يزال يستثمر بما يكفي لجعله آمنًا ومرنًا.
توضح حادثة Rackspace لماذا يمكن أن تكون "الإيرادات الصغيرة" خطرة داخل مزود. قد يكون للمنتج الصغير قاعدة عملاء مركزة تعتمد عليه بشدة. قد لا يتلقى نفس استثمار التحديث مثل منتجات النمو. لكن إذا فشل، يمكن أن تتجاوز العواقب السمعة والقانونية خط الإيرادات. المنتج صغير فقط من وجهة نظر محاسبة المزود.
بالنسبة لمجالس الإدارة والمديرين التنفيذيين، هذا درس مخاطر المحفظة. كل منتج قديم يخزن بيانات العملاء ويدير عمليات العملاء يجب أن يكون لديه ملف مرونة ونهاية العمر. ماذا سيحدث إذا توقف لمدة أسبوعين؟ كم عدد العملاء الذين يمكنهم التصدير بأنفسهم؟ كم عدد ليس لديهم بديل؟ ما طاقم الدعم الإضافي المطلوب؟ ماذا سيقول المزود إذا أجبرت الفدية على الإغلاق الفوري؟ إذا كانت تلك الإجابات غير مريحة، فإن التقاعد أو إعادة التصميم ليس عمل استراتيجي اختياري. إنه عمل مساءلة.
مزودو الخدمات المُدارة والشركاء كانوا جزءًا من سلسلة الاسترداد
تستهلك العديد من الشركات الصغيرة البريد المستضاف من خلال وسطاء أو بمساعدة مزودي الخدمات المُدارة. خلال حادثة Rackspace، أصبح مزودو الخدمات المُدارة ومستشارو تكنولوجيا المعلومات مترجمين وفرق ترحيل ومشغلي DNS ومستشارين للعملاء. يعكس النقاش العام في مجتمعات مزودي الخدمات المُدارة ضغط قرار ما إذا كان الانتظار أو الترحيل أو إعادة التوجيه أو التخلي عن الخدمة. هذا النقاش ليس دليلاً أوليًا، لكنه يوضح سلسلة اعتماد حقيقية.
سيطرت Rackspace على المنصة المتأثرة. سيطرت Microsoft على المنصة الوجهة وتحديثات منتج Exchange. سيطر مزودو الخدمات المُدارة على الإدارة المحلية للعميل، والوصول إلى DNS في كثير من الحالات، ودعم الجهاز، وتدريب المستخدم. سيطرة العملاء النهائيين على قرارات العمل والتواصل مع عملائهم. نجاح الاسترداد يعتمد على مدى جودة تنسيق هذه الأطراف.
يخلق الترحيل الطارئ أخطاء صغيرة ذات آثار كبيرة. قد يقوم مزود الخدمة المُدارة بتحديث سجلات MX قبل أن يكون جميع المستخدمين مستعدين. قد ينسى العميل صندوق بريد مشترك. قد يفقد المستخدم البريد المحمول. قد يتم تحميل البريد المؤرشف ببطء. قد تتعطل أذونات التقويم. قد لا تنتقل الإقامة القانونية بشكل نظيف. قد يتم تفويت مجموعة توزيع. قد يتم إعادة استخدام كلمة مرور المستخدم القديمة. لا شيء من هذه الأخطاء هو حادثة الفدية الأصلية، لكن جميعها عواقب الحادثة.
لهذا السبب يجب على المزودين المُدارين معاملة الشركاء كجماهير من الدرجة الأولى للحوادث. يحتاج مزودو الخدمات المُدارة إلى أدلة تشغيل فنية، وحالة جماعية للعملاء، وجهات اتصال إدارية موثقة، وإرشادات DNS، ونصوص ترحيل، وتعليمات استرداد الأرشيف، وجهات اتصال تصعيد. إذا تواصل المزود فقط مع مالكي الحسابات الفردية، يصبح نظام الشركاء قناة شائعات. إذا جهز الشركاء جيدًا، يصبح نظام الشركاء مضاعفًا للاسترداد.
تذكر إصدارات Rackspace العامة Microsoft Fast Track وطاقم الدعم الإضافي. كان ذلك علامة على حجم العمل. يجب أن تذهب الحوادث المستقبلية إلى أبعد من ذلك من خلال تحديد أدوار الشركاء مسبقًا ومسارات التفويض الطارئ. في انقطاع البريد، قد يكون الطرف الذي يمكنه تغيير DNS وتكوين المستأجر الوجهة أكثر أهمية من مالك العقد الاسمي.
خريطة المساءلة مشتركة، لكنها ليست متساوية
التوزيع الأنظف طبقي. كانت الجهات الإجرامية مسؤولة عن النشاط الخبيث. كانت Microsoft مسؤولة عن تحديثات أمان منتج Exchange، وإرشادات الثغرات، والهندسة الأمنية لـ Exchange و Exchange Online. كانت Rackspace مسؤولة عن بيئة Hosted Exchange التي تديرها، بما في ذلك التصحيح، والتخفيفات، وإدارة التعرض، والمراقبة، والتجزئة، والنسخ الاحتياطي والاستعادة، وتواصل العملاء، ودعم الترحيل، واسترداد البيانات، واستراتيجية المنتج. كان العملاء مسؤولين عن تخطيط الاستمرارية الخاص بهم، والوصول إلى المجال، وتكوين نقطة النهاية، وتواصل المستخدم، وحوكمة ما بعد الترحيل. كان مزودو الخدمات المُدارة والشركاء مسؤولين عن التنفيذ المحلي حيث اعتمد عليهم العملاء.
تلك المسؤوليات مشتركة لكنها ليست متساوية. اشترى العملاء بريدًا مُدارًا لأنهم لم يسيطروا على خوادم Exchange. سيطرت Rackspace على البيئة التي فشلت وعملية الاسترداد التي تلت ذلك. لا يعني ذلك أن Rackspace تسببت في الفدية. يعني أن المزود كان يمسك بالرافعات العملية للوقاية والاحتواء والاستعادة والأدلة.
تظهر الحادثة أيضًا لماذا لا يمكن قياس مساءلة السحابة فقط بوقت التشغيل بعد الترحيل. العميل الذي يستعيد بريدًا جديدًا لكنه يفقد بيانات التقويم القديمة، وينتظر أسابيع للأرشيفات، ولا يمكنه إثبات ما إذا تم الوصول إلى البيانات، أو يضطر لدفع مستشارين طارئين لم يتم تعويضه بالكامل. للاسترداد حالات متعددة: تدفق البريد، وتاريخ صندوق البريد، واستمرارية التقويم، وسلامة الأرشيف، وأجهزة المستخدم، والوضع الأمني، والأدلة القانونية، وثقة العميل.
احتوى رد Rackspace على عناصر جيدة: الاحتواء، والمشاركة في الدفاع السيبراني، والإفصاحات العامة للمستثمرين، ودعم الترحيل إلى Microsoft 365، وتعزيز الدعم، وتحديثات الحالة، وتدفقات عمل استرداد البيانات. يظهر السجل العام أيضًا حدودًا صارمة: انقطاع خدمة شديد، وترحيل طارئ، وقيود استرداد البيانات التاريخية، وتوقف المنتج، ودعاوى قضائية، وتكاليف، وعدم يقين متبقي للعملاء. كلا الجانبين ينتميان إلى التقييم.
الدرس الأوسع لأي مزود سحابي مُدار غير مريح. إذا كنت تدير منصة قديمة للشركات الصغيرة، فأنت تملك أكثر من الخوادم. أنت تملك خيارات الاستمرارية للعميل عندما لا يمكن الوثوق بخوادمك. يجب أن تكون هذه الملكية مرئية في الهندسة المعمارية قبل الهجوم: نسخ احتياطية مختبرة، وصادرات الخدمة الذاتية، و RTO/RPO واضحين، وأدوات ترحيل طارئة، وأدلة تشغيل للشركاء، وحزم أدلة، وتخطيط نهاية عمر صادق.
ما الذي يجب أن يتغير بعد Rackspace
بالنسبة للعملاء، تدعو حادثة Rackspace إلى ضوابط استمرارية أساسية ولكن غالبًا ما يتم إهمالها. امتلك مسجل المجال وبيانات اعتماد DNS. احتفظ بقائمة حالية من صناديق البريد والأسماء المستعارة ومجموعات التوزيع وصناديق البريد المشتركة والمسؤولين. اعرف من يمكنه تغيير سجلات MX. حافظ على قائمة اتصال خارج النطاق للموظفين والعملاء المهمين. قم بتصدير أو أرشفة البريد الإلكتروني الحرج وفقًا للمتطلبات القانونية والتجارية. اختبر إعداد البريد الطارئ. احتفظ بعقود البائعين وجهات اتصال الدعم خارج صندوق البريد المتأثر. اسأل المزودين عما يحدث إذا تم إيقاف منصة البريد المستضافة الخاصة بهم لأسباب أمنية.
بالنسبة للمزودين، الدرس أكثر تطلبًا. لا تبيع خدمات مُدارة قديمة بدون قصة فشل موثوقة. إذا أجبرت الفدية على الإغلاق، كيف يحصل العملاء على تدفق البريد في غضون ساعات؟ كيف يحصلون على البريد القديم في غضون أيام؟ كيف يعرفون ما إذا تم الوصول إلى البيانات؟ كيف يفي العملاء المنظمون بواجبات الإخطار؟ كيف يتلقى الشركاء تعليمات جماعية؟ كيف يتم تمويل تعزيز الدعم وتزويده بالعمالة؟ كيف تتعلق أرصدة الخدمة بالتزامات الاسترداد الفعلية؟ أي العملاء لا يزالون على المنصة لأن الترحيل صعب، وما هي الخطة لمساعدتهم على المغادرة بأمان؟
بالنسبة لبائعي البرامج، خاصة Microsoft في هذا السياق، يجب أن تفترض إرشادات الثغرات أن العملاء يشملون مزودين مُدارين يديرون ممتلكات Exchange كبيرة متعددة المستأجرين أو متعددة العملاء. الإرشادات التي تعمل لمؤسسة واحدة قد لا تكون بسيطة تشغيليًا لمزود لديه العديد من تبعيات العملاء. بيانات قابلية الاستغلال الواضحة، وأولوية التصحيح، وحدود التخفيف، وإرشادات الكشف مهمة لأن العملاء النهائيين لا يمكنهم رؤية الخوادم الضعيفة.
بالنسبة للجهات التنظيمية والمحاكم، تثير الحادثة سؤالًا مألوفًا: كيف يجب أن تقيم الأنظمة القانونية مزودًا يكون منتجه المتأثر صغيرًا ماليًا لكنه حيوي للعملاء؟ يمكن للأطر التقليدية للأهمية المادية والأضرار أن تكافح مع الضرر الموزع للمؤسسات الصغيرة والمتوسطة. من الصعب تجميع آلاف الخسائر الصغيرة وتوثيقها وتقاضيها، ومع ذلك يمكن أن تمثل اضطرابًا اقتصاديًا ومدنيًا حقيقيًا.
أصبح Rackspace Hosted Exchange سجلًا تحذيريًا لأنه ضغط هذه الأسئلة في حدث واحد. توقفت خدمة مُدارة. كان على العملاء الترحيل. كان استرداد البيانات التاريخية مرحليًا ومحدودًا. انتهى منتج قديم. تبعتها دعاوى قضائية. ظهرت النفقات واستردادات التأمين في الإيداعات. نجا المزود، لكن العملاء تعلموا أن "المستضاف" لا يعني "قابل للاسترداد بشروطي".
يجب أن يكون معيار المساءلة بعد Rackspace بسيطًا: إذا كان مزود السحابة هو الطرف الوحيد الذي يمكنه استعادة سجل العمليات للعميل، فإن المزود يدين بأكثر من وعود وقت التشغيل العادية. إنه مدين باستمرارية مختبرة، وأدلة محمولة، واتصالات واضحة، ومسار خروج يعمل قبل اليوم الذي يحتاجه العملاء بشدة.