Всегда зашифрованное поведение в SQL Server 2016

Question

Я делал демо-версию в SQL Server 2016 для темы Всегда зашифрован. У вас мало сомнений. Ниже приведены шаги, а затем:

В Сервер баз данных (размещенных в Microsoft Azure VM):

1. В таблице MyTable, создания ключа шифрования столбца ключа (CEK) и Master Encryption Key (CMK)
2. Select * from MyTable, показывает зашифрованные данные. (оба из приложения и сервера БД)
3. Экспортированные сертификат от сервера базы данных
4. импортирован сертификат в Сервер приложений (мой локальный компьютер)
5. Добавил Column Encryption Setting=Enabled в строку подключения моего приложения.
6. Он работает нормально, теперь он показывает данные обычного текста, как ожидалось.

Сомнение:

В сервере баз данных (в MS Azure VM), Если SysAdmin Логин (SQL Authentication) подключается к SSMS с дополнительным параметром Column Encryption Setting=Enabled, Это показывает данные простые текстовые (ожидающие зашифрованные данные). Насколько я понимаю, никто из пользователей приложения не должен видеть текстовые данные). Кто-нибудь может прояснить?

Answer 1

На шаге 3 вы указываете, что вы экспортируете сертификат с сервера баз данных, чтобы обеспечить максимальную безопасность, never сохраните свой сертификат на сервере базы данных. Серверу не нужно иметь доступ к сертификату.

Если SysAdmin Логин (SQL Authentication) подключается к SSMS с дополнительного шифрования параметра Column значение = Enabled, Это показывает простые текстовые данные (ожидающие зашифрованные данные). Мое понимание таково: no другой, а затем пользователи приложений должны видеть простые текстовые данные). Может ли кому-нибудь пояснить?

Если SysAdmin подключается к SSMS с клиентской машины, у которой есть сертификат, и если у SysAdmin есть разрешение на доступ к сертификату, они будут видеть текстовые данные.

Грубо говоря, всегда шифруется предоставляет следующие гарантии безопасности, данные Plaintext будут видны только для лиц, имеющих доступ к ColumnMasterKey (сертификат)

---

Для разработки, Рассмотрим следующий сценарий.

Рассмотрим две машины:

• machineâ: машина, на которой SQL Server работает
• MachineT: Клиентская машина.

Рассмотрим два пользователя

• UserA (это технически может быть группа пользователей, но я буду рассматривать сценарий с одним пользователем для простоты): Кто является администратором на machineâ, управление SQL-сервером и SysAdmin на SQL-сервере. Однако userA не имеет никакого доступа к MachineT и UserA не должен расшифровывать любые зашифрованные данные, хранящиеся в SQL Server на машине A (зашифрованные данные в контексте этого ответа являются данными, которые являются зашифрованный с использованием функции «Зашифрованная шина SQL Server»).

• UserT (это технически может быть группа пользователей, но я буду рассматривать сценарий с одним пользователем для простоты): доверенный пользователь имеет доступ к MachineT, имеет доступ ко всем данным в база данных db, которая размещена в SQL Server по адресу MachineA. Кроме того, поскольку userT доверено, он должен иметь возможность расшифровать зашифрованные данные.

Рассмотрим SQL Server работает на machineâ имеет базы данных БД и таблицу т.

Наша цель состоит в том, чтобы обеспечить столбец, принадлежащий таблице т, скажем ssnCol, так что только userT должны быть в состоянии увидеть ssnCol в незашифрованном виде.

Цель, описанная выше, может быть достигнута с использованием следующих шагов.

• UserT журналы в MachineT.
• UserT открывает SSMS в MachineT.
• UserT подключается к SQL Server на Мачинеа
• UserT шифрует ssnCol в таблице т с помощью шагов, указанных в Encrypt columns (configure Always Encrypted) секции this article
• После этого шага, столбец ssnCol бы быть зашифрованным.

Когда userT шифрует ssnCol способа, описанный выше, два ключа генерируется

• ЦОК: ЦМК известного колонка мастер-ключ является ключом, который используется для шифрования CEK/с , Этот ключ хранится в хранилище сертификатов окон MachineT.
• СЕК: СЕК аки столбец ключ шифрования является ключом, который используется для шифрования ssnCol, этот ключ хранится в зашифрованном виде в SQL Server на machineâ и не сохраняется в любом месте текста.

Следовательно, для того, чтобы дешифровать ssnCol, СЕК требуется, однако, для того, чтобы расшифровать CEK, ЦМК требуется.

Поскольку ЦМК находится в хранилище сертификатов Windows, из machineT только userT может получить доступ к CMK, расшифровать СЕК и расшифровать ssnCol.

ПользовательА является администратором на machineâ, а также SysAdmin на SQL Server, но, так как он/она не имеет доступа к ЦМК, ПользовательА не может получить доступ к ssnCol в незашифрованном виде. Вы можете проверить это, используя SSMS из machineâ, войдя в систему ПользовательА и запрашивая ssnCol

Если у вас есть дополнительные вопросы, пожалуйста, поместите их в комментариях, и я могу ответить на них.

Answer 2

Еще одно и очень важное соображение:

Основных задач Всегда Шифруемый для защиты ваших данных от вредоносных программ, запущенного на компьютере хостинга SQL Server и от злоумышленников высоких привилегий на машину хостинга SQL Server (АБД, sys admins). Если это векторы атак, которые вы хотите адресовать в своем приложении, никогда не следует предоставлять ключи для Always Encrypted на машине, на которой размещен экземпляр SQL Server, который содержит базу данных с столбцами, которые вы хотите защитить. Если вы запустите средство подготовки ключей, например. SSMS или PowerShell, на компьютере, на котором размещен ваш экземпляр, и машина скомпрометирована, злоумышленник может украсть ваши ключи, например. путем очистки SSMS-памяти. И, конечно, если вы создаете сертификат и помещаете его в хранилище сертификатов на серверной машине, для злоумышленника это становится еще проще.

Для получения более подробной информации и полезных рекомендаций обратитесь к https://msdn.microsoft.com/en-us/library/mt708953.aspx#SecurityForKeyManagement.