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

بنية الثقة الصفرية

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

بنية الثقة الصفرية

لقد انتهى عصر نموذج المحيط الأمني. لعقود طويلة، افترضت هندسة الأمان أن كل شيء داخل شبكة الشركة آمن، وأن كل شيء خارجها عدائي. انهار هذا الافتراض فور أن بدأ الموظفون يحملون أجهزتهم إلى المقاهي، وفور أن باتت تطبيقات SaaS تحتضن أثمن الأصول أكثر من مراكز البيانات، وفور أن أتاح اختراق بيانات اعتماد واحدة للمهاجم الوصول إلى الشبكة الداخلية بأسرها. تعلّمت Google هذا الدرس مباشرةً في عملية Aurora عام 2010: حيث تمكّن المهاجمون من اختراق محطة عمل واحدة ثم تحركوا أفقياً عبر الشبكة الداخلية للوصول إلى مستودعات الكود وحسابات المستخدمين حول العالم. لم تُبدِ الشبكة الداخلية أي مقاومة بعد اختراق المحيط.

كان ردّ Google هو BeyondCorp — إعادة هيكلة كاملة لآلية وصول الموظفين إلى الموارد الداخلية، نُشرت بشكل مفتوح اعتباراً من 2014 ونُفِّذت على نطاق Google الكامل بحلول 2017. الفكرة الجوهرية بسيطة: يجب ألا يُعامَل موقع الشبكة أبداً بوصفه دليلاً على الثقة. يجب أن تُتخذ كل قرارات الوصول بناءً على الهوية وحالة الجهاز والسياق — بغض النظر عمّا إذا كان الطلب قادماً من مكتب منزلي أو مطار أو رف خادم يبعد ثلاثة أقدام عن الخادم الذي يُنادِيه.

يتناول هذا الدرس الركائز الثلاث التي تجعل بنية الثقة الصفرية ملموسة: الوصول المدرك للهوية، وبروتوكول mTLS في كل مكان، ونمط وكيل الوصول BeyondCorp. ستنتهي من هذا الدرس وبيدك إعدادات قابلة للتشغيل ونموذج ذهني واضح لكيفية تطبيق هذه المفاهيم في بيئات Kubernetes السحابية الإنتاجية.

الركيزة الأولى: الوصول المدرك للهوية

في عالم الثقة الصفرية، تُمثّل الهوية مستوى التحكم. يجب أن يحمل كل كيان — مستخدم بشري، حساب خدمة، حاوية Pod، منفّذ CI — بيانات اعتماد موثّقة وقصيرة الأمد. تتم قرارات الوصول عند حدود المورد، لا عند حافة الشبكة.

التداعيات العملية لبيئة Kubernetes الإنتاجية:

بيانات اعتماد قصيرة الأمد في كل مكان. تُتيح AWS IRSA وGKE Workload Identity وAzure AD Workload Identity للحاويات الحصول على اعتمادات سحابية مؤقتة عبر تبادل رمز OIDC — متجنبةً بذلك الممارسة الكارثية لتثبيت مفاتيح الوصول طويلة الأمد كأسرار.
هوية مخصصة لكل حمل عمل على مستوى Pod. تُعدّ ServiceAccounts في Kubernetes وحدة الهوية الأساسية. يجب ربط كل ServiceAccount بالصلاحيات التي تحتاجها تحديداً، لا أكثر. لا تحمل ServiceAccount الافتراضية في كل مساحة أسماء أي صلاحيات مرتبطة بها بالمجموعات الحديثة — حافظ على ذلك وأنشئ حسابات مخصصة لكل حمل عمل.
سياسة مدركة للسياق. لا يكفي رمز الهوية وحده. في Google، تُقيّم BeyondCorp أيضاً وضع الجهاز (هل هو جهاز مُدار؟ هل نظام التشغيل محدَّث؟)، ووقت الطلب، والموقع الجغرافي، وإشارات المخاطر. في البيئات السحابية الأصيلة، يتيح Open Policy Agent / Gatekeeper ترميز هذا المنطق كسياسات Rego تُقيَّم عند كل طلب قبول أو تفويض.

سلسلة OIDC: تُصدر Kubernetes رموز OIDC للحاويات عبر وحدة تخزين رمز حساب الخدمة المُسقَطة. يتحقق مزوّد خدمة STS الخاص بمزوّد السحابة من الرمز مقابل نقطة اكتشاف OIDC للمجموعة ويستبدله باعتماد سحابي قصير الأمد. يجري هذا التبادل داخل الحاوية دون أن يغادر أي سر ثابت خزينة الأسرار.

يتطلّب تفعيل IRSA على مجموعة EKS وضع تعليقات توضيحية على ServiceAccount وإنشاء دور IAM بسياسة الثقة المناسبة:

# إنشاء سياسة ثقة دور IAM (استبدل رابط OIDC الخاص بمجموعتك)
aws iam create-role \
  --role-name my-app-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub":
            "system:serviceaccount:production:my-app"
        }
      }
    }]
  }'

# وضع تعليق توضيحي على Kubernetes ServiceAccount
kubectl annotate serviceaccount my-app \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/my-app-role

شرط StringEquals على موضوع OIDC بالغ الأهمية — إذ يحصر الاستيلاء على الدور في ServiceAccount محدّد بمساحة أسماء محددة. أي حرف بدل هنا سيُتيح لأي حاوية في المجموعة افتراض الدور.

الركيزة الثانية: بروتوكول mTLS في كل مكان

حتى مع وجود رموز الهوية، يبقى حركة مرور الشبكة بين الخدمات عُرضةً لهجمات الوسيط إذا جرت عبر TCP غير مشفّر أو TLS أحادي الاتجاه. يُلزم بروتوكول mTLS (TLS المتبادل) كلا طرفَي كل اتصال بتقديم شهادة صالحة صادرة عن جهة إصدار شهادات موثوقة. هذا يعني أن كل خدمة تُوثَّق تشفيرياً قبل تبادل بايتة واحدة من البيانات.

في مجموعة Kubernetes، تطبيق mTLS يدوياً غير عملي — إذ يُلزم كل فريق تطبيق بإدارة الشهادات وتدويرها ومعالجة انتهاء صلاحيتها. الحل الصحيح هو شبكة الخدمة: Istio أو Linkerd أو سياسات الشبكة المبنية على eBPF من Cilium. تُشغّل الشبكة وكيل جانبي بجانب كل حاوية يعترض جميع حركة المرور ويتعامل مع مصافحة mTLS بشفافية.

الثقة الصفرية: يمر كل طلب عبر وكيل وصول مدرك للهوية؛ وداخل الشبكة تستخدم جميع الاتصالات بين الحاويات بروتوكول mTLS مع شهادات SPIFFE/SVID المُطبَّقة عبر AuthorizationPolicy.

تُطبّق Istio بروتوكول mTLS على مستوى المجموعة بأكملها من خلال مورد PeerAuthentication واحد، ثم تُقيّد الهويات المسموح لها بالتواصل عبر AuthorizationPolicy:

# تطبيق mTLS الصارم على مستوى الشبكة بأكملها (لا يُسمح بحركة المرور غير المشفّرة)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system   # يُطبَّق على مستوى الشبكة بأكملها
spec:
  mtls:
    mode: STRICT

---
# السماح لـ order-service فقط باستدعاء payment-service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-allow-orders
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/order-service"
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/charge"]

لا تبدأ بوضع PERMISSIVE في الإنتاج. الوضع الافتراضي لـ mTLS في Istio هو PERMISSIVE — يقبل اتصالات النص الصريح واتصالات mTLS على حدٍّ سواء، مما يعني أن مهاجماً اخترق حمل عمل خارج الشبكة لا يزال قادراً على التحدث إلى خدمات الشبكة دون شهادة. اضبط STRICT فور تثبيت Istio، قبل نشر أي أحمال عمل. التحوّل إلى STRICT على مجموعة تعمل بحركة مرور غير مشفّرة مؤلم — تتعطّل الخدمات وتتسع دائرة التأثير.

الركيزة الثالثة: نمط وكيل الوصول BeyondCorp

تقلب BeyondCorp النموذج التقليدي للـ VPN رأساً على عقب. بدلاً من بوابة VPN تتحقق من "هل هذا الجهاز على الشبكة الصحيحة؟" ثم تمنح وصولاً واسع النطاق، تنشر BeyondCorp وكيل وصول أمام كل تطبيق داخلي. يتخذ الوكيل قرار التفويض لكل طلب بناءً على ثلاثة عوامل:

من أنت؟ — هوية موثّقة من مزوّد الهوية (Google Workspace أو Okta أو Azure AD). لا وصول مجهول، أبداً.
ما الجهاز الذي تستخدمه؟ — تتحقق خدمة جرد الأجهزة من: هل هو جهاز مُدار؟ هل يحمل أحدث تحديثات نظام التشغيل؟ هل تشفير القرص مُفعَّل؟ هل يُظهر MDM أي تنبيهات أمنية حديثة؟
ماذا تطلب؟ — المورد المحدد والإجراء، مُطابَقاً بسياسة تحدد أي المجموعات ومستويات الثقة بالأجهزة يمكنها الوصول إليه.

التطبيقات التجارية لهذا النمط هي Google Cloud IAP وCloudflare Access وAWS Verified Access. تُنهي الثلاثة اتصال TLS الخارجي وتُحقق من الهوية عبر OIDC/SAML وتتحقق من وضع الجهاز وتُوجّه الطلبات إلى الواجهة الخلفية فقط إذا أجازت السياسة ذلك — مع رأس JWT موقَّع يمكن للواجهة الخلفية الوثوق به دون الحاجة إلى إعادة تطبيق المصادقة.

ادمج الوكيل مع الشهادات قصيرة الأمد (SPIFFE/SPIRE). يُصدر SPIFFE (إطار هوية الإنتاج الآمن للجميع) شهادات X.509 — تُسمى SVIDs — لكل حمل عمل، تُجدَّد كل ساعة. SPIRE هو التطبيق المرجعي. عند تهيئة Istio لاستخدام SPIRE كجهة إصدار شهاداته، تحمل كل حاوية في الشبكة هوية تشفيرية مرتبطة بـ ServiceAccount الخاص بها ومساحة الأسماء والمجموعة. هذه الهوية مستقلة عن موقع الشبكة — تنتقل مع حمل العمل سواء كان يعمل في GKE أو EKS أو VM محلية، مما يجعلها أساس بنية ثقة صفرية حقيقية متعددة السحاب.

أنماط الفشل في الإنتاج

تُقدّم بنى الثقة الصفرية فئة جديدة من الحوادث الإنتاجية لم تواجهها فرق الشبكات المحلية من قبل. اعرفها قبل أن تتفاجأ بها أثناء المناوبة:

سلسلة انتهاء صلاحية الشهادات. إذا انتهت صلاحية شهادة CA للشبكة أو شهادة جذر SPIRE دون أن يُلاحَظ ذلك، تفشل كل الاتصالات بين الخدمات في المجموعة بأخطاء مصافحة TLS في آنٍ واحد. راقب انتهاء صلاحية الشهادات كمؤشر خدمة رئيسي. تنبيه عند 30 يوماً، تنبيه عاجل عند 7 أيام.
تعذّر الوصول إلى مُصدِر OIDC. إذا كانت نقطة اكتشاف OIDC في EKS غير متاحة مؤقتاً، تفشل الحاويات في الحصول على اعتمادات IRSA. ابنِ منطق إعادة المحاولة مع تراجع أسّي واستخدم تعليقات توضيحية eks.amazonaws.com/token-expiration لإطالة عمر الرمز إلى مستويات محتملة.
قفل الحركة المشروعة بسبب الرفض الافتراضي في AuthorizationPolicy. الإجراء الافتراضي في Istio عندما لا تتطابق أي AuthorizationPolicy هو ALLOW. بمجرد إنشاء أي AuthorizationPolicy في مساحة أسماء، يتحوّل الافتراضي إلى DENY لحمل العمل ذاك. الفرق التي تُطبّق سياسة على خدمة واحدة دون تغطية فحوصات الصحة من Kubernetes API server ستُطلق سيلاً من أخطاء 503 عند النشر التالي.
انحراف الساعة يكسر التحقق من JWT. تحمل رموز OIDC مطالبتَي iat وexp. أي عقدة تنجرف ساعتها بأكثر من خمس دقائق سيفشل التحقق من الرمز فيها. فرض مزامنة NTP (chrony أو timesyncd) على كل عقدة متطلب صحّة أساسي غير قابل للتفاوض.

الثقة الصفرية رحلة وليست مفتاحاً. استغرق Google أربع سنوات لترحيل أكثر من 60,000 موظف من VPN المؤسسية إلى BeyondCorp. ابدأ بأكثر خدماتك حساسيةً، وسجّل كل شيء بسجلات وصول منظّمة، وتوسّع تدريجياً. يجب أن يُسجّل كل إدخال في سجل الوصول: من (الهوية)، وماذا (المورد والإجراء)، ولماذا (السياسة المُطابَقة)، ومن أين (الجهاز وعنوان IP). هذا السجل هو مسار التدقيق ومرجع استكشاف الأخطاء في آنٍ واحد.