У нас есть настроенная группа отработки отказа управляемого экземпляра SQL Azure с первичным и вторичным экземплярами - проблема, с которой я сталкиваюсь, заключается в том, что мы используем шифрование на уровне ячеек (столбцов) (CLE) для некоторых столбцов таблицы нашей базы данных. Мое ограниченное понимание состоит в том, что их расшифровка зависит от главного ключа службы. Я думаю, проблема в том, что главный ключ базы данных зашифровывается с помощью главного ключа службы, а затем базы данных синхронизируются между экземплярами, но синхронизация не выполняет данные уровня сервера (экземпляра), т.е. главный ключ службы… так что на первичном Например, данные можно расшифровать, но на экземпляре аварийного переключения - нет. Следовательно, вы получите такую ошибку:
Перед выполнением этой операции создайте мастер-ключ в базе данных или откройте мастер-ключ в сеансе.
Если я запущу приведенный ниже SQL-код в своей пользовательской базе данных, он устранит проблему до тех пор, пока я не переключусь на сбой, после чего мне нужно будет запустить его снова. Это не идеально с точки зрения аварийного переключения, а также означает, что я не могу использовать вторичный экземпляр как экземпляр только для чтения.
OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘XXX’
ALTER MASTER KEY DROP ENCRYPTION BY SERVICE MASTER KEY
OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘XXX'
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY
Ниже я смог найти единственную статью с описанием проблемы (прокрутите в конец, где написано «Расшифровать данные в новой первичной реплике»), и она решает проблему путем резервного копирования главного ключа службы из первичного экземпляра и восстановления его в вторичный экземпляр, но это локальная настройка по сравнению с нашей настройкой Azure, и проблема в том, Я не знаю, как (или даже возможно) сделать резервную копию и восстановить главный ключ службы в Azure .
Я попытался создать резервную копию главного ключа службы из первичного экземпляра, чтобы восстановить его во вторичном экземпляре, но я не видел способа выполнить этот экспорт в управляемом экземпляре SQL Azure - https://docs.microsoft.com/ru-ru/sql/t-sql/statement/backup-service-master-key-transact-sql?view=sql-server-ver15… Я попытался указать ему место хранения BLOB-объектов, которое было немного натянуто, и ему это не понравилось:
BACKUP SERVICE MASTER KEY TO FILE = 'https://ourstorage.blob.core.windows.net/database-backups/service_master_key.key' ENCRYPTION BY PASSWORD = 'YYYY';
Msg 3078, уровень 16, состояние 2, строка 69 Имя файла https://pptefsaaseprd.blob.core.windows.net/database-backups/ase_prod_service_master_key недопустимо в качестве имени устройства резервного копирования для указанного типа устройства. Повторите команду BACKUP, указав допустимое имя файла и тип устройства.
Я слышал упоминание о возможности использования Azure Key Vault вместо этого, но не смог найти никаких примеров и, в идеале, не хочу вызывать какие-либо критические изменения в code / sql.
Чтобы дать больше контекста, наши текущие хранимые процедуры делают что-то вроде следующего:
OPEN SYMMETRIC KEY SSN_Key_Surname
DECRYPTION BY CERTIFICATE Surname;
/* SQL making use of the decrypted column */
CLOSE SYMMETRIC KEY SSN_Key_Surname;
Вот где я нахожусь. Надеюсь, мне просто не хватает простого шага - ведь это не редкость? т.е. если у вас есть управляемые экземпляры SQL Azure в группе отработки отказа, с шифрованием на уровне столбца, где главный ключ базы данных зашифрован главным ключом службы, как вы настраиваете такие вещи, чтобы данные можно было дешифровать как на первичном, так и на вторичном экземпляре?
Я полагаю, чтобы это сработало, вам нужно иметь возможность сделать резервную копию главного ключа службы из первичного экземпляра и восстановить его во вторичном экземпляре - возможно ли это в Azure?
