إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة

في أي مشروع يعتمد على CI/CD أو الأتمتة السحابية، تظهر مشكلة حساسة جداً: كيف نمنح أنظمة النشر صلاحية الوصول إلى الخوادم والخدمات الخارجية من دون كشف كلمات المرور أو مفاتيح API داخل المستودع؟ هنا يأتي دور GitHub Secrets كطبقة أساسية لحماية بيانات الاعتماد المستخدمة في التشغيل الآلي.

إذا كنت قد قرأت مقال ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ فستعرف أن أي خط نشر حديث يحتاج إلى الوصول إلى سجلات حاويات، خوادم، قواعد بيانات، أو مزودي سحابة. تخزين هذه المعلومات بشكل صريح داخل ملفات YAML أو داخل الكود نفسه هو خطأ أمني شائع قد يتحول إلى اختراق كامل للبنية.

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

ما هي GitHub Secrets ولماذا نحتاجها؟

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

• كلمة مرور خادم عبر SSH
• مفتاح خاص لنشر الملفات
• رمز وصول إلى Docker Hub
• مفتاح خدمة سحابية مثل AWS أو GCP
• رمز تطبيق خارجي لإرسال إشعارات أو تشغيل Webhook

الميزة الحقيقية ليست مجرد الإخفاء، بل العزل التشغيلي. أي أن السر لا يصبح جزءاً من سجل Git ولا من تاريخ التعديلات، ولا من ملفات البنية مثل Dockerfile أو إعدادات التطبيق.

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

أين تُخزن الأسرار داخل دورة الأتمتة؟

في العادة يوجد ثلاث طبقات رئيسية: أسرار على مستوى المستودع، أسرار على مستوى المؤسسة، وأسرار مرتبطة ببيئة مثل staging وproduction. هذا التقسيم مهم لأن كل بيئة تحتاج مفاتيح مختلفة وخط وصول منفصل.

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

أفضل توزيع للأسرار

• أسرار عامة مشتركة على مستوى المؤسسة للخدمات المركزية
• أسرار خاصة بكل مشروع على مستوى المستودع
• أسرار شديدة الحساسية على مستوى البيئة مع موافقات نشر يدوية
• حساب خدمة منفصل لكل تطبيق أو بيئة

إضافة السر واستخدامه داخل Workflow

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

name: Deploy Application

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout source code
        uses: actions/checkout@v4

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Deploy over SSH
        env:
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USER: ${{ secrets.SSH_USER }}
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
        run: |
          mkdir -p ~/.ssh
          echo "$SSH_KEY" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H "$SSH_HOST" >> ~/.ssh/known_hosts
          ssh "$SSH_USER@$SSH_HOST" "cd /var/www/app && ./deploy.sh"

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

الفرق بين الأسرار والمتغيرات البيئية

كثير من المبتدئين يخلطون بين Secrets وEnvironment Variables. المتغير البيئي وسيلة لتمرير قيمة أثناء التشغيل، لكنه ليس بالضرورة آمناً. أما السر فهو قيمة حساسة مخزنة بشكل مخصص ثم يمكن حقنها كمتغير بيئي عند الحاجة.

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

متى تستخدم كل واحد؟

• استخدم Secrets للبيانات الحساسة
• استخدم Variables للقيم التشغيلية غير الحساسة
• مرر السر إلى الخطوة المطلوبة فقط لتقليل مساحة التعرض

أخطاء أمنية شائعة عند استخدام GitHub Secrets

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

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

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

تصميم أمني أقوى: تدوير الأسرار وتقليل الصلاحيات

أفضل ممارسة احترافية هي اعتبار كل سر قابلاً للتسرب يوماً ما، ثم بناء النظام بحيث يكون أثر التسرب محدوداً. يتحقق ذلك عبر مبدأ Least Privilege وتدوير المفاتيح بشكل دوري.

1. أنشئ حساب خدمة مستقل لكل تطبيق
2. امنح كل حساب أقل صلاحيات ممكنة
3. استخدم أسرار مختلفة بين development وproduction
4. دوّر الرموز والمفاتيح بعد أي تغيير فريق أو حادثة أمنية
5. راقب سجلات الاستخدام غير المعتاد في مزود السحابة أو سجل الحاويات

كما أن دمج هذه السياسة مع حماية الفروع (Branch Protection) ومنع رفع الأكواد الخاطئة للنسخة الحية يجعل الوصول إلى أسرار الإنتاج مرتبطاً بمسار مراجعة منضبط، وليس بمجرد عملية push عادية.

مثال عملي: حقن مفتاح API لتشغيل اختبار تكاملي

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

name: Integration Tests

on:
  push:
    branches:
      - main
      - develop

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run integration tests
        env:
          PAYMENT_API_KEY: ${{ secrets.PAYMENT_API_KEY }}
        run: |
          ./scripts/run-integration-tests.sh

هذا الأسلوب يقلل انتشار السر داخل الجلسة التشغيلية، ويجعل التحليل الأمني أسهل عند مراجعة ملفات Workflow المعقدة التي تُبنى تدريجياً كما في بناء أوامر YAML لأتمتة تشغيل السكربتات التلقائية عند كل Push.

متى لا تكفي GitHub Secrets وحدها؟

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

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

الخلاصة

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

استخدام GitHub Secrets بالشكل الصحيح يعني: فصل البيئات، تقليل الصلاحيات، منع التسرب في السجلات، وتدوير المفاتيح بشكل دوري. وعندما تُبنى هذه الممارسات داخل ملفات Workflow منذ البداية، يصبح خط النشر أكثر أماناً واعتمادية وقابلية للتوسع.