Команда Set-AzureRmSqlDatabase не работает при снижении ценового уровня базы данных SQL Azure из-за мягкого удаления хранилища ключей.

Я использую автоматизированный сценарий PowerShell, чтобы снизить ценовой уровень резервной копии базы данных. При подаче следующей команды происходит сбой понижения уровня. Ошибка, если я правильно понял, относится к хранилищу ключей с ключом, названным таким же, как имя моего сервера, поскольку такого ключа не существует (следовательно, мягкое удаление также может быть не включено), эта команда не выполняется.

Команда была настроена, когда мое приложение не было настроено с хранилищем ключей, и похоже, что теперь она не работает.

Используемая команда:

Set-AzureRmSqlDatabase -DatabaseName <*Back-up DB name*> -ServerName <*SQL server name*> -ResourceGroupName <*Resource Group name*> -Edition Standard -RequestedServiceObjectiveName S0

Ошибка:

Set-AzureRmSqlDatabase: 45377: Указанный uri хранилища ключей 'https: //****.vault.azure.net/keys/ ‹SERVERNAME> / ‹< em > Подписка / какой-то идентификатор> недействительна. Убедитесь, что в хранилище ключей настроено мягкое удаление. (https://aka.ms/sqltdebyoksoftdelete) В строке: 1 символ: 2 + Set-AzureRmSqlDatabase -DatabaseName ‹Имя резервной базы данных> -ServerName‹ Имя сервера SQL> ... + ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ + CategoryInfo: CloseError: (:) [Set-AzureRmSqlDatabase], CloudException + FullyQualifiedErrorId: Microsoft.Azure.Commands.Sql.Database.Cmdlet.SetAzureSqlDatabase

Вопросы:
1. Почему команда Set-AzureRmSqlDatabase ссылается на URI хранилища ключей, если не упоминается явно?

2. Есть ли параметр, который нам нужно установить на уровне сервера / БД, чтобы эта команда могла читать имя сервера / БД напрямую, а не искать ключ с именем сервера?

  1. Связано ли это с прозрачным шифрованием данных?

  2. Предполагаем ли мы внести какие-либо изменения в эту команду, если хранилище ключей появится позже, чем настройка приложения / базы данных / хранилища ключей?


person swati gupta    schedule 19.07.2018    source источник


Ответы (2)


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

Я могу решить эту проблему, выполнив следующие действия:

  1. Обновленная оболочка PowerShell: установочный пакет

  2. Войдите в свою подписку на Azure и выполните эту команду

    $vault = Get-AzureRmKeyVault -VaultName myvault; $vault.EnableSoftDelete

  3. Если вышеуказанное не работает, выполните следующую команду. Это найдет resourceId хранилища ключей, а затем включит мягкое удаление -

($resource = Get-AzureRmResource -ResourceId (Get-AzureRmKeyVault -VaultName "YourKeyVaultNameHere").ResourceId).Properties | Add-Member - MemberType "NoteProperty" -Name "enableSoftDelete" -Value "true"

Set-AzureRmResource -resourceid $resource.ResourceId -Properties $resource.Properties

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

Get-AzureRmKeyVault -VaultName "YourKeyVaultNameHere"

Надеюсь, это будет полезно для кого-то, кто столкнется с подобной проблемой.

person swati gupta    schedule 30.07.2018

Вот несколько личных мнений, на которые вы можете сослаться.

Во-первых, согласно моему тесту, команда отлично работает на моей стороне.

Примечание. В моей тестовой среде это SQL-сервер и база данных без каких-либо других вещей, таких как прозрачное шифрование данных.

Set-AzureRmSqlDatabase -DatabaseName joydatabase -ServerName joydb -ResourceGroupName joywebapp -Edition Standard -RequestedServiceObjectiveName S0

введите описание изображения здесь

Почему команда Set-AzureRmSqlDatabase ссылается на URI хранилища ключей, если не упоминается явно?

Со своей стороны, я перехватываю запрос через скрипач, он не относится к URL-адресу хранилища ключей, см. Снимок экрана.

введите описание изображения здесь

Есть ли параметр, который нам нужно установить на уровне сервера / БД, чтобы эта команда могла читать имя сервера / БД напрямую, а не искать ключ с именем сервера?

Со своей стороны, я считаю, что нам не нужно этого делать.

Связано ли это с прозрачным шифрованием данных?

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

Предполагаем ли мы внести какие-либо изменения в эту команду, если хранилище ключей появится позже, чем настройка приложения / базы данных / хранилища ключей?

Я думаю, что не стоит вносить никаких изменений в эту команду.

person Joy Wang    schedule 20.07.2018
comment
Спасибо за анализ с вашей стороны. Но проблема остается той же, как-то в моем сценарии упоминается хранилище ключей. У вас есть настройка хранилища ключей для вашего приложения / БД? - person swati gupta; 20.07.2018
comment
@swatigupta Нет, это всего лишь одна база данных, поэтому я полагаю, что проблема может быть вызвана лазурным хранилищем ключей. Как упоминалось в сообщении об ошибке, если вы включите мягкое удаление, будет ли оно работать? Может быть, вы могли бы попробовать. - person Joy Wang; 20.07.2018
comment
Проблема в том, что у меня нет ключа с именем БД в хранилище ключей, и я не уверен, что этот ключ и секрет должны быть там. Как только ключ будет на месте, я могу попробовать включить мягкое удаление. Более того, очень важно понять, почему упоминается URL-адрес хранилища ключей. Я сомневаюсь, что на лазурном портале может быть какая-то настройка, которая перенаправляет любые имена БД для проверки хранилища ключей. - person swati gupta; 20.07.2018
comment
@swatigupta Это имеет смысл, если у вас нет ключа, это сложно объяснить, включая ссылку на URL-адрес хранилища ключей. Я рекомендую вам связаться с Azure Поддержка за помощью. - person Joy Wang; 20.07.2018