من المفترض أن يساعد تكامل SIEM المحلل في التحقق من حالة المصادقة، وليس إنشاء حادثة لكل صف تقرير مجمع فاشل. اختر وجهة وسير عمل محددين. يستخدم هذا الدليل استيعاب Azure Monitor وإدارة حوادث Microsoft Sentinel كمثال تصميم موثق، مع التعيينات المقترحة والقرارات الافتراضية بدلاً من تكامل EmailAuth المُطالب به.
ملاحظة منفصلة عن الاكتشاف
ان تقرير مجمع يسجل تقييمات المصادقة. تضيف النتيجة تفسيرًا مثل خسارة مرسل الفواتير المعتمد بشكل غير متوقع تنسيق. احتفظ بمجموعة الأدلة والنطاق الزمني والمرسل المعروف والثقة وتأثير الأعمال. RFC 9990 يوفر دلالات التقارير. ولا يثبت أن كل فشل هو ضار أو أنه يجب فتح حادثة.
استخدم مفتاح الارتباط المحدود الذي يحتوي على نطاق العميل والمجال والمرسل والحالة. تجنب وضع نصوص الرسائل أو عناوين المستلمين في الحدث عندما تكفي البيانات التعريفية ومرجع الأدلة الذي يمكن التحكم في الوصول إليه. قم بتضمين وقت الحدوث ووقت الاستيعاب بشكل منفصل حتى لا يتم الخلط بين الأدلة المتأخرة وبين انقطاع التيار الحالي.
تعيين إلى حدود الاستيعاب الفعلية
وثائق API الخاصة بسجلات Azure Monitor يصف إرسال البيانات من خلال قاعدة جمع البيانات إلى جدول هدف، مع المصادقة والأذونات المرتبطة بها. يحتاج النشر إلى مخطط الجدول الفعلي والدفق ونقطة النهاية وDCR والهوية المعتمدة. لا يثبت تسلسل JSON الناجح وحده أن الخدمة قبلت الحدث أو قامت بفهرسته.
يقوم التعيين المقترح بتعيين قيمة events_time إلى TimeGenerated ويحدد الأعمدة المخصصة TenantScope_s و Domain_s و FindingType_s و EvidenceRef_s و CorrelationKey_s و Severity_s و SchemaVersion_s. هذه الأسماء المخصصة عبارة عن مخطط مقترح، وليست حقول Sentinel مضمنة. TenantScope_s هي تسمية ارتباط التطبيق؛ ولا يفرض عزل مستأجر Azure أو أذوناته. تكوين واختبار الوصول بشكل منفصل.
ربط وإدارة الحادث
قرر ما إذا كانت قواعد التحليلات تنشئ حوادث من البيانات المستوعبة أو يقوم محول معتمد بإدارة الحوادث مباشرة. تجنب تشغيل كلا المسارين دون إلغاء البيانات المكررة. ال تقوم حوادث Sentinel بإنشاء أو تحديث واجهة برمجة التطبيقات يوثق عملية PUT مقابل معرف حادث محدد للإصدار 2025-09-01، مع حقول العنوان والخطورة والحالة المطلوبة. قم بتثبيت الإصدار الفعلي في التنفيذ والتعامل مع التزامن بدلاً من الكتابة فوق عمل المحلل بشكل أعمى.
حافظ على العلاقة بين مفتاح الارتباط ومعرف الحادث. تخصيص معرف حادث مميز لكل مفتاح موثوق به على مستوى المستأجر؛ يمكن أن تؤدي إعادة استخدام معرف ثابت واحد عبر المفاتيح إلى استبدال حادثة عميل آخر. التحقق من صحة ربط المستأجر قبل الارتباط، نظرًا لأن سلسلة المستأجر المقدمة بواسطة حدث غير موثوق به ليست مرجعًا. يمكن للملاحظات المتكررة تحديث الحادث الحالي بأدلة إضافية بدلاً من فتح التكرارات. تعيين محلل والإجراء التالي. يجب أن يسجل الإغلاق ما تم التحقيق فيه وسبب تبرير النتيجة، وذلك باستخدام حقول الحالة والتصنيف المدعومة للوجهة.
أبقِ ارتباطات العملاء وقرارات المحللين منفصلة
لنفترض ملاحظتين لنفس خريطة فقدان المحاذاة للمرسل المعتمد لحادث واحد على نطاق العميل، في حين أن التسليم المتكرر للملاحظة الأولى لا يضيف أي دليل مكرر. يجب أن يتم تعيين النتيجة المماثلة للعميل الثاني إلى الوجهة المعتمدة الخاصة به وهوية الحادث المميزة. إن إعادة استخدام معرف حادث ثابت واحد عبر كلا المفتاحين يؤدي إلى مخاطر الكتابة فوق السجل الخاطئ، حتى إذا كانت تسمية الارتباط تحتوي على اسم مستأجر.
بشكل منفصل، قد يقوم المحلل بإغلاق الحادث الأول بعد التأكد من الاختبار المتوقع المخطط له. يجب ألا يقوم الحدث المتأخر باستبدال هذا القرار بشكل أعمى أو إعادة فتحه بدون قاعدة دورة الحياة المعتمدة. احتفظ بالأدلة الموجودة، وقم بتقييم ما إذا كانت الملاحظة الجديدة ستغير النتيجة وحل التعديلات المتزامنة باستخدام عقد الوجهة. هذه قرارات افتراضية وليست حوادث فعلية أو نتائج تصنيف أو اختبارات دورة حياة تم تنفيذها.
لا ينشئ هذا الدليل أي DCR، ولا يحصل على أي رمز مميز، ولا يستوعب أي سجلات ولا يستدعي Sentinel API. قبل قبول الإنتاج، قم بتشغيل حدث اختبار معتمد من خلال الوجهة الحقيقية، وتحقق من الحقول المفهرسة ووصول المستأجر، وممارسة التسليم المكرر وتأكيد الإغلاق دون استبدال تغييرات المحللين غير ذات الصلة. الاحتفاظ بمعرفات الطلب والنتائج المرصودة. إذا كانت هناك أي مرحلة مفقودة، فقم بتسمية التكامل على أنه تصميم موثق مع التنفيذ المعلق، وليس عنصر تحكم منشور.