إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يسمح لك التحكم في الوصول المستند إلى الدور متعدد المستويات (RBAC) في Azure Monitor Log Analytics بتصفية بيانات مساحة العمل التي يمكن لكل مستخدم عرضها أو الاستعلام فيها، استنادا إلى الشروط التي تحددها لتلبية احتياجات عملك وأمانك. تشمل فوائد التحكم في الوصول هذا ما يلي:
- الوصول إلى مستوى الصف
- الوصول إلى مستوى الجدول
- فصل مستويات التحكم والبيانات
إذا كانت بنية Log Analytics تتضمن مساحات عمل متعددة لاستيعاب فصل البيانات أو الخصوصية أو الامتثال، فإن RBAC الدقيق يساعد في تبسيط المخطط الخاص بك عن طريق تقليل عدد مساحات العمل المطلوبة.
فيديو مقدمة
المتطلبات الأساسية
| فعل | الإذن مطلوب |
|---|---|
| إنشاء دور مخصص جديد |
Microsoft.Authorization/roleDefinitions/write إذن في النطاقات القابلة للتعيين.
على سبيل المثال، كما هو منصوص عليه في الدور المضمن المتميز، مسؤولو وصول المستخدم. |
| إضافة شروط أو تحديثها |
Microsoft.Authorization/roleAssignments/write والأذونات Microsoft.Authorization/roleAssignments/delete إلى مساحة عمل Log Analytics.
على سبيل المثال، كما هو منصوص عليه في الدور المضمن المتميز، مسؤول التحكم في الوصول المستند إلى الدور. |
متى تستخدم التحكم في الوصول استنادا إلى الدور متعدد المستويات؟
يساعدك التحكم في الوصول استنادا إلى الدور متعدد المستويات على تحقيق السيناريوهات التالية:
- فصل البيانات - افصل بيانات الوحدات والفرق والمواقع الجغرافية المختلفة من داخل نفس مساحة العمل، وتأكد من أن كل مستخدم يمكنه الوصول إلى البيانات ذات الصلة بمجموعته فقط. تستخدم شروط الوصول حقول السجل المخصصة لفرض الوصول على مستوى الصف مقسمة حسب سمات مثل جدار الحماية أو نوع الجهاز أو معرف الاشتراك أو المعرفات الأخرى.
- خصوصية البيانات - حماية البيانات الحساسة أو السرية، مثل المعلومات الشخصية أو السجلات الصحية أو المعاملات المالية، والسماح فقط بالوصول إلى المستخدمين المصرح لهم.
- توافق البيانات - استخدم التحكم في الوصول استنادا إلى الدور متعدد المستويات كأداة لمساعدتك على تلبية المتطلبات التنظيمية أو القانونية لمجالك أو منطقتك. فرض النهج وعناصر التحكم المناسبة على الوصول إلى البيانات واستخدامها.
يتحكم التحكم في الوصول استنادا إلى الدور متعدد المستويات في الوصول إلى البيانات مثل عرض البيانات أو الاستعلام فيها. لا يعالج إجراءات وحدة التحكم، مثل تعيين أذونات الوصول إلى البيانات أو إدارة مساحة العمل أو التحويلات أو تصدير البيانات.
تكوين التحكم في الوصول استنادا إلى الدور متعدد المستويات
انتقل إلى RBAC متعدد المستويات باستخدام مثال RBAC متعدد المستويات خطوة بخطوة.
توفر الأقسام التالية نظرة عامة على المفاهيم والخطوات الرئيسية المتضمنة في تكوين التحكم في الوصول استنادا إلى الدور متعدد المستويات.
اختيار الدور
لتكوين RBAC دقيق، استخدم الدور المضمن أو قارئ بيانات Log Analytics أو أنشئ دورا مخصصا بإجراءات محددة مطلوبة. ثم قم بتعيين الدور المحدد باستخدام الشروط. لمزيد من المعلومات حول الأدوار المخصصة، راجع أدوار Azure المخصصة.
الحد الأدنى المطلوب من الإجراءات وأذونات إجراءات البيانات:
| تعريف الدور المخصص | الإذن | الوصف |
|---|---|---|
| مستوى التحكم (الإجراءات) | Microsoft.OperationalInsights/workspaces/query/read |
تشغيل الاستعلامات في Log Analytics ورؤية بيانات التعريف. لا يمنح هذا الإذن حق الوصول إلى البيانات. |
| مستوى البيانات (DataActions) | Microsoft.OperationalInsights/workspaces/tables/data/read |
الوصول إلى البيانات وهو dataaction المختار في شرط تعيين الدور. إذا لم يتم تعيين أي شرط، يمنح هذا الإذن الوصول إلى جميع البيانات في النطاق المعين. |
اختياريا، قم بتضمين الوصول إلى واجهة مستخدم السجلات في مدخل Microsoft Azure عن طريق إضافة إجراء التحكم Microsoft.OperationalInsights/workspaces/read . لمزيد من المعلومات، راجع التحكم في Azure RBAC وإجراءات البيانات.
ملاحظة
يعد التحكم في الوصول استنادا إلى الدور متعدد المستويات، مثل Azure RBAC، نموذجا مضافة. أذوناتك الفعالة هي مجموع تعيينات الدور. لكي تسري شروط التحكم في الوصول استنادا إلى الدور متعدد المستويات، يجب إزالة أي تعيينات أدوار ذات امتيازات وصول أعلى.
على سبيل المثال، إذا كان لديك تعيينان للدور على نفس النطاق، مجموعة واحدة مع */read إجراء والأخرى بشروط تحد من الوصول إلى سجلات معينة، فإن الإذن الناتج هو الإجراء الذي */read يمنح حق الوصول إلى جميع السجلات في النطاق. لا يوجد إجراء رفض صريح، فقط رفض التعيينات.
الشروط والتعبيرات
تماما مثل تعيينات الأدوار العادية، يجب تعيين الدور المخصص الذي تم إنشاؤه إلى مستخدم أو مجموعة. الفرق هو أنه أثناء تعيين الدور، يتم تكوين الشروط لضبط التحكم في الوصول بدقة.
يسمح لك التحكم في الوصول استنادا إلى الدور متعدد المستويات بتعيين شرط على الجداول وعلى مستوى الصف، استنادا إلى البيانات الموجودة في كل سجل. تخطيط القيود استنادا إلى هاتين الاستراتيجيتين:
| طريقة التحكم بالوصول | مثال |
|---|---|
| لا يوجد وصول إلى البيانات، باستثناء ما هو مسموح به | تقييد الوصول إلى سجلات التطبيق بحيث يمكن للمستخدمين فقط رؤية السجلات حيث application id العمود هو تطبيق يسمح لهم بالوصول إليه. |
| الوصول إلى جميع البيانات، باستثناء ما هو غير مسموح به | السماح بالوصول إلى جميع سجلات تسجيل الدخول، باستثناء السجلات التي يكون العمود فيها userPrincipalName الرئيس التنفيذي. |
يتكون الشرط من إجراء بيانات الدور والتعبيرات. التعبير عبارة منطقية بتنسيق AttributeOperatorValue.
يتم تقييد القيم مع دعم الأحرف التالية:
- الأحرف الأبجدية الرقمية
- أحرف خاصة:
@، ،.-
يدعم Log Analytics RBAC متعدد المستويات سمات الجدول والعمود/القيمة:
| مصدر السمة | اسم العرض | النوع | الوصف | اسم السمة |
|---|---|---|---|---|
| مورد | اسم الجدول | سلسلة | أسماء الجداول المستخدمة لمنح/تقييد. | Microsoft.OperationalInsights/workspaces/tables:'<name>' |
| مورد | قيمة العمود (المفتاح هو اسم العمود) | القاموس (قيمة المفتاح) | اسم العمود وقيمته. اسم العمود هو المفتاح. قيمة البيانات في العمود هي القيمة. | Microsoft.OperationalInsights/مساحات العمل/الجداول/السجل:<مفتاح> |
فيما يلي مثال على لقطة شاشة لحالة تعيين دور RBAC متعدد المستويات باستخدام عدم الوصول إلى البيانات، باستثناء الطريقة المسموح بهاالتي تم تكوينها باستخدام مدخل Microsoft Azure.
تقليل التعقيد عن طريق تكوين تعيينات دور التحكم في الوصول استنادا إلى الدور متعدد المستويات في النطاق الذي قمت بتعيين شروطه لمطابقتها. على سبيل المثال، إذا تم تعيين دورك المخصص في نطاق مجموعة موارد، فمن المحتمل ألا تحتوي مساحات العمل الأخرى على موارد الجدول أو العمود المحددة في التعبير الخاص بك، مما يتسبب في تطبيق الشرط الخاص بك بشكل غير متوقع.
ومع ذلك، إذا قمت بتعيين شرط لتعيين دور على مستوى الجدول، يجب إنشاء دورين كما يلي:
- الدور 1: الإجراء:
Microsoft.OperationalInsights/workspaces/query/readلمساحة عمل الجدول. - الدور 2: DataAction:
Microsoft.OperationalInsights/workspaces/tables/data/readللجدول داخل مساحة العمل هذه. حدد الشرط على الدور مع إجراء البيانات.
لتجنب إنشاء دورين، استخدم أبسط نهج عن طريق تعيين الدور في مساحة العمل وتعيين الشروط للتحكم في مستوى الجدول.
لمزيد من المعلومات، راجع مستويات نطاق Azure RBAC.
عوامل تشغيل التعبير
تستخدم تعبيرات التحكم في الوصول استنادا إلى الدور متعددة المستويات مجموعة فرعية من عوامل تشغيل التحكم في الوصول المستندة إلى السمات (ABAC).
تدعم سمة اسم الجدول أربعة عوامل تشغيل. تمنحك عوامل التشغيل هذه المرونة لمطابقة قيم أسماء الجداول عند تعيين شرط.
| عوامل تشغيل ABAC | الوصف |
|---|---|
StringEquals |
المطابقة الحساسة لحالة الأحرف. يجب أن تتطابق القيم تماما مع السلسلة. |
StringNotEquals |
نفي StringEquals. |
ForAllOfAnyValues:StringEquals |
مكافئ منطقيا ل in(). إذا كانت كل قيمة على الجانب الأيسر تفي للمقارنة بقيمة واحدة على الأقل على الجانب الأيمن، تقييم التعبير إلى صحيح. |
ForAllOfAllValues:StringNotEquals |
مكافئ منطقيا ل !in(). إذا كانت كل قيمة على الجانب الأيسر تفي للمقارنة بقيمة واحدة على الأقل على الجانب الأيمن، تقييم التعبير إلى خطأ. |
تستند شروط ABAC المحددة لقيم الأعمدة في Log Analytics إلى البيانات الموجودة في هذا العمود. يمكن مقارنة أنواع بيانات السلسلة فقط. بالنسبة لسمة الوصول على مستوى الصف، يستند أي تحويل فقط إلى سلوك KQL.
يعرض الجدول التالي عوامل تشغيل تعبير ABAC المعتمدة. يتم سرد عوامل تشغيل Kusto المكافئة للوضوح.
| عامل تشغيل ABAC | عامل التشغيل المكافئ Kusto | الوصف |
|---|---|---|
StringEquals / StringEqualsIgnoreCase |
== / =~ |
مطابقة حساسة لحالة الأحرف (أو غير حساسة لحالة الأحرف). يجب أن تتطابق القيم تماما مع السلسلة. |
StringNotEquals / StringNotEqualsIgnoreCase |
!= / !~ |
نفي StringEquals (أو StringEqualsIgnoreCase). |
StringLike / StringLikeIgnoreCase |
has_cs / has |
مطابقة حساسة لحالة الأحرف (أو غير حساسة لحالة الأحرف). الجانب الأيمن من عامل التشغيل (RHS) هو مصطلح كامل في الجانب الأيسر (LHS). |
StringNotLike / StringNotLikeIgnoreCase |
!has_cs / !has |
نفي عامل تشغيل StringLike (أو StringLikeIgnoreCase) |
StringStartsWith / StringStartsWithIgnoreCase |
startswith_cs/ startswith |
مطابقة حساسة لحالة الأحرف (أو غير حساسة لحالة الأحرف). تبدأ القيمة بالسلسلة. |
StringNotStartsWith / StringNotStartsWithIgnoreCase |
!startswith_cs / !startswith |
نفي عامل تشغيل StringStartsWith (أو StringStartsWithIgnoreCase). |
ForAllOfAnyValues:StringEquals / ForAllOfAnyValues:StringEqualsIgnoreCase ForAllOfAllValues:StringNotEquals / ForAllOfAllValues:StringNotEqualsIgnoreCaseForAnyOfAnyValues:StringLikeIgnoreCase |
In / In~ !in / !in~ has_any |
يدعم 'ForAllOfAnyValues:<BooleanFunction>' سلاسل وأرقاما متعددة.
إذا كانت كل قيمة على الجانب الأيسر تفي للمقارنة بقيمة واحدة على الأقل على الجانب الأيمن، تقييم التعبير إلى صحيح. |
لا يتم تعيين شروط ABAC على الوظائف مباشرة. إذا قمت بتعيين الشرط على جدول، نشره حتى أي دالة تعتمد عليه. لمزيد من المعلومات حول عوامل التشغيل والمصطلحات، راجع عوامل تشغيل السلسلة.
تلميح
استخدم التحويلات لإثراء البيانات وتغيير أنواع البيانات وتغيير الحالة لتناسب تعبيرات ABAC بشكل أفضل. إذا كانت بياناتك لا تدعم الشروط التي تريد تطبيقها، فإن التحويلات هي أيضا الحل. على سبيل المثال، لتطبيق شروط على البيانات ذات العلاقة الأساسية العالية، مثل نطاقات IP، استخدم التحويلات لتجميع عناوين IP التي تنتمي إلى شبكات فرعية محددة حسب اسم الشبكة الفرعية.
لمزيد من المعلومات، راجع تحويلات جمع البيانات في Azure Monitor.
الاعتبارات
تنطبق العديد من الاعتبارات عند استخدام التحكم في الوصول استنادا إلى الدور متعدد المستويات في Log Analytics. توفر الأقسام التالية تفاصيل.
- يتوفر RBAC الدقيق في السحابة العامة وAzure Commercial (GCC) وAzure China.
Azure Monitor
- يتم التخطيط لمهام البحث وقواعد الملخص لدعم التحكم في الوصول استنادا إلى الدور متعدد المستويات، ولكن ليس تصدير البيانات. لكل هذه التجارب، إذا لم يكن الوصول الكامل موجودا إلى الجداول التي تم الاستعلام عليها، فلن يتمكن المستخدم من تكوين مهمة البحث أو القاعدة ويتلقى خطأ.
- التنبيهات: يتم دعم تنبيهات السجل المستندة إلى الهوية المدارة فقط.
- Application Insights: يتم دعم Application Insights المستندة إلى مساحة العمل فقط.
Microsoft Sentinel
عند نسخ البيانات من الجداول الأصلية باستخدام التتبع والإشارات المرجعية وقاعدة التحليلات والحوادث، لا تكون البيانات المنسوخة نسخا متماثلا محمية بشروط ABAC.
Azure ABAC وRBAC
تنطبق قيود Azure RBAC وABAC العادية. على سبيل المثال، حد تعيينات الدور الأقصى لكل اشتراك هو حد خدمة Azure ل RBAC. يحد Azure ABAC من عدد التعبيرات لكل شرط والحجم الإجمالي للشرط في KB. لمزيد من المعلومات، راجع المقالات التالية:
- حدود التحكم في الوصول استنادا إلى الدور في Azure
- حدود Azure ABAC
- الأسئلة المتداولة حول شروط تعيين دور لـ Azure
- استكشاف أخطاء حدود Azure RBAC وإصلاحها
التدقيق والمراقبة
يتم تسجيل التغييرات على تعيينات الأدوار في سجلات نشاط Azure. تشير استعلامات المستخدم في LAQueryLogs الجدول إلى ما إذا كان قد تم تنفيذ الاستعلام بشرط وصول ABAC قابل للتطبيق في ConditionalDataAccess العمود. تمكين السجلات باستخدام إعدادات التشخيص في مساحة عمل Log Analytics. لمزيد من المعلومات، راجع إعدادات تشخيص سجلات Azure Monitor.
الأسئلة المتداولة
أقوم بالوصول إلى سجلاتي عبر سياق المورد. هل يمكن فرض شرطي؟
يتم فرض التحكم في الوصول استنادا إلى الدور و ABAC لاستعلامات سياق الموارد، ولكن تتطلب مساحات العمل التي تحتوي على سجلات الموارد للوفاء بهذه المتطلبات الأساسية:
- قم بتعيين وضع التحكم في الوصول لكافة مساحات العمل ذات الصلة إلى طلب أذونات مساحة العمل.
إذا تم تعيينه إلى استخدام الموارد أو أذونات مساحة العمل، فإن إذن قراءة Azure المعين لمورد يوفر الوصول إلى جميع السجلات. يتم تجاهل أذونات مساحة العمل و ABAC. - تعيين ABAC على جميع مساحات العمل ذات الصلة.
لمزيد من المعلومات، راجع إدارة الوصول إلى مساحات عمل Log Analytics، وضع الوصول.
هل تستمر شروط التحكم في الوصول استنادا إلى الدور (RBAC) الدقيقة عند تصدير جدول؟
يتم فرض شروط التحكم في الوصول استنادا إلى الدور متعدد المستويات فقط على الاستعلامات. على سبيل المثال، لا تحافظ البيانات التي تم تصديرها بنجاح باستخدام ميزة تصدير بيانات مساحة العمل على شروط ABAC على بيانات الجدول الهدف.
كيف يمكنك تكوين الوصول استنادا إلى تصنيف البيانات؟
لتنفيذ نموذج الوصول إلى نمط Bell-LaPadula، يجب عليك تعيين شروط ABAC بشكل صريح للتمسك بكيانات مثل القراءة. على سبيل المثال، يجب أن يكون لدى المستخدم الذي لديه أذونات سرية للغاية إذن معين بشكل صريح لمستويات أقل مثل السرية والسرية وغير المصنفة للتأكد من أنه يمكنه الوصول إلى البيانات على مستويات أقل من المستوى الأعلى المعين له.