Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Детальный контроль доступа на основе ролей (RBAC) в Azure Monitor Log Analytics позволяет фильтровать данные рабочей области, которые каждый пользователь может просматривать или запрашивать в зависимости от условий, указанных в соответствии с потребностями бизнеса и безопасности. К преимуществам этого контроля доступа относятся следующие преимущества:
- Доступ на уровне строк
- Доступ на уровне таблицы
- Разделение уровней управления и данных
Если архитектура лог аналитикс включает несколько рабочих областей для обеспечения разделения данных, конфиденциальности или соответствия требованиям, детализированное управление доступом с помощью RBAC помогает упростить, уменьшив количество рабочих областей, необходимых для обеспечения этих функций.
Вводное видео
Предпосылки
| Действие | Требования к разрешениям |
|---|---|
| Создание настраиваемой роли |
Microsoft.Authorization/roleDefinitions/write разрешение на назначаемые области.
Например, как указано в привилегированной встроенной роли, Администраторы доступа пользователей. |
| Добавление или обновление условий |
Microsoft.Authorization/roleAssignments/write и Microsoft.Authorization/roleAssignments/delete разрешения для доступа к рабочей области Log Analytics.
Например, в соответствии с привилегированной встроенной ролью, Администратор управления доступом, основанного на ролях. |
Когда следует использовать детализированный RBAC?
Гранулированный RBAC помогает реализовать следующие сценарии:
- Разделение данных— отделяйте данные разных единиц, команд и географических расположений в одной рабочей области и убедитесь, что каждый пользователь может получать доступ только к данным, соответствующим их группе. Условия доступа используют настраиваемые поля журнала для принудительного разделения доступа на уровне строк по атрибутам, таким как брандмауэр, тип устройства, идентификатор подписки или другие идентификаторы.
- Конфиденциальность данных — защита сенситивных или конфиденциальных данных, таких как личная информация, медицинские записи или финансовые транзакции, с разрешением доступа только авторизованным пользователям.
- Соответствие данным . Используйте детализированный RBAC в качестве инструмента, чтобы помочь вам соответствовать нормативным или юридическим требованиям отрасли или региона. Применение соответствующих политик и элементов управления доступом к данным и их использованием.
Гранулярный RBAC контролирует доступ к данным, включая возможность просмотра или выполнения запросов к данным. Он не обращается к действиям уровня управления, таким как настройка разрешений для доступа к данным, управления рабочими областями, преобразований или экспорта данных.
Настройка детализированного RBAC
Погрузитесь в детализированное RBAC с пошаговым примером детализированного RBAC.
В следующих разделах представлен обзор ключевых понятий и шагов, связанных с настройкой детализированного RBAC.
Создание роли
Чтобы настроить детализированный RBAC, необходимо создать пользовательскую роль с обязательными действиями , а затем назначить настраиваемую роль с условиями. Дополнительные сведения о настраиваемых ролях см. в статье Настраиваемые роли Azure.
Минимальные необходимые разрешения для действия пользовательской роли и действий с данными:
| Определение пользовательской роли | Разрешение | Описание |
|---|---|---|
| Действия уровня управления (Действия) | Microsoft.OperationalInsights/workspaces/query/read |
Запустите запросы в Log Analytics и просмотрите метаданные. Это разрешение не предоставляет доступ к данным. |
| Действия плоскости данных (DataActions) | Microsoft.OperationalInsights/workspaces/tables/data/read |
Доступ к данным и выбран dataaction в условии назначения ролей. Если условие не задано, это разрешение предоставляет доступ ко всем данным в назначенной области. |
При необходимости включите доступ с портала Azure, добавив Microsoft.OperationalInsights/workspaces/read действие управления. Дополнительные сведения см. в разделе "Управление azure RBAC" и действия с данными.
Замечание
Гранулированная модель RBAC, например Azure RBAC, является аддитивной моделью. Ваши эффективные разрешения — это результат ваших назначений ролей. Чтобы детализированные условия RBAC вступают в силу, необходимо удалить все назначения ролей с более высокими привилегиями доступа.
Например, если у вас есть два назначения ролей в одной области, один набор с */read действием и другими условиями, ограничивающими доступ к определенным записям, результирующее разрешение — это */read действие, предоставляющее доступ ко всем журналам в области. Нет явного действия запрета, только запретить назначения.
Условия и выражения
Как и обычные назначения ролей, пользовательская роль, которую вы создали, должна быть назначена пользователю или группе. Разница заключается в том, что во время назначения роли условия настраиваются для точной настройки управления доступом.
Гранулярный RBAC позволяет задать условия для таблиц и строк на основе данных в каждой записи. Ограничения плана на основе этих двух стратегий:
| Метод управления доступом | Пример |
|---|---|
| Нет доступа к данным, кроме разрешенного | Ограничьте доступ к журналам приложений, чтобы пользователи могли видеть только записи, в которых application id столбец является приложением, к которому они могут получить доступ. |
| Доступ ко всем данным, кроме запрещенных | Разрешить доступ ко всем журналам входа, за исключением записей, где в столбце userPrincipalName указан генеральный директор. |
Условие состоит из действия с данными роли и выражений. Выражение — это логическое утверждение формата AttributeOperatorValue.
Значения ограничены поддержкой следующих символов:
- Буквенно-цифровые символы
- Специальные символы:
@,.,-
Подробный RBAC Log Analytics поддерживает атрибуты таблицы и столбца/значения:
| Источник атрибута | Отображаемое имя | Тип | Описание | Имя атрибута |
|---|---|---|---|---|
| Ресурс | Имя таблицы | Струна | Имена таблиц, используемые для предоставления или ограничения доступа. | Microsoft.OperationalInsights/workspaces/tables:'<name>' |
| Ресурс | Значение столбца (ключ — имя столбца) | Словарь (ключ-значение) | Имя и значение столбца. Имя столбца — это ключ. Значение данных в столбце — это значение. | Microsoft.OperationalInsights/workspaces/tables/record:<key> |
Ниже приведен пример снимка экрана с подробным условием назначения ролей RBAC с использованием метода "Нет доступа к данным", за исключением разрешенного метода,настроенного на портале Azure.
Уменьшите сложность, настроив детализированные назначения ролей RBAC в области, соответствующей установленным вами условиям. Например, если пользовательская роль назначена в области группы ресурсов, возможно, в других рабочих областях отсутствуют указанные в выражении ресурсы таблиц или столбцов, что может привести к неожиданному применению вашего условия.
Однако если задать условие назначения роли на уровне таблицы, необходимо создать две роли следующим образом:
- Роль 1. Действие:
Microsoft.OperationalInsights/workspaces/query/readдля рабочей области таблицы. - Роль 2: DataAction:
Microsoft.OperationalInsights/workspaces/tables/data/readдля таблицы в этой рабочей области. Определите условие роли с помощью действия данных.
Чтобы избежать создания двух ролей, используйте самый простой подход, назначив роль в рабочей области и установив условия для управления уровнем таблицы.
Дополнительные сведения см. в разделе уровни областей Azure RBAC.
Операторы выражений
Гранулярные выражения RBAC используют подмножество операторов управления доступом на основе атрибутов (ABAC).
Атрибут имени таблицы поддерживает четыре оператора. Эти операторы позволяют гибко сопоставлять имена таблиц с их значениями при установлении условия.
| Операторы ABAC | Описание |
|---|---|
StringEquals |
Сопоставление с учетом регистра. Значения должны точно совпадать со строкой. |
StringNotEquals |
Отрицание StringEquals. |
ForAllOfAnyValues:StringEquals |
Логически эквивалентен in(). Если каждое значение слева удовлетворяет сравнению по крайней мере с одним значением справа, выражение принимает значение true. |
ForAllOfAllValues:StringNotEquals |
Логически эквивалентен !in(). Если каждое значение на левой стороне удовлетворяет сравнению с по крайней мере одним значением справа, то выражение оценивается как false. |
Условия 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> поддерживает несколько строк и чисел.
Если каждое значение в левой части соответствует по крайней мере одному значению справа, то выражение оценивается как true. |
Условия ABAC не задаются непосредственно для функций. Если задать условие для таблицы, она будет распространяться до любой функции, которая зависит от нее. Дополнительные сведения об операторах и терминах см. в разделе "Строковые операторы".
Подсказка
Используйте преобразования для обогащения данных, изменения типов данных и изменения регистра, чтобы лучше адаптировать ваши выражения ABAC. Если данные не поддерживают условия, которые вы хотите применить, преобразования также являются решением. Например, чтобы применить условия к данным с высокой кардинальностью, например, диапазоны IP-адресов, используйте преобразования для группировки IP-адресов, принадлежащих выбранным подсетям по именам подсетей.
Дополнительные сведения см. в разделе "Преобразования сбора данных" в Azure Monitor.
Соображения
Некоторые рекомендации применяются при использовании детализированного RBAC в Log Analytics. В следующих разделах приведены особенности.
- Детализированный RBAC доступен только в общедоступном облаке.
Azure Monitor
- Задания поиска и правила сводки планируются для детальной поддержки RBAC, но не экспорта данных. Для всех этих сценариев, если отсутствует полный доступ к запрашиваемым таблицам, пользователь не может настроить задание поиска или правило и получает сообщение об ошибке.
- Оповещения: поддерживаются только оповещения журнала, основанные на управляемых идентичностях.
- Application Insights: поддерживаются только Application Insights, основанные на рабочей области.
Microsoft Sentinel
Когда данные реплицируются из исходных таблиц с помощью поиска, закладок, аналитических правил и инцидентов, реплицированные данные не находятся под защитой условий ABAC.
Azure ABAC и RBAC
Применяются обычные ограничения Azure RBAC и ABAC. Например, пороговое значение максимальных назначений ролей для каждой подписки является ограничением службы Azure для RBAC. Azure ABAC ограничивает количество выражений на условие и общий размер условия в КБ. Дополнительные сведения см. в следующих статьях:
- Ограничения Azure RBAC
- Ограничения Azure ABAC
- Вопросы и ответы об условиях назначения ролей Azure
- Решение проблем с ограничениями Azure RBAC
Аудит и мониторинг
Изменения назначений ролей регистрируются в журналах действий Azure. Запросы пользователей в LAQueryLogs таблице указывают, был ли выполнен запрос с соответствующим условием доступа ABAC в столбцеConditionalDataAccess. Включите журналы с помощью параметров диагностики в рабочей области Log Analytics. Для получения дополнительной информации смотрите в разделе "Параметры диагностики журналов Azure Monitor".
Часто задаваемые вопросы
Доступ к журналам осуществляется через контекст ресурса. Можно ли применить мое условие?
RBAC и ABAC применяются для запросов, проводимых в контексте ресурсов, но требуют, чтобы рабочие области, содержащие журналы ресурсов, соответствовали этим предварительным требованиям:
- Задайте для всех соответствующих рабочих областей режим управления доступом значение "Требовать разрешения рабочей области".
Если задано значение "Использовать ресурсы или разрешения рабочей области", разрешение на чтение Azure, назначенное ресурсу, предоставляет доступ ко всем журналам. Разрешения рабочего пространства и ABAC игнорируются. - Установите ABAC для всех соответствующих рабочих пространств.
Дополнительные сведения см. в статье "Управление доступом к рабочим областям Log Analytics", режиму доступа.
Сохраняются ли детализированные условия RBAC при экспорте таблицы?
Детализированные условия RBAC применяются только к запросам. Например, данные, успешно экспортированные с помощью функции экспорта данных рабочей области, не сохраняют условия ABAC для данных в целевой таблице.
Как настроить доступ на основе классификации данных?
Чтобы реализовать модель доступа в стиле Bell-LaPadula, необходимо явно задать условия ABAC, чтобы придерживаться принципов, таких как чтение на более низкий уровень. Например, пользователь с разрешениями верхнего секрета должен иметь явное разрешение для более низких уровней, таких как секрет, конфиденциальный и неклассифицированный, чтобы обеспечить доступ к данным на уровнях ниже, чем их верхний назначенный уровень.