Основные версии в SQL Server Кластеры больших данных

Область применения: SQL Server 2019 (15.x)

Внимание

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, и программное обеспечение будет продолжать поддерживаться с помощью накопительных обновлений SQL Server до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

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

Общие сведения о защите Кластеры больших данных SQL Server см. в концепциях безопасности для SQL Server Кластеры больших данных.

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

• Основные понятия шифрования неактивных данных и рекомендации по настройке
• Руководство по использованию зон шифрования HDFS Кластеры больших данных SQL Server
• Руководство по использованию sql Server Кластеры больших данных прозрачное шифрование данных (TDE)

Ключи HDFS

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

• Зоны шифрования (EZ). Зона шифрования — это папка в HDFS, связанная с ключом. Все файлы в этой папке шифруются. По умолчанию подготовленная среда EZ в SQL Server Кластеры больших данных называется securelake.
• Ключ зоны шифрования (ключ EZ) — именованный симметричный ключ. Система, управляемая системой, подготовленная в SQL Server Кластеры больших данных— securelakekey. Ключи зоны шифрования управляются с помощью Hadoop KMS (сервер управления ключами), выполняющегося внутри модулей pod узла имен SQL Server Кластеры больших данных. Ключи зоны шифрования дополнительно защищаются главным ключом шифрования, хранящимся в controldb (см. разделы ниже). Ключи зоны шифрования зашифровываются в Hadoop KMS с помощью открытой части главного ключа шифрования, а запросы на расшифровку отправляются на уровень управления.
• Зашифрованный ключ шифрования данных. Каждый файл в зоне шифрования шифруется ключом шифрования данных (DEK), созданным для этого файла. После создания ключа DEK он сохраняется вместе с данными. Перед сохранением ключа DEK он шифруется с помощью ключа зоны шифрования. Ключ DEK генерируется случайным образом для каждого файла. Стойкость симметричного ключа DEK такая же, как у ключа зоны шифрования.

На рисунке ниже показано, как файлы защищаются с помощью ключей DEK и как ключи DEK защищаются с помощью ключа зоны шифрования securelakekey.

Ключи SQL Server

Главный ключ шифрования, управляемый системой, и ключи зон шифрования HDFS хранятся в модуле pod controldb с именем controldb-<#>, например controldb-0. Дополнительные сведения см. в статье Ресурсы, развертываемые с помощью кластера больших данных.

Базы данных SQL Server шифруются симметричным ключом, также известным как ключ шифрования базы данных (DEK). Ключ DEK сохраняется в базе данных в зашифрованном формате. Предохранителем DEK может быть сертификат или асимметричный ключ. Чтобы изменить защиту DEK, используйте инструкцию ALTER DATABASE ENCRYPTION KEY . В метаданных асимметричного ключа SQL Server содержится URL-ссылка на ключ на уровне управления. Таким образом, все операции шифрования и расшифровки ключа шифрования базы данных (DEK) выполняются в контроллере. В SQL Server хранится открытый ключ, но он служит только для указания асимметричного ключа, но не для шифрования.

Основной ключ шифрования SQL Server Кластеры больших данных

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

1. Главные ключи шифрования — это асимметричные ключи RSA.
2. Один главный ключ шифрования создается для главного экземпляра SQL Server, а другой — для HDFS.
3. Открытый ключ, соответствующий главному ключу шифрования, всегда хранится в базе данных контроллера или controldb. Закрытый ключ хранится в базе данных контроллера для главного ключа шифрования, управляемого системой. Для ключей шифрования из аппаратного модуля безопасности (HSM) или от любого другого внешнего поставщика закрытые ключи не хранятся в базе данных контроллера (если только приложение для внешних ключей не включает закрытый ключ). Однако закрытый ключ не нужен внутри controldb и SQL Server Кластеры больших данных не потребует материала закрытого ключа.
4. Операции шифрования, использующие открытый ключ главного ключа шифрования, могут выполняться в самом контроллере, либо контроллер может передавать открытый ключ в Hadoop KMS, чтобы Hadoop KMS мог выполнять шифрование локально. Операции расшифровки должны осуществляться внешним поставщиком ключей, например HSM. Такая схема позволяет держать конфиденциальную часть асимметричного ключа за пределами кластера под защитой клиента. Это гарантирует, что корневой каталог шифрования для расшифровки всех данных никогда недоступен в экосистеме SQL Server Кластеры больших данных для ключей, настроенных клиентом.

Защита различных ключей при хранении

Ключи DEK для файлов HDFS и для SQL Server хранятся вместе с данными, которые они защищают. Для защиты ключа DEK используется соответственно ключ зоны шифрования HDFS или асимметричный ключ в SQL Server.

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

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

Общие сведения о защите представлены на приведенных ниже схемах. Защита хранящихся ключей зон шифрования HDFS:

Защита хранящегося главного ключа шифрования:

Смена ключей

Ключи зон шифрования HDFS

При развертывании SQL Server Кластеры больших данных с помощью Active Directory HDFS подготавливается с помощью зоны шифрования по умолчанию с именем securelake, защищенной securelakekey. Мы будем использовать имена по умолчанию в примерах, однако с помощью azdata можно подготовить новые зоны и ключи. Ключ securelakekey защищается главным ключом шифрования для HDFS, который хранится на уровне управления. Начиная с SQL 2019 с накопительным пакетом обновления 9 azdata можно использовать для смены ключей зон шифрования для HDFS. При смене ключей зон шифрования генерируется новый материал ключа с тем же именем (securelakekey), но с новой версией ключа, указывающей на материал. Для всех новых операций шифрования в HDFS (например, записи файлов) в зоне шифрования всегда используется последняя версия ключа, связанная с зоной шифрования. Для файлов в зоне шифрования, защищенных более старыми версиями ключей, можно использовать команду azdata bdc hdfs encryption-zone reencrypt, чтобы защитить все файлы последней версией ключа зоны шифрования.

Рассмотрим файл с именем file2 в /securelake. Ниже показана цепочка защиты.

Версию ключа securelakekey можно поменять на новую с помощью azdata bdc hdfs key roll -n securelakekey. Смена не приводит к повторному шифрованию ключей DEK, защищающих файл. Смена ключа в Hadoop приводит к формированию нового материала ключа и использованию для защиты последней версии главного ключа шифрования. На схеме ниже показано состояние системы после смены securelakekey.

Чтобы убедиться в том, что файлы в зонах шифрования защищены новым ключом securelakekey, выполните команду azdata bdc hdfs encryption-zone -a start -p /securelake.

На схеме ниже показано состояние системы после повторного шифрования зоны шифрования.

SQL Server

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

Смена главного ключа шифрования

Примечание.

До SQL Server 2019 с накопительным пакетом обновления 10 не существовало способа смены главного ключа шифрования. Начиная с SQL Server 2019 с накопительным пакетом обновления 10, появилась команда azdata, обеспечивающая смену главного ключа шифрования.

Главный ключ шифрования представляет собой 2048-разрядный ключ RSA. При смене главного ключа шифрования выполняется одно из описанных ниже действий в зависимости от источника ключа.

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

При смене главного ключа данные не шифруются повторно, но требуется смена ключей SQL Server и HDFS.

• После смены главного ключа предохранитель DEK базы данных SQL Server необходимо перевести на новую версию главного ключа.
• То же самое относится к HDFS. После смены ключа HDFS новый материал зашифровывается последней версией главного ключа. Более старые версии ключей зон шифрования останутся не затрагиваются. После смены ключа зоны шифрования HDFS необходимо повторно зашифровать связанные с ним зоны шифрования, используя последнюю его версию.

Смена главного ключа для HDFS

На схемах ниже показан процесс смены главного ключа шифрования HDFS. Начальное состояние HDFS:

Смена главного ключа шифрования осуществляется с помощью команды azdata bdc kms set –key-provider SystemManaged. (Обратите внимание, что эта команда инициирует смену главного ключа шифрования как для SQL, так и для HDFS, хотя это разные ключи на уровне управления.) Состояние после использования команды azdata bdc kms:

Чтобы использовалась новая версия главного ключа шифрования HDFS, можно выполнить команду azdata bdc hdfs key roll, которая переводит систему в представленное ниже состояние. Состояние после смены securelakekey:

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

Смена главного ключа для SQL Server

Главный ключ шифрования SQL Server устанавливается в базе данных master главного экземпляра SQL Server.

На схемах ниже показан процесс смены главного ключа шифрования для SQL Server.

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

Смена главного ключа шифрования осуществляется с помощью команды azdata bdc kms set –key-provider SystemManaged. (Обратите внимание, что эта команда инициирует смену главного ключа шифрования (или создание при его отсутствии) как для SQL, так и для HDFS, хотя это разные ключи на уровне управления.)

Асимметричный ключ можно просмотреть с помощью следующего запроса T-SQL в представлении системного каталога sys.asymmetric_keys.

USE master;
select * from sys.asymmetric_keys;

Для асимметричного ключа используется соглашение об именовании "tde_asymmetric_key_<версия>". Администратор SQL Server может затем сменить предохранитель DEK на асимметричный ключ с помощью инструкции ALTER DATABASE ENCRYPTION KEY. Например, используйте следующую команду T-SQL:

USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;

В результате предохранитель DEK меняется на асимметричный ключ:

При повторном выполнении команды azdata bdc kms set в sys.asymmetric_keys отображается другая запись для асимметричных ключей SQL Server в формате "tde_asymmetric_key_<версия>". С помощью этой команды azdata можно еще раз сменить предохранитель DEK для базы данных SQL Server.

Ключ, предоставляемый клиентом

Благодаря возможности привлечения внешних ключей в SQL Server Кластеры больших данных основной ключ шифрования извлекает открытый ключ с помощью приложения, которое развертывает клиент. При смене и использовании ключей HDFS вызовы для расшифровки ключей HDFS отправляются на уровень управления, а затем перенаправляются в приложение с помощью идентификатора ключа, предоставленного клиентом. Для SQL Server запросы на шифрование отправляются на уровень управления и выполняются им, так как у него есть открытый ключ. Запросы на расшифровку DEK из SQL также отправляются на уровень управления, а затем перенаправляются в приложение KMS.

На приведенной ниже схеме поясняется взаимодействие при настройке внешних ключей на уровне управления.

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

См. также

• Основные понятия безопасности для кластеров больших данных SQL Server
• Настройка кластера больших данных SQL Server
• Вопросы и ответы по кластерам больших данных