إدارة الوصول إلى بيانات Microsoft Sentinel حسب المورد

تتم إدارة الوصول إلى مساحة عمل باستخدام Azure RBAC. عادة ما يكون لدى المستخدمين الذين لديهم حق الوصول إلى مساحة عمل Log Analytics الممكنة Microsoft Sentinel أيضا حق الوصول إلى جميع بيانات مساحة العمل، بما في ذلك محتوى الأمان. يمكن للمسؤولين استخدام أدوار Azure لتكوين الوصول إلى ميزات محددة في Microsoft Sentinel، اعتمادا على متطلبات الوصول في فريقهم.

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

في مثل هذه الحالات، نوصي بتكوين التحكم في الوصول استنادا إلى الدور (RBAC) استنادا إلى الموارد المسموح بها للمستخدمين، بدلا من تزويدهم بالوصول إلى مساحة العمل أو ميزات Microsoft Sentinel محددة. يعرف هذا الأسلوب أيضا باسم إعداد التحكم في الوصول استنادا إلى الدور لسياق الموارد.

عندما يكون لدى المستخدمين حق الوصول إلى بيانات Microsoft Sentinel عبر الموارد التي يمكنهم الوصول إليها بدلا من مساحة العمل، يمكنهم عرض السجلات والمصنفات باستخدام الطرق التالية:

• عبر المورد نفسه، مثل جهاز ظاهري Azure. استخدم هذا الأسلوب لعرض السجلات والمصنفات لمورد معين فقط.

• عبر Azure Monitor. استخدم هذا الأسلوب عندما تريد إنشاء استعلامات تمتد عبر موارد و/أو مجموعات موارد متعددة. عند الانتقال إلى السجلات والمصنفات في Azure Monitor، حدد النطاق الخاص بك إلى مجموعة موارد أو موارد محددة واحدة أو أكثر.

تمكين التحكم في الوصول استنادا إلى الدور لسياق الموارد في Azure Monitor. لمزيد من المعلومات، راجع إدارة الوصول إلى بيانات السجل ومساحات العمل في Azure Monitor.

ملاحظة

إذا لم تكن بياناتك موردا Azure، مثل Syslog أو CEF أو بيانات Microsoft Entra ID أو البيانات التي تم جمعها بواسطة مجمع مخصص، فستحتاج إلى تكوين معرف المورد المستخدم يدويا لتحديد البيانات وتمكين الوصول. لمزيد من المعلومات، راجع تكوين التحكم في الوصول استنادا إلى الدور لسياق الموارد بشكل صريح للموارد غير Azure.

بالإضافة إلى ذلك، لا يتم دعم الوظائف وعمليات البحث المحفوظة في السياقات التي تركز على الموارد. لذلك، لا يتم دعم ميزات Microsoft Sentinel مثل التحليل والتسوية ل RBAC لسياق الموارد في Microsoft Sentinel.

سيناريوهات التحكم في الوصول استنادا إلى الدور لسياق الموارد

يسلط الجدول التالي الضوء على السيناريوهات التي يكون فيها التحكم في الوصول استنادا إلى الدور لسياق الموارد مفيدا للغاية. لاحظ الاختلافات في متطلبات الوصول بين فرق SOC والفرق غير التابعة ل SOC.

نوع المتطلب	فريق SOC	فريق غير تابع ل SOC
الأذونات	مساحة العمل بأكملها	موارد محددة فقط
الوصول إلى البيانات	كافة البيانات في مساحة العمل	بيانات الموارد المصرح للفريق بالوصول إليها فقط
الخبرة	تجربة Microsoft Sentinel الكاملة، ربما تكون محدودة بالأذونات الوظيفية المعينة للمستخدم	تسجيل الاستعلامات والمصنفات فقط

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

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

في هذه الصورة:

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

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

تكوين التحكم في الوصول استنادا إلى الدور لسياق الموارد بشكل صريح للموارد غير Azure

تحتوي Azure الموارد على دعم مضمن ل RBAC لسياق الموارد، ولكنها قد تتطلب ضبطا إضافيا عند العمل مع موارد غير Azure. على سبيل المثال، البيانات في مساحة عمل Log Analytics الممكنة Microsoft Sentinel غير Azure تتضمن الموارد بيانات Syslog أو CEF أو AAD أو البيانات التي تم جمعها بواسطة مجمع مخصص.

استخدم الخطوات التالية إذا كنت تريد تكوين التحكم في الوصول استنادا إلى الدور لسياق الموارد، ولكن بياناتك ليست موردا Azure.

لتكوين التحكم في الوصول استنادا إلى الدور لسياق الموارد بشكل صريح:

1. تأكد من تمكين التحكم في الوصول استنادا إلى الدور لسياق الموارد في Azure Monitor.

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

   تعيين أذونات قارئ السجل لكل عضو من أعضاء الفريق.

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

   عندما ترسل الموارد Azure البيانات إلى Microsoft Sentinel، يتم وضع علامة تلقائيا على سجلات السجل بمعرف المورد لمصدر البيانات.

   تلميح

   نوصي بتجميع الموارد التي تمنح حق الوصول لها ضمن مجموعة موارد معينة تم إنشاؤها لهذا الغرض.

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

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

   • معرفات الموارد مع إعادة توجيه السجل
   • معرفات الموارد مع مجموعة Logstash
   • معرفات الموارد مع مجموعة واجهة برمجة تطبيقات Log Analytics

معرفات الموارد مع إعادة توجيه السجل

عند تجميع الأحداث باستخدام Common Event Format (CEF) أو Syslog، يتم استخدام إعادة توجيه السجل لجمع الأحداث من أنظمة مصدر متعددة.

على سبيل المثال، عندما يستمع جهاز ظاهري لإعادة توجيه CEF أو Syslog للمصادر التي ترسل أحداث Syslog، ويعيد توجيهها إلى Microsoft Sentinel، يتم تعيين معرف مورد الجهاز الظاهري لإعادة توجيه السجل لجميع الأحداث التي يعيدون توجيهها.

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

على سبيل المثال، يضمن فصل الأجهزة الظاهرية جمع أحداث Syslog التي تنتمي إلى الفريق A باستخدام الجهاز الظاهري المجمع A.

تلميح

• عند استخدام جهاز ظاهري محلي أو جهاز ظاهري سحابي آخر، مثل AWS، كمرسل توجيه السجل الخاص بك، تأكد من أن لديه معرف مورد من خلال تنفيذ Azure Arc.
• لتوسيع نطاق بيئة الجهاز الظاهري لإعادة توجيه السجل، ضع في اعتبارك إنشاء مجموعة مقياس جهاز ظاهري لجمع سجلات CEF وSyslog.

معرفات الموارد مع مجموعة Logstash

إذا كنت تجمع بياناتك باستخدام المكون الإضافي لإخراج Microsoft Sentinel Logstash، فاستخدم حقل azure_resource_id لتكوين المجمع المخصص لتضمين معرف المورد في الإخراج الخاص بك.

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

على سبيل المثال، تعرض التعليمات البرمجية التالية نموذج ملف تكوين Logstash:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

تلميح

قد تحتاج إلى إضافة مقاطع متعددة output للتمييز بين العلامات المطبقة على أحداث مختلفة.

معرفات الموارد مع مجموعة واجهة برمجة تطبيقات Log Analytics

عند التجميع باستخدام واجهة برمجة تطبيقات مجمع بيانات Log Analytics، يمكنك تعيين الأحداث باستخدام معرف مورد باستخدام عنوان طلب HTTP x-ms-AzureResourceId .

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

بدائل التحكم في الوصول استنادا إلى الدور لسياق الموارد

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

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

السيناريو	الحل
لدى الشركة الفرعية فريق SOC يتطلب تجربة Microsoft Sentinel كاملة.	في هذه الحالة، استخدم بنية مساحة عمل متعددة لفصل أذونات البيانات. لمزيد من المعلومات، اطلع على: توسيع Microsoft Sentinel عبر مساحات العمل والمستأجرين > العمل مع الحوادث في العديد من مساحات العمل في وقت واحد
تريد توفير الوصول إلى نوع معين من الأحداث.	على سبيل المثال، قم بتزويد مسؤول Windows بإمكانية الوصول إلى أحداث أمن Windows في جميع الأنظمة. في مثل هذه الحالات، استخدم التحكم في الوصول استنادا إلى الدور على مستوى الجدول لتحديد الأذونات لكل جدول.
تقييد الوصول إلى مستوى أكثر دقة، إما لا يستند إلى المورد، أو إلى مجموعة فرعية فقط من الحقول في حدث ما	على سبيل المثال، قد ترغب في تقييد الوصول إلى سجلات Office 365 استنادا إلى شركة تابعة للمستخدم. في هذه الحالة، قم بتوفير الوصول إلى البيانات باستخدام التكامل المضمن مع لوحات معلومات وتقارير Power BI.
تقييد الوصول حسب مجموعة الإدارة	ضع Microsoft Sentinel ضمن مجموعة إدارة منفصلة مخصصة للأمان، ما يضمن توريث الحد الأدنى فقط من الأذونات لأعضاء المجموعة. ضمن فريق الأمان الخاص بك، قم بتعيين أذونات لمجموعات مختلفة وفقا لكل وظيفة مجموعة. نظرا لأن جميع الفرق لديها حق الوصول إلى مساحة العمل بأكملها، فسيكون لديها حق الوصول إلى تجربة Microsoft Sentinel الكاملة، مقيدة فقط بالأدوار Microsoft Sentinel التي تم تعيينها لها. لمزيد من المعلومات، راجع الأذونات في Microsoft Sentinel.

المحتويات ذات الصلة

لمزيد من المعلومات، اطلع على:

• الأذونات في Microsoft Sentinel
• إدارة الوصول إلى مساحات عمل Log Analytics
• ما هو التحكم في الوصول المستند إلى الدور Azure (Azure RBAC)؟