Ключи шифрования базы данных и SQL Server (компонент Database Engine)

Статья
05/23/2023

Применимо к:SQL Server

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

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

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

SQL Server имеет два первичных приложения для ключей: главный ключ службы (SMK), созданный в экземпляре SQL Server и для экземпляра 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 и пароля.

Управление ключами SQL Server и базы данных

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

Для управления симметричными ключами можно использовать средства, включенные в SQL Server, для выполнения следующих действий:

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

Важная информация по безопасности

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

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

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

Внимание

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