مهلة إلغاء DigiCert حولت التحقق من الشهادة إلى اختبار مساءلة لوقت التشغيل

الملخص

• أبلغت DigiCert في Mozilla Bugzilla أنها قامت بالتحقق من بعض النطاقات باستخدام قيمة عشوائية في سجل CNAME دون بادئة الشَرطة السفلية المطلوبة، مما أثر على مسار في نظام التحقق OEM الخاص بها. وقال تقرير الحادثة إن 83,267 شهادة TLS صالحة أُصدرت بناءً على هذه الطريقة، وأن المجموعة المتأثرة على الأرجح كانت مبالغًا في تقديرها لأن النظام لم يخزّن بشكل كافٍ ما إذا كانت الشَرطة السفلية موجودة.
• كانت مشكلة الإلغاء فورية. تتطلب المتطلبات الأساسية لـ CA/Browser Forum TLS الإلغاء خلال فترات زمنية محددة للشهادات التي أُصدرت بشكل خاطئ، ويقول تقرير حادثة الإلغاء المتأخر لـ DigiCert إنها ألغت جميع شهادات TLS المتأثرة البالغ عددها 83,267 خلال 120 ساعة بدلاً من فترة الـ 24 ساعة التي كانت مطلوبة بموجب القواعد السارية آنذاك.
• لم يكن الحدث مجرد خطأ برمجي في المرجع المصدق (CA). لقد كشف عن ضعف في جرد الشهادات بين المشتركين، وقيود الاتصال من خلال الموزعين وحسابات الشركات، وضغوط قانونية من نزاع أمر قضائي مؤقت لعميل، وحقيقة أن العديد من المؤسسات لا تزال تفتقر إلى الأتمتة لاستبدال الشهادات بسرعة على نطاق واسع.
• كانت السيطرة العملية موزعة. سيطرت DigiCert على تنفيذ التحقق وتحديد الشهادات وإخطار العملاء وتنفيذ الإلغاء والإبلاغ عن الحوادث. وسيطرت برامج الجذر ومنتدى CA/Browser Forum على توقعات الثقة وضغط السياسات، ولكن ليس على نشر العملاء. وسيطر المشتركون على جردهم والأتمتة ونوافذ التغيير والنشر الخاص بالخدمات. ولم يسيطر المستخدمون النهائيون على أي من المخاطر تقريبًا.
• الدرس المستفاد من المساءلة هو أن المرجعيات المصدقة لا يمكنها أن تتعامل مع الإلغاء على أنه حدث ورقي نادر، ولا يمكن للمشتركين أن يتعاملوا مع شهادات TLS الموثوقة علنًا على أنها بنية تحتية ثابتة. يعتمد نموذج أمان Web PKI على أن يكون الاستبدال السريع مملًا تشغيليًا قبل وصول الطوارئ.

شَرطة سفلية مفقودة أصبحت مشكلة استمرارية عالمية

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

سجل حادثة DigiCert العامة فيMozilla Bugzilla bug 1910322هو المرجع الواقعي. أبلغت DigiCert أنها تلقت تقرير مشكلة في شهادة يشير إلى احتمال وجود مشكلة في تنفيذ الطريقة 7، أي التحقق القائم على DNS. وصفت عمليات تحقق متعددة مرتبطة بـ DNS وقالت إن مراجعة الكود وجدت مسارًا واحدًا يمكن فيه إصدار شهادة عندما تُستخدم القيمة العشوائية كمضيف في سجل CNAME دون إضافة شَرطة سفلية مسبقة في البداية. لاحقًا في نفس الخطأ، قال تقرير حادثة DigiCert إن التأثير كان محدودًا بالمُصدرين الذين يستخدمون نظام التحقق OEM الخاص بها، بينما تم التحقق من مسارات التحقق من خلال CertCentral و CIS، محرك الإصدار عالي الحجم لمزودي الخدمات السحابية، بشكل صحيح ولم تتأثر.

الرقم أيضًا من سجل الحادثة العامة. قالت DigiCert إن 83,267 شهادة صالحة أُصدرت بناءً على الطريقة وأنها كانت تلغي جميع الشهادات الصالحة في قاعدة البيانات المدرجة على أنها تستخدم التحقق من DNS القائم على CNAME قبل تاريخ الإصلاح. أوضحت أن هذا ربما بالغ في تقدير المجموعة المتأثرة الحقيقية لأن عناصر تحكم نظام OEM لم تخزن بشكل كافٍ ما إذا كانت الشَرطة السفلية موجودة أم لا. هذه الجملة هي محور المساءلة. يمكن للنظام تحديد مجموعة مخاطر، لكن لا يمكنه تحديد الشهادات التي كانت متوافقة بدقة. في نظام الثقة، يمكن أن يصبح عدم اليقين بشأن الامتثال التزامًا بالإلغاء.

السبب الأمني وراء الشَرطة السفلية ليس مجرد تنسيقي. تميز طرق التحقق في CA/Browser Forum بين الأسماء التي يتحكم فيها المشترك والأسماء التي قد تكون مفوضة أو أنشأها المستخدم تحت نطاق أكبر. أكد النقاش في Bugzilla على أن بادئة الشَرطة السفلية تساعد في إنشاء نطاق تحقق خاص يمكن تجنبه من قبل أسماء المضيفين العادية والعديد من خدمات النطاقات الفرعية المفوضة. يمكن أن تُقوض الشَرطة السفلية المفقودة افتراضًا يُستخدم لمنع إصدار شهادات غير مرغوب فيها حيث يمكن للمستخدمين إنشاء نطاقات فرعية تحت نطاق لا يتحكمون فيه.

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

القواعد فعلت ما تفعله القواعد: فرضت الإجراء

تُعد المتطلبات الأساسية لـCA/Browser Forum TLSمجموعة القواعد العامة في قلب الحادثة. إنها تحدد طرق التحقق من النطاق والتزامات إلغاء الشهادات لشهادات خادم TLS الموثوقة علنًا. لا يحتاج المقال إلى ذكر كل متطلب لشرح هيكل المساءلة: إذا كانت الشهادة صدرت بشكل خاطئ أو لم يمتثل التحقق للمتطلبات الأساسية، يجب على المرجع المصدق الإلغاء خلال الموعد النهائي المعمول به ما لم تسمح القواعد نفسها بمسار آخر.

يذكر تقرير الإلغاء المتأخر لـ DigiCert فيMozilla Bugzilla bug 1910805تضارب الامتثال بوضوح. قالت DigiCert إنها كانت تعمل على إلغاء جميع الشهادات في غضون 24 ساعة، ولكن بعد النقاش مع برامج الجذر والمجتمع حول التأثير، قررت التأخير وإلغاء جميع الشهادات المتأثرة في غضون 120 ساعة. لخص تقرير الحادثة اللاحق التأثير: ألغت DigiCert 83,267 شهادة في خمسة أيام بدلاً من 24 ساعة كما هو مطلوب بموجب المتطلبات الأساسية الحالية.

هذا الاعتراف مهم لأنه يفصل بين حادثتين. تعلق Bug 1910322 بعدم الامتثال للتحقق من النطاق. تعلق Bug 1910805 بالإلغاء المتأخر. كانت المشكلة الأولى في كيفية اعتبار الشهادات غير متوافقة. كانت المشكلة الثانية في كيفية تعامل النظام مع الالتزام بإزالة تلك الشهادات من الثقة بينما لا يزال العملاء يعتمدون عليها للخدمات الحية.

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

كانت برامج الجذر حذرة بشأن السلطة. في سلسلة Bugzilla، قال ممثلو Chrome Root Program إنهم لا يملكون سلطة منح استثناءات للمتطلبات الأساسية لـ CA/Browser Forum وأن هذه المتطلبات قائمة على الإجماع وليست مملوكة لبرنامج جذر واحد. توفرسياسة Chrome Root Programالسياق الأوسع لمتصفح الجذر: يشارك المرجع المصدق في مخزن الجذر تحت توقعات البرنامج وتقييم الحوادث وضغط الامتثال المستمر. لكن استشارة برنامج الجذر أثناء الأزمة ليست إعفاءً سحريًا من القواعد العامة.

تؤدي كل منسياسة Mozilla لمخزن الجذروإرشاداتاستجابة Mozilla لحوادث CAوظيفة مماثلة. إنها تجعل الإبلاغ عن الحوادث والاستجابة جزءًا من حوكمة الثقة. إنها لا تشغل خوادم المشتركين ولا تجرد الشهادات داخل البنية التحتية للعملاء. إنها تخلق منتدى المساءلة العامة الذي كان على DigiCert أن تشرح فيه ما حدث وما الذي سيتغير.

كان تقرير DigiCert صريحًا بشكل غير معتاد حول الأسباب التنظيمية

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

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

يتضمن سجل Bugzilla نفسه اعتراف قيادة DigiCert بأن الفرق الداخلية لم تكن دائمًا تعمل معًا كما ينبغي وأن العالم الذي يعتمد عليها جعل ذلك غير مقبول. هذا ليس استنتاجًا قانونيًا، لكنه اعتراف مؤسسي قوي: المرجع المصدق الموثوق علنًا ليس مجرد بائع آخر للبرمجيات كخدمة (SaaS). كود التحقق الخاص به يصدر ادعاءات تعتمد عليها المتصفحات وأنظمة التشغيل والمواقع والوكالات والبنوك والمستشفيات والمستخدمون دون رؤية سير العمل الداخلي للمرجع المصدق.

قالت DigiCert أيضًا إن المسار المتأثر كان محدودًا بنظام التحقق OEM، وليس CertCentral و CIS. هذه الحدود مهمة. إنها تمنع المبالغة في الحادثة على أنها فشل لكل قناة تحقق لـ DigiCert. لكن الحدود تثير أيضًا سؤالًا تحكميًا: لماذا كان لمسار نظام تحقق واحد سلوك امتثال مختلف، ولماذا لم يحتفظ نموذج البيانات بتفاصيل كافية للتمييز بين الحالات المتوافقة وغير المتوافقة بعد فوات الأوان؟

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

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

جانب المشتركين حوّل السياسة إلى ألم

قال تحديث DigiCert الأولي في Bugzilla إن 83,267 شهادة أثرت على 6,807 مشتركًا. وقالت أيضًا إن العديد من العملاء الذين يشغلون بنية تحتية حيوية وشبكات اتصالات حيوية وخدمات سحابية وصناعات رعاية صحية لم يكونوا في وضع يسمح بإلغائهم دون انقطاعات حرجة في الخدمة. لم يكن هذا البيان إعفاءً شاملًا. كان دليلاً على أن أجزاء كبيرة من منظومة المشتركين كانت غير مستعدة تشغيليًا للاستبدال السريع.

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

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

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

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

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

الموزعون وقنوات العملاء كانوا جزءًا من سطح الفشل

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

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

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

خدمإشعار حادثة الإلغاءمن DigiCert، المُشار إليه من CISA وفي مناقشة Mozilla، دور الإشعار المواجه للعميل. كما أشارت CISA إلى بوابة حالة DigiCert علىstatus.digicert.comللحصول على جداول زمنية محدثة. تلك الصفحات مهمة حتى عندما يكون الوصول الأرشيفي غير مثالي لأن الوكالات العامة ومناقشات برامج الجذر وجهت العملاء إليها أثناء الحادثة.

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

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

الضغط القانوني كشف الحافة الضعيفة للإلغاء الإلزامي

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

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

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

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

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

الأتمتة كانت طبقة المرونة المفقودة

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

تم إنشاء ACME، المحدد فيRFC 8555، لأتمتة إصدار الشهادات وإدارتها. لا تقتصر الأتمتة على ACME، وليس كل نظام مؤسسي جاهزًا لـ ACME. لكن المبدأ أوسع: يجب أن تكون الشهادات قابلة للتجديد والاستبدال من خلال سير عمل مختبرة، وليس طقوسًا يدوية مرة واحدة في السنة. يُظهر اقتراحSC-063من CA/Browser Forum حول الشهادات قصيرة العمر وحوافز الأتمتة أن الصناعة كانت تدفع بالفعل نحو أعمار أقصر ومرونة أفضل قبل هذا الحادث.

أكدت تعليقات Chrome Root Program في Bugzilla نفس النقطة. قال ممثلو Chrome إنهم يعطون الأولوية لتحسين المرونة والقدرة على الصمود عبر Web PKI بحيث تكون أحداث الإلغاء أقل اضطرابًا، وأشاروا إلى أن الأتمتة والنهج من نوع ARI لها فائدة محدودة بدون اعتماد واسع من قبل المرجعيات المصدقة والمشتركين.امتداد معلومات تجديد ACME (ARI)المسودة ذات صلة لأنها تهدف إلى السماح للمرجعيات المصدقة بإرسال معلومات توقيت التجديد إلى عملاء ACME. إنه ليس حلاً كاملاً لجميع مشاكل الإلغاء المتأخر، لكنه يعكس الاتجاه الصحيح: تنسيق التجديد والاستبدال القابل للقراءة آليًا.

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

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

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

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

يمكن أن يحول فقدان أي من هذه الخطوات تصحيح امتثال المرجع المصدق إلى وقت تعطل طويل للعملاء.

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

الشهادات المتأثرة كانت مشكلة ثقة، وليس بالضرورة اكتشاف استغلال

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

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

يوفرموقع CCADB العامسياقًا للبنية التحتية للشفافية التي تستخدمها مخازن الجذر والمرجعيات المصدقة، بينما تساعدcrt.shوسجلات شفافية الشهادات المجتمع في فحص الشهادات الصادرة. في سلسلة Bugzilla، قام أعضاء المجتمع بتحليل قوائم الشهادات المقدمة من DigiCert مقابل بيانات شفافية الشهادات. هذه قوة لـ Web PKI: توجد أدلة عامة للمراجعة الخارجية. إنه أيضًا تذكير بأن الشفافية بعد الإصدار لا تحل محل التحقق الصحيح قبل الإصدار.

قال تقرير الحادثة إن DigiCert ستلغي جميع الشهادات في مجموعة المخاطر، على الرغم من أن المجموعة على الأرجح بالغت في التقدير. هذا قرار ثقة متحفظ. لكن قرارات الثقة المتحفظة تفرض تكاليف توفر. لذلك يجب أن تستثمر Web PKI في كلا الجانبين: تقليل الإصدار الخاطئ من خلال ضوابط تحقق أفضل، وتقليل الاضطراب من خلال أتمتة استبدال أفضل.

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

برامج الجذر كانت مراقبين، وليس مشغلي وقت تشغيل العملاء

تشكل برامج الجذر لـ Mozilla و Chrome و Apple و Microsoft منظومة المرجعيات المصدقة الموثوقة علنًا. تساعد كل منسياسة Mozilla لمخزن الجذروسياسة Chrome Root ProgramومعلوماتApple حول شفافية الشهادات وبرنامج الشهادات الموثوقةومتطلباتMicrosoft لبرنامج الجذر الموثوقفي تحديد بيئة الثقة التي تعمل فيها المرجعيات المصدقة. تختلف السياسات المحددة، لكن الفكرة المشتركة هي أن إدراج مخزن الجذر مشروط بسلوك المرجع المصدق الجدير بالثقة.

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

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

منتدى CA/Browser Forum هو طبقة أخرى. يكتب المنتدى المتطلبات الأساسية من خلال الإجماع بين المرجعيات المصدقة والمتصفحات. لذا فإن صفحةالمتطلبات الأساسية لـ TLSليست قانونًا خارجيًا مفروضًا على DigiCert وحدها. تشارك DigiCert والمرجعيات المصدقة الأخرى في المنظومة التي تخلق الالتزامات. عندما يجد مرجع مصدق لاحقًا أن الالتزام مؤلم تشغيليًا، فهذه إشارة لتحسين مرونة المنظومة، وليس دليلاً على أن الالتزام تعسفي.

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

ما سيطرت عليه DigiCert وما سيطروا عليه المشتركون

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

لم تسيطر DigiCert على نشر شهادات كل مشترك. لم تسيطر على كل تسليم للموزع، أو كل مجلس تغيير في مؤسسة، أو كل قيود جهاز، أو بنية كل عميل سحابة، أو نافذة صيانة كل مستشفى. كما لم تسيطر على المتطلبات الأساسية وحدها. كانت مسؤولة عن الامتثال لها، وعن التفسير عندما لم تفعل.

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

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

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

أدلة وضوابط أفضل للحادثة القادمة

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

نشر DigiCert اللاحق لكود التحقق من التحكم بالنطاق علىgithub.com/digicert/domain-control-validation، مع معلومات الحزمة المرئية علىMaven Centralوالتوثيق علىjavadoc.io، ذو صلة هنا. يمكن أن تساعد مواد التنفيذ المفتوح العملاء والمجتمع في فهم سلوك التحقق، على الرغم من أن الكود المفتوح وحده لا يثبت تكوين الإنتاج أو يزيل المخاطر التنظيمية.

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

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

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

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

الدرس الدائم

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

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

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

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