EKM (Extensible Key Management)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 03:00, 24 апреля 2017.
Extensible Key Management
Разработчики: Microsoft
Состояние разработки: Active
Операционная система: SQL Server
Локализация: English
Веб-сайт https://msdn.microsoft.com/ru-ru/library/bb895340.aspx/

EKM (англ. Extensible Key Management) – это расширенное управление ключами.

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

Следует учитывать следующие основные понятия:

  • Для лучшей производительности данные следует шифровать с помощью симметричных ключей, а не с помощью сертификатов и асимметричных ключей.
  • Главные ключи базы данных защищены главным ключом службы. Главный ключ службы создается при установке SQL Server и шифруется API-интерфейсом защиты данных Windows (DPAPI).
  • Симметричные или асимметричные ключи вне SQL Server.
  • Прозрачное шифрование данных (TDE) должно использовать симметричный ключ, который называется ключом шифрования базы данных, защищенный сертификатом, который, в свою очередь защищается главным ключом базы данных master или асимметричным ключом, хранящимся в модуле расширенного управления ключами.
  • Главный ключ службы и все главные ключи базы данных являются симметричными ключами.

Аутентификация SQL Server

ImgEKM1.jpg

Система безопасности компонента Database Engine состоит из двух разных подсистем безопасности:

  • системы безопасности Windows;
  • системы безопасности SQL Server.

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

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

На основе этих двух подсистем безопасности компонент Database Engine может работать в одном из следующих режимов аутентификации: в режиме Windows и в смешанном режиме.

Режим Windows требует, чтобы пользователи входили в систему баз данных исключительно посредством своих учетных записей Windows. Система принимает данные учетной записи пользователя, полагая, что они уже были проверены и одобрены на уровне операционной системы. Такой способ подключения к системе баз данных называется доверительным соединением (trusted connection), т.к. система баз данных доверяет, что операционная система уже проверила подлинность учетной записи и соответствующего пароля.

Смешанный режим позволяет пользователям подключаться к компоненту Database Engine посредством аутентификации Windows или аутентификации SQL Server. Это означает, что некоторые учетные записи пользователей можно настроить для использования подсистемы безопасности Windows, а другие, вдобавок к этому, могут использовать также и подсистему безопасности SQL Server.

Шифрование данных

Шифрование - это процесс приведения данных в запутанное непонятное состояние, вследствие чего повышается уровень их безопасности. Обычно конкретная процедура шифрования осуществляется с использованием определенного алгоритма. Наиболее важный алгоритм шифрования называется RSA, по первым буквам фамилий его создателей - Rivers, Shamir и Adelman.

Компонент Database Engine обеспечивает безопасность данных посредством иерархии уровней шифрования и инфраструктуры управления ключами. Каждый уровень защищает следующий за ним уровень шифрования, используя комбинацию сертификатов, асимметричных и симметричных ключей: [[Файл:ImgEKM3.png] На рисунке выше главный сервисный ключ задает ключ, который управляет всеми другими ключами и сертификатами. Главный сервисный ключ создается автоматически при установке компонента Database Engine. Этот ключ зашифрован с помощью API-интерфейса защиты данных Windows (DPAPI - Data Protection API).

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

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

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

  • симметричные ключи;
  • асимметричные ключи;
  • сертификаты.


Симметричные ключи

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

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

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

Язык Transact-SQL поддерживает несколько инструкций и системных функций применительно к симметричным ключам. В частности, для создания симметричного ключа применяется инструкция CREATE SYMMETRIC KEY, а для удаления существующего симметричного ключа - инструкция DROP SYMMETRIC KEY. Прежде чем симметричный ключ можно использовать для шифрования данных или для защиты другого ключа, его нужно открыть. Для этого используется инструкция OPEN SYMMETRIC KEY.

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

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

В случае если у вас имеется распределенная система или если использование симметричных ключей не обеспечивает достаточного уровня безопасности данных, то следует использовать асимметричные ключи. Асимметричный ключ состоит из двух частей: личного закрытого ключа (private key) и соответствующего общего открытого ключа (public key). Каждый из этих ключей может расшифровывать данные, зашифрованные другим ключом. Благодаря наличию личного закрытого ключа асимметричное шифрование обеспечивает более высокий уровень безопасности данных, чем симметричное шифрование.

Язык Transact-SQL поддерживает несколько инструкций и системных функций применительно к асимметричным ключам. В частности, для создания нового асимметричного ключа применяется инструкция CREATE ASYMMETRIC KEY, а для изменения свойств асимметричного ключа используется инструкция ALTER ASYMMETRIC KEY. Для удаления асимметричного ключа применяется инструкция DROP ASYMMETRIC KEY.

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

Сертификаты

Сертификат открытого ключа, или просто сертификат, представляет собой предложение с цифровой подписью, которое привязывает значение открытого ключа к определенному лицу, устройству или службе, которая владеет соответствующим открытым ключом. Сертификаты выдаются и подписываются центром сертификации (Certification Authority - CA). Сущность, которая получает сертификат из центра сертификации (CA), является субъектом данного сертификата (certificate subject).

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

Сертификаты содержат следующую информацию:

  • значение открытого ключа субъекта;
  • информацию, идентифицирующую субъект;
  • информацию, идентифицирующую издателя сертификата;
  • цифровую подпись издателя сертификата.

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

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

Расширенное управление ключами SQL Server

Следующим шагом к обеспечению более высокого уровня безопасности ключей является использование расширенного управления ключами (Extensible Key Management - EKM). Основными целями расширенного управления ключами являются следующие:

  • повышение безопасности ключей посредством выбора поставщика функций шифрования;
  • общее управление ключами по всему приложению.
ImgEKM2.png

Расширенное управление ключами позволяет сторонним разработчикам регистрировать свои устройства в компоненте Database Engine. Когда такие устройства зарегистрированы, регистрационные имена (logins) в SQL Server могут использовать хранящиеся в них ключи шифрования, а также эффективно использовать продвинутые возможности шифрования, поддерживаемые этими модулями. Расширенное управление ключами позволяет защитить данные от доступа администраторов базы данных (за исключением членов группы sysadmin). Таким образом система защищается от пользователей с повышенными привилегиями. Данные можно зашифровывать и расшифровывать, используя инструкции шифрования языка Transact-SQL, а SQL Server может использовать внешнее устройство расширенного управления ключами для хранения ключей.

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

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

При шифровании используется ключ шифрования базы данных (DEK), который хранится в загрузочной записи базы данных, где можно получить к нему доступ при восстановлении. Ключ шифрования базы данных является симметричным ключом, защищенным сертификатом, который хранится в базе данных master. Это позволяет разработчикам программного обеспечения шифровать данные с помощью алгоритмов шифрования AES и 3DES, не меняя существующие приложения.

Настройка прозрачного шифрования данных

Чтобы включить TDE, необходимо выполнить следующие действия: 1. Создание мастер-ключа базы данных в базе данных master. 2. Создание сертификата сервера в базе данных master.

 USE master
GO
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'Pa$$w0rd';
GO
CREATE CERTIFICATE Security_Certificate
WITH SUBJECT = ' DEK_Certificate';
GO 


В следующем примере кода показано, как создать резервную копию сертификата сервера и его закрытого ключа:

BACKUP CERTIFICATE Security_Certificate
TO FILE = 'D:\backups\security_certificate.cer'
WITH PRIVATE KEY
(FILE = 'D:\backups\security_certificate.key' ,
ENCRYPTION BY PASSWORD = 'CertPa$$w0rd'); 

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

USE AdventureWorks
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE Security_Certificate
GO 


Включить шифрование для пользовательской базы данных:

ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON; 

Чтобы проверить, выполняется ли шифрование базы данных, можно выполнить запрос:

 
USE master;
SELECT name, is_encrypted FROM sys.databases ; 

В столбце name выводится имя БД, а значение в столбце is_encrypted указывает: зашифрована (1) или не зашифрована (0) база данных.


Перемещение зашифрованных баз данных

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

  1. На исходном сервере отключите базу данных, которую требуется переместить.
  2. Скопируйте или переместите файлы базы данных в то же расположение на целевом сервере.
  3. Создайте DMK в базе данных master на целевом сервере.
  4. Используйте инструкцию CREATE CERTIFICATE для создания сертификата сервера на сервере назначения из резервной копии исходного (оригинального) сертификата сервера и его закрытого ключа.
  5. Присоедините базу данных на целевом сервере.

Принцип работы EKM (Extensible Key Management)

В корпоративной среде с соблюдением требований высокого уровня безопасности управление ключами шифрования на уровне отдельного сервера базы данных может оказаться непрактичным. Многие организации приняли корпоративное решение, которое позволяет им управлять ключами шифрования и сертификатов с помощью поставщика аппаратных модулей безопасности (hardware security modules, HSMs) для безопасного хранения ключей. SQL Server поддерживает расширенное управление ключами (EKM), что дает возможность регистрировать модули от сторонних поставщиков в SQL Server и позволяет использовать ключи шифрования, хранящиеся на них. Чтобы использовать ключи от стороннего поставщика EKM для реализации TDE, необходимо выполнить следующие задачи:

  • По умолчанию расширенное управление ключами отключено. Чтобы включить его, воспользуйтесь системной хранимой процедурой sp_configure с параметрами, приведенными в следующем примере:
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'EKM provider enabled', 1
GO
RECONFIGURE
GO 
  • Создание провайдера служб шифрования из файла, предоставляемого поставщиком EKM:
CREATE CRYPTOGRAPHIC PROVIDER EKM_Provider
FROM FILE = 'S:\EKM_Files\EKMKey.dll' ;
 
  • Создание учетной записи для системных администраторов:
CREATE CREDENTIAL EKM_Credential
WITH IDENTITY = 'EKM_Admin',
SECRET = 'Pa$$w0rd'
FOR CRYPTOGRAPHIC PROVIDER EKM_Provider ;
  • Добавьте учетную запись для имени входа, которое будет использоваться для настройки шифрования:
ALTER LOGIN [ADVENTUREWORKS\DBAdmin]
ADD CREDENTIAL EKM_Credential ;
  • Создайте асимметричный ключ, хранящийся в поставщике EKM:
USE master ;
GO
CREATE ASYMMETRIC KEY EKM_Login_Key
FROM PROVIDER EKM_Provider
WITH ALGORITHM = RSA_512,
PROVIDER_KEY_NAME = 'SQL_Server_Key' ;
 
  • Создание учетных данных для компонента Database Engine для использования при выполнении шифрования и расшифровки.
CREATE CREDENTIAL EKM_TDE_Credential
WITH IDENTITY = 'TDE_DB',
SECRET = 'Pa$$w0rd'
FOR CRYPTOGRAPHIC PROVIDER EKM_Provider ; 
  • Создайте имя входа, используемое при TDE и добавить учетные данные.
 CREATE LOGIN EKM_Login
FROM ASYMMETRIC KEY EKM_Login_Key ;
GO
ALTER LOGIN EKM_Login
ADD CREDENTIAL EKM_TDE_Credential ;
  • Создание ключа шифрования базы данных для шифрования базы данных.
USE AdventureWorks ;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER ASYMMETRIC KEY EKM_Login_Key ;
  • Включите TDE для базы данных.
ALTER DATABASE AdventureWorks
SET ENCRYPTION ON ;