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 защищает конфиденциальные данные от вредоносных программ и неавторизованных пользователей, обладающих очень высокими правами доступа: администраторов баз данных, администраторов компьютеров, администраторов облака или других пользователей, у которых есть санкционированный доступ к экземплярам сервера, оборудованию и т. д., но эти пользователи не должны иметь доступ к некоторым или всем фактическим данным.

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

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

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

поток данных

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

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

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

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

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

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

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

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

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

Процесс проверки анклава называется аттестацией анклава. В нем задействованы драйвер клиента в приложении и Компонент Database Engine, обращающийся к внешней службе аттестации. Особенности процесса аттестации зависят от типа анклава (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).

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

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

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

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

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

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

Операция SQL Server 2019 (15.x) База данных SQL Azure
Операторы сравнения Поддерживается Поддерживается
Оператор 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, использующие безопасные анклавы, выполнялись быстрее.

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

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

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

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

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

Если происходит сбой экземпляра 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) для столбцов с поддержкой анклавов, в которых используется случайное шифрование, поддерживаются только вложенные циклы соединения (с использованием индексов, если они доступны). Сведения о других различиях между различными продуктами см. в разделе Конфиденциальные запросы.
  • Криптографические операции на месте нельзя сочетать с другими изменениями метаданных столбцов, за исключением изменения параметров сортировки с сохранением значений кодовой страницы и допустимости значений 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 еще не поддерживают шифрование на месте. Сейчас обе эти программы перемещают данные из базы данных для криптографических операций, даже если ключи шифрования столбцов, используемые для операций, поддерживают анклавы.

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

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