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

Применимо к:yes Начиная с SQL Server 2019 (15.x) — только Windows База данных SQL Azure Yes

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

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

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

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

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

data flow

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

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

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

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

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

В SQL Server 2019 (15.x) и более поздних версий Always Encrypted вместе с безопасными анклавами использует безопасные анклавы памяти для безопасности на основе визуализации (VBS) (также известные как виртуальный безопасный режим, или анклавы VSM) в Windows.

В Базе данных SQL Azure Always Encrypted с безопасными анклавами использует анклавы Intel Software Guard Extensions (Intel SGX). Intel SGX — это аппаратная технология доверенной среды выполнения, поддерживаемая базами данных, которые используют конфигурацию оборудования серии DC.

SQL Server 2022

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

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

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

Процесс проверки анклава называется аттестацией анклава. В нем задействованы драйвер клиента в приложении и ядро СУБД, обращающееся к внешней службе аттестации. Особенности процесса аттестации зависят от типа анклава (VBS или SGX) и службы аттестации.

Процесс аттестации для безопасных анклавов VBS в SQL Server 2019 (15.x) и более поздних версий — это аттестация среды выполнения System Guard в Защитнике Windows, для которой в качестве службы аттестации требуется служба защитника узлов (HGS).

Для аттестации анклавов Intel SGX в Базе данных SQL Azure требуется служба Аттестация Microsoft Azure.

Примечание

SQL Server 2019 (15.x) и более поздних версий не поддерживает Аттестацию Microsoft Azure. Служба защитника узлов — это единственное решение аттестации, поддерживаемое для анклавов VBS в SQL Server 2019 (15.x) и более поздних версий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

При настройке решения высокой доступности или аварийного восстановления для базы данных с помощью 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) для столбцов с поддержкой анклавов, в которых используется случайное шифрование, поддерживаются только соединения с вложенным циклом (с применением индексов, если они доступны). Сведения о других различиях между различными продуктами см. в разделе Конфиденциальные запросы.
  • Криптографические операции на месте нельзя сочетать с другими изменениями метаданных столбцов, за исключением изменения параметров сортировки с сохранением значений кодовой страницы и допустимости значений 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.
  • Ограничения инструментов:
    • Единственные поддерживаемые хранилища ключей для хранения главных ключей столбцов с поддержкой анклава — хранилище сертификатов Windows и Azure Key Vault.
    • Не поддерживается импорт и экспорт баз данных, которые содержат ключи с поддержкой анклавов.
    • Для запуска криптографической операции на месте с помощью инструкции ALTER TABLE/ALTER COLUMN необходимо запустить инструкцию в окне запроса в среде SSMS или написать собственную программу, которая выполняет инструкцию. Командлет Set-SqlColumnEncryption в модуле SqlServer PowerShell и мастер Always Encrypted в SQL Server Management Studio еще не поддерживают шифрование на месте. Сейчас обе эти программы перемещают данные из базы данных для криптографических операций, даже если ключи шифрования столбцов, используемые для операций, поддерживают анклавы.

Дальнейшие действия

См. также раздел