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

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



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

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

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

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

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



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

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

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

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

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

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

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

الخدمات السحابية المدمجة

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

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



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



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



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

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

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

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



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

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

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

لاكتشاف الحوادث ، يمكنك استخدام مجموعة واسعة من خدمات المراقبة المختلفة التي طورتها أمازون (على الرغم من أنها غالبًا ما يتم استكمالها بأدوات خارجية ، مثل التذبذب). لذلك ، في AWS ، يتم تتبع جميع إجراءات المستخدم ، بغض النظر عن كيفية تنفيذها - من خلال وحدة التحكم الإدارية أو سطر الأوامر أو SDK أو خدمات AWS الأخرى. جميع سجلات تصرفات كل حساب AWS (بما في ذلك اسم المستخدم ، الإجراء ، الخدمة ، معلمات النشاط ونتائجها) واستخدام API متاحة من خلال 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 open لإضافة وظيفة مراقبة السجل لتطبيقات المستخدم وخدماته ، مما يسمح بتوسيع نطاق الأحداث التي تم تحليلها في سياق أمن المعلومات.



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



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

• محاولات لمسح الموقع ، والبحث عن المناطق الخلفية ، والبحث عن نقاط الضعف من خلال رشقات نارية من "404 أخطاء".
• Injection- (, SQL injection) “ 500”.
• sqlmap, nikto, w3af, nmap .. User Agent.

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



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

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

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



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

• CloudTrail - استخدام API وإجراءات المستخدم
• مستشار موثوق - التحقق من الأمان لأفضل الممارسات
• Config —
• VPC Flow Logs —
• IAM —
• ELB Access Logs —
• Inspector —
• S3 —
• CloudWatch —
• SNS — .

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

مثال: مراقبة IS في IaaS المستندة إلى Azure

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

لطالما كانت منتجات Microsoft تتميز "بالانفتاح" ، وفي أزور يتشابه الموقف. على سبيل المثال ، إذا كانت 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 الأخرى ، بما في ذلك تحليل الأحداث الأمنية ، لم تتم إدارتها بعد بالطريقة الأكثر ملاءمة. يتم حل جزء من المشكلة من خلال واجهة برمجة التطبيقات التي تتخلل جميع خدمات Microsoft Azure ، ولكن هذا سيتطلب جهودًا إضافية لدمج السحابة الخاصة بك مع SOC وتوافر متخصصين مؤهلين (في الواقع ،كما هو الحال مع أي دولة أخرى. SIEM العمل مع واجهات برمجة التطبيقات السحابية). بعض SIEMs ، التي سيتم مناقشتها لاحقًا ، تدعم Azure بالفعل ويمكنها أتمتة مهمة مراقبتها ، ولكن هناك بعض الصعوبات في ذلك - لا يمكن لجميعهم أخذ جميع السجلات التي لدى Azure.



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



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

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

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

• مجالات الأمان - المؤشرات الكمية الرئيسية المتعلقة بأمن المعلومات - عدد الحوادث ، وعدد العقد المعرضة للخطر ، والعقد غير المرسلة ، وأحداث أمان الشبكة ، إلخ.
• المشكلات البارزة - يعرض عدد وأهمية مشكلات IB النشطة
• Detections — ,
• Threat Intelligence — ,
• استفسارات الأمان الشائعة - استعلامات نموذجية ستساعدك في مراقبة أمان معلوماتك بشكل أفضل.

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



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



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

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



إذا كنت لا تحتاج فقط إلى القدرة على العمل مع السجلات ، ولكن في مركز الأمان الشامل لمنصة Azure السحابية الخاصة بك ، بما في ذلك إدارة سياسات IS ، يمكنك التحدث عن الحاجة للعمل مع Azure Security Center ، والتي يكون معظمها مفيدًا مقابل رسوم ، على سبيل المثال ، الكشف عن التهديدات والمراقبة خارج أزور ، تقييم المطابقة ، إلخ. (في الإصدار المجاني ، لا يمكنك الوصول إلا إلى تقييم الأمان والتوصيات لحل المشكلات المحددة). إنه يدمج جميع مشكلات الأمان في مكان واحد. في الواقع ، يمكننا التحدث عن مستوى أعلى من أمان المعلومات الذي توفره 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 ومركز الأمان اسم SOC لـ Cloud Azure ويمكن أن يكونا محددين (مع بعض الحجوزات) إذا لم تعد لديك أي بنية تحتية وقمت بنقل جميع موارد الحوسبة إلى السحابة وستكون سحابة Microsoft اللازوردية.



ولكن نظرًا لأن القدرات المضمنة لـ Azure (حتى مع اشتراك Sentinel) لا تكفي غالبًا لرصد IS وتكامل هذه العملية مع المصادر الأخرى للأحداث الأمنية (السحابية والداخلية على حد سواء) ، فهناك حاجة إلى تصدير البيانات التي تم جمعها إلى أنظمة خارجية ، والتي قد تشمل SIEM. يتم ذلك بمساعدة واجهة برمجة التطبيقات ، وبمساعدة الملحقات الخاصة المتاحة رسميًا في الوقت الحالي فقط من أجل SIEMs التالية - Splunk (Azure Monitor Add-On لـ Splunk) و IBM QRadar (Microsoft Azure DSM) و SumoLogic و ArcSight و ELK. في الآونة الأخيرة ، كان هناك المزيد من هذه SIEMs ، ولكن من 1 يونيو 2019 ، توقفت مايكروسوفت عن دعم أداة تكامل سجل Azure (AzLog) ، والتي في فجر Azure وفي غياب التوحيد العادي للعمل مع السجلات (لم يكن Azure Monitor موجودًا) دمج SIEMs الخارجية مع Microsoft Cloud. لقد تغير الموقف الآن وتوصي Microsoft النظام الأساسي Azure Event Hub كأداة التكامل الرئيسية لبقية SIEM. قام الكثيرون بالفعل بتطبيق هذا التكامل ، لكن كن حذرًا - فقد لا يلتقطون جميع سجلات 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 ، الذي كان يبني قدراته ، بما في ذلك القدرات الدفاعية ، يواجه مشاكل مع المركزية ؛ تتم إدارة GCP ، مثل Azure ، بشكل أفضل بشكل مركزي ، مما يقلل من عدد الأخطاء ووقت التنفيذ في المؤسسة. من وجهة نظر أمنية ، يوجد برنامج شركاء Google المعتمدون ، بشكل غريب ، بين AWS و Azure. لديه أيضًا تسجيل حدث واحد للمؤسسة بأكملها ، لكنه غير كامل. لا تزال بعض الوظائف في الوضع التجريبي ، ولكن يجب إزالة هذا النقص تدريجياً وسيصبح برنامج "شركاء Google المعتمدون" منصة أكثر نضجًا فيما يتعلق بمراقبة أمن المعلومات.



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

• نشاط المشرف - يحتوي على جميع الأحداث المتعلقة بالوصول الإداري ، على سبيل المثال ، إنشاء جهاز ظاهري ، وتغيير حقوق الوصول ، إلخ. تتم كتابة هذه المجلة دائمًا ، بغض النظر عن رغبتك ، وتخزين بياناتها لمدة 400 يوم.
• الوصول إلى البيانات - يحتوي على جميع الأحداث المتعلقة بالعمل مع البيانات من مستخدمي السحابة (إنشاء ، تعديل ، قراءة ، وما إلى ذلك). بشكل افتراضي ، لا تتم كتابة هذه المجلة ، لأن حجمها يتضخم بسرعة كبيرة. لهذا السبب ، العمر الافتراضي لها هو 30 يومًا فقط. بالإضافة إلى ذلك ، بعيدا عن كل شيء مكتوب في هذه المجلة. على سبيل المثال ، لا تتم كتابة الأحداث المتعلقة بالموارد المتاحة للجميع لجميع المستخدمين أو التي يمكن الوصول إليها دون الوصول إلى برنامج "شركاء Google المعتمدون".
• حدث النظام - يحتوي على أحداث النظام التي لا تتعلق بالمستخدمين ، أو تصرفات المسؤول الذي يغير تكوين الموارد السحابية. يتم كتابتها وتخزينها دائمًا لمدة 400 يوم.
• يعد Access Transparency مثالًا فريدًا على سجل يقوم بتسجيل جميع إجراءات موظفي Google (ولكن ليس لجميع خدمات GCP حتى الآن) الذين يصلون إلى البنية التحتية الخاصة بك كجزء من مسؤولياتهم الوظيفية. يتم تخزين هذه المجلة لمدة 400 يوم وهي غير متوفرة لكل عميل في برنامج "شركاء Google المعتمدون" ، ولكنها تخضع فقط لعدد من الشروط (إما دعم ذهبي أو بلاتيني ، أو وجود 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 سابقًا) - من خلال واجهة عارض السجل ، من خلال واجهة برمجة التطبيقات ، أو من خلال Google Cloud SDK أو من خلال صفحة النشاط في مشروعك ، والتي تهتم بالأحداث وفقًا لها. بنفس الطريقة ، يمكن أيضًا تصديرها إلى حلول خارجية لإجراء تحليل إضافي. يتم الأخير عن طريق تصدير السجلات إلى BigQuery أو Cloud Pub / Sub التخزين.

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



من المفيد أيضًا سرد بعض وحدات أمان المعلومات التي يمكن استخدامها داخل سحابة برنامج "شركاء Google المعتمدون" ، والتي تشبه ما تقدمه AWS:

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

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

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

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

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

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



تتمثل إحدى الميزات الرئيسية لسيسكو Stealthwatch Cloud في القدرة على تصميم كيانات. من خلال مساعدتها ، يمكنك إنشاء نموذج برنامج (أي محاكاة في الوقت الفعلي تقريبًا) لكل من موارد السحابة الخاصة بك (لا يهم إذا كان AWS أو Azure أو GCP أو أي شيء آخر). قد تشمل هذه الخوادم والمستخدمين ، وكذلك أنواع الموارد الخاصة ببيئة السحابة الخاصة بك ، مثل مجموعات الأمان ومجموعات النطاق التلقائي. تستخدم هذه النماذج تدفقات البيانات المهيكلة التي توفرها الخدمات السحابية كمدخلات. على سبيل المثال ، بالنسبة إلى AWS ، ستكون هذه هي سجلات تدفق VPC و 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:



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

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

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



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



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

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