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

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

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

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

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

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

HDFS keys

Для использования шифрования в HDFS используются следующие понятия:

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

На графике ниже объясняется, как файлы защищены с помощью DEK и как DEK защищен с помощью ключа EZ securelakekey.

Ключи SQL Server

Управляемый системой ключ шифрования и ключи EZ HDFS хранятся в 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. DEK защищается ключом EZ HDFS или асимметричным ключом в SQL Server соответственно.

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

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

Защита представлена на приведенных ниже схемах. Во-первых, защита хранилища ключей EZ HDFS:

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

Key rotation

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

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

Рассмотрим файл с именем 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, который можно повторно создать. Процесс восстановления приведет к повторному шифрованию всей базы данных.

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

Основной ключ шифрования — это ключ RSA 2048-разрядной версии. Смена основного ключа шифрования выполняет одно из следующих действий в зависимости от источника ключа:

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

Поворот основного ключа не шифрует ничего повторно. Затем необходимо повернуть ключи SQL Server и HDFS:

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

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

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

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

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

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

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

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

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

При свежей установке SQL Server Big Data Clusters в 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_<version>". Затем администратор 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 команда выполняется повторно, асимметричные ключи в SQL Server будут отображать другую запись в sys.asymmetric_keys формате "tde_asymmetric_key_<version>". Эту azdata команду можно использовать для повторного изменения защиты DEK базы данных SQL Server.

Предоставленный клиентом ключ

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

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

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

See also

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