Всегда шифруемый SQL Azure с помощью Keyvault — экспорт сертификата CMK

В Azure Key Vault можно создавать разные типы объектов: ключи, секреты и сертификаты. Для Always Encrypted требуется, чтобы главные ключи столбца, хранящиеся в Azure Key Vault, были ключами Key Vault. SSMS создает ключ Key Vault, когда вы решили сохранить новый главный ключ столбца в Key Vault. Кстати, то, что делает SSMS при создании ключа, эквивалентно вызову Add-AzureKeyVaultKey.

При этом при создании сертификата Key Vault (например, с помощью Add-AzureKeyVaultCertificate) адресуемый ключ и секрет также создаются с тем же именем — см. https://docs.microsoft.com/en-us/rest/api/keyvault/about-keys--secrets-and-certificates#key-vault-certificates. И вы можете использовать ключ, связанный с сертификатом, в качестве главного ключа столбца, если хотите. Однако я не знаю практической выгоды от этого: клиентский драйвер с поддержкой Always Encrypted (например, ADO.NET) даже не будет знать, что ключ связан с сертификатом.

Было бы полезно, если бы вы описали свои бизнес-требования и объяснили, почему, по вашему мнению, вам нужен главный ключ столбца в качестве сертификата.

Пожалуйста, имейте в виду, что даже если главный ключ столбца является реальным сертификатом, хранящимся в хранилище сертификатов Windows (не в Key Vault), драйверы с поддержкой Always Encrypted используют только открытый ключ и закрытый ключ, содержащиеся в сертификате, и игнорируют все остальное. В частности, драйвер никогда не проверяет дату истечения срока действия сертификата, цепочку ЦС или факт отзыва сертификата. Так задумано — мастер-ключи защищают долгоживущие данные, и такой подход гарантирует, что вы всегда сможете получить доступ к данным, пока у вас есть мастер-ключ (например, если вы создаете файл резервной копии базы данных, содержащий зашифрованные данные, и восстанавливаете базу данных из него несколько лет спустя, вы сможете получить доступ к своим данным).