مراقبة الأمن السحابي

يمثل نقل البيانات والتطبيقات إلى السحابة تحديًا جديدًا لشركات SOC في الشركات، والتي ليست مستعدة دائمًا لمراقبة البنية التحتية للأشخاص الآخرين. وفقًا لـ Netoskope، تستخدم المؤسسة المتوسطة (على ما يبدو في الولايات المتحدة) 1246 خدمة سحابية مختلفة، وهو ما يزيد بنسبة 22٪ عن العام الماضي. 1246 خدمة سحابية !!! 175 منها تتعلق بخدمات الموارد البشرية، و170 تتعلق بالتسويق، و110 في مجال الاتصالات، و76 في مجال المالية وإدارة علاقات العملاء. تستخدم Cisco 700 خدمة سحابية خارجية "فقط". لذلك أنا مرتبك قليلاً من هذه الأرقام. ولكن على أي حال، فإن المشكلة ليست معهم، ولكن مع حقيقة أن السحابة بدأت تستخدم بنشاط كبير من قبل عدد متزايد من الشركات التي ترغب في الحصول على نفس الفرص لمراقبة البنية التحتية السحابية كما هو الحال في شبكتها الخاصة. وهذا الاتجاه آخذ في النمو - بحسب بحسب غرفة الحسابات الأمريكية بحلول عام 2023، سيتم إغلاق 1200 مركز بيانات في الولايات المتحدة (تم إغلاق 6250 مركزًا بالفعل). لكن الانتقال إلى السحابة لا يقتصر فقط على "نقل خوادمنا إلى مزود خارجي". بنية جديدة لتكنولوجيا المعلومات، وبرامج جديدة، وعمليات جديدة، وقيود جديدة... كل هذا يجلب تغييرات كبيرة ليس فقط في مجال تكنولوجيا المعلومات، ولكن أيضًا في أمن المعلومات. وإذا تعلم مقدمو الخدمة كيفية التعامل بطريقة أو بأخرى مع ضمان أمان السحابة نفسها (لحسن الحظ، هناك الكثير من التوصيات)، فمن خلال مراقبة أمن المعلومات السحابية، خاصة على منصات SaaS، هناك صعوبات كبيرة سنتحدث عنها.

لنفترض أن شركتك قامت بنقل جزء من بنيتها التحتية إلى السحابة... توقف. ليس من هذه الطريق. إذا تم نقل البنية التحتية، وتفكر الآن فقط في كيفية مراقبتها، فقد فقدت بالفعل. ما لم يكن Amazon أو Google أو Microsoft (ثم مع التحفظات)، ربما لن يكون لديك قدرة كبيرة على مراقبة بياناتك وتطبيقاتك. من الجيد أن تتاح لك الفرصة للعمل مع السجلات. في بعض الأحيان، ستكون بيانات الأحداث الأمنية متاحة، ولكن لن تتمكن من الوصول إليها. على سبيل المثال، Office 365. إذا كان لديك أرخص ترخيص E1، فلن تكون الأحداث الأمنية متاحة لك على الإطلاق. إذا كان لديك ترخيص E3، فسيتم تخزين بياناتك لمدة 90 يومًا فقط، وفقط إذا كان لديك ترخيص E5، فستكون مدة السجلات متاحة لمدة عام (ومع ذلك، فإن هذا له أيضًا فروق دقيقة تتعلق بالحاجة إلى منفصلة اطلب عددًا من الوظائف للعمل مع السجلات من دعم Microsoft). بالمناسبة، ترخيص E3 أضعف بكثير من حيث وظائف المراقبة من بورصة الشركات. لتحقيق نفس المستوى، تحتاج إلى ترخيص E5 أو ترخيص امتثال متقدم إضافي، الأمر الذي قد يتطلب أموالًا إضافية لم يتم أخذها في الاعتبار في النموذج المالي الخاص بك للانتقال إلى البنية التحتية السحابية. وهذا مجرد مثال واحد على التقليل من أهمية القضايا المتعلقة بمراقبة أمن المعلومات السحابية. في هذه المقالة، دون التظاهر بالاكتمال، أريد أن ألفت الانتباه إلى بعض الفروق الدقيقة التي يجب أخذها في الاعتبار عند اختيار مزود السحابة من وجهة نظر أمنية. وفي نهاية المقال، سيتم تقديم قائمة مرجعية تستحق إكمالها قبل التفكير في حل مشكلة مراقبة أمن المعلومات السحابية.

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

• سجلات الأمان غير موجودة. هذا موقف شائع إلى حد ما، خاصة بين اللاعبين المبتدئين في سوق الحلول السحابية. لكن لا يجب أن تتخلى عنهم على الفور. تعتبر الشركات الصغيرة، وخاصة المحلية منها، أكثر حساسية لمتطلبات العملاء ويمكنها تنفيذ بعض الوظائف المطلوبة بسرعة عن طريق تغيير خارطة الطريق المعتمدة لمنتجاتها. نعم، لن يكون هذا نظيرًا لـ GuardDuty من Amazon أو وحدة "الحماية الاستباقية" من Bitrix، ولكن على الأقل شيئًا ما.
• لا يعرف أمن المعلومات مكان تخزين السجلات أو لا يمكن الوصول إليها. من الضروري هنا الدخول في مفاوضات مع مزود الخدمة السحابية - ربما سيقدم مثل هذه المعلومات إذا رأى أن العميل مهم بالنسبة له. ولكن بشكل عام، ليس من الجيد جدًا أن يتم توفير الوصول إلى السجلات "بقرار خاص".
• ويحدث أيضًا أن لدى موفر الخدمة السحابية سجلات، ولكنها توفر مراقبة محدودة وتسجيلًا للأحداث، وهي ليست كافية لاكتشاف جميع الحوادث. على سبيل المثال، قد تتلقى فقط سجلات التغييرات على موقع ويب أو سجلات محاولات مصادقة المستخدم، ولكن ليس الأحداث الأخرى، مثل حركة مرور الشبكة، والتي ستخفي عنك طبقة كاملة من الأحداث التي تميز محاولات اختراق البنية التحتية السحابية الخاصة بك.
• توجد سجلات، ولكن من الصعب أتمتة الوصول إليها، مما يفرض مراقبتها ليس بشكل مستمر، ولكن وفقًا لجدول زمني. وإذا لم تتمكن من تنزيل السجلات تلقائيا، فإن تنزيل السجلات، على سبيل المثال، بتنسيق Excel (كما هو الحال مع عدد من موفري الحلول السحابية المحليين)، قد يؤدي حتى إلى إحجام خدمة أمن معلومات الشركة عن العبث بها.
• لا يوجد مراقبة للسجل. ربما يكون هذا هو السبب الأكثر وضوحًا لحدوث حوادث أمن المعلومات في البيئات السحابية. يبدو أن هناك سجلات، ومن الممكن أتمتة الوصول إليها، ولكن لا أحد يفعل ذلك. لماذا؟

مفهوم الأمن السحابي المشترك

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

على سبيل المثال، يكون تصنيف البيانات المستضافة في السحابة دائمًا مسؤولية العميل. لا يمكن لموفر السحابة أو مزود خدمة خارجي مساعدته إلا بالأدوات التي تساعد في وضع علامة على البيانات في السحابة أو تحديد الانتهاكات أو حذف البيانات التي تنتهك القانون أو إخفاءها بطريقة أو بأخرى. ومن ناحية أخرى، فإن الأمن المادي يقع دائمًا على عاتق مزود الخدمة السحابية، ولا يمكنه مشاركته مع العملاء. لكن كل ما يقع بين البيانات والبنية التحتية المادية هو بالتحديد موضوع المناقشة في هذه المقالة. على سبيل المثال، تقع مسؤولية توفر السحابة على عاتق الموفر، كما تقع مسؤولية إعداد قواعد جدار الحماية أو تمكين التشفير على عاتق العميل. سنحاول في هذه المقالة إلقاء نظرة على آليات مراقبة أمن المعلومات التي يتم توفيرها اليوم من قبل العديد من موفري الخدمات السحابية المشهورين في روسيا، وما هي ميزات استخدامها، ومتى يستحق البحث عن حلول التراكب الخارجية (على سبيل المثال، Cisco E- أمن البريد) التي تعمل على توسيع قدرات السحابة الخاصة بك فيما يتعلق بالأمن السيبراني. في بعض الحالات، خاصة إذا كنت تتبع إستراتيجية السحابة المتعددة، لن يكون أمامك خيار سوى استخدام حلول مراقبة أمن المعلومات الخارجية في عدة بيئات سحابية في وقت واحد (على سبيل المثال، Cisco CloudLock أو Cisco Stealthwatch Cloud). حسنًا، في بعض الحالات ستدرك أن مزود الخدمة السحابية الذي اخترته (أو فرضه عليك) لا يقدم أي إمكانيات لمراقبة أمن المعلومات على الإطلاق. إنه أمر غير سارة، ولكن ليس قليلا، لأنه يسمح لك بتقييم مستوى المخاطر المرتبطة بالعمل مع هذه السحابة بشكل مناسب.

دورة حياة مراقبة الأمن السحابي

لمراقبة أمان السحابة التي تستخدمها، لديك ثلاثة خيارات فقط:

• الاعتماد على الأدوات التي يوفرها موفر السحابة الخاص بك،
• استخدام حلول من جهات خارجية تراقب الأنظمة الأساسية IaaS أو PaaS أو SaaS التي تستخدمها،
• قم ببناء البنية التحتية الخاصة بك للمراقبة السحابية (فقط لمنصات IaaS/PaaS).

دعونا نرى ما هي الميزات التي يتمتع بها كل خيار من هذه الخيارات. لكن علينا أولاً أن نفهم الإطار العام الذي سيتم استخدامه عند مراقبة المنصات السحابية. أود أن أسلط الضوء على 6 مكونات رئيسية لعملية مراقبة أمن المعلومات في السحابة:

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

إن فهم هذه المكونات سيسمح لك أن تقرر بسرعة في المستقبل ما يمكنك الحصول عليه من مزود الخدمة الخاص بك، وما يجب عليك القيام به بنفسك أو بمشاركة مستشارين خارجيين.

الخدمات السحابية المضمنة

لقد كتبت بالفعل أعلاه أن العديد من الخدمات السحابية اليوم لا توفر أي إمكانيات لمراقبة أمن المعلومات. بشكل عام، لا يهتمون كثيرا بموضوع أمن المعلومات. على سبيل المثال، إحدى الخدمات الروسية الشهيرة لإرسال التقارير إلى الجهات الحكومية عبر الإنترنت (لن أذكر اسمها بالتحديد). يدور القسم بأكمله حول أمان هذه الخدمة حول استخدام CIPF المعتمد. ولا يختلف قسم أمن المعلومات في خدمة سحابية محلية أخرى لإدارة المستندات الإلكترونية. يتحدث عن شهادات المفتاح العام، والتشفير المعتمد، والقضاء على ثغرات الويب، والحماية من هجمات DDoS، واستخدام جدران الحماية، والنسخ الاحتياطية، وحتى عمليات تدقيق أمن المعلومات المنتظمة. ولكن لا توجد كلمة حول المراقبة أو حول إمكانية الوصول إلى أحداث أمن المعلومات التي قد تكون ذات أهمية لعملاء مزود الخدمة هذا.

بشكل عام، من خلال الطريقة التي يصف بها موفر السحابة مشكلات أمن المعلومات على موقعه الإلكتروني وفي وثائقه، يمكنك فهم مدى جدية تعامله مع هذه المشكلة. على سبيل المثال، إذا قرأت الأدلة الخاصة بمنتجات "My Office"، فلن تكون هناك كلمة حول الأمان على الإطلاق، ولكن في وثائق المنتج المنفصل "My Office. KS3"، المصممة للحماية من الوصول غير المصرح به، هناك قائمة معتادة لنقاط الترتيب السابع عشر من FSTEC، والتي ينفذها "My Office.KS17"، ولكن لم يتم وصف كيفية تنفيذها، والأهم من ذلك، كيفية تنفيذها دمج هذه الآليات مع أمن المعلومات للشركات. ولعل مثل هذا التوثيق موجود، لكنني لم أجده في المجال العام، على موقع "مكتبي". على الرغم من أنه ربما لا يمكنني الوصول إلى هذه المعلومات السرية؟..

بالنسبة لبيتريكس، الوضع أفضل بكثير. تصف الوثائق تنسيقات سجلات الأحداث، ومن المثير للاهتمام، سجل التطفل، الذي يحتوي على أحداث تتعلق بالتهديدات المحتملة للنظام الأساسي السحابي. من هناك يمكنك سحب عنوان IP أو اسم المستخدم أو الضيف ومصدر الحدث والوقت ووكيل المستخدم ونوع الحدث وما إلى ذلك. صحيح، يمكنك العمل مع هذه الأحداث إما من لوحة التحكم السحابية نفسها، أو تحميل البيانات بتنسيق MS Excel. أصبح من الصعب الآن أتمتة العمل باستخدام سجلات Bitrix وسيتعين عليك القيام ببعض العمل يدويًا (تحميل التقرير وتحميله في SIEM الخاص بك). ولكن إذا تذكرنا أنه حتى وقت قريب نسبيا، لم تكن هذه الفرصة موجودة، فهذا يعد تقدما كبيرا. في الوقت نفسه، أود أن أشير إلى أن العديد من موفري الخدمات السحابية الأجانب يقدمون وظائف مماثلة "للمبتدئين" - إما إلقاء نظرة على السجلات بعينيك من خلال لوحة التحكم، أو تحميل البيانات بنفسك (ومع ذلك، يقوم معظمهم بتحميل البيانات بتنسيق . بتنسيق csv وليس Excel).

دون النظر في خيار عدم الاحتفاظ بالسجلات، يقدم لك موفرو الخدمات السحابية عادةً ثلاثة خيارات لمراقبة الأحداث الأمنية - لوحات المعلومات، وتحميل البيانات، والوصول إلى واجهة برمجة التطبيقات (API). يبدو أن الأول يحل العديد من المشكلات بالنسبة لك، لكن هذا ليس صحيحًا تمامًا - إذا كان لديك العديد من المجلات، فسيتعين عليك التبديل بين الشاشات التي تعرضها، مما يؤدي إلى فقدان الصورة العامة. بالإضافة إلى ذلك، من غير المرجح أن يوفر لك موفر السحابة القدرة على ربط الأحداث الأمنية وتحليلها بشكل عام من وجهة نظر أمنية (عادةً ما تتعامل مع البيانات الأولية التي تحتاج إلى فهمها بنفسك). هناك استثناءات وسنتحدث عنها أكثر. أخيرًا، من المفيد أن نسأل ما هي الأحداث التي يتم تسجيلها من قبل مزود الخدمة السحابية الخاص بك، وبأي تنسيق، وكيف تتوافق مع عملية مراقبة أمن المعلومات الخاصة بك؟ على سبيل المثال، تحديد هوية المستخدمين والضيوف والمصادقة عليهم. يسمح لك Bitrix نفسه، بناءً على هذه الأحداث، بتسجيل تاريخ ووقت الحدث واسم المستخدم أو الضيف (إذا كان لديك وحدة "تحليلات الويب") والكائن الذي تم الوصول إليه والعناصر الأخرى النموذجية لموقع الويب . لكن خدمات أمن معلومات الشركة قد تحتاج إلى معلومات حول ما إذا كان المستخدم قد وصل إلى السحابة من جهاز موثوق به (على سبيل المثال، في شبكة الشركة يتم تنفيذ هذه المهمة بواسطة Cisco ISE). ماذا عن مهمة بسيطة مثل وظيفة Geo-IP، والتي ستساعد في تحديد ما إذا كان حساب مستخدم الخدمة السحابية قد تمت سرقته؟ وحتى إذا كان موفر الخدمة السحابية يوفرها لك، فهذا لا يكفي. نفس Cisco CloudLock لا يقوم فقط بتحليل الموقع الجغرافي، ولكنه يستخدم التعلم الآلي لهذا الغرض ويحلل البيانات التاريخية لكل مستخدم ويراقب الحالات الشاذة المختلفة في محاولات تحديد الهوية والمصادقة. يتمتع MS Azure فقط بوظيفة مماثلة (إذا كان لديك الاشتراك المناسب).

هناك صعوبة أخرى - نظرًا لأن مراقبة أمن المعلومات بالنسبة للعديد من موفري الخدمات السحابية يعد موضوعًا جديدًا بدأوا للتو في التعامل معه، فهم يقومون باستمرار بتغيير شيء ما في حلولهم. اليوم لديهم إصدار واحد من واجهة برمجة التطبيقات (API)، وغدًا إصدار آخر، وبعد غد إصدار ثالث. عليك أيضًا أن تكون مستعدًا لذلك. وينطبق الشيء نفسه على الوظائف، التي قد تتغير، والتي يجب أن تؤخذ في الاعتبار في نظام مراقبة أمن المعلومات الخاص بك. على سبيل المثال، كان لدى Amazon في البداية خدمات منفصلة لمراقبة الأحداث السحابية — AWS CloudTrail وAWS CloudWatch. ثم ظهرت خدمة منفصلة لمراقبة أحداث أمن المعلومات - AWS GuardDuty. وبعد مرور بعض الوقت، أطلقت أمازون نظام إدارة جديدًا، Amazon Security Hub، والذي يتضمن تحليل البيانات الواردة من GuardDuty وAmazon Inspector وAmazon Macie والعديد من الشركات الأخرى. مثال آخر هو أداة تكامل سجل Azure مع SIEM - AzLog. تم استخدامها بشكل نشط من قبل العديد من موردي SIEM، حتى أعلنت شركة Microsoft في عام 2018 عن وقف تطويرها ودعمها، الأمر الذي واجه العديد من العملاء الذين استخدموا هذه الأداة بمشكلة (سنتحدث عن كيفية حلها لاحقًا).

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

مثال: مراقبة أمن المعلومات في IaaS استنادًا إلى AWS

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

أول شيء يجب قوله هو أن الأمازون ليست حصنًا منيعًا. حوادث مختلفة تحدث بانتظام لعملائه. على سبيل المثال، تمت سرقة الأسماء والعناوين وتواريخ الميلاد وأرقام هواتف 198 مليون ناخب من شركة Deep Root Analytics. سرقت شركة Nice Systems الإسرائيلية 14 مليون سجل لمشتركي Verizon. ومع ذلك، تتيح لك إمكانيات AWS المضمنة اكتشاف مجموعة واسعة من الحوادث. على سبيل المثال:

• التأثير على البنية التحتية (DDoS)
• تسوية العقدة (حقن الأوامر)
• اختراق الحساب والوصول غير المصرح به
• تكوين غير صحيح ونقاط الضعف
• واجهات وواجهات برمجة التطبيقات غير الآمنة.

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

لتحديد الحوادث، يمكنك استخدام مجموعة واسعة من خدمات المراقبة المختلفة التي طورتها أمازون (على الرغم من أنها غالبًا ما يتم استكمالها بأدوات خارجية مثل osquery). لذلك، في AWS، تتم مراقبة جميع إجراءات المستخدم، بغض النظر عن كيفية تنفيذها - من خلال وحدة التحكم الإدارية أو سطر الأوامر أو SDK أو خدمات AWS الأخرى. تتوفر جميع سجلات نشاط كل حساب AWS (بما في ذلك اسم المستخدم والإجراء والخدمة ومعلمات النشاط والنتيجة) واستخدام واجهة برمجة التطبيقات من خلال AWS CloudTrail. يمكنك عرض هذه الأحداث (مثل عمليات تسجيل الدخول إلى وحدة تحكم AWS IAM) من وحدة تحكم CloudTrail، أو تحليلها باستخدام Amazon Athena، أو "الاستعانة بمصادر خارجية" لحلول خارجية مثل Splunk، وAlienVault، وما إلى ذلك. يتم وضع سجلات AWS CloudTrail نفسها في حاوية AWS S3 الخاصة بك.

توفر خدمتان أخريان من AWS عددًا من إمكانيات المراقبة المهمة الأخرى. أولاً، Amazon CloudWatch هي خدمة مراقبة لموارد وتطبيقات AWS والتي تتيح لك، من بين أمور أخرى، تحديد الحالات الشاذة المختلفة في السحابة الخاصة بك. جميع خدمات AWS المضمنة، مثل Amazon Elastic Compute Cloud (الخوادم)، وAmazon Relational Database Service (قواعد البيانات)، وAmazon Elastic MapReduce (تحليل البيانات)، و30 خدمة أخرى من خدمات Amazon، تستخدم Amazon CloudWatch لتخزين سجلاتها. يمكن للمطورين استخدام واجهة برمجة التطبيقات المفتوحة من Amazon CloudWatch لإضافة وظيفة مراقبة السجل إلى التطبيقات والخدمات المخصصة، مما يسمح لهم بتوسيع نطاق تحليل الأحداث ضمن سياق أمني.

ثانيًا، تتيح لك خدمة VPC Flow Logs تحليل حركة مرور الشبكة المرسلة أو المستلمة بواسطة خوادم AWS الخاصة بك (خارجيًا أو داخليًا)، وكذلك بين الخدمات الصغيرة. عندما تتفاعل أي من موارد AWS VPC الخاصة بك مع الشبكة، تسجل VPC Flow Logs تفاصيل حول حركة مرور الشبكة، بما في ذلك واجهة الشبكة المصدر والوجهة، بالإضافة إلى عناوين IP والمنافذ والبروتوكول وعدد البايتات وعدد الحزم التي ترسلها. رأى. سوف يتعرف أولئك الذين لديهم خبرة في أمان الشبكة المحلية على أن هذا مشابه للخيوط NetFlow، والتي يمكن إنشاؤها بواسطة المحولات وأجهزة التوجيه وجدران الحماية على مستوى المؤسسات. تعتبر هذه السجلات مهمة لأغراض مراقبة أمن المعلومات، لأنها، على عكس الأحداث المتعلقة بإجراءات المستخدم والتطبيق، تسمح لك أيضًا بعدم تفويت تفاعلات الشبكة في بيئة السحابة الافتراضية الخاصة لـ AWS.

باختصار، توفر خدمات AWS الثلاث هذه — AWS CloudTrail وAmazon CloudWatch وVPC Flow Logs — معًا رؤية قوية إلى حد ما حول استخدام حسابك، وسلوك المستخدم، وإدارة البنية التحتية، ونشاط التطبيقات والخدمات، ونشاط الشبكة. على سبيل المثال، يمكن استخدامها للكشف عن الحالات الشاذة التالية:

• محاولات لمسح الموقع والبحث عن الأبواب الخلفية والبحث عن نقاط الضعف من خلال دفعات من "أخطاء 404".
• هجمات الحقن (على سبيل المثال، حقن SQL) من خلال دفعات من "500 خطأ".
• أدوات الهجوم المعروفة هي sqlmap، nikto، w3af، nmap، إلخ. من خلال تحليل حقل وكيل المستخدم.

قامت Amazon Web Services أيضًا بتطوير خدمات أخرى لأغراض الأمن السيبراني والتي تتيح لك حل العديد من المشكلات الأخرى. على سبيل المثال، لدى AWS خدمة مدمجة لمراجعة السياسات والتكوينات - AWS Config. توفر هذه الخدمة تدقيقًا مستمرًا لموارد AWS الخاصة بك وتكويناتها. لنأخذ مثالاً بسيطًا: لنفترض أنك تريد التأكد من تعطيل كلمات مرور المستخدم على جميع خوادمك وأن الوصول ممكن فقط بناءً على الشهادات. يُسهل AWS Config التحقق من ذلك لجميع خوادمك. هناك سياسات أخرى يمكن تطبيقها على خوادمك السحابية: "لا يمكن لأي خادم استخدام المنفذ 22"، أو "يمكن للمسؤولين فقط تغيير قواعد جدار الحماية" أو "يمكن للمستخدم Ivashko فقط إنشاء حسابات مستخدمين جديدة، ويمكنه القيام بذلك في أيام الثلاثاء فقط". " في صيف عام 2016، تم توسيع خدمة AWS Config لأتمتة الكشف عن انتهاكات السياسات المطورة. قواعد AWS Config هي في الأساس طلبات تكوين مستمرة لخدمات Amazon التي تستخدمها، والتي تنشئ أحداثًا في حالة انتهاك السياسات المقابلة. على سبيل المثال، بدلاً من تشغيل استعلامات AWS Config بشكل دوري للتحقق من تشفير جميع الأقراص الموجودة على خادم ظاهري، يمكن استخدام قواعد AWS Config للتحقق بشكل مستمر من أقراص الخادم للتأكد من استيفاء هذا الشرط. والأهم من ذلك، في سياق هذا المنشور، أن أي انتهاكات تولد أحداثًا يمكن تحليلها بواسطة خدمة أمن المعلومات الخاصة بك.

تتمتع AWS أيضًا بما يعادل حلول أمن معلومات الشركات التقليدية، والتي تولد أيضًا أحداثًا أمنية يمكنك ويجب عليك تحليلها:

• كشف التسلل - AWS GuardDuty
• التحكم في تسرب المعلومات - AWS Macie
• EDR (على الرغم من أنه يتحدث عن نقاط النهاية في السحابة بشكل غريب بعض الشيء) - AWS Cloudwatch + حلول osquery أو GRR مفتوحة المصدر
• تحليل Netflow - AWS Cloudwatch + AWS VPC Flow
• تحليل DNS - AWS Cloudwatch + AWS Route53
• م - خدمة دليل AWS
• إدارة الحساب - AWS IAM
• تسجيل الدخول الموحد - AWS SSO
• التحليل الأمني ​​- AWS Inspector
• إدارة التكوين - تكوين AWS
• واف - أوس واف.

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

على أية حال، كل شيء يبدأ بمصادر البيانات التي تزودك بأحداث أمن المعلومات. وتشمل هذه المصادر، على سبيل المثال لا الحصر، ما يلي:

• CloudTrail - استخدام واجهة برمجة التطبيقات وإجراءات المستخدم
• Trusted Advisor - فحص أمني وفقًا لأفضل الممارسات
• التكوين - جرد وتكوين الحسابات وإعدادات الخدمة
• سجلات تدفق VPC - اتصالات بالواجهات الافتراضية
• IAM - خدمة تحديد الهوية والمصادقة
• سجلات الوصول إلى ELB - موازن التحميل
• المفتش - نقاط الضعف في التطبيق
• S3 - تخزين الملفات
• CloudWatch - نشاط التطبيق
• SNS هي خدمة إعلام.

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

مثال: مراقبة أمن المعلومات في IaaS استنادًا إلى Azure

لا أريد الدخول في نقاش طويل حول أي من مقدمي الخدمات السحابية الثلاثة (Amazon أو Microsoft أو Google) هو الأفضل (خاصة وأن كل منهم لا يزال لديه تفاصيله الخاصة ومناسب لحل مشاكله الخاصة)؛ دعونا نركز على إمكانيات مراقبة أمن المعلومات التي يوفرها هؤلاء اللاعبون. يجب الاعتراف بأن Amazon AWS كانت واحدة من أولى الشركات في هذا القطاع وبالتالي تقدمت إلى أبعد الحدود من حيث وظائف أمن المعلومات (على الرغم من أن الكثيرين يعترفون بصعوبة استخدامها). ولكن هذا لا يعني أننا سوف نتجاهل الفرص التي توفرها لنا مايكروسوفت وجوجل.

تتميز منتجات Microsoft دائمًا بـ "انفتاحها" والوضع مشابه في Azure. على سبيل المثال، إذا كانت AWS وGCP تنطلق دائمًا من مفهوم "ما هو غير مسموح به فهو محظور"، فإن Azure لديه النهج المعاكس تمامًا. على سبيل المثال، عند إنشاء شبكة افتراضية في السحابة وجهاز افتراضي فيها، تكون جميع المنافذ والبروتوكولات مفتوحة ومسموح بها افتراضيًا. لذلك، سيتعين عليك بذل المزيد من الجهد في الإعداد الأولي لنظام التحكم في الوصول في السحابة من Microsoft. وهذا يفرض عليك أيضًا متطلبات أكثر صرامة فيما يتعلق بمراقبة النشاط في سحابة Azure.

تتمتع AWS بخصوصية مرتبطة بحقيقة أنه عند مراقبة مواردك الافتراضية، إذا كانت موجودة في مناطق مختلفة، فإنك تواجه صعوبات في الجمع بين جميع الأحداث وتحليلها الموحد، للقضاء عليها تحتاج إلى اللجوء إلى حيل مختلفة، مثل قم بإنشاء التعليمات البرمجية الخاصة بك لـ AWS Lambda والتي ستنقل الأحداث بين المناطق. لا يواجه Azure هذه المشكلة - حيث تقوم آلية سجل الأنشطة الخاصة به بتتبع جميع الأنشطة عبر المؤسسة بأكملها دون قيود. الأمر نفسه ينطبق على AWS Security Hub، الذي طورته أمازون مؤخرًا لدمج العديد من الوظائف الأمنية داخل مركز أمني واحد، ولكن داخل منطقتها فقط، والتي، مع ذلك، ليست ذات صلة بروسيا. لدى Azure مركز أمان خاص بها، وهو غير مقيد بالقيود الإقليمية، مما يوفر الوصول إلى جميع ميزات الأمان الخاصة بالمنصة السحابية. علاوة على ذلك، يمكن للفرق المحلية المختلفة توفير مجموعتها الخاصة من قدرات الحماية، بما في ذلك الأحداث الأمنية التي تديرها. لا يزال AWS Security Hub في طريقه ليصبح مشابهًا لـ Azure Security Center. لكن الأمر يستحق إضافة ذبابة في المرهم - يمكنك الضغط على الكثير مما تم وصفه مسبقًا في AWS من Azure، ولكن من الأفضل القيام بذلك فقط من أجل Azure AD وAzure Monitor وAzure Security Center. لم تتم إدارة جميع آليات أمان Azure الأخرى، بما في ذلك تحليل الأحداث الأمنية، بالطريقة الأكثر ملاءمة حتى الآن. تم حل المشكلة جزئيًا عن طريق واجهة برمجة التطبيقات (API)، التي تتخلل جميع خدمات Microsoft Azure، ولكن هذا سيتطلب جهدًا إضافيًا منك لدمج السحابة الخاصة بك مع SOC الخاص بك ووجود متخصصين مؤهلين (في الواقع، كما هو الحال مع أي SIEM آخر يعمل مع السحابة واجهات برمجة التطبيقات). بعض SIEMs، والتي سيتم مناقشتها لاحقًا، تدعم بالفعل Azure ويمكنها أتمتة مهمة مراقبتها، ولكن لديها أيضًا صعوباتها الخاصة - لا يمكنها جميعها جمع جميع السجلات الموجودة في Azure.

يتم توفير جمع الأحداث ومراقبتها في Azure باستخدام خدمة Azure Monitor، وهي الأداة الرئيسية لجمع وتخزين وتحليل البيانات في سحابة Microsoft ومواردها - مستودعات Git والحاويات والأجهزة الافتراضية والتطبيقات وما إلى ذلك. تنقسم جميع البيانات التي تم جمعها بواسطة Azure Monitor إلى فئتين - المقاييس، التي يتم جمعها في الوقت الفعلي وتصف مؤشرات الأداء الرئيسية لسحابة Azure، والسجلات، التي تحتوي على بيانات منظمة في سجلات تميز جوانب معينة من نشاط موارد وخدمات Azure. بالإضافة إلى ذلك، باستخدام Data Collector API، يمكن لخدمة Azure Monitor جمع البيانات من أي مصدر REST لإنشاء سيناريوهات المراقبة الخاصة بها.

فيما يلي بعض مصادر الأحداث الأمنية التي يقدمها لك Azure والتي يمكنك الوصول إليها من خلال Azure Portal أو CLI أو PowerShell أو REST API (وبعضها فقط من خلال Azure Monitor/Insight API):

• سجلات الأنشطة - يجيب هذا السجل على الأسئلة الكلاسيكية مثل "من" و"ماذا" و"متى" فيما يتعلق بأي عملية كتابة (PUT، POST، DELETE) على الموارد السحابية. لا يتم تضمين الأحداث المتعلقة بالوصول للقراءة (GET) في هذا السجل، مثل عدد من السجلات الأخرى.
• سجلات التشخيص - تحتوي على بيانات حول العمليات التي تتم باستخدام مورد معين مدرج في اشتراكك.
• تقارير Azure AD - تحتوي على نشاط المستخدم ونشاط النظام المتعلق بإدارة المجموعة والمستخدم.
• سجل أحداث Windows وLinux Syslog - يحتويان على أحداث من الأجهزة الافتراضية المستضافة في السحابة.
• المقاييس - تحتوي على قياس عن بعد حول الأداء والحالة الصحية للخدمات والموارد السحابية الخاصة بك. يتم قياسها كل دقيقة وتخزينها. خلال 30 يوما.
• سجلات تدفق مجموعة أمان الشبكة - تحتوي على بيانات حول أحداث أمان الشبكة التي تم جمعها باستخدام خدمة Network Watcher ومراقبة الموارد على مستوى الشبكة.
• سجلات التخزين - تحتوي على الأحداث المتعلقة بالوصول إلى مرافق التخزين.

للمراقبة، يمكنك استخدام SIEMs الخارجية أو شاشة Azure المدمجة وملحقاتها. سنتحدث عن أنظمة إدارة أحداث أمن المعلومات لاحقًا، ولكن الآن دعونا نرى ما يقدمه لنا Azure نفسه لتحليل البيانات في سياق الأمان. الشاشة الرئيسية لكل ما يتعلق بالأمان في Azure Monitor هي لوحة معلومات Log Analytics Security and Audit Dashboard (الإصدار المجاني يدعم كمية محدودة من تخزين الأحداث لمدة أسبوع واحد فقط). تنقسم لوحة المعلومات هذه إلى 5 مناطق رئيسية تعرض إحصائيات ملخصة لما يحدث في البيئة السحابية التي تستخدمها:

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

تتضمن ملحقات Azure Monitor Azure Key Vault (حماية مفاتيح التشفير في السحابة)، وتقييم البرامج الضارة (تحليل الحماية ضد التعليمات البرمجية الضارة على الأجهزة الافتراضية)، وAzure Application Gateway Analytics (تحليل، من بين أمور أخرى، سجلات جدار الحماية السحابية)، وما إلى ذلك. . تتيح لك هذه الأدوات، الغنية بقواعد معينة لمعالجة الأحداث، تصور جوانب مختلفة من نشاط الخدمات السحابية، بما في ذلك الأمان، وتحديد بعض الانحرافات عن التشغيل. ولكن، كما يحدث في كثير من الأحيان، تتطلب أي وظيفة إضافية اشتراكًا مدفوعًا مناسبًا، الأمر الذي سيتطلب منك استثمارات مالية مناسبة، والتي تحتاج إلى التخطيط لها مسبقًا.

يحتوي Azure على عدد من إمكانات مراقبة التهديدات المضمنة المدمجة في Azure AD وAzure Monitor وAzure Security Center. من بينها، على سبيل المثال، الكشف عن تفاعل الأجهزة الافتراضية مع عناوين IP الضارة المعروفة (بسبب وجود التكامل مع خدمات Threat Intelligence من Microsoft)، والكشف عن البرامج الضارة في البنية التحتية السحابية من خلال تلقي الإنذارات من الأجهزة الافتراضية المستضافة في السحابة، وكلمة المرور هجمات التخمين "على الأجهزة الافتراضية، ونقاط الضعف في تكوين نظام تعريف المستخدم، وتسجيل الدخول إلى النظام من أدوات إخفاء الهوية أو العقد المصابة، وتسريبات الحسابات، وتسجيل الدخول إلى النظام من مواقع غير عادية، وما إلى ذلك. يعد Azure اليوم أحد موفري الخدمات السحابية القلائل الذين يقدمون لك إمكانيات تحليل التهديدات المضمنة لإثراء أحداث أمان المعلومات المجمعة.

كما هو مذكور أعلاه، فإن وظيفة الأمان، ونتيجة لذلك، الأحداث الأمنية التي تولدها ليست متاحة لجميع المستخدمين بالتساوي، ولكنها تتطلب اشتراكًا معينًا يتضمن الوظيفة التي تحتاجها، والتي تولد الأحداث المناسبة لمراقبة أمن المعلومات. على سبيل المثال، تتوفر بعض الوظائف الموضحة في الفقرة السابقة لمراقبة الحالات الشاذة في الحسابات فقط في ترخيص P2 premium لخدمة Azure AD. بدونها، كما في حالة AWS، سيتعين عليك تحليل الأحداث الأمنية التي تم جمعها "يدويًا". وأيضًا، اعتمادًا على نوع ترخيص Azure AD، لن تكون جميع الأحداث متاحة للتحليل.

على بوابة Azure، يمكنك إدارة استعلامات البحث للسجلات التي تهمك وإعداد لوحات المعلومات لتصور مؤشرات أمان المعلومات الرئيسية. بالإضافة إلى ذلك، يمكنك هناك تحديد ملحقات Azure Monitor، والتي تسمح لك بتوسيع وظائف سجلات Azure Monitor والحصول على تحليل أعمق للأحداث من وجهة نظر أمنية.

إذا كنت لا تحتاج فقط إلى القدرة على العمل مع السجلات، بل إلى مركز أمان شامل لمنصة Azure السحابية الخاصة بك، بما في ذلك إدارة سياسة أمان المعلومات، فيمكنك التحدث عن الحاجة إلى العمل مع Azure Security Center، حيث تتوفر معظم وظائفه المفيدة. متاحة مقابل بعض المال، على سبيل المثال، الكشف عن التهديدات، والمراقبة خارج Azure، وتقييم الامتثال، وما إلى ذلك. (في النسخة المجانية، لديك فقط إمكانية الوصول إلى تقييم أمني وتوصيات للقضاء على المشاكل التي تم تحديدها). فهو يجمع جميع القضايا الأمنية في مكان واحد. في الواقع، يمكننا التحدث عن مستوى أعلى من أمان المعلومات مما يوفره لك Azure Monitor، لأنه في هذه الحالة يتم إثراء البيانات المجمعة عبر مصنع السحابة الخاص بك باستخدام العديد من المصادر، مثل Azure وOffice 365 وMicrosoft CRM عبر الإنترنت وMicrosoft Dynamics AX و outlook.com وMSN.com ووحدة الجرائم الرقمية لـ Microsoft (DCU) ومركز الاستجابة الأمنية لـ Microsoft (MSRC)، حيث يتم تركيب خوارزميات التعلم الآلي والتحليلات السلوكية المتنوعة المتنوعة، والتي من شأنها في النهاية تحسين كفاءة اكتشاف التهديدات والاستجابة لها .

لدى Azure أيضًا SIEM خاص بها - وقد ظهر في بداية عام 2019. هذا هو Azure Sentinel، الذي يعتمد على بيانات من Azure Monitor ويمكن أيضًا التكامل معه. حلول الأمان الخارجية (على سبيل المثال، NGFW أو WAF)، والتي تتزايد قائمتها باستمرار. بالإضافة إلى ذلك، من خلال تكامل Microsoft Graph Security API، لديك القدرة على ربط خلاصات Threat Intelligence الخاصة بك بـ Sentinel، مما يثري إمكانيات تحليل الحوادث في سحابة Azure الخاصة بك. يمكن القول أن Azure Sentinel هو أول SIEM "أصلي" ظهر من موفري الخدمات السحابية (نفس Splunk أو ELK، والتي يمكن استضافتها في السحابة، على سبيل المثال، AWS، لا تزال غير مطورة بواسطة موفري الخدمات السحابية التقليديين). يمكن تسمية Azure Sentinel and Security Center بـ SOC لسحابة Azure ويمكن أن يقتصر عليهما (مع بعض التحفظات) إذا لم يعد لديك أي بنية تحتية وقمت بنقل جميع موارد الحوسبة الخاصة بك إلى السحابة وستكون سحابة Microsoft Azure.

ولكن بما أن القدرات المضمنة في Azure (حتى لو كان لديك اشتراك في Sentinel) غالبًا ما لا تكون كافية لأغراض مراقبة أمن المعلومات ودمج هذه العملية مع المصادر الأخرى للأحداث الأمنية (سواء السحابية أو الداخلية)، فهناك حل تحتاج إلى تصدير البيانات المجمعة إلى أنظمة خارجية، والتي قد تشمل SIEM. يتم ذلك باستخدام واجهة برمجة التطبيقات (API) وباستخدام ملحقات خاصة، وهي متاحة حاليًا رسميًا فقط لأنظمة SIEM التالية - Splunk (Azure Monitor Add-On for Splunk)، وIBM QRadar (Microsoft Azure DSM)، وSumoLogic، وArcSight، وELK. حتى وقت قريب، كان هناك المزيد من هذه SIEMs، ولكن اعتبارًا من 1 يونيو 2019، توقفت Microsoft عن دعم أداة تكامل Azure Log (AzLog)، والتي في فجر وجود Azure وفي غياب التوحيد الطبيعي للعمل مع السجلات (Azure) لم تكن الشاشة موجودة حتى الآن) مما جعل من السهل دمج SIEM الخارجي مع سحابة Microsoft. الآن تغير الوضع وتوصي Microsoft بمنصة Azure Event Hub كأداة التكامل الرئيسية لـ SIEMs الأخرى. لقد قام العديد منهم بالفعل بتنفيذ هذا التكامل، ولكن كن حذرًا - فقد لا يلتقطون جميع سجلات Azure، ولكن بعضها فقط (راجع الوثائق الخاصة بـ SIEM الخاص بك).

في ختام رحلة قصيرة إلى Azure، أود أن أقدم توصية عامة حول هذه الخدمة السحابية - قبل أن تقول أي شيء عن وظائف مراقبة أمن المعلومات في Azure، يجب عليك تكوينها بعناية فائقة واختبار أنها تعمل كما هو مكتوب في الوثائق و كما أخبرك المستشارون بشركة Microsoft (وقد تكون لديهم وجهات نظر مختلفة حول وظائف وظائف Azure). إذا كانت لديك الموارد المالية، فيمكنك الحصول على الكثير من المعلومات المفيدة من Azure فيما يتعلق بمراقبة أمن المعلومات. إذا كانت مواردك محدودة، كما هو الحال في AWS، فسيتعين عليك الاعتماد فقط على قوتك والبيانات الأولية التي توفرها لك Azure Monitor. وتذكر أن العديد من وظائف المراقبة تكلف أموالاً ومن الأفضل أن تتعرف على سياسة التسعير مسبقًا. على سبيل المثال، يمكنك تخزين 31 يومًا من البيانات مجانًا بحد أقصى 5 جيجابايت لكل عميل - وتجاوز هذه القيم سيتطلب منك صرف أموال إضافية (حوالي 2 دولار أمريكي لتخزين كل جيجابايت إضافية من العميل و0,1 دولار أمريكي لكل جيجابايت إضافية) تخزين 1 جيجابايت كل شهر إضافي). قد يتطلب العمل مع القياس عن بعد للتطبيق والمقاييس أيضًا أموالًا إضافية، بالإضافة إلى العمل مع التنبيهات والإشعارات (يتوفر حد معين مجانًا، والذي قد لا يكون كافيًا لاحتياجاتك).

مثال: مراقبة أمن المعلومات في IaaS استنادًا إلى Google Cloud Platform

يبدو Google Cloud Platform شابًا مقارنةً بـ AWS وAzure، ولكن هذا جيد جزئيًا. على عكس AWS التي زادت قدراتها، بما في ذلك الأمان، تدريجيًا، مع وجود مشاكل في المركزية؛ تتم إدارة Google Cloud Platform، مثل Azure، بشكل أفضل مركزيًا، مما يقلل الأخطاء ووقت التنفيذ عبر المؤسسة. من وجهة نظر أمنية، فإن Google Cloud Platform، بشكل غريب، يقع بين AWS وAzure. لديه أيضًا تسجيل حدث واحد للمؤسسة بأكملها، ولكنه غير كامل. لا تزال بعض الوظائف في الوضع التجريبي، ولكن يجب التخلص من هذا النقص تدريجيًا وسيصبح Google Cloud Platform منصة أكثر نضجًا من حيث مراقبة أمن المعلومات.

الأداة الرئيسية لتسجيل الأحداث في Google Cloud Platform هي Stackdriver Logging (على غرار Azure Monitor)، والتي تتيح لك جمع الأحداث عبر البنية الأساسية السحابية بالكامل (وكذلك من AWS). من منظور الأمان في Google Cloud Platform، تحتوي كل مؤسسة أو مشروع أو مجلد على أربعة سجلات:

• نشاط المسؤول - يحتوي على جميع الأحداث المتعلقة بالوصول الإداري، على سبيل المثال، إنشاء جهاز افتراضي، وتغيير حقوق الوصول، وما إلى ذلك. تتم كتابة هذا السجل دائمًا، بغض النظر عن رغبتك، ويتم تخزين بياناته لمدة 400 يوم.
• الوصول إلى البيانات - يحتوي على جميع الأحداث المتعلقة بالعمل مع البيانات من قبل مستخدمي السحابة (الإنشاء والتعديل والقراءة وما إلى ذلك). بشكل افتراضي، لا تتم كتابة هذا السجل، حيث يتضخم حجمه بسرعة كبيرة. ولهذا السبب فإن مدة صلاحيتها هي 30 يومًا فقط. بالإضافة إلى ذلك، ليس كل شيء مكتوب في هذه المجلة. على سبيل المثال، لا تتم كتابة الأحداث المتعلقة بالموارد التي يمكن لجميع المستخدمين الوصول إليها بشكل عام أو التي يمكن الوصول إليها دون تسجيل الدخول إلى Google Cloud Platform.
• حدث النظام - يحتوي على أحداث النظام غير المتعلقة بالمستخدمين، أو إجراءات المسؤول الذي يقوم بتغيير تكوين موارد السحابة. يتم كتابته وتخزينه دائمًا لمدة 400 يوم.
• تُعد "شفافية الوصول" مثالاً فريدًا للسجل الذي يلتقط جميع إجراءات موظفي Google (ولكن ليس لجميع خدمات Google Cloud Platform) الذين يصلون إلى بنيتك الأساسية كجزء من واجباتهم الوظيفية. يتم تخزين هذا السجل لمدة 400 يوم ولا يكون متاحًا لكل عملاء Google Cloud Platform، ولكن فقط في حالة استيفاء عدد من الشروط (إما دعم المستوى الذهبي أو البلاتيني، أو وجود 4 أدوار من نوع معين كجزء من دعم الشركة). تتوفر وظيفة مماثلة أيضًا، على سبيل المثال، في Office 365 - Lockbox.

مثال السجل: شفافية الوصول

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

يمكن الوصول إلى هذه السجلات بعدة طرق (بنفس الطريقة التي تمت مناقشتها مسبقًا من خلال Azure وAWS) - من خلال واجهة Log Viewer، أو من خلال واجهة برمجة التطبيقات، أو من خلال Google Cloud SDK، أو من خلال صفحة النشاط في مشروعك الذي مهتمون بالأحداث. وبنفس الطريقة، يمكن تصديرها إلى حلول خارجية لإجراء تحليل إضافي. ويتم هذا الأخير عن طريق تصدير السجلات إلى BigQuery أو Cloud Pub/Sub.

بالإضافة إلى Stackdriver Logging، توفر منصة Google Cloud Platform أيضًا وظيفة مراقبة Stackdriver، والتي تتيح لك مراقبة المقاييس الرئيسية (الأداء، وMTBF، والصحة العامة، وما إلى ذلك) للخدمات والتطبيقات السحابية. يمكن أن تسهل البيانات المعالجة والمرئية العثور على المشكلات في البنية الأساسية السحابية لديك، بما في ذلك في سياق الأمان. ولكن تجدر الإشارة إلى أن هذه الوظيفة لن تكون غنية جدًا في سياق أمن المعلومات، نظرًا لأن GCP اليوم ليس لديه نظير لنفس AWS GuardDuty ولا يمكنه تحديد الأحداث السيئة بين جميع الأحداث المسجلة (قامت Google بتطوير اكتشاف تهديدات الأحداث، لكنه لا يزال قيد التطوير في النسخة التجريبية ومن السابق لأوانه الحديث عن فائدته). يمكن استخدام Stackdriver Monitoring كنظام للكشف عن الحالات الشاذة، والتي سيتم بعد ذلك التحقيق فيها للعثور على أسباب حدوثها. ولكن نظرًا لقلة الموظفين المؤهلين في مجال أمن معلومات Google Cloud Platform في السوق، فإن هذه المهمة تبدو صعبة حاليًا.

ومن الجدير أيضًا تقديم قائمة ببعض وحدات أمان المعلومات التي يمكن استخدامها داخل سحابة GCP الخاصة بك، والتي تشبه ما تقدمه AWS:

• يعد Cloud Security Command Center بمثابة نظير لـ AWS Security Hub وAzure Security Center.
• Cloud DLP - الاكتشاف والتحرير التلقائي (مثل الإخفاء) للبيانات المستضافة في السحابة باستخدام أكثر من 90 سياسة تصنيف محددة مسبقًا.
• Cloud Scanner عبارة عن أداة فحص للثغرات الأمنية المعروفة (XSS وFlash حقن والمكتبات غير المصححة وما إلى ذلك) في App Engine وCompute Engine وGoogle Kubernetes.
• Cloud IAM - التحكم في الوصول إلى جميع موارد Google Cloud Platform.
• Cloud Identity - إدارة حسابات مستخدمي Google Cloud Platform والجهاز والتطبيقات من وحدة تحكم واحدة.
• Cloud HSM - حماية مفاتيح التشفير.
• خدمة إدارة المفاتيح السحابية - إدارة مفاتيح التشفير في GCP.
• التحكم في خدمة VPC - أنشئ محيطًا آمنًا حول موارد Google Cloud Platform لحمايتها من التسريبات.
• مفتاح أمان Titan - الحماية من التصيد الاحتيالي.

تنشئ العديد من هذه الوحدات أحداثًا أمنية يمكن إرسالها إلى مساحة تخزين BigQuery لتحليلها أو تصديرها إلى أنظمة أخرى، بما في ذلك SIEM. كما هو مذكور أعلاه، يعد Google Cloud Platform نظامًا أساسيًا قيد التطوير وتعمل Google الآن على تطوير عدد من وحدات أمان المعلومات الجديدة لنظامها الأساسي. من بينها اكتشاف تهديدات الأحداث (المتوفر الآن في الإصدار التجريبي)، والذي يقوم بفحص سجلات Stackdriver بحثًا عن آثار النشاط غير المصرح به (يشبه GuardDuty في AWS)، أو Policy Intelligence (المتوفر في ألفا)، والذي سيسمح لك بتطوير سياسات ذكية لـ الوصول إلى موارد Google Cloud Platform.

لقد قدمت نظرة عامة قصيرة على إمكانيات المراقبة المضمنة في الأنظمة الأساسية السحابية الشائعة. ولكن هل لديك متخصصون قادرون على العمل مع سجلات موفر IaaS "الأولية" (ليس الجميع على استعداد لشراء الإمكانات المتقدمة لـ AWS أو Azure أو Google)؟ بالإضافة إلى ذلك، يعرف الكثيرون القول المأثور "ثق ولكن تحقق"، والذي أصبح أكثر صدقًا من أي وقت مضى في مجال الأمن. ما مدى ثقتك في القدرات المضمنة لموفر السحابة الذي يرسل لك أحداث أمان المعلومات؟ إلى أي مدى يركزون على أمن المعلومات على الإطلاق؟

في بعض الأحيان يكون من المفيد النظر إلى حلول مراقبة البنية التحتية السحابية المتراكبة التي يمكن أن تكمل الأمان السحابي المدمج، وفي بعض الأحيان تكون هذه الحلول هي الخيار الوحيد للحصول على نظرة ثاقبة حول أمان بياناتك وتطبيقاتك المستضافة في السحابة. بالإضافة إلى ذلك، فهي ببساطة أكثر ملاءمة، لأنها تأخذ على عاتقها جميع مهام تحليل السجلات الضرورية التي تم إنشاؤها بواسطة خدمات سحابية مختلفة من موفري خدمات سحابية مختلفين. مثال على هذا الحل المتراكب هو Cisco Stealthwatch Cloud، الذي يركز على مهمة واحدة - مراقبة الحالات الشاذة في أمن المعلومات في البيئات السحابية، بما في ذلك ليس فقط Amazon AWS وMicrosoft Azure وGoogle Cloud Platform، ولكن أيضًا السحب الخاصة.

مثال: مراقبة أمن المعلومات باستخدام Stealthwatch Cloud

توفر AWS منصة حوسبة مرنة، ولكن هذه المرونة تسهل على الشركات ارتكاب الأخطاء التي تؤدي إلى مشكلات أمنية. ونموذج أمن المعلومات المشترك يساهم فقط في ذلك. تشغيل البرامج في السحابة مع وجود ثغرات أمنية غير معروفة (يمكن مكافحة الثغرات المعروفة، على سبيل المثال، بواسطة AWS Inspector أو GCP Cloud Scanner)، وكلمات المرور الضعيفة، والتكوينات غير الصحيحة، والمطلعين، وما إلى ذلك. وينعكس كل هذا في سلوك الموارد السحابية، والتي يمكن مراقبتها بواسطة Cisco Stealthwatch Cloud، وهو نظام لمراقبة أمن المعلومات واكتشاف الهجمات. السحب العامة والخاصة.

إحدى الميزات الرئيسية لـ Cisco Stealthwatch Cloud هي القدرة على نمذجة الكيانات. باستخدامه، يمكنك إنشاء نموذج برمجي (أي محاكاة في الوقت الفعلي تقريبًا) لكل مورد من موارد السحابة الخاصة بك (لا يهم ما إذا كان AWS أو Azure أو GCP أو أي شيء آخر). يمكن أن تتضمن هذه الخوادم والمستخدمين، بالإضافة إلى أنواع الموارد الخاصة ببيئة السحابة الخاصة بك، مثل مجموعات الأمان ومجموعات القياس التلقائي. تستخدم هذه النماذج تدفقات البيانات المنظمة التي توفرها الخدمات السحابية كمدخلات. على سبيل المثال، بالنسبة إلى AWS، ستكون هذه هي VPC Flow Logs وAWS CloudTrail وAWS CloudWatch وAWS Config وAWS Inspector وAWS Lambda وAWS IAM. تكتشف نمذجة الكيان تلقائيًا دور وسلوك أي من مواردك (يمكنك التحدث عن تصنيف جميع الأنشطة السحابية). تتضمن هذه الأدوار جهاز Android أو Apple المحمول، وخادم Citrix PVS، وخادم RDP، وبوابة البريد، وعميل VoIP، والخادم الطرفي، ووحدة التحكم بالمجال، وما إلى ذلك. ثم يقوم بمراقبة سلوكهم بشكل مستمر لتحديد متى يحدث سلوك محفوف بالمخاطر أو يهدد السلامة. يمكنك التعرف على تخمين كلمة المرور، وهجمات DDoS، وتسريبات البيانات، والوصول عن بعد غير القانوني، ونشاط التعليمات البرمجية الضارة، وفحص الثغرات الأمنية والتهديدات الأخرى. على سبيل المثال، هذا ما يبدو عليه اكتشاف محاولة الوصول عن بعد من بلد غير معتاد لمؤسستك (كوريا الجنوبية) إلى مجموعة Kubernetes عبر SSH:

وهذا ما يبدو عليه التسريب المزعوم للمعلومات من قاعدة بيانات Postgress إلى دولة لم نواجه أي تفاعل معها من قبل:

أخيرًا، هذا ما تبدو عليه العديد من محاولات SSH الفاشلة من الصين وإندونيسيا من جهاز خارجي بعيد:

أو لنفترض أن مثيل الخادم في VPC، وفقًا للسياسة، لن يكون أبدًا وجهة لتسجيل الدخول عن بُعد. لنفترض كذلك أن هذا الكمبيوتر واجه عملية تسجيل دخول عن بعد بسبب تغيير خاطئ في سياسة قواعد جدار الحماية. ستكتشف ميزة نمذجة الكيان هذا النشاط ("الوصول عن بُعد غير المعتاد") والإبلاغ عنه في الوقت الفعلي تقريبًا وستشير إلى استدعاء AWS CloudTrail أو Azure Monitor أو GCP Stackdriver Logging API المحدد (بما في ذلك اسم المستخدم والتاريخ والوقت، من بين تفاصيل أخرى ).مما أدى إلى تغيير قاعدة الاتحاد الدولي للاتصالات. ومن ثم يمكن إرسال هذه المعلومات إلى SIEM لتحليلها.

يتم تنفيذ إمكانات مماثلة لأي بيئة سحابية تدعمها Cisco Stealthwatch Cloud:

تعد نمذجة الكيانات شكلاً فريدًا من أشكال التشغيل الآلي للأمان الذي يمكنه الكشف عن مشكلة لم تكن معروفة سابقًا مع الأشخاص أو العمليات أو التكنولوجيا لديك. على سبيل المثال، يسمح لك باكتشاف المشكلات الأمنية، من بين أشياء أخرى، مثل:

• هل اكتشف أحد الأشخاص بابًا خلفيًا في البرنامج الذي نستخدمه؟
• هل هناك أي برنامج أو جهاز تابع لجهة خارجية في السحابة الخاصة بنا؟
• هل يسيء المستخدم المصرح له الامتيازات؟
• هل كان هناك خطأ في التكوين سمح بالوصول عن بعد أو أي استخدام آخر غير مقصود للموارد؟
• هل هناك تسرب للبيانات من خوادمنا؟
• هل كان هناك من يحاول الاتصال بنا من موقع جغرافي غير معتاد؟
• هل السحابة الخاصة بنا مصابة برموز ضارة؟

يمكن إرسال حدث أمان المعلومات المكتشف في شكل تذكرة مقابلة إلى Slack وCisco Spark ونظام إدارة الحوادث PagerDuty، كما يمكن إرساله أيضًا إلى العديد من SIEMs، بما في ذلك Splunk أو ELK. للتلخيص، يمكننا القول أنه إذا كانت شركتك تستخدم إستراتيجية متعددة السحابة ولا تقتصر على أي مزود سحابي واحد، فإن إمكانات مراقبة أمن المعلومات الموضحة أعلاه، فإن استخدام Cisco Stealthwatch Cloud يعد خيارًا جيدًا للحصول على مجموعة موحدة من المراقبة قدرات للاعبين السحابيين الرائدين - Amazon وMicrosoft وGoogle. الشيء الأكثر إثارة للاهتمام هو أنه إذا قارنت أسعار Stealthwatch Cloud مع التراخيص المتقدمة لمراقبة أمن المعلومات في AWS أو Azure أو GCP، فقد يتبين أن حل Cisco سيكون أرخص حتى من القدرات المدمجة في Amazon وMicrosoft وحلول جوجل. إنه أمر متناقض، لكنه صحيح. وكلما زاد عدد السحب وإمكانياتها التي تستخدمها، أصبحت ميزة الحل الموحد أكثر وضوحًا.

بالإضافة إلى ذلك، يمكن لـ Stealthwatch Cloud مراقبة السحابات الخاصة المنتشرة في مؤسستك، على سبيل المثال، استنادًا إلى حاويات Kubernetes أو من خلال مراقبة تدفقات Netflow أو حركة مرور الشبكة المستلمة من خلال النسخ المتطابق في معدات الشبكة (حتى المنتجة محليًا)، أو بيانات AD أو خوادم DNS وما إلى ذلك. سيتم إثراء كل هذه البيانات بمعلومات استقصاء التهديدات التي تجمعها Cisco Talos، وهي أكبر مجموعة غير حكومية في العالم من الباحثين في تهديدات الأمن السيبراني.

يتيح لك ذلك تنفيذ نظام مراقبة موحد لكل من السحابة العامة والمختلطة التي قد تستخدمها شركتك. يمكن بعد ذلك تحليل المعلومات المجمعة باستخدام إمكانات Stealthwatch Cloud المضمنة أو إرسالها إلى SIEM (يتم دعم Splunk وELK وSumoLogic والعديد من الميزات الأخرى افتراضيًا).

بهذا نكمل الجزء الأول من المقال والذي استعرضت فيه الأدوات المدمجة والخارجية لمراقبة أمن المعلومات لمنصات IaaS/PaaS، والتي تتيح لنا اكتشاف الحوادث التي تحدث في البيئات السحابية والاستجابة لها بسرعة لقد اختار مشروعنا. في الجزء الثاني، سنواصل الموضوع وننظر في خيارات مراقبة منصات SaaS باستخدام مثال Salesforce وDropbox، وسنحاول أيضًا تلخيص كل شيء وتجميعه معًا من خلال إنشاء نظام موحد لمراقبة أمن المعلومات لمقدمي الخدمات السحابية المختلفة.

المصدر: www.habr.com