Используйте коннектор SQL Server с функциями шифрования SQL Server

Область применения:SQL Server

Распространённые действия по шифрованию SQL Server, использующие асимметричный ключ, защищённый Azure Key Vault, делятся на следующие три области:

Прозрачное шифрование данных (TDE) с использованием асимметричного ключа из Azure Key Vault.
Шифрование резервных копий с помощью асимметричного ключа из хранилища ключей.
Шифрование на уровне столбцов с использованием асимметричного ключа из хранилища ключей.

Выполните шаги с 1 по 4 из статьи Set up прозрачное шифрование данных with Azure Key Vault for SQL Server, прежде чем следовать шагам из этой статьи.

Примечание.

Версии 1.0.0.440 и более ранние были заменены и больше не поддерживаются в производственных средах. Обновитесь до версии 1.0.1.0 или новее. Скачайте текущую версию из Центр загрузки Майкрософт и следуйте инструкциям в разделе «Обновление SQL Server Connector» статьи Обслуживание и устранение неполадок SQL Server Connector.

Примечание.

Microsoft Entra ID ранее был известен как Azure Active Directory (Azure AD).

Прозрачное шифрование данных с использованием асимметричного ключа из Azure Key Vault

После выполнения шагов с 1 по 4 в Set up прозрачное шифрование данных with Azure Key Vault for SQL Server, используйте ключ Azure Key Vault для шифрования ключа шифрования базы данных с помощью TDE. Для получения дополнительной информации о повороте ключей с помощью PowerShell см. Поворот защитника прозрачное шифрование данных (TDE) с помощью PowerShell.

Внимание

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

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

Диаграмма, показывающая иерархию ключа шифрования при использовании Azure Key Vault.

Создайте учетные данные SQL Server для использования движком базы данных с TDE

ядро СУБД использует учетные данные приложений Microsoft Entra для доступа к хранилищу ключей при загрузке базы данных. Чтобы ограничить предоставленные вами права на доступ к хранилищу ключей, создайте ещё один Client ID и Secret, как описано в Шаге 1: Настройте модель аутентификации для ядро СУБД.

Измените приведенный ниже скрипт Transact-SQL следующим образом:
- Измените аргумент IDENTITY (ContosoDevKeyVault), чтобы он указывал на хранилище ключей Azure.
  - Если вы используете глобальную службу Azure, замените аргумент именем Azure Key Vault из шага 2. Создайте IDENTITY хранилище ключей.
  - Если вы используете частное облако Azure, например Azure для государственных организаций, Azure под управлением 21Vianet или Azure для Германии, замените аргумент IDENTITY на URI хранилища, возвращённый в создание хранилища ключей и ключа с помощью PowerShell. Не включайте https:// в URI хранилища ключей.
- Замените первую часть аргумента SECRET на идентификатор клиента приложения Microsoft Entra, указанный на шаге 1: Настройте модель аутентификации. В этом примере идентификатором клиента является EF5C8E094D2A4A769998D93440D8115D.
  
  Внимание
  
  Необходимо удалить дефисы из идентификатора клиента.
- Дополните вторую часть SECRET аргумента с помощью клиентского секрета из первого шага. В этом примере клиентский секрет равен ReplaceWithAADClientSecret.
- Последняя строка для аргумента SECRET представляет собой длинную последовательность букв и цифр без дефисов.
```
USE master;  
CREATE CREDENTIAL Azure_EKM_TDE_cred   
    WITH IDENTITY = 'ContosoDevKeyVault', -- for global Azure
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.microsoftazure.de', -- for Azure Germany   
    SECRET = 'EF5C8E094D2A4A769998D93440D8115DReplaceWithAADClientSecret'   
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;  
```

Создание имени входа в SQL Server для ядра СУБД для TDE

Создайте имя входа SQL Server и добавьте в него учетные данные из шага 1. В этом примере Transact-SQL используется тот же ключ, который был импортирован ранее.

USE master;  
-- Create a SQL Server login associated with the asymmetric key   
-- for the Database engine to use when it loads a database   
-- encrypted by TDE.  
CREATE LOGIN TDE_Login   
FROM ASYMMETRIC KEY CONTOSO_KEY;  
GO   

-- Alter the TDE Login to add the credential for use by the   
-- Database Engine to access the key vault  
ALTER LOGIN TDE_Login   
ADD CREDENTIAL Azure_EKM_TDE_cred ;  
GO

Создать ключ шифрования базы данных (DEK)

DEK шифрует ваши данные и лог-файлы в экземпляре базы данных, а затем шифруется асимметричным ключом в Azure Key Vault. Вы можете создать DEK, используя любой алгоритм или длину ключа, который поддерживает SQL Server.
```
USE ContosoDatabase;  
GO  

CREATE DATABASE ENCRYPTION KEY   
WITH ALGORITHM = AES_256   
ENCRYPTION BY SERVER ASYMMETRIC KEY CONTOSO_KEY;  
GO  
```
Включите TDE
```
-- Alter the database to enable transparent data encryption.  
ALTER DATABASE ContosoDatabase   
SET ENCRYPTION ON;  
GO  
```
Используя Management Studio, проверьте, что TDE включен, подключившись к вашей базе данных через обозреватель объектов. Кликните правой кнопкой мыши по базе данных, наведите указатель на «Задачи», а затем выберите «Управление шифрованием базы данных».

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

Кроме того, можно выполнить следующий скрипт Transact-SQL. Состояние шифрования 3 указывает на зашифрованную базу данных.
```
USE MASTER  
SELECT * FROM sys.asymmetric_keys  

-- Check which databases are encrypted using TDE  
SELECT d.name, dek.encryption_state   
FROM sys.dm_database_encryption_keys AS dek  
JOIN sys.databases AS d  
     ON dek.database_id = d.database_id;  
```
Примечание.

База данных tempdb автоматически шифруется, когда любая база данных включает TDE (прозрачное шифрование данных).

Шифрование резервных копий с помощью асимметричного ключа из хранилища ключей

Зашифрованные резервные копии поддерживаются начиная с SQL Server 2014 (12.x). Следующий пример создаёт и восстанавливает резервную копию, зашифрованную ключом шифрования данных, который защищён асимметричным ключом в хранилище ключей.

ядро СУБД использует учетные данные приложений Microsoft Entra для доступа к хранилищу ключей при загрузке базы данных. Чтобы ограничить предоставленные вами права на доступ к хранилищу ключей, создайте ещё один Client ID и Секрет, как описано в Шаге 1: Настройте модель аутентификации для ядро СУБД.

Создайте учетные данные SQL Server для использования ядром СУБД при шифровании резервных копий

Измените приведенный ниже скрипт Transact-SQL следующим образом:
- Измените аргумент IDENTITY (ContosoDevKeyVault), чтобы он указывал на хранилище ключей Azure.
  - Если вы используете глобальную службу Azure, замените аргумент именем Azure Key Vault из шага 2. Создайте IDENTITY хранилище ключей.
  - Если вы используете изолированное облако Azure, например Azure для государственных организаций, Microsoft Azure под управлением 21Vianet или Azure для Германии, замените аргумент IDENTITY на URI хранилища, возвращаемый в разделе Создание хранилища ключей и ключа с помощью PowerShell. Не включайте https:// в URI хранилища ключей.
- Замените первую часть SECRET аргумента на идентификатор клиента приложения Microsoft Entra из Шага 1: Настройте модель аутентификации. В этом примере идентификатором клиента является EF5C8E094D2A4A769998D93440D8115D.
  
  Внимание
  
  Необходимо удалить дефисы из идентификатора клиента.
- Завершите вторую часть SECRET аргумента с помощью Клиентского секрета из первого шага. В этом примере клиентский секрет равен Replace-With-AAD-Client-Secret. Последняя строка для аргумента SECRET представляет собой длинную последовательность букв и цифр, без дефисов.
```
USE master;  

CREATE CREDENTIAL Azure_EKM_Backup_cred   
    WITH IDENTITY = 'ContosoDevKeyVault', -- for global Azure
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.microsoftazure.de', -- for Azure Germany   
    SECRET = 'EF5C8E094D2A4A769998D93440D8115DReplace-With-AAD-Client-Secret'   
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;    
```
Создайте логин на SQL Server для ядро СУБД для шифрования резервных копий

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

Внимание

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

В этом примере используется асимметричный ключ, CONTOSO_KEY_BACKUP хранящийся в хранилище ключей, который можно импортировать или создать раньше для master базы данных, как описано в Шаге 2: Создание хранилища ключей.
```
USE master;  

-- Create a SQL Server login associated with the asymmetric key   
-- for the Database engine to use when it is encrypting the backup.  
CREATE LOGIN Backup_Login   
FROM ASYMMETRIC KEY CONTOSO_KEY_BACKUP;  
GO   

-- Alter the Encrypted Backup Login to add the credential for use by   
-- the Database Engine to access the key vault  
ALTER LOGIN Backup_Login   
ADD CREDENTIAL Azure_EKM_Backup_cred ;  
GO  
```
Создайте резервную копию базы данных

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

В следующем примере обратите внимание, что если база данных уже зашифрована с помощью TDE, и асимметричный ключ CONTOSO_KEY_BACKUP отличается от асимметричного ключа TDE, резервная копия шифруется как асимметричным ключом TDE, так и CONTOSO_KEY_BACKUP. Целевой экземпляр SQL Server требует оба ключа для расшифровки резервной копии.
```
USE master;  

BACKUP DATABASE [DATABASE_TO_BACKUP]  
TO DISK = N'[PATH TO BACKUP FILE]'   
WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD,   
ENCRYPTION(ALGORITHM = AES_256,   
SERVER ASYMMETRIC KEY = [CONTOSO_KEY_BACKUP]);  
GO  
```
Восстановить базу данных

Для восстановления резервной копии базы данных, зашифрованной с помощью TDE, целевой экземпляр SQL Server должен сначала иметь копию асимметричного ключа хранилища ключей, используемого для шифрования. Чтобы создать такую копию:
- Если исходный асимметричный ключ, используемый для TDE, больше не находится в хранилище ключей, восстановите резервную копию ключа хранилища ключей или переимпортируйте ключ из локального HSM. Чтобы отпечаток ключа совпал с отпечатком, записанным в резервной копии базы данных, ключ должен использовать то же имя ключа в хранилище ключей, что и изначально.
- Примените шаги 1 и 2 к целевому экземпляру SQL Server.
- После того как целевой экземпляр SQL Server получит доступ к асимметричным ключам для шифрования резервной копии, восстановите базу данных на сервере.
Пример кода восстановления:
```
RESTORE DATABASE [DATABASE_TO_BACKUP]  
FROM DISK = N'[PATH TO BACKUP FILE]'   
    WITH FILE = 1, NOUNLOAD, REPLACE;  
GO  
```
Дополнительные сведения о параметрах резервного копирования см. в разделе BACKUP (Transact-SQL).

Шифрование на уровне столбцов с использованием асимметричного ключа из хранилища ключей

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

Внимание

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

В этом примере используется асимметричный ключ, CONTOSO_KEY_COLUMNS хранящийся в хранилище ключей, который можно импортировать или создать ранее, как описано в Шаге 2: Создать хранилище ключей. Чтобы использовать этот асимметричный ключ в ContosoDatabase базе данных, запустите CREATE ASYMMETRIC KEY оператор снова, чтобы база ContosoDatabase данных получила ссылку на ключ.

USE [ContosoDatabase];  
GO  
  
-- Create a reference to the key in the key vault  
CREATE ASYMMETRIC KEY CONTOSO_KEY_COLUMNS   
FROM PROVIDER [AzureKeyVault_EKM_Prov]  
WITH PROVIDER_KEY_NAME = 'ContosoDevRSAKey2',  
CREATION_DISPOSITION = OPEN_EXISTING;  
  
-- Create the data encryption key.  
-- The data encryption key can be created using any SQL Server   
-- supported algorithm or key length.  
-- The DEK will be protected by the asymmetric key in the key vault  
  
CREATE SYMMETRIC KEY DATA_ENCRYPTION_KEY  
    WITH ALGORITHM=AES_256  
    ENCRYPTION BY ASYMMETRIC KEY CONTOSO_KEY_COLUMNS;  
  
DECLARE @DATA VARBINARY(MAX);  
  
--Open the symmetric key for use in this session  
OPEN SYMMETRIC KEY DATA_ENCRYPTION_KEY   
DECRYPTION BY ASYMMETRIC KEY CONTOSO_KEY_COLUMNS;  
  
--Encrypt syntax  
SELECT @DATA = ENCRYPTBYKEY  
    (  
    KEY_GUID('DATA_ENCRYPTION_KEY'),   
    CONVERT(VARBINARY,'Plain text data to encrypt')  
    );  
  
-- Decrypt syntax  
SELECT CONVERT(VARCHAR, DECRYPTBYKEY(@DATA));  
  
--Close the symmetric key  
CLOSE SYMMETRIC KEY DATA_ENCRYPTION_KEY;

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-10-08