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


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

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

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

جوهر المشكلة

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

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

التنفيذ

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

توصيات للمنظمات

• 2FA إلزامي لجميع الموظفين.
• لجميع المستخدمين أو الذين لديهم أذونات أعلى على الأقل:
  
  • توفير جهة اتصال (بريد إلكتروني ، IM) للمؤسسة أو المسؤول (يتيح لك GitHub إخفاء معلومات الاتصال للخصوصية).
  • تأكد من إبلاغ المؤسسة أو المسؤول عن الاختراق المحتمل لحسابك (على سبيل المثال ، بشأن سرقة جهاز كمبيوتر محمول).

إرشادات المستودعات

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

توصيات سير العمل

• يجب الإشارة إلى عمليات النشر والإصدارات والأحداث الأخرى التي تستحق المراجعة بعلامة موقعة بمفتاح GPG معروف سابقًا.
• يجب أن تصدر جميع عمليات النشر والإصدارات فقط بعد تدقيق جميع عمليات التنفيذ والعلامات الموقعة للمفاتيح الصحيحة.

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



هنا مثال تدقيق. أولاً ، نحصل على نسخة محلية من البيانات الخاصة octo_org ، ثم يتم تجميع تقرير لكل مستودع:

 $ ./get_branch_protections.py octo_org 2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat 2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992). 2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992). 2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947). 

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

 $ ./report_branch_status.py --header octo_org.db.json name,protected,restricted,enforcement,signed,team_used octo_org/react-starter,True,False,False,False,False octo_org/node-starter,False,False,False,False,False 

كما ترى ، فقط octo_org/react-starter تضمن الحماية من الدفع القسري على فرع الإنتاج. والنتيجة بتنسيق CSV لإدراجها بسهولة في جدول البيانات.

كيف يمكنك المساعدة

ما زلنا ننفذ هذه التوصيات ونتعلم على طول الطريق. إذا كنت تعتقد أن توصياتنا لأمن المستودعات مناسبة لك ، فساعد في تبسيط التنفيذ. شارك تجربتك في صفحة النصائح أو افتح تذكرة في مستودع GitHub-Audit .