الملخص
- الحدث:أعلنت GitHub أنها اكتشفت خلال الأسبوع الموافق 20 مارس 2023 أن مفتاح مضيف SSH RSA الخاص بـ GitHub.com قد تم كشفه لفترة وجيزة في مستودع عام على GitHub. استبدلت المفتاح في حوالي الساعة 05:00 UTC يوم 24 مارس بعد ظهور أولي قصير للمفتاح الجديد من حوالي الساعة 02:30 UTC.
- الحدود:امتلاك مفتاح المضيف هذا يمكن أن يساعد خصمًا في انتحال شخصية 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 مفتاح مضيف SSH RSA القديم المستخدم في عمليات 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 فقط مفتاح مضيف SSH RSA الخاص بـ 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القديم، وإضافة المفتاح العام الجديد مباشرة أو استرداد المفاتيح المنشورة من Meta API الخاص بـ GitHub، وتأكيد بصمة RSA الجديدة. كما حذرت من أن وظائف GitHub Actions باستخدامactions/checkoutمع خيارssh-keyيمكن أن تفشل. قالت GitHub إنها كانت تحدث علاماتv2وv3وmainالمدعومة للإجراء. الوظائف المثبتة على SHA التزام محدد لن تتحرك مع تلك العلامات وتحتاج إلى تحديث مقصود.
حالة نقطة النهاية العامة.توثيق Meta REST APIالحالي يظهر أن استجابة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، المعاصر للحادثة، يحذر من أن بناء ملف hosts معروف من مخرجات مسح غير موثقة يترك المستخدمين عرضة لهجوم شخص في الوسط.
الإغراء التشغيلي هو تعيينStrictHostKeyChecking=noأو توجيهUserKnownHostsFileإلى موقع قابل للتخلص. يمكن أن يجعل خط الأنابيب أخضر، لكنه يغير السؤال من "هل هذا هو GitHub؟" إلى "هل أجاب شيء على المنفذ 22؟"دليل تكوين العميللـ OpenSSH يشرح أن التحقق الصارم يرفض مفاتيح المضيف المتغيرة ويوفر أقصى حماية ضد هذه الفئة من الانتحال. يصف أيضًاaccept-new، الذي يقبل المضيفين غير المعروفين سابقًا لكنه لا يزال يرفض المفاتيح المتغيرة. لا تزيل أي من الإعدادين الحاجة إلى توزيع هويات مضيف موثقة.
الدرس ليس أن كل مطور يجب أن يصبح عالم تشفير في الساعة 05:00 UTC. بل أن المنظمة يجب أن تحول السؤال التشفيري إلى سؤال تشغيلي قبل الطوارئ: أي مصدر موثوق، ومن يمكنه الموافقة على بصمة جديدة، وكيف يتم توزيعها، وأي وظائف يجب أن تتوقف، وكيف يتم إثبات الاسترداد الناجح؟
السيناريو المضاد الأول: التدوير قبل أن يجبر الكشف الجدول
اسأل ماذا كان سيحدث لو قامت GitHub بتدوير مفتاح مضيف RSA كتمرين مخطط له قبل شهر واحد.
التدوير المخطط يمكنه نشر البصمة المستقبلية مسبقًا، وتقديم خوارزميات مفاتيح مضيف متعددة، وتحديث مخازن الثقة المُدارة، وممارسة مسار GitHub Actions، وقياس العملاء الذين ما زالوا مثبتين على RSA، وترك المفتاح القديم صالحًا خلال فترة تداخل محددة. آليةUpdateHostKeysفي OpenSSH يمكنها تعلم مفاتيح إضافية فقط بعد أن يوثق الخادم بهوية موثوقة بالفعل. هذا نمط مفيد للتدوير السلس: استخدام علاقة ثقة سليمة لتقديم الهوية التالية قبل إلغاء الهوية الحالية.
التدوير الطارئ بعد كشف المفتاح الخاص مختلف. بمجرد أن يكون المفتاح الخاص القديم قد يصبح في أيدي الخصوم، التداخل المطول يحافظ على فرصة الانتحال. لا يمكن للمزود حل هذا التوتر بالوعد بعدم التدوير أبدًا. يمكن تقليله عن طريق الحفاظ على أكثر من مفتاح مضيف محمي بشكل مستقل، واختبار تفاوض العميل بانتظام، ونشر نقاط نهاية تحقق مستقرة، وممارسة مسار إلغاء مضغوط، ومعرفة أي تبعيات يحتفظ بها المزود تدمج المفتاح القديم.
كان لدى GitHub بالفعل هويات مضيف ECDSA و Ed25519، والإشعار يقول إن مستخدمي تلك المفاتيح لم يتأثروا. ذلك قلل من نصف قطر الانفجار. السجل العام لا يحدد عدد المستخدمين والوظائف الذين تعلموا تلك البدائل بالفعل، وعدد الذين كانوا RSA-only، أو ما إذا كانت تمارين التدوير قبل الكشف قد اختبرت المسار الطارئ. تلك الأرقام ستميز التنوع التشفيري على الخادم عن الاستمرارية القابلة للاستخدام عبر قاعدة العملاء.
اختبار التدوير العملي له دليل عند كلا الطرفين. يجب أن يكون المزود قادرًا على إظهار أنه يمكن إنشاء بديل دون تصدير مواد خاصة إلى مساحة عمل مطور؛ وأنه يمكن نشره دون تقديم غير مقصود مبكر؛ وأن المفاتيح القديمة يمكن إلغاؤها بسرعة؛ وأن المدونة والوثائق وAPI والدعم وحالة الرسائل تبقى متسقة؛ وأن العملاء والإجراءات من الطرف الأول يمكن تحديثها. يجب أن يكون العميل قادرًا على إظهار أن أسطوله يرفض تغييرًا غير معلن، ويستهلك تغييرًا معتمدًا معلنًا، ولا يتطلب من كل مطور الارتجال.
المقياس الرئيسي ليس "اكتمل التدوير." إنه الوقت من قرار المزود إلى استرداد العميل الموثق، مقسمًا حسب محطات العمل البشرية، والخوادم الدائمة، والمشغلين المؤقتين، وCI الطرف الثالث، وأجهزة النشر، وإصدارات الإجراءات المثبتة. التدوير الذي ينجح عند حافة الخدمة بينما يترك أنظمة النشر عالية القيمة غير قادرة على جلب المصدر هو مكتمل تقنيًا وغير مكتمل تشغيليًا.
السيناريو المضاد الثاني: جعل التحقق مستقلاً بما يكفي ليصبح مهمًا
الآن افترض أن خصمًا كان لديه مفتاح RSA المكشوف وموقعه على شبكة عميل واحد في لحظة إعلان GitHub للتغيير. هل يستطيع العميل التمييز بين المفتاح الجديد الحقيقي ومفتاح قديم لا يزال موثوقًا يقدمه المهاجم؟
إشعار مارس قدم عدة حقائق مفيدة: الخوارزمية المتأثرة، بصمة الاستبدال، المفتاح العام الكامل، الوقت الفعّال، البدائل غير المتغيرة، والأوامر. API الخاص بـ GitHub قدم بيانات قابلة للقراءة آليًا. الوثائق والمدونة استخدمتا HTTPS. بالنسبة لمعظم المنظمات، التحقق من أكثر من واحد من هذه الأسطح ومطابقة البصمة تمامًا كان إجراء طوارئ معقول.
لكن "مستقل" هو طيف. المدونة والوثائق وAPI وبوابة الدعم والخدمة تُدار ضمن نفس النظام البيئي للشركة والنطاق. اختراق واسع لوحة تحكم النشر في GitHub يمكن أن يؤثر على عدة منها في وقت واحد، على الرغم من عدم وجود دليل على ذلك هنا. عميل ذو احتياجات ضمان أعلى يمكنه تخزين البصمات المعتمدة في مستودع التكوين الخاص به، وتلقي تنبيهات مزود موقعة عبر قناة مسجلة مسبقًا، وطلب مراجعين داخليين لمقارنة مصادر من شبكات منفصلة، أو استخدام موجز مزود موثوق.
بروتوكول SSH أيضًا يعرف نماذج توزيع ثقة أخرى.RFC 4255يحدد سجلات DNS SSHFP ويؤكد أن البصمة المقبولة بدون قناة تحقق آمنة تترك الاتصال عرضة للخطر. التبديل المستند إلى DNS يكون ذا معنى فقط عندما تكون بيانات DNS موثقة، عادةً مع DNSSEC، وعندما يتحقق العميل وفقًا للسياسة. نقل بصمة من تحذير SSH إلى DNS غير موقع سينقل مشكلة الثقة بدلاً من حلها.
اتصالات موثوقية GitHub ذات صلة لكنها غير قابلة للتبديل.تصميم موقع الحالةللشركة يشرح أن عمليات Git لها مكون متميز وأن العملاء يمكنهم الاشتراك عبر البريد الإلكتروني أو SMS أو webhook.توثيق دعم GitHubالحالي يوجه العملاء أيضًا إلى حوادث الحالة وقنوات الاشتراك. تلك الموجزات يمكن أن تخبر فريق العمليات بوجود مشكلة خدمة. ضوء الحالة وحده لا يمكنه مصادقة بصمة استبدال ما لم يحمل رسالة الحادث أو يربط إلى دليل المفتاح الموثوق.
اختبار السيناريو المضاد هو بالتالي ملموس: افصل مشغل اختبار عن وحدة التحكم الإدارية العادية للمنظمة، استبدل مفتاح RSA المتوقع لـ GitHub بمفتاح اختبار، ولاحظ الاستجابة. هل تتوقف الوظيفة؟ هل يحافظ التنبيه على البصمة المقدمة؟ هل يمكن لمهندس الاستجابة العثور على إرشاد معتمد من خلال قناة لا تعتمد على تلك الوظيفة؟ هل هناك هوية للشخص المخول بالموافقة على التغيير؟ هل يمكن لإدارة التكوين تحديث الأسطول بشكل ذري وعكس إدخال خاطئ؟ إذا كانت الإجابة "شخص يبحث على الويب ويلصق الأمر الأول،" فإن نموذج الثقة لا يزال يعتمد في الغالب على الحظ البشري.
السيناريو المضاد الثالث: إيقاف المفتاح الخاص قبل أن يبدأ "لفترة وجيزة"
بدأ الحدث بمادة خاصة في مستودع عام، لذا مراجعة ضوابط معقولة تسأل أين كان يمكن مقاطعة النشر. يجب ألا تفترض إجابة لم تقدمها 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 أو احتفاظه. سجلات العميل و CI تبقى ضرورية.
اختبار السيناريو المضاد هو ما إذا كانت المؤسسة تستطيع الإجابة، قبل تدوير أي شيء، "أي خطوط أنابيب إنتاج ستتوقف إذا تغير مفتاح مضيف RSA الخاص بـ GitHub؟" إذا كانت الإجابة تستغرق وقتًا أطول من انقطاع النشر المسموح به، فإن مخزن الثقة هو تبعية إنتاج غير مُدارة.
CI يحول البصمة إلى حدث استمرارية خدمة
مطور بشري يرى تحذيرًا. مشغل غير مراقب يعيد حالة خروج غير صفرية. هذا الاختلاف يغير شكل التأثير.
عملية سحب فاشلة يمكن أن تمنع الاختبارات من البدء، وتوقف قطعة إصدار من البناء، وتمنع مستودع بنية تحتية من تطبيق تغيير، أو تترك نشرًا ينتظر المصدر. الوحدات الفرعية الخاصة والمستودعات الثانوية هي أسباب شائعة لتوفير مفتاح SSH لـactions/checkout؛ أنظمة CI الأخرى تستدعي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 المصدر في دليل إجراءات داخلي. اطلب فحصًا ثانيًا قبل تغيير الثقة على مستوى المؤسسة. اعرف أي وظائف CI تستخدم 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 "لا سبب للاعتقاد" ليس مكافئًا لإثبات أنه لم ينسخ أحد المفتاح. المستودعات العامة مصممة للتكاثر السريع. على العكس، الاستنساخ أو عرض الصفحة خلال الفترة لن يثبت بحد ذاته استخدامًا ضارًا. دليل الاستخدام سيتطلب قياسات شبكة، وتقارير عن انتحال مفتاح قديم بعد الكشف، أو نقاط نهاية مشبوهة، أو سجلات اتصال من جانب العميل.
تقرير مزود أكثر اكتمالاً سيجيب على ثمانية أسئلة:
- ما الذي أنشأ أو صدّر المفتاح الخاص، وأي حد حيازة تم تجاوزه؟
- أي سطح مستودع كشفه، ولأي فترة زمنية بالضبط، ومن خلال أي APIs أو ذاكرات تخزين مؤقت؟
- أي تحكم اكتشفه، وكم سرعان ما وصل التنبيه إلى شخص مخول بإلغائه؟
- ما الدليل الذي دعم الاستنتاج بأن أنظمة GitHub ومعلومات العملاء لم تخترق؟
- ما هي القياسات التي تم فحصها لاستخدام مفتاح المضيف المحاول، وما حدود الرؤية المتبقية؟
- لماذا كان المفتاح الجديد مرئيًا من حوالي الساعة 02:30 UTC، وهل كان ذلك ضمن خطة التغيير؟
- كم عدد وظائف الطرف الأول أو إصدارات الإجراءات المدعومة التي تطلبت تحديثًا، وكم استغرق استرداد العميل؟
- ما التغييرات الدائمة التي تم إجراؤها على حيازة المفاتيح، ومنع المستودعات، وتدريب التدوير، وإخطار العميل؟
إرشادات GitHub الحالية حولالاستجابة لحادثة أمنيةتوصي بالحفاظ على الأدلة، وتسجيل القرارات، والتواصل، واستخدام بيانات التدقيق. هذا معيار حالٍ معقول. إنه ليس تدقيقًا مستقلاً لاستجابة GitHub الخاصة في عام 2023.
إرشادات مخاطر سلسلة توريد الأمن السيبرانيالحالية من NIST تضع ضمان المزود، وتنسيق الحوادث، والتخطيط للطوارئ ضمن الحوكمة التنظيمية. مطبقًا هنا، الضمان ليس شهادة تقول إن المزود آمن. إنه دليل على أن المزود يمكنه إلغاء هوية مخترقة، وإخبار العملاء بكيفية مصادقة الاستبدال، ومساعدتهم في فهم عدم اليقين المتبقي.
المسؤولية تتبع التحكم العملي
الناشر غير المقصود، إذا كان شخصًا متورطًا، تحكم في الفعل المباشر لكن ربما لم يتحكم في النظام الكامل الذي جعل مادة المضيف الإنتاجية قابلة للنشر. تسمية ذلك الشخص لن تجيب لماذا كان التصدير ممكنًا، ولماذا سمحت ضوابط المستودع بالكائن، ولماذا استغرق الكشف الوقت الذي استغرقه، أو كيف أثر التدوير على العملاء. لم تحدد GitHub الفاعل، ولا يوجد أساس لإسناد الدافع.
قادة الأمن والبنية التحتية في GitHub تحكموا في الضمانات الأعلى تأثيرًا: توليد وتخزين مفتاح المضيف، والوصول إلى المواد الخاصة، وسياسة المستودع، والكشف والتحقيق، وتوقيت الإلغاء، ونشر مفتاح جديد، وقياس إساءة الاستخدام، والبصمات العامة، وتحديثات Actions من الطرف الأول، وتنسيق الدعم، وعمق الإفصاح بعد الحادثة. يحصلون على الحصة الأكبر من مساءلة الوقاية والاستجابة لأن العملاء لم يتمكنوا من تدوير مفتاح مضيف GitHub.com أو فحص حيازته.
يستحق GitHub أيضًا الفضل في قرار الاحتواء الأساسي. استبدال المفتاح كان الإجراء الحكيم على الرغم من التكلفة التشغيلية. الإشعار سمّى الخوارزمية المتأثرة، وفصل SSH عن HTTPS، وقدم البصمة الجديدة والمفتاح العام، وأعطى طرق تحديث يدوية وقائمة على API، واعترف بالتقديم التحضيري في 02:30، وحذر مستخدمي Actions، وحدّث العلامات المدعومة. مزود أخفى التغيير لتجنب إزعاج العملاء لكان قد تركهم يثقون في مفتاح خاص مكشوف.
تحكم مالكو المؤسسات والمؤسسات في كيفية دخول GitHub في سلسلة الإنتاج الخاصة بهم. تضمنت مسؤولياتهم جرد استخدام SSH، والحفاظ على التحقق الصارم، والحفاظ على حزمة ثقة موثوقة، والاشتراك في الإشعارات، وإعطاء موظفي الاستجابة مسار موافقة، والاحتفاظ بسجلات العميل، واختبار النقل البديل، ونسخ احتياطي للمصادر والبيانات الوصفية الحرجة. هذه الواجبات لا تعفي GitHub من نشرها. إنها تعترف بأن تصميم استرداد العميل موجود على أنظمة لا تديرها GitHub.
تحكم القائمون على الإجراءات والتكاملات في مواد المضيف المدمجة، وقنوات الإصدار، وتعليمات التحديث. العلامة القابلة للتحريك يمكنها تقديم إصلاح سريع؛ SHA المثبت يمكنه الحفاظ على النزاهة التي تمت مراجعتها. يجب على القائمين نشر التزام الإصلاح بالضبط، والتوقيع أو مصادقة الإصدارات بطريقة أخرى حيثما كان ذلك مدعومًا، وجعل مواد الثقة قابلة للتكوين دون تشجيع فحوصات حية غير موثقة.
تحكمت قيادة المؤسسات الصغيرة والمتوسطة في الأولويات والموارد. من غير المعقول توقع أن شركة من خمسة أفراد تدير فريق استجابة تشفير عالمي. من المعقول تعيين مالك، والاحتفاظ بخيار احتياطي واحد مختبر، وتحديد المدة التي يمكن تحمل انقطاع التحكم بالمصدر فيها. يجب على المشترين وشركات التأمين طلب أدلة متناسبة مع تلك النتيجة بدلاً من استبيان عام.
الخصم الذي استخدم المفتاح لانتحال شخصية GitHub سيتحمل مسؤولية ذلك الهجوم. لا يوجد مثل هذا الاستخدام مثبت في السجل العام الذي تمت مراجعته. مشغلو الشبكات، ومزودو DNS، وسلطات الشهادات تحكموا في قنوات ثقة مجاورة، لكن لا دليل على أنهم فشلوا أو تورطوا في هذا الحدث. لا ينبغي توزيع المسؤولية على كل مشارك محتمل لمجرد أن هجومًا افتراضيًا سيتطلبهم.
مجموعة تحكم تنجو من كلا معنيي التحذير
الهدف الدائم ليس "منع تحذيرات مفاتيح المضيف." إنه جعل المنظمة تستجيب بشكل صحيح سواء كان التحذير يعني صيانة أو هجومًا.
بالنسبة للمزود، حافظ على مفاتيح المضيف الخاصة غير قابلة للتصدير حيثما أمكن، وافصل التوقيع الإنتاجي عن بيئات المستودع والمطور، وسجل كل تصدير استثنائي. افحص الملفات قبل الالتزام وعند الدفع وبعد النشر؛ قم بتضمين تنسيقات المفاتيح الخاصة العامة؛ وجّه تنبيهات المفاتيح عالية الثقة مباشرة إلى وظيفة الحوادث؛ واجعل التجاوزات نادرة وقابلة للإسناد ومراجعة. حافظ على خوارزميتين حديثتين لمفتاح المضيف في مجالات حيازة منفصلة. ممارسة التدوير الطارئ من خلال عملاء الطرف الأول، والإجراءات المدعومة، والتوثيق، وAPI، والدعم، وإخطار العملاء.
بالنسبة للعملاء، فرض التحقق الصارم وتوزيع مفاتيح المضيف المعتمدة من خلال إدارة التكوين. جرد كل نظام يقوم بعمليات Git عبر SSH. خزّن بصمات المزود وعناوين URL للتحقق في دليل إجراءات مسيطر عليه. اشترك في قنوات التغيير الأمني والحالة التشغيلية. اطلب مقارنة دقيقة للخوارزمية والبصمة. احتفظ بأدلة الاتصالات الفاشلة. اختبر خيار HTTPS الاحتياطي ببيانات اعتماد محددة النطاق واختبار استعادة المستودع من مرآة أو حزمة.
لكلا الجانبين، قم بقياس التسليم. وقت المزود للكشف والاحتواء واتخاذ القرار والتدوير والنشر وتصحيح تبعيات الطرف الأول يجب أن يكون مرئيًا داخليًا. وقت العميل للتنبيه والتحقق والموافقة وتحديث طائر الكناري ونشر الثقة ومسح الوظائف الفاشلة يجب قياسه في التمارين. الفاصل الزمني بين 02:30 و 05:00 UTC يظهر لماذا تحتاج مراحل النشر إلى طوابع زمنية ذات معنى خارجي.
الاختبار النهائي غير مريح بقصد. قدم مفتاح استبدال معلنًا في تمرين واحد ومفتاحًا زائفًا غير معلن في آخر. المفتاح المعلن يجب أن يتم التحقق منه ونشره ضمن هدف الاسترداد. المفتاح الزائف يجب أن يظل محظورًا ويُرفع كاشتباه اعتراض. إذا تم قبول كليهما، فقد فشل الأمان. إذا ظل كلاهما محظورًا إلى أجل غير مسمى، فقد فشلت الاستمرارية. إذا تم إخبار الموظفين بأي تمرين هو أي قبل أن يبدأ، فقد اختبرت المنظمة برنامجًا نصيًا، وليس حكمًا.
استنتاج المساءلة
استجابة GitHub في مارس 2023 كانت صحيحة في فعلها المركزي: مفتاح مضيف خاص مكشوف علنًا لا يمكن أن يظل هوية موثوقة، حتى بدون إساءة استخدام ملحوظة. التدوير قلل من المخاطر الأمنية. حالات الفشل الناتجة لم تكن ضوضاء جانبية؛ كانت دليلاً على أن العملاء كانوا يفرضون قرار الثقة الذي كان المفتاح موجودًا لدعمه.
يصبح الحدث أكثر إفادة عندما يبقى ضمن أدلته. لم يكن سرقة مكشوفة لمستودعات العملاء. لم يكن دليلاً على أن مهاجمًا دخل إلى GitHub. لم يكن انقطاعًا عامًا لـ GitHub.com. كان نشر سر مصادقة مزود، متبوعًا باستبدال سريع أجبر بعض العملاء والأتمتة على تحديد ما إذا كانت هوية جديدة مثيرة للقلق حقيقية.
امتلكت GitHub الظروف التي يمكن بموجبها نشر مفتاح مضيفها الخاص وجودة إشارة الاستبدال. امتلك العملاء الميل الأخير من تلك الإشارة إلى أجهزة المطورين وأنظمة الإصدار. الفجوة بينهما كانت الاعتماد السحابي: مزود عالمي يمكنه نشر بصمة جديدة واحدة، لكن كل منظمة معتمدة لا تزال بحاجة إلى المصادقة والموافقة والتشغيل.
بالنسبة لمؤسسة ناضجة، يجب أن يكون ذلك تحديث ثقة مُدارًا. بالنسبة لمؤسسة صغيرة ومتوسطة، يجب أن يكون دليل إجراءات قصيرًا مع عينين ثانية ومسار HTTPS مُختبر. بالنسبة لأي منهما، لا يجب أن تكون الإجابة هي إسكات التحذير. كان الصباح آمنًا فقط عندما يستطيع العميل المتوقف الحصول على أدلة موثوقة، والتحديث بدقة، والاستئناف دون التظاهر بأن الهوية لم تعد مهمة.