Поделиться через

Always Encrypted с безопасными анклавами.

  • Статья

Область применения: SQL Server 2019 (15.x) и более поздних версий — Windows только База данных SQL Azure

Always Encrypted с безопасными анклавами расширяет конфиденциальные вычислительные возможности Always Encrypted, обеспечивая шифрование на месте и расширенные конфиденциальные запросы. Always Encrypted с безопасными анклавами доступны в SQL Server 2019 (15.x) и более поздних версий, а также в Базе данных SQL Azure.

Представлено в База данных SQL Azure в 2015 году и в SQL Server 2016 (13.x), Always Encrypted защищает конфиденциальность конфиденциальных данных от вредоносных программ и пользователей с высоким уровнем привилегий: администраторы баз данных (DBAs), администраторы компьютеров, облачные администраторы или другие пользователи, имеющие законный доступ к экземплярам сервера, оборудованию и т. д., но не должны иметь доступ к некоторым или всем фактическим данным.

Без улучшений, описанных в этой статье, Always Encrypted защищает данные, шифруя их на стороне клиента, и ни в коем случае не допускает отображение данных и соответствующих криптографических ключей в виде открытого текста в ядре СУБД. Таким образом, функциональные возможности для зашифрованных столбцов в базе данных строго ограничены. Единственными операциями, которые ядро СУБД может выполнять с зашифрованными данными, являются сравнения на равенство (доступны только при использовании детерминированного шифрования). Все остальные операции, включая криптографические операции (начальное шифрование данных или смена ключа) и расширенные запросы (например, сопоставления шаблонов), в базе данных не поддерживаются. Пользователям необходимо переместить данные за пределы базы данных, чтобы выполнить эти операции на стороне клиента.

Always Encrypted с безопасными анклавами устраняет эти ограничения, позволяя выполнять некоторые вычисления с данными в виде обычного текста внутри безопасного анклава на стороне сервера. Защищенный анклав — это защищенная область памяти в процессе ядра СУБД. Безопасный анклав представляет собой "черный ящик" на фоне остальной части ядра СУБД и других процессов на главном компьютере. Просмотреть данные или код внутри анклава невозможно, даже с помощью отладчика. Эти свойства делают безопасный анклав доверенной средой выполнения, которая может безопасно обращаться к криптографическим ключам и конфиденциальным данным в виде открытого текста без угрозы конфиденциальности данных.

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

Схема потока данных для Always Encrypted.

При синтаксическом анализе инструкции Transact-SQL, переданной приложением, ядро СУБД определяет, содержит ли инструкция какие-либо операции с зашифрованными данными, для которых требуется использовать безопасный анклав. Для таких инструкций выполняются следующие действия.

  • Драйвер клиента отправляет ключи шифрования столбцов, необходимые для выполнения операций, в безопасный анклав (через защищенный канал) и передает инструкцию для выполнения.

  • При обработке инструкции ядро СУБД делегирует безопасному анклаву криптографические операции и расчеты в зашифрованных столбцах. При необходимости анклав расшифровывает данные и выполняет вычисления в виде открытого текста.

При обработке инструкции данные и ключи шифрования столбцов не отображаются в виде открытого текста в ядре СУБД за пределами безопасного анклава.

Поддерживаемые драйверы клиента

Чтобы использовать Always Encrypted с безопасными анклавами, приложению необходимо использовать драйвер клиента, который поддерживает эту функцию. Настройте приложение и драйвер клиента, чтобы включить вычисления анклава и аттестацию анклава (см. раздел аттестации безопасного анклава ниже). Дополнительные сведения, включая список поддерживаемых клиентских драйверов, см. в разделе Разработка приложений с помощью Always Encrypted.

Поддерживаемые технологии анклава

Always Encrypted поддерживает следующие технологии анклава (или типы анклава):

Тип анклава, доступный для базы данных, зависит от продукта SQL, на котором он размещен (База данных SQL Azure vs. SQL Server) и (в случае База данных SQL Azure) конфигурации базы данных.

  • В SQL Server 2019 (15.x) и более поздних версиях Always Encrypted поддерживает анклавы VBS. (Анклава Intel SGX не поддерживается.)

  • В База данных SQL Azure база данных может использовать анклав Intel SGX или анклав VBS в зависимости от оборудования, на который настроена база данных:

    • Базы данных с использованием конфигурации оборудования серии DC (доступной с моделью приобретения виртуальных ядер) используют анклавы Intel SGX.
    • Базы данных с использованием конфигурации, отличной от серии DC с моделью приобретения виртуальных ядер и базами данных с помощью модели приобретения DTU, можно настроить для использования анклавов VBS.

    Примечание.

    В настоящее время анклавы VBS доступны во всех База данных SQL Azure регионах, кроме Jio India Central.

Дополнительные сведения о защите каждого типа анклава см. в разделе "Вопросы безопасности".

Аттестация безопасного анклава

Аттестация анклава — это механизм глубокой защиты, который может помочь обнаружить атаки, связанные с изменением кода анклава или его среды вредоносными администраторами.

Аттестация анклава позволяет клиентскому приложению установить доверие с безопасным анклавом для базы данных, приложение подключено, прежде чем приложение использует анклав для обработки конфиденциальных данных. Рабочий процесс аттестации проверяет, что анклав является подлинным анклавом VBS или Intel SGX, а код, выполняемый внутри него, является подлинной библиотекой анклавов с подписью Майкрософт для Always Encrypted. Во время аттестации драйвер клиента в приложении и ядро СУБД взаимодействовать с внешней службой аттестации с помощью указанной клиентом конечной точки.

Always Encrypted может использовать одну из двух служб аттестации:

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

Размещение продукта Тип анклава Поддерживаемые протоколы аттестации
SQL Server 2019 (15.x) и более поздних версий Анклавы VBS HGS, без аттестации
База данных SQL Azure Анклавы SGX (базы данных серии DC) Аттестация Microsoft Azure
База данных SQL Azure Анклавы VBS Нет аттестации

Несколько важных моментов для вызова:

  • Для тестирования анклавов VBS в SQL Server 2019 (15.x) и более поздних версий требуется HGS. Кроме того, можно использовать анклавы VBS без аттестации (требуются последние клиентские драйверы).
  • При использовании анклавов Intel SGX (в базах данных серии DC) в База данных SQL Azure аттестация является обязательной и требуется microsoft Аттестация Azure.
  • Анклавы VBS в База данных SQL Azure не поддерживают аттестацию.

Дополнительные сведения см. в разделе:

Терминология

Ключи с поддержкой анклава

В Always Encrypted с безопасными анклавами реализованы ключи с поддержкой анклава:

  • Главный ключ столбца с поддержкой анклава — ключ столбца master , имеющий ENCLAVE_COMPUTATIONS свойство, указанное в объекте метаданных ключа столбца master внутри базы данных. Объект метаданных ключа столбца master также должен содержать допустимую подпись свойств метаданных. Дополнительные сведения см. в статье CREATE COLUMN MASTER KEY (Transact-SQL).
  • Ключ шифрования столбцов с поддержкой анклава — ключ шифрования столбцов, зашифрованный с помощью ключа столбца master с поддержкой анклава. Для вычислений в защищенном анклаве можно использовать только ключи шифрования столбца с поддержкой анклава.

Дополнительные сведения см. в статье Управление ключами в Always Encrypted с безопасными анклавами.

Столбцы с поддержкой анклава

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

Возможности конфиденциальных вычислений для столбцов с поддержкой анклава

Двумя ключевыми преимуществами Always Encrypted с безопасными анклавами являются шифрование на месте и расширенные конфиденциальные запросы.

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

Шифрование на месте позволяет выполнять криптографические операции со столбцами базы данных в безопасном анклава, не перемещая данные за пределы базы данных. Шифрование на месте повышает производительность и надежность криптографических операций. Шифрование на месте можно выполнить с помощью инструкции ALTER TABLE (Transact-SQL).

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

  • Шифрование столбца с открытым текстом с помощью ключа шифрования столбца с поддержкой анклава.
  • Повторное шифрование зашифрованного столбца с поддержкой анклава:
    • смена ключа шифрования столбца и повторное шифрование столбца с помощью нового ключа шифрования столбца с поддержкой анклава;
    • изменение типа шифрования для столбца с поддержкой анклава, например, с детерминированного на случайное.
  • Расшифровка данных, хранящихся в столбце с поддержкой анклава (преобразование столбца в столбец с обычным текстом).

Шифрование на месте поддерживается как для детерминированного, так и для случайного шифрования, при условии, что для ключей шифрования столбца, участвующих в криптографической операции, включена поддержка анклава.

Конфиденциальные запросы

Примечание.

SQL Server 2022 (16.x) добавляет дополнительную поддержку конфиденциальных запросов с помощью операций JOIN, GROUP BY и ORDER BY в зашифрованных столбцах.

Конфиденциальные запросы представляют собой запросы DML, которые содержат операции над столбцами с поддержкой анклава, выполняемые в безопасном анклаве.

В безопасном анклаве поддерживаются следующие операции.

Операция База данных SQL Azure SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Операторы сравнения Поддерживается Поддерживаемые Поддерживается
BETWEEN (Transact-SQL) Поддерживается Поддерживаемые Поддерживается
IN (Transact-SQL) Поддерживается Поддерживаемые Поддерживается
LIKE (Transact-SQL) Поддерживается Поддерживаемые Поддерживается
DISTINCT Поддерживается Поддерживаемые Поддерживается
Соединения Поддерживается Поддерживается Поддерживаются только соединения с вложенным циклом
SELECT — предложение ORDER BY (Transact-SQL) Поддерживается Поддерживается Не поддерживается
SELECT — GROUP BY- Transact-SQL Поддерживается Поддерживается Не поддерживается

Примечание.

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

Уровень совместимости базы данных должен иметь значение SQL Server 2022 (160) или более поздней версии.

В База данных SQL Azure и в SQL Server 2022 (16.x) конфиденциальные запросы, использующие анклавы в столбце символьной строки (char, nchar), требуют, чтобы столбец использовал параметры сортировки точки двоичного кода (_BIN2) или параметры сортировки UTF-8. В SQL Server 2019 (15.x) требуется a_BIN2 сортировки.

Дополнительные сведения см. в разделе "Выполнение инструкций Transact-SQL с помощью безопасных анклавах".

Индексы в столбцах с поддержкой анклава

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

Чтобы индекс столбца, зашифрованного с помощью случайного шифрования, не приводил к утечке конфиденциальных данных, значения ключей в структуре данных индекса (сбалансированное дерево) шифруются и сортируются по значениям в формате открытого текста. Сортировка по значениям в формате открытого текста также полезна при обработке запросов внутри анклава. Когда исполнитель запроса в ядре СУБД использует индекс в зашифрованном столбце для расчетов внутри анклава, он выполняет в этом индексе поиск конкретных значений, хранящихся в данном столбце. Каждый поиск может включать несколько сравнений. Исполнитель запросов делегирует каждое сравнение анклаву, который расшифровывает сохраненное в столбце значение и переданное для сравнения значение ключа индекса, затем сравнивает их в формате обычного текста и возвращает в исполнитель результат этого сравнения.

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

Индекс по столбцу, зашифрованному с помощью детерминированного шифрования, сортируется по значению в формате зашифрованного текста (не открытого текста), независимо от наличия поддержки анклава для этого столбца.

Дополнительные сведения см. в статье Создание и использование индексов в столбцах с помощью Always Encrypted с безопасными анклавами. Общие сведения о работе индексирования в ядре СУБД см. в статье с описанием кластеризованных и некластеризованных индексов.

Восстановление базы данных

Если экземпляр SQL Server завершается ошибкой, его базы данных могут оставаться в состоянии, в котором файлы данных могут содержать некоторые изменения из неполных транзакций. Запущенный экземпляр выполняет процесс восстановления базы данных, который включает откат каждой незавершенной транзакции, найденной в журнале транзакций, что позволяет сохранить целостность базы данных. Если незавершенная транзакция вносила изменения в индекс, такие изменения также должны быть отменены. Например, некоторые ключевые значения в индексе могут потребоваться удалить или повторно включить.

Внимание

Корпорация Майкрософт настоятельно рекомендует вам включить для базы данных Ускоренное восстановление баз данных (ADR), прежде чем создавать первый индекс по столбцу с поддержкой анклава с использованием случайного шифрования. ADR по умолчанию включен в Базе данных SQL Azure, но не в SQL Server 2019 (15.x) и более поздних версий.

Традиционный процесс восстановления базы данных (который соответствует модели восстановления ARIES) предусматривает, что для отмены изменений в индексе SQL Server ожидает, пока приложение не предоставит в анклав ключ шифрования соответствующего столбца, а это может занять много времени. Ускоренное восстановление баз данных (ADR) значительно сокращает число операций отката, которые откладываются из-за отсутствия ключа шифрования столбца во внутреннем кэше анклава. В результате существенно увеличивается доступность базы данных, ведь вероятность блокировки новых транзакций будет минимальной. При включении ADR SQL Server по-прежнему может потребоваться ключ шифрования столбцов для завершения очистки старых версий данных, но это делает это в качестве фоновой задачи, которая не влияет на доступность базы данных или пользовательских транзакций. В журнале ошибок могут отображаться сообщения об ошибках, указывающие на сбой операций очистки из-за отсутствия ключа шифрования столбца.

Вопросы безопасности

К функции Always Encrypted с безопасными анклавами применимы следующие соображения по безопасности.

  • Анклавы VBS помогают защитить данные от атак на виртуальной машине. Однако они не обеспечивают никакой защиты от атак с помощью привилегированных системных учетных записей, исходящих от узла. Анклавы Intel SGX защищают данные от атак, исходящих от гостевой ОС и ос узла.
  • Использование аттестации анклава рекомендуется, если оно доступно для вашей среды, и если вы обеспокоены защитой данных от атак пользователей с доступом администратора на уровне ОС к компьютеру, на котором размещена база данных. При использовании аттестации необходимо убедиться, что служба аттестации и ее конфигурация управляются доверенным администратором. Кроме того, поддерживаемые службы аттестации предлагают различные политики и режимы аттестации, некоторые из которых выполняют минимальную проверку анклава и ее среды, а также предназначены для тестирования и разработки. Внимательно следуйте рекомендациям по работе с конкретной службой аттестации, чтобы гарантировать правильные конфигурации и политики для вашего рабочего развертывания.
  • Шифрование столбца с помощью случайного шифрования с помощью ключа шифрования столбцов с поддержкой анклава может привести к утечке порядка данных, хранящихся в столбце, так как такие столбцы поддерживают сравнение диапазонов. Например, если зашифрованный столбец с информацией о заработной плате сотрудников имеет индекс, злонамеренный администратор базы данных может просканировать индекс для поиска максимального значения заработной платы и определить сотрудника с максимальной заработной платой (если имена сотрудников в этой базе данных не шифруются).
  • Если вы используете Always Encrypted для защиты конфиденциальных данных от несанкционированного доступа к базам данных, не делитесь ключами столбцов или ключами шифрования столбцов master с базами данных. Администратор базы данных может управлять индексами по зашифрованным столбцам без прямого доступа к этим ключам, используя внутренний кэш ключей шифрования столбцов в анклаве.

Рекомендации по обеспечению непрерывности бизнес-процессов, аварийному восстановлению и миграции данных

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

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

Ниже приведены моменты, на которые следует обратить внимание.

  • SQL Server

    • При настройке группы доступности Always On необходимо убедиться, что все экземпляры SQL Server, на которых размещены базы данных в группе доступности, поддерживают Always Encrypted с безопасными анклавами и для них настроены анклавы и аттестация.
    • При восстановлении из файла резервной копии базы данных, которая использует функцию Always Encrypted с безопасными анклавами, на экземпляре SQL Server с настроенным анклавом, операция восстановления пройдет успешно и будут доступны все функции, которые не зависят от анклава. Но все последующие инструкции, которые используют функциональность анклава, завершатся сбоем, а также станут недействительными все индексы для столбцов с поддержкой анклава, которые используют случайное шифрование. Это же относится к ситуации, когда база данных присоединяется с использованием Always Encrypted и безопасных анклавов к экземпляру, на котором не настроен анклав.
    • Если база данных содержит индексы по столбцам с поддержкой анклава и использованием случайного шифрования, не забудьте включить ускорение восстановления базы данных (ADR) для этой базы данных перед созданием ее резервной копии. ADR обеспечит мгновенную доступность базы данных и всех ее индексов сразу после восстановления базы данных. Дополнительные сведения см. в разделе Восстановление базы данных.

  • База данных SQL Azure

    • При настройке активной георепликации убедитесь, что база данных-получатель поддерживает безопасные анклавы, если их поддерживает база данных-источник.

В SQL Server и Базе данных SQL Azure при миграции базы данных с помощью BACPAC-файла необходимо убедиться, что вы удалили все индексы для столбцов с поддержкой анклава и использованием случайного шифрования, прежде чем создавать BACPAC-файл.

Известные ограничения

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

Все остальные ограничения для Always Encrypted, перечисленные в ограничениях , также применяются к Always Encrypted с безопасными анклавами.

Отдельно к Always Encrypted с безопасными анклавами применяются следующие ограничения.

  • Невозможно создание индексов по столбцами с поддержкой анклава с использованием случайного шифрования
  • Столбцы с поддержкой анклава, использующие случайное шифрование, не могут быть столбцами первичного ключа и не могут ссылаться на ограничения внешнего ключа или ограничения уникальных ключей.
  • В SQL Server 2019 (15.x) (это ограничение не применяется к База данных SQL Azure или SQL Server 2022 (16.x)) только вложенные соединения циклов (с использованием индексов, если они доступны) поддерживаются в столбцах с поддержкой анклава с помощью случайного шифрования. Сведения о других различиях между различными продуктами см. в разделе Конфиденциальные запросы.
  • Криптографические операции на месте не могут сочетаться с другими изменениями метаданных столбца, за исключением изменения сортировки на той же кодовой странице и допустимости null. Например, вы не можете зашифровать, повторно зашифровать или расшифровать столбец и изменить тип данных столбца в одной инструкции Transact-SQL ALTER TABLE/ALTER COLUMN. Используйте для этого две отдельных инструкции.
  • Использование ключей с поддержкой анклава для столбцов в таблицах в памяти не поддерживается.
  • Выражения, определяющие вычисляемые столбцы, не могут выполнять вычисления со столбцами с поддержкой анклава, в которых используется случайное шифрование (даже если эти операции есть в списке поддерживаемых операций в раздела Конфиденциальные запросы).
  • Escape-символы не поддерживаются в параметрах оператора LIKE для столбцов с поддержкой анклава, в которых используется случайное шифрование.
  • Запросы с оператором LIKE или оператором сравнения, которые включают параметр запроса с одним из следующих типов данных (которые после шифрования становятся большими объектами), игнорируют индексы и выполняют полное сканирование таблицы.
    • nchar[n] и nvarchar[n], если n больше 3967.
    • char[n], varchar[n], binary[n], varbinary[n], если n больше 7935.
  • Ограничения инструментов:
    • Единственными поддерживаемыми хранилищами ключей для хранения ключей столбцов master с поддержкой анклава являются Хранилище сертификатов Windows и Azure Key Vault.
    • Чтобы активировать криптографическую операцию ALTER TABLE/ALTER COLUMNна месте, необходимо выполнить инструкцию с помощью окна запроса в SSMS или Azure Data Studio или написать собственную программу, которая выдает инструкцию. Set-SqlColumnEncryption В настоящее время командлет в модуле SqlServer PowerShell и мастере Always Encrypted в SQL Server Management Studio не поддерживают шифрование на месте. Переместите данные из базы данных для криптографических операций, даже если ключи шифрования столбцов, используемые для операций, включены в анклава.
  • При восстановлении базы данных с поддержкой анклава VBS необходимо повторно настроить параметр анклава VBS.

Связанный контент