Типы ключей, алгоритмы и операции

Key Vault поддерживает два типа ресурсов: хранилища и управляемые HSM. Оба типа ресурсов поддерживают различные ключи шифрования. Сведения о поддерживаемых типах ключей и типах защиты по каждому типу ресурсов см. в разделе "Сведения о ключах".

В следующей таблице показана сводка по типам ключей и поддерживаемым алгоритмам.

Алгоритмы EC

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

Типы кривых

• P-256 — кривая NIST P-256, определенная в DSS FIPS PUB 186-4.
• P-256K — кривая SEC SECP256K1, определенная в sec 2: рекомендуемые параметры домена эллиптических кривых.
• P-384 — кривая NIST P-384, определенная в DSS FIPS PUB 186-4.
• P-521 — кривая NIST P-521, определенная в DSS FIPS PUB 186-4.

SIGN/VERIFY

• ES256 — ECDSA для дайджестов SHA-256 и ключей, созданных с кривой P-256. Этот алгоритм описан на RFC7518.
• ES256K — ECDSA для дайджестов SHA-256 и ключей, созданных с кривой P-256K. Этот алгоритм находится на этапе ожидания стандартизации.
• ES384 — ECDSA для дайджестов SHA-384 и ключей, созданных с кривой P-384. Этот алгоритм описан на RFC7518.
• ES512 — ECDSA для дайджестов SHA-512 и ключей, созданных с кривой P-521. Этот алгоритм описан на RFC7518.

Алгоритмы RSA

Следующие идентификаторы алгоритма поддерживаются с ключами RSA и RSA-HSM.

Ключи обертывания/разобертывания (WRAPKEY/UNWRAPKEY), шифрование/дешифрование (ENCRYPT/DECRYPT)

• RSA-OAEP-256 — RSAES с оптимальным асимметричным заполнением шифрования, хэш-функцией SHA-256 и функцией генерации маски MGF1 с использованием SHA-256.
• [Не рекомендуется] RSA1_5 — шифрование ключей RSAES-PKCS1-V1_5 [RFC3447].
• [Не рекомендуется] RSA-OAEP — RSAES с использованием оптимального асимметричного шифрования с дополнительным заполнением (OAEP) [RFC3447], с параметрами по умолчанию, указанными в RFC 3447 в разделе A.2.1. В этих параметрах по умолчанию используется хэш-функция SHA-1 и функция генерации маски MGF1 с помощью SHA-1.

SIGN/VERIFY

• PS256 — RSASSA-PSS с использованием SHA-256 и MGF1 с SHA-256, как описано в RFC7518.
• PS384 — RSASSA-PSS с использованием SHA-384 и MGF1 с SHA-384, как описано в RFC7518.
• PS512 — RSASSA-PSS, использующий SHA-512 и MGF1 с SHA-512, как описано в RFC7518.
• RS256 — RSASSA-PKCS-v1_5 с помощью SHA-256. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-256 и иметь длину в 32 байта.
• RS384 — RSASSA-PKCS-v1_5 с помощью SHA-384. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-384 и иметь длину в 48 байтов.
• RS512 — RSASSA-PKCS-v1_5 с помощью SHA-512. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-512 и иметь длину в 64 байта.
• RSNULL — см. RFC2437 специализированный вариант использования для включения определенных сценариев TLS.

Алгоритмы симметричных ключей (только для управляемых устройств HSM)

Следующие идентификаторы алгоритма поддерживаются с ключами oct-HSM.

Ключи обертывания/разобертывания (WRAPKEY/UNWRAPKEY), шифрование/дешифрование (ENCRYPT/DECRYPT)

• AES-KW — оболочка ключей AES (RFC3394).
• AES-GCM — шифрование AES в режиме счетчика Galois (NIST SP 800-38d).
• AES-CBC — шифрование AES в режиме цепочки блоков шифров (NIST SP 800-38a).

При использовании этих алгоритмов с 256-битными ключами они устойчивы против квантовых атак в соответствии с набором The Commercial National Security Algorithm Suite 2.0 и руководством по квантовым вычислениям.

SIGN/VERIFY

• HS256 — HMAC с помощью хэш-функции SHA-256, как описано в RFC7518.
• HS384 — HMAC с хэш-функцией SHA-384, как описано в RFC7518.
• HS512 — HMAC с помощью хэш-функции SHA-512, как описано в RFC7518.

Ключевые операции

Key Vault, включая управляемый HSM, поддерживает следующие операции с ключевыми объектами:

• Create: клиент создает ключ в Key Vault. Key Vault создает и сохраняет значение ключа и не освобождает его клиенту. Асимметричные ключи можно создать в Key Vault.
• Import: клиент импортирует существующий ключ в Key Vault. Асимметричные ключи можно импортировать в Key Vault с помощью нескольких различных методов упаковки в конструкции JWK.
• Update: клиент с достаточными разрешениями изменяет метаданные (ключевые атрибуты), связанные с ключом, ранее хранящимся в Key Vault.
• Delete: клиент с достаточными разрешениями удаляет ключ из Key Vault.
• List: клиент перечисляет все ключи в заданной Key Vault.
• List versions: клиент перечисляет все версии заданного ключа в заданном Key Vault.
• Get: клиент извлекает открытые части заданного ключа в Key Vault.
• Резервное копирование: экспортирует ключ в защищенной форме.
• Восстановление: импортирует ранее сохраненный ключ.
• Выпуск: безопасно освобождает ключ для авторизованного кода, работающего в конфиденциальной вычислительной среде. Для этого требуется подтверждение, что Доверенная Среда Выполнения (TEE) соответствует требованиям политики выпуска ключа.
• Rotate: обновляет существующий ключ путем создания новой версии ключа (только для Key Vault).

Дополнительные сведения см. в разделе Key operations in the Key Vault REST API reference.

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

• Sign and Verify: строго говоря, эта операция является "подписанием хэша" или "проверкой хэша", так как Key Vault не поддерживает хэширование содержимого в процессе создания подписи. Приложения должны хэшировать данные локально, а затем запрашивать, чтобы Key Vault подписал хэш. Проверка подписанных хэшей поддерживается как удобная операция для приложений, которые могут не иметь доступа к [открытому] материалу ключа. Для максимальной производительности приложений операции VERIFY следует выполнять локально.
• Key Encryption/Wrapping: можно использовать ключ, хранящийся в Key Vault, для защиты другого ключа, как правило, ключа шифрования симметричного содержимого (CEK). Если ключ в Key Vault асимметричный, используйте шифрование ключей. Например RSA-OAEP, а операции WRAPKEY/UNWRAPKEY эквивалентны операциям ENCRYPT/DECRYPT. Если ключ в хранилище Key Vault симметричный, используйте обертку ключа. Например, AES-KW. Операция WRAPKEY поддерживается в качестве удобства для приложений, которые могут не иметь доступа к открытому ключевому материалу. Для оптимизации производительности приложений рекомендуется выполнять операции WRAPKEY локально.
• Encrypt и Decrypt. Для шифрования или расшифровки одного блока данных можно использовать ключ, хранящийся в Key Vault. Размер блока определяется типом ключа и выбранным алгоритмом шифрования. Операция шифрования предоставляется для удобства для приложений, которые могут не иметь доступа к [открытому] материалу ключа. Для оптимизации производительности приложений операции ENCRYPT нужно выполнять локально.

Несмотря на то что использование WRAPKEY/UNWRAPKEY с помощью асимметричных ключей может показаться лишним (так как данная операция эквивалентна ENCRYPT/DECRYPT), применение разных операций важно. Это обеспечивает разделение семантики и авторизации этих операций, а также целостность в случаях, когда служба поддерживает другие типы ключей.

Key Vault не поддерживает операции EXPORT. Создав ключ в системе, вы не сможете извлечь его или изменить его данные. Однако пользователям Key Vault может потребоваться ключ для других вариантов использования, например после удаления. В этом случае они могут использовать операции BACKUP и RESTORE для экспорта или импорта ключа в защищенной форме. Невозможно использовать ключи, созданные операцией BACKUP вне Key Vault. Кроме того, можно использовать операцию IMPORT для нескольких экземпляров Key Vault.

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

Дополнительные сведения о объектах JWK см. в разделе "Веб-ключ JSON" (JWK).

Операции политики смены ключа

Настройте автоматическую ротацию ключа хранилища ключей, установив политику автоматической ротации ключа. Эта возможность доступна только в ресурсах Key Vault.

• Получение политики поворота: получение конфигурации политики поворота.
• Задайте политику поворота: задайте конфигурацию политики поворота.

Ключевые атрибуты

Помимо материала ключа, можно указать следующие атрибуты. В запросе JSON необходимо включить attributes ключевое слово и фигурные скобки ({}), даже если атрибуты не указаны.

• включено: логическое значение, необязательно, значение по умолчанию — true. Указывает, включен ли ключ и доступен ли ключ для криптографических операций. Используйте атрибут enabled с nbf и exp. Когда операция проводится между nbf и exp, операция разрешена только если атрибут enabled имеет значение true. Операции вне окна nbf / exp автоматически запрещаются, за исключением расшифровки, выпуска, расшифровки ключа и проверки.
• nbf: IntDate, необязательно, по умолчанию теперь. Атрибут nbf (не раньше) определяет время, до которого ключ НЕ ДОЛЖЕН использоваться для криптографических операций, за исключением расшифровки, выпуска, распаковки и проверки. Для обработки атрибута nbf требуется, чтобы текущая дата и время должна быть после или равно не до даты и времени, указанной в атрибуте nbf . Key Vault МОЖЕТ предусмотреть небольшую погрешность, обычно не более нескольких минут, чтобы учесть расхождение времени. Нужно указать число, содержащее значение IntDate.
• exp: IntDate, необязательно, значение по умолчанию — "навсегда". Атрибут exp (время окончания срока действия) определяет время окончания срока действия после которого ключ НЕ ДОЛЖЕН использоваться для криптографической операции, за исключением расшифровки, освобождения, распаковки и проверки. Обработка атрибута exp требует, чтобы текущая дата/время должна быть до даты и времени окончания срока действия, указанного в атрибуте exp . Key Vault МОЖЕТ предоставить некоторый небольшой временной запас, как правило, не более чем несколько минут, чтобы учесть смещение времени. Нужно указать число, содержащее значение IntDate.

Следующие атрибуты только для чтения включены в любой ответ, включающий ключевые атрибуты:

• создано: IntDate, необязательно. Созданный атрибут указывает, когда была создана эта версия ключа. Значение null для ключей, созданных до добавления этого атрибута. Нужно указать число, содержащее значение IntDate.
• обновлено: IntDate, необязательный параметр. Обновленный атрибут указывает, когда была обновлена эта версия ключа. Значение, присвоенное ключам, равно null, если они были обновлены до добавления этого атрибута. Нужно указать число, содержащее значение IntDate.
• hsmPlatform: строка, необязательно. Базовая платформа HSM, которая защищает ключ.
  • hsmPlatform Значение 2 означает, что ключ защищен на новейшей платформе HSM, сертифицированной по последнему стандарту FIPS 140-3 уровня 3.
  • hsmPlatform Значение 1 означает, что ключ защищен предыдущей аппаратной платформой безопасности, сертифицированной в соответствии с Федеральным стандартом обработки информации (FIPS) 140-2 уровня 2.
  • hsmPlatform Значение 0 означает, что ключ защищен с помощью модуля шифрования программного обеспечения FIPS 140-2 уровня 1.
  • Если это значение не задано с помощью управляемого пула HSM, ключ защищен последней версией FIPS 140-3 уровня 3, проверенной платформой HSM.

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

Дополнительные сведения о IntDate и других типах данных см. в разделе "Сведения о ключах, секретах и сертификатах: типы данных".

Операции, зависящие от даты и времени

Еще не действующие и просроченные ключи вне окна nbf / exp, работают для расшифровки, разрешения, распаковки и проверки операций (не возвращают 403, Запрещено). Основной причиной использования ключа в состоянии "еще не проверено" является возможность проверить ключ перед использованием в рабочей среде. Обоснование использования состояния с истекшим сроком действия заключается в том, чтобы разрешить операции восстановления с данными, созданными при действии ключа. Кроме того, можно отключить доступ к ключу с помощью политик Key Vault или обновив атрибут ключа enabled на false.

Дополнительные сведения о типах данных см. в разделе "Типы данных".

Дополнительные сведения о других возможных атрибутах см. в веб-ключе JSON (JWK).

Ключевые теги

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

Контроль доступа к ключам

Key Vault предоставляет управление доступом для ключей на уровне Key Vault, который выступает в качестве контейнера для ключей. Вы можете управлять доступом к ключам с помощью Key Vault Azure Role-Based Access Control (рекомендуется) или устаревшей модели разрешений на доступ к хранилищу Vault Access Policy. Azure RBAC — это модель авторизации по умолчанию и рекомендуемая модель авторизации. Она имеет три предопределенные роли для управления ключами: Key Vault криптоофицер, Key Vault криптопользователь и Key Vault пользователь шифрования службы. Эти роли можно определить на уровне подписки, группы ресурсов или хранилища. Дополнительные сведения см. в разделе Azure RBAC и политики доступа.

Разрешения модели разрешений политики доступа хранилища (устаревшая версия):

• Разрешения для операций управления ключами

  • get: чтение открытой части ключа, а также его атрибутов
  • список ключей или версий ключа, хранящихся в хранилище ключей.
  • обновление. Обновление атрибутов ключа
  • create: Создание новых ключей
  • импорт: импорт ключа в хранилище ключей
  • удалить: удалить ключевой объект
  • восстановление: восстановление удаленного ключа
  • резервное копирование: резервное копирование ключа в хранилище ключей
  • восстановление. Восстановление резервного копирования ключа в хранилище ключей

• Разрешения для криптографических операций

  • расшифровка: используйте ключ для отмены защиты последовательности байтов
  • шифрование: используйте ключ для защиты произвольной последовательности байтов
  • unwrapKey: используйте ключ для распаковки защищенных симметричных ключей
  • wrapKey: используйте ключ для защиты симметричного ключа
  • проверить: Используйте ключ для проверки дайджестов
  • знак: используйте ключ для подписывания дайджестов

• Разрешения для привилегированных операций

  • Очистка: очистка (окончательное удаление) удаленного ключа
  • предоставление: предоставление ключа в конфиденциальную вычислительную среду, соответствующую release_policy ключу.

• Разрешения для операций политики смены

  • rotate: смена существующего ключа путем создания новой версии ключа (только Key Vault)
  • получение политики ротации: извлечение конфигурации политики ротации
  • установка политики ротации: конфигурация политики ротации

Дополнительные сведения о работе с ключами см. в статье Key operations in the Key Vault REST API reference.

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

• About Key Vault
• О службе "Managed HSM"
• О секретах
• Сведения о сертификатах
• Обзор REST API Key Vault
• Аутентификация, запросы и ответы
• руководство разработчика Key Vault