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

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

В следующей таблице показана сводка по типам ключей и поддерживаемым алгоритмам в Key Vault. Для симметричного алгоритма (oct-HSM/AES) см. раздел "Типы ключей", "алгоритмы" и "операции" (управляемый 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.

Алгоритмы симметричного ключа

Симметричные ключи (oct-HSM /AES) не поддерживаются в Key Vault. Поддерживаемые алгоритмы AES (AES-KW, AES-GCM, AES-CBC) и HMAC sign/verify (HS256/384/512) см. в разделах "Типы ключей", "Алгоритмы и операции" (Управляемый HSM).

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

Следующие операции поддерживаются в ключевых объектах:

• Создание: клиент создает ключ в службе. Служба создает и сохраняет значение ключа и не освобождает его клиенту.
• Импорт: клиент импортирует существующий ключ в службу. Асимметричные ключи можно импортировать с помощью нескольких различных методов упаковки в конструкции JWK.
• Обновление. Клиент с достаточными разрешениями изменяет метаданные (ключевые атрибуты), связанные с ранее сохраненным ключом.
• Удаление: клиент с достаточными разрешениями удаляет ключ.
• Список: клиент перечисляет все ключи в службе.
• Список версий: клиент перечисляет все версии заданного ключа.
• Get: клиент получает открытые части заданного ключа. Операция get не возвращает закрытую часть асимметричного ключа и ключевой материал симметричного ключа.
• Резервное копирование: экспортирует ключ в защищенной форме.
• Восстановление: импортирует ранее резервный ключ.
• Выпуск: безопасно освобождает ключ для авторизованного кода, работающего в конфиденциальной вычислительной среде. Требуется аттестация того, что среда доверенного выполнения (TEE) соответствует требованиям release_policy ключа.

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

• Подписание и проверка: Строго говоря, эта операция представляет собой «подписание хэша» или «проверку хэша», поскольку служба не вычисляет хэш содержимого в рамках создания подписи. Приложения должны локально вычислять хэш данных, которые требуется подписать, а затем запрашивать у службы подпись этого хэша. Проверка подписанных хэшей поддерживается как удобное для приложений, которые могут не иметь доступа к материалу открытого ключа; для обеспечения оптимальной производительности операции проверки должны выполняться локально.
• Шифрование / обертывание ключей: Ключ, хранящийся в сервисе, может защищать другой ключ, обычно симметричный ключ шифрования содержимого (CEK). Если ключ в службе асимметричный, используйте шифрование ключей (например, RSA-OAEP; WRAPKEY/UNWRAPKEY эквивалентно ENCRYPT/DECRYPT. Если ключ в службе симметричный, используйте оболочку ключей (например, AES-KW). WRAPKEY поддерживается в качестве удобства для приложений, которые могут не иметь доступа к материалу открытого ключа; для обеспечения оптимальной производительности операции оболочки должны выполняться локально.
• Шифрование и расшифровка: ключ, хранящийся в службе, может шифровать или расшифровывать один блок данных. Размер блока определяется типом ключа и выбранным алгоритмом шифрования. Шифрование предоставляется для удобства; для обеспечения оптимальной производительности операции шифрования должны выполняться локально.

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

Служба не поддерживает операции EXPORT. После того как ключ подготовлен, вы не сможете извлечь его или изменить его ключевой материал. Чтобы переместить ключ, используйте операции BACKUP и RESTORE для экспорта или импорта ключа в защищенной форме. Ключи, созданные backup, нельзя использовать вне службы.

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

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

Помимо операций, перечисленных выше, Key Vault (хранилища) поддерживают:

• Ротация: Выполняет ротацию существующего ключа путем создания новой версии ключа. Эта операция доступна только для ресурсов Key Vault, но не для Managed HSM.

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

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

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

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

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

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

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

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

• создано: IntDate, необязательно. Созданный атрибут указывает, когда была создана эта версия ключа. Значение null для ключей, созданных до добавления этого атрибута. Нужно указать число, содержащее значение IntDate.
• обновлено: IntDate, необязательный параметр. Обновленный атрибут указывает, когда была обновлена эта версия ключа. Значение, присвоенное ключам, равно null, если они были обновлены до добавления этого атрибута. Нужно указать число, содержащее значение IntDate.

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

Ключи, срок действия которых ещё не наступил или уже истёк, вне окна nbf / exp используются для операций расшифрования, освобождения, развёртывания и проверки (ошибка 403 Forbidden не возвращается). Основной причиной использования ключа в состоянии "еще не проверено" является возможность проверить ключ перед использованием в рабочей среде. Обоснование использования состояния «истёк» заключается в том, чтобы обеспечить возможность выполнять операции по восстановлению данных, созданных в то время, когда ключ был действителен. Вы также можете отключить доступ к ключу, обновив включенный атрибут на false.

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

Помимо атрибутов, перечисленных выше, Key Vault ключи предоставляют:

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

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

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

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

Можно указать дополнительные метаданные, относящиеся к приложению, в виде тегов. 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.

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

• Сведения о Key Vault
• Сведения о ключах в управляемом HSM
• Ключевые типы, алгоритмы и операции (управляемый HSM)
• О секретах
• Сведения о сертификатах
• Обзор REST API Key Vault
• Аутентификация, запросы и ответы
• руководство разработчика Key Vault