Настройка защищенных таблиц в журналах Azure Monitor (предварительная версия)

В этой статье показано, как задать уровень защиты таблицы, предоставить доступ авторизованным пользователям и убедиться, что конфигурация работает должным образом. Защищённые таблицы используют модель «запрет по умолчанию», при которой непривилегированные стандартные и пользовательские роли с правами чтения не могут получать доступ к конфиденциальным данным, пока вы явно не предоставите разрешение с помощью условий ABAC.

Prerequisites

Требование	Сведения
подписка Azure	Активная подписка Azure с рабочей областью Log Analytics.
Разрешения	Роль владельца или участника Log Analytics в рабочей области. Вам потребуется `Microsoft.OperationalInsights/workspaces/tables/protectionLevel/write` действие для изменения уровня защиты таблицы.
Знакомство с RBAC и ABAC	Понимание условий Azure RBAC и ABAC. Общие сведения об ABAC в Log Analytics см. в статье «Детализированное управление доступом на основе ролей в Azure Monitor».

Настройка уровня защиты таблицы

Установка для таблицы уровня защиты Protected немедленно запрещает непривилегированным стандартным ролям чтения и пользовательским ролям доступ к данным в этой таблице. Выполните эти действия для каждой таблицы, содержащей конфиденциальные данные телеметрии.

На портале Azure перейдите к рабочим областям Log Analytics и выберите рабочую область.
В разделе "Параметры" выберите "Таблицы".
Найдите таблицу, которую вы хотите защитить, и выберите меню с многоточием (...).
Нажмите Управление таблицей.
В разделе "Уровень защиты" выберите "Защищенный".
Нажмите Сохранить.

Снимок экрана: портал Azure, на котором показана панель

Используйте следующую команду, чтобы задать уровень Protected защиты таблицы с помощью интерфейса командной строки.

# User input
subscriptionId="aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
resourceGroupName="myResourceGroupName"
workspaceName="myWorkspaceName"
tableName="myTableName"

# Build request URL
apiEndpoint="https://management.azure.com"
path="/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName"
provider="Microsoft.OperationalInsights/workspaces/$workspaceName/tables/$tableName"
url="$apiEndpoint$path/providers/$provider?api-version=2025-02-01"

az rest --method patch --url "$url" \
  --body '{"properties": {"protectionLevel": "Protected"}}'

Чтобы обновить уровень защиты таблицы, используйте этот PATCH запрос для операции обновления таблиц. Используйте ту версию apiVersion, которая описана там последней.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}?api-version={apiVersion}
Authorization: Bearer {accessToken}
Content-Type: application/json

{
  "properties": {
    "protectionLevel": "Protected"
  }
}

Успешный ответ возвращает определение таблицы, где для protectionLevel задано значение Protected:

{
  "properties": {
    "protectionLevel": "Protected",
    "schema": { ... },
    "retentionInDays": 30
  }
}

Предоставление доступа к защищенным таблицам

После защиты таблицы необходимо явно предоставить доступ пользователям, которым нужны данные. Используйте встроенную роль Privileged Monitoring Data Reader для широкого доступа или создайте пользовательские роли с условиями protectionLevel ABAC для более избирательного доступа.

Назначьте роль читателя данных привилегированного мониторинга

Встроенная роль Читатель данных привилегированного мониторинга предоставляет доступ на чтение ко всем защищенным таблицам в назначенной области.

Портал Azure не поддерживает добавление условий ABAC в встроенные роли. Это ограничение является защитой пользовательского интерфейса, чтобы предотвратить ошибки пользователей. Чтобы добавить настраиваемые условия в эту роль, используйте шаблоны ARM, REST API или другие программные методы.

Портал Azure
Azure CLI;

На портале Azure перейдите в область, в которой вы хотите назначить роль (подписку, группу ресурсов, рабочую область или любой поддерживаемый ресурс Azure).
Выберите элемент управления доступом (IAM)>Добавить>Добавить назначение роли.
На вкладке Role найдите и выберите Privileged Monitoring Data Reader.
На вкладке Участники выберите пользователя, группу или управляемую идентификацию.
Выберите кнопку Проверить + назначить.

Используйте следующую команду, чтобы назначить роль "Privileged Monitoring Data Reader" с помощью CLI.

# User input
subscriptionId="aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
resourceGroupName="myResourceGroupName"
workspaceName="myWorkspaceName"
assigneeObjectId="myAssigneeObjectId"

scope="/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName"
scope+="/providers/Microsoft.OperationalInsights/workspaces/$workspaceName"

az role assignment create \
  --assignee "$assigneeObjectId" \
  --role "Privileged Monitoring Data Reader" \
  --scope "$scope"

Предоставление доступа только к определенным защищенным таблицам

Если вам нужно ограничить доступ к отдельным защищенным таблицам, а не всем из них, создайте настраиваемое назначение ролей с условиями ABAC, которые фильтруют как по имени таблицы, так и на уровне защиты.

Создайте или выберите пользовательскую роль на основе метода доступа , который требуется использовать.
- Требуется DataActions для доступа, ориентированного на рабочую область: Microsoft.OperationalInsights/workspaces/tables/data/read
- Обязательный DataActions для доступа, ориентированного на ресурсы: Microsoft.Insights/logs/data/read

При создании назначения роли добавьте условие с двумя выражениями, соединёнными оператором AND:

Expression	Атрибут	Operator	Ценность
1	`Microsoft.OperationalInsights/workspaces/tables:name`	`StringEquals`	Имя конкретной таблицы (например, `AppTraces`)
2	`Microsoft.OperationalInsights/workspaces/tables:protectionLevel`	`StringEquals`	`Protected`

Условие в формате ABAC выглядит следующим образом:

(
  (
    !(ActionMatches{'Microsoft.OperationalInsights/workspaces/tables/data/read'})
  )
  OR
  (
    @Resource[Microsoft.OperationalInsights/workspaces/tables:name] StringEquals 'AppTraces'
    AND
    @Resource[Microsoft.OperationalInsights/workspaces/tables:protectionLevel] StringEquals 'Protected'
  )
)

При необходимости измените имя таблицы и оператор. Для доступа к нескольким таблицам используйте ForAllOfAnyValues:StringEquals список имен таблиц. Дополнительные сведения о синтаксисе выражений см. в разделе "Детализированное управление доступом на основе ролей (RBAC)" в Azure Monitor.

Предоставление доступа с привязкой к времени с помощью PIM

Используйте Microsoft Entra управление привилегированными пользователями (PIM), чтобы предоставить оперативный доступ к защищенным таблицам на ограниченное время.

В PIM создайте подходящее назначение для роли "Читатель привилегированных данных мониторинга" (или настраиваемую роль) в нужной области.
Задайте максимальную длительность активации в соответствии с политикой вашей организации.
Когда пользователям требуется доступ, они активируют роль в PIM. Доступ автоматически отменяется при истечении срока действия окна активации.

Этот шаблон хорошо подходит для реагирования на инциденты и сценариев поддержки, в которых инженеры нуждаются в временном доступе к конфиденциальным журналам.

Включение режима DataActionsOnly

По умолчанию некоторые роли, основанные на действиях плоскости управления, например Reader и Monitoring Reader, неявно предоставляют доступ для чтения данных журналов. DataActionsOnly режим удаляет этот путь доступа, чтобы управлять доступом только DataActions к данным.

На портале Azure перейдите к рабочим областям Log Analytics и выберите рабочую область.
В разделе Параметры выберите Свойства.
В режиме авторизации данных выберите только действия с данными.

Используйте следующую команду, чтобы включить DataActionsOnly режим с помощью интерфейса командной строки.

# User input
subscriptionId="aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
resourceGroupName="myResourceGroupName"
workspaceName="myWorkspaceName"

# Build request URL
apiEndpoint="https://management.azure.com"
path="/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName"
provider="Microsoft.OperationalInsights/workspaces/$workspaceName"
url="$apiEndpoint$path/providers/$provider?api-version=2025-02-01"

az rest --method patch --url "$url" \
  --body '{"properties": {"features": {"dataAuthorizationMode": "DataActionsOnly"}}}'

Чтобы включить DataActionsOnly режим, используйте этот PATCH запрос для операции обновления рабочих областей . Используйте ту версию apiVersion, которая описана там последней.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}?api-version={apiVersion}
Authorization: Bearer {accessToken}
Content-Type: application/json

{
  "properties": {
    "features": {
      "dataAuthorizationMode": "DataActionsOnly"
    }
  }
}

После включения режима DataActionsOnly убедитесь, что пользователи, которые ранее полагались на роли плоскости управления для доступа к журналам, теперь получили соответствующие назначения ролей на основе DataActions.

Проверка конфигурации

Выполните эти проверки, чтобы убедиться, что защита и предоставление доступа работают правильно.

Убедитесь, что не привилегированные пользователи не видят данных

Войдите как пользователь с ролью читателя Log Analytics, но не имеет роли "Читатель привилегированных данных мониторинга" или настраиваемую роль с условиемprotectionLevel.
Откройте рабочую область на портале Azure и перейдите в Logs.
Запустите запрос к защищенной таблице.
```
ProtectedTableName
| take 10
```
Убедитесь, что запрос выполнен успешно, но возвращает нулевые строки.

Убедитесь, что привилегированные пользователи видят данные

Войдите в систему под учетной записью пользователя, которому назначена роль "Privileged Monitoring Data Reader" или соответствующая настраиваемая роль с условиями ABAC.
Выполните тот же запрос.
Убедитесь, что запрос возвращает строки данных.

Проверьте журнал действий на наличие изменений конфигурации

Откройте журнал действий для рабочей области и отфильтруйте его по имени операции Update Table. Найдите записи, отображающие изменения в свойстве protectionLevel . Эти записи подтверждают, когда и кем были защищены таблицы.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-06-23