ملخص
- قال تحديث Akamai بتاريخ 17 يونيو 2021 إن حادثة خدمة Prolexic Routed 3.0 أثرت على جزء من العملاء الذين يستخدمون خدمة تخفيف هجمات DDoS الموجهة، مع بدء التنبيه في الساعة 8:47 صباحًا بالتوقيت الشرقي وإعادة توجيه حركة مرور العملاء تلقائيًا أو يدويًا حتى الاستعادة.
- المسألة المسؤولة هي التخفيف المفوض. يرسل العميل حركة المرور عبر خدمة التنظيف للبقاء على قيد الحياة هجمات DDoS، ولكن هذا المسار يصبح اعتمادًا على استمرارية الأعمال عندما يفشل التحقق من الصحة أو حالة التوجيه داخل موفر التخفيف.
- قالت Akamai إن الحادثة لم تكن ناتجة عن تحديث للنظام أو هجوم إلكتروني وأشارت إلى تجاوز قيمة جدول توجيه عن غير قصد. وهذا يضيق نطاق التحليل إلى التحقق التشغيلي من المسار، وضوابط السعة/الحالة، وإعادة التوجيه، واستعادة العميل.
- سجل القياس الخارجي لـ ThousandEyes مهم لأنه أظهر تأثيرًا متفاوتًا على العملاء وقيمة خطط النسخ الاحتياطي. يجب الحكم على حادثة تخفيف موجهة من خلال ما إذا كان بإمكان العملاء تجاوز حركة المرور أو إعادتها بأمان عندما يكون مسار الدفاع معطلاً.
- يجب أن تغطي أدلة الإصلاح الدائمة حواجز حماية جدول التوجيه، والتجاوز المسبق التحقق، وإشعار العميل، ونطاق إعادة التوجيه التلقائي، وسعة الدعم اليدوي، وسلامة إعادة حركة المرور، وإثبات أن مسار التخفيف لا يمكن أن يصبح انقطاعًا أكبر من الهجوم الذي يهدف إلى امتصاصه.
التخفيف المفوض يغير من يتحكم في الاستمرارية
تحديث Akamai العام، تقدم Akamai تحديثًا حول تأثير خدمة Prolexic DDoS، هو سجل الحادثة الأساسي. قالت الشركة إن Prolexic Routed 3.0 شهد حادثة خدمة أثرت على جزء من العملاء. وقالت إن التنبيهات بدأت في الساعة 8:47 صباحًا بالتوقيت الشرقي، وتم إعادة توجيه حركة مرور العملاء المتأثرين تلقائيًا أو يدويًا بواسطة فرق Akamai، وتم استعادة الخدمات في الساعة 12:47 مساءً بالتوقيت الشرقي. كما قالت إن الحادثة لم تكن ناتجة عن تحديث للنظام أو هجوم إلكتروني وأن المشكلة كانت تجاوز قيمة جدول توجيه عن غير قصد.
هذا البيان يجعل سؤال المساءلة دقيقًا. النقطة ليست ما إذا كانت Akamai تحت الهجوم. النقطة هي كيف تتحكم خدمة الحماية في مسار حركة مرور العميل وكيف يمكن للعملاء الهروب من هذا المسار عندما يفشل. تخفيف DDoS ليس مجرد ميزة أمان إضافية. في النموذج الموجه، يمكن أن يصبح جزءًا من طوبولوجيا الشبكة الحية للعميل.
تصف مواد Akamai الخاصة بـ Prolexic الخدمة بأنها حماية DDoS للبنية التحتية. توضح صفحة منتج Prolexic، و صفحة موجز منتج Prolexic، و ملف PDF لموجز منتج Prolexic الغرض الدفاعي: امتصاص حركة المرور الخبيثة وفحصها وتخفيفها قبل وصولها إلى أصول العميل. لا ينبغي معالجة لغة المنتج اللاحقة/الحالية كنتيجة لحادثة 2021، لكنها توضح نموذج الخدمة الذي يخلق التبعية.
من السهل فهم التبعية بشكل خاطئ. قد يعتقد العميل أن تخفيف DDoS هو درع يوضع أمام الخدمة. التصميم الموجه هو أكثر من درع. إنه يغير كيفية وصول حركة المرور إلى العميل. إذا تم الإعلان عن حركة المرور أو إعادة توجيهها عبر مراكز التنظيف، فإن حالة المسار، وأنفاق GRE، والاتصالات المباشرة، ومسارات العودة، وعمليات المزود تصبح جزءًا من التوفر. عندما يفشل مسار الحماية، قد يحتاج العميل إلى مسار تجاوز تم تصميمه وتفويضه واختباره وفهمه مسبقًا.
كلمة "تجاوز" محورية. التجاوز ليس ارتجالًا مذعورًا بعد تلف خدمة الحماية. إنها طريقة مخططة مسبقًا لإعادة حركة المرور إلى مسار آمن مع موازنة خطر أن يواجه العميل مرة أخرى حركة مرور عدائية. لا يريد العميل إزالة الحماية بشكل عرضي أثناء الهجوم. لكن أثناء انقطاع مزود التخفيف، قد يحتاج العميل إلى الاختيار بين الاستمرار عبر مسار دفاع فاشل وكشف أصل من خلال مسار احتياطي. يجب تصميم هذا القرار قبل الحادثة.
الحماية الموجهة تحول التحقق من المسار إلى رعاية العملاء
تعتبر مواد وصف خدمة Akamai مهمة لأنها تظهر كيف يعتمد التخفيف الموجه على آليات التحكم في الشبكة. يصف ملف PDF لوصف خدمات Akamai Prolexic Routed من حيث توجيه BGP لحركة المرور إلى مراكز تنظيف Akamai. يناقش مدونة Akamai حول Prolexic و Equinix Cloud Exchange جلب دفاع DDoS أقرب إلى أصل العميل من خلال الترابط. هذه المواد ليست تقارير ما بعد الانقطاع، لكنها تشرح لماذا التحكم في التوجيه هو الخدمة.
يتم تعريف BGP نفسه في RFC 4271. يتم تعريف GRE، الذي غالبًا ما يكون جزءًا من عودة حركة المرور أو تصميم النفق في بنيات التخفيف، في RFC 2784. لا تقول هذه المعايير ما فعلته Akamai بشكل خاطئ أو صحيح في عام 2021. إنها توضح المفردات التقنية: إعلانات المسار، ومسارات حركة المرور، والأنفاق، وآليات العودة ليست تفاصيل خلفية. إنها سطح المنتج.
إذا تم تجاوز قيمة جدول توجيه المزود، يحتاج العملاء إلى معرفة ما يعنيه ذلك لحركة مرورهم. هل أثرت الحالة المتأثرة على برمجة المسار الجديدة؟ هل أضعفت حركة مرور العودة؟ هل أثرت فقط على عملاء معينين، أو بادئات معينة، أو مناطق معينة، أو علاقات توجيه معينة؟ كان بيان Akamai العام موجزًا، لذا لا ينبغي للتحليل المسؤول اختراع تفاصيل. لكن الإيجاز نفسه يحدد سؤال الإصلاح: ما هي حواجز الحماية التي تمنع الآن تحكم التوجيه المخفف من تجاوز قيمة حالة بطريقة تؤثر على توفر العميل؟
التحقق من المسار في هذا السياق هو رعاية العملاء. إنه ليس مجرد فحص هندسة شبكة داخلي. تحقق المزود يحمي إيرادات العميل، والبوابات العامة، وواجهات برمجة التطبيقات، والوصول إلى البنوك، وتطبيقات SaaS، والخدمات المواجهة للطوارئ. يؤدي فشل التحقق إلى تحويل العمل إلى فرق عمليات العميل، التي يجب أن تحدد ما إذا كانت ستنتظر، أو تعيد التوجيه، أو تتجاوز، أو تتواصل مع المستخدمين، أو تصعد عبر الدعم.
يقدم RFC 7454، عمليات BGP والأمان، توقعات عامة للأمان التشغيلي حول سياسة المسار والتصفية والنظافة التشغيلية. توفر إجراءات مشغل الشبكة MANRS إجراءات مشغل الشبكة و تأمين توجيه الإنترنت من CISA إطارًا عامًا ومجتمعيًا لانضباط المسار. هذه مراجع عامة، وليست نتائج خاصة بالحادثة. إنها مهمة لأن خدمات التخفيف الموجه تضع انضباط مسار المشغل مباشرة في استمرارية العميل.
ملاحظة حول التنضيد
القياسات الخارجية تظهر تأثيرًا متفاوتًا
تحليل ThousandEyes لـ انقطاع Akamai Prolexic Routed قيم لأنه ينظر من خارج المزود. لاحظت اختلافات في الوصول، وسلوكًا متعلقًا بالتوصيل البيني، وتباينًا بين العملاء. أدرجت ThousandEyes لاحقًا الحدث في سبعة انقطاعات هزت عام 2021، مؤكدة أن بعض المؤسسات التي لديها خطط احتياطية معدة كانت قادرة على تقليل التأثير. هذا بالضبط درس المساءلة: إخفاقات التخفيف الموجه ليست فقط إخفاقات المزود؛ إنها اختبارات لاستعداد العميل للتجاوز وإعادة التوجيه المدعومة من المزود.
لا ينبغي أن يصبح وجود تأثير متفاوت إلقاء اللوم على الضحية. يشتري العملاء تخفيف DDoS لأنهم يريدون مزودًا متخصصًا لامتصاص مشكلة لا يمكنهم التعامل معها بأمان بمفردهم. إذا فشل مسار الخدمة، يظل المزود مسؤولاً عن سلامة المسار، وإشعار الحالة، وإعادة التوجيه التلقائي، وسعة الدعم، والإصلاح بعد الحادثة. في الوقت نفسه، يحتاج العملاء الذين لديهم خدمات عامة حرجة إلى تصميمات تجاوز وتراجع مختبرة لأنه لا يوجد مسار حماية محصن من الفشل.
التقارير الثانوية، بما في ذلك تقرير SecurityWeek Akamai يلقي باللوم في الانقطاع على خدمة حماية DDoS و iTnews خطأ توجيه Akamai تسبب في انقطاعات واسعة النطاق، وصفت الاضطرابات المرئية التي أثرت على الخدمات العامة. يمكن أن توضح هذه التقارير النطاق، لكن لا ينبغي استخدامها للادعاء بمدة موحدة أو وضع استعادة متطابق لكل منظمة. يؤثر التخفيف الموجه على العملاء بشكل مختلف اعتمادًا على البادئات وشركاء التوجيه وخطط التجاوز وتصميم التطبيق وسرعة الاتصال.
تظهر أدلة القياس أيضًا سبب ضرورة رؤية المسار العام. قد يكون موقع العميل على الويب أو واجهة برمجة التطبيقات غير متاحة حتى لو كانت خوادم المصدر سليمة. يرى المستخدم التطبيق معطلاً. قد لا يرى العميل مشكلة واضحة في المصدر. قد يقوم المزود بإعادة التوجيه. يمكن للمسابير الخارجية إظهار أين تفشل حركة المرور أو تعود. بدون هذه الرؤية، يضيع المستجيبون الوقت في تصحيح الطبقة الخاطئة.
بالنسبة للمزودين، الدرس هو أن الاتصال العام بعد الحادثة يجب أن يتضمن هيكل توجيه وتأثير على العملاء كافٍ لجعل القياس ذا معنى. إذا كان البيان العام يقول فقط "حادثة خدمة"، فلا يمكن للعملاء معرفة ما إذا كانت دفاتر التشغيل الخاصة بهم يجب أن تتغير. إذا كان يقول أي خدمة، وما نوع حالة التوجيه التي فشلت، وكيف تم إعادة توجيه حركة المرور، وما هي الضوابط التلقائية التي عملت، وما هي الضوابط اليدوية التي كانت مطلوبة، وما هي حواجز الحماية المتكررة التي تغيرت، يمكن للعملاء تحسين بنيتهم الخاصة.
التجاوز هو تصميم مشترك، وليس قرارًا في اللحظة الأخيرة
تحتوي خطة التجاوز الجيدة على عدة عناصر. يعرف العميل أي البادئات والخدمات محمية. يعرف العميل ما يحدث في أوضاع التشغيل الدائم وعند الطلب. يعرف المزود والعميل من يمكنه تفويض تغييرات حركة المرور. يعرف المزودون العلويون ما إذا كانت الإعلانات البديلة مسموح بها. DNS و TLS وجدران الحماية وضوابط الوصول إلى المصدر وحدود التطبيق جاهزة لمسارات حركة المرور المتغيرة. تعرف فرق الدعم أي خدمات الأعمال هي الأعلى أولوية. قوالب الاتصال جاهزة للمستخدمين النهائيين.
بدون هذا التصميم، يمكن أن يخلق التجاوز مخاطر جديدة. قد يؤدي إرسال حركة المرور حول خدمة التنظيف إلى كشف المصدر للهجوم الذي كانت الخدمة تهدف إلى امتصاصه. قد يؤدي ترك حركة المرور داخل مسار تخفيف فاشل إلى إطالة الانقطاع. قد يؤدي الإعلان عن بادئات أكثر تحديدًا إلى آثار جانبية لسياسة المسار. قد يكون تغيير DNS بطيئًا جدًا أو معتمدًا على ذاكرة التخزين المؤقت. قد يؤدي تعطيل قيود المصدر إلى خلق تعرض أمني. لا يمكن اتخاذ هذه المقايضات بهدوء عندما تكون الخدمات العامة غير متاحة بالفعل.
يعد NIST SP 800-61 Revision 2، دليل التعامل مع حوادث الكمبيوتر، إرشادات عامة، لكن دورة حياة الحوادث ذات صلة: التحضير، والكشف، والاحتواء، والاستئصال، والاستعادة، والدروس المستفادة. في التخفيف الموجه، يشمل التحضير معرفة كيفية نقل حركة المرور بأمان. تشمل الاستعادة استعادة التوجيه المحمي الطبيعي دون إنشاء طفرة أو تسرب أو فجوة أمنية.
سؤال تجاوز العميل هو أيضًا اقتصادي. قد لا تمتلك الشركات الصغيرة والمتوسطة طاقم هندسة شبكات خاص بها. قد تعتمد كليًا على المزود وموفر الاستضافة المُدارة. إذا فشل التخفيف الموجه، فقد لا يعرفون ما هي البادئات المعلنة، أو أي جهات اتصال يمكنها الموافقة على التغيير، أو ما إذا كان التجاوز موجودًا. يجب على المزود الذي يبيع الحماية لهؤلاء العملاء توفير لغة دليل تشغيل عملية، وليس فقط رسومات بنية على مستوى المؤسسة.
تواجه المؤسسات الكبيرة مشكلة مختلفة. قد يكون لديهم شبكات متطورة ومزودين متعددين، لكن حوكمتهم يمكن أن تكون بطيئة. إذا كانت إعادة التوجيه الطارئة تتطلب موافقات عبر فرق الأمن والشبكة والقانون والأعمال والتنفيذ، فقد يكون التجاوز موجودًا على الورق ولا يزال غير قابل للاستخدام. يجب أن يساعد اتصال المزود بالحادثة العملاء على اتخاذ قرارات سريعة قائمة على الأدلة.
إعادة التوجيه التلقائي تحتاج إلى دليل على التغطية
قال تحديث Akamai إن حركة مرور العملاء المتأثرين تم إعادة توجيهها تلقائيًا أو يدويًا بواسطة فرق Akamai. هذه العبارة مهمة لأنها تحدد وضعي استعادة. إعادة التوجيه التلقائي تشير إلى منطق تجاوز الفشل المبني مسبقًا. إعادة التوجيه اليدوي تشير إلى تدخل بشري للحالات التي لم يغطها المسار التلقائي، أو لم يكتمل، أو يتطلب معالجة خاصة بالعميل. السؤال المسؤول هو كيف تغيرت هذه الفئات بعد الحادثة.
يجب اختبار إعادة التوجيه التلقائي مقابل فشل واقعي من جانب المزود. لا يكفي إثبات أن إعادة التوجيه تعمل أثناء تمرين مخطط له أو انتقال بطلب من العميل. يجب أن تعمل عندما تكون حالة التوجيه الخاصة بالمزود معطلة، وعندما يكون حجم التنبيهات مرتفعًا، وعندما يحتاج العديد من العملاء إلى المساعدة في وقت واحد، وعندما يكون الاتصال بالحالة تحت الضغط. يجب أن يكون نظام استعادة مزود تخفيف DDoS مصممًا للتأثير المتزامن على عدة عملاء لأن الخدمة نفسها هي بنية تحتية مشتركة.
تعتبر سعة الدعم اليدوي مهمة لأنه لا يمكن لجميع العملاء أن يكونوا في الصف الأول. قد يكون لدى المزود مهندسين ممتازين وما زالوا يواجهون طوابير عندما يتصل العديد من العملاء في وقت واحد. يجب أن يشرح سجل الإصلاح العام ما إذا كانت خطوات التوجيه اليدوي قد تم تقليلها، وما إذا كان المزيد من العملاء قد حصلوا على إعادة توجيه تلقائي، وما إذا كانت دفاتر تشغيل الدعم قد تغيرت، وما إذا أصبح الإشعار أكثر دقة. قالت Akamai إنها ستضمن أن كل عميل لديه إعادة توجيه تلقائي إلى أقرب مركز تنظيف في حالة الفشل. هذا الوعد هو علامة إصلاح، لكن العملاء يحتاجون إلى دليل لاحق على الإنجاز.
عودة حركة المرور هي جزء آخر من الاستعادة. بمجرد إصلاح مسار المزود، يمكن أن تؤدي إعادة نقل العملاء عبر الحماية إلى خلق مخاطر إذا لم تتم إدارة تقارب المسار، وسلوك ذاكرة التخزين المؤقت، وحالة جدار الحماية، وحالة النفق، أو حركة المرور الهجومية. قد يتم استعادة الخدمة، لكن مسار العودة الإهمال يمكن أن يخلق إخفاقات متقطعة. يجب أن يتضمن سجل الحادثة ليس فقط أوقات بدء الانقطاع وانتهائه، ولكن كيف تم إعادة حركة المرور إلى حالة محمية مستقرة.
يوفر نموذج 10-K لعام 2021 من Akamai، إيداع SEC، سياقًا أوسع لمخاطر الأعمال: تبيع Akamai خدمات يستخدمها العملاء للأداء والأمان والتوفر. لا يقرر الإيداع حادثة Prolexic. إنه يظهر لماذا يمكن لانقطاعات المزود في البنية التحتية للأمان والتسليم أن تصبح قضايا حوكمة للعملاء. عندما يكون دور البائع هو الاستمرارية، فإن ضوابط الاستمرارية الخاصة بالبائع هي جزء من المنتج.
يجب أن يحدد إشعار الحالة نقاط التبعية والقرار
أثناء حادثة تخفيف موجهة، يحتاج العملاء إلى أكثر من إشعار توفر عام. يحتاجون إلى معرفة ما إذا كانت الخدمة المتأثرة هي Prolexic Routed أو وظيفة أخرى من Akamai، وما إذا كانت المشكلة تؤثر على جميع العملاء أو مجموعة فرعية، وما إذا كان تخفيف الهجوم لا يزال نشطًا، وما إذا كان التجاوز موصى به أو محفوفًا بالمخاطر، وما إذا كانت إعادة التوجيه التلقائي تحدث، وما الإجراء الذي يجب على العملاء اتخاذه إذا كان تطبيقهم غير قابل للوصول.
يمكن للجمهور تحمل بعض عدم اليقين في وقت مبكر من الحادثة. ما لا يمكن استخدامه هو طمأنة غامضة تترك العملاء يتخمون ما إذا كانوا سيغيرون المسارات. يجب أن يتطور إشعار الحالة: أولاً تحديد الخدمة المتأثرة والأعراض؛ ثم تحديد اعتماد المسار أو التنظيف؛ ثم ذكر ما إذا كانت حركة المرور يتم إعادة توجيهها تلقائيًا أو يدويًا؛ ثم تقديم إرشادات لتصعيد العميل؛ ثم نشر ملاحظة بعد الحادثة تشرح ما تغير. هذا التقدم يقلل من الضرر الثانوي.
حادثة Prolexic هي حالة حيث تتقاطع حالة المزود ودفاتر تشغيل العميل. إذا كانت الخدمة المحمية للعميل معطلة، يجب عليه أن يقرر ما إذا كان سينتظر إعادة توجيه المزود أو يفعل خطة التراجع الخاصة به. المزود لديه أفضل رؤية للخلل من جانب الخدمة. العميل لديه أفضل رؤية لأولوية الأعمال وتأثير التطبيق المحلي. إشعار الحالة الجيد يسمح لهذه الرؤى بالالتقاء بسرعة.
يجب أن يتجنب الاتصال أيضًا الادعاءات الواسعة. قالت Akamai إن الحادثة لم تكن تحديثًا للنظام أو هجومًا إلكترونيًا. هذه الحقيقة مهمة لأن العملاء يمكنهم التركيز على استعادة التوجيه التشغيلي بدلاً من الاستجابة للاختراق. لكن العملاء ما زالوا بحاجة إلى معرفة ما إذا كانت خدماتهم الخاصة متأثرة، وما إذا كانت حركة المرور الهجومية موجودة، وما إذا كانت سلامة البيانات أو السرية متورطة. يجب تحديد حوادث التوفر بدقة حتى لا يفعل العملاء القليل جدًا أو الكثير جدًا.
بالنسبة للخدمات العامة الحرجة، إشعار الحالة له وظيفة اجتماعية. قد تحتاج البنوك والبوابات الحكومية وواجهات الرعاية الصحية وخدمات الاتصالات إلى إشعار مستخدميها. إذا كان تفسير مزود التخفيف العلوي محددًا وفي الوقت المناسب، يمكن للمؤسسات النهائية التواصل بدقة. إذا كان متأخرًا أو غامضًا، تصبح الإشعارات النهائية غامضة أيضًا. غالبًا ما ينتقل نقل التكلفة من خلال عدم اليقين قبل أن ينتقل من خلال المال.
خدمات التنظيف تحتاج إلى شفافية في مجال الفشل
تنظيف DDoS هو تجريد متعمد. لا يريد العملاء إدارة كل توقيع هجوم أو مجموعة سعة عالمية أو علاقة توصيل أو نفق أو قاعدة تخفيف. يشترون خدمة مزود لأن المزود يمكنه تشغيل دفاعات متخصصة على نطاق واسع. لكن التجريد لا يجب أن يخفي مجالات الفشل التي تؤثر على الاستمرارية. يحتاج العملاء إلى فهم أي جزء من مسار المزود يمكن أن يفشل وكيف يمكنهم الاستجابة.
يمكن لوثائق المنتج وصف هذا بشروط مضبوطة. يمكنها شرح التوجيه الدائم مقابل عند الطلب، ومسؤوليات إعلان BGP، ومسارات عودة النفق، وخيارات الاتصال المباشر، والحد الأقصى لنطاق المسار، والاعتماد على نظافة بادئة العميل، وإجراءات التجاوز الطارئ، وجهات اتصال الدعم. يمكنها شرح ما يتغير إذا تم إعادة توجيه حركة المرور تلقائيًا إلى أقرب مركز تنظيف. يمكنها وصف إجراءات العميل الخطيرة أثناء الهجوم النشط. لا يتطلب أي من ذلك الكشف عن طرق التخفيف الحساسة.
شفافية مجال الفشل مهمة بشكل خاص عندما يتم تبادل الأمان والتوفر. قد يختار العميل مسارًا محميًا صارمًا يزيد من مرونة DDoS ولكنه يزيد من الاعتماد على المزود. قد يقبل عميل آخر المزيد من التعرض للمصدر مقابل تجاوز أسرع. هذه قرارات تجارية. يجب أن تكون مستندة إلى أدلة المزود، وليس اكتشافها أثناء الانقطاع.
يجب استخدام حادثة 2021 كدرس للمشتريات. يجب على مشتري تخفيف DDoS الموجه أن يسألوا: ماذا يحدث إذا كانت خدمة التنظيف نفسها بها خطأ في التوجيه؟ هل إعادة التوجيه التلقائي ممكّنة لكل بادئة محمية؟ كيف يتم تفويض التجاوز؟ كم مرة يتم اختباره؟ هل يمكن للعميل رؤية حالة المسار؟ ما تفاصيل الحالة التي سيتم توفيرها؟ ما مدى سرعة عودة حركة المرور إلى الحماية الطبيعية؟ ما الالتزامات التعاقدية التي تنطبق عندما يكون مسار الحماية هو مسار الانقطاع؟
يجب أن يرحب المزودون بهذه الأسئلة إذا كانت لديهم ضوابط قوية. إنهم يحولون حادثة مؤلمة إلى تصميم عميل أكثر وضوحًا. كما أنهم يقللون من عبء الاستجابة خلال الحدث التالي لأن العملاء الذين لديهم خطط تجاوز مختبرة يتصلون بمعلومات أفضل ويتخذون قرارات أكثر أمانًا.
المجهولات المتبقية وسؤال المساءلة
لا يكشف السجل العام عن كل تفاصيل قيمة جدول التوجيه التي حددتها Akamai. لا يوفر خريطة عميل بسبة لوقت التعطل، أو إعادة التوجيه التلقائي، أو التدخل اليدوي، أو استعداد التجاوز. لا يتحقق بشكل مستقل من أن كل عميل حصل لاحقًا على إعادة توجيه تلقائي إلى أقرب مركز تنظيف. لا يظهر جميع التخصيصات التعاقدية بين العميل والمزود والشبكات العلوية. يجب أن تظل هذه المجهولات مرئية.
ما هو معروف كافٍ لتحديد المساءلة. قامت Akamai بتشغيل خدمة Prolexic Routed 3.0. استخدمت الخدمة مسارات حركة مرور موجهة لحماية العملاء من هجمات DDoS. قالت Akamai إن قيمة جدول توجيه تم تجاوزها عن غير قصد وأن العملاء المتأثرين تم إعادة توجيههم تلقائيًا أو يدويًا. أظهر القياس الخارجي أن تأثير العميل متفاوت وأن خطط النسخ الاحتياطي كانت مهمة. تحمل العملاء والمستخدمون عواقب اعتماد الحماية الذي أصبح غير متاح.
السؤال المسؤول هو ما إذا كان التخفيف الموجه أصبح أكثر أمانًا بعد الحادثة. هل أضافت Akamai التحقق لمنع حدود حالة المسار من أن تصبح انقطاعات للعملاء؟ هل غطت إعادة التوجيه التلقائي جميع العملاء كما وعدت؟ هل أصبحت وثائق تجاوز العميل أكثر وضوحًا؟ هل حددت إشعارات الحالة نقاط القرار بشكل أسرع؟ هل تحسنت إجراءات إعادة حركة المرور؟ هل تلقى العملاء أدلة اختبار أو إرشادات معمارية؟ هل قللت الخدمة من التدخل اليدوي في ظل ظروف خطأ من جانب المزود؟
يجب الحكم على الإجابة من خلال الأدلة. بيان المزود بأن الخدمات تم استعادتها هو البداية. سجل الإصلاح بعد الحادثة، ودفاتر تشغيل العميل، ومسارات التجاوز المختبرة، وسلوك الخدمة اللاحق هي الدليل. لأن تخفيف DDoS يُباع كاستمرارية تحت ضغط عدائي، يجب أن تخضع استمرارية المسار الخاصة بالمزود لمعيار عالٍ.
الدرس النهائي ليس أن تخفيف DDoS الموجه سيء. إنه أن الحماية المفوضة تخلق تبعية مفوضة. يحتاج العملاء إلى مسار الحماية، لكنهم يحتاجون أيضًا إلى طريق آمن حول مسار الحماية عندما يكون نظام الدفاع معطلاً. حادثة Prolexic من Akamai جعلت شرط التصميم هذا مرئيًا. معيار المساءلة هو ما إذا كانت هذه الرؤية أصبحت تحكمًا دائمًا للعميل بدلاً من مجرد ذكرى انقطاع ليوم واحد.
ضوابط السعة من جانب المزود تحتاج إلى معنى مرئي للعميل
عبارة Akamai "قيمة جدول التوجيه" مضغوطة بالضرورة. لا تكشف علنًا عن البنية الداخلية، ولا ينبغي مدها إلى ما هو أبعد من بيان الشركة. ولكن حتى العبارة المدمجة لها عواقب حوكمة. يحتاج العملاء إلى فهم أن حالة المسار من جانب المزود يمكن أن تصبح حدًا مواجهًا للعميل. إذا كان يمكن تجاوز قيمة بطريقة تقاطع الخدمة، فإن التحقق من تلك القيمة هو جزء من نموذج مرونة العميل.
سؤال الإصلاح العام ليس الاسم الحرفي للقيمة. إنه فئة التحكم. هل تم مراقبة القيمة؟ هل كان هناك تنبيه قبل تأثير العميل؟ هل تم اختبار الحد في ظل ظروف النمو والفشل؟ هل كان هناك حاجز حماية لمنع برمجة المسار غير الآمنة؟ هل كان هناك تراجع عندما تم الاقتراب من القيمة؟ هل يمكن أن تتكرر الحالة في مركز تنظيف آخر أو منطقة أو مجموعة عملاء أخرى؟ هذه الأسئلة تحول بيانًا موجزًا إلى قائمة مساءلة عملية.
يمكن للعملاء طلب هذه المعلومات دون المطالبة بتنفيذ حساس. يمكن للمزود أن يقول إن عتبات حالة المسار مراقبة، وأن الإصدارات أو تغييرات المسار مختبرة ضد الحدود، وأن إعادة التوجيه التلقائي تغطي سيناريوهات محددة، وأن دفاتر التشغيل تغطي الاستثناءات اليدوية، وأن إشعار العميل سيحدد نقاط القرار. يمكنه أيضًا تزويد عملاء المؤسسات بتأكيد أعمق بموجب السرية المناسبة. النقطة ليست كشف النظام للجمهور. النقطة هي التأكيد ذي الصلة بالعميل.
يجب أيضًا اختبار ضوابط السعة مقابل شكل حالات طوارئ DDoS. يمكن لحركة المرور الهجومية أن تخلق تغييرات مفاجئة في المسار والتخفيف. قد يقوم العملاء بتنشيط الحماية عند الطلب تحت الضغط. قد يقوم المزودون بنقل حركة المرور بين مراكز التنظيف. قد يتصرف نفس التحكم الذي يعمل أثناء نافذة صيانة هادئة بشكل مختلف أثناء أحداث العملاء المتزامنة. يجب أن تتحقق الخدمة المصممة لحركة المرور العدائية من حالة المسار في ظل ظروف شبيهة بالعداء، وليس فقط العمليات العادية.
أظهرت حادثة Prolexic أن الحد الداخلي لمزود الحماية يمكن أن يشعر به المستخدمون النهائيون الذين لم يسمعوا عن الخدمة من قبل. الشخص الذي يحاول الوصول إلى بنك أو بوابة عامة يرى الموقع معطلاً. العميل يرى حادثة مورد. المزود يرى مشكلة حالة توجيه داخلية. المساءلة تتطلب الترجمة بين هذه الرؤى بحيث يثبت الطرف المسيطر على الحد أنه قلل من الأعراض العامة.
يجب على العملاء تصنيف الخدمات المحمية حسب مخاطر التجاوز
ليست كل خدمة محمية يجب أن تتجاوز بنفس الطريقة. موقع تسويقي عام، واجهة برمجة تطبيقات للدفع، تسجيل دخول للخدمات المصرفية عبر الإنترنت، بوابة رعاية صحية، مستوى تحكم SaaS، وخدمة حكومية لديهم تعرض مختلف إذا تمت إزالة حماية DDoS. دفتر تشغيل التجاوز الذي يعامل جميع البادئات المحمية على قدم المساواة هو تقريبي للغاية. يجب على العملاء تصنيف الخدمات المحمية حسب مخاطر البقاء على مسار تخفيف فاشل ومخاطر ترك الحماية.
بالنسبة للمواقع المعلوماتية منخفضة المخاطر، قد يكون التجاوز مقبولاً بسرعة إذا كان المصدر يمكنه استيعاب حركة المرور العادية. بالنسبة لأنظمة المعاملات عالية المخاطر، قد يتطلب التجاوز حدود معدل علوية، أو تغييرات في الوصول إلى المصدر، أو تشكيل حركة المرور الإقليمي. بالنسبة للخدمات التي تتعرض لهجوم بالفعل، قد يكون التجاوز خطيرًا ما لم يكن مسار تخفيف آخر جاهزًا. بالنسبة للخدمات الخاضعة للتنظيم، قد يتطلب القرار موافقة تجارية وإشعارًا عامًا. يجب أن يتم هذا التصنيف قبل انقطاع المزود، وليس في منتصفه.
يمكن للمزود المساعدة من خلال توفير شجرة قرارات التجاوز. يمكن للشجرة أن تسأل ما إذا كان العميل تحت هجوم نشط، وما إذا كان هناك تخفيف بديل، وما إذا كانت تغييرات DNS أو BGP أسرع، وما إذا كانت سعة المصدر كافية، وما إذا كانت قواعد جدار الحماية تسمح بالوصول المباشر، وما إذا كان الدعم يمكنه المساعدة في العودة الآمنة. هذا التوجيه ليس بديلاً عن هندسة العميل. إنه يجعل هندسة العميل ممكنة تحت ضغط الوقت.
يجب على العملاء أيضًا اختبار العودة إلى الحماية. من الشائع اختبار تجاوز الفشل ونسيان العودة. بعد حل حادثة المزود، يجب أن تعود حركة المرور إلى خدمة التنظيف دون كسر الجلسات، أو فقدان استقرار المسار، أو كشف المصادر، أو إعادة تقديم حركة المرور الهجومية. إذا لم يتم التدرب على العودة، قد تؤخر المؤسسات استعادة الحماية أو تخلق انقطاعًا ثانيًا. يغطي دفتر التشغيل الكامل التجاوز والعودة كدورة حياة واحدة.
سجل Prolexic مفيد حتى للعملاء الذين لم يتأثروا. أي منظمة تستخدم تخفيف DDoS الموجه يمكنها أن تسأل ما إذا كان تصنيف التجاوز لديها حديثًا. يمكنها إجراء تمرين طاولة: Akamai أو مزود آخر يبلغ عن خلل تخفيف موجه؛ إعادة التوجيه التلقائي تعمل لبعض البادئات وليس كلها؛ المستخدمون العامون يفشلون؛ لا هجوم مرئي؛ ماذا نفعل في أول خمس عشرة دقيقة؟ ستكشف الإجابة ما إذا كانت تبعية الحماية محكومة.
التخفيف متعدد المزودين يمكن أن يقلل المخاطر ويزيد التعقيد
يستجيب بعض العملاء لحادثة تخفيف موجهة من خلال النظر في مزودي DDoS متعددين. يمكن أن يقلل ذلك من الاعتماد على مزود واحد، ولكنه يمكن أيضًا أن يقدم تعقيدًا في سياسة المسار. قد يتطلب المزودون المتعددون إعلانات بادئات مختلفة، وأنفاقًا، واستراتيجيات DNS، وقيودًا على المصدر، وفحوصات صحية، وعقودًا، وجهات اتصال دعم. يمكن لخطة متعددة المزودين سيئة التصميم أن تخلق نفس الارتباك الذي كان من المفترض حله.
السؤال الصحيح ليس ببساطة "كم عدد البائعين؟" إنه "أي مجالات الفشل منفصلة؟" إذا اعتمد مزودان على نفس المسار العلوي، أو نفس التحكم في DNS، أو نفس عنق الزجاجة في المصدر، أو نفس عملية الموافقة الداخلية، فقد يكون الربح العملي للمرونة أقل مما يشير إليه عدد البائعين. إذا لم يستطع العميل تشغيل المزود الثاني تحت الضغط، فقد يصبح المزود الثاني وثائق بدلاً من استمرارية.
تنويع المزود يغير أيضًا معالجة الهجوم. حدث DDoS هو عدائي. يمكن أن يؤدي تبديل مزودي التخفيف أثناء الهجوم إلى كشف عناوين المصدر، أو إعادة تعيين سياق التصفية، أو يتطلب ترجمة القاعدة. يجب أن يعرف العميل أي مزود لديه السلطة، وكيف تنتقل حركة المرور، ومن ينسق مع المزودين العلويين، وكيف تتم مقارنة القياس عن بعد. هذه التفاصيل مهمة جدًا لارتجالها.
مع ذلك، يمكن أن يساعد التنويع إذا كان مصممًا ومختبرًا. قد يحتفظ العميل بمسار تنظيف ثانوي، أو تراجع قائم على السحابة لحركة مرور أقل حساسية، أو استراتيجية DNS طارئة. قد يقسم الخدمات حسب الأهمية ويعين نماذج تخفيف مختلفة. قد يتعاقد على مساعدة المزود أثناء التجاوز. الدرس من حادثة Akamai ليس أن كل عميل يحتاج إلى مزودين كاملين. إنه أن كل عميل يحتاج إلى استراتيجية مجال فشل مختارة بوعي.
يمكن للبائعين دعم هذه الاستراتيجية من خلال الشفافية حول كيفية فشل خدمتهم الموجهة، وكيف يمكن للعملاء المغادرة والعودة، وما هي المكونات المملوكة للعميل والمتطلبات الأساسية. عندما يقاوم المزود أي مناقشة للتجاوز، فإنه يطلب من العملاء الثقة في مسار واحد بشكل مطلق. أظهرت حادثة Prolexic لماذا الثقة المطلقة في مسار حماية واحد ليست خطة مرونة.
يجب أن يشمل عقد الحماية التعاون في الانقطاع
غالبًا ما تركز عقود تخفيف DDoS على سعة الهجوم، ووقت الاستجابة، وتوفر الخدمة، والدعم، والتسعير. تشير حادثة Prolexic إلى أسئلة إضافية. هل يحدد العقد مسؤوليات المزود عندما يكون مسار التخفيف معطلاً؟ هل يتطلب إعادة توجيه تلقائي حيثما أمكن؟ هل يحدد كيف يتم تحديد أولويات إعادة التوجيه اليدوي؟ هل يحدد التزامات العميل فيما يتعلق ببيانات البادئة، وتكوين النفق، وجهات اتصال الطوارئ، وموافقة التجاوز؟ هل يتضمن أدلة ما بعد الحادثة؟
لا يمكن لشروط العقد حل كل مشكلة تشغيلية، لكن يمكنها فرض التحضير. إذا كان العقد يتطلب جهات اتصال طوارئ حديثة، فلدى كلا الطرفين سبب للحفاظ عليها. إذا كان يتطلب اختبارات تجاوز الفشل الدورية، فمن غير المرجح أن يكون التجاوز نظريًا. إذا كان يتطلب تحديثات الحالة بمعلومات قابلة للتنفيذ، يمكن للعملاء التخطيط للاتصال النهائي. إذا كان يتطلب مراجعة ما بعد الحادثة، فمن الصعب نسيان التزامات الإصلاح.
يجب أن يعالج العقد أيضًا البيانات والقياس عن بعد. أثناء انقطاع التخفيف الموجه، يحتاج العملاء إلى سجلات أو تقارير تظهر متى فشلت حركة المرور، ومتى أعيد توجيهها، وما المناطق أو البادئات المتأثرة، ومتى استؤنفت الحماية العادية. بدون هذه الأدلة، لا يمكن للعملاء شرح الحدث لمستخدميهم أو مدققيهم أو الجهات التنظيمية. القياس عن بعد للمزود هو جزء من مساءلة العميل.
بالنسبة للخدمات الأساسية العامة، يجب أن يشمل التعاون التعاقدي الاتصال العام. قد يحتاج بنك أو وكالة حكومية أو خدمة رعاية صحية إلى إخبار المستخدمين بأن مزود تخفيف علوي يعاني من مشكلة توفر. يمكن لصياغة المزود أن تساعد في منع المعلومات المضللة. يمكنها أيضًا تأكيد أن الحدث هو مشكلة توفر وتوجيه وليس اختراق بيانات حيثما كان ذلك مدعومًا. لغة المورد الواضحة تقلل من عبء العميل.
الدرس الواسع هو أن التخفيف المفوض هو علاقة، وليس صندوقًا أسود. يتحكم المزود في دفاعات متخصصة. يمتلك العميل مهمة الخدمة. أثناء فشل جانب المزود، تلتقي هذه المسؤوليات. العقود الجيدة، ودفاتر التشغيل، وإشعارات الحالة، والاختبارات تجعل هذا اللقاء متوقعًا. بدونها، يمكن لقيمة جدول توجيه داخل بيئة بائع أن تصبح انقطاعًا عامًا مع حقوق قرار غير واضحة.
يجب أن تكون أدلة مسار العودة جزءًا من ضمان التخفيف
للتخفيف الموجه وجهان عامان: المسار إلى خدمة التنظيف والمسار العائد إلى العميل. غالبًا ما يركز المشترون على الأول لأنه أسهل في الفهم. تدخل حركة المرور الهجومية شبكة المزود الدفاعية، يقوم المزود بتصفيتها، وتصل حركة المرور النظيفة إلى المصدر. يمكن أن يكون جانب العودة بنفس الأهمية. تحدد الأنفاق والاتصالات المباشرة وتفضيلات المسار وقواعد جدار الحماية وقيود المصدر ما إذا كان المستخدمون المحميون يتلقون الخدمة بالفعل.
تجعل حادثة Prolexic أدلة مسار العودة جزءًا من الضمان. إذا قام المزود بإعادة توجيه حركة المرور تلقائيًا أو يدويًا، يحتاج العملاء إلى معرفة ما إذا كانت مسارات العودة صالحة، وما إذا كانت الأنفاق سليمة، وما إذا كانت قوائم السماح المصدر لا تزال متطابقة، وما إذا كانت العودة ستحافظ على الحماية. يمكن استعادة الخدمة تقنيًا على مستوى المزود بينما لا يزال لدى العميل عدم تطابق في جانب المصدر. يمكن أن يبدو هذا الخلل كانقطاع مستمر للمزود، أو سوء تكوين العميل، أو مشكلة استعادة جزئية.
لذلك يجب على العملاء طلب حالات اختبار المسار ومسار العودة في الإعداد. يجب أن يثبت الاختبار الأول التشغيل المحمي العادي. الثاني يجب أن يثبت إعادة التوجيه من جانب المزود. الثالث يجب أن يثبت التجاوز المصرح به من قبل العميل. الرابع يجب أن يثبت العودة الآمنة إلى الحماية. الخامس يجب أن يثبت الاتصال: من يتلقى التنبيهات، وماذا يقولون، وما الإجراء المتوقع. الخطة التي لم تنقل حركة المرور مطلقًا في تمرين متحكم به ليست خطة تجاوز يمكن الاعتماد عليها.
بيان Akamai بأن حركة المرور تم إعادة توجيهها تلقائيًا أو يدويًا يوفر نقطة بداية مفيدة، لكن العملاء يحتاجون إلى أدلة محلية. هل شاركت بادئاتهم المحمية في إعادة التوجيه التلقائي؟ هل تطلب تطبيقهم دعمًا يدويًا؟ هل أظهرت السجلات متى حدثت تغييرات المسار؟ هل تعافى المستخدمون عندما قال المزود أن الخدمة استعيدت؟ هل كان على العميل تغيير ضوابط المصدر؟ هذه الأسئلة تجعل حادثة المزود قابلة للتنفيذ دون التكهن بما هو أبعد من السجل العام.
ضمان مسار العودة مهم أيضًا للمؤسسات الصغيرة. قد يكون لدى المؤسسة الكبيرة فرق شبكة يمكنها فحص حالة BGP و GRE وجدار الحماية. العميل الأصغر قد يعرف فقط أن الموقع معطل. يمكن للوحات معلومات المزود والحالة بلغة واضحة ودفاتر تشغيل فريق الحساب سد هذه الفجوة. إذا كان المزود يبيع تخفيفًا متقدمًا لمنظمات بدون طاقم شبكة متقدم، يجب على المزود جعل حالات الاستعادة مفهومة.
معيار المساءلة هو دليل على أن الحماية يمكن تركها وإعادة الدخول إليها بأمان. تخفيف DDoS غير معتاد لأن قرارات الفشل لها عواقب أمنية في كلتا الحالتين. البقاء على مسار فاشل يمكن أن يمنع الخدمة. مغادرة المسار يمكن أن تكشف المصدر. العودة بسرعة كبيرة أو بدون تحقق يمكن أن تعيد تقديم المخاطر. لهذا السبب يجب أن يشمل ضمان التخفيف الموجه إثبات دخول حركة المرور، وعودة حركة المرور، والتجاوز، والعودة كعائلة تحكم واحدة.
يجب أن يميز اتصال العميل بين الانقطاع والهجوم
قد يفترض عميل حماية DDoS بشكل معقول أن أي مشكلة توفر بالقرب من خدمة التخفيف هي هجوم. قال تحديث Akamai إن حادثة Prolexic Routed لم تكن ناتجة عن هجوم إلكتروني. هذا التمييز ذو قيمة تشغيلية. إذا اعتقد العميل أن الانقطاع ناتج عن هجوم، فقد يتجنب التجاوز، ويشدد الضوابط، وينشط اتصالات الأزمات، أو يصعد إلى قيادة الأمن. إذا كان بإمكان المزود تأكيد مشكلة خدمة توجيه داخلية، يتغير مسار قرار العميل.
يجب على المزود إجراء هذا التمييز بسرعة عندما تدعمه الأدلة. "نحن نحقق" مناسب في وقت مبكر. بمجرد معرفة ذلك، "هذه مشكلة توجيه خدمة، لا توجد حركة مرور هجومية ملحوظة ضد أصلك" أو "حالة الهجوم لا تزال قيد المراجعة" يمنح العملاء أساسًا أفضل للعمل. يجب أن يقول الاتصال أيضًا ما إذا كان يجب على العميل الامتناع عن تغييرات المسار، أو تحضير التجاوز، أو الاتصال بالدعم لإعادة التوجيه اليدوي.
هذا هو المكان الذي يصبح فيه إشعار الحالة وثيقة تحكم مشتركة. المزود يعرف حالة الخدمة. العميل يعرف أهمية الأعمال. كلاهما يحتاج إلى لغة مشتركة. إذا كان إشعار المزود تقنيًا جدًا، قد لا تتصرف فرق الأعمال. إذا كان غامضًا جدًا، قد تخمن فرق الشبكة. الإشعار الجيد يحدد المنتج المتأثر، وأعراض العميل، وفئة السبب المعروفة، والإجراء الموصى به، ووقت التحديث التالي.
يستفيد المستخدمون النهائيون من هذا الوضوح. يمكن لبنك أو شركة SaaS أو وكالة عامة إخبار مستخدميها أن مزود تخفيف DDoS علوي يعاني من مشكلة توفر بدلاً من التلميح إلى اختراق أو عيب في التطبيق. تقلل الصياغة الدقيقة من الشائعات وحمل الدعم والذعر الأمني غير الضروري. كما تساعد المزود على تجنب إلقاء اللوم عليه لأضرار لا تدعمها الأدلة مع الاستمرار في امتلاك اعتماد الخدمة الذي يتحكم فيه.