Управление на стороне клиента. Операции с ключом клиента в течение его жизненного цикла

Область применения: Azure Information Protection, Office 365

К чему относится: клиент унифицированных меток и классический клиент AIP

Примечание

Для унификации и улучшения работы пользователей поддержка классического клиента Azure Information Protection и клиента управления метками на портале Azure прекращается с 31 марта 2021 г. Хотя классический клиент продолжит работать, дальнейшая поддержка предоставляться не будет и версии для обслуживания классического клиента больше не будут выпускаться.

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

Если вы управляете своим ключом клиента для Azure Information Protection (сценарий с использованием собственного ключа, BYOK), сведения об операциях в течение жизненного цикла, относящихся к этой топологии, см. в следующих разделах.

Отзыв ключа клиента

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

Чтобы отозвать ключ клиента, управляемый клиентом, в Azure Key Vault измените разрешения в хранилище ключей, содержащем ключ клиента Azure Information Protection, чтобы служба Rights Management Azure больше не могла получить доступ к ключу. Это действие эффективно отменяет ключ клиента для Azure Information Protection.

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

Повторное создание ключа клиента

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

Чтобы повторно создать ключ, необходимо настроить объект ключа клиента и указать альтернативный ключ. Затем ранее использованный ключ автоматически отмечается как заархивированный для Azure Information Protection. Эта конфигурация гарантирует, что содержимое, защищенное с помощью этого ключа, остается доступным.

Далее приведены примеры, когда может потребоваться повторно создать ключ для Azure Information Protection.

  • Компания разделяется на несколько компаний. При повторном создании ключа клиента новая компания не будет иметь доступ к новому содержимому, публикуемому вашими сотрудниками. Но новая компания будет иметь доступ к старому контенту, если получит копию старого ключа клиента.

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

  • Существуют основания предполагать, что мастер-копия ключа клиента (принадлежащая вам) скомпрометирована.

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

  1. Только если новый ключ находится в другом хранилище ключей, который вы уже используете для Azure Information Protection: авторизовать Azure Information Protection для использования хранилища ключей с помощью командлета Set-азкэйваултакцессполици .

  2. Если Azure Information Protection еще не известно о ключе, который вы хотите использовать, выполните командлет use-аипсервицекэйваулткэй .

  3. Настройте объект ключа клиента с помощью командлета Run Set-аипсервицекэйпропертиес .

Дополнительные сведения о каждом из этих этапов

  • Чтобы сменить ключ для другого управляемого ключа, см. статью планирование и реализация ключа клиента Azure Information Protection.

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

  • Чтобы повторно создать ключ, перейдя на ключ, управляемый корпорацией Майкрософт, см. сведения об операциях под управлением Майкрософт в разделе Повторное создание ключа клиента.

Резервное копирование и восстановление ключа клиента

Так как именно вы управляете своим ключом клиента, вы также отвечаете за архивацию ключа, который использует Azure Information Protection.

Если вы создали ключ клиента в локальной среде, в nCipher HSM: для резервного копирования ключа создайте резервную копию файла ключа с маркером, файла мира и карточек администратора. При перемещении ключа в Azure Key Vault служба сохраняет файл ключа с токеном для защиты от сбоев любых узлов служб. Этот файл привязан к системе безопасности для определенного региона или экземпляра Azure. Но не следует считать файл ключа с токеном полной резервной копией. Например, если вам когда-либо понадобится копия ключа в виде обычного текста для использования вне HSM-модуля nCipher, Azure Key Vault не сможет его получить, так как она содержит только невосстанавливаемую копию.

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

Экспорт ключа клиента

При использовании сценария BYOK нельзя экспортировать ключ клиента из хранилища ключей Azure или Azure Information Protection. Копия в хранилище ключей Azure не является восстанавливаемой.

Реакция на нарушения

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

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

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

Описание инцидента Вероятный ответ
Произошла утечка ключа клиента. Повторно создайте ключ клиента. Ознакомьтесь с разделом Повторное создание ключа клиента.
Неавторизованное лицо или вредоносное ПО получило права на использование ключа клиента, но утечка самого ключа клиента не произошла. В этой ситуации повторное создание ключа клиента не поможет, и необходимо выполнить анализ основной причины. Если получение доступа несанкционированным лицом произошло вследствие ошибки в процессе или программе, то такую ситуацию необходимо исправить.
Уязвимость обнаружена в технологии HSM текущего поколения. Корпорация Майкрософт должна обновить HSM. Если есть основания предполагать, что эта уязвимость может раскрыть ключи, Майкрософт проинструктирует всех клиентов повторно создать свои ключи.
Уязвимость, обнаруженную в алгоритме RSA, в длине ключа или в результате атаки методом "грубой силы", возможно вычислить. Корпорация Майкрософт обязуется обновлять Azure Key Vault или Azure Information Protection для поддержки новых алгоритмов и более длинных ключей, которые более устойчивы, и сообщать всем клиентам о необходимости повторного создания ключей.