مشاركة عبر

استكشاف أخطاء قواعد التحليلات وإصلاحها في Microsoft Sentinel

  • مقالة

توضح هذه المقالة كيفية التعامل مع بعض المشكلات التي قد تنشأ مع تنفيذ قواعد التحليلات المجدولة في Microsoft Sentinel.

المشكلة: لا تظهر أي أحداث في نتائج الاستعلام

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

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

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

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

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

بمعنى آخر، يتصرف الحقل OriginalQuery مثل سلوك حقل الاستعلام ضمن إعداد تجميع الأحداث الافتراضي.

المشكلة: فشل تنفيذ قاعدة مجدولة، أو يلحق باسمها «تعطل تلقائي»

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

فشل عابر

يحدث فشل عابر بسبب ظرف مؤقت وسرعان ما يعود إلى الوضع الطبيعي، وعند هذه النقطة ينجح تنفيذ القاعدة. ومن بين بعض الأمثلة على حالات الفشل التي يصنفها Microsoft Sentinel على أنها عابرة هي:

  • استغراق استعلام القاعدة وقتًا طويلاً لتشغيله وتنتهي مهلته.
  • مشكلات الاتصالية بين مصادر البيانات وLog Analytics، أو بين Log Analytics وMicrosoft Sentinel.
  • يعتبر أي فشل آخر جديد وغير معروف عابرًا.

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

فشل دائم - قاعدة قابلة للتجزئة التلقائية

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

  • تم حذف مساحة العمل الهدف (التي تم تشغيل استعلام القاعدة عليها).
  • تم حذف الجدول الهدف (الذي تم تشغيل استعلام القاعدة عليه).
  • تمت إزالة Microsoft Sentinel من مساحة العمل الهدف.
  • لم تعد الدالة المستخدمة من قبل استعلام القاعدة صالحة؛ تم تعديله أو إزالته.
  • تم تغيير الأذونات إلى أحد مصادر البيانات لاستعلام القاعدة (راجع المثال).
  • تم حذف أحد مصادر البيانات لاستعلام القاعدة.

في حالة وجود عدد محدد مسبقًا من حالات الفشل الدائمة المتتالية، من النوع نفسه وعلى القاعدة نفسها، يتوقف Microsoft Sentinel عن محاولة تنفيذ القاعدة، ويتخذ أيضًا الخطوات التالية:

  1. تعطيل القاعدة.
  2. إضافة الكلمات "تعطل تلقائي" في بداية اسم القاعدة.
  3. إضافة سبب الفشل (والتعطل) إلى وصف القاعدة.

يمكنك بسهولة تحديد وجود أي قواعد قابلة للتجزئة التلقائية، عن طريق فرز قائمة القواعد حسب الاسم. توجد القواعد القابلة للتجزئة التلقائية في أعلى القائمة أو بالقرب منها.

يجب أن يتأكد مديرو SOC من التحقق من قائمة القواعد بانتظام بحثا عن وجود قواعد قابلة للتجزئة التلقائية.

فشل دائم بسبب استنزاف الموارد

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

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

راجع أيضا الموارد المفيدة للعمل مع Kusto Query Language في Microsoft Sentinel للحصول على مزيد من المساعدة.

فشل دائم بسبب فقدان الوصول عبر الاشتراكات/المستأجرين

أحد الأمثلة المحددة على وقت حدوث فشل دائم بسبب تغيير الأذونات على مصدر بيانات (راجع القائمة) يتعلق بحالة موفر حلول أمان Microsoft (MSSP) - أو أي سيناريو آخر حيث تقوم قواعد التحليلات بالاستعلام عبر الاشتراكات أو المستأجرين.

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

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

إذا قمت بتشغيل Microsoft Sentinel في سيناريو الاشتراك المشترك أو عبر المستأجرين، وإذا فقد أحد المحللين أو المهندسين الوصول إلى مساحة عمل معينة، فستتوقف أي قواعد أنشأها هذا المستخدم عن العمل. ستحصل على رسالة مراقبة صحية تتعلق ب "الوصول غير الكافي إلى المورد"، وسيتم تقسيم القاعدة تلقائيا وفقا للإجراء الموضح سابقا.

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

لمزيد من المعلومات، راجع:

كذلك، تعلم من مثال استخدام قواعد التحليلات المخصصة عند توسيع المراقبة باستخدام مُوصّل مخصص.