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

  • Статья

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

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

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

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

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

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

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

Для модели ценообразования для выделенных кластеров Log Analytics требуется уровень обязательств начиная с 100 ГБ в день.

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

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

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

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

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

Важно!

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

Screenshot of customer-managed key overview.

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

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

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

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

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

  • Хранилище кластера имеет уникальный ключ шифрования для каждой учетной записи хранения — АЕК.
  • АЕК используется для получения DEK — ключей, используемых для шифрования каждого блока данных, записываемых на диск.
  • При настройке ключа в Key Vault и обновлении сведений о ключе в кластере хранилище кластера выполняет запросы на упаковку и распаковку АЕК для шифрования и расшифровки.
  • Ключ KEK никогда не покидает Key Vault, а если он является управляемым 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. Следует включить пункты Обратимое удаление и Защита от очистки.

Screenshot of soft delete and purge protection settings.

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

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

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

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

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

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

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

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

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

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

    Откройте Key Vault в портал Azure, щелкните конфигурацию Access в Параметры и выберите параметр управления доступом на основе ролей Azure. Затем введите управление доступом (IAM) и добавьте назначение роли пользователя шифрования шифрования службы шифрования key Vault.

    Screenshot of Grant Key Vault RBAC permissions.

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

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

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

    Screenshot of Grant Key Vault access policy permissions.

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

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

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

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

Важно!

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

Screenshot of Grant Key Vault permissions.

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

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

Н/П

Важно!

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

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

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

Отзыв ключа

Важно!

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

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

Смена ключей

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

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

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

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

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

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

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

Screenshot of Workbook save.

Примечание.

Запросы остаются зашифрованными с помощью ключа Майкрософт (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, но они могут находиться в разных подписках.

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

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

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

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

  • Поведение в зависимости от доступности 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 не найден, кластер может быть удален. Если вы пытаетесь создать кластер с таким именем и получить конфликт, кластер находится в процессе удаления.

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