Настройка использования собственного ключа (BYOK)

  • 7 мин

Сценарий

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

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

Требования к этом процессу приведены ниже.

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

Терминология

Имя ключа Тип ключа Происхождение Описание
Ключ обмена ключами (KEK) RSA HSM Azure Key Vault Защищенная HSM пара ключей RSA, созданная в Azure Key Vault
Упаковочный ключ AES (Стандарт шифрования данных) HSM от поставщика Временный ключ AES, созданный локальным устройством HSM
Целевой ключ RSA, EC, AES (только управляемый HSM) HSM от поставщика Ключ для передачи в модуль HSM Azure Key Vault

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

  • Он должен быть ключом RSA-HSM с размером ключа 4096 бит (рекомендуется), 3072 бита или 2048 бит.
  • Его ключевые операции (key_ops) ограничены "импортом", что позволяет использовать его исключительно во время процесса BYOK. Это ограничение сводит к минимуму область атаки.
  • Он должен находиться в том же хранилище, где необходимо импортировать целевой ключ, обеспечивая правильную изоляцию хранилища ключей.

Порядок действий пользователя

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

  1. Создание ключа KEK — создание ключа обмена ключами в Azure Key Vault.
  2. Получите открытый ключ KEK — скачайте общедоступную часть для использования с инструментами поставщика HSM.
  3. Используя средство BYOK, предоставленное поставщиком HSM, импортируйте KEK в целевой HSM и экспортируйте целевой ключ, защищенный KEK.
  4. Импортируйте защищенный целевой ключ в Azure Key Vault . Завершите передачу с помощью Azure CLI или PowerShell.

Клиенты используют средство BYOK и документацию, предоставляемую поставщиком HSM, для выполнения шага 3. Этот процесс создает объект передачи ключей (файл с расширением ".byok"), который безопасно инкапсулирует зашифрованный материал ключа.

Ограничения на HSM

Существующий HSM может применять ограничения для ключей, которыми они управляют, включая:

  • Модуль HSM должен быть настроен для разрешения экспорта с использованием обёртывания ключей.
  • Целевой ключ помечается как CKA_EXTRACTABLE (атрибут Cryptoki) для HSM, чтобы разрешить контролируемый экспорт.
  • В некоторых случаях ключ KEK и оболочка помечены как CKA_TRUSTED, что позволяет использовать их для упаковки ключей в HSM.

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

Замечание

Эти действия можно выполнить с помощью нескольких интерфейсов, включая Azure CLI (как показано в примерах), Azure PowerShell и портал Azure. Их также можно выполнять программным способом с помощью пакета SDK Azure Key Vault для сценариев автоматического развертывания.

Создание KEK

Используйте команду az keyvault key create, чтобы создать KEK с операциями ключа, установленными для импорта. Обратите внимание на идентификатор ключа ('kid'), возвращенный из этой команды, так как он необходим для последующих операций.

az keyvault key create --kty RSA-HSM --size 4096 --name KEKforBYOK --ops import --vault-name ContosoKeyVaultHSM

Это важно

Разные службы Azure поддерживают разные длины KEK. Например, Azure SQL поддерживает только длину ключей в 2048 битах или 3072 битах. Перед созданием KEK всегда проверяйте требования к размеру ключа для вашего конкретного сервиса.

Получение открытого ключа KEK

Скачайте часть открытого ключа KEK и сохраните ее в виде PEM (Privacy-Enhanced Mail). Этот файл используется с инструментом BYOK поставщика HSM.

az keyvault key download --name KEKforBYOK --vault-name ContosoKeyVaultHSM --file KEKforBYOK.publickey.pem

Генерация BLOB для передачи ключей с помощью инструмента BYOK от поставщика HSM

Используйте инструмент BYOK, предоставленный поставщиком HSM, для создания объекта передачи ключа (хранится в виде файла ".byok"). Открытый ключ KEK в формате Privacy-Enhanced Mail (PEM) является одним из входных данных этого средства. Обратитесь к конкретной документации поставщика HSM, чтобы получить подробные инструкции по использованию средства BYOK.

BLOB-объект передачи ключа

В долгосрочной перспективе корпорация Майкрософт хотела бы использовать механизм PKCS#11 CKM_RSA_AES_KEY_WRAP для передачи целевого ключа в Azure Key Vault. Механизм PKCS#11 создает единый блоб и, что более важно, промежуточный ключ AES обрабатывается двумя модулями HSM и гарантированно является кратковременным.

Открытый текст целевого ключа зависит от его типа:

  • Для ключа RSA закрытый ключ ASN.1 DER, закодированный в виде [RFC3447], упакован в PKCS#8 [RFC5208]
  • Для ключа EC кодировка ASN.1 DER закрытого ключа [RFC5915] упакована в PKCS#8 [RFC5208]
  • Для октетного ключа необработанные байты ключа

Байты исходного ключа преобразуются по механизму CKM_RSA_AES_KEY_WRAP:

  • Эфемерный ключ AES создается и шифруется обернутым ключом RSA с использованием RSA-OAEP и SHA1.
  • закодированный исходный ключ шифруется с помощью ключа AES с упаковкой в ключ AES и заполнением;
  • зашифрованный ключ AES и зашифрованный исходный ключ сцепляются, и из них формируется конечный BLOB-объект с зашифрованными данными.

Формат большого двоичного объекта передачи использует компактную сериализацию веб-шифрования JSON (RFC7516) в качестве транспортного средства для доставки необходимых метаданных службе для правильной расшифровки.

Рекомендации по реализации BYOK

При реализации собственных ключей для Azure Key Vault рассмотрите следующие рекомендации по безопасности и эксплуатации:

  • Используйте самый большой поддерживаемый размер ключа . Создайте KEK с размером 4096-разрядного ключа по возможности, так как они обеспечивают самую надежную криптографическую защиту. Используйте только меньшие размеры ключей, если это требуется определенными ограничениями службы.

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

  • Поддержание сертификатов безопасности HSM - Убедитесь, что локальный модуль HSM соответствует стандартам сертификации FIPS 140-2 уровня 2 или более высокого уровня, соответствуя или превосходя уровень безопасности Azure Key Vault.

  • Защита процесса передачи — защита файла byok во время передачи в Azure. Хотя материал ключа зашифрован, файл по-прежнему должен рассматриваться как конфиденциальный и передаваемый по безопасным каналам.

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

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

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

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

  • Реализация элементов управления доступом . Используйте управление доступом на основе ролей Azure (RBAC), чтобы ограничить возможность выполнения операций BYOK. Разделите разрешения для создания KEK от разрешений, которые могут импортировать целевые ключи.

  • Включите ведение журнала аудита - Активируйте ведение журнала и мониторинг Azure Key Vault для отслеживания всех операций BYOK, включая создание KEK, загрузку ключей и импорт целевых ключей. Интеграция журналов с Azure Monitor или решением SIEM.

  • Проверьте поддержку поставщика. Перед приобретением или реализацией решения HSM убедитесь, что поставщик предоставляет средство BYOK, совместимое с текущими требованиями Azure Key Vault.

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