أظهرت كومودو أن مخاطر إصدار الشهادات هي أيضًا مخاطر الإخطار والإنفاذ

ملخص

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

سجل الأدلة وكيفية استخدامه

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

العدد الصغير للشهادات أخفى مشكلة تفويض كبيرة

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

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

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

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

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

الإلغاء كان ضروريًا لكنه غير كافٍ

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

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

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

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

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

كان يجب أن يصل الإخطار إلى أطراف ذات مهام مختلفة

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

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

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

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

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

متاجر الجذور هي برامج خاصة ذات عواقب عامة

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

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

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

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

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

يجب أن يكون سجل الإنفاذ قابلاً للتحقق

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

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

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

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

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

الإنفاذ سلسلة، وليس حدث إلغاء واحد

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

لم تكن أي من هذه الخطوات اختيارية إذا كان الهدف هو حماية المستخدم العملية.

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

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

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

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

الإصدار المفوض يحول أمن الشريك إلى بنية تحتية عامة

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

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

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

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

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

ماذا سيتضمن تحليل ما بعد الحادثة الحديث الأقوى

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

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

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

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

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

قرار القارئ بشأن الثقة بالشهادة

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

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

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

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

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

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

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

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

طباعة

الخلاصة

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