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

الكشف والاستجابة في السحابة

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

الكشف والاستجابة في السحابة

يُقلّل التصليب من احتمالية الاختراق؛ أما الكشف والاستجابة فيُقلّلان من حجم الضرر حين يفشل التصليب. كل مزوّد سحابي كبير يوفّر خدمات تتبّع أصيلة — مثل AWS CloudTrail وGuardDuty وSecurity Hub وCloudWatch Logs — تمنحك رؤية كاملة لكل ما يفعله كل مبدأ وخدمة وموارد في كل لحظة. على نطاق الشركات الكبرى، الفارق بين الفرق التي تتلقى التنبيه عند ثاني استدعاء API من المهاجم وتلك التي تكتشف الاختراق في تدقيق ربع سنوي يعود إلى شيء واحد: مدى إتقانها لتحويل هذه البيانات إلى تنبيهات قابلة للتنفيذ وذات إشارة عالية وضجيج منخفض.

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

CloudTrail: سجل API غير القابل للتغيير

يُسجّل AWS CloudTrail كل استدعاء API في حسابك — نقرات لوحة التحكم، وأوامر CLI، واستدعاءات SDK، والاستدعاءات بين الخدمات — كأحداث JSON منظّمة تُسلَّم إلى S3 وإلى CloudWatch Logs اختياريًا. وهو أساس كل سير عمل للكشف والتحقيق الجنائي.

أفضل الممارسات في الإنتاج التي تُغفلها معظم الفرق:

  • تفعيل المسار متعدد المناطق — تُفوّت المسارات أحادية المنطقة الخدمات العالمية (IAM وSTS وRoute 53 وCloudFront) وأي موارد تُنشأ في منطقة غير مراقبة. يحل العَلَم --is-multi-region-trail هذه المشكلة.
  • تفعيل التحقق من صحة ملفات السجل — يوقّع CloudTrail كل ملف مُسلَّم بتوقيع SHA-256، مما يُمكّنك من إثبات عدم العبث بالسجلات للمدققين ومحققي الحوادث.
  • حماية وجهة S3 — قيّد الوصول إلى الدلو لتكتب إليه CloudTrail فقط ويقرأ منه نظام SIEM الخاص بك؛ احظر الوصول العام؛ وفعّل حذف MFA وObject Lock بوضع الامتثال للفترة الزمنية المطلوبة.
  • الإرسال إلى CloudWatch Logs — تأخير التسليم عبر S3 يصل إلى 15 دقيقة؛ بينما الاستيعاب في CloudWatch Logs شبه فوري ويُتيح فلاتر المقاييس للتنبيه بأقل من دقيقة.
  • تفعيل CloudTrail Insights — كشف الشذوذات المعتمد على التعلم الآلي في معدلات استدعاء API للكتابة؛ يرصد حشو بيانات الاعتماد وعمليات استخراج البيانات بالجملة التي تبدو كارتفاعات مشروعة.
# إنشاء مسار متعدد المناطق مُصلَّب (يُنفَّذ مرة واحدة لكل حساب إدارة) aws cloudtrail create-trail \ --name org-audit-trail \ --s3-bucket-name my-org-cloudtrail-logs \ --is-multi-region-trail \ --enable-log-file-validation \ --cloud-watch-logs-log-group-arn arn:aws:logs:us-east-1:123456789012:log-group:cloudtrail:* \ --cloud-watch-logs-role-arn arn:aws:iam::123456789012:role/CloudTrailCloudWatchRole \ --include-global-service-events \ --enable-log-file-validation aws cloudtrail start-logging --name org-audit-trail # تفعيل Insights (شذوذات معدل الكتابة والقراءة) aws cloudtrail put-insight-selectors \ --trail-name org-audit-trail \ --insight-selectors '[{"InsightType":"ApiCallRateInsight"},{"InsightType":"ApiErrorRateInsight"}]'
على مستوى المنظمة، انشر حساب مفوَّض (حساب أدوات الأمان) واستخدم مسار AWS Organizations — مسار واحد يغطي جميع الحسابات الأعضاء ولا يمكن لمديري الحسابات الأعضاء تعطيله. هذا هو النمط المستخدم في كل منظمة AWS تعمل بكفاءة على نطاق واسع.

GuardDuty: استخبارات التهديدات على نطاق السحابة

Amazon GuardDuty خدمة كشف تهديدات إقليمية ومُدارة تحلّل باستمرار أحداث إدارة CloudTrail وأحداث بيانات S3 وسجلات تدفق VPC واستعلامات DNS دون أن تحتاج إلى توجيه أي شيء إليها يدويًا. تُضافر هذه البيانات مع قوائم استخبارات AWS للتهديدات وCrowdStrike وProofpoint ونماذج الشذوذات الخاصة بها لإنتاج نتائج — تنبيهات مُصنَّفة ومُرجَّحة.

نتائج GuardDuty منظّمة في ثلاث عائلات يجب أن تعرفها جيدًا:

  • الاستطلاع — فحص المنافذ (Recon:EC2/PortProbeUnprotectedPort)، وتعداد API غير المعتاد (Recon:IAMUser/MaliciousIPCaller). مهاجمون يرسمون خريطة بيئتك قبل التحرك.
  • اختراق بيانات الاعتماد / اختراق المثيل — استدعاءات API من عُقد خروج Tor (UnauthorizedAccess:IAMUser/TorIPCaller)، واستدعاءات من IPs في قوائم التهديدات المعروفة (UnauthorizedAccess:EC2/TorClient)، وبيانات اعتماد مستخدمة خارج ساعات التشغيل أو المناطق العادية (CredentialAccess:IAMUser/AnomalousBehavior).
  • التسريب / التأثير — استرداد بيانات S3 بكميات كبيرة من مبدأ غير مألوف (Exfiltration:S3/ObjectRead.Unusual)، ومثيل EC2 يتواصل مع نطاق C2 معروف (Backdoor:EC2/C&CActivity.B)، وحركة مرور تعدين بيتكوين (CryptoCurrency:EC2/BitcoinTool.B).
CloudTrail and GuardDuty detection pipeline CloudTrail API Events VPC Flow Logs Network Traffic DNS Logs Route 53 Resolver S3 Data Events Object Access GuardDuty Threat Intel + ML Findings (scored) EventBridge Rule: severity >= 7 SNS Alert PagerDuty / Slack Lambda Auto-Remediation CloudWatch Metric Filters + Alarms
مسار الكشف: تُغذّي السجلات الخام GuardDuty وCloudWatch؛ وتمر النتائج عبر EventBridge إلى التنبيه والمعالجة الآلية.

كتابة فلاتر مقاييس CloudWatch للكشف المخصص

يغطّي GuardDuty أنماط التهديدات الأكثر شيوعًا، لكن بيئتك تنطوي على مخاطر فريدة تستلزم استخراج إشارات مخصصة. تحلّل فلاتر مقاييس CloudWatch سجلات CloudTrail في الوقت الفعلي تقريبًا، وتزيد مقياسًا مخصصًا عند تطابق نمط ما، وتُطلق إنذارًا — مما يمنحك تنبيهات على أي حدث API في غضون 60 ثانية من حدوثه.

أنماط ذات إشارة عالية يجب أن يراقبها كل حساب إنتاج:

  • استخدام حساب الجذر (أي استدعاء API من مبدأ الجذر)
  • فشل ConsoleLogin — محاولات القوة الغاشمة على كلمات مرور مستخدمي IAM
  • تغييرات سياسة IAM والمستخدم — تصعيد غير مصرح به للصلاحيات
  • إيقاف CloudTrail أو حذفه — مهاجم يخفي آثاره
  • فتح قواعد دخول مجموعة الأمان على 0.0.0.0/0
  • جدولة حذف مفتاح KMS — سلائف لهجوم فدية
# 1. إنشاء فلتر مقاييس لنشاط حساب الجذر aws logs put-metric-filter \ --log-group-name cloudtrail \ --filter-name RootAccountUsage \ --filter-pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }' \ --metric-transformations \ metricName=RootAccountUsageCount,metricNamespace=CloudTrailAlerts,metricValue=1,defaultValue=0 # 2. إنذار: أي استخدام للجذر يُعدّ حرجًا (العتبة=1 خلال 5 دقائق) aws cloudwatch put-metric-alarm \ --alarm-name RootAccountUsage \ --metric-name RootAccountUsageCount \ --namespace CloudTrailAlerts \ --statistic Sum \ --period 300 \ --threshold 1 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 1 \ --alarm-actions arn:aws:sns:us-east-1:123456789012:security-alerts \ --alarm-description "Root account API call detected" # 3. فلتر مقاييس: CloudTrail أُوقف أو حُذف aws logs put-metric-filter \ --log-group-name cloudtrail \ --filter-name CloudTrailMutated \ --filter-pattern '{ ($.eventName = StopLogging) || ($.eventName = DeleteTrail) || ($.eventName = UpdateTrail) }' \ --metric-transformations \ metricName=CloudTrailMutatedCount,metricNamespace=CloudTrailAlerts,metricValue=1,defaultValue=0
ينشر معيار CIS لـ AWS (الإصدار 1.5) أنماط الفلاتر الدقيقة وعتبات الإنذار لـ 14 ضابطًا إلزاميًا. أتمت نشرها عبر Terraform باستخدام موردَي aws_cloudwatch_log_metric_filter وaws_cloudwatch_metric_alarm — عامل وضعية الكشف لديك كرمز واختبرها في CI.

أتمتة الاستجابة مع EventBridge + Lambda

التنبيه الذي تتصرف بناء عليه بعد ساعتين ليس كشفًا — بل تحقيقًا جنائيًا. الهدف هو الاحتواء الآلي للنتائج عالية الثقة والتأكيد البشري للنتائج ذات الثقة المنخفضة. النمط المستخدم على نطاق واسع: تُرسل نتائج GuardDuty إلى EventBridge؛ وتقيّم دالة Lambda الخطورة ونوع النتيجة؛ ثم إما تُعالج آليًا (إلغاء بيانات الاعتماد، وعزل المثيل، وحظر IP في WAF) أو تفتح حادثة PagerDuty مع ملء كامل السياق مسبقًا.

إجراءات المعالجة الآلية حسب نوع النتيجة:

  • بيانات اعتماد IAM المخترقة (UnauthorizedAccess:IAMUser/*) — تستدعي Lambda iam:CreateAccessKey لإنشاء مفتاح جديد، وiam:UpdateAccessKeyStatus لتعطيل القديم، وiam:AttachUserPolicy لإرفاق سياسة حجر تمنع كل شيء. يحتفظ المستخدم بهويته لكنه لا يستطيع التصرف حتى يُعيد فريق الأمان تفعيله.
  • مثيل EC2 مخترق (Backdoor:EC2/*، CryptoCurrency:EC2/*) — تُعدّل Lambda مجموعة أمان المثيل للسماح بـ SSH من CIDR مضيف الأمان فقط، وتُنشئ لقطة EBS للتحليل الجنائي، وتُعلّم المثيل بـ SecurityStatus=Quarantined.
  • وصول S3 غير معتاد (Exfiltration:S3/*) — تُفعّل Lambda حظر الوصول العام على الدلو، وتُلغي أي سياسة دلو S3 تتيح s3:GetObject لـ *.
# قاعدة EventBridge: توجيه نتائج GuardDuty عالية الخطورة إلى Lambda # (Severity >= 7.0 = عالية؛ >= 4.0 = متوسطة) { "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "severity": [{ "numeric": [">=", 7] }] } } # هيكل معالج Lambda (Python 3.12) — حجر مستخدم IAM مخترق import boto3, json iam = boto3.client("iam") QUARANTINE_POLICY_ARN = "arn:aws:iam::123456789012:policy/SecurityQuarantine" def handler(event, context): finding = event["detail"] ftype = finding["type"] user = finding.get("resource", {}).get("accessKeyDetails", {}).get("userName") if not user or "IAMUser" not in ftype: return # تُعالجه أهداف أخرى # 1. إرفاق سياسة حجر تمنع كل شيء iam.attach_user_policy(UserName=user, PolicyArn=QUARANTINE_POLICY_ARN) # 2. تعطيل جميع مفاتيح الوصول للمستخدم keys = iam.list_access_keys(UserName=user)["AccessKeyMetadata"] for key in keys: iam.update_access_key( UserName=user, AccessKeyId=key["AccessKeyId"], Status="Inactive" ) print(json.dumps({"action": "quarantined", "user": user, "finding": ftype}))
يمكن أن تُسبّب المعالجة الآلية انقطاعات إذا أطلقت نتيجة إيجابية كاذبة على حساب خدمة مشروع. قيّد المعالجة الآلية دائمًا على النتائج ذات الخطورة >= 7.0 وأنواع النتائج التي تحققت منها في بيئتك. استخدم علامة IAM DO_NOT_QUARANTINE على حسابات الخدمة التي يجب أن توجَّه بدلاً من ذلك إلى قائمة انتظار مراجعة بشرية. اختبر Lambda مقابل نتائج GuardDuty النموذجية (aws guardduty create-sample-findings) في حساب غير إنتاجي قبل التفعيل في الإنتاج.

ربط الإشارات: Security Hub كلوحة تحكم موحدة

في أي بيئة AWS واقعية (عشرات الحسابات ومناطق متعددة)، تُنشئ نتائج GuardDuty وقواعد Config ونتائج Macie وتقارير ثغرات Inspector وتنبيهات CloudWatch المخصصة طوفانًا من الإشارات إذا استُهلكت بصورة مستقلة. يجمع AWS Security Hub كل هذه المعطيات في تنسيق نتائج موحّد ومعياري (ASFF — AWS Security Finding Format) ويوفر لوحة تحكم عبر الحسابات والمناطق مع درجات الامتثال لـ CIS وPCI-DSS وNIST 800-53.

فعّل Security Hub في حساب أدوات الأمان كمدير مفوَّض، وجمّع جميع الحسابات الأعضاء، واستخدم حل الاستجابة والمعالجة الآلية (SHARR) الخاص به كأساس لمكتبة دفاتر التشغيل لديك.

مبادئ دليل الاستجابة للحوادث

الكشف بلا دليل استجابة مُتدرَّب عليه مجرد مظاهر. يمر دليل الاستجابة الاحترافي لنتيجة GuardDuty بخمس مراحل: الفرز (هل هذه نتيجة إيجابية حقيقية؟)، الاحتواء (وقف النزيف)، الاستئصال (إزالة وجود المهاجم)، الاسترداد (استعادة الخدمة)، ومراجعة ما بعد الحادث (سد ثغرة الكشف). يجب أن تمتلك كل مرحلة مُلّاك واضحون وأشجار قرارات وحدودًا زمنية قصوى. لاختراق بيانات الاعتماد، معايير مستوى الخدمة في الشركات السحابية الأصيلة الرائدة هي: الفرز أقل من 5 دقائق (آلي)، والاحتواء أقل من 15 دقيقة (آلي أو مهندس مناوب)، والاستئصال والاسترداد أقل من ساعتين، ومراجعة ما بعد الحادث خلال 5 أيام عمل.

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