استكشاف مشكلات موصل AWS S3 وإصلاحها

يتيح لك موصل Amazon Web Services (AWS) S3 استيعاب سجلات خدمة AWS، التي تم جمعها في مستودعات AWS S3، إلى Microsoft Sentinel. أنواع السجلات التي ندعمها حاليا هي AWS CloudTrail وسجلات تدفق VPC وAWS GuardDuty.

توضح هذه المقالة كيفية تحديد سبب المشكلات التي تحدث في موصل AWS S3 بسرعة حتى تتمكن من العثور على الخطوات اللازمة لحل المشكلات.

تعرف على كيفية توصيل Microsoft Sentinel ب Amazon Web Services لاستيعاب بيانات سجل خدمة AWS.

لا يتلقى Microsoft Sentinel البيانات من موصل Amazon Web Services S3 أو أحد أنواع البيانات الخاصة به

سجلات موصل AWS S3 (أو أحد أنواع البيانات الخاصة به) غير مرئية في مساحة عمل Microsoft Sentinel لأكثر من 30 دقيقة بعد توصيل الموصل.

قبل البحث عن سبب وحل، راجع هذه الاعتبارات:

• قد يستغرق الأمر حوالي 20-30 دقيقة من لحظة توصيل الموصل حتى يتم استيعاب البيانات في مساحة العمل.
• تشير حالة اتصال الموصل إلى وجود قاعدة مجموعة؛ لا يشير إلى أنه تم استيعاب البيانات. إذا كانت حالة موصل Amazon Web Services S3 خضراء، فهناك قاعدة تجميع لأحد أنواع البيانات، ولكن لا توجد بيانات حتى الآن.

تحديد سبب مشكلتك

في هذا القسم، نغطي هذه الأسباب:

1. لم يتم تعيين نهج أذونات موصل AWS S3 بشكل صحيح.
2. لا يتم استيعاب البيانات في مستودع S3 في AWS.
3. لا تتلقى Amazon Simple Queue Service (SQS) في سحابة AWS إعلامات من مستودع S3.
4. لا يمكن قراءة البيانات من SQS/S3 في سحابة AWS. مع سجلات GuardDuty، تحدث المشكلة بسبب أذونات KMS خاطئة.

السبب 1: لم يتم تعيين نهج أذونات موصل AWS S3 بشكل صحيح

تحدث هذه المشكلة بسبب أذونات غير صحيحة في بيئة AWS.

إنشاء نهج الأذونات

تحتاج إلى نهج الأذونات لنشر موصل بيانات AWS S3. راجع الأذونات المطلوبة وقم بتعيين الأذونات ذات الصلة.

السبب 2: البيانات ذات الصلة غير موجودة في مستودع S3

السجلات ذات الصلة غير موجودة في مستودع S3.

الحل: البحث عن السجلات وتصدير السجلات إذا لزم الأمر

1. في AWS، افتح مستودع S3، وابحث عن المجلد ذي الصلة وفقا للسجلات المطلوبة، وتحقق مما إذا كانت هناك أي ملفات سجل داخل المجلد.
2. إذا لم تكن البيانات موجودة، فهناك مشكلة في تكوين AWS. في هذه الحالة، تحتاج إلى تكوين خدمة AWS لتصدير السجلات إلى مستودع S3.

السبب 3: لم تصل بيانات S3 إلى SQS

لم يتم نقل البيانات بنجاح من S3 إلى SQS.

الحل: تحقق من وصول البيانات وتكوين إعلامات الحدث

1. في AWS، افتح SQS ذات الصلة.
2. في علامة التبويب Monitoring ، يجب أن تشاهد نسبة استخدام الشبكة في عنصر واجهة مستخدم عدد الرسائل المرسلة . إذا لم تكن هناك نسبة استخدام الشبكة في SQS، فهناك مشكلة في تكوين AWS.
3. تأكد من أن تعريف إعلامات الحدث ل SQS يتضمن عوامل تصفية البيانات الصحيحة (البادئة واللاحقة).
   1. لمشاهدة إعلامات الحدث، في مستودع S3، حدد علامة التبويب Properties ، وحدد موقع قسم Event notifications .
   2. إذا لم تتمكن من رؤية هذا القسم، فقم بإنشائه.
   3. تأكد من أن SQS لديه النهج ذات الصلة للحصول على البيانات من مستودع S3. يجب أن يحتوي SQS على هذا النهج في علامة التبويب نهج الوصول .

السبب 4: لم يقرأ SQS البيانات

لم يقرأ SQS بيانات S3 بنجاح.

الحل: تحقق من أن SQS يقرأ البيانات

1. في AWS، افتح SQS ذات الصلة.

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

3. ارتفاع واحد في البيانات غير كاف. انتظر حتى تتوفر بيانات كافية (عدة ارتفاعات)، ثم تحقق من وجود مشكلات.

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

   SentinelHealth 
   | where TimeGenerated > ago(1d)
   | where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
   | where OperationName == 'Data fetch failure summary'
   | mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
   | extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
   | extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
   | project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedProperties
   

5. تأكد من تمكين ميزة الصحة:

   SentinelHealth 
   | take 20
   

6. إذا لم يتم تمكين ميزة الصحة، فمكنها.

تظهر البيانات من موصل AWS S3 (أو أحد أنواع البيانات الخاصة به) في Microsoft Sentinel مع تأخير أكثر من 30 دقيقة

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

تحديد سبب مشكلتك

في هذا القسم، نغطي هذه الأسباب:

• لم يتم إعداد تشفير السجل بشكل صحيح
• لم يتم تعريف إعلامات الأحداث بشكل صحيح
• أخطاء صحية أو معطل صحي

السبب 1: لم يتم إعداد تشفير السجل بشكل صحيح

إذا تم تشفير السجلات بالكامل أو جزئيا بواسطة خدمة إدارة المفاتيح (KMS)، فقد لا يكون لدى Microsoft Sentinel إذن ل KMS هذا لفك تشفير الملفات.

الحل: التحقق من تشفير السجل

تأكد من أن Microsoft Sentinel لديه إذن ل KMS هذا لفك تشفير الملفات. راجع أذونات KMS المطلوبة لسجلات GuardDuty وCloudTrail.

السبب 2: لم يتم تكوين إعلامات الأحداث بشكل صحيح

عند تكوين إعلام حدث Amazon S3، يجب تحديد أنواع الأحداث المدعومة التي يجب على Amazon S3 إرسال الإعلام إليها. إذا كان نوع الحدث الذي لم تحدده موجودا في مستودع Amazon S3، فلن يرسل Amazon S3 الإعلام.

الحل: تحقق من تعريف إعلامات الأحداث بشكل صحيح

للتحقق من تعريف إعلامات الحدث من S3 إلى SQS بشكل صحيح، تحقق مما يلي:

• يتم تعريف الإعلام من المجلد المحدد الذي يتضمن السجلات، وليس من المجلد الرئيسي الذي يحتوي على المستودع.
• يتم تعريف الإعلام بلاحقة .gz . على سبيل المثال:

السبب 3: أخطاء السلامة أو تعطيل الصحة

قد تكون هناك أخطاء في سجلات الصحة، أو قد لا يتم تمكين ميزة الصحة.

الحل: تحقق من عدم وجود أخطاء في سجلات السلامة وتمكين الصحة

1. تحقق من عدم وجود أخطاء في سجلات السلامة عن طريق تشغيل هذا الاستعلام:

   SentinelHealth
   | where TimeGenerated between (ago(startTime)..ago(endTime))
   | where SentinelResourceKind  == "AmazonWebServicesS3"
   | where Status != "Success"
   | distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description
   

2. تأكد من تمكين ميزة الصحة:

   SentinelHealth 
   | take 20
   

3. إذا لم يتم تمكين ميزة الصحة، فمكنها.

الخطوات التالية

في هذه المقالة، تعلمت كيفية تحديد الأسباب وحل المشكلات الشائعة بسرعة مع موصل AWS S3.

نرحب بالملاحظات والاقتراحات وطلبات الميزات وتقارير الأخطاء أو التحسينات والإضافات. انتقل إلى مستودع GitHub Microsoft Azure Sentinel لإنشاء مشكلة أو نسخة المستودع وتحميل مساهمة.