Убежище от входа до мастер-серии пять: Transit Secrets Engine

一、Двигатель секретов транзита

• Механизм конфиденциальности транспорта обрабатывает шифрование данных при передаче. Сейф не хранит данные, отправленные в механизм конфиденциальности. Также думайте об этом как о «криптографии как услуге» или «шифровании как услуге». Механизм секретов транзита также может подписывать и проверять данные, генерировать хэши и HMAC данных, а также выступать в качестве источника случайных байтов.
• Основным вариантом использования транспорта является шифрование данных из приложения при сохранении зашифрованных данных в каком-либо первичном хранилище данных. Это снимает бремя правильного шифрования/дешифрования с разработчика приложения и возлагает бремя на оператора хранилища.
• Поддерживается создание ключей, что позволяет использовать один и тот же ключ для нескольких целей путем получения новых ключей на основе значений контекста, предоставленных пользователем. В этом режиме может дополнительно поддерживаться конвергентное шифрование, позволяющее одним и тем же входным значениям создавать один и тот же зашифрованный текст.
• Генерация ключа данных позволяет запросу процесса возвращать высокоэнтропийный ключ заданной длины в битах, зашифрованный именованным ключом. Обычно это также возвращает ключ в виде открытого текста, чтобы разрешить немедленное использование, но это можно отключить для требований аудита.

2. Управление рабочим набором

• Движок Transit поддерживает управление версиями ключей. Версии ключа старше min_decryption_version, указанного ключом, архивируются, а оставшиеся версии ключа принадлежат рабочему набору. Это связано с соображениями производительности для быстрой загрузки ключей, но также и с соображениями безопасности: было обнаружено, что из-за запрета расшифровки ключей старой версии большинство пользователей не могут расшифровать зашифрованные тексты, соответствующие устаревшим (но конфиденциальным) данным, но в чрезвычайных ситуациях min_decryption_version может быть перемещен назад, чтобы разрешить юридическую расшифровку.
• В настоящее время этот архив хранится в одной записи хранилища. Для некоторых бэкэндов хранилища, особенно тех, которые используют Raft или Paxos для обеспечения высокой доступности, частые ротации могут привести к тому, что размеры записей архивного хранилища будут больше, чем может выдержать бэкенд хранилища. Для частой ротации использование именованных ключей, соответствующих временным диапазонам (например, от пятиминутного периода времени до ближайшего кратного пяти), может быть хорошим выбором, позволяя нескольким ключам действовать одновременно в одном месте. Детерминированный способ решить, какой ключ использовать в любой момент времени.

3. Рекомендации NIST по ротации

• Рекомендуется регулярная ротация ключей шифрования даже при отсутствии компрометации. Для ключей AES-GCM, в соответствии с рекомендациями публикации NIST 800-38D, ротация должна происходить до того, как версия ключа выполнит примерно 232 шифрования. Рекомендуется, чтобы операторы оценивали скорость шифрования ключа и использовали ее для определения частоты ротации, чтобы не допустить достижения рекомендуемого предела. Например, если вы определили, что расчетная скорость составляет 40 миллионов операций в день, достаточно чередовать секрет каждые три месяца.

Четыре, тип ключа

На данный момент механизм секретов транзита поддерживает следующие типы ключей (все типы ключей также генерируют отдельные ключи HMAC):

• aes128-gcm96: AES-GCM со 128-битным ключом AES и 96-битным одноразовым номером, поддерживает шифрование, дешифрование, создание ключей, конвергентное шифрование.
• aes256-gcm96: AES-GCM с 256-битным ключом AES и 96-битным одноразовым номером; поддерживает шифрование, расшифровку, создание ключей, конвергентное шифрование (по умолчанию)
• chacha20-poly1305: ChaCha20-Poly1305 с 256-битным ключом, поддерживает шифрование, дешифрование, создание ключей, конвергентное шифрование
• ed25519: Ed25519; поддержка подписи, проверки подписи и получения ключа
• ecdsa-p256: ECDSA, использующий кривую P-256, поддерживает подписи и проверку подписи.
• ecdsa-p384: ECDSA, использующий кривую P-384, поддерживает подписи и проверку подписи.
• ecdsa-p521: ECDSA, использующий кривую P-521, поддерживает подписи и проверку подписи
• rsa-2048: 2048-битный ключ RSA, поддерживает шифрование, дешифрование, подпись и проверку
• rsa-3072: 3072-битный ключ RSA, поддерживает шифрование, дешифрование, подпись и проверку
• rsa-4096: 4096-битный ключ RSA, поддерживает шифрование, дешифрование, подпись и проверку
• hmac: HMAC, поддерживает генерацию и проверку HMAC.
• управляемый_ключ: управляемый ключ; поддерживает несколько операций, в зависимости от решения по управлению резервными ключами. Дополнительные сведения см. в разделе Ключи условного депонирования.

Примечание. В режиме FIPS 140-2 следующие алгоритмы не сертифицированы и не должны использоваться: chacha20-poly1305 и ed25519.

Примечание. Все типы ключей поддерживают операции HMAC, используя второй случайно сгенерированный ключ для времени создания или ротации ключа. Тип ключа HMAC поддерживает только HMAC и ведет себя так же, как другие алгоритмы с точки зрения операций HMAC, но поддерживает импорт ключа. По умолчанию тип ключа HMAC использует 256-битный ключ.

В операциях RSA используется один из следующих методов:

• OAEP (шифрование, дешифрование) с хеш-функцией SHA-256 и MGF,
• PSS (подпись, проверка) с настраиваемой хэш-функцией, также используемой для MGF, и
• PKCS#1v1.5: (подпись, проверка), с настраиваемыми хеш-функциями.

5. Слитное шифрование

• Конвергентное шифрование — это режим, в котором один и тот же набор открытого текста + контекст всегда создает один и тот же зашифрованный текст. Это достигается путем получения ключей с помощью функции получения ключей и детерминированного получения случайных чисел. Поскольку эти свойства различны для любой комбинации открытого текста и зашифрованного текста в ключевом пространстве размером 2^256, риск повторного использования nonce близок к нулю.
• Это имеет много практического применения. Обычный шаблон использования заключается в том, чтобы разрешить хранение значений в базе данных в зашифрованном виде, но с ограниченной поддержкой поиска/запроса, чтобы строки с одинаковым значением для определенного поля могли быть возвращены из запроса.

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

• Версия 1 требует, чтобы клиенты предоставляли свои собственные одноразовые номера, что очень гибко, но потенциально опасно при неправильном выполнении. Это только в Убежище 0.6.1, в этой версии нельзя обновить ключи.
• Версия 2 использует алгоритмический подход для получения параметров. Однако используемый алгоритм уязвим для автономных атак с подтверждением открытого текста, которые могут быть выполнены злоумышленником методом грубой силы, если открытый текст невелик. Ключи, использующие версию 2, можно обновить, просто выполнив операцию ротации до новой версии ключа; затем существующие значения можно будет перенастроить в соответствии с новой версией ключа и использовать алгоритм версии 3.
• Версия 3 использует другой алгоритм для защиты от автономных атак с подтверждением открытого текста. Он похож на AES-SIV тем, что использует PRF для генерации случайных чисел из открытого текста.

6. Развертывание

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

Чтобы включить секретный движок Transit:

vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/

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

Создайте именованный ключ шифрования:

vault write -f transit/keys/my-key
Success! Data written to: transit/keys/my-key

Обычно каждое приложение имеет свой собственный ключ шифрования.

Семь, используйте

После того, как секретный механизм настроен и у пользователя/компьютера есть токен Vault с соответствующими разрешениями, он может использовать этот секретный механизм.

1. Зашифруйте некоторые данные открытого текста, используя конечную точку /encrypt с именованным ключом:

Примечание. ** Все данные в виде открытого текста должны быть закодированы в base64. Причина этого требования в том, что Vault не требует, чтобы открытый текст был «текстом». Это может быть двоичный файл, такой как PDF или изображение. **Самый простой безопасный транспортный механизм для этих данных — закодировать их в base64 как часть полезной нагрузки JSON.

vault write transit/encrypt/my-key plaintext=$(echo "my secret data" | base64)
Key            Value
---            -----
ciphertext     vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw==
key_version    1

Возвращаемый зашифрованный текст начинается с vault:v1:. Первый префикс (хранилище) идентифицирует его как хранилище. v1 означает, что ключ версии 1 использовался для шифрования открытого текста, поэтому при смене ключа Vault знает, какую версию использовать для расшифровки. Остаток представляет собой конкатенацию base64 вектора инициализации (IV) и зашифрованного текста.

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

Vault HTTP API указывает максимальный размер запроса 32 МБ для предотвращения атак типа «отказ в обслуживании». Это можно настроить для каждого блока прослушивателя в конфигурации сервера Vault.

2. Расшифруйте часть данных, используя конечную точку /decrypt с именованным ключом:

vault write transit/decrypt/my-key ciphertext=vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw==
Key          Value
---          -----
plaintext    bXkgc2VjcmV0IGRhdGEK

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

base64 --decode <<< "bXkgc2VjcmV0IGRhdGEK"
my secret data

Эту расшифровку также можно выполнить в одной команде с помощью некоторых умных сценариев оболочки:

vault write -field=plaintext transit/decrypt/my-key ciphertext=vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw== | base64 --decode
my secret data

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

3. Смените базовый ключ шифрования. Это сгенерирует новый ключ шифрования и добавит его в связку ключей для указанного ключа:

vault write -f transit/keys/my-key/rotate
Success! Data written to: transit/keys/my-key/rotate

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

4. Обновите зашифрованные данные до нового ключа. Vault расшифрует значение с помощью соответствующего ключа в связке ключей, а затем зашифрует полученный открытый текст с помощью последнего ключа в связке ключей.

vault write transit/rewrap/my-key ciphertext=vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw==
Key            Value
---            -----
ciphertext     vault:v2:fhsQPtZtEns2j7ZXLn28EYWh5NF0tFk9i5fa0jq7qkNsft/ZEFlVook1pg==
key_version    2

Этот процесс не раскрывает данные открытого текста. Таким образом, политика Vault может предоставить практически ненадежному процессу возможность «переупаковывать» зашифрованные данные, поскольку этот процесс не сможет получить доступ к открытым текстовым данным.

8. Принесите свой ключ (BYOK)

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

Во-первых, необходимо прочитать ключ упаковки из транспорта:

vault read transit/wrapping_key

Ключ-оболочка будет 4096-битным открытым ключом RSA.

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

HSM

Если ключ импортирован из HSM, поддерживающего PKCS#11, возможны два случая:

• Если HSM поддерживает механизм CKM_RSA_AES_KEY_WRAP, ключ-оболочка может использоваться для упаковки целевого ключа.
• В противном случае оба механизма могут быть объединены для переноса целевого ключа. Сначала следует сгенерировать 256-битный ключ AES, а затем использовать его для переноса целевого ключа с помощью механизма CKM_AES_KEY_WRAP_KWP. Затем ключ AES должен быть заключен в ключ упаковки с использованием MGF1 и SHA-1, SHA-224, SHA-256, SHA-384 или SHA-512 с использованием механизма CKM_RSA_PKCS_OAEP.

Зашифрованный текст создается путем добавления завернутого целевого ключа к завернутому ключу AES.

Байты зашифрованного текста должны быть закодированы в base64.

ручной процесс

Если целевой ключ не хранится в HSM или KMS, можно использовать следующие шаги для создания зашифрованного текста для ввода в конечную точку импорта:

• Создайте временный 256-битный ключ AES.
• Обертывает целевой ключ эфемерным ключом AES с помощью AES-KWP.

Примечание. При переносе симметричного ключа, такого как ключ AES или ChaCha20, переносите необработанные байты ключа. Например, для 128-битного ключа AES это будет массив байтов длиной 16 символов, который будет обернут напрямую без base64 или другой кодировки.

При переносе асимметричного ключа (например, ключа RSA или ECDSA) закодированный формат PKCS8 ключа следует заключить в необработанный DER/двоичный формат. Не применяйте кодировку PEM к этому большому двоичному объекту и не кодируйте его в base64 перед шифрованием.

• Поместите ключ AES в ключ упаковки Vault, используя RSAES-OAEP с MGF1 и SHA-1, SHA-224, SHA-256, SHA-384 или SHA-512.
• Удалите временный ключ AES.
• Добавляет обернутый целевой ключ к обернутому ключу AES.
• Результат в кодировке Base64.