Настройка шифрования столбцов с помощью мастера always encrypted

Настройка безопасности компонента Database Engine

Настройку безопасности компонента Database Engine можно выполнить одним из следующих способов:

с помощью среды управления Management Studio сервера SQL Server;
используя инструкции языка Transact-SQL.

Эти два метода рассматриваются в последующих подразделах.

Управление безопасностью с помощью среды Management Studio

Чтобы с помощью среды Management Studio создать новое регистрационное имя, разверните в обозревателе объектов Object Explorer узел сервера, затем разверните папку «Security», в этой папке щелкните правой кнопкой папку «Logins» и в контекстном меню выберите опцию New Login. Откроется диалоговое окно Login — New:

Первым делом нужно решить, какой способ аутентификации применять: Windows или SQL Server. В случае выбора аутентификации Windows, в качестве регистрационного имени (Login name) необходимо указать действительное имя пользователя Windows в форме domain\user_name (домен\имя_пользователя). А если выбрана аутентификация SQL Server, необходимо ввести новое регистрационное имя (Login name) и соответствующий пароль (Password). Можно также указать базу данных и язык по умолчанию. База данных по умолчанию — это база данных, к которой пользователь автоматически подключается сразу же после входа в компонент Database Engine. Выполнив все эти действия, пользователь может входить в систему под этой новой учетной записью.

Управление безопасностью посредством инструкций Transact-SQL

Для управления безопасностью компонента Database Engine применяются три инструкции языка Transact-SQL: CREATE LOGIN, ALTER LOGIN и DROP LOGIN. Инструкция CREATE LOGIN создает новое регистрационное имя входа в SQL Server. Синтаксис этой инструкции следующий:



Соглашения по синтаксису

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

В списке option_list1 указывается несколько параметров, наиболее важным из которых является параметр password, который задает пароль для данного регистрационного имени. (Другие возможные параметры — DEFAULT_DATABASE, DEFAULT_LANGUAGE и CHECK_EXPIRATION.)

Как видно из синтаксиса инструкции CREATE LOGIN, предложение FROM может содержать один из следующих параметров:

Параметр WINDOWS: Указывает, что данное регистрационное имя соотносится с существующей учетной записью пользователя Window. Этот параметр можно указать с другими подпараметрами, такими как default_database и default_language.
Параметр CERTIFICATE: Задает имя сертификата для привязки к данному регистрационному имени.
Параметр ASYMMETRIC KEY: Задает имя асимметричного ключа для привязки к данному регистрационному имени. (Сертификат и асимметричный ключ уже должны присутствовать в базе данных master.)

В примерах ниже показано создание разных форм регистрационного имени. В следующем примере создается регистрационное имя «Vasya» с паролем «12345!»:

В примере ниже создается регистрационное имя «Vasya», которое сопоставляется с учетной записью пользователя Windows с таким же самым именем пользователя:

Для конкретной системной среды нужно должным образом изменить имя компьютера и имя пользователя (в примере выше это ProfessorWeb и vasya соответственно).

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

Наконец, инструкция DROP LOGIN применяется для удаления существующего регистрационного имени. Однако регистрационное имя, которое ссылается (владеет) на другие объекты, удалить нельзя.

Операции с ключами

Key Vault, включая управляемый HSM, поддерживает следующие операции с объектами ключей:

Создание. Позволяет клиентам создавать ключи в Key Vault. Значение ключа создается в Key Vault и хранится в нем. Оно не выдается клиенту. В Key Vault можно создать асимметричные ключи.
Import: Позволяет клиентам импортировать имеющиеся ключи в Key Vault. В Key Vault можно импортировать асимметричные ключи с помощью нескольких различных способов упаковки внутри конструкции JWK.
Обновление. Позволяет клиентам с достаточными разрешениями изменять метаданные (атрибуты ключей), связанные с ключами, сохраненными ранее в Key Vault.
Удалить. Позволяет клиентам с достаточными разрешениями удалять ключи из Key Vault.
Вывод списка. Позволяет клиентам выводить полный список ключей в определенном хранилище ключей.
Вывод списка версий. Позволяет клиентам выводить список всех версий указанного ключа в определенном хранилище ключей.
Получение. Позволяет клиентам извлекать открытые части указанного ключа из Key Vault.
Архивация. Экспорт ключей в защищенной форме.
Восстановление. Импорт ранее заархивированного ключа.

Дополнительные сведения о работе с ключами см. в справочнике по работе с Azure Key Vault с помощью REST API.

После создания ключа в Key Vault с его использованием можно выполнять следующие криптографические операции:

Подпись и проверка. Строго говоря, эта операция подписи и проверки хэша, так как Key Vault не поддерживает хэширование содержимого для создания подписи. Приложения должны хэшировать данные для подписи локально, а затем запрашивать подпись хэша в Key Vault. Проверка подписанных хэшей поддерживается в качестве удобного механизма для приложений, у которых нет доступа к материалам открытого ключа. Для максимальной производительности приложений операции VERIFY следует выполнять локально.
Шифрование и упаковка ключа. Ключ, сохраненный в Key Vault, можно использовать для защиты другого ключа, как правило, симметричного ключа шифрования содержимого (CEK). Если ключ в Azure Key Vault асимметричен, используется шифрование ключа. Например RSA-OAEP, а операции WRAPKEY/UNWRAPKEY эквивалентны операциям ENCRYPT/DECRYPT. Если ключ в Azure Key Vault симметричен, применяется упаковка ключа. Например, AES-KW. Операция WRAPKEY поддерживается в качестве удобного механизма для приложений, у которых нет доступа к материалам открытого ключа. Для оптимизации производительности приложений рекомендуется выполнять операции WRAPKEY локально.
Шифрование и расшифровка. Ключ, хранимый в Key Vault, можно использовать для шифрования или расшифровки одного блока данных, размер которого определяется типом ключа и выбранным алгоритмом шифрования. Операция шифрования предоставляется в качестве удобного механизма для приложений, у которых нет доступа к материалам открытого ключа. Для оптимизации производительности приложений операции ENCRYPT нужно выполнять локально.

Хотя операции WRAPKEY и UNWRAPKEY с использованием асимметричных ключей могут показаться излишними (так как они эквивалентны операции ENCRYPT и DECRYPT), важно использовать различные операции. Это обеспечивает разделение семантики и авторизации этих операций, а также целостность в случаях, когда служба поддерживает другие типы ключей

Azure Key Vault не поддерживает операции EXPORT. Как только ключ подготовлен в системе, нельзя извлечь его или изменить его материал. Однако пользователям Key Vault ключ может потребоваться для других вариантов использования, например при его удалении. В этом случае они могут использовать операции BACKUP и RESTORE для экспорта или импорта ключей в защищенной форме. Ключи, созданные в ходе операции BACKUP, не могут использоваться за пределами Key Vault. Кроме того, в различных экземплярах Key Vault также можно использовать операцию IMPORT.

Пользователи могут ограничивать любую из криптографических операций, поддерживаемых Key Vault, для каждого ключа с помощью свойства key_ops объекта JWK.

Дополнительные сведения об объектах JWK см. в статье о веб-ключе JSON (JWK).

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

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

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

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

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

SQL Server использует для защиты главного ключа службы и главного ключа базы данных алгоритм шифрования AES. AES — это новый алгоритм шифрования, отличный от алгоритма 3DES, используемого в более ранних версиях. После обновления экземпляра компонента Компонент Database Engine до SQL Server необходимо заново сформировать главный ключ службы и главный ключ базы данных, чтобы обновить главные ключи до алгоритма AES. Дополнительные сведения о повторном создании главного ключа базы данных см. в статьях 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 и пароля.

Общие сведения о потенциальном риске при самостоятельном управлении ключами

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

Рассмотрите следующую последовательность событий.

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

Эти действия приведут к отключению всех сред в клиенте от интернет-доступа и сделают невозможным восстановление всех резервных копий базы данных.

Важно!

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

Требования к ключам шифрования

Если вы предоставляет собственный ключ шифрования, ваш ключ должен отвечать следующим требованиям, принятым Azure Key Vault.

Формат файла ключа шифрования должен быть PFX или BYOK.
2048-разрядный RSA или RSA-HSM тип ключа.
PFX-файлы ключей шифрования должны быть защищены паролем.

Дополнительные сведения о создании и переносе ключа с защитой HSM по Интернету см. в разделе Создание и перенос ключей с защитой HSM для хранилища ключей Azure. Поддерживается только . Перед генерацией ключа HSM перейдите в центр администрирования Power Platform, окно Управление ключами шифрования/Создать ключ для получения идентификатора подписки для региона вашей среды. Вам необходимо скопировать и вставить этот идентификатор подписки в HSM, чтобы создать ключ. Это гарантирует, что только наше хранилище ключей Azure сможет открыть ваш файл.

Алгоритмы RSA

Для ключей EC-HSM в Key Vault поддерживаются приведенные ниже идентификаторы алгоритма.

WRAPKEY/UNWRAPKEY, ENCRYPT/DECRYPT

RSA1_5 — это шифрование ключа RSAES-PKCS1-V1_5 .
RSA-OAEP — алгоритм RSAES, использующий оптимальное асимметричное шифрование с дополнением (OAEP) , с параметрами по умолчанию, указанными в RFC 3447 в разделе A.2.1. В этих параметрах по умолчанию используется хэш-функция SHA-1 и функция генерации маски MGF1 с помощью SHA-1.
RSA-OAEP-256 — RSAES с использованием OAEP (оптимальное асимметричное шифрование с дополнением), хэш-функции SHA-256 и функции MGF1 для создания маски с поддержкой SHA-256.

SIGN/VERIFY

PS256 — RSASSA-PSS с помощью SHA-256 и MGF1 с SHA-256, как описано в RFC7518.
PS384 — RSASSA-PSS с помощью SHA-384 и MGF1 с SHA-384, как описано в RFC7518.
PS512 — RSASSA-PSS с помощью SHA-512 и MGF1 с SHA-512, как описано в RFC7518.
RS256 — RSASSA-PKCS-v1_5, использующий SHA-256. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-256 и иметь длину в 32 байта.
RS384 — RSASSA-PKCS-v1_5, использующий SHA-384. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-384 и иметь длину в 48 байтов.
RS512 — RSASSA-PKCS-v1_5, использующий SHA-512. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-512 и иметь длину в 64 байта.
RSNULL — специализированный вариант использования для реализации определенных сценариев TLS (см. RFC2437).

Надежность асимметричного шифрования

Теоретически приватный ключ от асимметричного шифра можно вычислить, зная публичный ключ и механизм, лежащий в основе алгоритма шифрования (последнее — открытая информация). Надежными считаются шифры, для которых это нецелесообразно с практической точки зрения. Так, на взлом шифра, выполненного с помощью алгоритма RSA с ключом длиной 768 бит на компьютере с одноядерным процессором AMD Opteron с частотой 2,2 ГГц, бывшем в ходу в середине 2000-х, ушло бы 2000 лет.

При этом фактическая надежность шифрования зависит в основном от длины ключа и сложности решения задачи, лежащей в основе алгоритма шифрования, для существующих технологий. Поскольку производительность вычислительных машин постоянно растет, длину ключей необходимо время от времени увеличивать. Так, в 1977-м (год публикации алгоритма RSA) невозможной с практической точки зрения считалась расшифровка сообщения, закодированного с помощью ключа длиной 426 бит, а сейчас для шифрования этим методом используются ключи от 1024 до 4096 бит, причем первые уже переходят в категорию ненадежных.

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

TDE и журналы транзакций

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

Состояние шифрования файла журнала можно определить, просмотрев столбец в представлении , как показано в примере:

Дополнительные сведения об архитектуре файлов журнала SQL Server см. в разделе Журнал транзакций (SQL Server).

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

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

Подготовка главных ключей столбцов в диалоговом окне «Новый главный ключ столбца»

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

С помощью обозревателя объектов перейдите к папке Безопасность > Ключи постоянного шифрования в базе данных.
Щелкните правой кнопкой мыши папку Главные ключи столбцов и выберите Создать главный ключ столбца… .
В диалоговом окне Новый главный ключ столбца введите имя объекта метаданных главного ключа столбца.
Выберите хранилище ключей.
- Хранилище сертификатов — текущий пользователь — указывает расположение хранилища сертификатов текущего пользователя в хранилище сертификатов Windows, которое является личным хранилищем.
- Хранилище сертификатов — локальный компьютер — указывает расположение хранилища сертификатов локального компьютера в хранилище сертификатов Windows.
- Azure Key Vault — потребуется войти в Azure (щелкните Вход). После входа вы сможете выбрать одну из подписок Azure, хранилище ключей или управляемый модуль HSM (требуется SSMS 18.9 или более поздней версии).
  
  Примечание
  
  Сейчас диалоговое окно Новый главный ключ столбца не поддерживает хранилища ключей, которые используют разрешения по ролям для авторизации. Поддерживаются только хранилища ключей, использующие политики доступа.
  
  Примечание
  
  Чтобы использовать главные ключи столбцов, хранящиеся в управляемом модуле HSM в Azure Key Vault, требуется SSMS 18.9 или более поздних версий.
- Поставщик хранилища ключей (KSP) — указывает хранилище ключей, которое доступно через поставщик хранилища ключей (KSP), реализующий API криптографии следующего поколения (CNG). Как правило, этот тип хранилища является аппаратным модулем безопасности (HSM). После выбора этого параметра необходимо выбрать поставщик KSP. По умолчанию выбран поставщик хранилища ключей Microsoft Software Key Store Provider . Чтобы использовать главный ключ столбца, хранящийся в HSM, выберите KSP для устройства (он должен быть установлен и настроен на компьютере до открытия диалогового окна).
- Поставщик служб шифрования (CSP) — хранилище ключей, доступное через поставщик служб шифрования (CSP), который реализует Cryptography API (CAPI). Как правило, это хранилище является аппаратным модулем безопасности (HSM). После выбора этого параметра необходимо выбрать поставщик CSP. Чтобы использовать главный ключ столбца, хранящийся в HSM, выберите CSP для устройства (он должен быть установлен и настроен на компьютере до открытия диалогового окна).
Примечание

Так как CAPI — это устаревший API, параметр «Поставщик служб шифрования» отключен по умолчанию. Его можно включить, создав значение CAPI Provider Enabled DWORD в разделе реестра Windows и установив для него 1. Если хранилище ключей не поддерживает CNG, вместо CAPI следует использовать CNG.

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

Примечание

Флажок Разрешить вычисления анклава не отображается, если в экземпляре SQL Server не выполнена правильная настройка безопасных анклавов.
Выберите существующий ключ в хранилище ключей либо нажмите кнопку Создать ключ или Создать сертификат , чтобы создать ключ в хранилище ключей.
Нажмите кнопку ОК , и новый ключ появится в списке.

После завершения работы с диалоговым окном среда SQL Server Management Studio создаст метаданные для главного ключа столбца в базе данных. Для выполнения этой задачи в диалоговом окне создается и запускается инструкция CREATE COLUMN MASTER KEY (Transact-SQL) .

При включении поддержки анклава для главного ключа столбца среда SSMS также подписывает метаданные с помощью главного ключа столбца.

Разрешения на подготовку главного ключа столбца

Для создания главного ключа столбца в диалоговом окне необходимо разрешение ALTER ANY COLUMN MASTER KEY в базе данных. Вам также требуются разрешения для хранилища ключей на доступ к главному ключу столбца и на его использование. Дополнительные сведения о разрешениях для хранилища ключей, необходимых, чтобы выполнять операции управления ключами, см. в статье Создание и хранение главных ключей столбцов для Always Encrypted в разделе о нужном хранилище.

Схема учреждения

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

Обмена ключами Диффи-Хеллмана и Ривест-Шамира-Адлеман (RSA) являются наиболее широко используются два алгоритмы обмена ключами. В 1976 году Уитфилд Диффи и Мартин Хеллман построили алгоритм Диффи – Хеллмана , который был первым алгоритмом с открытым ключом. Протокол обмена ключами Диффи-Хеллмана позволяет обмениваться ключами по незащищенному каналу путем электронной генерации общего ключа между двумя сторонами. С другой стороны, RSA — это форма системы асимметричных ключей, которая состоит из трех этапов: генерация ключа, шифрование и дешифрование.

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