Как лучше всего зашифровать / расшифровать данные SQL Server, чтобы даже разработчики не могли их увидеть?

Question

Вот интересная проблема, и я ищу шаблон, который сделает все это работоспособным.

Я создаю приложение для умного клиента для школьной системы. Он будет содержать информацию о студентах, включая их табели успеваемости, больничные и т. Д. он будет генерировать отчеты на уровне учеников, включая их табели успеваемости, каждый из которых будет содержать очень личные комментарии своих учителей. Приложение будет получать данные с удаленного сервера через веб-сервисы.

Так что данные довольно конфиденциальны. Я зашифрую его в базе данных и расшифрую при извлечении - никаких проблем там нет.

Проблема в том, что я и моя команда должны никогда не видеть данные открытого текста. Тогда возникает интересная проблема для исследования производственных ошибок! Мы хотим открыть ту же запись, что и пользователь, чтобы увидеть то, что он видит. Но если мы ДЕЛАЕМ, мы нарушаем конфиденциальность.

Моя мысль такова, и она не идеальна.

• Сначала зашифруйте данные перед сохранением в базе данных, расшифруйте их в пользовательском интерфейсе. Там ничего нового.
• Во-вторых, поместите механизм в пользовательский интерфейс, чтобы скрыть привилегированные данные. (т. е. имена и повествование учителя являются привилегированными; уровень образования - нет.) Я не буду шифровать это, но запутывать его - даже простой смены ключей будет достаточно. Причина в том, что эти отчеты полны текста. Если я зашифрую абзац и покажу результат в отчете, это будет сплошная стена из заглавных букв, не похожая на оригинальный текст. Если я сделаю сдвиг клавиш алфавитных символов, это будет нечитаемо, но все равно будет выглядеть как абзацы, предложения, маркированные списки и тому подобное. Будет легче увидеть, что происходит, не добавляя визуальных усложнений.
• В-третьих, я установил настройку конфигурации, чтобы выполнить обфускацию пользовательского интерфейса только для членов, скажем, роли SysAdmin, а не учителя или SchoolAdmin. Во время разработки я установил эту конфигурацию в False, и мы разрабатываем против фальшивого открытого текста. Для производства мы установили для него значение True, и с этого момента мы видим только запутанный текст.

Наконец, для тех случаев, когда мы абсолютно ДОЛЖНЫ видеть открытый текст записей учащегося, у нас есть настройка переопределения в пользовательском интерфейсе, которая противоречит настройке конфигурации и представляет открытый текст. И нам это удается на человеческом уровне - информируя администрацию школы о том, что в ЭТУ дату по ЭТОЙ причине нам нужно будет просмотреть ЭТУ студенческую запись и т. Д. Подписи подписаны, дано ворчливое согласие, юристы разбираются со своими самолетами, промывают повторить.

Мысли? Я чувствую, что это должно быть протоптанной землей. Пожалуйста, помогите мне улучшить этот план, если это возможно.

Answer 1

Когда мы работали в команде с похожей проблемой, нам пришлось использовать огромное количество ложных данных. Производство было ВСЕГДА угадайкой. Никому не разрешили узнать ни одного из шифров.

EDIT

Если вы хотите быть в полной безопасности, вы позволите сторонней компании обрабатывать данные, что ставит их в положение защиты данных и гарантирует, что вам не предъявят иск в случае ошибки. Просто мой .02

Answer 2

Итак, в целом я подхожу к этому следующим образом:

SQL-сервер имеет функции шифрования - либо прозрачное шифрование (которое не подходит для вашего случая, поскольку вы увидите дешифрованные данные в запросах), либо шифрование на основе ключей, где учетные записи пользователей имеют ACL на ключе. С помощью этого метода вы создаете сертификат X509 на самом сервере SQL, а затем генерируете симметричные ключи с подходящими списками ACL. Затем в хранимых процедурах вы можете открыть симметричный ключ для возврата незашифрованных данных в ваше приложение. Конечно, вы должны подключаться к SQL через безопасные средства - вы можете поместить сертификат X509 на сервер SQL для защитных подключений.

Конечно, теперь у вас есть проблема управления ключами. Вы можете создать определенную учетную запись Windows для своего приложения для запуска со случайным надежным паролем, который сбрасывается, как только вы настраиваете пул приложений, а затем добавляете эту учетную запись NT в SQL (если вы находитесь в доменной среде, это легко Для этого в рабочих группах необходимо отразить учетную запись на сервере IIS и SQL). Для отладки вам понадобится другая учетная запись с доступом к ключам. Пароль для этой учетной записи должен быть настроен как «разбитое стекло» - храниться где-то, что можно проверить, или половина пароля будет разделена между двумя или более людьми, которые должны согласиться, с формальным подтверждением того, что это необходимо (а затем оно изменяется после использования )

Здесь есть введение в шифрование SQL здесь , но оно не охватывает ACL. На MSDN имеется целый раздел , который также охватывает средства проверки подлинности и различные доступные вам параметры.

Или вы можете использовать веб-службу шифрования, которую вы вызываете для шифрования данных, при этом возвращается GUID-ссылка на ключ и зашифрованный текст. Таким образом, ключ может храниться в хорошо защищенной базе данных, а функции дешифрования могут быть защищены для каждой учетной записи. Опять же, вам нужно иметь аккаунт разбитого стекла. Я сделал это, когда клиенты не чувствуют себя достаточно уверенно, чтобы самостоятельно управлять шифрованием SQL.

Answer 3

Одна вещь, которую вы обязательно должны иметь, - это неизменный контрольный журнал. Всякий раз, когда кто-либо получает доступ к любым конфиденциальным данным, создается контрольная запись. В таких случаях, как системные администраторы, запрашивающие доступ к данным отчета, которые они обычно не должны просматривать, регистрируются исключения.

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

Answer 4

На самом деле вам не нужно расшифровывать данные в пользовательском интерфейсе. В SQL Server есть инструменты для шифрования в реальном времени. Если кому-то нужно увидеть открытый текст, его можно было бы назначить на роль, которая дала бы ему это разрешение (и была бы удалена, когда он был готов).

Однако, если просмотр данных нарушает конфиденциальность, очевидно, что вы никогда не сможете увидеть производственные данные. Единственное решение - это копия данных с ложными или совершенно случайными данными.