إدارة الوصول إلى بيانات Microsoft Azure Sentinel حسب المورد
عادة، يمكن للمستخدمين الذين لديهم حق الوصول إلى مساحة عمل Log Analytics الممكنة ل Microsoft Sentinel أيضا الوصول إلى جميع بيانات مساحة العمل، بما في ذلك محتوى الأمان. يمكن للمسؤولين استخدام أدوار Azure لتكوين الوصول إلى ميزات معينة في Microsoft Azure Sentinel، بناءً على متطلبات الوصول في فريقهم.
ومع ذلك، قد يكون لديك بعض المستخدمين الذين يحتاجون إلى الوصول إلى بيانات معينة فقط في مساحة العمل الخاصة بك، ولكن لا يجب أن يكون لديهم حق الوصول إلى بيئة Microsoft Sentinel بأكملها. على سبيل المثال، قد ترغب في تزويد فريق العمليات غير الأمنية (غير SOC) بإمكانية الوصول إلى بيانات حدث Windows للخوادم التي يمتلكونها.
في مثل هذه الحالات، نوصي بتكوين التحكم في الوصول استنادا إلى الدور (RBAC) استنادا إلى الموارد المسموح بها للمستخدمين، بدلا من تزويدهم بالوصول إلى مساحة العمل أو ميزات Microsoft Sentinel المحددة. تُعرف هذه الطريقة أيضاً بإعداد RBAC لسياق الموارد .
عندما يكون لدى المستخدمين حق الوصول إلى بيانات Microsoft Sentinel عبر الموارد التي يمكنهم الوصول إليها بدلا من مساحة العمل، يمكنهم عرض السجلات والمصنفات باستخدام الطرق التالية:
عبر المورد نفسه ، مثل Azure Virtual Machine. استخدم هذه الطريقة لعرض السجلات والمصنفات لمورد معين فقط.
عبر Azure Monitor . استخدم هذه الطريقة عندما تريد إنشاء استعلامات تغطي عدة موارد و/أو مجموعات موارد. عند التنقل إلى السجلات والمصنفات في Azure Monitor، حدد نطاقك لواحد أو أكثر من مجموعات الموارد أو الموارد المحددة.
تمكين RBAC لسياق الموارد في Azure Monitor. لمزيد من المعلومات، راجع إدارة الوصول إلى بيانات السجل ومساحات العمل في Azure Monitor .
إشعار
إذا لم تكن بياناتك مورد Azure، مثل بيانات معرف Syslog أو CEF أو Microsoft Entra أو البيانات التي تم جمعها بواسطة جامع مخصص، فستحتاج إلى تكوين معرف المورد المستخدم لتحديد البيانات وتمكين الوصول يدويا. لمزيد من المعلومات، راجع تكوين التحكم في الوصول استنادا إلى الدور في سياق الموارد بشكل صريح للموارد غير التابعة ل Azure.
بالإضافة إلى ذلك، لا يتم دعم الوظائف وعمليات البحث المحفوظة في السياقات التي تركز على الموارد. لذلك، فإن ميزات Microsoft Azure Sentinel مثل التحليل والتسوية غير مدعومة لسياق الموارد RBAC في Microsoft Azure Sentinel.
سيناريوهات RBAC في سياق الموارد
يبرز الجدول التالي السيناريوهات حيث يكون RBAC في سياق الموارد أكثر فائدة. لاحظ الاختلافات في متطلبات الوصول بين فرق SOC والفرق غير التابعة لها.
نوع المتطلب | فريق SOC | فريق غير SOC |
---|---|---|
الأذونات | مساحة العمل بأكملها | موارد محددة فقط |
الوصول إلى البيانات | جميع البيانات في مساحة العمل | فقط البيانات الخاصة بالموارد التي يحق للفريق الوصول إليها |
تجربة | تجربة Microsoft Azure Sentinel الكاملة، والتي ربما تكون مقيدة بالأذونات الوظيفية المعينة للمستخدم | استعلامات السجل والمصنفات فقط |
إذا كان لدى فريقك متطلبات وصول مماثلة للفريق غير التابع لـ SOC الموضح في الجدول أعلاه، فقد يكون RBAC لسياق الموارد حلاً جيداً لمؤسستك.
على سبيل المثال، تعرض الصورة التالية إصدارا مبسطا من بنية مساحة العمل حيث تحتاج فرق الأمان والعمليات إلى الوصول إلى مجموعات مختلفة من البيانات، ويتم استخدام التحكم في الوصول استنادا إلى الدور في سياق الموارد لتوفير الأذونات المطلوبة.
في هذه الصورة:
- يتم وضع مساحة عمل Log Analytics الممكنة ل Microsoft Sentinel في اشتراك منفصل لعزل الأذونات بشكل أفضل عن الاشتراك الذي تستخدمه فرق التطبيقات لاستضافة أحمال العمل الخاصة بهم.
- يتم منح فرق التطبيقات حق الوصول إلى مجموعات الموارد الخاصة بها، حيث يمكنهم إدارة مواردهم.
يسمح هذا الاشتراك المنفصل وRBAC لسياق الموارد لهذه الفرق بعرض السجلات التي تم إنشاؤها بواسطة أي موارد لديهم حق الوصول إليها، حتى عندما يتم تخزين السجلات في مساحة عمل حيث لا يكون لديهم حق الوصول المباشر. يمكن لفرق التطبيقات الوصول إلى سجلاتها عبر منطقة السجلات في مدخل Microsoft Azure، لإظهار سجلات لمورد معين، أو عبر Azure Monitor، لإظهار جميع السجلات التي يمكنهم الوصول إليها في نفس الوقت.
تكوين التحكم في الوصول استنادا إلى الدور لسياق الموارد بشكل صريح للموارد غير التابعة ل Azure
تحتوي موارد Azure على دعم مضمن ل RBAC في سياق الموارد، ولكنها قد تتطلب ضبطا إضافيا عند العمل مع موارد غير Azure. على سبيل المثال، تتضمن البيانات في مساحة عمل Log Analytics الممكنة ل Microsoft Sentinel التي ليست موارد Azure بيانات Syslog أو CEF أو AAD أو البيانات التي تم جمعها بواسطة مجمع مخصص.
استخدم الخطوات التالية إذا كنت تريد تكوين RBAC لسياق الموارد، لكن بياناتك ليست أحد موارد Azure.
لتكوين 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 .
إذا كنت تستخدم RBAC لسياق الموارد وتريد أن تكون الأحداث التي جمعتها واجهة برمجة التطبيقات متاحة لمستخدمين محددين، فاستخدم معرف المورد لمجموعة الموارد التي أنشأتها للمستخدمين .
بدائل التحكم في الوصول استنادا إلى الدور في سياق الموارد
اعتماداً على الأذونات المطلوبة في مؤسستك، قد لا يوفر استخدام RBAC لسياق الموارد حلاً كاملاً. على سبيل المثال، ضع في اعتبارك ما إذا كان يجب على المؤسسة التي تم وصف بنيتها في القسم السابق أيضا منح حق الوصول إلى سجلات Office 365 لفريق تدقيق داخلي. في هذه الحالة، قد يستخدمون RBAC على مستوى الجدول لمنح فريق التدقيق حق الوصول إلى جدول OfficeActivity بأكمله، دون منح أذونات لأي جدول آخر.
تصف القائمة التالية السيناريوهات التي قد تلائم فيها الحلول الأخرى للوصول إلى البيانات متطلباتك بشكل أفضل:
السيناريو | حل |
---|---|
لدى إحدى الشركات التابعة فريق SOC يتطلب خبرة Microsoft Azure Sentinel كاملة . | في هذه الحالة، استخدم بنية متعددة مساحات العمل لفصل أذونات البيانات الخاصة بك. لمزيد من المعلومات، راجع: |
تريد توفير الوصول إلى نوع معين من الأحداث . | على سبيل المثال، قم بتزويد مسؤول Windows بإمكانية الوصول إلى أحداث أمان Windows في جميع الأنظمة. في مثل هذه الحالات، استخدم RBAC على مستوى الجدول لتحديد الأذونات لكل جدول. |
تقييد الوصول إلى مستوى أكثر دقة، إما لا يعتمد على المورد، أو على مجموعة فرعية فقط من الحقول في حدث ما | على سبيل المثال، قد ترغب في تقييد الوصول إلى سجلات Office 365 بناءً على شركة تابعة للمستخدم. في هذه الحالة، قم بتوفير الوصول إلى البيانات باستخدام التكامل المدمج مع لوحات تحكم وتقارير Power BI . |
تقييد الوصول حسب مجموعة الإدارة | ضع Microsoft Sentinel ضمن مجموعة إدارة منفصلة مخصصة للأمان، مما يضمن توريث الحد الأدنى فقط من الأذونات لأعضاء المجموعة. ضمن فريق الأمان، قم بتعيين أذونات لمجموعات مختلفة وفقا لكل وظيفة مجموعة. نظرا لأن جميع الفرق لديها حق الوصول إلى مساحة العمل بأكملها، فسيكون لديها حق الوصول إلى تجربة Microsoft Sentinel الكاملة، مقيدة فقط بأدوار Microsoft Sentinel التي تم تعيينها لهم. لمزيد من المعلومات، راجعالأذونات في Microsoft Azure Sentinel. |
الخطوات التالية
لمزيد من المعلومات، راجعالأذونات في Microsoft Azure Sentinel.