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

مقالة
06/01/2023

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

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

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

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

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

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

ملاحظة

إذا لم تكن بياناتك أحد موارد Azure، مثل بيانات Syslog أو CEF أو Microsoft Azure Active Directory أو البيانات التي تم جمعها بواسطة مُجمع مخصص، فستحتاج إلى تكوين معرّف المورد يدوياً المستخدم لتحديد البيانات وتمكين الوصول. لمزيد من المعلومات، راجع تكوين RBAC لسياق الموارد بشكل صريح .

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

سيناريوهات RBAC في سياق الموارد

يبرز الجدول التالي السيناريوهات حيث يكون RBAC في سياق الموارد أكثر فائدة. لاحظ الاختلافات في متطلبات الوصول بين فرق SOC والفرق غير التابعة لها.

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

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

طرق بديلة لتنفيذ RBAC في سياق الموارد

اعتماداً على الأذونات المطلوبة في مؤسستك، قد لا يوفر استخدام RBAC لسياق الموارد حلاً كاملاً.

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

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

تكوين RBAC لسياق الموارد بشكل صريح

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

على سبيل المثال، تتضمن البيانات الموجودة في مساحة عمل Microsoft Azure Sentinel التي ليست موارد Azure بيانات Syslog أو CEF أو Microsoft Azure Active Directory أو البيانات التي تم جمعها بواسطة مُجمع مخصص.

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

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

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

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

تلميح

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

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

لمزيد من المعلومات بشأن معرفات الموارد، راجع:

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

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

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

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

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

تلميح

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

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

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

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

على سبيل المثال، يُظهر التعليمة البرمجية التالية نموذجاً لملف تكوين 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

تلميح

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

معرفات الموارد مع مجموعة API Log Analytics

عند التجميع باستخدام Log Analytics Data Collector API ، يمكنك التعيين إلى الأحداث باستخدام معرّف مورد باستخدام رأس طلب HTTP x-ms-AzureResourceId .

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

لمزيد من المعلومات، راجعالأذونات في Microsoft Azure Sentinel.

مشاركة عبر