الخلاصة
- قالت IBM في إخطار محفوظ إن معلومات توجيه غير صحيحة بكميات كبيرة سببت ازدحامًا شديدًا، أي حالة تعجز فيها قدرة الشبكة على معالجة الحركة عن مجاراة الطلب. وبادئة الشبكة هي نطاق من عناوين الإنترنت يُعامل كوحدة واحدة عند التوجيه؛ فإذا اختلت المعلومات عنها تراجعت قابلية الوصول، أي قدرة المستخدم أو الخدمة على بلوغ الوجهة المطلوبة فعليًا.
- عند تعطل المسار الرئيسي، يصبح مستوى الإدارة، أي مجموعة وظائف المراقبة والتهيئة والاستعادة التي يستخدمها المشغّلون، حاسمًا. ويعني الوصول خارج النطاق وإيصال معلومات الحالة وجود وسيلة مستقلة عن مسار الإنتاج تتيح التحكم وإبلاغ المعنيين بما يحدث؛ أما نطاق الأثر فهو اتساع الخدمات والمستخدمين الذين تمتد إليهم نتيجة عطل واحد، لا مجرد عدد الأجهزة التي أطلقت إنذارًا.
- لا تنتهي المساءلة عند قول إن السبب جاء من طرف خارجي. فملكية التحكم تعني تحديد الجهة التي تملك فعلًا سلطة قبول المسارات أو رفضها، وضبط الإنذارات، وعزل الخلل، واستعادة الخدمة. والقياسات التشغيلية، أو بيانات الرصد التي تنتجها الأجهزة والخدمات، لا تفيد إلا إذا أمكن ربطها بقرار واضح وزمن واضح على جانبي الحدّ بين المزوّدين.
ما الذي تُثبته السجلات العامة؟
أفادت تغطية TechCrunch المعاصرة للحادثة بأن اضطرابًا واسعًا في شبكة IBM Cloud صار ظاهرًا قرابة الساعة 14:30 بتوقيت المحيط الهادئ في 9 يونيو 2020. تأثرت خدمات مستضافة، وأعادت صفحة الحالة الرئيسية لدى IBM خطأً داخليًا في الخادم بدلًا من معلومات الحالة التي كان العملاء يحتاجونها.
لا يعني هذا التوقيت أن كل منطقة أو منتج أو عميل بدأ يعاني في اللحظة نفسها. ولا تحتوي المواد العامة على ساعة موحّدة لبداية الانقطاع ونهايته عالميًا. لذلك لا يجوز اختصار تجارب متباينة ومراحل استعادة مختلفة في مدة واحدة تُنسب إلى الجميع.
حفظت تقارير The Register وCRN شرح IBM الذي قال إن مزوّد شبكة خارجيًا أرسل كمية كبيرة من معلومات التوجيه غير الصحيحة إلى IBM Cloud، ما أدى إلى ازدحام شديد وأثر في خدمات سحابية ومراكز بيانات. هذا إسناد صادر عن IBM؛ وليس نتيجة فحص مستقل لسجلات موجّهات خاصة أو لتهيئة منشورة كاملة.
وقالت IBM أيضًا إن الخدمات أُعيدت، وإنها اتخذت خطوات للتخفيف، وإن عملها على تحديد السبب لم يكشف عن فقدان بيانات أو مشكلات في الأمن السيبراني. تظل هذه النتيجة السلبية مقيدة بنطاق فحص IBM وتصريحها، ولا تعادل تدقيقًا مستقلًا في حالة كل عميل أو كل معاملة.
كيف تتحول معلومات المسار إلى أثر في الخدمة؟
تتبادل الشبكات عبر BGP إعلانات المسارات التي تصف البادئات التي يمكن الوصول إليها من كل جار. ثم يطبق كل مشغّل سياسة التوجيه، أي القواعد التي تحدد أي مسار يُقبل، وأي مسار يُفضّل، وأي معلومات يعاد إعلانها إلى شبكات أخرى.
إذا وصلت معلومات كثيرة وغير صحيحة، فقد تستهلك معالجة المسارات موارد الجهاز، وقد تدفع الحركة نفسها نحو وجهات لا تؤدي إلى الخدمة المقصودة. ذكرت Zello في تقريرها اللاحق أن عددًا كبيرًا من المسارات المحقونة أدى إلى إرسال خوادمها في IBM Cloud حركة IPv4 الصادرة نحو وجهات خاطئة. وIPv4 هو الإصدار الرابع من بروتوكول الإنترنت، ويستخدم عناوين بطول 32 بت للتعريف بوجهات الاتصال.
بعد تغيير معلومات المسار، تحتاج الشبكات إلى وقت كي تستقبل التحديثات وتعيد الاختيار وتستقر على حالة متسقة. تسمى هذه العملية تقارب المسارات. وقد تستعيد مجموعة من المستخدمين الوصول قبل أخرى، أو يعود تطبيق بينما تظل أداة إدارية غير متاحة، لذلك تبدو الاستعادة تدريجية لا لحظة واحدة.
لكن السجل العام لا يحدد النظام المستقل الذي بدأ منه الإعلان، ولا البادئات أو خصائص المسار أو الجلسات أو شيفرة السياسة التي شاركت في الحادثة. والنظام المستقل هو مجموعة شبكات تديرها جهة تشغيل واحدة، وخصائص المسار بيانات إضافية تؤثر في اختياره، أما الجلسة فهي صلة تبادل معلومات التوجيه بين جهازين. لا تسمح عبارة «كمية كبيرة» باستنتاج جدول الإنترنت الكامل أو قيمة إعداد بعينها.
ما الذي أضافته ملاحظات العميل؟
سجلت Zello إخفاقات واسعة في تسجيل الدخول وإعادة الاتصال، وانقطاع التواصل حتى لدى مستخدمين كانوا متصلين بالفعل، وتعذر الوصول إلى لوحات الإدارة، كما تأثرت أربع خدمات. تقدم هذه الملاحظات صورة من جهة التطبيق، لا من داخل شبكة IBM وحدها.
وتبيّن تلك الصورة أن المشكلة قد تمس قابلية استخدام الخدمة وقدرة المشغّل على إدارتها في آن واحد. فإذا تعطلت لوحة الإدارة وصفحة الحالة مع مسار البيانات، لا يفقد العميل الاتصال فحسب، بل يفقد أيضًا وسيلة معرفة ما يحدث واتخاذ قرار بشأن الاستمرارية.
مع ذلك، لا تمثل Zello كل عملاء IBM Cloud. ولا تثبت سجلاتها عدد المعاملات الفاشلة في المنصة كلها، أو الخسائر المالية، أو كل المناطق المتأثرة. وتكمن قيمتها في أنها ملاحظة مباشرة ومحددة، لا في أنها أساس لتقدير أثر عالمي لم تُنشر له قاعدة قياس كاملة.
ونقلت CRN فقدان الوصول إلى البيئات ولوحات التحكم وشاشات الحالة، كما نقلت أن عمليات شبكة IBM عدّلت سياسات التوجيه أثناء الاستعادة. يشير ذلك إلى استعادة متعددة المراحل، لكنه لا يكشف التغييرات الدقيقة أو من وافق عليها أو أثر كل تغيير على كل مجموعة من العملاء.
حدّ المزوّد لا ينبغي أن يصبح فراغًا في المسؤولية
حتى إذا صح إسناد IBM إلى المزوّد الخارجي، لا تختفي مسؤوليات IBM التشغيلية. فمن نطاق سيطرتها قبول المسارات الواردة، ووضع حواجز لها، وضبط الإنذارات، واتخاذ قرار العزل، والحفاظ على وسائل إدارة وإبلاغ مستقلة، وقياس تعافي العملاء، والاحتفاظ بسجل يتيح شرح القرارات لاحقًا.
أما المزوّد الخارجي فيستطيع التحقق مما يعلنه إلى الخارج، وسحب المعلومات الخاطئة بسرعة، وتنبيه الطرف الآخر إلى السلوك غير المتوقع. ولا تكشف المواد العامة كيف وزعت العقود واجبات التصفية والإنذار والسحب والإصلاح بين الطرفين. يجب لذلك فصل القدرة التقنية على الفعل عن الالتزام التعاقدي الذي لا نراه.
يتطلب تحليل ملكية التحكم صيغة بسيطة: من فعل ماذا، تجاه أي نظام أو معلومة، وبأي دليل؟ من كان يستطيع رفض مسار وارد؟ من كان يستطيع وقف إعلان خاطئ؟ من كان يستطيع إبقاء صفحة الحالة متاحة؟ التركيز على الصلاحيات والتهيئة العاملة أدق من الاكتفاء باسم الشركة الوارد في العقد.
ويعني الحد الأقصى لعدد البادئات وضع سقف لعدد بادئات الشبكات التي يقبلها جهاز من جار بعينه، بحيث يصدر تنبيهًا عند زيادة غير متوقعة أو يوقف قبول المزيد منها وفق السياسة. يصف RFC 7454 سياسات الحدود، وتصفية البادئات الواردة والصادرة، وحدودًا مخصصة لكل نظير بوصفها إرشادات تشغيلية عامة.
لكن RFC 7454 لا يثبت إعداد IBM أو إعداد المزوّد الخارجي في عام 2020. لا نعرف هل كان حدّ البادئات مطبقًا، وما قيمته، وهل كان تجاوزه يطلق إنذارًا فقط أم يقطع الجلسة. والإرشاد العام ليس ضمانًا لمنع الحادثة ولا دليلًا على تهيئة خاصة لم تُنشر.
الإدارة والإبلاغ أثناء اضطراب المسار
إذا اعتمد مستوى الإدارة على المسار نفسه الذي تأثر، فقد يفقد المشغّل القدرة على المراقبة والتغيير والاستعادة في الوقت الذي يحتاجها فيه أكثر. ولا يقتصر الوصول خارج النطاق وإيصال معلومات الحالة على توفير شاشة ثانية؛ بل يتطلبان وسيلة للتحكم والإبلاغ لا تشترك مع المسار الرئيسي في سبب الفشل نفسه.
وتشمل الاستقلالية التحقق من المصادقة، وتحويل أسماء الخدمات إلى عناوين اتصال، وربط الشبكة، وتوزيع معلومات الحالة. فإذا بدت الأدوات منفصلة لكنها تعتمد على نظام الأسماء أو الاتصال ذاته، فقد تتوقف معًا. ولا تكشف المعلومات العامة تصميم IBM الداخلي، لذلك لا يمكن الادعاء بأنها فصلت هذه الاعتماديات أو لم تفصلها.
قد تشمل القياسات التشغيلية عدد المسارات الواردة، وسرعة التحديث، وحمل الأجهزة، واختبارات قابلية الوصول، وإخفاقات التطبيقات لدى العملاء. المهم ليس جمع الأرقام فقط، بل القدرة على ربط بداية التغير بالطرف الذي رصده، وبالإجراء الذي اتخذه، وبالنتيجة التي ظهرت للعميل.
ولا يقاس نطاق الأثر بعدد المناطق أو أسماء المنتجات وحدها. يمكن لتعطل أدوات الإدارة أو قنوات إيصال معلومات الحالة أن يؤخر الاستعادة وقرارات العملاء حتى عندما يكون أثر البيانات متفاوتًا. كما أن عودة بعض المسارات أولًا لا تكفي لإعلان استعادة عامة إذا بقيت وظائف أخرى غير متاحة.
لماذا لا يصح وصف الحادثة بأنها هجوم؟
وجود كمية كبيرة من معلومات التوجيه لا يثبت نية خبيثة. أما هجوم حجب الخدمة الموزّع (DDoS) فهو فعل متعمد تستخدم فيه مصادر عديدة لإغراق خدمة أو استنزاف قدرتها، لكن السجلات المتاحة لا تثبت أن حادثة IBM كانت من هذا النوع، أو أنها كانت اختطافًا للمسارات أو تخريبًا أو اختراقًا سيبرانيًا.
قالت IBM إن فحصها لم يحدد مشكلة في الأمن السيبراني. يبقى ذلك تصريحًا منسوبًا ومحدودًا بهذه الحادثة، وليس برهانًا شاملًا على أن أي خطر أمني كان مستحيلًا. إضافة قصة هجوم بلا دليل تشتت الانتباه عن الأسئلة القابلة للفحص: معلومات المسار، والحواجز، والإنذارات، وسلطة التغيير.
كيف نقرأ الاستعادة والتخفيف؟
أعلنت IBM استعادة الخدمات واتخاذ خطوات للتخفيف، ونقلت CRN تعديل سياسات التوجيه أثناء التعافي. تثبت هذه العبارات أفعالًا تاريخية أُبلغ عنها، لكنها لا تثبت أن الإجراءات ما زالت مطبقة الآن أو أنها اختُبرت بصورة مستقلة أو أنها تمنع تكرار الاضطراب.
يحتاج تقييم الاستعادة إلى فصل عودة مسارات البيانات عن عودة لوحات الإدارة وصفحة الحالة ووظائف العملاء. ولا يقدم السجل العام خطًا زمنيًا كاملًا لكل ذلك، لذلك لا يصح إنشاء لحظة عالمية موحدة للاستعادة أو مدة مشتركة لكل العملاء.
ولتقييم التخفيف اليوم، نحتاج إلى معرفة مدى تنفيذ الإجراءات ونطاقها، واختبارات الفشل، ونتائج التحقق المستقل، وآلية المراقبة المستمرة، وما إذا كانت الحدود بين المشغّلين تُختبر معًا. هذه التفاصيل غير منشورة. ينبغي نقل ما أُعلن عن الإجراءات التاريخية بدقة من دون اعتباره تأكيدًا لمتانة الوضع الحالي.
ما الذي لا يزال مجهولًا؟
لا نعرف اسم مزوّد الشبكة الخارجي، أو النظام المستقل المصدر، أو البادئات، أو مسارات العبور، أو خصائصها، أو جلسات BGP، أو شيفرة السياسة التي كانت تعمل. تسمية شركة أو إعداد على سبيل التخمين ستتجاوز ما تسمح به الأدلة.
ولا نعرف الكيان التعاقدي الدقيق أو توزيع واجبات التصفية والإنذار والسحب وإبلاغ العملاء. فالسيطرة التقنية والعقد ليسا الشيء نفسه، ولا يمكن استخلاص أحدهما من الآخر من المواد العامة وحدها.
كذلك لا توجد حصيلة كاملة للعملاء أو المناطق أو المعاملات أو الخسائر. ولا تُظهر المصادر بنية IBM الخاصة، أو إنذاراتها الداخلية، أو مالك قرار بعينه، أو تصميم مستوى الإدارة لديها.
ولا نعرف مقدار تنفيذ إجراءات التخفيف، أو نطاقها، أو تحقق طرف مستقل منها، أو فعاليتها الحالية. ولا تثبت المواد العامة إهمالًا أو مخالفة تنظيمية أو نتيجة لعقد مستوى خدمة أو تعويضات أو سلوكًا جنائيًا أو مسؤولية فردية.
أسئلة عملية لقياس المساءلة
أولًا، هل كانت شروط قبول المسارات ورفضها محددة عند كل حد، وهل طابقت الوثائق التهيئة العاملة؟ الشبكة تتصرف وفق الشيفرة والإعداد الجاريين، لا وفق النوايا المكتوبة فقط.
ثانيًا، هل استطاعت الفرق اكتشاف الزيادة غير الطبيعية أو تراجع قابلية الوصول قبل وصول شكاوى العملاء؟ لا يكفي أن يصدر إنذار؛ يجب معرفة من استلمه، وماذا كان يستطيع أن يفعل، وكيف تحقق من أثر قراره.
ثالثًا، هل ظل التحكم والإبلاغ متاحين عندما اضطرب المسار الرئيسي؟ إذا فقد العميل لوحة الإدارة وصفحة الحالة مع الخدمة، يمتد الضرر إلى قرار الاستمرارية وإلى سرعة التعافي.
رابعًا، هل استطاعت IBM والمزوّد الخارجي بناء خط زمني واحد من قياساتهما؟ وجود سجلات على الجانبين لا يكفي إذا تعذر ربط الوقت والمسار والبادئة والقرار والنتيجة.
خامسًا، هل اختُبرت إجراءات التخفيف في سيناريو يتضمن زيادة غير متوقعة في المسارات، واستعادة تدريجية، وفقدان وسائل الإدارة؟ لا تقدم المواد العامة جوابًا، ولذلك يكون طلب طريقة التحقق أكثر دقة من قبول وعد عام بعدم التكرار.
النص العام للصورة
النص البديل: صورة مفاهيمية غير موسومة بعلامة تجارية تُظهر نقطة اتصال عند حافة شبكة سحابية، مع أجهزة توجيه ولوحات توصيل ألياف ضوئية داخل غرفة عمليات هادئة.
التعليق: صورة تحريرية مفاهيمية؛ لا تمثل IBM أو مزوّد الشبكة الخارجي غير المسمّى أو منشأة حقيقية أو حادثة عام 2020 نفسها، ولا تعرض بنية شبكة موثقة أو دليلًا على مسار بعينه.
المصادر
- https://www.theregister.com/2020/06/11/ibm_blames_external_network_provider/
- https://techcrunch.com/2020/06/09/ibm-cloud-suffers-prolonged-outage/
- https://www.crn.com/news/cloud/ibm-blames-massive-cloud-outage-on-third-party-network-provider
- https://status.zellowork.com/issues/5ef227ab4a0ebd6da0cb113e
- https://www.rfc-editor.org/rfc/rfc7454.html
- https://btw.media/en/directory/international-business-machines-corporation-united-states-of-america-the
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
