Как выйти из SSMS 2016 (Microsoft SQL Server)?

Я внедрил Always Encryption для шифрования поля SSN для таблицы пациентов в моей базе данных Azure.(используя Azure Key Vault в качестве поставщика хранилища ключей)

Я использую SSMS 2016 (13.0.16100.1) в качестве клиентского инструмента.
Сначала я попытался выполнить простой оператор выбора для этой конкретной таблицы пациентов. Он поставляется с всплывающим окном для подписи * (см. Ниже) *. Чтобы я мог войти в свою учетную запись, чтобы расшифровать столбец SSN.

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

Здесь я испытал 2 типа случаев:

ДЕЛО 1

Не удалось выйти из текущих учетных данных

Предположим, что я впервые ввел действительные учетные данные (у кого есть доступ для расшифровки ключа @ssn)

В этом случае эти учетные данные были сохранены внутри. Я не смог выйти из системы с моими учетными данными.

Первоначально я думаю, что учетные данные были сохранены на основе сеанса. Поэтому он будет работать только для этого конкретного сеанса. Но это не так...

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

СЛУЧАЙ 2

Не удается повторно ввести учетные данные

Предположим, что я впервые подписался с недействительными учетными данными (у кого нет доступа для расшифровки ключа @ssn)

В этом случае я не смог расшифровать столбец SSN. Итак, снова учетные данные были сохранены внутри.

Поэтому, если я хочу повторно войти с моими действительными учетными данными, я не могу этого сделать.


Я думаю, что для решения обоих СЛУЧАЕВ будет единственное решение =>ВЫЙТИ ИЗ ТЕКУЩИХ УЧЕТНЫХ ДАННЫХ

PS: я знаю, что у нас есть еще один вариант Вход с использованием аутентификации по паролю Active Directory. Но, к сожалению, это будет использоваться только для настроенного администратора Active Directory в одиночку. Но в моей организации более 100 участников. Таким образом, нет возможности предоставить по крайней мере 10 участникам возможность использовать вход в Active Directory.

ОБНОВЛЕНИЕ1


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


person Jayendran    schedule 18.07.2017    source источник


Ответы (1)


Во-первых, один поясняющий комментарий: вышеприведенное всплывающее диалоговое окно запрашивает учетные данные для Azure Key Vault (где вы, вероятно, храните главный ключ столбца для Always Encrypted, который защищает данные в таблице пациентов), а не для учетных данных базы данных. Аутентификация базы данных (например, с помощью аутентификации по паролю Active Directory в диалоговом окне «Подключение к серверу») не зависит от аутентификации Azure Resource Manager (Azure Key Vault). Хотя вы можете использовать одно и то же удостоверение для проверки подлинности базы данных и Azure RM, это не обязательно.

Описанные вами проблемы будут решены в версии SSMS 17.2, которая будет выпущена в ближайшее время, позволяя вам изменять удостоверение пользователя Azure RM в каждой точке проверки подлинности. Кроме того, в SSMS 17.2 учетные данные/токены будут привязаны к процессу и не будут сохраняться, поэтому после перезапуска SSMS не запомнит их. Добавление элемента управления «выход из системы» находится в нашей дорожной карте, но у нас пока нет конкретных сроков для этого.

Одним из способов обхода описанных вами проблем может быть запуск мастера Always Encrypted (правый клиент для любой таблицы и выбор «Шифровать столбцы») и нажатие «Изменить пользователя» (на странице конфигурации главного ключа столбца), а затем нажатие «Отмена» и отмена мастера. Это должно аннулировать текущие кредиты в кеше, и после этого вы запрашиваете свою таблицу, должно открыться всплывающее окно, и вы сможете ввести новые кредиты.

Спасибо,

Якуб

person Jakub Szymaszek - Microsoft    schedule 25.07.2017
comment
Хорошо, спасибо за ответ. Что касается вашего обходного пути, он не работает для меня. Он снова показывает другую ошибку, такую ​​​​как Purge. Я следовал вашим шагам, но все равно использует мои старые учетные данные. в вопросе) - person Jayendran; 26.07.2017
comment
Это сработало для меня, у меня была проблема, когда я вошел в неправильную учетную запись и в результате не мог просматривать данные зашифрованного столбца. Мне удалось изменить пользователей в диалоговом окне шифрования и решить проблему. - person Luke Rice; 28.08.2017