كشف التهديدات في AWS0%
كشف التهديدات في AWS: كيف تبيع GuardDuty وInspector وSecurity Hub للعميل
في كل صفقة cloud security بالخليج، يسأل العميل سؤالاً واحداً: كيف أعرف أنّي مخترَق قبل ما يصير الضرر؟ AWS تجيب بثلاث خدمات native تشتغل مع بعض: GuardDuty للكشف عن السلوك المشبوه، Inspector لاكتشاف الثغرات، وSecurity Hub لتجميع كل النتائج في لوحة واحدة. دورك كـ presales architect مو شرح كل زر، بل ربط هذه الخدمات بقيمة أعمال واضحة: تقليل وقت الكشف، تقليل الكلفة، والامتثال لمتطلبات NCA وSAMA.
- 1GuardDuty خدمة كشف تهديدات agentless تحلّل CloudTrail وVPC Flow Logs وDNS logs بشكل مستمر، وتكتشف السلوك الشاذ مثل تعدين عملات أو وصول من IP خبيث — بدون أي software تركّبه على الـ workloads. هذه نقطة بيع قوية: لا overhead ولا تأخير على الـ teams.
- 2Amazon Inspector يفحص الـ EC2 وcontainer images في ECR والـ Lambda functions تلقائياً مقابل قواعد بيانات الثغرات (CVE)، ويعطي درجة خطورة contextual تأخذ بالحسبان exposure الفعلي للشبكة — يعني العميل يصلّح أولاً ما هو خطير فعلاً، مو قائمة CVE عمياء.
- 3AWS Security Hub هو الـ single pane of glass الذي يجمع نتائج GuardDuty وInspector وعشرات الخدمات في صيغة موحّدة (ASFF)، ويقيس وضع الأمان مقابل معايير جاهزة مثل CIS AWS Foundations وPCI DSS — هذه هي اللوحة التي تعرضها للـ CISO ليرى الصورة الكاملة في دقيقة.
- 4القيمة الحقيقية للعميل ليست خدمة منفردة بل الـ pipeline: Inspector يكشف الثغرة، GuardDuty يكشف الاستغلال، Security Hub يجمعهما ويشغّل automated response عبر EventBridge وLambda — تتكلم بلغة MTTD/MTTR (متوسط زمن الكشف والاستجابة)، وهي المقاييس التي تهمّ الـ board.
- 5نموذج التسعير usage-based بدون رسوم ثابتة: GuardDuty على حجم الـ logs المحللة، Inspector لكل instance/image مفحوصة، Security Hub لكل finding وعملية compliance check. اربط هذا بـ OPEX المتوقّع وقدّم تقدير شهري — العميل الخليجي يكره المفاجآت في الفاتورة، فأعطه نطاقاً واقعياً مبكراً.
خط أنابيب الكشف والاستجابة في AWS
🔍
Inspector يكشف الثغرة🛡️
GuardDuty يكشف الاستغلال📊
Security Hub يجمّع⚡
EventBridge يشغّل الرد🤖
Lambda يعالج آلياً🔎تفاصيل أعمق
- معمارياً، الثلاث خدمات regional لكنها تدعم delegated administrator عبر AWS Organizations: تعيّن حساباً واحداً (عادة Security account) ليجمع نتائج كل الحسابات في كل الـ regions. هذا حاسم للمؤسسات الخليجية الكبيرة (بنوك، جهات حكومية) ذات multi-account landing zone — لا تبيع GuardDuty لحساب واحد، بل لـ org كاملة مع centralized findings، وهنا تظهر قيمتك كـ architect لا كبائع feature.
- في مقارنة المنافسين، يسأل العميل: لماذا native وليس Microsoft Defender for Cloud أو CrowdStrike أو Wiz؟ الحجة: GuardDuty/Inspector صفر agents وتكامل أعمق مع AWS بثوانٍ، بينما CSPM طرف ثالث مثل Wiz يعطي multi-cloud وagentless graph أقوى للبيئات الهجينة. الموقف المتوازن: ابدأ native للتغطية السريعة منخفضة الكلفة، وأضف طبقة CSPM موحّدة لو العميل multi-cloud (AWS + Azure + on-prem) — هذا يبني ثقة لأنك لا تبيع vendor واحد بشكل أعمى.
- السياق التنظيمي الخليجي هو ورقتك الرابحة: NCA Essential Cybersecurity Controls (ECC) وSAMA Cyber Security Framework يطلبان continuous monitoring وlogging وincident detection صراحةً. اربط كل ضابط بخدمة: ECC monitoring ⟵ GuardDuty، vulnerability management ⟵ Inspector، compliance posture ⟵ Security Hub conformance packs. أضف بُعد data residency: استخدم regions في الـ Middle East (Bahrain me-south-1، UAE me-central-1) حتى تبقى الـ findings داخل الحدود — هذه نقطة حساسة للجهات الحكومية والبنوك السعودية.
AWS Native مقابل CSPM طرف ثالث
Native (GuardDuty+Inspector)
- ◆صفر agents، تفعيل بثوانٍ
- ◆تكامل AWS أعمق
- ◆تسعير usage-based
- ◆نطاق AWS فقط
طرف ثالث (Wiz/Defender)
- ◆تغطية multi-cloud موحّدة
- ◆agentless graph أقوى
- ◆لوحة واحدة لكل cloud
- ◆كلفة license إضافية
💡 نصيحة مقابلة: 💡 نصيحة Presales: لا تبيع الخدمات الثلاث كأدوات منفصلة. ارسمها كـ pipeline واحد على السبورة أمام العميل — اكتشاف، كشف، تجميع، استجابة — واختم بسؤال: كم ساعة تحتاج فرقتك اليوم لتكتشف اختراقاً؟ الفرق بين 200 يوم يدوي ودقائق آلية هو حجّتك بالكامل.