Always Encrypted¶

Always Encrypted — это технология шифрования данных на стороне клиента, реализованная в системах управления базами данных (СУБД) Microsoft SQL Server (начиная с версии 2016) и в базе данных Azure SQL Database. Она позволяет гарантировать, что конфиденциальные данные (например, номера кредитных карт, паспортные данные, медицинские записи) остаются зашифрованными на протяжении всего времени их хранения и обработки, включая моменты передачи по сети, нахождения в оперативной памяти сервера и записи на диск. Ключевой особенностью технологии является то, что ключи шифрования никогда не передаются СУБД, а хранятся и управляются исключительно на стороне клиентского приложения, что делает данные недоступными для администраторов баз данных, операторов облачных платформ и злоумышленников, получивших доступ к серверу.

¶История и предпосылки создания

До появления Always Encrypted основными методами защиты данных в СУБД были шифрование на уровне диска (Transparent Data Encryption, TDE) и шифрование на уровне столбцов с помощью встроенных функций (например, ENCRYPTBYKEY). TDE защищает файлы базы данных от кражи носителя, но не защищает данные от администратора базы данных или от чтения из оперативной памяти сервера. Шифрование на уровне столбцов с помощью функций требует от разработчика явного управления ключами и может быть подвержено утечкам через планы запросов или журналы транзакций.

Always Encrypted была впервые представлена корпорацией Microsoft в 2015 году как часть SQL Server 2016 Community Technology Preview (CTP) и официально выпущена в 2016 году. Основной целью было создание механизма, который бы разделял ответственность за данные: владелец данных (клиент) полностью контролирует ключи шифрования, а СУБД выступает лишь в роли хранилища зашифрованных данных, не имея возможности их расшифровать. В 2017 году, с выходом SQL Server 2017, технология получила поддержку для работы с зашифрованными столбцами в запросах с использованием сравнения на равенство (enclave-based Always Encrypted), что значительно расширило её применимость.

¶Архитектура и принцип работы

¶Двухуровневая система ключей

Always Encrypted использует два типа ключей, образующих иерархию:

1. Колоночный мастер-ключ (Column Master Key, CMK) — это ключ, который используется для шифрования колоночных ключей. Он хранится вне СУБД, в надёжном хранилище, таком как:

• Windows Certificate Store (хранилище сертификатов Windows);
• Azure Key Vault (облачное хранилище ключей);
• аппаратный модуль безопасности (HSM), поддерживающий Cryptography API: Next Generation (CNG);
• другие провайдеры, совместимые с Microsoft Cryptographic API.

1. Колоночный ключ шифрования (Column Encryption Key, CEK) — это симметричный ключ, который непосредственно шифрует данные в конкретном столбце таблицы. CEK, в свою очередь, зашифрован с помощью CMK. Метаданные о зашифрованных столбцах и зашифрованный CEK хранятся в системном каталоге базы данных.

¶Процесс шифрования и дешифрования

1. Шифрование: Клиентское приложение (драйвер ADO.NET или ODBC) получает от СУБД метаданные о том, какие столбцы зашифрованы и каким CEK. Драйвер запрашивает CMK из внешнего хранилища, расшифровывает CEK, а затем шифрует данные перед отправкой на сервер. На сервер поступает уже зашифрованное значение.
2. Дешифрование: При чтении данных сервер возвращает клиенту зашифрованные значения. Драйвер на стороне клиента получает CMK, расшифровывает CEK, а затем расшифровывает сами данные. Сервер никогда не видит ни открытый текст, ни ключи шифрования.

¶Режимы работы

• Детерминированное шифрование (Deterministic encryption): Всегда генерирует одинаковое зашифрованное значение для одного и того же исходного текста. Это позволяет выполнять поиск по равенству (WHERE column = 'value'), группировку (GROUP BY), соединения по равенству (JOIN) и индексацию на зашифрованных столбцах. Однако этот режим уязвим для атак по словарю частот, поэтому рекомендуется использовать его только для столбцов, где уникальность значений высока (например, идентификаторы).
• Рандомизированное шифрование (Randomized encryption): Использует случайное значение при каждом шифровании, что делает одинаковые исходные данные выглядящими как разные зашифрованные строки. Это обеспечивает более высокую криптостойкость, но не позволяет выполнять никакие операции на стороне сервера, кроме поиска по точному совпадению с использованием специальных механизмов (enclave).

¶Enclave-based Always Encrypted (Secure Enclaves)

Начиная с SQL Server 2019 и Azure SQL Database, появилась поддержка безопасных анклавов (secure enclaves). Анклав — это защищённая область памяти процессора (например, Intel SGX или Virtualization-based Security в Windows), в которой сервер может выполнять вычисления над зашифрованными данными, не расшифровывая их за пределами анклава. Это позволяет выполнять не только сравнения на равенство, но и операции сравнения (>, <), LIKE, ORDER BY и даже вычисления над зашифрованными столбцами, сохраняя при этом принцип «нулевого доверия» к серверу. Ключи шифрования передаются в анклав, но не покидают его пределов.

¶Применение

Always Encrypted применяется в сценариях, где требуется высокий уровень защиты конфиденциальных данных от несанкционированного доступа со стороны персонала, обслуживающего базы данных, или от компрометации серверной инфраструктуры. Основные области применения:

• Финансовый сектор: Защита номеров банковских карт (PAN), кодов CVV, данных о счетах и транзакциях от утечек через администраторов или при взломе сервера.
• Здравоохранение: Шифрование медицинских записей, персональных данных пациентов, результатов анализов, что необходимо для соответствия требованиям HIPAA (США) и 152-ФЗ «О персональных данных» (РФ).
• Государственные и облачные сервисы: Использование в Azure SQL Database для выполнения обязательств перед клиентами, что провайдер облачных услуг не имеет доступа к их данным. Это особенно важно при размещении данных в облаке, где физический доступ к серверам контролируется сторонней организацией.
• Разработка приложений: Позволяет разработчикам не беспокоиться о реализации шифрования на уровне приложения, а полагаться на встроенную поддержку в драйверах базы данных.

¶Ограничения и критика

Несмотря на высокий уровень защиты, Always Encrypted имеет ряд ограничений:

• Ограниченная функциональность запросов: В режиме рандомизированного шифрования сервер не может выполнять никакие операции над данными (поиск, сортировку, агрегацию). В режиме детерминированного шифрования — только сравнение на равенство. Режим с анклавами расширяет возможности, но требует специального оборудования (Intel SGX) или виртуализации (VBS).
• Производительность: Шифрование и дешифрование на стороне клиента добавляет задержки. Для больших объёмов данных или частых операций чтения/записи это может быть критично. Использование анклавов также вносит накладные расходы на выполнение запросов.
• Сложность управления ключами: Необходимо организовать безопасное хранение и ротацию CMK. Потеря мастер-ключа делает данные навсегда недоступными.
• Не все типы данных поддерживаются: Некоторые типы данных (например, XML, геопространственные типы) не могут быть зашифрованы с помощью Always Encrypted.
• Отсутствие поддержки в некоторых инструментах: Не все старые версии драйверов и инструментов администрирования (например, SQL Server Management Studio до определённой версии) поддерживают работу с зашифрованными столбцами.

¶Сравнение с другими методами шифрования

¶Интересные факты

• Технология Always Encrypted была разработана в ответ на растущие требования к защите данных в облачных средах, где пользователи не доверяют провайдеру инфраструктуры.
• В 2020 году Microsoft представила поддержку Always Encrypted с анклавами для Azure SQL Database, что позволило выполнять сложные запросы к зашифрованным данным без потери производительности.
• Для работы с Always Encrypted не требуется вносить изменения в существующую схему базы данных — достаточно определить, какие столбцы должны быть зашифрованы, и настроить ключи.

¶Источники

• Microsoft Docs: Always Encrypted (Database Engine)
• Microsoft Docs: Always Encrypted with secure enclaves
• SQL Server 2016: Always Encrypted (Technical Overview)
• B. Beauchemin, D. Rundensteiner, "Pro SQL Server 2016 Administration" (Apress, 2016)