ملخص
- قال تحديث Akamai الصادر في 17 يونيو 2021 إن حادث خدمة Prolexic Routed 3.0 أثر على جزء من العملاء الذين يستخدمون خدمة تخفيف DDoS الموجهة، حيث بدأ التنبيه في الساعة 8:47 صباحًا بالتوقيت الشرقي وأعيد توجيه حركة مرور العملاء تلقائيًا أو يدويًا حتى الاستعادة.
- المسألة المسؤولة هي التخفيف المفوض. يرسل العميل حركة المرور عبر خدمة تنظيف لمواجهة هجمات DDoS، لكن هذا المسار يصبح اعتمادًا على استمرارية الأعمال عندما يفشل التحقق من صحة التوجيه أو حالة التوجيه داخل مزود التخفيف.
- قالت Akamai إن الحادث لم يكن بسبب تحديث للنظام أو هجوم إلكتروني، وأشارت إلى تجاوز غير مقصود لقيمة في جدول التوجيه. يحصر ذلك التحليل في التحقق التشغيلي من التوجيه، وضوابط السعة/الحالة، وإعادة التوجيه، واستعادة العملاء.
- سجل القياس الخارجي لـ ThousandEyes مهم لأنه أظهر تباين تأثير الحادث على العملاء وقيمة خطط الاحتياط. يجب الحكم على حادث تخفيف موجه من خلال قدرة العملاء على الالتفاف أو إعادة حركة المرور بأمان عند تعطل مسار الدفاع.
- يجب أن تغطي أدلة الإصلاح الدائمة حواجز حماية جدول التوجيه، والالتفاف المسبق التحقق، وإشعار العميل، ونطاق إعادة التوجيه التلقائي، وسعة الدعم اليدوي، وسلامة إعادة حركة المرور، وإثبات أن مسار التخفيف لا يمكن أن يصبح انقطاعًا أكبر من الهجوم الذي من المفترض أن يمتصه.
التخفيف المفوض يغير من يتحكم في الاستمرارية
التحديث العام من 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 توفر تأطيرًا عامًا ومجتمعيًا لانضباط التوجيه. هذه مراجع عامة، وليست نتائج خاصة بالحادث. إنها مهمة لأن خدمات التخفيف الموجه تضع انضباط توجيه المشغل مباشرة في استمرارية العميل.
ملاحظة حول الطباعة
القياسات الخارجية تظهر تأثيرًا متفاوتًا
تحليلانقطاع Akamai Prolexic Routedمن ThousandEyes قيم لأنه ينظر من خارج المزود. لاحظ اختلافات في قابلية الوصول، وسلوكًا متعلقًا بالربط، وتباينًا بين العملاء. أدرجت 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،إيداع هيئة الأوراق المالية، يوفر سياقًا أوسع لمخاطر الأعمال: تبيع 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 رئيسي يعاني من مشكلة توفر بدلاً من التلميح إلى اختراق أو عيب في التطبيق. الصياغة الدقيقة تقلل من الشائعات، وعبء الدعم، والذعر الأمني غير الضروري. كما تساعد المزود على تجنب إلقاء اللوم عليه بسبب أضرار لا تدعمها الأدلة مع الاستمرار في امتلاك اعتماد الخدمة الذي يتحكم فيه.