Шифрование на стороне клиента для очередей
Клиентские библиотеки Хранилища очередей 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. |
Кроме того, корпорация Майкрософт рекомендует выполнить следующие действия для защиты данных:
- Настройте учетные записи хранения для использования частных конечных точек для защиты всего трафика между виртуальной сетью и учетной записью хранения через приватный канал. Дополнительные сведения см. в статье Использование частных конечных точек для службы хранилища 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, шифровать само содержимое, взаимодействовать с выбранным хранилищем ключей для шифрования ключей, а также форматировать и отправлять дополнительные метаданные. Эти издержки зависят от объема шифруемых данных. Мы рекомендуем клиентам всегда тестировать свои приложения для повышения производительности во время разработки.