افحص حماية الدفع في GitHub

7 دقائق

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

ما هو الحماية من الدفع؟

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

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

كيف تعمل حماية الدفع

تندمج حماية الدفع بسلاسة مع سير عمل Git القياسي مع توفير اكتشاف بيانات اعتماد قوي.

عملية الحماية من الدفع

عندما تقوم بدفع الالتزامات إلى مستودع مع تفعيل حماية الدفع:

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

يحدث رفض الدفع قبل إضافة أي التزامات إلى المستودع البعيد، مما يضمن عدم دخول السر إلى تاريخ المستودع.

مثال على استجابة حماية الدفع

عندما تكتشف حماية الدفع سريا، ترى مخرجا مشابها ل:

$ git push origin main
remote: 
remote: —————— GitHub Push Protection ——————
remote: 
remote: Secret found in the following locations:
remote: 
remote:   • src/PaymentProcessor.cs:15
remote:     - Secret type: Stripe API Key
remote:     - Detected: sk_live_51Abc123...
remote: 
remote: Push protection has blocked this push.
remote: 
remote: To push these commits, you must:
remote:   1. Remove the secret from the commits (recommended)
remote:   2. Request a bypass (requires justification)
remote: 
To https://github.com/user/repo.git
 ! [remote rejected] main -> main (push declined due to secret scanning)
error: failed to push some refs to 'https://github.com/user/repo.git'

معايير الكشف

تستخدم الحماية من الدفع نفس الأنماط السرية التي تستخدم المسح السري لكنها تطبق معايير أكثر صرامة:

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

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

توفر الحماية من الدفع

توفر حماية الدفع يختلف حسب رؤية المستودع ومستوى اشتراك GitHub.

المستودعات العامة

للمستودعات العامة:

مفعل افتراضيا: جميع المستودعات العامة الجديدة لديها حماية دفع مفعلة تلقائيا (اعتبارا من 2024).
مجاني: بدون تكلفة مرتبطة بالميزة.
متوفر عالميا: يعمل لجميع المستخدمين الذين لديهم مستودعات عامة.

المستودعات الخاصة

بالنسبة للمستودعات الخاصة، تتطلب حماية الدفع من GitHub Advanced Security:

GitHub Enterprise Cloud: متوفر برخصة Advanced Security.
خادم GitHub Enterprise: متوفر برخصة Security متقدمة.
التحكم على مستوى المنظمة: يتيح المسؤولون الحماية على مستوى المنظمة أو المستودع.

للحصول على تعليمات مفصلة حول تفعيل حماية الدفع، راجع وثائق حماية الدفع في GitHub.

التعامل مع كتل الحماية من الدفع

عندما تمنع حماية الدفع دفعا، لديك ثلاث خيارات للدقة.

إزالة السر (موصى به)

الطريقة الآمنة هي إزالة السر من التزاماتك:

تحديد السر: راجع رسالة الخطأ لتحديد موقع الملف والسطر الذي يحتوي على السر.

إزالة السر محليا: قم بتعديل الملف لإزالة بيانات الاعتماد المشفرة أصليا:

// Before (blocked by push protection)
private const string StripeKey = "sk_live_51Abc123...";

// After (reads from environment variable)
private readonly string _stripeKey = Environment.GetEnvironmentVariable("STRIPE_API_KEY");

عدل الالتزام: إذا كان السر في التزامك الأخير:
```
git add .
git commit --amend --no-edit
```
إعادة كتابة التاريخ للالتزامات القديمة: إذا كان السر في الالتزامات السابقة، استخدم إعادة التأسيس التفاعلية:
```
git rebase -i HEAD~5  # Adjust number based on how far back the commit is
```
حدد الالتزامات المشاكل للتحرير، وأزل السر، واستمر في إعادة التنصيب.
ادفع بنجاح: مع إزالة السر، ادفع مرة أخرى:
```
git push origin main
```

هذا النهج يضمن عدم دخول أي أسرار إلى تاريخ المستودع.

حماية التجاوز (استخدم بحذر)

في ظروف محدودة، قد تحتاج إلى تجاوز حماية الدفع. تشمل الأسباب المشروعة:

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

لتجاوز حماية الدفع، يوفر GitHub خيار تجاوز عند عرض خطأ الدفع المحجوب. تحتاج إلى تقديم مبرر للتحويل.

مهم

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

اسمح للنمط

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

التفاعل بين المسح السري وحماية الدفع

يعمل المسح السري وحماية الدفع معا كطبقات مكملة لحماية الاعتمادات:

الحماية من الدفع (استباقية): تمنع الأسرار من الدخول إلى المستودع من الأساس.
المسح السري (محقق): يكتشف الأسرار التي تتجاوز حماية الدفع أو كانت موجودة قبل تفعيل حماية الدفع.

السيناريوهات الشائعة

فهم كيفية تفاعل هذه الميزات يساعدك على الاستجابة بشكل مناسب.

كلاهما مفعل، سر جديد

عندما تكون كلتا الميزتين نشطتين وتحاول الالتزام بسر جديد، فإن الحماية بالضغط تمنع المشكلة تماما:

تحاول دفع التزام بسر.
حماية الدفع تمنع الدفع.
تزيل السر وتدفع بنجاح.
لا يتم توليد تنبيه مسح سري (السر لم يدخل المستودع أبدا).

تجاوز حماية الدفع

عند تجاوز حماية الدفع، لا يزال المسح السري يخلق تنبيها يتطلب تصحيحا:

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

السر الذي ارتكب قبل الحماية

الأسرار التاريخية تتطلب تنظيفا يدويا حتى بعد تفعيل حماية الدفع:

تم تفعيل الحماية من الدفع حديثا.
يكتشف المسح السري السر التاريخي.
يظهر التنبيه في تبويب الأمن.
يجب عليك إزالة السر من تاريخ Git.

نمط الثقة المنخفضة

كل ميزة أمنية تتعامل مع الأنماط الغامضة بشكل مختلف، مما يوفر اكتشافا متعدد الطبقات:

أنت ترتكب كودا بنمط غامض.
حماية الدفع تسمح بالدفع (فقط تمنع أسرار الثقة العالية).
قد يولد المسح السري تنبيها للمراجعة.
أنت تقيم ما إذا كان سرا حقيقيا.

أفضل الممارسات

لتعظيم فعالية الحماية:

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

القيود والاعتبارات

فهم حدود حماية الدفع يمكن أن يساعدك في تنفيذ أمان شامل:

قيود النطاق

الحماية من الدفع تعمل فقط في وقت الدفع:

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

تأثير سير العمل

الحماية من الدفع تتطلب إجراء فوريا:

يجب حل الدفعات المحجوبة: لا يمكنك تأجيل المعالجة كما هو الحال مع تنبيهات ما بعد الالتزام.
احتمال حدوث اضطراب في سير العمل: قد يجد المطورون غير المألوفين بالإدارة السرية أن العقبات محبطة.

توفير توثيق جيد وتدريب يقلل من اضطرابات سير العمل مع الحفاظ على الأمان.

الممارسات التكميلية

استخدم أدوات أخرى إلى جانب الحماية من الدفع:

خطافات ما قبل الالتزام: اكتشف الأسرار محليا قبل محاولة الدفع.
قوالب متغيرات البيئة: توفر .env.example ملفات تظهر المتغيرات المطلوبة بدون قيم فعلية.
مكتبات الإدارة السرية: استخدم Azure Key Vault SDK، أو Amazon Web Services (AWS) Secrets Manager SDK، أو أدوات مشابهة.
مراجعة الكود: درب المراجعين على مراقبة الاعتمادات المشفرة بشكل ثابت.

الملاحظات

هل كانت هذه الصفحة مفيدة؟