Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Существует три способа управления доступом на уровне таблицы в рабочей области Log Analytics с помощью управления доступом на основе ролей (RBAC). Эта статья ссылается на все методы, хотя рекомендуется использовать только детализированный RBAC.
- Гранулярный RBAC (рекомендуется)
- RBAC на уровне таблицы (двойная роль)
- RBAC на уровне таблицы (устаревшая версия)
Гранулированный RBAC позволяет точно настроить доступ на уровне таблицы или строки. Пользователи с доступом на уровне таблицы могут считывать данные и запросы из указанных таблиц как в рабочей области, так и в контексте ресурса. Дополнительные сведения см. в разделе "Детализированный RBAC".
Настройка детализации RBAC для доступа на уровне таблицы
Конфигурация доступа на уровне таблицы с помощью детализированного RBAC менее сложна, чем предыдущие методы, и обеспечивает гибкость реализации условий на уровне строк. Эти шаги просто сосредоточены на настройке доступа на уровне таблицы. Дополнительные сведения см. в разделе "Детализированный RBAC".
Для настройки детализированного RBAC для доступа на уровне таблицы необходимо выполнить следующие действия.
- Выберите встроенную роль Log Analytics Data Reader, или создайте пользовательскую роль.
- Создайте условие для назначенной роли (разрешающая или ограничивающая)
Создание детализированной настраиваемой роли RBAC
Плоскость управления "data action" отличает более детализированный RBAC от более ранних методов настройки доступа на уровне таблицы и уже настроена в встроенной роли чтения данных Log Analytics. Если вы не выберете встроенную роль, выполните следующие действия, чтобы создать пользовательскую роль. Дополнительные сведения см. в разделе "Создание детализированного назначения роли RBAC".
Вот JSON-образец для настраиваемой роли.
{ "properties": {
"roleName": "Log Analytics Standard Table Access",
"description": "This custom role provides general access to all non-restricted tables.",
"assignableScopes": [
"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contoso-US-la-workspace"
],
"permissions": [
{
"actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read"
],
"notActions": [],
"dataActions": [
"Microsoft.OperationalInsights/workspaces/tables/data/read"
],
"notDataActions": []
}
]
}
}
Назначьте роль пользователю или группе. Дополнительные сведения см. в разделе "Назначение детализированных ролей RBAC".
- В рабочей области Log Analytics выберите элемент управления доступом (IAM).
- выберите Добавить назначение ролей.
- Выберите пример созданной пользовательской
Log Analytics Standard Table Accessроли, а затем нажмите кнопку "Далее". - Выберите пользователя или группу, которой нужно назначить роль, а затем нажмите кнопку "Далее". Роль назначается группе безопасности команды сети в этом примере.
- Выберите Условия>Добавить условие>Добавить действие.
- Выберите действие Чтение данных рабочей области>Выбрать.
Условие сборки с разрешением
В этом примере создается разрешительное условие с помощью стратегии Доступ ко всем данным, за исключением того, что не разрешено. Доступ ограничен к таблицам SigninLogs и SecurityEvent, но разрешен ко всем остальным таблицам. Пример ограничивающего условия см. в разделе "Детализированные варианты использования RBAC".
- В разделе «Построение выражения» выберите «Добавить выражение»
- Выберите ресурс из раскрывающегося списка "Источник атрибутов ".
- Выберите имя таблицы из раскрывающегося списка атрибутов .
- Выберите ForAnyOfAllValues:StringNotEquals из раскрывающегося списка Оператор.
- Введите
SigninLogsиSecurityEventв полях "Значение ".
Вот как выглядит разрешительное условие доступа на уровне таблицы, когда завершено.
При назначении одной роли доступ на уровне таблицы настраивается для разделения ограниченных таблиц из стандартных таблиц. Дополнительные сведения см. в аспектах гранулярного управления доступом (RBAC) и устранении неполадок при гранулярном управлении доступом (RBAC).
Настройка доступа на уровне таблицы (метод двойной роли)
Рекомендуется использовать детальный метод RBAC вместо этого метода. В этом разделе описаны действия по настройке метода двойной роли.
Этот метод управления доступом на уровне таблицы также использует пользовательские роли Azure для предоставления пользователям или группам доступа к определенным таблицам в рабочей области, но требует назначения двух ролей для каждого пользователя или группы.
| Область действия | Описание роли |
|---|---|
| Рабочая область | Пользовательская роль, которая предоставляет ограниченные разрешения для чтения сведений о рабочей области и выполнения запроса в рабочей области, но не для чтения данных из каких-либо таблиц |
| Таблица | Роль читателя , ограниченная определенной таблицей |
Создание роли рабочего пространства
Создайте пользовательскую роль на уровне рабочей области, чтобы пользователи считывали сведения о рабочей области и выполняли запрос в рабочей области, не предоставляя доступ на чтение к данным в любых таблицах:
- Перейдите в рабочую область и выберите Управление доступом (IAM)>Роли.
- Щелкните правой кнопкой мыши роль читателя и выберите Клонировать.
Откроется экран создания настраиваемой роли . - На вкладке "Основы" экрана:
- Выберите вкладку >Edit:
- В разделе
"actions"добавьте следующие действия:"Microsoft.OperationalInsights/workspaces/read", "Microsoft.OperationalInsights/workspaces/query/read" - В разделе
"not actions"добавьте:"Microsoft.OperationalInsights/workspaces/sharedKeys/read"
- В разделе
- Нажмите "Сохранить">Проверка + Создание>Создать.
- Выберите управление доступом (AIM)>Добавить>Добавить назначение ролей.
- Выберите созданную пользовательскую роль и нажмите кнопку "Далее". Откроется вкладка "Члены" на экране "Добавление настраиваемой роли".
- + Выберите участников , чтобы открыть экран "Выбрать участников ".
- Найдите пользователя >Select.
- Выберите Обзор и назначение.
Теперь пользователь может считывать сведения о рабочей области и выполнять запрос, но не может считывать данные из каких-либо таблиц.
Назначение роли доступа к таблице
- В меню рабочих областей Log Analytics выберите "Таблицы".
- Выберите многоточие (... ) справа от таблицы и выберите элемент управления доступом (IAM).
- На экране Управление доступом (IAM) выберите Добавить>, затем Добавить назначение роли.
- Выберите роль читателя и нажмите кнопку "Далее".
- + Выберите участников , чтобы открыть экран "Выбрать участников ".
-
- Найдите пользователя >Select.
- Выберите Обзор и назначение.
Теперь пользователь может считывать данные из этой конкретной таблицы. При необходимости предоставьте пользователю доступ на чтение к другим таблицам в рабочей области.
Настройка доступа на уровне таблицы (устаревший метод)
Устаревший метод управления доступом на уровне таблицы больше не рекомендуется. Он не поддерживает условия уровня строк и более сложный, чем детальный метод RBAC. Рекомендуется использовать детальный метод RBAC вместо этого метода. В этом разделе описаны шаги по настройке устаревшего метода.
Устаревший метод табличного уровня также использует пользовательские роли Azure , чтобы предоставить пользователям или группам доступ к определенным таблицам в рабочей области. Пользовательские роли Azure применяются к рабочим областям с режимом управления доступом в контексте рабочей области или контексте ресурсов независимо от режима доступа пользователя.
Чтобы определить доступ к определенной таблице, создайте пользовательскую роль:
- Задайте разрешения пользователя в разделе "Действия " определения роли.
- Используйте
Microsoft.OperationalInsights/workspaces/query/*для предоставления доступа ко всем таблицам. - Чтобы исключить доступ к определенным таблицам при использовании подстановочного знака в actions, перечислите таблицы, исключенные из раздела NotActions определения роли.
Ниже приведены примеры действий настраиваемых ролей для предоставления и отзыва доступа к конкретным таблицам.
Предоставление доступа к таблицам Heartbeat и AzureActivity:
"Actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read",
"Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
"Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"
],
Предоставление доступа только к таблице SecurityBaseline:
"Actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read",
"Microsoft.OperationalInsights/workspaces/query/SecurityBaseline/read"
],
Предоставление доступа ко всем таблицам, за исключением SecurityAlert:
"Actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read",
"Microsoft.OperationalInsights/workspaces/query/*/read"
],
"notActions": [
"Microsoft.OperationalInsights/workspaces/query/SecurityAlert/read"
],
Ограничения устаревшего метода, связанного с пользовательскими таблицами
Пользовательские таблицы хранят данные, собранные из источников данных, таких как текстовые журналы и API сборщика данных HTTP. Чтобы определить тип таблицы, просмотрите сведения о таблице в Log Analytics.
Используя устаревший метод доступа на уровне таблицы, вы не можете предоставить доступ к отдельным пользовательским таблицам журналов на уровне таблицы, но вы можете предоставить доступ ко всем настраиваемым таблицам журналов. Чтобы создать роль с доступом ко всем таблицам пользовательских журналов, создайте настраиваемую роль с помощью следующего действия:
"Actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read",
"Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read"
],
Соображения
- В пользовательском интерфейсе Log Analytics пользователи с табличным уровнем могут просматривать список всех таблиц в рабочей области, но могут получать только данные из таблиц, к которым у них есть доступ.
- Стандартные роли Читателя или Участника, которые включают действие */read, переопределяют управление доступом на уровне таблицы и предоставляют пользователям доступ ко всем данным журналов.
- Пользователь с доступом на уровне таблицы, но без разрешений на уровне рабочей области может получать данные журнала из API, но не из портала Azure.
- Администраторы и владельцы подписки имеют доступ ко всем типам данных независимо от других параметров разрешений.
- Владельцы рабочих областей рассматриваются как и другие пользователи для управления доступом на уровне каждой таблицы.
- Назначайте роли группам безопасности, а не отдельным пользователям, чтобы сократить количество назначений. Эта рекомендация помогает использовать существующие средства управления группами для настройки и проверки доступа.