منذ عدة سنوات، أطلق GitHub Security مبادرة لتقييم وتحسين نظافة أسرارنا العامة. وكجزء من هذا الجهد، قمنا بتجربة إمكانية المسح السري التي كانت قيد التطوير في ذلك الوقت. وذلك عندما وجدنا أكثر من 20000 سرًا منتشرة عبر أكثر من 15000 مستودعًا لدينا.
وكان الرقم أعلى بكثير مما توقعنا، ولكن سرعان ما أصبح من الواضح أن النجاح سيعتمد على تحديد التنبيهات التي تمثل خطرا حقيقيا، وتعيين الملكية، ومعالجتها بأمان. وبعد تسعة أشهر، وصلنا إلى الصفر من التنبيهات المفتوحة.
غالبًا ما يسألنا عملاء المسح السري الجدد: “كيف تدير هذا الأمر داخليًا؟ كيف قمت فعليًا بتنظيف أسرارك الحالية؟”
مثل العديد من شركات البرمجيات طويلة الأمد، تطور نهج GitHub لإدارة الأسرار بمرور الوقت. تأسست GitHub في عام 2008، قبل أن تصبح الخزائن المركزية والمسح السري الآلي والمنصات المخصصة لإدارة الأسرار شائعة اليوم في جميع أنحاء الصناعة. ومع نضوج الممارسات الهندسية ونمو GitHub، واصلنا الاستثمار في ضوابط أقوى وأدوات أفضل وتقليل المخاطر بشكل منهجي للأنماط القديمة. يعكس هذا العمل التزامنا المستمر بتحسين الأمان وتقليل التعرض وضمان أن ممارساتنا الداخلية تلبي نفس المعايير العالية التي نتوقعها في جميع أنحاء الصناعة.
يشارك منشور المدونة هذا ما نجح معنا خلال هذا الجهد، ويسلط الضوء على الاستراتيجيات التي يمكنك تطبيقها لحماية أسرارك بشكل أفضل.
قطع الضوضاء
أول شيء اكتشفناه هو أن عدد التنبيهات كان مضللاً بعض الشيء، أي أن 20000 تنبيه لا تعني 20000 مشكلة خطيرة بنفس القدر.
عندما بحثنا في البيانات، اكتشفنا أن خمسة مستودعات فقط تمثل ما يقرب من 18000 من تلك التنبيهات، وكان كل واحد من هذه الأسرار غير نشط: تركيبات الاختبار، وبيانات الاعتماد المعطلة، والأسرار المزيفة ولكن تبدو صالحة المستخدمة للاختبار. (نحن نبني فحصًا سريًا، لذلك من الطبيعي أن يكون لدينا مستودعات مليئة بالأسرار التي تبدو شرعية في الاختبارات.)
وقد ترك ذلك أكثر من 2000 تنبيه يحتاج إلى الاهتمام: بيانات الاعتماد المباشرة المحتملة وآلاف القرارات المتعلقة بالمخاطر والتناوب والمعالجة.
الأسرار لا تعيش فقط في التعليمات البرمجية
لمست المعالجة السرية أكثر من مجرد كود المصدر. لقد وجدنا أسرارًا في تذاكر الدعم (يقوم العملاء أحيانًا بتضمين الرموز المميزة)، وتقارير مكافآت الأخطاء (يكشف الباحثون عما وجدوه من خلال النسخ الكاملة، بما في ذلك طلبات واجهة برمجة التطبيقات (API) مع الرموز المميزة المستخدمة)، وملاحظات الحوادث، وصفحات wiki.
لقد عقدنا شراكة مع دعم العملاء والاستجابة للحوادث الأمنية وبرنامج مكافآت الأخطاء الخاص بنا لتطوير قواعد اللعبة المشتركة. عبر جميع مسارات العمل هذه، كان علينا التأكد من أننا لم نقم بإنشاء مشكلات جديدة، مثل فتح المشكلات أو دفع الالتزامات التي تحتوي على الأسرار ذاتها التي كنا نحاول معالجتها.
نهجنا المرحلي
لم نكن نريد إنهاء 20 ألف تنبيه من خلال مطالبة عدد قليل من مهندسي الأمن بفحصها واحدًا تلو الآخر. لقد تعاملنا معها مثل أي تراكم تشغيلي آخر: إيقاف الديون الجديدة، ثم العمل على ما هو موجود بالفعل من خلال سير عمل قابل للتكرار وقابل للقياس ولا يعتمد على المعرفة المؤسسية لشخص واحد.
المرحلة 1: التمكين في كل مكان، وإيقاف التراكم
قبل تنظيف الأسرار الموجودة، كان علينا أن نمنع تراكم أسرار جديدة.
لقد قمنا بتمكين الفحص السري ودفع الحماية عبر جميع مؤسساتنا ومؤسساتنا. بفضل إعدادات GitHub Advanced Security على مستوى المؤسسة، لم يكن هذا عبارة عن سجل مستودع تلو الآخر عبر 15000 مستودع. لقد قمنا بفرض الإعداد بحيث لا تتمكن المستودعات الفردية والفرق من إلغاء الاشتراك بهدوء.
منعت حماية الدفع الأسرار الجديدة في المصدر. أدى ذلك إلى منع الأعمال المتراكمة من النمو بشكل أسرع مما يمكننا حرقه.
المرحلة الثانية: الفهم والفرز
لقد قمنا بتقسيم التنبيهات التي يزيد عددها عن 20000 تنبيه حسب المستودع والنوع السري والعمر حتى نتمكن من فصل الضوضاء عن العمل.
عندما بحثنا في الأمر، اكتشفنا أن خمسة مستودعات فقط تمثل ما يقرب من 18000 من تلك التنبيهات، وكان كل واحد من هذه الأسرار غير نشط: تركيبات الاختبار، وبيانات الاعتماد المعطلة، والأسرار المزيفة ولكن تبدو صالحة المستخدمة للاختبار. (نحن نبني فحصًا سريًا، لذلك من الطبيعي أن يكون لدينا مستودعات مليئة بالأسرار التي تبدو شرعية في الاختبارات.)
بالنسبة للتنبيهات ذات الحجم الكبير والمنخفضة المخاطر، قمنا بتطوير معايير للإغلاق المجمع. إذا كان السر موجودًا في مستودع اختبار مخصص، ولم يكن نشطًا على الإطلاق، ويتطابق مع نمط اختبار معروف، فيمكننا بكل ثقة وضع علامة على أنه تم حله. وفي غضون أيام، أغلقنا ما يقرب من 18000 تنبيه.
الأسئلة الصعبة
كان علينا اتخاذ قرارات استراتيجية حول كيفية معالجة الأسرار. عندما يبقى سر ما في مشكلة ما، هل تقوم بتحرير النص (وربما إزالة سجل المراجعة)، أو الحفاظ على مسار التدقيق؟ عندما يتم حفظ سر ما في أحد المستودعات، هل تعيد كتابة سجل git؟ أي شخص حاول إعادة كتابة سجل git على نطاق واسع يعرف ما سيحدث بعد ذلك: تؤدي عمليات الدفع القسري إلى كسر طلبات السحب المفتوحة، وإبطال التزامات SHAs، ومقاطعة المطورين بشكل عام.
كان السؤال الشائع هو: “هل يمكننا حذف المستودع إذا لم يعد قيد الاستخدام؟” وكانت إجابتنا بشكل عام لا. يأخذ المستودع المحذوف مسار التدقيق الخاص به معه. إذا تم تسريب سر في هذا المستودع أو تم اختراق المستودع، فستفقد سجل الطب الشرعي الذي ستحتاج إليه أثناء الاستجابة للحوادث. قم بتدوير السر، وقم بأرشفة المستودع إذا كان ذلك مناسبًا، ولكن احتفظ بالسجل.
كلما كان ذلك ممكنًا، نقوم بتدوير السر المكشوف أو إلغاءه أولاً. السؤال الأصعب هو ما إذا كانت المخاطر المتبقية تستدعي إعادة كتابة تاريخ git، أو ما إذا كان من الممكن ترك سر تم إبطاله في التاريخ في مكانه بأمان. هذه هي أنواع الأسئلة والقرارات المطروحة مع كل تنبيه والتي تتصارع معها فرق أمان المنتج.
المرحلة 3: التحقق من صحة ما هو حي بالفعل
ربما تم تدوير بيانات الاعتماد الموجودة في المستودع منذ سنوات، أو ربما لا تزال تفتح أنظمة الإنتاج. لا يمكنك تحديد الأولويات دون معرفة الفرق.
في ذلك الوقت، لم يكن الفحص السري يتضمن التحقق من الصلاحية، لذلك قمنا ببناء نهجنا الخاص. كان الهدف ضيقًا: تحديد ما إذا كانت بيانات الاعتماد لا تزال تعمل أم لا، وجمع ما يكفي من بيانات التعريف لتوجيه التنبيه أو إخطار المالك الصحيح، عندما يكون ذلك مناسبًا.
على سبيل المثال، بالنسبة لرمز GitHub، يمكن أن يقدم الفحص التمثيلي طلبًا واحدًا تمت مصادقته إلى نقطة نهاية منخفضة التأثير مثل GET /user:
response="$(
curl -sS -w '\n%http_code' \
-H "Authorization: Bearer $TOKEN" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/user
)"
status="$response##*$'\n'"
body="$response%$'\n'*"
case "$status" in
200)
login="$(jq -r '.login // empty' <<< "$body")"
echo "token appears active for GitHub user: $login"
;;
401)
echo "token appears invalid or revoked"
;;
403|429)
echo "unable to determine validity; rate-limited or blocked"
;;
*)
echo "unable to determine validity: HTTP $status"
;;
esac تذكر أن هدفنا كان الإجابة على أصغر مجموعة من الأسئلة المفيدة: هل لا تزال بيانات الاعتماد هذه تعمل، ومن يحتاج إلى معرفتها؟ لقد تعاملنا مع الردود الغامضة على أنها غير حاسمة، وتجنبنا متابعة طلبات المستودعات أو المنظمات أو الموارد الخاصة الأخرى.
يتطلب هذا شراكة وثيقة مع فرق الخصوصية والفرق القانونية لدينا. حتى التحقق من الصلاحية “للقراءة فقط” يمكن أن يكون له آثار عندما تلمس بيانات اعتماد قد لا تمتلكها.
وبينما كنا نتعامل مع هذا الأمر يدويًا، قام فريق المنتج لدينا ببناء الحل محليًا، مما جعل العمل المتبقي أسرع بكثير. تم الآن دمج التحقق من الصلاحية في الفحص السري لـ GitHub.
المرحلة 4: معرفة من يملك ماذا
كشف هذا العمل متعدد الوظائف أيضًا عن مشكلة ملكية: حتى بعد أن علمنا أن بيانات الاعتماد نشطة، كان لا يزال يتعين علينا معرفة من يمكنه تدويرها.
لقد عقدنا شراكة مع دعم العملاء والاستجابة للحوادث الأمنية وبرنامج مكافآت الأخطاء الخاص بنا لتطوير قواعد اللعبة المشتركة للأسرار التي تم الإبلاغ عنها خارج التعليمات البرمجية. وشمل ذلك تنقيح القيم السرية قبل توجيه العمل إلى الفرق، وتحديد ما إذا كانت بيانات الاعتماد تخص GitHub أو أحد العملاء، وإخطار العملاء أو الباحثين المتأثرين حتى يتمكنوا من تدوير الرموز المميزة تحت سيطرتهم. عبر جميع مسارات العمل هذه، كان علينا التأكد من أننا لم نقم بإنشاء مشكلات جديدة، مثل فتح المشكلات أو دفع الالتزامات التي تحتوي على الأسرار ذاتها التي كنا نحاول معالجتها.
بالنسبة لبيانات الاعتماد الصادرة عن GitHub، مثل رموز الوصول الشخصية، فقد عملنا مع فريق المنتج لدينا لعرض بيانات التعريف السرية مباشرةً في التنبيه: من أنشأ الرمز المميز، ومتى، وما هي نطاقاته. وهذا يعني أننا لسنا بحاجة إلى استخدام الرمز المميز نفسه لمعرفة الجهة التي ينتمي إليها.
بالنسبة لكل شيء آخر، كانت الملكية أصعب، مما كشف عن مشكلة أعمق: لم يكن لدى جميع المستودعات مالكون واضحون.
تعمل معاييرنا الهندسية الداخلية (برنامج أساسيات الهندسة) على فرض الملكية الدائمة على الخدمات، ونحتفظ بالتخطيط بين الخدمات والمستودعات، ولكن لا يتم تعيين جميع المستودعات بشكل واضح للخدمة. أدى الألم الذي واجهناه إلى مبادرة أوسع نطاقًا لملكية المستودع (باستخدام خصائص GitHub المخصصة)، بالإضافة إلى جهد مواز لضمان أن جميع الأسرار الموجودة في مدير الاعتماد لدينا تمتلك مالكين دائمين. لا يمكنك تدوير السر إذا لم تتمكن من العثور على المالك.
المرحلة الخامسة: الفرز اليدوي للذيل الطويل
وحتى مع التحقق من الصحة والبيانات الوصفية، فإن سلسلة طويلة من التنبيهات تتطلب الحكم البشري. لكل واحد: ما الذي يمنحه هذا الوصول، هل تم تدويره، من يملك النظام المتصل، وما هو مسار الإصلاح؟
بالنسبة لكل تنبيه قمنا برفضه، تأكدنا من تسجيل ترتيب دقيق (على سبيل المثال، تم الإلغاء، أو الاستخدام في الاختبار، أو الإيجابية الخاطئة)، بالإضافة إلى تعليق يحتوي على سياق ذي صلة، مثل رابط لمشكلة معالجة أو استثناء أمني معتمد.
تطلبت هذه المرحلة تعاونًا وثيقًا بين الفرق لتحديد مالكي النظام والتحقق من صحة حالة العلاج وتقييم المخاطر المتبقية عندما تكون الإشارات الآلية وحدها غير كافية.
المرحلة السادسة: تنظيم المساءلة ودفعها
ومع ظهور الأنماط، جعلنا العمل قابلاً للتطوير:
- قمنا بتوجيه التنبيهات إلى منصة إدارة الثغرات الداخلية لدينا من أجل التتبع المركزي وإعداد التقارير.
- تحتاج بيانات الاعتماد المختلفة إلى خطوات معالجة مختلفة. لقد قمنا بتوثيق قواعد اللعب حسب النوع السري حتى تتمكن الفرق من خدمة نفسها بنفسها.
- نقوم بأتمتة الإخطارات وتوجيه التنبيهات إلى الفرق المناسبة بناءً على ملكية المستودع.
القطعة الأخيرة كانت المساءلة. لقد ربطنا المعالجة السرية ببرنامج أساسيات الهندسة في GitHub، مما جعله أحد أساسيات الأمان التي يتم قياس الفرق وفقًا لها. لقد وضعنا توقعات واضحة وأعطينا الفرق رؤية واضحة للحالة. عندما تكون النظافة السرية جزءًا من كيفية قياس الصحة الهندسية، فإنها تصبح مسؤولية مشتركة عبر المؤسسة.
بعد تسعة أشهر من بدايتنا، وصلنا إلى صندوق الوارد صفر.
الدروس المستفادة
- لا داعي للذعر على الرقم. كان العدد الأولي لدينا أكثر من 20000 تنبيه، ولكن 90% منها لم تكن صالحة. لا يمثل العدد الأولي النطاق الحقيقي للعمل تقريبًا.
- التمكين والتنفيذ في كل مكان، بدون استثناءات. تؤدي عمليات الطرح الجزئية إلى إنشاء نقاط عمياء. لقد قمنا بتمكين وفرض الفحص السري والحماية على مستوى المؤسسة، دون السماح لأي شخص بإلغاء الاشتراك.
- التحقق من صحة قبل التصعيد. ليس كل سر تم اكتشافه حيًا. يساعدك التحقق من الصحة على إنشاء قائمة مهام ذات أولوية.
- البيانات الوصفية توفر ساعات. بالنسبة إلى بيانات اعتماد GitHub، تقلل البيانات الوصفية السرية من عمل المباحث الضروري. إذا كنت تعمل مع موفري خدمات خارجيين، فادفعهم إلى عرض بيانات تعريف مماثلة، أو أنشئ طبقة الإثراء الخاصة بك.
- لا يمكنك العلاج بدون ملكية. الاستثمار في البنية التحتية الدائمة للملكية في وقت مبكر.
- أتمتة سير العمل بعد الكشف. يساعدك الاكتشاف على البدء، ولكن التحدي التشغيلي كان يتمثل في توجيه التنبيهات وتتبع المالكين وإغلاق الحلقة. استثمر في طبقة سير العمل.
- اجعلها مشكلة الجميع. لا تستطيع فرق الأمن معالجة آلاف التنبيهات وحدها. لقد ربطنا النظافة السرية ببرنامج أساسيات الهندسة لدينا. عندما تراقب القيادة لوحات المعلومات، تجد الفرق الوقت لإصلاح الأمور.
- توثيق إطار القرار الخاص بك. سوف تواجه أسرارًا بدون مسارات علاجية نظيفة. قم بتوثيق كيفية اتخاذ القرار: متى يكون التناوب كافيًا؟ متى تعيد كتابة التاريخ؟ متى تقبل المخاطر المتبقية؟
ماذا يعني هذا بالنسبة لك
لا تحتاج إلى إعادة اختراع معظم ما قمنا ببنائه. العديد من الحلول اليدوية لدينا، بما في ذلك التحقق من الصلاحية وتحديد الملكية والفرز المجمع، أصبحت الآن ميزات أصلية في الفحص السري.
إذا كنت تبدأ اليوم:
- تمكين وتنفيذ المسح السري ودفع الحماية في كل مكان.
- فرز الأعمال المتراكمة حسب المستودع والنوع السري؛ ما يمكنك إثباته هو الضوضاء.
- تحقق من صحة ما هو حي قبل التصعيد.
- قم بتوجيه التنبيهات إلى المالكين، وتتبع عملية الإصلاح مثل أي عمل هندسي آخر.
هل أنت مستعد للبدء؟ تعرف على كيفية تمكين الفحص السري وحماية الدفع باستخدام GitHub Advanced Security.
اقرأ التالي: كيف تعاملنا مع ملكية المستودعات على نطاق واسع، ولماذا تعد الملكية الدائمة للمستودعات والأسرار هي الأساس الذي يعتمد عليه كل شيء آخر.
كتب بواسطة
