الامتثال والسياسات ككود

اكتشاف الانجراف والامتثال المستمر

18 دقيقة الدرس 9 من 27

اكتشاف الانجراف والامتثال المستمر

يُحدّد "الكود كسياسة" ما يجب أن تبدو عليه بنيتك التحتية. أما اكتشاف الانجراف فيجيب على السؤال الأصعب: هل لا تزال تبدو هكذا الآن؟ في بيئات الإنتاج، تتسع الهوة بين الحالة المطلوبة والحالة الفعلية باستمرار — يُطبّق المهندسون إصلاحات يدوية طارئة، وتُحدّث مزودو الخدمات السحابية الإعدادات الافتراضية، وتنشئ آليات التوسع التلقائي موارد لم تكن في Terraform أصلاً، وتُغيّر واجهات برمجة التطبيقات سلوكها بصمت. يُغلق الامتثال المستمر هذه الحلقة باكتشاف الانجراف والتنبيه عنه ومعالجته قبل أن يتحول إلى نتيجة أمنية أو إخفاق في التدقيق.

ما هو الانجراف ولماذا يحدث؟

الانجراف هو أي انحراف بين الحالة المطلوبة المُعلنة (ملف حالة Terraform، بيان Kubernetes، النسخة الذهبية من AMI، سياسة OPA) والمورد الحي. هناك ثلاثة أسباب جذرية ستواجهها بشكل متكرر في بيئات الإنتاج:

التغييرات الطارئة: يُطبّق مهندس في فريق الاستجابة الطارئة تغييراً يدوياً عبر AWS Console في الساعة الثانية صباحاً لوقف انقطاع في الإنتاج، ولا يُرمَّز هذا التغيير أبداً.
التأثيرات الجانبية للأتمتة: التوسع التلقائي، وإطار عمل Lambda، ومُزوّد عُقد Kubernetes التلقائي، وتحديثات مجموعات معاملات RDS — كلها تنشئ أو تُعدّل موارد خارج نطاق IaC.
التعديل الخارجي: يُهمل مزود الخدمة السحابية إصداراً من TLS، أو يُغيّر إعداد التشفير الافتراضي، أو يُدوّر موارد الأجهزة الأساسية، مما يُغيّر الحالة الفعلية للمورد دون أي إجراء من جانبك.

الانجراف ليس مشكلة بنية تحتية فحسب — إنه مشكلة امتثال. كل إطار تدقيق (SOC 2، ISO 27001، PCI DSS) يشترط أن تطابق بيئتك الضوابط الموثقة. الانجراف الصامت يعني أن شهاداتك خاطئة، وهذا أسوأ من عدم وجود شهادة على الإطلاق.

اكتشاف الانجراف في Terraform عملياً

يُعدّ terraform plan أبسط أداة لاكتشاف الانجراف للموارد المُدارة بـ IaC. شغّله في وضع القراءة فقط مقابل واجهة برمجة التطبيقات الخاصة بالمزود، وسيُبلّغ عن الفرق بين الحالة والواقع. في خطوط CI/CD، النمط المعتمد هو مهمة "خطة اكتشاف الانجراف" المجدولة التي تستخدم -detailed-exitcode (كود الخروج 2 يعني وجود انجراف) وتُطلق تنبيهاً إن كان الكود غير صفر.

# .github/workflows/drift-detection.yml
name: Terraform Drift Detection

on:
  schedule:
    - cron: '0 */4 * * *'   # كل 4 ساعات
  workflow_dispatch:

jobs:
  detect-drift:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # OIDC — لا بيانات اعتماد طويلة الأمد
      contents: read

    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/TerraformReadOnly
          aws-region: us-east-1

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.8.0

      - name: Terraform Init
        run: terraform init -input=false
        working-directory: ./infra

      - name: Detect Drift
        id: plan
        # exit 0 = لا تغييرات، 1 = خطأ، 2 = انجراف مكتشف
        run: |
          set +e
          terraform plan -detailed-exitcode -input=false -out=drift.tfplan
          echo "exit_code=$?" >> "$GITHUB_OUTPUT"
        working-directory: ./infra

      - name: Alert on Drift
        if: steps.plan.outputs.exit_code == '2'
        run: |
          curl -X POST "$SLACK_WEBHOOK" \
            -H 'Content-type: application/json' \
            --data '{"text":":rotating_light: تم اكتشاف انجراف في Terraform في الإنتاج. راجع سجل التشغيل."}'
        env:
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}

لا تُشغّل terraform apply تلقائياً رداً على الانجراف. تحقق أولاً من أن الانجراف غير مقصود — فقد يكون تغييراً مشروعاً خارج النطاق ينبغي استيراده لا الكتابة فوقه. التطبيق الأعمى التلقائي يمكن أن يحذف موارد إنتاجية تم إنشاؤها خارج نطاق IaC عمداً.

AWS Config للامتثال المستمر للموارد

يُغطي اكتشاف انجراف Terraform الموارد التي تُديرها Terraform فقط. أما AWS Config فيُغطي كل شيء في حسابك — الموارد التي أنشأتها أدوات أخرى، أو AWS Console، أو AWS نفسها. يُسجّل Config تغييرات الإعداد باستمرار ويُقيّمها مقابل القواعد التي تُحدّدها. عند خروج مورد عن الامتثال، يُطلق Config نتيجة يمكن توجيهها إلى Security Hub أو SNS أو دالة Lambda للمعالجة.

خط أنابيب الامتثال المستمر: يُقيّم AWS Config الموارد الحية مقابل القواعد، ويُوجّه النتائج إلى Security Hub، ويُشغّل EventBridge للمعالجة التلقائية عبر Lambda، ويُنبّه فرق الاستجابة الطارئة.

أكثر قواعد AWS Config تأثيراً على نطاق واسع هي required-tags (فرض وسوم تخصيص التكلفة والملكية على جميع الموارد) وencrypted-volumes (اكتشاف وحدات تخزين EBS غير المشفرة). كلتاهما قواعد مُدارة من AWS لا تتطلب كتابة أي Lambda.

# Terraform: نشر قاعدة Config مع معالجة تلقائية عبر SSM Automation
resource "aws_config_config_rule" "encrypted_volumes" {
  name = "encrypted-volumes"

  source {
    owner             = "AWS"
    source_identifier = "ENCRYPTED_VOLUMES"
  }

  depends_on = [aws_config_configuration_recorder.main]
}

# المعالجة: عند وجود NON_COMPLIANT، استدعاء مستند SSM لتشفير الوحدة
resource "aws_config_remediation_configuration" "encrypt_volumes" {
  config_rule_name = aws_config_config_rule.encrypted_volumes.name
  target_type      = "SSM_DOCUMENT"
  target_id        = "AWSConfigRemediation-EncryptUnencryptedVolume"

  automatic                  = true
  maximum_automatic_attempts = 3
  retry_attempt_seconds      = 60

  parameter {
    name           = "AutomationAssumeRole"
    static_value   = aws_iam_role.config_remediation.arn
  }
  parameter {
    name           = "VolumeId"
    resource_value = "RESOURCE_ID"
  }
}

Kubernetes: المزامنة المستمرة كضبط للانجراف

في Kubernetes، يُعالَج الانجراف بشكل مختلف لأن مستوى التحكم يُزامن باستمرار. إذا حررت يدوياً نشراً مُداراً بواسطة Flux أو ArgoCD باستخدام kubectl edit، سيكتشف متحكم GitOps التناقض في دورة المزامنة التالية ويُعيد المورد إلى الحالة المُعلنة في Git — عادةً في غضون 30 إلى 90 ثانية. هذا يجعل GitOps آلية التحكم في الانجراف الأقوى لأحمال عمل Kubernetes.

للحالات التي يجب فيها اكتشاف الانجراف بدلاً من إعادته تلقائياً (مثل كائنات RBAC أو NetworkPolicy التي حذفها شخص ما يدوياً)، استخدم kubectl diff -f manifests/ في مهمة CI مجدولة لمقارنة حالة الكلاستر الحي مع بيانات Git.

# فحص الانجراف المجدول لـ Kubernetes — مقارنة بيانات Git مع الكلاستر الحي
#!/bin/bash
set -e

KUBECONFIG=/run/secrets/kubeconfig
MANIFEST_DIR=./k8s/production

echo "=== تقرير انجراف Kubernetes $(date -u) ==="

# kubectl diff يخرج 0 إذا كانت متطابقة، 1 إذا كانت هناك اختلافات
kubectl --kubeconfig="$KUBECONFIG" diff -f "$MANIFEST_DIR" | tee /tmp/drift-report.txt
EXIT_CODE=${PIPESTATUS[0]}

if [ "$EXIT_CODE" -eq 1 ]; then
  echo "تم اكتشاف الانجراف — إرسال تنبيه"
  curl -s -X POST "$SLACK_WEBHOOK" \
    -H 'Content-type: application/json' \
    -d '{"text":"⚠️ تم اكتشاف انجراف في Kubernetes في الإنتاج. راجع تقرير الانجراف."}'
  exit 1
fi

echo "لم يُكتشف أي انجراف."

في Google، تتعامل فرق SRE مع كل فارق غير مُزامَن باعتباره حادثة من المستوى الثالث يجب إغلاقها في غضون 24 ساعة. الانضباط ليس في الأدوات — بل في التوقع الثقافي بأن البيئة المتباينة خطر نشط لا ضوضاء خلفية. ضمّن هذا التوقع في دفاتر تشغيل الاستجابة الطارئة.

التقارير المستمرة للامتثال

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

نسبة الامتثال عبر الزمن: تتبّع نسبة الموارد الممتثلة إلى الإجمالي في مقياس متسلسل زمنياً. يعرض جدول امتثال AWS Config واتجاهات نتائج Security Hub هذا أصلاً. في Kubernetes، تُصدّر أدوات مثل Falco وPolaris مقاييس Prometheus يمكنك رسمها في Grafana.
متوسط وقت المعالجة (MTTR): أطلق تنبيهاً عندما تظل أي نتيجة مفتوحة أطول من SLA المتفق عليه (مثال: حرج = 24 ساعة، مرتفع = 72 ساعة). هذا مقياس رئيسي في تدقيقات SOC 2 من النوع الثاني.
قابلية تتبع التغييرات: يجب ربط كل إجراء معالجة بتذكرة (JIRA، Linear) ومرتبطة بالنتيجة المحددة. يجب أن تكتب دوال Lambda للمعالجة سجلاً منظماً يتضمن معرّف المورد، ومعرّف النتيجة، والإجراء المتخذ، والطابع الزمني — إلى CloudWatch Logs Insights لإمكانية الاستعلام.

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