الإدارة الآمنة للأسرار ومتغيرات البيئة
تجنّبوا تضمين الأسرار بشكل ثابت في الشيفرة المصدرية باستخدام مديري الأسرار (Vault وAWS Secrets Manager) وحقن متغيرات البيئة أثناء التشغيل.
الإدارة الآمنة للأسرار ومتغيرات البيئة درس مجاني في Cloud & IT Cert Prep على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Cloud & IT Cert Prep، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.
مشكلة الأسرار المضمّنة في الشيفرة
تُعد الأسرار المضمّنة في الشيفرة — مثل مفاتيح API، وكلمات مرور قواعد البيانات، ومفاتيح TLS الخاصة، ورموز OAuth المضمّنة مباشرةً في الشيفرة المصدرية — من أكثر الثغرات الأمنية شيوعًا وأسهلها منعًا. وتنكشف الأسرار الموجودة في الشيفرة المصدرية في سجل التحكم بالإصدارات (حتى بعد حذفها)، ويطلع عليها جميع المطورين الذين يملكون صلاحية الوصول إلى المستودع، وغالبًا ما تتسرب عند جعل المستودعات عامة عن طريق الخطأ. وتفحص أدوات مثل GitGuardian وtruffleHog باستمرار المنصات مثل GitHub بحثًا عن الأسرار المتسربة.
# DANGEROUS: hardcoded secret in source code
# db_password = 'P@ssw0rd#2026'
# api_key = 'sk-live-abc123xyz789'
# aws_secret = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
# These secrets are now:
# - In git history (even if later deleted)
# - Visible to all repo contributors
# - Potentially in CI/CD logs
# - Often leaked when repos go public accidentallyمتغيرات البيئة: أفضل، لكنها غير كافية
تزيل متغيرات البيئة الأسرار من الشيفرة المصدرية عبر حقنها وقت التشغيل من خلال نظام التشغيل المضيف أو منسق الحاويات. ويقرأ التطبيق os.environ['DB_PASSWORD'] بدلًا من قيمة مضمّنة في الشيفرة. وهذا أفضل من تضمين الأسرار مباشرةً، لكن لمتغيرات البيئة نقاط ضعف: فهي تظهر في قوائم العمليات، وتنتقل إلى العمليات التابعة، وينتهي بها المطاف غالبًا في تفريغات الأعطال وسجلات تصحيح الأخطاء، كما تتطلب تدويرًا يدويًا. وهي مناسبة للتطوير، لكنها غير كافية وحدها لإدارة أسرار الإنتاج.
# Environment variable pattern:
# In .env file (NEVER commit to git):
# DB_PASSWORD=P@ssw0rd#2026
# API_KEY=sk-live-abc123xyz789
# In .gitignore:
# .env
# *.env
# .env.*
# In application code:
# db_password = os.environ.get('DB_PASSWORD')
# api_key = os.environ.get('API_KEY')
# Risk: env vars visible in 'ps aux' output,
# inherited by child processes, appear in /proc/<pid>/environمديرو الأسرار المتخصصون
مديرو الأسرار هم أنظمة مصممة خصيصًا لتخزين الأسرار وتدويرها وتدقيق الوصول إليها. وتشمل الحلول الرائدة HashiCorp Vault (المفتوح المصدر والمؤسسي)، وAWS Secrets Manager، وAzure Key Vault، وGoogle Cloud Secret Manager. وتصادق التطبيقات على مدير الأسرار وقت التشغيل، وتسترد السر، وتستخدمه — ولا تُخزَّن الأسرار مطلقًا على القرص أو في متغيرات البيئة. ويُسجَّل كل وصول، ما يتيح تدقيق من وصل إلى أي سر ومتى.
# HashiCorp Vault secret retrieval (conceptual):
# Application authenticates to Vault using:
# - AWS IAM role (in cloud environments)
# - Kubernetes service account token
# - AppRole credentials
# After authentication, retrieve secret:
# vault kv get -field=password secret/prod/database
# In application (Python SDK):
# client = hvac.Client(url='https://vault.company.com')
# client.auth.aws.iam_login(role='prod-app')
# secret = client.secrets.kv.read_secret('prod/database')
# db_password = secret['data']['password']التدوير التلقائي للأسرار
تتمثل إحدى المزايا الرئيسية لمديري الأسرار مقارنةً بمتغيرات البيئة في التدوير التلقائي. إذ يمكن لـ AWS Secrets Manager تدوير كلمات مرور قواعد بيانات RDS تلقائيًا وفق جدول زمني (مثلًا كل 30 يومًا) من دون الحاجة إلى إعادة نشر التطبيق. ويحدّث مدير الأسرار كلمة المرور في قاعدة البيانات، ويحدّث السر المخزّن في الوقت نفسه. وتحصل التطبيقات التي تسترد الأسرار عند كل اتصال تلقائيًا على بيانات الاعتماد الجديدة. ويزيل ذلك الممارسة الشائعة المتمثلة في استخدام كلمات مرور «دائمة» لحسابات الخدمة لا يجري تدويرها مطلقًا.
# AWS Secrets Manager rotation configuration:
# Secret: prod/app-database-credentials
# Rotation: enabled
# Frequency: every 30 days
# Lambda function: SecretsManager-MyRDSRotation
# Rotation process:
# 1. Lambda creates new DB password
# 2. Updates secret in Secrets Manager
# 3. Updates password on RDS instance
# 4. Tests new credentials work
# 5. Deprecates old credentials
# Application: always calls GetSecretValue at runtime -> gets fresh valueآلية الدفاع باستخدام .gitignore
يتمثل خط الدفاع الأول ضد الأسرار التي يتم إيداعها في مستودع الشفرة في ملف .gitignore تتم صيانته بشكل صحيح، بحيث يستبعد جميع الملفات التي قد تحتوي على أسرار. ومع ذلك، لا يمنع .gitignore إلا عمليات الإيداع المستقبلية؛ أما الأسرار التي سبق إيداعها فتظل موجودة في سجل git. وإذا أُودعت أسرار عن طريق الخطأ، فيجب التعامل معها فورًا على أنها مكشوفة: قم بتدوير السر، ثم يمكنك اختياريًا استخدام أدوات مثل git filter-repo لإعادة كتابة السجل (وهو أمر مطلوب للامتثال، لكنه غير كافٍ بمفرده لأن السر قد يكون استُخرج بالفعل).
# Recommended .gitignore entries for secret files:
# .env
# .env.*
# *.pem
# *.key
# *.p12
# *.pfx
# credentials.json
# service_account*.json
# secrets.yaml
# config/secrets.yml
# terraform.tfvars (may contain cloud credentials)
# .aws/credentials
# Pre-commit hook to scan for secrets before commit:
# pre-commit install
# hook: detect-secrets / gitleaks / truffleHogأسرار البنية التحتية كتعليمة برمجية
غالبًا ما تحتوي ملفات البنية التحتية كتعليمة برمجية (IaC)، مثل Terraform وCloudFormation وبيانات Kubernetes، على أسرار، ومنها سلاسل اتصال قواعد البيانات ومفاتيح API في تعريفات متغيرات البيئة وشهادات TLS. وغالبًا ما تُودع هذه الملفات في أنظمة التحكم في الإصدارات، مما يؤدي إلى خطر كشف الأسرار. تشمل الحلول الأسرار الديناميكية في Vault (حيث ينشئ Vault بيانات اعتماد قصيرة الأجل مخصصة لكل عملية تشغيل لـ Terraform)، وأسرار Kubernetes (المخزنة في etcd، والتي يجب تشفيرها أثناء التخزين)، وexternal-secrets-operator الذي يزامن الأسرار من مدير أسرار إلى Kubernetes أثناء التشغيل.
مبدأ أقل الصلاحيات للأسرار
ينبغي لكل تطبيق أو خدمة الوصول فقط إلى الأسرار التي يحتاج إليها تحديدًا؛ وهذا هو مبدأ أقل الصلاحيات المطبق على الأسرار. يحتاج تطبيق الويب إلى كلمة مرور قاعدة البيانات، لكنه لا يحتاج إلى المفتاح الخاص لمرجع التصديق (CA). وتحتاج مهمة إعداد التقارير إلى بيانات اعتماد للقراءة فقط من قاعدة البيانات، لا إلى صلاحية الكتابة. يفرض مديرو الأسرار ذلك من خلال سياسات الوصول التي تحدد أي هويات (أدوار IAM وحسابات الخدمة وAppRoles) يمكنها قراءة أي أسرار، مع تسجيل جميع عمليات الوصول لأغراض التدقيق.
# Vault policy: web application can read DB password only
# policy name: web-app-policy
# path 'secret/prod/database' {
# capabilities = ['read']
# }
# path 'secret/prod/tls-certs/*' {
# capabilities = [] # DENY - app does not need TLS keys
# }
# This policy is assigned to the web app's AppRole.
# The reporting service gets a separate policy with
# only 'secret/prod/reporting-db-readonly' access.الأسرار الديناميكية
يتم إنشاء الأسرار الديناميكية عند الطلب لجهة طالبة محددة، وتنتهي صلاحيتها تلقائيًا. يستطيع Vault إنشاء بيانات اعتماد مؤقتة لقاعدة البيانات تكون صالحة لمدة ساعة واحدة، ومرتبطة بالخدمة المحددة التي طلبتها. وبعد انتهاء الصلاحية، تلغي قاعدة البيانات بيانات الاعتماد تلقائيًا. ويعني هذا الأسلوب عدم وجود بيانات اعتماد ثابتة طويلة الأجل يمكن سرقتها؛ وحتى إذا التقط مهاجم بيانات اعتماد ديناميكية، فستنتهي صلاحيتها سريعًا وستكون مرتبطة بهوية الجهة الطالبة في سجلات التدقيق.
# Vault dynamic secrets: temporary DB credentials
# Application calls Vault to get a DB credential:
# vault read database/creds/web-app-role
#
# Vault response:
# username: v-web-app-x7k2m-1234567890 (unique, temporary)
# password: A1b2C3d4E5f6G7h8 (randomly generated)
# lease_duration: 1h (auto-expires)
#
# After 1 hour, Vault instructs DB to revoke this user.
# No static password ever exists for the attacker to steal.الأسرار في مسارات CI/CD
غالبًا ما تتطلب مسارات CI/CD أسرارًا، مثل بيانات اعتماد موفر السحابة للنشر، ورموز Docker Registry، ومفاتيح التوقيع. يُمنع منعًا باتًا تخزين الأسرار في نصوص المسارات أو ملفات الإعداد. بدلًا من ذلك، استخدم مخزن الأسرار المدمج في منصة المسار (GitHub Actions Secrets وGitLab CI Variables وJenkins Credentials Store) أو اجلب الأسرار من خزنة مركزية أثناء التشغيل باستخدام هوية جهاز. ضع علامة الإخفاء على متغيرات الأسرار في السجلات لمنع كشفها عن طريق الخطأ في مخرجات البناء.
# GitHub Actions: using secrets in pipeline
# secrets.yml in GitHub Settings -> Secrets (encrypted storage)
# Secret: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
# In .github/workflows/deploy.yml:
# env:
# AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
# AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
# Best practice: use OIDC federation instead
# GitHub -> AWS trust relationship via OIDC token
# -> No static AWS keys needed at allتدقيق الوصول إلى الأسرار
يوفر مديرو الأسرار سجلات تدقيق شاملة لكل حدث وصول إلى سر: أي هوية وصلت إلى أي سر، ومن أي عنوان IP، وفي أي وقت، وما إذا كان الوصول ناجحًا أو مرفوضًا. وتُعد هذه السجلات أساسية للامتثال (SOC 2 وPCI-DSS) والاستجابة للحوادث. وعند الاشتباه في اختراق بيانات اعتماد، تكشف سجلات التدقيق الأنظمة التي وصلت إليها ووقت ذلك، مما يتيح تحديد الأنظمة التي قد تكون متأثرة بسرعة واتخاذ قرارات الاحتواء.
خطافات ما قبل الإيداع لمنع الأسرار
خطافات ما قبل الإيداع هي نصوص برمجية تعمل تلقائيًا قبل إتمام كل عملية إيداع في git، مما يتيح اكتشاف الأسرار قبل دخولها إلى سجل التحكم في الإصدارات. تتكامل أدوات مثل detect-secrets (Yelp) وGitLeaks وgit-secrets (AWS) كخطافات لما قبل الإيداع، وتفحص الملفات المرحلية بحثًا عن أنماط تطابق مفاتيح API وسلاسل الاتصال والمفاتيح الخاصة ورموز JWT. وإذا اكتُشف سر، تُرفض عملية الإيداع ويُطلب من المطور إزالة بيانات الاعتماد. ويسهّل إطار pre-commit إضافة إعدادات الخطافات ومشاركتها بين الفرق.
# Installing detect-secrets as pre-commit hook:
# 1. Install: pip install detect-secrets
# 2. Create baseline: detect-secrets scan > .secrets.baseline
# 3. Add to .pre-commit-config.yaml:
# repos:
# - repo: https://github.com/Yelp/detect-secrets
# rev: v1.4.0
# hooks:
# - id: detect-secrets
# args: ['--baseline', '.secrets.baseline']
# 4. Install hooks: pre-commit install
# Now every commit attempt is scanned:
# git commit -m 'add config'
# -> detect-secrets runs
# -> if AWS key pattern found: COMMIT BLOCKED
# -> developer must remove secret and use secrets managerتحقق سريع
اختبر مدى فهمك لمفاهيم CompTIA Security+ (SY0-701) الواردة في هذا الدرس.
مراجعة الدرس
تعلمت في هذا الدرس أن الأسرار المضمّنة في الشفرة المصدرية يجب التخلص منها واستبدالها بمديري أسرار مثل Vault أو AWS Secrets Manager، وأن التدوير التلقائي يزيل بيانات الاعتماد طويلة الأجل التي قد يستغلها المهاجمون حتى بعد الاختراق الأولي، وأن الأسرار الديناميكية وسياسات الوصول وفق مبدأ أقل الصلاحيات تقلل من قيمة أي سر منفرد يتم كشفه. بعد ذلك، سنستكشف أمان التبعيات وتحليل تكوين البرمجيات.
الأسئلة الشائعة
هل درس «الإدارة الآمنة للأسرار ومتغيرات البيئة» مجاني؟
نعم — نص درس «الإدارة الآمنة للأسرار ومتغيرات البيئة» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Cloud & IT Cert Prep، انتقل إلى CoddyKit PRO. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.
ماذا ستتعلم في «الإدارة الآمنة للأسرار ومتغيرات البيئة»؟
تجنّبوا تضمين الأسرار بشكل ثابت في الشيفرة المصدرية باستخدام مديري الأسرار (Vault وAWS Secrets Manager) وحقن متغيرات البيئة أثناء التشغيل. تتمرن على Cloud & IT Cert Prep مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Cloud & IT Cert Prep؟
لا تُشترط خبرة سابقة. Cloud & IT Cert Prep على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.
كم من الوقت يستغرق درس «الإدارة الآمنة للأسرار ومتغيرات البيئة»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Cloud & IT Cert Prep هذا؟
نعم. كل درس في Cloud & IT Cert Prep يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- التحقق من المدخلات وترميز المخرجات
- الإدارة الآمنة للأسرار ومتغيرات البيئة
- أمان التبعيات وتحليل تكوين البرمجيات
- DevSecOps: نقل الأمان إلى مراحل مبكرة من مسارات التطوير