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

Always Encrypted с защищёнными анклавами.

Применимо к: SQL Server 2019 (15.x) и более поздних версий в Базе данных SQL Windows 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 (доступную в рамках модели приобретения vCore), используют анклавы Intel SGX.
    • Базы данных с использованием конфигурации, отличной от DC-серии с моделью приобретения виртуальных ядер, и базы данных с использованием модели приобретения DTU можно настроить для использования анклавов VBS.

    Note

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

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

Утверждение безопасного анклава

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

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

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

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

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

Несколько важных моментов, на которые стоит обратить внимание:

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

Дополнительные сведения можно найти здесь

Terminology

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

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

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

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

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

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

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

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

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

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

Поддерживаемые на месте криптографические операции:

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

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

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

Note

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

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

Операции, поддерживаемые в безопасных анклавах, :

Operation Azure SQL Database SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Операторы сравнения Supported Supported Supported
МЕЖДУ (Transact-SQL) Supported Supported Supported
IN (Transact-SQL) Supported Supported Supported
КАК (Transact-SQL) Supported Supported Supported
DISTINCT Supported Supported Supported
Joins Supported Supported Поддерживаются только соединения с вложенными циклами
SELECT — клауза ORDER BY (Transact-SQL) Supported Supported Не поддерживается
SELECT — GROUP BY—Transact-SQL Supported Supported Не поддерживается

Note

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

Уровень совместимости базы данных следует установить на 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 с помощью безопасного анклава.

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

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

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

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

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

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

Important

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

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

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

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

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

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

При настройке решения высокой доступности или аварийного восстановления для базы данных с 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, так и в Azure SQL Database с помощью 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. Например, невозможно зашифровать, повторно зашифровать или расшифровать столбец и изменить тип данных столбца в одной ALTER TABLE/ALTER COLUMN инструкции Transact-SQL. Используйте два отдельных утверждения.
  • Использование ключей с поддержкой анклава для столбцов в таблицах в памяти не поддерживается.
  • Выражения, определяющие вычисляемые столбцы, не могут выполнять никаких вычислений для столбцов с поддержкой анклава с помощью случайного шифрования (даже если вычисления являются одними из поддерживаемых операций, перечисленных в конфиденциальных запросах).
  • Escape-символы не поддерживаются в параметрах оператора LIKE в столбцах с поддержкой анклава при использовании случайного шифрования.
  • Запросы с оператором LIKE или оператором сравнения, который имеет параметр запроса, используя один из следующих типов данных (которые становятся большими объектами после шифрования), игнорируют индексы и выполняют сканирование таблиц.
    • nchar[n] и nvarchar[n], если n больше 3967.
    • char[n], , varchar[n], binary[n]varbinary[n]если n больше 7935.
  • Единственными поддерживаемыми хранилищами ключей для хранения ключей столбцов master с поддержкой анклава являются Хранилище сертификатов Windows и Azure Key Vault.
  • При восстановлении базы данных с поддержкой анклава VBS необходимо повторно настроить параметр анклава VBS.

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

  • Last updated on