تقوية أمن السحابة وKubernetes

إدارة وضعية الأمان السحابي والتهيئة الخاطئة

18 دقيقة الدرس 2 من 28

إدارة وضعية الأمان السحابي والتهيئة الخاطئة

الطريقة الأكثر شيوعًا لاختراق البيئات السحابية ليست من خلال ثغرات يوم الصفر المتطورة — بل من خلال التهيئة الخاطئة. دلو S3 متاح للعموم، ودور IAM يحمل صلاحيات *:*، ومجموعة أمان مفتوحة على 0.0.0.0/0 للمنفذ 22، وخادم Kubernetes API مكشوف للإنترنت مع تمكين المصادقة المجهولة. هذه هي نواقل الهجوم الحقيقية. اختراق Capital One عام 2019، وتسريب Twitch عام 2021، وعشرات الحوادث الأصغر — تشترك جميعها في سبب جذري واحد: قام شخص ما بتهيئة شيء بشكل خاطئ، ولم يلاحظ أحد الأمر حتى فعل ذلك أحد المهاجمين.

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

مشكلة التهيئة الخاطئة على نطاق واسع

تمتلك المؤسسة النموذجية مئات من حسابات AWS (أو مشاريع GCP / اشتراكات Azure) تديرها عشرات الفرق. كل فريق يوفر البنية التحتية عبر Terraform أو CDK أو وحدة التحكم. بدون طبقة وضعية مركزية، تتراكم نتائج الأمان بسرعة أكبر مما تستطيع أي فريق بشري معالجتها. يمكن أن يحتوي حساب AWS واحد على آلاف الموارد؛ وتنظيم من 200 حساب قد يحتوي على مئات الآلاف. المراجعة اليدوية مستحيلة. CSPM هو الأسلوب الوحيد القابل للتطبيق.

تتوسع مساحة الهجوم في ثلاثة أبعاد متزامنة: الاتساع (خدمات ومناطق جديدة يتم تبنيها)، والعمق (خيارات تهيئة أكثر لكل خدمة — S3 وحده يمتلك قوائم التحكم في الوصول على مستوى الكائنات، وسياسات الدلو، وكتل الوصول العام، وإعدادات التشفير، وObject Lock، والنسخ المتماثل، ونقاط نهاية VPC)، والسرعة (البنية التحتية المنشورة عبر CI/CD في دقائق). يجب على منصة CSPM تتبع الأبعاد الثلاثة باستمرار.

مفهوم أساسي: التهيئة الخاطئة هي السبب الأول لحوادث أمان السحابة. يسد CSPM الفجوة بين "ما نشرناه" و"ما تقول سياسة الأمان أننا يجب أن ننشره" — باستمرار، لا وقت التدقيق.

المعايير: أساس فحص الوضعية

فحوصات CSPM ليست آراء اعتباطية. إنها مبنية على معايير أمان منشورة تمثل إجماع الصناعة على شكل التهيئة الآمنة للسحابة:

معايير CIS — ينتج مركز أمان الإنترنت معايير تفصيلية لـ AWS وAzure وGCP وKubernetes. كل فحص مُرقَّم (مثال: CIS AWS 1.4: "تأكد من تدوير مفاتيح الوصول كل 90 يومًا أو أقل")، ومصنَّف حسب مجال التحكم، ومُعيَّن له مستوى ملف تعريف (المستوى 1 = أساسي، المستوى 2 = دفاع متعمق).
NIST SP 800-53 — إطار التحكم الفيدرالي الأمريكي، مُعيَّن لتهيئات السحابة. مطلوب لأعباء العمل FedRAMP.
SOC 2 / ISO 27001 — ضوابط الأمان التشغيلي التي تُعيَّن لتهيئات سحابية محددة.
أفضل ممارسات الأمان التأسيسية من AWS (FSBP) — المعيار الأصلي لـ AWS Security Hub؛ يتم تنظيمه تلقائيًا بواسطة AWS لمجموعة خدماتهم.
PCI DSS — معيار صناعة بطاقات الدفع مع متطلبات تهيئة سحابية محددة لبيئات بيانات حاملي البطاقات.

تُشغِّل معظم عمليات نشر CSPM في بيئة الإنتاج أطر عمل متعددة في آنٍ واحد وتستخدم اتحاد النتائج — المورد الذي يفشل في معيار CIS AWS Level 1 و NIST AC-2 له أولوية أعلى من ذلك الذي يفشل في فحص واحد فقط.

معمارية CSPM: AWS Security Hub على نطاق واسع

AWS Security Hub هو منصة CSPM الأصلية من AWS. يجمع النتائج من الخدمات الأصلية لـ AWS (GuardDuty وInspector وMacie وIAM Access Analyzer وFirewall Manager) والأدوات الخارجية (Wiz وPrisma Cloud وOrca Security) في تنسيق نتائج موحد يسمى ASFF (تنسيق نتائج أمان Amazon).

AWS Security Hub يجمع النتائج من حسابات الأعضاء والأدوات الخارجية في طائرة وضعية واحدة، ثم يوجهها إلى المعالجة ولوحات المعلومات وأنظمة إدارة التذاكر.

يستخدم النشر النموذجي في الشركات الكبرى AWS Organizations مع تفويض Security Hub إلى حساب Security مخصص. يرسل كل حساب عضو النتائج إلى حساب Security تلقائيًا. تفعيل هذا عبر تنظيم من 200 حساب يتطلب استدعاء API واحدًا:

# تفعيل Security Hub عبر جميع حسابات الأعضاء عبر تكامل Organizations
# يُشغَّل من حساب Security (المشرف المفوَّض)

aws securityhub enable-organization-admin-account \
  --admin-account-id 111122223333

# تفعيل تلقائي لجميع الحسابات الحالية والجديدة
aws securityhub update-organization-configuration \
  --auto-enable \
  --auto-enable-standards SECURITY_HUB_DEFAULT

# تفعيل معايير محددة بشكل جماعي (CIS AWS Foundations 1.4)
aws securityhub batch-enable-standards \
  --standards-subscription-requests \
    '[{"StandardsArn":"arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"}]'

فحص الوضعية مع AWS Config Rules وConformance Packs

AWS Config هي طبقة الجرد وتتبع التغييرات الأساسية. كل تغيير في المورد (إنشاء، تعديل، حذف) يُصدر Configuration Item. تُقيِّم Config Rules هذه العناصر مقابل السياسة. Conformance Pack هو مجموعة من Config Rules تمثل إطار امتثال — تنشر ملف YAML واحدًا وتحصل على أكثر من 100 قاعدة عبر حسابك.

# نشر حزمة مطابقة CIS AWS Foundations Benchmark
aws configservice put-conformance-pack \
  --conformance-pack-name CIS-AWS-Foundations-1-4 \
  --template-s3-uri s3://your-bucket/CIS_AWS_Foundations_Benchmark_v1.4.yaml \
  --delivery-s3-bucket your-config-bucket

# استعلام حالة الامتثال الحالية عبر جميع القواعد
aws configservice describe-conformance-pack-compliance \
  --conformance-pack-name CIS-AWS-Foundations-1-4 \
  --query 'ConformancePackRuleComplianceList[?ComplianceType==`NON_COMPLIANT`]' \
  --output table

# كتابة قاعدة Config مخصصة (مُقيِّم Lambda مُدار)
# القاعدة: يجب أن تمتلك جميع دلاء S3 كتلة الوصول العام مُفعَّلة
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-bucket-public-access-block-required",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "S3_BUCKET_LEVEL_PUBLIC_ACCESS_PROHIBITED"
  },
  "Scope": {
    "ComplianceResourceTypes": ["AWS::S3::Bucket"]
  }
}'

ممارسة احترافية: استخدم conformance packs بدلًا من القواعد الفردية. تُنشر حزمة المطابقة بشكل ذري — إذا نشر خط أنابيبك 80 قاعدة وفشل التحقق من القاعدة الستين، تُرجع الحزمة بأكملها بشكل نظيف. والأهم: تمنحك ARN واحدًا للاستعلام عن "هل أنا متوافق مع CIS Level 1؟" بدلًا من تجميع 80 حالة قاعدة فردية.

المعالجة التلقائية: إغلاق الحلقة

الكشف بدون معالجة مجرد ضجيج. القيمة الحقيقية لـ CSPM هي حلقة التغذية الراجعة كشف → معالجة. تُشغِّل نتائج AWS Security Hub قواعد EventBridge؛ يستدعي EventBridge دوال Lambda التي تستدعي AWS API ذات الصلة لإصلاح التهيئة الخاطئة. هذا هو نمط المعالجة التلقائية المستخدم على نطاق واسع.

دالة Lambda للمعالجة لدلو S3 العام تبدو كالتالي (مبسطة):

# قاعدة EventBridge: توجيه نتائج Security Hub لدلو S3 العام إلى Lambda للمعالجة
aws events put-rule \
  --name RemediatePublicS3Bucket \
  --event-pattern '{
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"],
    "detail": {
      "findings": {
        "ProductFields": {
          "ControlId": ["S3.1", "S3.2", "S3.8"]
        },
        "Compliance": {
          "Status": ["FAILED"]
        }
      }
    }
  }'

# دالة معالجة Lambda (Python مُبسَّط):
# import boto3
# def handler(event, context):
#     for finding in event['detail']['findings']:
#         bucket_name = finding['Resources'][0]['Id'].split(':::')[-1]
#         s3 = boto3.client('s3')
#         s3.put_public_access_block(
#             Bucket=bucket_name,
#             PublicAccessBlockConfiguration={
#                 'BlockPublicAcls': True,
#                 'IgnorePublicAcls': True,
#                 'BlockPublicPolicy': True,
#                 'RestrictPublicBuckets': True,
#             }
#         )
#         # تحديث حالة سير عمل النتيجة إلى RESOLVED
#         securityhub.batch_update_findings(...)

فخ إنتاجي: المعالجة التلقائية بدون قائمة استثناءات ستُعطل الأمور. Lambda التي تحجب جميع دلاء S3 العامة بشكل أعمى ستُعطل استضافة المواقع الثابتة، ودلاء أصل CloudFront ذات سياسات عامة مقصودة، وأي دلو جعله فريق التطبيق عامًا عن قصد لأسباب مشروعة. احتفظ دائمًا بـقائمة إخماد (جدول DynamoDB أو معامل SSM) للاستثناءات المعتمدة، وتحقق منها قبل المعالجة. والأهم: اكتب حالة سير عمل النتيجة على SUPPRESSED (ليس RESOLVED) للاستثناءات حتى يكون مسار التدقيق نظيفًا.

CSPM مفتوح المصدر: Prowler وSteampipe

Prowler هو أداة CSPM الرائدة مفتوحة المصدر. تُنفِّذ أكثر من 300 فحص عبر AWS وAzure وGCP وتُخرج النتائج بتنسيق JSON أو ASFF أو CSV أو HTML. تتكامل مباشرة مع خطوط أنابيب CI/CD وSecurity Hub. تشغيل فحص معيار CIS يستغرق ثوانٍ:

# تثبيت Prowler (Python 3.9 أو أعلى)
pip install prowler

# تشغيل CIS AWS Foundations Benchmark المستوى 1 مقابل الحساب/المنطقة الحالية
prowler aws --compliance cis_level1_aws --output-formats json,html --output-directory ./findings

# تشغيل عائلات فحص محددة (IAM وS3 والتسجيل)
prowler aws --services iam s3 cloudtrail --severity high critical

# التكامل مع Security Hub (يرسل نتائج ASFF مباشرة)
prowler aws --security-hub --compliance cis_level2_aws

# التشغيل في CI (رمز الخروج 3 = نتائج فوق العتبة، مفيد لبوابات خط الأنابيب)
prowler aws --compliance cis_level1_aws --exit-code 3 --severity critical high
# if [ $? -eq 3 ]; then echo "CRITICAL findings — blocking deploy"; exit 1; fi

Steampipe يتبع زاوية مختلفة: يُقدِّم موارد سحابتك كجداول SQL حتى تتمكن من الاستعلام عن الوضعية بـ SQL قياسي. هذا قوي للغاية للتحقيقات الفورية والمعايير المخصصة:

-- Steampipe: البحث عن جميع دلاء S3 مع تعطيل الإصدار
SELECT name, region, versioning_enabled
FROM aws_s3_bucket
WHERE versioning_enabled = false
ORDER BY region, name;

-- البحث عن مستخدمي IAM الذين لديهم وصول للوحة التحكم لكن بدون MFA
SELECT name, create_date, mfa_enabled, password_last_used
FROM aws_iam_user
WHERE mfa_enabled = false
  AND password_enabled = true
ORDER BY password_last_used DESC NULLS LAST;

-- مجموعات الأمان مع الدخول الوارد 0.0.0.0/0 على SSH أو RDP
SELECT group_id, group_name, vpc_id, region,
       perm ->> 'FromPort' AS from_port,
       perm ->> 'IpProtocol' AS protocol
FROM aws_vpc_security_group,
     jsonb_array_elements(ip_permissions) AS perm,
     jsonb_array_elements(perm -> 'IpRanges') AS cidr
WHERE cidr ->> 'CidrIp' = '0.0.0.0/0'
  AND (perm ->> 'FromPort')::int IN (22, 3389);

وضعية Kubernetes: kube-bench

لمجموعات Kubernetes، معيار CIS Kubernetes Benchmark هو المرجع. تُشغِّل kube-bench محليًا مقابل أي مجموعة وتُبلِّغ عن اجتياز/فشل لكل تحكم:

# تشغيل kube-bench مقابل المجموعة الحالية (تكتشف تلقائيًا control-plane مقابل node)
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

# أو التشغيل مباشرة على عقدة
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro \
  aquasec/kube-bench:latest \
  --benchmark cis-1.8

# تحكمات CIS Kubernetes الرئيسية للتحقق منها:
# 1.1.1 - صلاحيات ملف kube-apiserver.yaml (يجب أن تكون 600)
# 1.2.1 - خادم API anonymous-auth=false
# 1.2.6 - مسار سجل تدقيق خادم API مُهيَّأ
# 4.2.1 - تعطيل المصادقة المجهولة لـ Kubelet
# 5.1.1 - عدد ارتباطات دور cluster-admin

الكشف عن الانجراف وفحص بوابة خط الأنابيب

يجب أن يحدث فحص الوضعية في مكانين: باستمرار (كل تغيير في التهيئة يُشغِّل إعادة تقييم) وقبل النشر (يتم فحص خطط Terraform ومانيفستات Kubernetes قبل وصولها إلى الإنتاج). البوابة قبل النشر تُمسك بالتهيئات الخاطئة قبل أن توجد، لا بعدها.

أدوات مثل Checkov (فاحص IaC لـ Terraform/Kubernetes/CloudFormation) وtfsec تُوصَّل بخط أنابيب CI كبوابة جودة. مجموعة أمان مفتوحة على 0.0.0.0/0 في خطة Terraform تُفشل خط الأنابيب قبل أن يُشغَّل terraform apply:

# تشغيل Checkov مقابل خطة Terraform (الفشل عند شدة HIGH)
checkov -d ./terraform --framework terraform \
  --check CKV_AWS_24,CKV_AWS_25,CKV_AWS_53 \
  --compact --output cli

# أو فحص جميع الأطر دفعة واحدة مع عتبة الشدة
checkov -d . --soft-fail-on MEDIUM --hard-fail-on HIGH,CRITICAL

# مقتطف GitHub Actions: بوابة PR على Checkov
# - name: Run Checkov IaC scan
#   uses: bridgecrewio/checkov-action@master
#   with:
#     directory: terraform/
#     framework: terraform
#     soft_fail: false
#     check: CKV_AWS_*

ممارسة الشركات الكبرى: النمط الناضج هو "انزلاق لليسار + كشف لليمين." شغِّل Checkov/tfsec في خط أنابيب PR (انزلاق لليسار) وشغِّل Prowler/Config باستمرار في الإنتاج (كشف لليمين). تمنع بوابة PR التهيئات الخاطئة الجديدة؛ يكتشف الفاحص المستمر الانجراف في التهيئة من تغييرات وحدة التحكم، أو الإصلاحات اليدوية، أو الإعدادات الافتراضية للخدمة التي تغيرت بعد آخر تطبيق لـ Terraform. كلتا الطبقتين مطلوبتان — لا تكفي أي منهما وحدها.

قياس الامتثال وتتبع مستوى الخدمة

CSPM لا يتعلق فقط بإيجاد الأخطاء الفردية — بل بإثبات تحسن الوضعية بمرور الوقت. يوفر Security Hub درجة امتثال على مستوى الحساب لكل معيار (0–100%). تُحدِّد فرق الأمان في الشركات الكبرى مستويات خدمة حسب الشدة: معالجة النتائج الحرجة في غضون 24 ساعة، والعالية في غضون 7 أيام، والمتوسطة في غضون 30 يومًا. يتم تتبع هذه المستويات عبر مقاييس Security Hub المُصدَّرة إلى CloudWatch وعرضها على لوحة معلومات عمليات الأمان.

المقياس الأهم ليس "عدد النتائج" — بل متوسط وقت المعالجة (MTTR) حسب الشدة. فريق لديه 500 نتيجة جميعها معالجة ضمن مستوى الخدمة أكثر أمانًا من فريق لديه 50 نتيجة حيث 10 نتائج حرجة مفتوحة منذ 45 يومًا.