قناة إعادة الشحن السحابية من Amazon: AWS Security Hub تفحص ثغرة أمنية عالية المخاطر في الامتثال ؟ دليل إصلاح عناصر الامتثال الأمني المشترك

بصفتك الشخص المسؤول عن التشغيل والصيانة الذي يتعامل مع البنية السحابية وأمن النظام يوميًا ، فإن إحدى أكثر اللحظات إثارة للقلق هي فتح وحدة التحكم في الصباح الباكر ورؤية

AWS Security Hub

قفز من اللون الأحمر على الواجهة

CRITICAL (الطوارئ)

أو

HIGH (مخاطر عالية)

إنذار.

في نظام الإشراف على الامتثال الحالي للمؤسسات ، سواء كان PCI-DSS أو CIS AWS Foundations Benchmark أو CIS Controls ، فإن Security Hub يشبه "الفاحص السحابي" الصارم. سيقوم بمسح جميع موارد AWS الخاصة بك على مدار الساعة ، وبمجرد العثور على تكوين لا يتوافق مع أفضل الممارسات الأمنية ، سيتم وضع علامة على ثغرات الامتثال على الفور.

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

ستنظف هذه المقالة مسحًا ضوئيًا بواسطة Security Hub من منظور التشغيل والصيانة الحقيقي

أربع نقاط ضعف مشتركة عالية المخاطر في الامتثال

، توفير دليل إصلاح يدوي وقابل للهبوط ، وفي نفس الوقت تحدث عن خط رأس المال الأساسي الذي يضمن السلامة والتشغيل العادي للموارد على السحابة (بما في ذلك

شحن حساب AWS

الاستراتيجية).

1. فهم معايير Security Hub وتصنيفات المخاطر

نحتاج إلى معرفة كيفية إجراء Security Hub لتقييم الامتثال قبل أن نتمكن من الحصول على إصلاح عملي.

يعتمد Security Hub بشكل أساسي على الأنواع التالية من معايير الأمان:

AWS Foundation Security Best Practices (FSBP): أفضل الممارسات الأمنية الموصى بها رسميًا من قبل AWS.

CIS AWS Foundations Benchmark: معيار أساسي للسلامة AWS شائع الاستخدام في الصناعة.

PCI-DSS / NIST / HIPAA: معايير الامتثال في صناعات محددة (مثل المدفوعات المالية ، والرعاية الطبية ، وما إلى ذلك).

بعد فشل كل قاعدة من قواعد الامتثال ، يقوم Security Hub بتقسيم مستويات المخاطر بناءً على التأثير المحتمل للثغرة الأمنية:

Critical (الطوارئ) ، High (مرتفع) ، Medium (متوسط) ، Low (منخفض)

.

[AWS Security Hub مراقبة وحدة التحكم]

│

── ► [اكتشف ثغرة Critical/High]

│ │

│ ── ► تعرض الوصول المشترك لـ S3 Bucket

│ ── ► IAM Root / Admin تفتقر إلى MFA

│

مجموعة الأمان 0.0.0.0.0/0 إطلاق منفذ عالي الخطورة

لم يتم فتح تدقيق CloudTrail / VPC Flow Logs

│

── ► [إجراء تحقيق عميق وإصلاح تلقائي]

2. 4 نقاط ضعف الامتثال الشائعة عالية المخاطر وإرشادات الإصلاح اليدوي

وفقًا لتجربة تدقيق أمان AWS لعدد كبير من الشركات ، تظهر الأنواع الأربعة التالية من نقاط الضعف في Security Hub بشكل متكرر للغاية ، ويتم تصنيف معظمها على أنها

هيغ

أو

CRITICAL

.

1. يفتح برميل S3 أذونات القراءة/الكتابة العامة (S3.2 / S3.3)

مستوى المخاطر: CRITICAL / HIGH

وصف الثغرة الأمنية: لا يقوم برميل S3 بتشغيل "Block Public Access" (Block Public Access) ، أو يُسمح بقراءة أو كتابة Principal: "*" في Bucket Policy/ACL. يكمن السبب الجذري لعدد لا يحصى من خروقات البيانات الحساسة للشركات في هذا.

خطوات الإصلاح:

الطريقة أ: قم بتشغيل "حظر الوصول العام" على مستوى البرميل

افتح وحدة التحكم AWS S3 وابحث عن Bucket الذي تم وضع علامة عليه.

انقر على علامة التبويب Permissions (أذونات).

انقر على Edit في منطقة Block Public للوصول (settings bucket).

حدد الوصول إلى Block all public ، وانقر على حفظ وإدخال أمر التأكيد.

الطريقة B: إصلاح بنقرة واحدة باستخدام AWS CLI

باش

Aws s3api put-public-الوصول-block \

-- Bucket <اسم دلو التخزين الخاص بك> \

-- Public-الوصول-block-configuration "BlockPublicAcs = true ، Ignore PublicAcs = true ، BlockPublicPolicy = true ، Restrict PublicBuckets = true"

توصيات التشغيل والصيانة: يوصى بفتح Block Public Access مباشرة على مستوى حساب AWS Account / Organizations لمنع المطورين من إنشاء دلاء S3 العامة عن طريق الخطأ.

2. لا يقوم حساب الجذر IAM (Root User) بتمكين MFA أو استخدام الحساب الجذر للعمليات اليومية (IAM.1 / IAM.6)

مستوى المخاطر: CRITICAL

وصف الثغرة الأمنية: R من حساب AWS

يتمتع مستخدمو oot بأعلى الأذونات. بمجرد تسريب كلمة المرور وعدم وجود حماية للمصادقة متعددة العوامل (MFA) ، يمكن للمهاجم الاستيلاء على حساب AWS بأكمله على الفور وحتى تدمير جميع البيانات.

خطوات الإصلاح:

ربط MFA لحساب Root: تسجيل الدخول إلى حساب AWS Root ، أدخل وحدة التحكم IAM. انقر على Dashboard على اليسار للعثور على Root user MFA في Security recommendations. انقر على Add MFA ، يوصى باختيار Virtual MFA device (مثل Authenticator App) أو مفتاح أمان أجهزة FIDO.

قفل حساب Root ، تعطيل Access Key: تحقق مما إذا كان حساب الجذر قد أنشأ Access Key / Secret Key. إذا كان هناك ، على الفور Delete. لا يتم الاحتفاظ بحسابات Root إلا في عدد قليل جدًا من سيناريوهات إدارة الطوارئ (مثل تغيير طريقة الدفع وإلغاء الحساب) ، ويجب تفويض التشغيل والصيانة اليومية من خلال مركز IAM Identity (SSO) أو IAM Roles.

3. أصدر فريق الأمان الوصول إلى المنفذ عالي الخطورة بنسبة 0.0.0.0/0 (EC2.2 / EC2.19)

مستوى المخاطر: HIGH

وصف الثغرة الأمنية: يتم تعيين 0.0.0.0/0 (مفتوح على الشبكة بالكامل) في قواعد الدخول إلى منافذ إدارة حساسة ، مثل TCP 22 (SSH) أو TCP 3389 (RDP) أو منافذ قاعدة البيانات TCP 3306 (MySQL) و TCP 5432 (PostgreSQL).

خطوات الإصلاح:

افتح وحدة التحكم EC2-> Security Groups وابحث عن معرف مجموعة الأمان المذكور في تنبيه Security Hub.

تحرير قواعد الدخول: احذف قاعدة 22/3389 مع المصدر 0.0.0.0/0. قم بتعديل مصدر منفذ الإدارة إلى شبكة التصدير العامة الثابتة للشركة IP /232 أو مقطع شبكة VPN. بالنسبة لمنافذ قاعدة البيانات ، قم بتغيير المصدر إلى السماح فقط باتصالات حركة المرور من مجموعة أمان طبقة الويب/التطبيق (باستخدام مرجع مداخل معرف مجموعة الأمان).

أفضل الممارسات: التخلي عن الشبكة العامة المباشرة SSH لتسجيل الدخول إلى EC2 ، وتحويل AWS Systems Manager (SSM) Session Manager بالكامل. يمكن لـ SSM الاتصال بالخادم بأمان دون فتح 22 منفذًا أو IP للشبكة العامة.

4-لم تفتح CloudTrail سجل المراجعة العالمية (CloudTrail.1/CloudTrail.2)

)

مستوى المخاطر: عالٍ

وصف الثغرة الأمنية: لم يقم CloudTrail بتكوين سجل لجميع المواقع (trail-region) ، أو لم يفتح التحقق من تكامل ملفات السجل. هذا يعني أن المتسلل لن يتمكن من الاحتفاظ بآثار السجل عندما يقوم بعمليات ضارة في منطقة غير مكفّنة.

خطوات الإصلاح:

أدخل وحدة التحكم CloudTrail ، انقر على Trails -> Create trail.

املأ اسم Trail ، ضع علامة على Enable for the regions (تمكين جميع المناطق).

في موقع Storage ، قم بتكوين تسليم السجلات إلى دلو S3 مشفر.

تحقق من التحقق من ملف السجل (التحقق من ملف السجل) للتأكد من أن السجل مقاوم للعبث.

قم بتشغيل تشفير إضافي لـ KMS لضمان أمان تخزين السجل.

3. "خط الدفاع الأساسي" للأمن السحابي وعمليات البنية التحتية: أموال الحساب والامتثال

في التشغيل والصيانة الأمنية اليومية ، يركز العديد من الفنيين 100 ٪ من طاقتهم على ثغرات التعليمات البرمجية ، ومجموعات أمان الشبكة ، وإدارة حقوق IAM والتحكم فيها ، لكنهم غالبًا ما يتجاهلون خطرًا خفيًا مميتًا على قدم المساواة ولكنه غالبًا ما يكون مخفيًا خارج التكنولوجيا-

مخاطر انقطاع الخدمة السحابية بسبب إبطال بيانات اعتماد حساب AWS أو انقطاع الأموال

.

لنفترض أن هذا السيناريو: لقد عملت للتو بجد لإكمال مجموعة كاملة من حوكمة الامتثال لـ Security Hub ، ولكن نظرًا لأن طريقة الدفع المرتبطة بحساب AWS غير صالحة أو حد بطاقة الائتمان غير كافٍ ، فإن الحساب يولد متأخرات (Overdue).

ماذا يحدث عندما يتم تعليق حساب AWS أو تقييده بسبب المتأخرات ؟

تخفيض تصنيف خدمة الأمان وانقطاع السجل: في حالة المتأخرات ، قد تتأخر بعض خدمات الأمان التي تعتمد على الجدولة الديناميكية (مثل الكشف عن التهديد في GuardDuty ، وتسليم السجل في الوقت الفعلي لـ CloudTrail ، والكشف الآلي لـ Security Hub) بسبب الوصول المحدود إلى واجهة برمجة التطبيقات أو التعليق ، مما يؤدي إلى فترة فارغة من المراقبة الأمنية.

فشل البرنامج النصي لإصلاح الأتمتة: إذا قام فريقك بنشر عملية إصلاح تلقائية تستند إلى EventBridge Lambda ، فقد تتسبب خدمة الحساب المحدودة بشكل مباشر في فشل تنفيذ Lambda ، ولا يمكن حظر الثغرة الأمنية في الوقت الأول.

يتم تقليل الدفاع عن الاستخدام الخبيث: من المرجح أن يتعرض المتسللون للهجوم من قبل المتسللين الذين يستخدمون قنوات الإنتاج السوداء. إذا استخدم المتسللون ثغرة أمنية لتعدين العملات المشفرة (Crypto-Mining) بشكل غير قانوني في حسابك ، فإن الفواتير الضخمة التي يتم إنشاؤها على الفور قد تجعل الحساب أكثر خطورة.

استراتيجية ضمان رأس المال وخط الدفاع AWS للمؤسسات:

إنشاء إنذار فاتورة AWS (AWS Budget)

S): قم بتخصيص تحذير الميزانية في Cost Management. عندما يصل الاستهلاك إلى 50 ٪ و 80 ٪ و 100 ٪ ، أرسل رسائل بريد إلكتروني وإشعارات من خلال SNS.

إلغاء حظر قنوات إعادة الشحن والدفع على مستوى المؤسسة: بالنسبة للشركات التي تذهب إلى البحر أو المواقع متعددة الجنسيات الكبيرة ، هناك مخاطر كبيرة تتمثل في الاعتماد فقط على بطاقات الائتمان الشخصية للموظفين لربط حسابات AWS (مثل انتهاء صلاحية البطاقات ، وخصم بطاقات التحكم في المخاطر المصرفية ، وما إلى ذلك). يجب على الشركات إنشاء آلية رسمية ومستمرة لإعادة شحن حساب AWS ، مثل إعادة شحن أزواج عامة إلى عامة من خلال شركاء AWS المعتمدين رسميًا (AWS Partner) ، أو التسوية العامة ، أو التقدم بطلب للحصول على فترة حساب AWS Enterprise Agreement (اتفاقية EA) ، والقضاء بشكل أساسي على مخاطر الخدمة السحابية الناجمة عن انقطاع الأموال.

الفصل بين حساب الإدارة وحساب الأعمال: مع AWS Organizations ، يتم فصل حساب الدفع الرئيسي (حساب الإدارة) عن حساب الأمان (حساب الأمان/الإنتاج) الذي يدير خدمة محددة. الحساب الرئيسي مسؤول فقط عن الجمع بين الفوترة والانتهاء الموحد لإعادة شحن حساب AWS. عزل تأثير مخاطر الأموال على بيئة أمان الأعمال.

رابعاً-الملخص والحوكمة الأمنية Checklist

AWS Security Hub ليس أداة لمرة واحدة ، ولكنه نظام مراقبة مستمر. في مواجهة التحذيرات عالية الخطورة التي يتم تحديثها بشكل متكرر ، يجب على فريق التشغيل والصيانة إنشاء آلية حلقة مغلقة "للتحقيق والإصلاح والتحقق والوقاية الآلية".

وأخيرا ، يلخص لك قائمة دورية الامتثال اليومية/الأسبوعية:

عناصر التفتيش

متطلبات الهدف

إصلاح الأولوية

وصول برميل التخزين S3

افتح الحساب الكامل Block Public Access

P0 (الطوارئ)

** حماية حساب Root **

فتح MFA ، تعطيل Access Key

P0 (الطوارئ)

مجموعة الأمان منافذ عالية الخطورة

إغلاق فتح 0.0.0.0/0 إلى 22/3389

P1 (ارتفاع)

التدقيق والمراقبة

قم بتشغيل سجل CloudTrail على مستوى المنطقة مع تشفير KMS

P1 (ارتفاع)

الامتثال للأموال والخدمات

قم بإعداد تحذير الفاتورة لضمان التدفق السلس لقنوات إعادة شحن حساب AWS

P1 (ارتفاع)

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