Поделиться через

Ключ Azure Monitor, управляемый клиентом

  • Статья

Данные в Azure Monitor шифруются с помощью ключей, управляемых Майкрософт. Вы можете использовать собственный ключ шифрования для защиты данных и сохранения запросов в рабочих областях. Управляемые клиентом ключи в Azure Monitor обеспечивают большую гибкость управления доступом к журналам. После настройки новые данные, передаваемые в связанные рабочие области, шифруются с помощью ключа, хранящегося в Azure Key Vault, или управляемого azure Key Vault HSM.

Просмотрите ограничения и ограничения перед настройкой .

Общие сведения о ключе, управляемом клиентом

Шифрование неактивных данных является стандартным требованием к конфиденциальности и безопасности в организациях. Вы можете полностью управлять шифрованием Azure или использовать различные варианты для тесного управления ключами шифрования и шифрования.

Azure Monitor обеспечивает шифрование всех неактивных данных и сохраненных запросов с помощью управляемых Майкрософт ключей (MMK). Использование шифрования Azure Monitor идентично тому, как работает шифрование служба хранилища Azure.

Чтобы управлять жизненным циклом ключей и иметь возможность отзыва доступа к данным, вы можете шифровать данные с помощью Azure Key Vault.

Управляемые клиентом ключи доступны в выделенных кластерах и обеспечивают более высокий уровень защиты и управления. Данные шифруются в хранилище дважды — на уровне обслуживания с помощью ключей, управляемых корпорацией Майкрософт, или ключей, управляемых клиентом, и на уровне инфраструктуры с использованием двух различных алгоритмов шифрования и двух разных ключей. Двойное шифрование защищает от сценария, в котором может быть скомпрометирован один из алгоритмов шифрования или ключей. Выделенные кластеры также позволяют защитить данные с помощью блокировки.

Данные, используемые за последние 14 дней или недавно используемые в запросах, хранятся в горячем кэше (SSD-сервере) для повышения эффективности запросов. Данные SSD шифруются с помощью ключей Майкрософт независимо от того, настроены ли ключи, управляемые клиентом, но ваш контроль доступа к SSD соответствует отзыву ключей.

Внимание

Выделенные кластеры используют модель ценообразования на уровне обязательств не менее 100 ГБ в день.

Как работают управляемые клиентом ключи в Azure Monitor

Azure Monitor использует управляемое удостоверение для предоставления доступа к Azure Key Vault. Удостоверение кластера Log Analytics поддерживается на уровне кластера. Чтобы разрешить управляемые клиентом ключи в нескольких рабочих областях, ресурс кластера Log Analytics служит промежуточным подключением удостоверения между Key Vault и рабочими областями Log Analytics. Хранилище кластера использует управляемое удостоверение, связанное с кластером, для проверки подлинности в Azure Key Vault с помощью идентификатора Microsoft Entra.

Кластеры поддерживают два типа управляемых удостоверений: назначаемые системой и назначаемые пользователем. В зависимости от сценария в кластере можно определить одно удостоверение.

  • Управляемое удостоверение, назначаемое системой, проще и создается автоматически с кластером, если identity type задано значение SystemAssigned. Это удостоверение используется позже, чтобы предоставить хранилищу доступ к Key Vault для шифрования и расшифровки данных.
  • Управляемое удостоверение, назначаемое пользователем, позволяет настроить ключи, управляемые клиентом, identity type UserAssignedпри создании кластера и предоставить ему разрешения в Key Vault перед созданием кластера.

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

Внимание

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

Снимок экрана: обзор ключа, управляемого клиентом.

  1. Key Vault
  2. Ресурс кластера Log Analytics с управляемым удостоверением с разрешениями на Key Vault — удостоверение распространяется на хранилище выделенного кластера на основе наложения.
  3. Выделенный кластер
  4. Рабочие области, связанные с выделенным кластером

Операция с ключами шифрования

Существует три типа ключей, участвующих в шифровании данных службы хранилища:

  • KEK — ключ шифрования ключей (ключ, управляемый клиентом)
  • AEK — ключ шифрования учетной записи
  • DEK — ключ шифрования данных

Применяются следующие правила:

  • Хранилище кластера имеет уникальный ключ шифрования для каждой учетной записи хранения — АЕК.
  • АЕК используется для получения DEK — ключей, используемых для шифрования каждого блока данных, записываемых на диск.
  • При настройке ключа в Key Vault и обновлении сведений о ключе в кластере хранилище кластера выполняет запросы на упаковку и распаковку АЕК для шифрования и расшифровки.
  • KEK никогда не покидает Хранилище ключей и, если вы используете управляемый модуль HSM, он никогда не покидает оборудование.
  • служба хранилища Azure использует управляемое удостоверение, связанное сРесурс кластера для проверки подлинности. Он обращается к Azure Key Vault с помощью идентификатора Microsoft Entra.

Действия по подготовке ключа, управляемого клиентом

  1. Создание Azure Key Vault и ключа хранилища.
  2. Создание кластера
  3. Предоставление разрешений для вашего Key Vault.
  4. Указание в кластере сведений об идентификаторе ключа
  5. Связывание рабочих областей

Конфигурация ключа, управляемого клиентом, сейчас не поддерживается на портале Azure. Подготовку можно выполнить с помощью PowerShell, CLI или REST.

Хранение ключа шифрования (KEK)

В портфеле продуктов Azure для управления ключами указаны хранилища и управляемые устройства HSM, которые вы можете использовать.

Создайте или используйте существующий Azure Key Vault в регионе, который планируется в кластере. В хранилище ключей создайте или импортируйте ключ для шифрования журналов. Для Azure Key Vault нужно настроить возможность восстановления, чтобы обезопасить ключи и доступ к данным в Azure Monitor. Вы можете проверить эту конфигурацию в свойствах вашего Key Vault. Следует включить пункты Обратимое удаление и Защита от очистки.

Снимок экрана: параметры обратимого удаления и очистки.

Эти параметры можно обновить в Key Vault с помощью интерфейса командной строки и PowerShell.

Создание кластера

Кластеры используют управляемое удостоверение для шифрования данных в Key Vault. Настройте identity type свойство или SystemAssigned UserAssigned при создании кластера, чтобы разрешить доступ к Key Vault для операций шифрования данных и расшифровки.

Параметры удостоверений в кластере для управляемого удостоверения, назначаемого системой

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Примечание.

Тип удостоверения можно изменить после создания кластера без прерывания приема или запросов со следующими рекомендациями.

  • Обновление SystemAssigned до UserAssigned— предоставление удостоверения UserAssign в Key Vault, а затем обновление identity type в кластере
  • Обновление UserAssigned до SystemAssigned— так как управляемое удостоверение, назначаемое системой после обновления кластера identity type SystemAssigned, необходимо выполнить следующие действия.
    1. Обновите кластер и удалите ключ— набор keyVaultUriи keyNamekeyVersion значение ""
    2. Обновление кластера identity type до SystemAssigned
    3. Обновление Key Vault и предоставление разрешений для удостоверения
    4. Обновление ключа в кластере

Выполните процедуру, показанную в статье "Выделенные кластеры".

Предоставление разрешений Key Vault

В Key Vault есть две модели разрешений для предоставления доступа к кластеру и хранилищу на основе подложек — управление доступом на основе ролей Azure (Azure RBAC) и политики доступа к Хранилищу (устаревшая версия).

  1. Назначьте элемент управления Azure RBAC (рекомендуется)

    Чтобы добавить назначения ролей, необходимо иметь роль с Microsoft.Authorization/roleAssignments/write Microsoft.Authorization/roleAssignments/delete разрешениями, такими как администратор доступа пользователей или владелец.

    1. Откройте Key Vault в портал Azure и выберите параметры>конфигурации>доступа Azure на основе ролей и применить
    2. Нажмите кнопку " Перейти к управлению доступом(IAM) и добавьте назначение роли пользователя шифрования шифрования службы шифрования key Vault.
    3. Выберите управляемое удостоверение на вкладке "Члены" и выберите подписку для удостоверения и удостоверения в качестве члена

    Снимок экрана: предоставление разрешений RBAC key Vault.

  2. Назначение политики доступа к хранилищу (устаревшая версия)

    Откройте Key Vault в портал Azure и выберите ">Политика доступа к>хранилищу доступа" и "Добавить политику доступа", чтобы создать политику с этими параметрами:

    • Разрешения ключей: установите флажки Получение, Упаковка ключа и Распаковка ключа.
    • Выберите субъект в зависимости от типа удостоверения, используемого в кластере (назначаемое системой или пользователем управляемое удостоверение)
      • Управляемое удостоверение, назначенное системой: введите имя кластера или идентификатор субъекта кластера
      • Управляемое удостоверение, назначенное пользователем: введите имя удостоверения

    Снимок экрана: предоставление разрешений политики доступа Key Vault.

    Разрешение Получение необходимо, чтобы убедиться, что Key Vault настроено как восстанавливаемое для защиты ключа и доступа к данным Azure Monitor.

Указание в кластере новых сведений об идентификаторе ключа

Для всех операций в кластере требуется разрешение на действие Microsoft.OperationalInsights/clusters/write. Это разрешение можно предоставить с помощью владельца или участника, который может выполнять действие */write, или с помощью роли участника Log Analytics, которая может выполнять действие Microsoft.OperationalInsights/*.

На этом шаге в выделенном хранилище кластера обновляется ключ и версия, используемые для переноса и распаковки АЕК.

Внимание

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

Снимок экрана: предоставление разрешений Key Vault.

Обновите KeyVaultProperties в кластере, указав сведения об идентификаторе ключа.

Эта операция выполняется асинхронно и может потребовать много времени.

Н/П

Внимание

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

Для выполнения этой операции необходимо иметь разрешения на запись как для рабочей области, так и для кластера. Он включает элементы Microsoft.OperationalInsights/workspaces/write и Microsoft.OperationalInsights/clusters/write.

Выполните процедуру, показанную в статье "Выделенные кластеры".

Отзыв ключа

Внимание

  • Рекомендуемый способ отмены доступа к данным — отключение ключа или удаление политики доступа в Key Vault.
  • При настройке для параметра identity type кластера значения None также отменяется доступ к данным, но этот подход не рекомендуется, так как его нельзя отменить без обращения в службу поддержки.

Хранилище кластера всегда учитывает изменения в разрешениях ключа в течение часа или раньше, а хранилище становится недоступным. Новые данные, используемые для связанных рабочих областей, удаляются и не удаляются. Данные недоступны в этих рабочих областях, и запросы завершаются ошибкой. Ранее полученные данные остаются в хранилище, пока вы не удалите кластер и рабочие области. Недоступные данные управляются политикой хранения данных и очищаются при достижении срока хранения. Данные, полученные за последние 14 дней или недавно использовавшиеся в запросах, хранятся в оперативном кэше (с поддержкой SSD) для повышения эффективности запросов. Данные на диске SSD удаляются при выполнении операции отзыва ключа и становятся недоступными. Хранилище кластера пытается периодически подключиться к Key Vault и распаковывать его, а после включения ключа отменять загрузку данных SSD из хранилища, а прием данных и запрос возобновляется в течение 30 минут.

Смена ключей

Смена ключей имеет два режима.

  • Автоматическое обновление "keyVaultProperties" свойств в кластере и опущении "keyVersion" или присвоение ""ему значения. Хранилище автоматически использует последнюю версию ключа.
  • Явное обновление версии ключа— обновление "keyVaultProperties" свойств и обновление версии ключа в "keyVersion" свойстве. Для смены ключей "keyVersion" требуется явное обновление свойства в кластере. Дополнительные сведения см. в разделе "Обновление кластера с сведениями об идентификаторе ключа". Если вы создаете новую версию ключа в Key Vault, но не обновляете ключ в кластере, хранилище кластера продолжает использовать предыдущий ключ. Если вы отключите или удалите старый ключ перед обновлением нового ключа в кластере, вы получите состояние отзыва ключей.

Все данные остаются доступными во время и после операции смены ключей. Данные всегда шифруются с помощью ключа шифрования учетной записи (АЕК), который шифруется с помощью новой версии ключа шифрования ключа (KEK) в Key Vault.

Управляемый клиентом ключ для сохраненных запросов и оповещений поиска по журналам

Язык запросов, используемый в Log Analytics, является выразительным и может содержать конфиденциальные сведения в комментариях, или в синтаксисе запросов. Некоторым организациям требуется, чтобы такая информация была защищена в рамках политики ключей, управляемых клиентом, и вы должны сохранять запросы, зашифрованные с помощью ключа. Azure Monitor позволяет хранить сохраненные запросы и оповещения поиска журналов, зашифрованные ключом в собственной учетной записи хранения при связывании с рабочей областью.

Управляемый клиентом ключ для книг

Учитывая рекомендации по использованию ключа, управляемого клиентом, для сохраненных запросов и оповещений поиска по журналам Azure Monitor позволяет хранить запросы книги, зашифрованные с помощью ключа в вашей учетной записи хранения, при выборе параметра "Сохранить содержимое в служба хранилища Azure учетной записи" в книге "Сохранить".

Снимок экрана: сохранение книги.

Примечание.

Запросы остаются зашифрованными с помощью ключа Майкрософт (MMK) в следующих сценариях независимо от конфигурации управляемых клиентом ключей: панелей мониторинга Azure, приложения логики Azure, записных книжек Azure и Runbook службы автоматизации.

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

Рекомендации по настройке ключа, управляемого клиентом, для запросов

  • У вас должны быть разрешения на запись в рабочую область и в учетную запись хранения.
  • Обязательно создайте учетную запись хранения в том же регионе, что и рабочая область Log Analytics, с шифрованием ключей, управляемым клиентом. Это важно, так как сохраненные запросы хранятся в хранилище таблиц, и его можно шифровать только при создании учетной записи хранения.
  • Запросы, сохраненные в пакете запросов, не шифруются с помощью ключа, управляемого клиентом. Выберите " Сохранить как устаревший запрос " при сохранении запросов, чтобы защитить их с помощью ключа, управляемого клиентом.
  • Сохранение запросов в хранилище считается артефактами службы, а их формат может измениться.
  • Связывание учетной записи хранения для запросов удаляет существующие запросы из рабочей области. Копирование сохраняет запросы, необходимые перед этой конфигурацией. Сохраненные запросы можно просмотреть с помощью PowerShell.
  • Запросы типа "Журнал" и "Закрепить на панели мониторинга" не поддерживаются при связывании учетной записи хранения для запросов.
  • Вы можете связать одну учетную запись хранения с рабочей областью для сохраненных запросов и запросов оповещений поиска журналов.
  • Оповещения поиска журналов сохраняются в хранилище BLOB-объектов и шифрование ключей, управляемых клиентом, можно настроить при создании учетной записи хранения или более поздней версии.
  • Оповещения поиска по журналам не содержат результатов поиска или запроса оповещений. Чтобы получить контекст для сработавших оповещений, можно использовать измерения оповещений.

Настройка BYOS для сохраненных запросов

Свяжите учетную запись хранения для запросов, чтобы сохранить сохраненные запросы в учетной записи хранения.

Н/П

После настройки любой новый сохраненный поисковый запрос будет сохранен в хранилище.

Настройка BYOS для запросов оповещений поиска по журналам

Свяжите учетную запись хранения для оповещений для оповещений поиска по журналам в учетной записи хранения.

Н/П

После настройки любой новый запрос оповещения будет сохранен в хранилище.

Защищенное хранилище

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

Блокировка предоставляется в выделенном кластере в Azure Monitor, где разрешение на доступ к данным предоставляется на уровне подписки.

См. дополнительные сведения о защищенном хранилище для Microsoft Azure.

Операции с ключами, управляемыми клиентом

Ключ, управляемый клиентом, предоставляется в выделенном кластере, и эти операции описаны в статье о выделенном кластере.

  • Получение всех кластеров в группе ресурсов
  • Получение всех кластеров в подписке
  • Обновление резервирования мощности в кластере
  • Обновление billingType в кластере
  • Отсоединение рабочей области от кластера
  • Удаление кластера

Пределы и ограничения

  • Для каждого региона и каждой подписки можно создать до пяти активных кластеров.

  • В каждом регионе и каждой подписке может существовать до семи кластеров (активных или недавно удаленных).

  • С кластером можно связать до 1000 рабочих областей Log Analytics.

  • За 30-дневный период в определенной рабочей области можно выполнить до двух операций связывания.

  • Перемещение кластера в другую группу ресурсов или подписку в настоящее время не поддерживается.

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

  • В настоящее время защищенное хранилище недоступно в Китае.

  • Блокировка не применяется к таблицам с вспомогательным планом.

  • Двойное шифрование настраивается автоматически для кластеров, созданных начиная с октября 2020 года в поддерживаемых регионах. Вы можете проверить, настроено ли для кластера двойное шифрование, отправив запрос GET в кластер и убедившись, что значение isDoubleEncryptionEnabled равно true для кластеров с включенным двойным шифрованием.

    • Если вы создаете кластер и получаете сообщение об ошибке "<имя_региона> не поддерживает двойное шифрование для кластеров", вы по-прежнему можете создать кластер с двойным шифрованием, добавив "properties": {"isDoubleEncryptionEnabled": false} в текст запроса REST.
    • После создания кластера невозможно изменить параметры двойного шифрования.

  • Разрешено удаление рабочей области, связанной с кластером. Если вы решите восстановить рабочую область в период обратимого удаления, она вернется в предыдущее состояние и останется связанной с кластером.

  • Шифрование ключа, управляемого клиентом, применяется к вновь принятым данным после времени настройки. Данные, которые были приема до настройки, остаются зашифрованными с помощью ключей Майкрософт. Данные можно запрашивать до и после настройки ключа, управляемой клиентом, без проблем.

  • Хранилище Azure Key Vault должно быть настроено как восстанавливаемое. Эти свойства не включены по умолчанию, и их нужно настроить с помощью интерфейса командной строки или PowerShell.

  • Хранилище ключей Azure, кластер и рабочие области должны находиться в одном регионе и в одном клиенте Microsoft Entra, но они могут находиться в разных подписках.

  • При настройке для параметра identity type кластера значения None также отменяется доступ к данным, но этот подход не рекомендуется, так как его нельзя отменить без обращения в службу поддержки. Рекомендуемый способ отмены доступа к данным — отзыв ключа.

  • Вы не можете использовать ключ, управляемый клиентом с управляемым удостоверением, назначаемым пользователем, если Key Vault находится в Private-Link (vNet). В этом сценарии можно использовать управляемое удостоверение, назначаемое системой.

  • Вспомогательный план таблицы не поддерживает ключи, управляемые клиентом. Данные в таблицах с вспомогательным планом шифруются с помощью ключей, управляемых Корпорацией Майкрософт, даже если вы защищаете данные в остальной части рабочей области Log Analytics с помощью собственного ключа шифрования.

Устранение неполадок

  • Поведение в зависимости от доступности Key Vault:

    • При нормальных операциях. Служба хранилища кэширует АЕК в течение короткого периода времени и возвращается к Key Vault для периодической распаковки.

    • Ошибки подключения Key Vault— хранилище обрабатывает временные ошибки (время ожидания, сбои подключения, проблемы с DNS), позволяя ключам оставаться в кэше во время проблемы доступности и преодолевать проблемы с доступностью. Возможность создавать запросы и принимать данные не прерывается.

  • Частота доступа к Key Vault — частота, с которой хранилище кластера обращается к Key Vault для упаковки и распаковки , составляет от 6 до 60 секунд.

  • Если вы обновляете кластер во время подготовки или обновляете состояние, обновление завершается ошибкой.

  • Если возникает конфликт — ошибка при создании кластера, кластер с тем же именем может быть удален за последние 14 дней и сохранен зарезервирован. Удаленное имя кластера становится доступным через 14 дней после удаления.

  • Связывание рабочей области с кластером завершается ошибкой, если рабочая область связана с другим кластером.

  • Если вы создаете кластер и указываете KeyVaultProperties немедленно, операция может завершиться ошибкой, пока удостоверение не будет назначено кластеру и предоставлено Key Vault.

  • Если вы обновляете существующий кластер с помощью KeyVaultProperties и политики доступа к ключу Get отсутствует в Key Vault, операция завершается ошибкой.

  • Если вам не удается развернуть кластер, убедитесь, что Azure Key Vault, кластер и рабочие области находятся в одном регионе. Они могут находиться в разных подписках.

  • Если вы поворачиваете ключ в Key Vault и не обновляете новые сведения об идентификаторе ключа в кластере, кластер продолжает использовать предыдущий ключ и данные будут недоступны. Обновите новые сведения об идентификаторе ключа в кластере, чтобы возобновить прием данных и запрос. Вы можете обновить версию ключа с помощью "'", чтобы хранилище всегда использовало более позднюю версию ключа автоматически.

  • Некоторые операции выполняются долго и могут занять некоторое время, включить создание кластера, обновление ключа кластера и удаление кластера. Состояние операции можно проверить, отправив запрос GET в кластер или рабочую область и проследив за ответом. Например, у несвязанной рабочей области не будет значения clusterResourceId в разделе features.

  • Сообщения об ошибках

    Обновление кластера

    • 400 — кластер находится в состоянии удаления. Выполняется асинхронная операция. Перед выполнением операции обновления кластер должен завершить операцию.
    • 400 — KeyVaultProperties не пуст, но имеет неправильный формат. См. раздел об обновлении идентификатора ключа.
    • 400— не удалось проверить ключ в Key Vault. Это может быть связано с отсутствием разрешений или ключа. Убедитесь, что задали ключ и политику доступа в Key Vault.
    • 400 — ключ не может быть восстановлен. Для Key Vault должно быть задано обратимое удаление и защита от удаления. См. документацию по Key Vault.
    • 400 — операция не может быть выполнена сейчас. Дождитесь завершения асинхронной операции и повторите попытку.
    • 400 — кластер находится в состоянии удаления. Дождитесь завершения асинхронной операции и повторите попытку.

    Получение кластера

    • 404--Cluster не найден, кластер может быть удален. Если вы пытаетесь создать кластер с таким именем и получить конфликт, кластер находится в процессе удаления.

Следующие шаги