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

مشهد التهديدات السحابية

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

مشهد التهديدات السحابية

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

يرسم هذا الدرس خريطة سطح الهجوم الفعلي. سنفحص كيف تنشأ التهيئات الخاطئة وكيف يكتشفها المهاجمون، وكيف تُسرق بيانات الاعتماد وكيف تُستغل، وكيف ينتقل المهاجم أفقيًا عبر البيئة السحابية بعد الوصول الأولي. فهم سلسلة الهجوم شرط أساسي لكل ضابط تصليب ستطبقه في الدروس التالية.

تصنيف التهديدات وفق CNCF و CSA

تتلاقى قائمة الإحدى عشر الفادحة الصادرة عن تحالف أمن السحابة (CSA) مع الورقة البيضاء لأمن السحابة الأصيلة الصادرة عن CNCF عند الأسباب الجذرية ذاتها. الفئات الأعلى تكرارًا في حوادث الإنتاج على نطاق واسع هي:

التهيئة الخاطئة — موارد نُشرت بإعدادات افتراضية غير آمنة (تخزين عام، صلاحيات IAM مفتوحة، مجموعات أمان متساهلة، سجلات تدقيق معطلة).
اختراق بيانات الاعتماد — مفاتيح API مسربة، بيانات اعتماد ثابتة طويلة الأمد، حسابات خدمة مُفرطة الصلاحيات، ورموز OAuth مسروقة.
ضعف ضوابط الهوية — لا مصادقة متعددة العوامل على الحسابات المتميزة، ولا تطبيق لمبدأ الحد الأدنى من الصلاحيات، ولا مراجعات دورية للوصول.
واجهات API غير آمنة — نقاط نهاية البيانات الوصفية بدون مصادقة، وواجهات برمجية لمستوى التحكم بدون حماية، وغياب التحقق من TLS.
الحركة الأفقية — تقدم المهاجم من نقطة انطلاق (مورد واحد مخترق) نحو هدفه (سرقة البيانات، برامج الفدية، استغلال الحوسبة في تعدين العملات).

في الواقع العملي تترابط هذه الفئات في سلسلة. تهيئة خاطئة تمنح الوصول الأولي؛ بيانات اعتماد مُكتشفة خلال ذلك الوصول تُمكّن من تصعيد الصلاحيات؛ والحركة الأفقية تصل إلى البيانات الحساسة. يتطلب التصليب قطع هذه السلسلة عند نقاط متعددة — دفاع متعمق، لا محيط واحد.

كيف تبدأ الاختراقات فعلًا: التهيئة الخاطئة

التهيئة الخاطئة هي السبب الرئيسي للاختراقات السحابية. اختراق Capital One عام 2019 — 100 مليون سجل عميل — بدأ بـ WAF من AWS مُهيأ بشكل خاطئ أتاح ثغرة SSRF (تزوير الطلبات من جانب الخادم). استخدم المهاجم SSRF للوصول إلى خدمة البيانات الوصفية للنسخة (IMDS) واسترداد بيانات اعتماد IAM المؤقتة المرتبطة بدور مُفرط الصلاحيات. استُخدمت تلك البيانات بعد ذلك لإدراج حاويات S3 وتنزيلها.

فئات التهيئة الخاطئة الشائعة في بيئات الإنتاج:

حاويات التخزين المكشوفة للإنترنت — صحيح أن S3 و GCS و Azure Blob تعتمد الإعداد الخاص افتراضيًا في الإصدارات الحديثة، لكن وحدات Terraform القديمة والحاويات المُنشأة من وحدة التحكم وتعديلات ACL على سياسات الحاوية تُنتج باستمرار كائنات عامة. إذن s3:GetObject واحد على * في سياسة الحاوية كافٍ لسرقة بيانات ضخمة.
قواعد مجموعة الأمان مع صلاحية الدخول 0.0.0.0/0 — منافذ SSH (22) و RDP (3389) وقواعد البيانات (3306، 5432) المكشوفة للإنترنت العام تكتشفها الماسحات الآلية في غضون دقائق من النشر. تفهرسها Shodan و Censys باستمرار.
تفعيل IMDSv1 — خدمة البيانات الوصفية الأصلية لـ EC2 (الإصدار 1) لا تتطلب رمز جلسة. أي عملية على النسخة — بما في ذلك حمولات SSRF التي يتلقاها تطبيق الويب — يمكنها طلب http://169.254.169.254/latest/meta-data/iam/security-credentials/ والحصول على بيانات اعتماد AWS صالحة بدون مصادقة. أُطلق IMDSv2 (قائم على الجلسة، مبني على PUT) عام 2019 تحديدًا بسبب نمط Capital One. في 2025، لا يزال IMDSv2 غير افتراضي لجميع أنواع النسخ وقوالب الإطلاق — يجب فرضه صراحةً.
تعطيل سجلات التدقيق — CloudTrail غير مُفعّل في جميع المناطق، أو سجلات تدقيق GCP لا تشمل أحداث الوصول للبيانات، أو سجل تدقيق Kubernetes API معطل. بدون سجلات، الاستجابة للحوادث تعمل في الظلام.

فخ الإنتاج: ينشئ Terraform و CloudFormation الموارد من الكود، لكن ذلك الكود يُكتب مرة واحدة وكثيرًا ما يتباعد عن الحالة الفعلية مع مرور الوقت. يُجري المهندسون تغييرات منفردة في وحدة التحكم، أو يُضيفون موارد يدويًا، أو يُعدّلون مجموعات الأمان لحل مشكلة عاجلة دون تحديث IaC. والنتيجة بنية تحتية حالتها الفعلية لا تطابق حالتها المُعلنة. عامل دائمًا انجراف terraform plan باعتباره حدثًا أمنيًا، لا مجرد إزعاج تشغيلي.

اكتشاف التهيئات الخاطئة قبل المهاجمين يستلزم فحصًا مستمرًا. الأمر التالي في AWS CLI يُراجع إعدادات الوصول العام لحاويات S3 عبر حسابك — خطوة أولى يمكن لأي فريق تنفيذها فورًا:

# إدراج جميع الحاويات والتحقق من إعدادات حظر الوصول العام
aws s3api list-buckets --query 'Buckets[*].Name' --output text \
  | tr '\t' '\n' \
  | xargs -I{} sh -c \
    'aws s3api get-public-access-block --bucket {} 2>&1 || echo "UNSET: {}"'

# فرض حظر على مستوى الحساب لجميع الحاويات الجديدة والحالية
aws s3control put-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

سرقة بيانات الاعتماد: المسار الأكثر مباشرة

بيانات اعتماد صالحة تتجاوز كل ضابط شبكة، وكل قاعدة WAF، وكل توقيع كشف تسلل. يستثمر المهاجمون كثيرًا في جمع بيانات الاعتماد لأن ذلك ينجح. المتجهات الرئيسية هي:

مستودعات الكود المصدري — مفاتيح AWS، وملفات JSON لحسابات خدمة GCP، وسلاسل اتصال قواعد البيانات المُدمجة في GitHub (عام أو خاص) هي المتجه الأكثر شيوعًا. يكتشف فحص الأسرار في GitHub كثيرًا من الأنماط، لكن ليس جميعها — والمستودعات الخاصة ليست بمنأى عن التهديدات الداخلية أو تسريبات الرموز.
كشف خطوط أنابيب CI/CD — متغيرات البيئة في سجلات GitHub Actions، والأسرار غير المُخفاة في منتجات البناء، وإعدادات ACTIONS_STEP_DEBUG=true التي تُفرغ جميع متغيرات البيئة في سجل التشغيل.
بيانات الاعتماد الثابتة طويلة الأمد — مفاتيح وصول IAM بلا انتهاء صلاحية. مفتاح أُنشئ لمطور غادر المنظمة قبل ثلاث سنوات، ولم يُدوَّر، ولا يزال نشطًا، هو باب خلفي دائم وصالح تمامًا. AWS لا تُنهي صلاحية المفاتيح تلقائيًا.
خدمات البيانات الوصفية للنسخ والحاويات — ثغرات SSRF أو ما يعادلها في تطبيقات الويب التي تسمح للمهاجم بجلب http://169.254.169.254 (AWS)، أو http://metadata.google.internal (GCP)، أو http://169.254.169.254/metadata (Azure).
التصيد للحصول على بيانات اعتماد موحدة — سرقة تأكيدات SSO/SAML، واختطاف رموز OAuth عبر إعادة توجيه مفتوحة، أو سرقة بيانات الاعتماد قصيرة الأمد من ملف ~/.aws/credentials المحلي للمطور.

اكتشف بيانات الاعتماد IAM الثابتة طويلة الأمد وغير المُستخدمة باستخدام تقرير بيانات الاعتماد — قدرة أصيلة في AWS يجب على كل فريق تشغيلها وفق جدول أسبوعي:

# توليد تقرير بيانات الاعتماد IAM (تتجدد البيانات كل 4 ساعات)
aws iam generate-credential-report

# تنزيل التقرير وتحليله: عرض المفاتيح النشطة غير المُستخدمة منذ أكثر من 90 يومًا
aws iam get-credential-report --query 'Content' --output text \
  | base64 --decode \
  | awk -F',' 'NR==1 || ($9=="true" && $11 != "N/A" && $11 < "2025-03-01") \
    {printf "user=%-30s key_active=%-6s last_used=%s\n", $1, $9, $11}'

# الحقول: اسم المستخدم ($1)، المفتاح_1_نشط ($9)، تاريخ_آخر_استخدام_للمفتاح_1 ($11)
# أي مفتاح نشط مع آخر استخدام أقدم من 90 يومًا يجب تدويره أو تعطيله فورًا

الحركة الأفقية: من نقطة الانطلاق إلى البيانات الحساسة

الوصول الأولي نادرًا ما يكون هدف المهاجم. المهاجم يريد البيانات، أو الوصول الدائم، أو موارد الحوسبة. الحركة الأفقية هي عملية التوسع من نقطة الانطلاق نحو الهدف. في البيئة السحابية، العوامل الرئيسية المُمكِّنة للحركة الأفقية هي:

أدوار IAM مُفرطة الصلاحيات — خدمة حوسبة (EC2، Lambda، مهمة ECS) بدور يحتوي على iam:PassRole أو iam:CreateAccessKey أو sts:AssumeRole يُمكّن المهاجم من التصعيد إلى أي دور في الحساب بإنشاء بيانات اعتماد جديدة أو افتراض هويات أكثر صلاحية.
شبكات VPC مسطحة — VPC تستطيع فيه جميع الشبكات الفرعية الوصول إلى بعضها بدون تجزئة دقيقة ولا نقاط نهاية خاصة، يضطر التدفق إلى المرور عبر بوابة الإنترنت دون ضرورة، ويسمح لأي تطبيق مخترق ببدء اتصالات مع كل تطبيق آخر.
حسابات الخدمة المشتركة في Kubernetes — حاوية تعمل بحساب خدمة له صلاحيات get/list/watch على secrets على مستوى الكتلة يستطيع قراءة كل سر في أي مساحة اسم. حاوية واحدة مخترقة تتحول إلى أداة استخراج مفاتيح للكتلة بأكملها.
الأسرار في متغيرات البيئة — متغيرات البيئة متاحة لأي عملية على المضيف، وتظهر في /proc/[pid]/environ، وتُفرغ في كثير من سجلات الأخطاء، وتراها Kubernetes API لأي شخص لديه صلاحية pods/exec أو describe pod على مساحة الاسم.

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

سيناريو اختراق واقعي

هكذا يتكشف اختراق حقيقي في شركة SaaS متوسطة الحجم تعمل على AWS مع Kubernetes (EKS):

يُدمج مطور ملف .env في مستودع GitHub عام خلال جلسة تصحيح أخطاء ليلية. يحتوي الملف على مفتاح وصول AWS لبيئة التطوير المرحلي. يُرسل فحص الأسرار في GitHub تنبيهًا — لكن المفتاح قد حُصد بالفعل بواسطة ماسحات آلية تستطلع تدفق أحداث GitHub العام في الوقت الحقيقي.
يُشغّل المهاجم aws sts get-caller-identity بالمفتاح المسروق ويُأكد أنه صالح. يُشغّل aws iam list-attached-user-policies ويكتشف أن المفتاح يعود لمستخدم مطور مُرفقة به سياسة AdministratorAccess المُدارة من AWS — صلاحية مُنحت للوصول "المؤقت" قبل أشهر ولم تُسحب أبدًا.
بالوصول الإداري، يُنشئ المهاجم مستخدم IAM جديدًا بمفتاح وصول خاص به للتثبيت الدائم، ثم يستكشف البيئة. يجد كتلة EKS، يُولّد kubeconfig بـ aws eks update-kubeconfig، ويكتشف أن ConfigMap في الكتلة يُعيّن مجموعة system:masters لجميع مستخدمي AWS المُصادق عليهم في الحساب — تهيئة خاطئة شائعة في الكتل المُهيأة بالتوثيق الأولي لـ EKS.
بصلاحية مدير الكتلة، يُشغّل المهاجم kubectl get secrets --all-namespaces ويسترد بيانات اعتماد قاعدة البيانات، ومفاتيح API لجهات خارجية، ومفتاح Stripe السري المُخزَّن كـ Kubernetes Secrets في base64 بنص واضح.
يُسرّب المهاجم الأسرار، يستخدم بيانات اعتماد قاعدة البيانات لتفريغ قاعدة البيانات PostgreSQL للإنتاج، وينشر DaemonSet على كل عقدة يُشغّل عامل تعدين — كل ذلك في غضون 45 دقيقة من اختراق بيانات الاعتماد الأولي.

رؤية جوهرية: كل خطوة في السيناريو أعلاه كانت ممكّنة بإخفاق ضابط مختلف: تضمين الأسرار في الكود، عدم تدوير المفاتيح، IAM مُفرط الصلاحيات، تهيئة خاطئة في EKS، وأسرار مُخزنة بـ base64 بدل مدير الأسرار. لا إخفاق ضابط واحد كارثي بمفرده — الاختراق استلزم جميعها في تسلسل. الدفاع المتعمق يعني ضمان أن يتجاوز المهاجم عقبات مستقلة متعددة، لا عقبة واحدة فحسب.

مصادر استخبارات التهديدات التي تستحق المتابعة

البقاء على اطلاع بمشهد التهديدات السحابية متطلب تشغيلي، لا مراجعة دورية. المصادر الرئيسية التي تستخدمها فرق الأمان في الإنتاج هي:

استخبارات تهديدات AWS GuardDuty — كشف مُدار للتهديدات يتكامل مع CloudTrail وسجلات تدفق VPC وسجلات DNS. ادرس كتالوج أنواع نتائج GuardDuty لفهم الأنماط السلوكية التي تعتبرها AWS مؤشرات على اختراق.
MITRE ATT&CK للسحابة — مصفوفة السحابة على attack.mitre.org تُعيّن كل تقنية (T1530: بيانات من التخزين السحابي، T1078.004: حسابات السحابة) إلى سلوك المعتدي الحقيقي. استخدمها لقياس ثغرات التغطية في اكتشافاتك.
Sysdig Threat Research و Lacework Labs — ينشران تقارير تهديدات خاصة بالحاويات و Kubernetes مع أدوات هجوم حقيقية (TeamTNT، Rocke، Kinsing) ومؤشرات الاختراق الخاصة بها.
نشرات أمان AWS وتحذيرات أمان GCP — القنوات الرسمية للثغرات على مستوى المنصة. اشترك في كليهما عبر RSS وعاملهما كتنبيهات تشغيلية، لا قراءة اختيارية.

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

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