إدارة أسرار GitHub Actions: حماية مفاتيح API وكلمات المرور في سير العمل

By Mirko Peters · 2026-10-26

تعرّف على كيفية تأمين خطوط CI/CD لديك باستخدام أسرار GitHub Actions بالشكل الصحيح. اكتشف أفضل الممارسات لإدارة مفاتيح API ورموز الوصول بأمان.

Automatically translated with AI from the original post. Read the English original

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

النقاط الرئيسية

• لا تضمّن أبدًا كلمات المرور الحساسة أو مفاتيح API أو رموز الوصول بشكل ثابت (Hardcoded) داخل ملفات YAML الخاصة بسير العمل.
• توفر GitHub ثلاثة مستويات من الأسرار: أسرار المستودع، وأسرار المؤسسة، وأسرار البيئة.
• تُشفَّر الأسرار قبل وصولها إلى GitHub، وتُخفى تلقائيًا داخل سجلات التشغيل.
• يمكن لأسرار البيئة أن تفرض موافقة بشرية قبل أن تصبح بيانات اعتماد النشر متاحة لمهمة ما.
• اتبع دائمًا مبدأ أقل الصلاحيات، بحيث يُمنح كل سر أصغر مجموعة ممكنة من الأذونات اللازمة.

لماذا تفشل بيانات الاعتماد النصية الصريحة في CI/CD

يغري المطورين المستعجلين لإعداد خط أنابيب جديد بلصق مفتاح API مباشرة في ملف إعدادات سير العمل. فبعد كل شيء، إذا كان سير العمل خاصًا، فمن سيراه؟ هذه العقلية تُدخل ثغرات أمنية خطيرة. فملفات سير العمل مُدارة بالإصدارات، أي أن كل مراجعة تاريخية وكل commit وكل فرع يحتفظ بسجل دائم لكل ما كُتب داخل مستندات YAML هذه.

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

المستويات الثلاثة لأسرار GitHub

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

أسرار على مستوى المستودع

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

أسرار على مستوى المؤسسة

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

أسرار على مستوى البيئة

تربط أسرار البيئة بيانات الاعتماد بأهداف نشر محددة مثل بيئتي الاختبار والإنتاج. وهنا تُخزَّن المفاتيح اللازمة للوصول إلى الأنظمة الحية. والأهم أن أسرار البيئة تتيح لك تعيين مراجعين مطلوبين، بحيث يجب أن يوافق شخص بشري يدويًا على تشغيل النشر قبل أن تُفتح بيانات اعتماد الإنتاج وتُسلَّم إلى المشغّل.

كيف تحمي GitHub بياناتك أثناء النقل

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

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

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

أفضل الممارسات للأتمتة الآمنة

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

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

الخاتمة

إتقان إدارة أسرار GitHub Actions يحوّل خطوط CI/CD الخاصة بك من مصادر محتملة للمخاطر الأمنية إلى محركات أتمتة متينة من فئة المؤسسات. فمن خلال فصل بيانات الاعتماد عن شيفرتك، والاستفادة من ضوابط وصول متعددة المستويات، يمكنك تسليم البرمجيات بسرعة دون التفريط في الأمان.

لاستكشاف أساسيات بناء سيرات العمل الآلية، اطّلع على استمع إلى الحلقة الكاملة. وتابع النقاش الكامل لتتعرف أكثر على إعداد المشغّلات والمهام وrunners لبيئتك السحابية الحديثة!

الأسئلة المتداولة

هل يمكنني قراءة سر GitHub Actions داخل طلب سحب من فرع منسوخ (Fork)؟

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

كيف أمرّر سرًا من سير العمل إلى خطوة محددة؟

تمرر الأسرار إلى سير العمل باستخدام السياق 'env' داخل خطوة أو مهمة، بربط سر GitHub بمتغير بيئة، مثل env: API_KEY: ${{ secrets.MY_API_KEY } }.

هل أسرار GitHub Actions مخفية في السجلات بشكل مضمون؟

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

ما الفرق بين أسرار المستودع وأسرار البيئة؟

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