Как SQL Server Always Encrypted работает на стороне клиента - PullRequest
2 голосов
/ 14 марта 2019

У меня некоторая путаница в концепции Always Encrypted.Пожалуйста, следуйте приведенному ниже сценарию.

Я создал CMK (имя - CMK_01) на компьютере A в папке CurrentUser / My.Таким образом, у меня есть всегда зашифрованный сертификат, созданный на машине А, которую я экспортировал.

После этого я создал CEK (имя - CEK_01) из машины A, используя этот CMK (CMK_01).

После этого я создал таблицу (имя - TBL_01) на машине B и использовал ееCEK_01 для шифрования своего столбца (имя - COL_01).

Теперь для проверки концепции Always Encrypted Я установил сертификат Always Encrypted на машине B и применил параметр шифрования столбца = включен в SSMS.

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

После этого я запросил эту таблицу с машины C без установки сертификата и обнаружил, что данные в зашифрованном виде.Так что в основном это прекрасно работает со стороны БД.Это работает на основе сертификата, установленного на отдельном компьютере, и зависит от папки, в которой он установлен (текущий или локальный компьютер).

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

Теперь возникает проблема,

Iпопытался использовать эту функциональность на стороне .NET.Поэтому я включил параметр шифрования столбца = включено в строке подключения .NET-кода.А затем я развернул код .NET на сервере (машина D).После этого я установил всегда зашифрованный сертификат на один из пользовательских компьютеров (компьютер E) в папке CurrentUser / My.

Теперь, когда пользователь на компьютере E пытается просмотреть данные в пользовательском интерфейсе, он выдает ошибку,В основном шифрование здесь не работает.

Чтобы решить эту проблему, я создал новый CMK (имя - CMK_01) с тем же ключом сертификата, но путь к CMK находится в LocalMachine \ My.

Затем я добавил это новое значение CMK в существующий CEK (CEK_01).

Так что теперь у нас в основном есть 2 CMK - один и тот же ключ сертификата с другим путем и 1 CEK с 2 различными значениями CMK, что означает, что оба CMK могут получить доступ к этому CEK.

После этого мы установили Always Encrypted Certificateна сервере IIS (в папке LocalMachine \ My path), где был развернут наш код (машина D).После того, как эта ошибка была удалена, но все пользователи, которые могут войти на эту веб-страницу, могут зашифровать / расшифровать данные, потому что мы установили сертификат на IIS-сервере (машина D).

Теперь мой вопрос -

  1. Правильно ли это в нашей реализации?

  2. Так работает Always Encrypted?Я имею в виду, что мы не можем использовать индивидуальное шифрование и дешифрование для отдельных пользователей, устанавливая сертификат на отдельном компьютере пользователя, чтобы тот, у кого есть этот доступ к сертификату, мог только пользователь шифровать / дешифровать данные, в противном случае остальным пользователям, у которых нет этого сертификата, могут эти пользователи.видеть только данные в зашифрованном виде на этой веб-странице?

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