Планирование и реализация ключа клиента Azure Information Protection

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

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

Примечание

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

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

Ключ клиента Azure Information Protection — это корневой ключ вашей организации. Другие ключи могут быть производными от этого корневого ключа, включая ключи пользователей, ключи компьютеров или ключи шифрования документов. Каждый раз, когда Azure Information Protection использует эти ключи для Организации, они криптографически связаны с ключом клиента Azure Information Protection root.

Помимо корневого ключа клиента, Организации может требоваться Локальная безопасность для конкретных документов. Защита локальных ключей обычно требуется только для небольшого объема содержимого и, следовательно, настроена вместе с корневым ключом клиента.

Типы ключей Azure Information Protection

Корневой ключ клиента может иметь следующие значение:

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

Совет

Если вы используете класс Classic Client и требуется дополнительная Локальная защита, используйте вместо нее собственный ключ (HYOK) .

Корневые ключи клиента, созданные корпорацией Майкрософт

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

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

Для ключа по умолчанию дальнейшие действия не требуются, и вы можете перейти непосредственно к началу работы с корневым ключом клиента.

Примечание

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

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

Защита создание собственных ключей (BYOK)

BYOK — защита использует ключи, созданные клиентами, либо в Azure Key Vault, либо локально в организации клиента. Затем эти ключи передаются в Azure Key Vault для дальнейшего управления.

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

Дополнительные сведения см. в разделе Настройка защиты BYOK.

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

Двойное шифрование ключей (ДКЕ)

Относится только к: административная унифицированная метка только для клиента

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

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

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

Используйте ДКЕ, если ваша организация:

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

Примечание

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

Дополнительные сведения см. в разделе Шифрование двойных ключей в документации по Microsoft 365.

Держите собственный ключ (HYOK)

Относится только к классическому классу "административный клиент"

HYOK — защита использует ключ, который создается и удерживается клиентами, в расположении, изолированном от облака. Поскольку HYOK-Protection обеспечивает доступ только к данным локальных приложений и служб, клиенты, использующие HYOK, также имеют облачный ключ для облачных документов.

Используйте HYOK для документов, которые:

  • Ограничение только для нескольких пользователей
  • Не предоставляется за пределами Организации
  • Используются только во внутренней сети.

Как правило, эти документы имеют наивысшую классификацию в вашей организации, как «наиболее секретный».

Содержимое может быть зашифровано с помощью защиты HYOK только при наличии классического клиента. Однако при наличии содержимого, защищенного с помощью HYOK, его можно просмотреть как в классическом, так и в унифицированном клиенте меток.

Дополнительные сведения см. в разделе хранение собственных ключей (HYOK).

Дальнейшие действия

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

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