حوّلت Dyn الاعتماد على DNS إلى مشكلة مساءلة لاستمرارية الإيرادات

ملخص

• لم تكن حادثة Dyn انقطاعًا تقليديًا للتطبيقات. لا تزال العديد من الخدمات عبر الإنترنت المتأثرة تمتلك خوادم وموظفين وبرامج قيد التشغيل، لكن المستخدمين لم يتمكنوا من الوصول إليها بشكل موثوق لأن المهاجمين استهدفوا طبقة DNS الموثوقة التي تخبر الإنترنت بمكان وجود تلك الخدمات.
• سيطرت Dyn على بنيتها التحتية لـ DNS الموثوق، والاستجابة لهجمات حجب الخدمة، والاتصالات حول الحالة، ومساعدة العملاء. تحكم العملاء في تركيز المزود، و DNS الثانوي، وخيارات TTL، واستعداد المسجل، والمراقبة، وافتراضات استمرارية الأعمال. سيطر مصنعو إنترنت الأشياء وشبكات الوصول على أجزاء من خطر الروبوتات الذي جعل حجم الهجوم ممكنًا.
• قضية المساءلة هي استمرارية الإيرادات. يمكن لمتاجر التجزئة، ومواقع الإعلام، ومزودي SaaS، أو الخدمات العامة أن تفقد الطلبات، والإعلانات، وقنوات الدعم، وثقة المستخدم حتى عندما يكون التطبيق الأصلي سليمًا، إذا كان تحليل الأسماء يعتمد بشدة على مزود واحد تعرض للهجوم.
• الإصلاح الدائم هو دليل على أن DNS مصمم كاعتماد حاسم: سلطة متعددة المزودين، نقل منطقة أو أتمتة مُختبرة، مراقبة مستقلة، تغييرات مسجل مُمارسة، TTLs واقعية، سعة حجب الخدمة، إشعار الحالة، ووعي على مستوى مجلس الإدارة بأن قابلية الوصول جزء من التحكم في الإيرادات.

فشل DNS يمكن أن يجعل الخدمة السليمة غير قابلة للوصول

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

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

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

كان فريق الاستعداد للطوارئ الحاسوبية الأمريكي قد حذر بالفعل من تهديدات شبيهة بـ Mirai فيتنبيه أكتوبر 2016 بشأن خطر DDoS المتزايد من Mirai وروبوتات أخرى. جاء التحذير قبل حدث Dyn وأظهر استخدام أجهزة إنترنت الأشياء المخترقة في هجمات DDoS. هذا التوقيت مهم. هجوم Dyn لم يخلق مشكلة روبوت إنترنت الأشياء؛ بل أظهر كيف يمكن لحجم الروبوت أن يحول مزود DNS مشترك إلى نقطة اختناق عامة لقابلية الوصول.

سيطرة Dyn كانت حقيقية لكنها لم تكن كاملة

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

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

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

النظام البيئي الأوسع كان لديه سيطرة أيضًا. شحن مصنعو إنترنت الأشياء أجهزة ببيانات اعتماد افتراضية ضعيفة، وممارسات تحديث سيئة، ومساءلة قليلة عن الآثار الخارجية للإساءة. يمكن لشبكات الوصول اكتشاف بعض حركة مرور الأجهزة المخترقة والحد منها. كان لدى المستهلكين والشركات الصغيرة غالبًا قدرة عملية قليلة على تأمين أجهزة DVR والكاميرات والموجهات. ربطت سلطات إنفاذ القانون لاحقًا Mirai بمتهمين محددين؛إعلان الإقرار بالذنب لعام 2017 من وزارة العدلوصف إنشاء وتشغيل روبوتات Mirai و click-fraud. هذا السجل القانوني مهم لأنه يُظهر المسؤولية الخبيثة، لكنه لا يلغي واجبات الموردين والعملاء حول مرونة الوصول.

استمرارية الإيرادات تبدأ بقابلية الوصول

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

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

تحتاج المراقبة إلى مطابقة الاعتماد. قد يقول فحص اصطناعي للتطبيق من منطقة واحدة أن الموقع معطل، لكنه قد لا يميز بين فشل المنشأ وفشل DNS الموثوق، وتخزين المحلل المتكرر المؤقت، وقابلية وصول BGP، وتوجيه CDN، أو مشاكل مزود الإنترنت المحلي. مؤسسة ناضجة تراقب استجابة DNS الموثوق من شبكات متعددة، وتتحقق مما إذا كانت خوادم الأسماء تجيب، وتراقب صحة DNSSEC إذا كان مستخدمًا، وتفصل صحة التطبيق عن صحة تحليل الأسماء. خلال هجوم Dyn، شكل هذا التمييز الاستجابة. العميل الذي كان تطبيقه سليمًا بحاجة إلى إجراء DNS وإجراء من المزود، وليس إلى تراجع التطبيق.

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

DNS الثانوي هو انضباط، ليس مربع اختيار

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

توثيقBIND لنقل المناطقمن اتحاد أنظمة الإنترنت وRFC 1996 حول إشعار DNSيوضح أن DNS متعدد الخوادم لديه آليات طويلة الأمد لتوزيع تغييرات المنطقة. يضيف DNS المُدار الحديث واجهات API وإدارة حركة المرور وميزات خاصة بالمزود، لكن المشكلة الأساسية تبقى المزامنة والسلطة. لا يمكن لشركة أن تفترض أن إضافة بائع ثانٍ بدون عملية تحديث مُختبرة ستعمل أثناء انقطاع.

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

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

سعة DDoS هي قضية نظام بيئي

أظهر روبوت Mirai أن خطر DDoS يُخلق بعيدًا عن الضحية. تم تجنيد الكاميرات وأجهزة DVR والموجهات وأجهزة أخرى في حركة هجوم لأنها كانت ضعيفة الأمان ومنتشرة على نطاق واسع. تحليلKrebsOnSecurity لعام 2016 لانقطاع Dynربط الاضطراب العام بالأجهزة الاستهلاكية المخترقة، واستعراض Cloudflare اللاحق لـ Miraiشرح لماذا كانت البيانات الافتراضية والتعرض للأجهزة مهمة. تلك المصادر ليست بديلاً عن رواية Dyn الخاصة، لكنها تساعد في شرح لماذا كان حجم الهجوم مشكلة بنية تحتية مشتركة.

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

استجابت الهيئات الحكومية والمعايير بمرور الوقت بتوجيهات أمان إنترنت الأشياء.NISTIR 8259 حول الأنشطة الأساسية للأمن السيبراني لمصنعي أجهزة إنترنت الأشياءومعايير الأمن السيبراني لإنترنت الأشياء الاستهلاكيةمن NIST تعبر عن خطوط أساس أمان الأجهزة التي كانت ستقلل من التعرض على غرار Mirai لو تم تنفيذها على نطاق واسع في وقت سابق. يعكسبرنامج وضع العلامات للأمن السيبراني للأجهزة الذكيةمن FCC نفس الاتجاه السياسي: جعل ممارسات الأجهزة غير الآمنة أكثر وضوحًا للمشترين. هذه التدابير لا تحل تركيز مزود DNS، لكنها تعالج مصدر حركة المرور الذي يمكن أن يفشل دفاعات المزود.

ممارسات مشغلي الشبكات مهمة أيضًا. إرشادات مكافحة الانتحال مثلBCP 38, RFC 2827وBCP 84, RFC 8704المحدثة تعالج التحقق من عنوان المصدر، وهو تحكم يساعد في تقليل بعض فئات حركة المرور المسيئة. لم يعتمد Mirai فقط على الانتحال، لكن الدرس الأوسع هو أن مرونة DDoS هي انضباط نظام بيئي. يمكن لمزودي DNS شراء السعة وبناء التنقية، لكن شبكات الوصول، وصناع الأجهزة، ومزودي السحابة، والعملاء all يؤثرون على حجم الهجوم وتأثيره.

استمرارية الخدمة العامة تضيف واجبًا آخر

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

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

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

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

جودة الإشعار مهمة عندما يُعطل دفتر العناوين

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

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

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

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

الدرس على مستوى مجلس الإدارة ليس "اشترِ المزيد من DNS"

الدرس على مستوى مجلس الإدارة هو التعامل مع قابلية الوصول العامة كأصل تجاري. DNS، و BGP، و CDN، والدفاع ضد DDoS، وشهادات TLS، والتحكم في المسجل، واتصالات الحالة all تقع قبل الإيرادات. قد تكون مملوكة لفرق تقنية، لكن فشلها يسبب ضررًا تجاريًا وعامًا. لا يحتاج مجالس الإدارة إلى معرفة كل نوع سجل. يحتاجون إلى معرفة ما إذا كانت المؤسسة لديها اعتمادات حاسمة بدون بديل مُختبر.

تقرير مجلس إدارة مفيد بعد Dyn سيجيب على ستة أسئلة. أي النطاقات حاسمة للإيرادات أو الخدمة العامة؟ أي المزودين يتحكمون في DNS الموثوق؟ أي النطاقات لديها DNS ثانوي أو تبديل مستقل؟ متى تم اختبار التبديل آخر مرة؟ كيف ستتواصل المؤسسة إذا لم يتمكن نطاقها الرئيسي من الحل؟ أي عمليات الإيرادات أو الدعم أو السلامة ستتوقف إذا تدهور DNS لمدة ساعة أو ست ساعات أو يوم؟

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

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

الإصلاح الدائم يعني تقليل نطاق الفشل المشترك

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

بالنسبة لـ Dyn ومزودي DNS المُدارين الآخرين، يجب أن يتضمن دليل الإصلاح سعة DDoS، والتنسيق مع المزودين الأعلى، وبصمة البث المتعدد، ورؤية تأثير العميل الخاص، وشفافية الحالة، والدعم أثناء موجات الهجوم. بالنسبة للعملاء، يجب أن يشمل DNS ثانوي مُختبر، ومراقبة مستقلة، وجاهزية المسجل، وضمان عملية DNSSEC، واتصال بديل. لأنظمة الأجهزة والشبكات، يجب أن يشمل تقليل تجنيد الروبوت وحركة المرور المسيئة. للمستخدمين من القطاع العام، يجب أن يشمل تدريبات استمرارية تفترض فشل مزود DNS.

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

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

تمرين DNS حقيقي أصعب من مخطط التبديل

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

يجب أن يشمل التمرين خطوات المسجل. من يمكنه تسجيل الدخول؟ هل أقفال السجل مفعلة؟ هل التغييرات محمية بموافقة متعددة الأشخاص؟ هل يمكن إجراء تغييرات طارئة دون تعطيل ضوابط الأمان؟ هل سجلات DNSSEC DS مفهومة؟ توضح إرشادات ممارسات DNSSEC التشغيلية فيRFC 6781لماذا تضيف المناطق الموقعة اعتبارات تشغيلية؛ يمكن لـ DNSSEC تعزيز المصادقة، لكن التغييرات الطارئة غير الحذرة يمكن أن تكسر التحقق من الصحة. الشركة التي توقع المناطق يجب أن تعرف كيف يتفاعل التبديل مع التوقيع وإدارة المفاتيح والتفويض قبل الانقطاع.

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

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

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

يجب أن تتطلب العقود أدلة على الحوادث، وليس فقط أرقام وقت التشغيل

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

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

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

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

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

السلطات العامة يمكنها نسخ نفس الاختبار

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

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

إرشادات NCSC في المملكة المتحدة حولإدارة مخاطر DNSتصف DNS كاعتماد حاسم وتشجع المؤسسات على فهم الملكية والتكوين وأمان المسجل. تلك الإرشادات تعزز درس Dyn: خطر DNS ليس فقط مشكلة المزود. إنها مشكلة ملكية وتكوين ومراقبة واستمرارية لكل مؤسسة لديها خدمة رقمية عامة.

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

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

المساءلة يجب أن تمتد إلى منع الروبوتات

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

إجراء لجنة التجارة الفيدرالية ضد D-Link، الملخص فيإعلان الشكوى لعام 2017، لم ينشأ من حالة Dyn على وجه التحديد، لكنه يوضح اتجاه المساءلة للأجهزة الشبكية غير الآمنة. أمان الأجهزة الاستهلاكية ليس فقط قضية خصوصية لأصحاب الأجهزة. على نطاق واسع، تصبح الأجهزة الضعيفة قدرة هجوم بنية تحتية ضد ضحايا غير مرتبطين. هذه الآثار الخارجية هي سبب انتماء أمان الأجهزة إلى مقال استمرارية DNS.

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

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

الحدث التالي المشابه لـ Dyn قد يكون أكثر تجزؤًا

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

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

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

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

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