Шифрование столбца данных - sql server & azure synapse analytics & azure sql database & sql managed instance

Механизмы шифрования

SQL Server поддерживает следующие механизмы шифрования:

функции Transact-SQL
асимметричные ключи;
симметричные ключи;
Сертификаты
прозрачное шифрование данных.

Функции Transact-SQL

Отдельные элементы можно зашифровать по мере их вставки или обновления с помощью функций Transact-SQL. Дополнительные сведения см. в статьях ENCRYPTBYPASSPHRASE (Transact-SQL) и DECRYPTBYPASSPHRASE (Transact-SQL).

Сертификаты

Сертификат открытого ключа, или просто сертификат, представляет собой подписанную цифровой подписью инструкцию, которая связывает значение открытого ключа с идентификатором пользователя, устройства или службы, имеющей соответствующий закрытый ключ. Сертификаты поставляются и подписываются центром сертификации (certification authority, CA). Сущность, получающая сертификат от центра сертификации, является субъектом этого сертификата. Как правило, сертификаты содержат следующие сведения.

Открытый ключ субъекта.
Идентификационные данные субъекта, например имя и адрес электронной почты.
Срок действия, то есть интервал времени, на протяжении которого сертификат будет считаться действительным.

Сертификат действителен только в течение указанного в нем периода, который задается в каждом сертификате при помощи дат ( Valid From и Valid To ), определяющих начало и окончание срока действия. По истечении срока действия сертификата его субъект должен запросить новый сертификат.
Идентификационные данные поставщика сертификата.
Цифровая подпись поставщика.

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

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

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

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

Самостоятельно подписанные сертификаты, созданные SQL Server , соответствуют стандарту X.509 и поддерживают поля X.509 v1.

Асимметричные ключи

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

симметричные ключи;

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

прозрачное шифрование данных.

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

Проверка TDE

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

Чтобы обеспечить более полный контроль над проверкой шифрования, SQL Server 2019 (15.x) вводит сканирование TDE, которое имеет синтаксис приостановки и возобновления

Вы можете приостановить сканирование, когда рабочая нагрузка в системе будет очень высокой или в течение критически важного для бизнеса периода, а затем возобновить сканирование позже

Чтобы приостановить сканирование шифрования TDE, используйте следующий синтаксис:

Подобным образом вы можете возобновить сканирование шифрования TDE с помощью следующего синтаксиса:

Столбец encryption_scan_state добавлен в динамическое административное представление. Он показывает текущее состояние сканирования шифрования. Кроме того, появился столбец encryption_scan_modify_date, который содержит дату и время последнего изменения состояния сканирования шифрования.

Если экземпляр SQL Server перезапускается во время приостановки проверки шифрования, во время запуска в журнал ошибок записывается сообщение. Сообщение указывает, что существующее сканирование приостановлено.

Важно!

Функция приостановки и возобновления TDE сейчас недоступна в Базе данных SQL Azure, Управляемом экземпляре SQL Azure и Azure Synapse Analytics.

Смена ключа шифрования столбца

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

Ключ шифрования столбца можно сменить в двух режимах — вне сети или в сети. Первый способ быстрее, но приложения не смогут записывать данные в затронутые таблицы. Второй способ, вероятно, займет больше времени, но вы сможете ограничить интервал времени, в течение которого затронутые таблицы будут недоступными для приложений. Дополнительные сведения см. в статье «Настройка шифрования столбцов с помощью Always Encrypted с помощью PowerShell и Set-SqlColumnEncryption».

Задача	Статья	Доступ к ключам с открытым текстом или хранилищу ключей	Доступ к базе данных
Шаг 1. Запуск среды PowerShell и импорт модуля SqlServer.		Нет	Нет
Шаг 2. Соединение с сервером и базой данных.		Нет	Да
Шаг 3. Проверка подлинности в Azure, если главный ключ столбца (защищающий ключ шифрования столбца, подлежащий смене) хранится в хранилище ключей или в управляемом модуле HSM в Azure Key Vault.	Add-SqlAzureAuthenticationContext	Да	Нет
Шаг 4. Создание ключа шифрования столбца, его шифрование с помощью главного ключа столбца и создание метаданных ключа шифрования столбца в базе данных.	New-SqlColumnEncryptionKeyПримечание. Используйте командлет, который внутренним образом создает и шифрует ключ шифрования столбца.На самом деле для создания метаданных ключа командлет выполняет инструкцию CREATE COLUMN ENCRYPTION KEY (Transact-SQL) .	Да	Да
Шаг 5. Поиск всех столбцов, зашифрованных с помощью старого ключа шифрования столбца.	Учебник по программированию управляющих объектов SQL Server (SMO)	Нет	Да
Шаг 6. Создание объекта SqlColumnEncryptionSettings для каждого затронутого столбца. SqlColumnEncryptionSettings — это объект, который существует в памяти (PowerShell). Он определяет целевую схему шифрования столбца. В этом случае объект должен указывать, что затронутый столбец следует зашифровать с помощью нового ключа шифрования столбца.	New-SqlColumnEncryptionSettings	нет	Нет
Шаг 7. Повторное шифрование столбцов, определенных на шаге 5, с помощью нового ключа шифрования столбца.	Set-SqlColumnEncryptionПримечание. Выполнение этого шага может занять длительное время. Приложения не будут иметь доступ к таблицам во время выполнения операции или ее части в зависимости от выбранного режима (в сети или вне сети).	Да	Да
Шаг 8. Удаление метаданных для старого ключа шифрования столбца.	Remove-SqlColumnEncryptionKey	Нет	Да

Пример: смена ключа шифрования столбца

В приведенном ниже скрипте демонстрируется смена ключа шифрования столбца. В скрипте предполагается, что целевая база данных содержит несколько столбцов, зашифрованных с помощью ключа шифрования CEK1 (подлежащего смене), который защищен главным ключом столбца CMK1 (главный ключ столбца не хранится в Azure Key Vault).

Дополнительные сведения

Шифрование пакетов входа и шифрование пакетов данных

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

SQL Server самозаверяющих сертификатов

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

При использовании самозаверяющего сертификата SQL Server записывает в журнал ошибок следующее сообщение:

SQL Server 2016 (13.x) и более ранних версиях используется алгоритм SHA1. Однако алгоритм SHA1 и многие более старые алгоритмы стали устаревшими, начиная с SQL Server 2016 г. (13.x). Дополнительные сведения см. в статье Устаревшие функции ядра СУБД в SQL Server 2016 г.

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

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

Скрипт PowerShell для создания самозаверяющего сертификата для SQL Server

Следующий фрагмент кода можно использовать для создания самозаверяющего сертификата на компьютере под управлением SQL Server. Сертификат соответствует требованиям к шифрованию для изолированного экземпляра SQL Server и сохраняется в хранилище сертификатов локального компьютера (PowerShell должен быть запущен от имени администратора):

Смена главного ключа столбца без разделения ролей

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

Задача	Статья	Доступ к ключам с открытым текстом или хранилищу ключей	Доступ к базе данных
Шаг 1. Создание нового главного ключа столбца в хранилище ключей.Примечание. Этот шаг не поддерживается в модуле SqlServer PowerShell. Для выполнения этой задачи из командной строки используйте средства, поддерживаемые выбранным хранилищем ключей.	Создание и хранение главных ключей столбцов для Always Encrypted	Да	Нет
Шаг 2. Запуск среды PowerShell и импорт модуля SqlServer.		Нет	Нет
Шаг 3. Соединение с сервером и базой данных.		Нет	Да
Шаг 4. Создание объекта SqlColumnMasterKeySettings, содержащего сведения о расположении нового главного ключа столбца. SqlColumnMasterKeySettings — это объект, который существует в памяти (PowerShell). Для его создания используйте командлет, поддерживаемый хранилищем ключей.	New-SqlAzureKeyVaultColumnMasterKeySettingsNew-SqlCertificateStoreColumnMasterKeySettingsNew-SqlCngColumnMasterKeySettingsNew-SqlCspColumnMasterKeySettings	нет	Нет
Шаг 5. Создание метаданных о новом главном ключе столбца в базе данных.	New-SqlColumnMasterKeyПримечание. На самом деле для создания метаданных ключа командлет выполняет инструкцию CREATE COLUMN MASTER KEY (Transact-SQL) .	Нет	Да
Шаг 6. Проверка подлинности в Azure, если текущий или новый главный ключ столбца хранится в хранилище ключей или в управляемом модуле HSM в Azure Key Vault.	Add-SqlAzureAuthenticationContext	Да	Нет
Шаг 7. Запуск процесса смены путем шифрования каждого ключа шифрования столбца, который в данный момент защищен с помощью старого главного ключа столбца, с использованием нового главного ключа столбца. После выполнения этого шага каждый затронутый ключ шифрования столбца (связанный со старым сменяемым главным ключом столбца) шифруется с помощью старого и нового главных ключей и имеет два зашифрованных значения в метаданных базы данных.	Invoke-SqlColumnMasterKeyRotation	Да	Да
Шаг 8. Работа с администраторами всех приложений, выполняющих запросы к зашифрованным столбцам в базе данных (и защищенных с помощью старого главного ключа столбца), по обеспечению доступа приложений к новому главному ключу столбца.	Создание и хранение главных ключей столбцов (постоянное шифрование)	Да	Нет
Шаг 9. Завершение процесса смены.Примечание. Перед выполнением этого шага убедитесь, что все приложения, отправляющие запросы к зашифрованным столбцам, которые защищены с помощью старого главного ключа столбца, настроены для использования нового главного ключа столбца. В случае преждевременного выполнения этого шага некоторые приложения не смогут расшифровывать данные. Завершите процесс смены, удалив из базы данных зашифрованные значения, созданные с помощью старого главного ключа столбца. При этом будет удалена связь между старым главным ключом столбца и защищаемыми ими ключами шифрования столбцов.	Complete-SqlColumnMasterKeyRotation	Нет	Да
Шаг 10. Удаление метаданных из старого главного ключа столбца.	Remove-SqlColumnMasterKey	Нет	Да

Примечание

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

Смена главного ключа столбца без разделения ролей (пример с сертификатом Windows)

Приведенный ниже скрипт является законченным примером замены существующего главного ключа столбца (CMK1) на новый главный ключ столбца (CMK2).

Применения ключей шифрования SQL Server и базы данных

SQL Server имеет два первичных приложения для ключей: главный ключ службы (SMK), созданный и для экземпляра SQL Server, а также главный ключ базы данных (DMK), используемый для базы данных.

Главный ключ службы

Главный ключ службы является корнем иерархии шифрования SQL Server. SmK создается автоматически при первом запуске экземпляра SQL Server и используется для шифрования пароля связанного сервера, учетных данных и главного ключа базы данных в каждой базе данных. Главный ключ службы шифруется с помощью ключа локального компьютера и API-интерфейса защиты данных Windows. DPAPI использует ключ, производный от учетных данных Windows учетной записи службы SQL Server и учетных данных компьютера. Главный ключ службы может быть расшифрован лишь той учетной записью службы, под которой он был создан, или участником, имеющим доступ к учетным данным компьютера.

Главный ключ службы может быть открыт только учетной записью службы Windows, под которой он был создан, либо участником, имеющим доступ к имени и паролю учетной записи службы.

SQL Server использует алгоритм шифрования AES для защиты главного ключа службы (SMK) и главного ключа базы данных (DMK). AES — это новый алгоритм шифрования, отличный от алгоритма 3DES, используемого в более ранних версиях. После обновления экземпляра ядра СУБД до SQL Server SMK и DMK необходимо повторно создать, чтобы обновить главные ключи до AES. Дополнительные сведения о повторном создании SMK см. в разделе ALTER SERVICE MASTER KEY (Transact-SQL) и ALTER MASTER KEY (Transact-SQL).

Главный ключ базы данных

Главный ключ базы данных — это симметричный ключ, который применяется для защиты закрытых ключей сертификатов и асимметричный ключей, которые есть в базе данных. Его также можно использовать для шифрования данных, но он имеет ограничения длины, которые делают его менее практичным для данных, чем использование асимметричного ключа. Чтобы разрешить автоматическое шифрование главного ключа базы данных, копия этого ключа зашифровывается с помощью главного ключа службы. Ключ хранится как в базе данных, где используется ключ, так и в системной базе данных master .

Копия, которая хранится в базе данных master , автоматически обновляется при каждом изменении главного ключа. Но это поведение по умолчанию может быть изменено с помощью параметра DROP ENCRYPTION BY SERVICE MASTER KEY инструкции ALTER MASTER KEY . Главный ключ базы данных, который не зашифрован с помощью главного ключа службы, следует открывать с помощью инструкции OPEN MASTER KEY и пароля.

Шаг 7. Выполнение полнофункциональных запросов к зашифрованным столбцам

Теперь можно выполнять полнофункциональные запросы к зашифрованным столбцам. Некоторая обработка запросов будет выполняться в анклаве на стороне сервера.

В экземпляре SSMS с включенной функцией Always Encrypted убедитесь, что включена параметризация для Always Encrypted.
1. Выберите пункт Инструменты в главном меню SSMS.
2. Выберите Параметры.
3. Выберите Выполнение запроса>SQL Server>Дополнительно.
4. Убедитесь, что установлен флажок Включить параметризацию для Always Encrypted.
5. Щелкните ОК.
Откройте новое окно запроса, а затем вставьте и выполните приведенный ниже запрос. Запрос должен возвратить соответствующие заданным условиям поиска значения и строки в виде открытого текста.
Попробуйте выполнить тот же запрос еще раз в экземпляре SSMS с отключенной функцией Always Encrypted и запишите код возникшей ошибки.

Шаг 2. Настройка компьютера SQL Server как защищенного узла

На этом шаге выполняется настройка компьютера SQL Server как защищенного узла, зарегистрированного в HGS с помощью аттестации ключа узла.

Предупреждение

Аттестация узла ключа считается менее строгим режимом аттестации. При возможности для рабочих сред следует использовать аттестацию доверенного платформенного модуля (TPM). Дополнительные сведения см. в статье .

Войдите на компьютер SQL Server с правами администратора, откройте консоль Windows PowerShell с повышенными привилегиями и найдите имя компьютера, указанное в переменной computername.
Установите компонент Guarded Host (Защищенный узел). При этом будет также установлена технология Hyper-V (если она еще не установлена).
При появлении запроса на завершение установки Hyper-V перезагрузите компьютер SQL Server.
Если SQL Server работает на виртуальной машине или на физическом компьютере, который не поддерживает безопасную загрузку UEFI или не имеет блок IOMMU, вам нужно удалить требование VBS для функций безопасности платформы.
1. Удалите требование безопасной загрузки и IOMMU, выполнив следующую команду на своем компьютере SQL Server в консоли PowerShell, запущенной с повышенными правами.
2. Снова перезагрузите компьютер SQL Server, чтобы технология VBS начала работать со сниженными требованиями.
Снова войдите на компьютер SQL Server с правами администратора, откройте консоль Windows PowerShell с повышенными привилегиями, создайте уникальный ключ узла и экспортируйте полученный открытый ключ в файл.
Скопируйте вручную файл ключа узла, созданный на предыдущем шаге, на компьютер HGS. В следующих инструкциях подразумевается, что файл имеет имя , и он скопирован на рабочий стол компьютера HGS.
На компьютере HGS откройте консоль Windows PowerShell с повышенными привилегиями и зарегистрируйте ключ узла вашего компьютера SQL Server с помощью HGS:
На компьютере SQL Server в консоли Windows PowerShell с повышенными привилегиями выполните следующую команду, чтобы сообщить компьютеру SQL Server, где должна выполняться аттестация. Обязательно укажите IP-адрес или DNS-имя своего компьютера HGS в качестве обоих значений адреса.

Результат приведенной выше команды должен показывать, что аттестация пройдена (AttestationStatus = Passed).

Если возникла ошибка HostUnreachable, это означает, что компьютер SQL Server не может обмениваться данными с HGS. Проверьте связь с компьютером HGS с помощью команды ping.

Ошибка UnauthorizedHost указывает, что открытый ключ не был зарегистрирован на сервере HGS. Повторите шаги 5 и 6, чтобы устранить эту ошибку.

Если все эти действия не помогают, запустите командлет Remove-HgsClientHostKey и повторите шаги 4–7.

Механизмы шифрования

SQL Server поддерживает следующие механизмы шифрования:

функции Transact-SQL
асимметричные ключи;
симметричные ключи;
Сертификаты
прозрачное шифрование данных.

Функции Transact-SQL

Сертификаты

Открытый ключ субъекта.
Идентификационные данные субъекта, например имя и адрес электронной почты.
Срок действия, то есть интервал времени, на протяжении которого сертификат будет считаться действительным.

Сертификат действителен только в течение указанного в нем периода, который задается в каждом сертификате при помощи дат ( Valid From и Valid To ), определяющих начало и окончание срока действия. По истечении срока действия сертификата его субъект должен запросить новый сертификат.
Идентификационные данные поставщика сертификата.
Цифровая подпись поставщика.

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

Асимметричные ключи

симметричные ключи;

прозрачное шифрование данных.

Предварительные требования

Чтобы начать работу с Always Encrypted с безопасными анклавами, потребуется по крайней мере два компьютера (это могут быть виртуальные машины):

Компьютер с SQL Server для размещения SQL Server и SSMS.
компьютер HGS для запуска службы защиты узла, необходимой для аттестации анклава.

Требования к компьютеру с SQL Server

SQL Server 2019 (15.x) или более поздняя версия.
Windows 10, версия 1809 или более поздняя — Корпоративная, Windows 11 или более поздней версии — Корпоративная, Windows Server 2019 или более поздней версии — выпуск Datacenter. Другие выпуски Windows 10/11 и Windows Server не поддерживают аттестацию с помощью HGS.
Поддержка ЦП для технологий виртуализации:
- Intel VT-x с Extended Page Tables.
- AMD-V с Rapid Virtualization Indexing.
- Если вы запускаете SQL Server на виртуальной машине:
  - В Azure используйте (рекомендуется) или размер виртуальной машины 1-го поколения с включенной вложенной виртуализацией. Изучите документацию по размерам отдельных виртуальных машин, чтобы определить, какие размеры виртуальных машин 1-го поколения поддерживают вложенную виртуализацию.
  - В Hyper-V 2016 или более поздней версии (за пределами Azure) обязательно используйте виртуальную машину 2-го поколения (рекомендуется) или виртуальную машину 1-го поколения со вложенной виртуализацией. Дополнительные сведения см. в статьях о том, как выбрать поколение для виртуальной машины в Hyper-V, и о .
  - В VMware vSphere 6.7 или более поздней версии включите для виртуальной машины поддержку безопасности на основе виртуализации, как описано в документации VMware.
  - Другие низкоуровневые оболочки и общедоступные облака могут поддерживать возможности вложенной виртуализации, позволяющие использовать Always Encrypted с анклавами VBS. Просмотрите сведения о совместимости и инструкции по настройке в документации по своему решению для виртуализации.
SQL Server Management Studio (SSMS) версии не ниже 18.3.

Кроме того, можно установить SSMS на другом компьютере.

Предупреждение

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

Требования к компьютеру с HGS

Windows Server 2019, выпуск Standard или Datacenter
2 процессора
8 ГБ ОЗУ
Хранилище 100 ГБ

Примечание

Компьютер HGS не должен быть присоединен к домену перед началом работы.

Шаг 3. Настройка Always Encrypted с безопасными анклавами в SQL Server

На этом шаге выполняется включение функциональности Always Encrypted с использованием анклавов в экземпляре SQL Server.

От имени системного администратора с помощью SSMS подключитесь к экземпляру SQL Server без включенной функции Always Encrypted для подключения к базе данных.
1. Запустите SSMS.
2. В диалоговом окне Соединение с сервером укажите имя сервера, выберите метод аутентификации и введите учетные данные.
3. Нажмите Параметры >> и выберите вкладку Always Encrypted.
4. Убедитесь, что флажок Включить Always Encrypted (шифрование столбцов)не установлен.
5. Выберите Подключиться.
Откройте новое окно запроса и выполните инструкции ниже, чтобы задать для типа безопасного анклава значение «Безопасность на базе виртуализации (VBS)».
Перезапустите экземпляр SQL Server, чтобы предыдущее изменение вступило в силу. Можно перезапустить этот экземпляр в SSMS, щелкнув его правой кнопкой мыши в обозревателе объектов и выбрав «Перезапуск». После перезагрузки экземпляра снова подключитесь к нему.
Убедитесь, что безопасный анклав загружен, выполнив следующий запрос:

По результатам запроса должен возвращаться следующий результат:

name value value_in_use

column encryption enclave type (тип анклава для шифрования столбцов) 1 1

name	value	value_in_use
column encryption enclave type (тип анклава для шифрования столбцов)	1	1

Во время или после установки SQL Server

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

учетные записи служб;

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

Режим проверки подлинности

Требует проверку подлинности Windows для подключений к SQL Server.
Используйте проверку подлинности Kerberos. Дополнительные сведения см. в разделе Регистрация имени участника-службы для соединений Kerberos.

Надежные пароли

Всегда назначайте надежный пароль для учетной записи sa .
Всегда включайте проверку политики паролей для определения надежности и срока действия пароля.
Для всех имен входа SQL Server используйте только надежные пароли.

Важно!

Во время установки SQL Server Express для группы BUILTIN\Users добавляется имя входа. Благодаря этому все прошедшие проверку подлинности пользователи компьютера получают доступ к экземпляру SQL Server Express как члены роли public. Имя входа группы BUILTIN\Users можно удалить, чтобы ограничить доступ к компоненту Компонент Database Engine только пользователям компьютера, у которых есть отдельные имена входа, или членам других групп Windows с именами входа.