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

مشروع: تصليب بيئة سحابية و Kubernetes

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

مشروع: تصليب بيئة سحابية و Kubernetes

كل درس في هذا البرنامج التعليمي قدّم فئة من فئات التحكم بشكل منفصل — IAM، والشبكة، وأمان الـ Pod، وتصليب الكلاستر، وأمان وقت التشغيل، والثقة الصفرية، وCSPM، والاستجابة للحوادث. التحدي الحقيقي هو تطبيقها جميعًا بشكل متماسك على بنية إنتاج واحدة، وحل التعارضات، وترتيب العمل بحيث لا يتوقف النظام الحي، وإثبات للمراجعين وفريق SRE أن التصليب يصمد عبر الزمن.

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

البنية المرجعية

تتكون البيئة النموذجية من:

حساب AWS بثلاثة بيئات (dev وstaging وprod) في VPC منفصلة.
كلاستر EKS 1.29 في VPC الإنتاج يشغّل عشرة خدمات مصغّرة، وقاعدة بيانات PostgreSQL على RDS، وكلاستر Redis على ElastiCache.
دلو S3 للملفات التي يرفعها المستخدمون، وتوزيع CloudFront، وموازن حمل ALB أمام الكلاستر.
ECR كسجل للحاويات، وGitHub Actions كنظام CI/CD، وTerraform Cloud لإدارة البنية التحتية.
Prometheus وGrafana وLoki للمراقبة، وFalco لأمان وقت التشغيل.

البنية المحصّنة: كل طبقة من الإنترنت وصولًا إلى طبقة البيانات تخضع لضوابط صريحة.

المرحلة الأولى — أساس حساب AWS وIAM

قبل الاقتراب من الكلاستر، أحكم تأمين الحساب نفسه. شغّل فحوصات AWS Security Hub وConfig لتأسيس نقاط مرجعية:

# تفعيل Security Hub مع معيار CIS AWS Foundations
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

# التحقق من أن حساب الجذر لديه MFA ولا توجد مفاتيح وصول نشطة
aws iam get-account-summary | jq '.AccountMFAEnabled, .AccountAccessKeysPresent'
# المتوقع: 1 (MFA مفعّل)، 0 (لا مفاتيح جذر)

# قائمة بمستخدمي IAM الذين يملكون وصولًا للوحة التحكم ولا يملكون MFA
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F',' 'NR>1 && $4=="true" && $8=="false" {print $1, "NO MFA"}'

# إرفاق حدود صلاحيات بكل دور IAM لتقليل نطاق الضرر
aws iam put-role-permissions-boundary \
  --role-name EngineerRole \
  --permissions-boundary arn:aws:iam::123456789012:policy/OrgMaxPermissions

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

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name acme-audit-logs-immutable \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --include-global-service-events

aws cloudtrail start-logging --name org-trail

# سياسة دلو S3 على حساب التسجيل — رفض حذف الكائنات لأي شخص
# "Effect": "Deny",
# "Principal": "*",
# "Action": ["s3:DeleteObject","s3:DeleteBucket","s3:PutBucketPolicy"],
# "Resource": "arn:aws:s3:::acme-audit-logs-immutable/*"

المرحلة الثانية — تصليب الشبكة

راجع كل مجموعة أمان في VPC الإنتاج بحثًا عن دخول غير مقيّد (0.0.0.0/0) على منافذ غير HTTP. يجب أن تقبل مجموعات عقد EKS الحركة فقط من مجموعة أمان ALB على منفذ التطبيق، ومن مجموعة أمان المستوى التحكمي للكلاستر على منفذ Kubelet (10250). يجب أن يقبل RDS الحركة فقط من مجموعة أمان عقد EKS على المنفذ 5432.

# البحث عن مجموعات الأمان ذات الدخول غير المقيّد
aws ec2 describe-security-groups \
  --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query 'SecurityGroups[*].[GroupId,GroupName,IpPermissions[*].FromPort]' \
  --output table

# تطبيق NetworkPolicy في Kubernetes: رفض كل الدخول افتراضيًا ثم السماح بشكل انتقائي
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

kubectl apply -f k8s/netpol-default-deny.yaml

المرحلة الثالثة — قائمة تصليب كلاستر EKS

اعمل بهذه القائمة على كلاسترك. كل بند يقابل ضابطًا في معيار CIS EKS Benchmark:

وصول نقطة نهاية خادم API — عطّل النقطة العامة أو قيّدها بنطاق IP الشركة. فعّل النقطة الخاصة. استخدم eksctl utils update-cluster-endpoints.
تشفير Secrets بمفاتيح KMS — تأكد من ضبط --encryption-config بمفتاح KMS. تحقق: aws eks describe-cluster --name prod --query 'cluster.encryptionConfig'.
مراجعة RBAC — اسرد جميع ClusterRoleBindings لـcluster-admin. يجب ألا تكون هناك سوى إعدادات النظام الافتراضية وحساب الطوارئ.
معايير أمان Pod — ضع تسمية pod-security.kubernetes.io/enforce: restricted على جميع نطاقات الإنتاج.
IMDSv2 على مجموعات العقد — يجب أن تضبط جميع قوالب الإطلاق HttpTokens: required وHttpPutResponseHopLimit: 1 لمنع هجمات SSRF من مستوى Pod.
IRSA بدلًا من أدوار العقد — كل حساب خدمة يحتاج وصولًا لـ AWS يجب أن يستخدم IAM Roles for Service Accounts، وليس سياسة دور عقدة شاملة.

# مراجعة ClusterRoleBindings لـ cluster-admin
kubectl get clusterrolebindings \
  -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

# فحص تسميات أمان Pod على النطاقات
kubectl get namespaces -o json | jq '.items[] | {name: .metadata.name, pss: .metadata.labels}'

# تطبيق PSS المقيّد على نطاق الإنتاج
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.29 \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

# التحقق من تشفير EKS بـ KMS
aws eks describe-cluster --name prod \
  --query 'cluster.encryptionConfig[*].{Resources:resources,KMSKey:provider.keyArn}'

المرحلة الرابعة — إدارة الأسرار

استبدل جميع كائنات Secret في Kubernetes التي تخزّن بيانات اعتماد نصية بـ Vault Agent Injector أو Secrets Store CSI Driver المدعوم بـ AWS Secrets Manager. دوّر كل بيانات اعتماد طويلة الأمد وجدتها في المراجعة. اضبط حدًا أقصى لمدة صلاحية 90 يومًا لأي سر ثابت في Vault.

# تثبيت Secrets Store CSI Driver ومزوّد AWS
helm repo add secrets-store-csi-driver \
  https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
helm install csi-secrets-store \
  secrets-store-csi-driver/secrets-store-csi-driver \
  -n kube-system --set syncSecret.enabled=true

helm repo add aws-secrets-manager \
  https://aws.github.io/secrets-store-csi-driver-provider-aws
helm install -n kube-system awssmp aws-secrets-manager/secrets-store-csi-driver-provider-aws

# SecretProviderClass يشير إلى AWS Secrets Manager
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: db-credentials
  namespace: production
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "prod/db/password"
        objectType: "secretsmanager"

المرحلة الخامسة — أمان سلسلة التوريد والصور

يجب أن تكون كل صورة تعمل في الإنتاج موقّعة بـ Cosign ومُتحقَّق منها بواسطة سياسة OPA Gatekeeper عند الدخول. يجب أن تحذف سياسة دورة حياة ECR الصور غير المُوسَمة بعد 14 يومًا، ويجب أن يشغّل سير عمل GitHub Actions أداة Trivy على كل طلب سحب ويمنع الدمج عند وجود ثغرات CRITICAL.

# توقيع الصورة بعد الرفع (في CI)
cosign sign --key cosign.key \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:1.4.2

# التحقق من التوقيع (في webhook القبول أو قيد Gatekeeper)
cosign verify --key cosign.pub \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:1.4.2

# فحص Trivy في GitHub Actions — الحظر عند CRITICAL
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:1.4.2
    exit-code: '1'
    severity: 'CRITICAL'
    ignore-unfixed: true

المرحلة السادسة — الكشف في وقت التشغيل والامتثال المستمر

يجب أن يكون Falco يعمل بالفعل من درس أمان وقت التشغيل. تحقق من تفعيل هذه القواعد على الأقل: shell spawned in container، وwrite to /etc in container، وunexpected outbound connection، وprivilege escalation via sudo. أرسل تنبيهات Falco إلى PagerDuty عبر تكامل Falco Sidekick. أعدّ تقريرًا أسبوعيًا من Security Hub يُرسَل بالبريد الإلكتروني لقيادة الهندسة. جدوّل فحصًا ربع سنوي لمعيار CIS باستخدام Kube-bench كـ CronJob.

# تشغيل kube-bench كـ Job واحد لإنتاج نتيجة CIS
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench 2>&1 | grep -E "PASS|FAIL|WARN" | tail -40

# تأكيد أن Falco يرصد قاعدة shell-in-container
kubectl exec -it -n production deploy/api -- /bin/sh 2>/dev/null || true
# يجب أن يصدر Falco: Warning Spawned Shell in Container (proc.name=sh)

# فحص تغطية قواعد Falco
kubectl exec -n falco ds/falco -- falco --list | grep -c "rule:"

قائمة التصليب وثيقة حية. تظهر الثغرات يوميًا، وتغيّر إصدارات Kubernetes السلوكيات الافتراضية، وتتطور بنيتك التحتية. أودع قائمة التصليب الكاملة كملف Markdown في مستودع البنية التحتية وشغّلها في كل مراجعة أمنية ربع سنوية. وثّقها وأرّخها ووقّع على كل تشغيل. سيطلب المراجعون في مراجعات SOC 2 وISO 27001 هذه الوثيقة تحديدًا.

إثبات الصمود: التحقق المستمر من الضوابط

التصليب الذي يُطبَّق مرة واحدة يتدهور. يتناوب المهندسون، تنجرف حالة Terraform، وتُنشَر أعباء عمل جديدة دون المرور عبر القائمة. استخدم هذه الآليات لضمان بقاء الضوابط في مكانها:

قيود OPA Gatekeeper لكل قاعدة أمان Pod وتوقيع صورة — تُرفض عند الدخول، لا تُكتشف بعد النشر.
قواعد AWS Config لكل ضابط على مستوى الحساب — دوالّ Lambda للمعالجة التلقائية للقواعد منخفضة الخطورة، وتنبيهات للمراجعة البشرية للقواعد عالية الخطورة.
Trivy Operator يعمل داخل الكلاستر، يفحص أعباء العمل الجارية باستمرار ويكتب النتائج في CRDs من نوع VulnerabilityReport. أنشئ تنبيهًا في Grafana عند ظهور ثغرة CRITICAL في صورة جارية.
Terraform Sentinel أو Checkov في كل طلب سحب — يحظر أي تغيير بنية تحتية يفتح مجموعة أمان لـ0.0.0.0/0، أو يعطّل التشفير، أو يحذف مسار المراجعة.

ابدأ بالضوابط ذات التأثير الأعلى والجهد الأقل أولًا. في الواقع العملي، البنود التي تحقق أكبر تخفيض للمخاطر لكل ساعة مهندس هي: تفعيل GuardDuty وSecurity Hub (دقائق، يرصد غالبية التهديدات النشطة)، وفرض IMDSv2 على جميع EC2 ومجموعات العقد (يزيل فئة كاملة من هجمات SSRF-to-credential-theft)، وتدوير أو حذف مفاتيح وصول IAM غير المستخدمة. نفّذ هذه الثلاثة قبل أي شيء آخر.

فرض معايير أمان Pod على كلاستر قائم سيوقف الـ Pods. لا تغيّر تسمية نطاق من warn إلى enforce دون تشغيل kubectl label namespace production pod-security.kubernetes.io/warn=restricted لدورة نشر كاملة على الأقل، وقراءة كل تحذير في سجل مراجعة خادم API، وإصلاح جميع مواصفات Pod غير المتوافقة. تغيير وضع الفرض على نطاق به Deployments غير متوافقة يعني أن عملية الطرح التالية لا تستطيع إنشاء Pods — وهذا يعني انقطاعًا في ساعات العمل.

مخرجات التسليم

مشروع التصليب لا يكتمل حتى ينتج وثائق دائمة تصمد أمام تغيّر الفريق. سلّم: دليل تشغيل التصليب (هذه القائمة مع الأوامر)، ووثيقة نموذج التهديد (STRIDE مطبّق على مخطط البنية)، وحزمة أدلة لفريق الامتثال (تصدير Security Hub، تقرير kube-bench بصيغة HTML، SBOM من Trivy لكل صورة)، وقائمة بالنتائج مع أصحابها وتواريخ استحقاقها متتبَّعة في نظام إدارة المشاريع. جدوّل إعادة التشغيل بعد ستة أشهر.