صباح استجابة GitHub الأمنية الصحيحة بدت تمامًا مثل هجوم

الملخص

• الحدث:قالت GitHub إنها اكتشفت خلال الأسبوع الموافق 20 مارس 2023 أن المفتاح الخاص لمضيف RSA SSH لموقع GitHub.com قد تم كشفه لفترة وجيزة في مستودع عام على GitHub. واستبدلت المفتاح في حوالي الساعة 05:00 بالتوقيت العالمي المنسق في 24 مارس بعد ظهور تحضيري قصير للمفتاح الجديد ابتداءً من حوالي الساعة 02:30 بالتوقيت العالمي المنسق.
• الحدود:قد تساعد حيازة مفتاح المضيف هذا الخصم في انتحال شخصية GitHub لعملاء SSH الذين قد يتم تحويل حركة مرورهم ولا يزالون يثقون في هوية RSA القديمة. لم يمنح المفتاح بحد ذاته حق الوصول إلى بنية GitHub التحتية أو مستودعات العملاء أو حسابات العملاء أو مفاتيح SSH الخاصة بالمستخدمين. ذكرت GitHub أنه لا يوجد سبب للاعتقاد بأنه تم إساءة استخدامه، وقالت إن النشر لم ينجم عن اختراق أنظمة GitHub أو معلومات العملاء.
• المفارقة التشغيلية:كان من المفترض أن يتوقف عميل SSH الصارم عندما تتغير هوية GitHub. قد يؤدي هذا الفشل الوقائي إلى مقاطعة دفعات المطورين، وعمليات السحب الآلية، واسترجاع الوحدات الفرعية، والبنى، وعمليات النشر حتى يتحقق شخص ما من المفتاح الجديد ويوزعه. يؤدي حذف المفتاح القديم بشكل أعمى أو إيقاف التحقق إلى استعادة التوفر عن طريق تجاهل الدليل الذي قد يكون قد حدد هجومًا حقيقيًا.
• نتيجة المساءلة:سيطرت GitHub على حراسة المفتاح الخاص للمضيف، والوقاية والكشف حول النشر، وتنفيذ التدوير، والتواصل الموثوق، وتحديثات علاماتactions/checkoutالمدعومة. سيطرة العملاء على جرد مخازن الثقة الخاصة بهم، والتحقق المستقل، ومسار تحديث الأتمتة، ووسيلة النقل البديلة، وخطة الاستمرارية. يدعم السجل العام حدثًا أمنيًا واستمراريًا متوسط التأثير، ولكن ليس اكتشافًا بأن رمز العميل قد سُرق أو تغير.

الساعة 02:30 UTC: هوية جديدة صحيحة تظهر مبكرًا جدًا

الجزء الأكثر كشفًا في رواية GitHub ليس النشر العرضي نفسه. بل هو الفاصل الزمني الذي تصرفت فيه البنية التحتية الشرعية مثل بنية تحتية تحت الهجوم.

نشر كبير مسؤولي الأمن في GitHub إشعار استبدال مفتاح المضيف في 23 مارس 2023. يقول الإشعار إن المفتاح RSA الجديد تم تقديمه لفترة وجيزة من حوالي الساعة 02:30 UTC في 24 مارس أثناء تحضير GitHub للتغيير. في حوالي الساعة 05:00 UTC، استبدلت GitHub مفتاح مضيف RSA SSH القديم المستخدم في عمليات Git على GitHub.com. توقعت الشركة أن ينتشر الاستبدال خلال الـ 30 دقيقة التالية.

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

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

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

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

ما تم كشفه وما لم يتم كشفه

يستخدم SSH مفاتيح مختلفة لمطالبات مختلفة. الخلط بينها يجعل الحدث يبدو إما أسوأ بكثير أو أصغر بكثير مما تسمح به الأدلة.

مفتاح المستخدم أو النشر يثبت عادةً العميل لـ GitHub: يُظهر الحائز السيطرة على مفتاح خاص مرتبط بحساب أو مستودع. مفتاح المضيف يثبت الخادم للعميل: يوقع GitHub مواد تبادل المفاتيح حتى يتمكن العميل من تحديد أن الطرف الآخر يتحكم في هوية الخادم المتوقعة لـ GitHub. مواصفات نقل SSH، RFC 4253، تفصل مصادقة المضيف التشفيرية في طبقة النقل عن مصادقة المستخدم فوقها. كان السر المكشوف لـ GitHub على جانب هوية الخادم من هذا التبادل.

قالت GitHub إن المفتاح الخاص لمضيف RSA لم يمنح حق الوصول إلى بنيتها التحتية أو بيانات العملاء. كما قالت إن الكشف لم ينجم عن اختراق أنظمة GitHub أو معلومات العملاء، وأنه ليس لديها سبب للاعتقاد بأن المفتاح قد أسيء استخدامه. هذه حدود ذات معنى. إنها تستبعد معاملة النشر نفسه كدليل على أن المهاجم قد سجل الدخول إلى GitHub، أو قرأ المستودعات الخاصة في حالة السكون، أو حصل على مفاتيح SSH الخاصة بالمستخدمين، أو غير الفروع، أو وصل إلى خدمات HTTPS وGit على الويب.

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

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

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

المجموعة الفرعية مهمة أيضًا. استبدلت GitHub فقط مفتاح مضيف RSA SSH لـ GitHub.com. وقال إشعارها إن مستخدمي ECDSA وEd25519 لا يحتاجون إلى التصرف، وأن عمليات Git عبر HTTPS وحركة المرور العادية على الويب لم تتأثر. صفحة بصمات SSH التي تحتفظ بها GitHub تنشر بصمات منفصلة RSA وECDSA وEd25519 وإدخالات المفتاح العام الكاملة. المنظمة التي تقول "تغير مفتاح SSH لـ GitHub" دون تسمية الخوارزمية ستسبب حذفًا غير ضروري لثقة صالحة وتجعل المراجعة الجنائية أصعب.

الجدول الزمني الذي يسمح به الإشعار العام

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

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

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

حوالي الساعة 02:30 UTC في 24 مارس.ربما واجه بعض العملاء مفتاح مضيف RSA الجديد أثناء التحضير. هذا مهم لأن تغيير مخزن الثقة كان مرئيًا خارجيًا قبل نقطة الاستبدال حوالي الساعة 05:00 UTC. في خطة طوارئ ممارسة، التقديم التحضيري إما خطوة توافق مقصودة مع سلوك متوقع موثق أو شذوذ نشر تم تسجيله في الجدول الزمني للحادث. اعترفت GitHub بذلك لكنها لم تشرح الآليات.

حوالي الساعة 05:00 UTC.أكملت GitHub استبدال RSA وتوقعت حوالي 30 دقيقة للانتشار. يجب أن يتوقف المفتاح القديم بعد ذلك عن مصادقة خدمة SSH الحقيقية لـ GitHub.com. العملاء المثبتون عليه يمكن أن يفشلوا بشكل مغلق. العملاء المتفاوضون على نوع مفتاح غير متغير يمكنهم الاستمرار. بقي HTTPS وسيلة نقل بديلة لـ Git.

مباشرة بعد الاستبدال.أخبرت GitHub المستخدمين بإزالة إدخالgithub.comالقديم، وإضافة المفتاح العام الجديد مباشرة أو استرداد المفاتيح المنشورة من GitHub Meta API، وتأكيد بصمة RSA الجديدة. كما حذرت من أن وظائف GitHub Actions التي تستخدمactions/checkoutمع خيارssh-keyقد تفشل. قالت GitHub إنها كانت تحدث علامات الإجراء المدعومةv2وv3وmain. الوظائف المثبتة على SHA التزام محدد لن تتحرك مع تلك العلامات وتحتاج إلى تحديث متعمد.

حالة نقطة النهاية العامة.يظهر توثيق نقطة نهاية REST Meta الحالية أن استجابةGET /metaغير المصادق عليها تتضمن بصمات مفاتيح SSH ومفاتيح المضيف العامة الكاملة. هذا يعطي الآلات مصدرًا منظمًا. لا يقرر ما إذا كانت منظمة معينة يجب أن تثق في استجابة جديدة أثناء حادث، ولا يثبت مخططه الحالي الاستجابة الدقيقة التي تلقاها كل عميل في مارس 2023.

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

كان التحذير نقطة قرار، وليس رسالة خطأ يجب مسحها

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

تلك القاعدة تحول رسالة طرفية حمراء واحدة إلى ثلاث مهام منفصلة.

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

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

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

الإغراء التشغيلي هو تعيينStrictHostKeyChecking=noأو توجيهUserKnownHostsFileإلى موقع يمكن التخلص منه. يمكن أن يجعل خط الأنابيب أخضر، لكنه يغير السؤال من "هل هذه GitHub؟" إلى "هل أجاب شيء على المنفذ 22؟" يشرح دليل تكوين عميل OpenSSH أن التحقق الصارم يرفض مفاتيح المضيف المتغيرة ويوفر أقصى حماية ضد هذا النوع من انتحال الشخصية. كما يصفaccept-new، الذي يقبل المضيفين غير المعروفين سابقًا لكنه لا يزال يرفض المفاتيح المتغيرة. لا تلغي أي من الإعدادين الحاجة إلى توزيع هويات مضيف أصلية.

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

الفرضية المعاكسة الأولى: التدوير قبل أن يجبر الكشف الجدول

اسأل ما كان سيحدث لو كانت GitHub قد قامت بتدوير مفتاح مضيف RSA كتمرين مقرر قبل شهر واحد.

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

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

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

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

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

الفرضية المعاكسة الثانية: جعل التحقق مستقلاً بما يكفي ليكون مهمًا

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

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

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

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

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

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

الفرضية المعاكسة الثالثة: إيقاف المفتاح الخاص قبل أن يبدأ "لفترة وجيزة"

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

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

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

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

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

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

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

الفرضية المعاكسة الرابعة: معاملة مخازن الثقة كتبعيات إنتاج

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

كشفت حادثة مارس عن تكلفة تلك الاختفاء. حذر GitHub بشكل خاص من أن وظائفactions/checkoutالتي تستخدم إدخالssh-keyقد تفشل. مستودعactions/checkout المحتفظ به يوثق لماذا: عندما يتم تحديد مصادقة SSH، يهيئ الإجراء مفتاحًا خاصًا، ويفعل التحقق الصارم من المضيف افتراضيًا، ويضيف ضمنيًا مفاتيح مضيف GitHub.com العامة. تحديث الإجراء يمكنه تحديث تلك الثقة المضمنة للعلامات المتحركة. وظيفة مثبتة على التزام غير قابل للتغيير ستستمر في تشغيل الكود القديم المراجع، بما في ذلك مواد المضيف القديمة.

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

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

السجلات تدعم المتابعة. مرجع أحداث سجل التدقيق الحالي لـ GitHub يوثق أحداثgit.cloneوgit.fetchمع حقول بروتوكول النقل، على الرغم من أن وصول أحداث Git والاحتفاظ بها يختلفان عن أحداث التدقيق العادية. يمكن أن تساعد تلك السجلات المؤسسة في تقدير استخدام SSH وتحديد النشاط حول حادثة. لا تحدد الاتصالات الفاشلة التي لم تصل إلى GitHub، ولا ينبغي افتراض أن التوثيق الحالي يصف خطة كل عميل لعام 2023 أو احتفاظه. تبقى سجلات العميل والتكامل المستمر ضرورية.

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

التكامل المستمر يحول البصمة إلى حدث استمرارية خدمة

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

يمكن لفحص واحد فاشل أن يمنع الاختبارات من البدء، أو يوقف قطعة إصدار من البناء، أو يمنع مستودع بنية تحتية من تطبيق تغيير، أو يترك نشرًا ينتظر المصدر. الوحدات الفرعية الخاصة والمستودعات الثانوية أسباب شائعة لتوفير مفتاح SSH لـactions/checkout؛ أنظمة تكامل مستمر أخرى تستدعيgit cloneمباشرة. يحدث فحص مفتاح المضيف قبل أن يتمكن Git من تحديد ما إذا كان المستودع المطلوب حميدًا أو عاجلاً أو عامًا. كل عملية متأثرة تفشل عند نفس حدود الثقة.

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

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

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

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

نسخة المؤسسات الصغيرة والمتوسطة من نفس الصباح

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

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

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

توثيق إدارة المستودعات البعيدة لـ GitHub يشرح كيفية تبديل عنوان بعيد بين SSH وHTTPS. هذا خيار استمرارية مفيد لأن حدث مارس لم يؤثر على عمليات Git عبر HTTPS. إنه ليس تجاوزًا آليًا: HTTPS يتطلب بيانات اعتماد خاصة به، وثقة، ووكيل، وترتيبات أقل امتياز. تبديل متسرع يدمج رمز وصول شخصي واسع في سجل بناء يحل حادثة عن طريق خلق أخرى.

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

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

الأدلة التي من شأنها تغيير التقييم

السجل العام قوي بشأن إجراء الاستبدال وضعيف بشأن آليات الكشف.

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

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

تقرير مزود أكثر اكتمالاً سيجيب على ثمانية أسئلة:

1. ما الذي أنشأ أو صدر المفتاح الخاص، وما حدود الحراسة التي تم تجاوزها؟
2. أي سطح مستودع كشفه، وبأي دقة، ومن خلال أي APIs أو ذاكرات تخزين مؤقت؟
3. أية سيطرة اكتشفته، وبأي سرعة وصل التنبيه إلى شخص مخول بإبطاله؟
4. ما الأدلة التي دعمت الاستنتاج بأن أنظمة GitHub ومعلومات العملاء لم تخترق؟
5. أي قياسات عن بعد تم فحصها لاستخدام المفتاح المضيف المحاول، وما حدود الرؤية المتبقية؟
6. لماذا كان المفتاح الجديد مرئيًا من حوالي الساعة 02:30 UTC، وهل كان ذلك ضمن خطة التغيير؟
7. كم عدد وظائف الطرف الأول أو إصدارات الإجراءات المدعومة التي تطلبت تحديثًا، وما الوقت الذي استغرقه استرداد العميل الظاهر؟
8. ما التغييرات الدائمة التي أجريت على حراسة المفاتيح، ومنع المستودعات، وتدريبات التدوير، وإعلام العملاء؟

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

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

المسؤولية تتبع السيطرة العملية

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

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

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

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

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

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

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

مجموعة سيطرة تنجو من كلا معنيي التحذير

الهدف الدائم ليس "منع تحذيرات مفتاح المضيف". إنه جعل المنظمة تستجيب بشكل صحيح سواء كان التحذير يعني صيانة أو هجومًا.

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

بالنسبة للعملاء، فرض التحقق الصارم ووزع مفاتيح المضيف المعتمدة من خلال إدارة التهيئة. جرد كل نظام يقوم بـ Git عبر SSH. خزن بصمات المزود وعناوين URL للتحقق في كتابة تشغيل محكوم. اشترك في قنوات كل من التغيير الأمني والحالة التشغيلية. طلب مقارنة دقيقة للخوارزمية والبصمة. احتفظ بأدلة الاتصال الفاشل. اختبر بديل HTTPS مع بيانات اعتماد محدودة واختبار استعادة المستودع من مرآة أو حزمة.

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

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

استنتاج المساءلة

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

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

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

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