نشر تكامل الأمان المتقدم مع GitHub

يوفر هذا الدليل خطوات إعداد وإجراءات أخرى لمساعدتك على دمج GitHub Advanced Security (GHAS) و Microsoft Defender for Cloud، ثم التحقق من صحة التكامل من الطرف. يساعد هذا التكامل في تعظيم أمان التطبيقات السحابية الأصلية من Microsoft من خلال ربط مخاطر وقت التشغيل والسياق مع الشيفرة الأصلية لمعالجة أسرع مدعومة بالذكاء الاصطناعي.

باتباع هذا الدليل، أنت:

قم بإعداد مستودع GitHub الخاص بك لتغطية Defender for Cloud بشكل جيد.
أنشئ عامل خطر زمن تشغيل.
اختبر حالات الاستخدام الحقيقية في Defender for Cloud.
ربط الكود بموارد وقت التشغيل.
ابدأ حملة أمنية على GitHub. تستخدم هذه الحملة سياق وقت التشغيل لإعطاء الأولوية لتنبيهات الأمان الخاصة ب GGAS.
قم بإنشاء مشاكل في GitHub من Defender for Cloud لبدء المعالجة.
أغلق الحلقة بين فرق الهندسة والأمن.

المتطلبات الأساسية

الجانب	التفَاصيل
المتطلبات البيئية	- حساب GitHub مع موصل تم إنشاؤه في Defender for Cloud - رخصة GitHub Advanced Security (GHAS) على المستودعات المتصلة - خطة إدارة وضعية الأمان السحابي (DCSPM) من Defender مفعلة عند الاشتراك - Microsoft Security Copilot (اختياري للمعالجة الآلية المدعومة بالذكاء الاصطناعي)
الأدوار والأذونات	- صلاحيات مسؤول الأمان - مسؤول الأمان على اشتراك Azure (لعرض النتائج في Defender for Cloud) - مالك منظمة GitHub (لربط المستودعات وتكوين حملات الأمان)
بيئات السحابة	- متوفر فقط في السحب التجارية (وليس في Azure Government أو Azure التي تديرها 21Vianet أو غيرها من السحب السيادية)

إعداد البيئة الخاصة بك

الخطوة 1: قم بإعداد مستودع GitHub وتشغيل سير العمل

لاختبار التكامل، استخدم مستودعاتك الخاصة أو مشروع صندوق رمل example يحتوي على مستودع اختبار GitHub يحتوي على كل المحتويات لبناء صورة حاوية ضعيفة.

قم بتسجيل الدخول إلى بوابة Azure.
اذهب إلى Microsoft Defender for Cloud>DevOps security.
أدخل اسم مستودع الشيفرة الخاص بك في شريط البحث (مثال: zava-webshop).
تحقق من أنه ينتمي إلى المنظمة التي تراقبها، مثل منظمة زافا-كاربورد .
راجع إذا كانت هناك أي نتائج للمستودع.
تأكد من أن حالة الأمان المتقدمةمفعلة. هذا يشير إلى أن GitHub Advanced Security مفعل على المستودع المراقب.
إذا لم يتم العثور على مستودعك، راجع Microsoft Defender for Cloud الوثائق لاستكشاف الأخطاء وGitHub في الانضمام إلى الموصل.
تأكد من تفعيل المسح بدون وكيل لموصل GitHub الخاص بك.

الخطوة 2: تأكد من أن بيئتك جاهزة

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

رؤية كاملة للكود إلى وقت التشغيل

يراقب Microsoft Defender for Cloud باستمرار مستودعات الشيفرة المصدرية بحثا عن ثغرات أمنية.
يتم مسح تشويشات البناء، مثل صور الحاويات، في سجلات الحاويات قبل نشرها.
يتم مراقبة أحمال العمل أثناء التشغيل التي تنشر على عناقيد Kubernetes بحثا عن مخاطر الأمان.
يقوم Defender for Cloud بربط وتتبع كل عنصر من الشيفرة، مرورا بالبناء والنشر، إلى وقت التشغيل وما بعده.

ملاحظة

قد يستغرق الأمر حتى 24 ساعة بعد تطبيق الخطوات السابقة لرؤية النتائج التالية.

اختبر أن GitHub مسح بدون وكيل يلتقط المستودع.

اذهب إلى Microsoft Defender for Cloud>Cloud Security Explorer وقم بإجراء الاستعلام. تختبر استعلامات التحقق ما إذا كان Defender يمكنه تحديد التشويشات الناتجة عن خطوط الأنابيب وأحمال العمل الخاصة بك. إذا كانت الاستعلامات تعيد النتائج، فهذا يشير إلى أن المسح والارتباط يعملان كما هو متوقع.

ملاحظة

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

تحقق من صحة أن Defender for Cloud (في Azure Container Registry) قام بمسح صورة الحاوية واستخدامها لإنشاء حاوية.
في استفسارك، أضف شروط نشرك المحدد.
تحقق من تشغيل الحاوية وأن Defender for Cloud قام بمسح عنقود AKS.
تحقق من أن عوامل الخطر مضبوطة بشكل صحيح على جانب Defender for Cloud. ابحث عن اسم الحاوية في صفحة مخزون Defender for Cloud، وستجد أنه مصنف كحرج.

ملاحظة

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

يضمن التحقق الناجح أن الخطوات التالية، مثل التوصيات، والحملات، وتوليد الأعداد في GitHub، تحقق نتائج ذات معنى.

ملاحظة

بعد تصنيف موردك كحرج، قد يستغرق إرسال البيانات إلى GitHub حتى 12 ساعة من Defender for Cloud. اعرف المزيد.

الخطوة 3: إنشاء حملة GitHub

لإنشاء حملة مسح، يجب أن تعمل على مستوى منظمة GitHub. هذه التجربة غير متوفرة على مستوى المستودع الفردي.

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

الخطوة 4: تعبئة التوصيات

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

في بوابة Defender for Cloud، اذهب إلى تبويب التوصيات .
ابحث عن اسم الحاوية التي أنشأتها من مستودع الكود الخاص بك.
افتح أحد توصيات برنامج التحديث ؛ يبدأ اسم التوصية ب Update
اختر تبويب CVEs المرتبطة تظهر تنبيهات الأمان كجزء من تدفق تقييم التوصيات. توفر هذه التنبيهات مؤشرات حول نتائج GitHub Advanced Security التي يعرفها الهندسيون مسبقا. لاحظ أن بعض معرفات CVE تحتوي على رابط عرض على GitHub في عمود تنبيهات GitHub ذات الصلة.

اختر الرابط لفتح تنبيه الأمان الخاص ب GHAS. (لعرض محتوى تنبيهات GHAS في GitHub، يجب أن يكون لديك صلاحيات الوصول إلى مستودع GitHub المعني. إذا لم يكن لديك صلاحيات دخول، يمكنك دائما نسخ الرابط للاستخدام التالي أو التواصل مع مسؤول GitHub الخاص بك.)

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

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

ماذا بعد ذلك؟ كيف يمكنني معرفة من هو الفريق المناسب للإصلاح؟ كيف يمكنني معرفة أي سياق يمكن أن يساعد في الهندسة في الإصلاح؟

إنشاء مشكلة في GitHub

لسد الحلقة بين فرق الأمن والهندسة، يمكنك إنشاء مشكلة في GitHub تعطي الأولوية لقضايا الأمان التي يجب أن يركز عليها فريق الهندسة. يمكن أن يشمل هذا الترتيب الأولوية تمرير نتائج لم يلتقطها GHAS لكن Defender for Cloud اكتشفها لمعرفات CVE ليست جزءا من التبعيات المباشرة. يمكن أن تشمل هذه النتائج ثغرات في الصورة الأساسية أو نظام التشغيل أو البرمجيات مثل NGINX.

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

من خلال عرض التوصيات، يمكنك إنشاء مشكلة في GitHub بشكل صريح لتتبع أعمال الإصلاح.

اذهب إلى تبويب رؤى الإصلاح وشاهد مخطط الكود إلى وقت التشغيل. يقوم المخطط بتعيين الحاوية التي تعمل بصورة الحاوية في مستودع الكود وإلى مستودع الكود الأصلي في GitHub.
1. في تبويب Remediation Insights (رؤى العلاج )، راجع مربع وقت التشغيل المتأثر.
2. تحقق مما إذا كانت هناك مشكلة GitHub موجودة بالفعل. إذا كانت هناك مشكلة في GitHub موجودة بالفعل، تظهر أيقونة GitHub على الجهاز. مرر المؤشر فوق الأيقونة لعرض تفاصيل المشكلة.
3. إذا لم تكن هناك مشكلة ولديك الأذونات المطلوبة، يمكنك إنشاء مشكلة جديدة في GitHub. حدد اتخاذ إجراء.
4. اختر خيار توليد GitHub المشكلة من النافذة المنبثقة.
5. إذا تم إنشاء المشكلة بنجاح، سترى إشعارا منبثقا يحتوي على رابط للمشكلة. يتم إنشاء الإصدار في مستودع الكود الأصلي.
ملاحظة

إذا لم يكن خيار توليد GitHub متوفرا، فقد تكون صلاحيات GitHub أو المستودع المطلوبة مفقودة. تواصل مع GitHub أو مسؤول المستودع لطلب الوصول.
1. تتبع تحديثات الملكية والحالة - التغييرات في حالة الإصدار أو التنازل التي أجريت في GitHub تنعكس في Microsoft Defender for Cloud، مما يتيح لك تتبع تقدم الملكية والمعالجة من منظور Recommendations.