Шифрование на стороне клиента для очередей

Статья
06/01/2023

Клиентские библиотеки Хранилища очередей Azure для .NET и Python поддерживает шифрование данных в клиентских приложениях перед отправкой в Службу хранилища Azure и их расшифровку во время скачивания клиентом. Кроме того, клиентские библиотеки поддерживают интеграцию с Azure Key Vault для управления ключами учетной записи хранения.

Важно!

Служба хранилища Azure поддерживает шифрование на стороне службы и на стороне клиента. Для большинства сценариев корпорация Майкрософт рекомендует использовать функции шифрования на стороне службы, чтобы упростить защиту данных. Дополнительные сведения о шифровании на стороне службы см. в статье Шифрование Службы хранилища Azure для неактивных данных.

Сведения о шифровании на стороне клиента

Клиентская библиотека Хранилища очередей Azure использует алгоритм AES для шифрования данных пользователя. В клиентской библиотеке доступны две версии шифрования на стороне клиента:

В версии 2 используется режим счетчика с аутентификацией Галуа (GCM) с AES.
В версии 1 используется режим цепочки цифровых блоков (CBC) с AES.

Предупреждение

Использование функции шифрования на стороне клиента версии 1 больше не рекомендуется из-за уязвимости системы безопасности в реализации клиентской библиотеки режима CBC. Дополнительные сведения об этой уязвимости системы безопасности приведены в статье Обновление функции шифрования на стороне клиента в пакете SDK Службы хранилища Azure для устранения уязвимости системы безопасности. Если вы используете версию 1, рекомендуем обновить приложение для использования версии 2 и перенести данные. Дополнительные рекомендации см. далее в разделе Устранение уязвимости системы безопасности в приложениях.

Устранение уязвимости системы безопасности в приложениях

Из-за уязвимости системы безопасности, обнаруженной в реализации клиентской библиотеки Хранилища очередей в режиме CBC, корпорация Майкрософт рекомендует немедленно выполнить одно или несколько следующих действий:

Рекомендуем использовать функции шифрования на стороне службы вместо функций шифрования на стороне клиента. Дополнительные сведения о шифровании на стороне службы см. в статье Шифрование Службы хранилища Azure для неактивных данных.
Если нужно использовать шифрование на стороне клиента, переведите приложения с шифрования на стороне клиента версии 1 на шифрование на стороне клиента версии 2.

В следующей таблице описаны действия, которые нужно выполнить, если вы решили перевести приложения на шифрование на стороне клиента версии 2:

Состояние шифрования на стороне клиента	Рекомендованные действия
Для шифрования на стороне клиента приложение использует версию клиентской библиотеки, которая поддерживает только шифрование на стороне клиента версии 1.	Обновите приложение для использования версии клиентской библиотеки, которая поддерживает шифрование на стороне клиента версии 2. Список поддерживаемых версий см. в разделе Таблица поддержки пакета SDK для шифрования на стороне клиента. Обновите код для использования функции шифрования на стороне клиента версии 2.
Для шифрования на стороне клиента приложение использует версию клиентской библиотеки, которая поддерживает шифрование на стороне клиента версии 2.	Обновите код для использования функции шифрования на стороне клиента версии 2.

Состояние шифрования на стороне клиента

Рекомендованные действия

Для шифрования на стороне клиента приложение использует версию клиентской библиотеки, которая поддерживает только шифрование на стороне клиента версии 1.

Обновите приложение для использования версии клиентской библиотеки, которая поддерживает шифрование на стороне клиента версии 2. Список поддерживаемых версий см. в разделе Таблица поддержки пакета SDK для шифрования на стороне клиента.

Обновите код для использования функции шифрования на стороне клиента версии 2.

Для шифрования на стороне клиента приложение использует версию клиентской библиотеки, которая поддерживает шифрование на стороне клиента версии 2.

Обновите код для использования функции шифрования на стороне клиента версии 2.

Кроме того, корпорация Майкрософт рекомендует выполнить следующие действия для защиты данных:

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

Таблица поддержки пакета SDK для шифрования на стороне клиента

В следующей таблице показано, какие версии клиентских библиотек для .NET и Python поддерживают функцию шифрования на стороне клиента и каких именно версий:

	.NET	Python
Шифрование на стороне клиента версий 1 и 2	Версии 12.11.0 и более поздние версии	Версии 12.4.0 и более поздние версии
Только шифрование на стороне клиента версии 1	Версии 12.10.0 и более ранние версии	Версии 12.3.0 и более ранние версии

Если приложение использует функцию шифрования на стороне клиента с более ранней версией клиентской библиотеки .NET или Python, сначала нужно обновить код до версии, поддерживающей шифрование на стороне клиента версии 2. Затем расшифруйте и повторно зашифруйте данные с помощью функции шифрования на стороне клиента версии 2. При необходимости во время переноса кода вы можете использовать версию клиентской библиотеки, которая поддерживает параллельное шифрование на стороне клиента версии 2, с более ранней версией клиентской библиотеки.

Как работает шифрование на стороне клиента

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

Клиентские библиотеки Хранилища очередей используют Azure Key Vault для защиты ключей, применяемых для шифрования на стороне клиента. Дополнительные сведения об Azure Key Vault см. в статье Что такое Azure Key Vault?

Шифрование и расшифровка методом конвертов

Шифрование методом конверта выполняется следующим образом:

Клиентская библиотека Службы хранилища Azure создает ключ шифрования содержимого (CEK), который является симметричным ключом для однократного использования.
Данные пользователя шифруются с помощью этого ключа CEK.
Ключ CEK, в свою очередь, шифруется с помощью ключа шифрования ключа KEK. KEK определяется идентификатором ключа и может быть парой асимметричных ключей или симметричным ключом. Можно управлять ими локально или сохранить их в Azure Key Vault.

Сама клиентская библиотека Службы хранилища Azure не имеет доступа к ключу KEK. Библиотека вызывает алгоритм шифрования ключа, который обеспечивается хранилищем ключей. Пользователи могут при необходимости использовать настраиваемые поставщики для шифрования и расшифровки ключа.
Затем зашифрованные данные передаются в Хранилище очередей Azure. Упакованный ключ с некоторыми дополнительными метаданными шифрования интерполируется с зашифрованными данными.

Расшифровка методом конверта выполняется следующим образом:

Клиентская библиотека Службы хранилища Azure предполагает, что пользователь управляет KEK локально или в Azure Key Vault. Пользователь может не знать, какой именно ключ использовался для шифрования. Вместо этого достаточно настроить и использовать сопоставитель ключей, который будет распознавать разные идентификаторы ключей.
Клиентская библиотека скачивает зашифрованные данные вместе с данными шифрования, которые хранятся в Службе хранилища Azure.
Затем упакованный ключ CEK распаковывается (расшифровывается) с помощью KEK. Клиентская библиотека не имеет доступа к KEK во время этого процесса. Она только вызывает алгоритм распаковки Azure Key Vault или другого хранилища ключей.
Клиентская библиотека использует CEK для расшифровки зашифрованных пользовательских данных.

Шифрование и расшифровка сообщений

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

Во время шифрования клиентская библиотека создает случайный ключ IV размером 16 байт, случайный ключ CEK размером 32 байта и выполняет конвертное шифрование текста сообщения очереди, используя полученную информацию. Зашифрованный ключ CEK и дополнительные метаданные шифрования добавляются в зашифрованное сообщение очереди. Это измененное сообщение (показано ниже) сохраняется в службе.

<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

Во время расшифровки зашифрованный ключ извлекается из сообщения очереди и расшифровывается. Ключ IV также извлекается из сообщения очереди и используется вместе с расшифрованным ключом для расшифровки данных сообщения очереди. Размер метаданных шифрования очень мал (не более 500 байт). Хотя этот объем учитывается при подсчете максимального значения в 64 КБ для сообщения очереди, им можно пренебречь. Зашифрованное сообщение имеет кодировку Base64, как показано в приведенном выше фрагменте. Это приводит к увеличению размера отправляемого сообщения.

Из-за краткосрочного хранения сообщений в очереди не требуется выполнять их расшифровку и повторное шифрование после обновления до шифрования на стороне клиента версии 2. Все менее безопасные сообщения будут меняться в ходе обычного использования очереди.

Шифрование на стороне клиента и производительность

Учитывайте, что шифрование результатов анализа данных хранилища отрицательно влияет на производительность. При использовании шифрования на стороне клиента в приложении клиентская библиотека должна в безопасном режиме создать CEK и IV, шифровать само содержимое, взаимодействовать с выбранным хранилищем ключей для шифрования ключей, а также форматировать и отправлять дополнительные метаданные. Эти издержки зависят от объема шифруемых данных. Мы рекомендуем клиентам всегда тестировать свои приложения для повышения производительности во время разработки.