Устранение распространённых проблем при использовании Always Encrypted с безопасными анклавами

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

В этой статье описывается, как определить и устранить распространенные проблемы, которые могут возникнуть при выполнении инструкций Transact-SQL (TSQL) с использованием Always Encrypted с безопасными анклавами.

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

Ошибки при подключении к базе данных

Чтобы выполнить инструкции с помощью безопасного анклава, необходимо включить Always Encrypted, указать протокол аттестации и, если применимо, URL-адрес аттестации для подключения к базе данных, как описано в предварительных требованиях для выполнения инструкций с использованием безопасных анклавах. Однако подключение завершится ошибкой, если указать протокол аттестации, но ваша база данных Azure SQL или целевой экземпляр SQL Server не поддерживают безопасные анклавы или неправильно настроены.

  • Если вы используете базу данных SQL Azure с анклавами Intel SGX, убедитесь, что ваша база данных использует аппаратную конфигурацию серии DC. Дополнительные сведения см. в разделе "Включение анклавов Intel SGX" для базы данных SQL Azure.
  • Если вы используете базу данных Azure SQL с анклавами VBS, убедитесь, что для свойства базы данных preferredEnclaveType установлено значение VBS. Дополнительные сведения см. в разделе "Включение анклавов VBS" для базы данных SQL Azure.
  • Если вы используете SQL Server 2019 (15.x) или более поздней версии, проверьте правильность настройки безопасного анклава для вашего экземпляра. Дополнительные сведения см. в статье Настройка безопасного анклава в SQL Server.

Ошибки аттестации при использовании Microsoft Аттестация Azure

Примечание.

Этот раздел относится только к базе данных SQL Azure с анклавами Intel SGX.

Прежде чем драйвер клиента отправит инструкцию T-SQL на логический сервер Azure SQL для выполнения, драйвер активирует следующий рабочий процесс аттестации анклава с помощью Аттестации Microsoft Azure.

  1. Драйвер клиента передает URL-адрес аттестации, указанный в подключении к базе данных, на логический сервер Azure SQL.
  2. Логический сервер Azure SQL собирает свидетельства об анклаве, среде его размещения и коде, выполняемом в анклаве. Затем сервер отправляет поставщику аттестации запрос на аттестацию, указанный в URL-адресе аттестации.
  3. Поставщик аттестации проверяет свидетельство на соответствие настроенной политике и выдает токен аттестации логическому серверу Azure SQL. Поставщик аттестации подписывает токен аттестации с помощью закрытого ключа.
  4. Логический сервер Azure SQL отправляет токен аттестации драйверу клиента.
  5. Клиент обращается к поставщику аттестации по указанному URL-адресу аттестации для получения открытого ключа и проверяет подпись в токене аттестации.

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

  • Логическому серверу Azure SQL не удается подключиться к поставщику аттестации в службе "Аттестация Azure" (шаг 2 указанного выше рабочего процесса), указанному в URL-адресе аттестации. К вероятным причинам относятся:
    • URL-адрес аттестации неверен или неполон. Дополнительные сведения см. в статье Как определить URL-адрес службы аттестации для политики аттестации.
    • Поставщик аттестации был случайно удалён.
    • Брандмауэр был настроен для поставщика аттестации, но не разрешает доступ к службам Microsoft.
    • Периодическая сетевая ошибка приводит к недоступности поставщика аттестации.
  • Логический сервер SQL Azure не авторизован для отправки запросов аттестации поставщику аттестации. Убедитесь, что администратор поставщика аттестации добавил серверу базы данных роль "Читатель аттестации".
  • Сбой проверки политики аттестации (на шаге 3 приведенного выше рабочего процесса).
    • Наиболее вероятной основной причиной является неверная политика аттестации. Убедитесь, что вы используете политику, рекомендованную Майкрософт. Дополнительные сведения см. в разделе Создание и настройка поставщика аттестации.
    • Проверка политики также может завершиться сбоем в результате нарушения безопасности, компрометирующего серверный анклав.
  • Клиентскому приложению не удается подключиться к поставщику аттестации и получить открытый ключ подписи (на шаге 5). К вероятным причинам относятся:
    • Настройка брандмауэров между приложением и поставщиком аттестации может блокировать подключения. Чтобы устранить неполадки с заблокированным подключением, проверьте, что вы можете подключиться к конечной точке OpenID поставщика аттестации. Например, используйте веб-браузер на компьютере, на котором размещено приложение, чтобы узнать, можно ли подключиться к конечной точке OpenID. Дополнительные сведения см. в разделе Конфигурация метаданных — Get.

Ошибки аттестации при использовании службы защиты узла

Примечание.

Этот раздел относится только к SQL Server 2019 (15.x) и более поздним версиям.

Прежде чем драйвер клиента отправляет инструкцию T-SQL в SQL Server для выполнения, драйвер активирует следующий рабочий процесс аттестации анклава с помощью службы защиты узлов (HGS).

  1. Драйвер клиента вызывает SQL Server для запуска аттестации.
  2. SQL Server собирает свидетельства о своем анклаве, среде, в которой он размещен, и коде, выполняющемся внутри анклава. SQL Server запрашивает сертификат работоспособности у экземпляра HGS, в котором была зарегистрирована машина, размещающая SQL Server. Дополнительные сведения см. в разделе Регистрация компьютера в службе Host Guardian Service.
  3. HGS проверяет доказательства и выдает сертификат работоспособности SQL Server. HGS подписывает сертификат работоспособности своим закрытым ключом.
  4. SQL Server отправляет сертификат работоспособности драйверу клиента.
  5. Драйвер клиента обращается в HGS по URL-адресу аттестации, указанному для подключения к базе данных, чтобы получить открытый ключ HGS. Клиентский драйвер проверяет подпись в сертификате состояния.

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

  • SQL Server не может подключиться к HGS (шаг 2 приведенного выше рабочего процесса) из-за периодических сетевых ошибок. Чтобы устранить проблему подключения, администратор компьютера SQL Server должен проверить, что компьютер может подключиться к компьютеру HGS.
  • Сбой проверки на шаге 3. Чтобы устранить проблему проверки, выполните следующие действия.
    • Администратор компьютера SQL Server должен работать с администратором клиентского приложения, чтобы убедиться, что компьютер SQL Server зарегистрирован в том же экземпляре HGS, что и экземпляр, на который ссылается URL-адрес аттестации на стороне клиента.
    • Администратор компьютера SQL Server должен подтвердить, что компьютер SQL Server может успешно пройти аттестацию, следуя инструкциям из Шаг 5. Подтвердите, что узел может успешно пройти аттестацию.
  • Клиентскому приложению не удается подключиться к HGS и получить открытый ключ подписи (на шаге 5). Скорее всего, причина:
    • Настройка одного из брандмауэров между приложением и поставщиком аттестации может блокировать подключения. Убедитесь, что компьютер, на котором размещается приложение, может подключиться к компьютеру HGS.

Ошибки шифрования на месте

В этом разделе перечислены распространённые ошибки, которые могут возникнуть при использовании ALTER TABLE/ALTER COLUMN для шифрования без переноса данных (в дополнение к ошибкам аттестации, описанным в предыдущих разделах). Дополнительные сведения см. в статье Настройка шифрования столбцов на месте с помощью Always Encrypted с безопасными анклавами.

  • Ключ шифрования столбца, который вы пытаетесь использовать для шифрования, расшифровки или повторного шифрования данных, не является ключом с поддержкой анклава. Дополнительные сведения о предварительных требованиях для шифрования на месте см. в разделе о предварительных требованиях. Сведения о подготовке ключей с поддержкой анклава см. в статье Подготовка ключей с поддержкой анклава.
  • Вы не включили Always Encrypted и вычисления анклава для подключения к базе данных. См. раздел Необходимые условия для выполнения инструкций с использованием безопасных анклавов.
  • Инструкция ALTER TABLE/ALTER COLUMN активирует криптографическую операцию и изменяет тип данных столбца или задает параметры сортировки с кодовой страницей, отличной от текущей кодовой страницы параметров сортировки. Объединение криптографических операций с изменениями на странице типа данных или параметров сортировки не допускается. Чтобы устранить эту проблему, используйте отдельные инструкции: одну инструкцию для изменения типа данных или кодовой страницы параметров сортировки и вторую для шифрования на месте.

Ошибки при выполнении конфиденциальных запросов DML с использованием безопасных анклавов

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

Следующий шаг

Разработка приложений с использованием Always Encrypted с защищенными анклавами

Связанные материалы

  • Last updated on