Как выполнить перенос ключевых рабочих нагрузок

Azure Key Vault и Managed HSM не позволяют экспортировать ключи, чтобы защитить ключевой материал и гарантировать невозможность изменения HSM-свойств ключей.

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

Существует несколько сценариев, требующих миграции ключевых рабочих нагрузок:

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

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

службы Azure с помощью ключа, управляемого клиентом

Для большинства рабочих нагрузок, использующих ключи в Key Vault, наиболее эффективным способом переноса ключа в новое расположение (новый управляемый HSM или новый key vault в другой подписке или регионе) является следующее:

1. Создайте новый ключ в новом хранилище или управляемой системе HSM.
2. Предоставьте рабочей нагрузке доступ к новому ключу, назначив управляемую идентификацию рабочей нагрузки соответствующей роли Azure RBAC в Azure Key Vault или соответствующей локальной роли RBAC в Managed HSM.
3. Обновите рабочую нагрузку, чтобы использовать новый ключ в качестве управляемого клиентом ключа шифрования.
4. Сохраните старый ключ, пока не хотите, чтобы резервные копии данных рабочей нагрузки, которые они изначально защищали.

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

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

1. Создайте новый ключ в целевом хранилище ключей или управляемом HSM.
2. Следуйте инструкциям в разделе "Настройка ключей, управляемых клиентом" для существующей учетной записи хранения, чтобы обновить учетную запись хранения, чтобы использовать новый ключ.
3. Сохраняйте доступ к предыдущему управляемому клиентом ключу, пока служба хранилища полностью не перейдет на новый ключ.
4. Убедившись, что все операции работают правильно с новым ключом, можно безопасно удалить предыдущий ключ (но не удалять его, если требуется получить доступ к старым резервным копиям).

Этот шаблон применяется ко многим службам Azure, поддерживающим ключи, управляемые клиентом.

Пользовательские приложения и шифрование на стороне клиента

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

1. Создайте новое хранилище ключей или управляемый HSM и создайте новый ключ шифрования ключей (KEK).
2. Повторно зашифруйте все ключи или данные, зашифрованные старым ключом, с помощью нового ключа. (Если данные шифруются ключом в хранилище ключей напрямую, это может занять некоторое время, так как все данные должны быть считаны, расшифрованы и зашифрованы с помощью нового ключа. Используйте шифрование конверта, где это возможно, чтобы ускорить смену ключей). При повторном шифровании данных рекомендуется трехуровневая иерархия ключей, которая упрощает поворот KEK в будущем:
   1. Ключ шифрования ключей в Azure Key Vault или управляемом HSM
   2. Первичный ключ
   3. Ключи шифрования данных, производные от первичного ключа
3. Проверьте данные после миграции (и перед удалением).
4. Не удаляйте старое хранилище ключей и ключей, пока вы больше не хотите, чтобы резервные копии данных, связанных с ним.

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

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

Примеры ресурсов с различными доменами безопасности:

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

Чтобы использовать один и тот же ключевой материал в этих областях:

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

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

   • Для Azure Key Vault следуйте спецификации BYOK Azure Key Vault.
   • Для Managed HSM воспользуйтесь руководством Импорт ключей, защищённых HSM, в Managed HSM (BYOK).

   Это важно

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

3. Обновите приложения и службы, чтобы использовать новый универсальный код ресурса (URI) ключа в каждом регионе. Настройте каждое региональное развертывание вашего приложения, например пользовательское приложение, База данных SQL Azure, Azure Cosmos DB либо другую службу, чтобы ссылаться на новый URI ключа из хранилища или управляемого аппаратного модуля безопасности (HSM) в этом регионе. Так как каждый Key Vault или Managed HSM имеет собственный уникальный URI, URI ключа будет отличаться в каждом ресурсе, даже если материал ключа идентичен. Убедитесь, что конфигурации вашего приложения ссылаются на правильный ключевой URI.

Перенос ключей клиента в Azure Information Protection

Перенос ключей арендатора в Azure Information Protection обозначается как "смена ключа" или "перекатывание ключа". Управляемые клиентом операции жизненного цикла ключа клиента AIP содержат подробные инструкции по выполнению этой операции.

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

1. Удалите защиту из документа, защищенного старым ключом клиента.
2. Снова примените защиту, которая будет использовать новый ключ клиента.

Переход на платформу HSM 2

Azure Key Vault обновила свою платформу HSM, чтобы обеспечить улучшенную безопасность с проверкой FIPS 140 уровня 3. Теперь все новые ключи и версии ключей создаются с помощью HSM Platform 2. Вы можете проверить, какая платформа HSM защищает ключ, глядя на его атрибут hsmPlatform .

Чтобы перенести рабочие нагрузки на ключи, защищенные платформой HSM 2:

1. Создание новых ключей на платформе HSM 2

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

2. Смена ключей для разных служб

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

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

Управление ключами клиентов для Microsoft 365

Для организаций, совершающих переход с HSM Platform 1, эффективное управление ключами клиентов имеет решающее значение. Microsoft 365 предоставляет надежные инструменты и рекомендации для управления и ротации корневых ключей, контролируемых клиентом, и ключей доступности. Ниже приведены ключевые ресурсы, которые помогут вам управлять этим процессом:

• Свернуть или повернуть ключ клиента или ключ доступности: узнайте, как свернуть управляемые клиентом корневые ключи или ключи доступности, включая создание новых версий или создание новых ключей.
• Понимание ключа доступности: Подробные сведения о ключе доступности и его роли в шифровании Microsoft 365.
• Manage Customer Key for Microsoft 365: комплексное руководство по управлению ключами клиентов, включая создание и назначение политик шифрования данных (DEPS).

Основные рекомендации по выведению из эксплуатации платформы HSM 1

По мере того, как платформа HSM 1 снимается с эксплуатации, убедитесь, что вы:

1. Свернуть или повернуть корневые ключи, управляемые клиентом, по мере необходимости для обеспечения соответствия требованиям и безопасности.
2. Обновите политики шифрования данных (DEPS), чтобы ссылаться на новые ключи или версии ключей.
3. Следуйте рекомендациям по управлению ключами, включая минимизацию разрешений и использование ключей мониторинга.

Дополнительные сведения см. в документации Ключ клиента Microsoft Purview.

Дальнейшие шаги

• Сведения об Azure Key Vault
• Понимание автообновления паролей в Azure Key Vault
• Что такое управляемый HSM в Azure Key Vault?
• Управление ключами в Azure