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

Применимо к:База данных SQL Azure

В этой статье описывается прозрачное шифрование данных (TDE) с ключами, управляемыми клиентом, на уровне базы данных для База данных SQL Azure.

Примечание.

CMK уровня базы данных доступен для База данных SQL Azure (все выпуски База данных SQL). Он недоступен для Управляемый экземпляр SQL Azure, локальной среды SQL Server, виртуальных машин Azure и Azure Synapse Analytics (выделенных пулов SQL (ранее — хранилище данных SQL)).

Примечание.

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

Обзор

Azure SQL предоставляет клиентам возможность шифрования неактивных данных с помощью прозрачного шифрования данных (TDE). Расширение TDE с помощью ключа, управляемого клиентом (CMK), обеспечивает защиту данных в неактивных случаях, когда средство защиты TDE (ключ шифрования) хранится в Azure Key Vault, который шифрует ключи шифрования базы данных. В настоящее время TDE с CMK устанавливается на уровне сервера и наследуется всеми зашифрованными базами данных, связанными с этим сервером. Эта новая функция позволяет настроить защиту TDE в качестве ключа, управляемого клиентом, отдельно для каждой базы данных на сервере. Любой Microsoft.Sql/servers/databases ресурс с допустимым свойством nonempty encryptionProtector настроен с помощью ключей, управляемых клиентом.

В этом сценарии асимметричный ключ, хранящийся в управляемом клиентом и управляемом клиентом Azure Key Vault (AKV), можно использовать отдельно для каждой базы данных на сервере для шифрования ключа шифрования базы данных (DEK), называемого предохранителем TDE. Существует возможность добавления ключей, удаления ключей и изменения управляемого удостоверения, назначаемого пользователем (UMI) для каждой базы данных. Дополнительные сведения об удостоверениях см. в разделе "Управляемые типы удостоверений" в Azure.

Доступны следующие функции:

• Назначаемое пользователем управляемое удостоверение: вы можете назначить одно назначаемое пользователем управляемое удостоверение базе данных. Это удостоверение можно использовать для доступа к Azure Key Vault и управления ключами шифрования.
• Управление ключами шифрования. Вы можете включить добавление одного или нескольких ключей шифрования на уровне базы данных и задать один из добавленных ключей в качестве предохранителя TDE. Добавляемые ключи шифрования используют управляемое удостоверение, назначаемое пользователем, для доступа к Azure Key Vault.
• Федеративное удостоверение клиента. Вы также можете включить управляемый клиентом ключ (CMK) из Azure Key Vault в другом клиенте Microsoft Entra, чтобы его можно было задать как средство защиты TDE на уровне базы данных, используя федеративный набор удостоверений клиента в База данных SQL Azure. Это позволяет управлять TDE ключами, хранящимися в Azure Key Vault другого клиента.

Примечание.

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

Преимущества управляемого клиентом TDE на уровне базы данных

Как и другие поставщики услуг, также известные как независимые поставщики программного обеспечения (ISV), используют База данных SQL Azure для создания служб, многие обращаются к эластичным пулам в качестве способа эффективного распределения вычислительных ресурсов между несколькими базами данных. Имея каждую из баз данных клиентов в общем эластичном пуле, поставщики программного обеспечения могут воспользоваться возможностью пула оптимизировать использование ресурсов, обеспечивая наличие достаточных ресурсов для каждой базы данных.

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

С помощью TDE CMK уровня базы данных поставщики программного обеспечения могут предложить клиентам возможности CMK и обеспечить изоляцию безопасности, так как защита TDE каждой базы данных потенциально может принадлежать соответствующему клиенту ISV в хранилище ключей, которому они принадлежат. Изоляция безопасности, достигнутая для клиентов поставщика программного обеспечения, является как ключом, так и удостоверением, используемым для доступа к ключу.

На схеме ниже приведены сведения о новых функциональных возможностях, указанных выше. Он представляет два отдельных клиента Microsoft Entra. КлиентBest Services, содержащий логический сервер SQL Azure с двумя базами данных, DB 1 и DB 2Azure Key Vault 1 с доступом Key 1 к базе данных DB 1 с помощьюUMI 1. Оба UMI 1 параметра и Key 1 представляют параметр уровня сервера. По умолчанию все базы данных, созданные на этом сервере, наследуют этот параметр для TDE с помощью CMK. Клиент Contoso представляет клиент, содержащий Azure Key Vault 2 оценку базы данных по всему клиенту в Key 2 рамках поддержки межтенантной поддержки CMK на уровне базы DB 2 данных, используя Key 2 и UMI 2 настраивая эту базу данных.

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

Поддерживаемые сценарии управления ключами

В следующем разделе предполагается, что есть сервер, состоящий из трех баз данных (например Database1, Database2и Database3).

Существующий сценарий

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

• Сервер — Key1 установка в качестве CMK
• Database1 — Key1 используется в качестве CMK
• Database2 — Key1 используется в качестве CMK
• Database3 — Key1 используется в качестве CMK

Новый поддерживаемый сценарий: логический сервер, настроенный с помощью ключа, управляемого клиентом

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

• Сервер — Key1 установка в качестве CMK
• Database1 — Key2 используется в качестве CMK
• Database2 — Key1 используется в качестве CMK
• Database3 — Key1 используется в качестве CMK

Примечание.

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

Новый поддерживаемый сценарий: логический сервер, настроенный с помощью ключа, управляемого службой

Логический сервер настроен с помощью управляемого службой ключа (SMK) для TDE. Другой управляемый клиентом ключ (Key2) можно настроить на уровне базы данных.

• Сервер — набор ключей, управляемых службой, в качестве предохранителя TDE
• Database1 — Key2 задано как CMK
• Database2 — набор ключей, управляемых службой, в качестве предохранителя TDE
• Database3 — набор ключей, управляемых службой, в качестве предохранителя TDE

Восстановление шифрования на уровне сервера

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

Примечание.

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

Хотя операция отменить изменения поддерживается только в том случае, если логический сервер настроен с управляемым службой ключом при использовании TDE, база данных, настроенная с cmK уровня базы данных, может быть восстановлена на сервере, настроенном с помощью CMK, если сервер имеет доступ ко всем ключам, используемым исходной базой данных с допустимым удостоверением.

Требования к хранилищу ключей и управляемому удостоверению

Те же требования к настройке ключей Azure Key Vault (AKV) и управляемых удостоверений, включая параметры ключей и разрешения, предоставленные удостоверению, применяемого к компоненту CMK на уровне сервера, также применяются к CMK уровня базы данных. Дополнительные сведения см. в разделе прозрачное шифрование данных (TDE) с CMK и управляемыми удостоверениями с помощью CMK.

Управление ключами

Смена средства защиты TDE для базы данных означает переключиться на новый асимметричный ключ, который защищает базу данных. Смена ключей — это онлайн-операция, и она должна занять всего несколько секунд. Операция расшифровывает и повторно шифрует ключ шифрования базы данных, а не всю базу данных. После назначения допустимого управляемого удостоверения, назначаемого пользователем, смена ключа на уровне базы данных — это операция CRUD базы данных, которая включает обновление свойства защиты шифрования базы данных. Set-AzSqlDatabase и свойство -EncryptionProtector можно использовать для смены ключей. Чтобы создать новую базу данных, настроенную с помощью CMK уровня базы данных, можно использовать New-AzSqlDatabase с параметрами и -UserAssignedIdentityId параметрами-EncryptionProtector-AssignIdentity.

Новые ключи можно добавить, а существующие ключи можно удалить из базы данных с помощью аналогичных запросов и изменения свойства ключей для ресурса базы данных. Set-AzSqlDatabase с параметром -KeyList и -KeysToRemove может использоваться для этих операций. Чтобы получить параметр защиты шифрования, удостоверения и ключей, можно использовать Get-AzSqlDatabase . Ресурс Azure Resource Manager Microsoft.Sql/servers/database по умолчанию отображает только средство защиты TDE и управляемое удостоверение, настроенные в базе данных. Чтобы развернуть полный список ключей, необходимы другие параметры -ExpandKeyList . Кроме того, и значение времени (например, -KeysFilter "current"2023-01-01) можно использовать для получения текущих ключей, используемых и ключей, используемых в прошлом в определенный момент времени.

Автоматическая смена клавиш

Автоматическая смена ключей доступна на уровне базы данных и может использоваться с ключами Azure Key Vault. Поворот активируется при обнаружении новой версии ключа и автоматически будет поворачиваться в течение 24 часов. Сведения о настройке автоматической смены ключей с помощью портал Azure, PowerShell или Azure CLI см. в статье "Автоматическая смена ключей" на уровне базы данных.

Разрешение на управление ключами

В зависимости от модели разрешений хранилища ключей (политики доступа или Azure RBAC) доступ к хранилищу ключей можно предоставить либо путем создания политики доступа в хранилище ключей, либо путем создания нового назначения роли RBAC Azure.

Модель разрешений политики доступа

Чтобы база данных использовала средство защиты TDE, хранящееся в AKV для шифрования DEK, администратор хранилища ключей должен предоставить следующие права доступа к управляемому удостоверению, назначенному пользователем базы данных, с помощью уникального удостоверения Microsoft Entra:

• get — для получения общедоступной части и свойств ключа в Azure Key Vault.
• wrapKey — для защиты (шифрования) DEK.
• unwrapKey — чтобы иметь возможность отмены защиты (расшифровки) DEK.

Модель разрешений Azure RBAC

Чтобы база данных использовала средство защиты TDE, хранящееся в AKV для шифрования DEK, новое назначение роли Azure RBAC с пользователем шифрования службы шифрования key Vault необходимо добавить для управляемого удостоверения, назначаемого пользователем базы данных, с помощью уникального удостоверения Microsoft Entra.

Межтенантные ключи, управляемые клиентом

Межтенантные ключи, управляемые клиентом, с прозрачным шифрованием данных, описывают настройку федеративного идентификатора клиента для CMK уровня сервера. Аналогичную настройку необходимо выполнить для CMK уровня базы данных и федеративного идентификатора клиента необходимо добавить в рамках запросов API Set-AzSqlDatabase или New-AzSqlDatabase .

Примечание.

Если мультитенантное приложение не было добавлено в политику доступа к хранилищу ключей с необходимыми разрешениями (Get, Wrap Key, Unwrap Key), используя приложение для федерации удостоверений в портал Azure отобразит ошибку. Убедитесь, что разрешения настроены правильно перед настройкой федеративного удостоверения клиента.

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

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

Примечание.

Управление удостоверениями и ключами для TDE с ключами, управляемыми клиентом на уровне базы данных, подробно описывает операции управления удостоверениями и ключами для CMK уровня базы данных, а также примеры Azure CLI и REST API.

Дополнительные рекомендации

• Если TDE с CMK уже включен на уровне сервера, установка CMK для определенной базы данных переопределяет параметр CMK уровня сервера (DEK базы данных повторно шифруется с помощью защиты TDE уровня базы данных).
• Любые изменения или повороты ключа уровня логического сервера не влияют на параметры CMK уровня базы данных, и база данных продолжает использовать собственный параметр CMK.
• CMK уровня базы данных не поддерживается через Transact-SQL (T-SQL).
• Управляемое удостоверение, назначаемое пользователем логического сервера (UMI), можно использовать на уровне базы данных. Однако рекомендуется использовать назначенный UMI для CMK уровня базы данных.
• Параметры CMK на уровне сервера не влияют на отдельные базы данных, настроенные с помощью CMK уровня базы данных, и они продолжают использовать собственный отдельный клиент или конфигурацию между клиентами.
• На уровне базы данных можно задать только одно назначаемое пользователем управляемое удостоверение.

Примечание.

Управляемые удостоверения в базе данных должны быть переназначированы, если база данных переименована.

Миграция существующих баз данных на уровень CMK на уровне базы данных

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

База данных, настроенная с помощью CMK уровня сервера без геоконфигурации реплика

1. Используйте sys.dm_db_log_info (Transact-SQL) — SQL Server для базы данных и найдите активные файлы виртуальных журналов (VLFs).
2. Для всех активных VLFs запишите vlf_encryptor_thumbprint результат.sys.dm_db_log_info
3. Используйте sys.dm_database_encryption_keys (Transact-SQL) — представление SQL Server для базы данных для проверкаencryptor_thumbprint. encryptor_thumbprintЗапишите .
4. Используйте командлет Get-AzSqlServerKeyVaultKey, чтобы получить все ключи уровня сервера, настроенные на логическом сервере. В результатах выберите те, которые имеют тот же отпечаток, который соответствует списку из приведенного выше результата.
5. Вызов API базы данных обновления к базе данных, которую требуется перенести, а также средство защиты удостоверений и шифрования. Передайте приведенные выше ключи в качестве ключей уровня базы данных с помощью параметров Set-AzSqlDatabase , , -KeyList-AssignIdentity( -EncryptionProtector и при необходимости-FederatedClientId).-UserAssignedIdentityId

Внимание

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

База данных, настроенная с помощью CMK уровня сервера с геоконфигурацией реплика

1. Выполните действия (1) до (4) упоминание, указанных в предыдущем разделе, чтобы получить список ключей, необходимых для миграции.
2. Вызов API базы данных обновления к базе данных-источнику и базе данных-получателю, которую требуется перенести, а также удостоверение и указанные выше ключи в качестве ключей уровня базы данных с помощью Set-AzSqlDatabase и -KeyList параметра. Не устанавливайте средство защиты шифрования.
3. Ключ уровня базы данных, который вы хотите использовать в качестве основного средства защиты баз данных, необходимо сначала добавить в базу данных-получатель. Используйте Set-AzSqlDatabase , -KeyList чтобы добавить этот ключ в базу данных-получатель.
4. После добавления ключа защиты шифрования в базу данных-получатель используйте Set-AzSqlDatabase , чтобы задать его в качестве средства защиты шифрования в базе данных-источнике -EncryptionProtector с помощью параметра.
5. Задайте ключ в качестве средства защиты шифрования в базе данных-получателе, как описано в разделе (4), чтобы завершить миграцию.

Внимание

Чтобы перенести базы данных, настроенные с помощью ключа, управляемого службой сервера, и гео-реплика tion, выполните действия (3), (4) и (5) из этого раздела.

Геоизбыточное реплика и высокий уровень доступности

В сценариях активных гео-реплика групп игрупп отработки отказа задействованные базы данных-источник и вторичные базы данных могут быть связаны либо с одним хранилищем ключей (в любом регионе), либо с отдельными хранилищами ключей. Если отдельные хранилища ключей связаны с сервером-источником и сервером-получателем, клиент несет ответственность за поддержание согласованности данных ключей в хранилищах ключей, чтобы вторичная геореплика была синхронизирована и могла использовать тот же ключ из своего связанного хранилища ключей, если первичный ключ станет недоступным из-за сбоя в регионе и активации отработки отказа. Можно настроить до четырех вторичных реплик, но цепочки (вторичные реплики вторичных реплик) не поддерживаются.

Чтобы установить активное гео-реплика tion для базы данных, настроенной с помощью CMK уровня базы данных, необходимо создать вторичную реплика с допустимым управляемым удостоверением, назначаемым пользователем, и список текущих ключей, используемых базой данных-источником. Список текущих ключей можно получить из базы данных-источника с помощью необходимых фильтров и параметров запроса или с помощью PowerShell и Azure CLI. Действия, необходимые для настройки гео реплика такой базы данных:

1. Предварительно заполните список ключей, используемых базой данных-источником, с помощью команды Get-AzSqlDatabase и -ExpandKeyList-KeysFilter "current" параметров. Исключите, -KeysFilter если вы хотите получить все ключи.
2. Выберите управляемое удостоверение, назначаемое пользователем (и федеративный идентификатор клиента при настройке доступа между клиентами).
3. Создайте базу данных в качестве вторичной базы данных с помощью New-AzSqlDatabaseSecondary и предоставьте предварительно заполненный список ключей, полученных из исходной базы данных, и указанного выше удостоверения (и федеративного клиента DI при настройке межтенантного доступа) в вызове API с помощью -AssignIdentity-KeyListпараметров , , -UserAssignedIdentityId( -EncryptionProtector и при необходимости-FederatedClientId).
4. Используйте New-AzSqlDatabaseCopy , чтобы создать копию базы данных с теми же параметрами на предыдущем шаге.

Внимание

База данных, настроенная с помощью CMK уровня базы данных, должна иметь реплика (или копировать) с помощью CMK уровня базы данных. Реплика не может использовать параметры шифрования уровня сервера.

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

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

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

Примечание.

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

Резервное копирование и восстановление баз данных с помощью TDE с управляемым клиентом ключом на уровне базы данных

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

Внимание

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

Восстановление до точки во времени

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

1. Предварительно заполните список ключей, используемых базой данных-источником, с помощью команды Get-AzSqlDatabase и -ExpandKeyList-KeysFilter "2023-01-01" параметров. 2023-01-01 — это пример точки во времени, в которую вы хотите восстановить базу данных. Исключите, -KeysFilter если вы хотите получить все ключи.
2. Выберите управляемое удостоверение, назначаемое пользователем (и федеративный идентификатор клиента при настройке доступа между клиентами).
3. Используйте Restore-AzSqlDatabase с -FromPointInTimeBackup параметром и укажите предварительно заполненный список ключей, полученных на основе описанных выше шагов, и указанное выше удостоверение (и федеративный идентификатор клиента при настройке межтенантного доступа) в вызове API с помощью -KeyListпараметров , -UserAssignedIdentityId-AssignIdentity( -EncryptionProtector и при необходимости-FederatedClientId).

Примечание.

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

Удаление восстановления базы данных

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

1. Предварительно заполните список ключей, используемых базой данных-источником, с помощью Get-AzSqlDeletedDatabaseBackup и -ExpandKeyList параметра. Рекомендуется передать все ключи, которые использовала исходная база данных, но также может быть предпринята попытка восстановления с ключами, предоставленными временем -KeysFilterудаления.
2. Выберите управляемое удостоверение, назначаемое пользователем (и федеративный идентификатор клиента при настройке доступа между клиентами).
3. Используйте Restore-AzSqlDatabase с -FromDeletedDatabaseBackup параметром и предоставьте предварительно заполненный список ключей, полученных из описанных выше шагов, и указанное выше удостоверение (и федеративный идентификатор клиента при настройке доступа между клиентами) в вызове API с помощью -KeyListпараметров , -UserAssignedIdentityId-AssignIdentity( -EncryptionProtector и при необходимости-FederatedClientId).

Геовосстановление

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

• Предварительно заполните список ключей, используемых базой данных-источником, с помощью Get-AzSqlDatabaseGeoBackup и -ExpandKeyList извлечения всех ключей.
• Выберите управляемое удостоверение, назначаемое пользователем (и федеративный идентификатор клиента при настройке доступа между клиентами).
• Используйте Restore-AzSqlDatabase с -FromGeoBackup параметром и предоставьте предварительно заполненный список ключей, полученных из описанных выше шагов, и указанное выше удостоверение (и федеративный идентификатор клиента при настройке доступа между клиентами) в вызове API с помощью -KeyListпараметров , -UserAssignedIdentityId-AssignIdentity( -EncryptionProtector и при необходимости-FederatedClientId).

Внимание

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

Примечание.

Резервные копии долгосрочного хранения резервных копий (LTR) не предоставляют список ключей, используемых резервной копией. Чтобы восстановить резервную копию LTR, все ключи, используемые исходной базой данных, должны быть переданы целевому объекту восстановления LTR.

Дополнительные сведения о восстановлении резервного копирования для База данных SQL с помощью CMK уровня базы данных с примерами использования PowerShell, Azure CLI и REST API см. в статье Настройка гео реплика и восстановления резервного копирования для прозрачного шифрования данных с помощью ключей, управляемых клиентом на уровне базы данных.

Ограничения

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

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

Для дальнейшего понимания этого сценария рассмотрим следующие временная шкала:

• Время t0 = база данных создается без шифрования
• Время t1 = эта база данных защищена ключом Thumbprint A, управляемым клиентом.
• Время t2 = средство защиты базы данных поворачивается на новый управляемый клиентом ключ Thumbprint Bуровня базы данных.
• Время t3 = запрашивается изменение Thumbprint C предохранителя.
• Если используются Thumbprint Aактивные VLFs, поворот не допускается.
• Если активные VLFs не используютсяThumbprint A, вращение допускается.

Вы можете использовать sys.dm_db_log_info (Transact-SQL) — представление SQL Server для базы данных и искать активные файлы виртуальных журналов. Вы увидите активный VLF, зашифрованный с помощью первого ключа (например, Thumbprint A). После создания достаточного журнала с помощью вставки данных этот старый VLF очищается, и вы сможете выполнить другой поворот ключа.

Если вы считаете, что что-то держит журнал дольше, чем ожидалось, обратитесь к следующей документации для дальнейшего устранения неполадок:

• sys.dm_db_log_stats (Transact-SQL) для возможных log_truncation_holdup_reason значений.
• Устранение ошибки полного журнала транзакций 9002.

Следующие шаги

Ознакомьтесь со следующей документацией по различным операциям CMK на уровне базы данных:

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

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