Как лучше всего шифровать/дешифровать данные SQL Server для предотвращения даже разработчиков от наблюдения его?
Вот интересная проблема, и я ищу шаблон, который сохранит все это осуществимым.
Я создаю приложение умного клиента для школьной системы. Это будет содержать информацию о студентах включая их табели успеваемости, больные дни, и т.д. это генерирует отчеты студенческого уровня, включая их табели успеваемости, каждых богатых с очень персональным комментарием их учителей. Приложение получит данные из удаленного сервера через веб-сервисы.
Таким образом, данные являются довольно конфиденциальными. Я зашифрую его в базе данных и дешифрую его на извлечении - без проблем там.
Проблема состоит в том, что моя команда и я никогда не должны действительно видеть производственные данные простого текста. Интересная проблема появляется затем для исследования производственных ошибок! Мы захотим открыть ту же запись как пользователь для наблюдения то, что они видят. Но если мы ДЕЛАЕМ мы нарушаем конфиденциальность.
Моя мысль - это, и это не прекрасно.
- Во-первых, зашифруйте данные прежде, чем сохранить в базе данных, дешифруйте его в UI. Ничто нового там.
- Во-вторых, поместите механизм в UI для запутывания привилегированных данных. (т.е. имена и рассказ учителя привилегированы; год обучения не.) Я не зашифрую его, но запутаю его - даже простой ключевой сдвиг был бы достаточен. Так как причина, эти отчеты полны текста. Если я зашифрую абзац и покажу результат в отчете, то это будет твердая стена символов верхнего регистра, не смотря ничто как оригинальный текст. Если я сделаю ключевой сдвиг на буквенных символах, то это будет нечитабельно, но будет все еще похоже на абзацы, предложения, маркированные списки и т.п.. Будет легче видеть то, что идет не так, как надо, не добавляя визуальную сложность.
- В-третьих, я вставил параметр конфигурации для выполнения, эта путаница UI только для членов говорят, роль SysAdmin, не Учитель или SchoolAdmin. Во время разработки я установил эту конфигурацию на Ложь, и мы разрабатываем против поддельного простого текста. Для производства мы устанавливаем его на Правда, и от той точки вперед, мы только видим запутываемый текст.
Наконец, для тех случаев, где мы абсолютно ДОЛЖНЫ видеть простой текст записей студента, у нас есть установка переопределения в UI, который отменяет параметр конфигурации и представляет простой текст. И мы управляем этим на человеческом уровне - информирование администрации школы, что в ЭТУ дату поэтому мы должны будем видеть запись ЭТОГО студента и т.д. Знак offs подписывается, ворчливое согласие дано, адвокаты скремблированы своим струям, промывке и повторению.
Мысли? Я чувствую, что это должно хорошо шагаться земля. Помогите мне изменить к лучшему этот план, если это возможно.
4 ответа
На самом деле вам не нужно расшифровывать данные в пользовательском интерфейсе. В SQL Server есть инструменты для шифрования в реальном времени. Если кому-то нужно было увидеть открытый текст, его можно было бы отбросить до роли, которая дала бы ему это разрешение (и отменила бы, когда они закончили).
Однако, если просмотр данных нарушает конфиденциальность, очевидно, что вы никогда не сможете увидеть производственные данные. Единственное решение - это копия данных либо с измененными данными, либо с полностью случайными данными.
Одна вещь, которую вы обязательно должны иметь, - это неизменяемый контрольный журнал. Каждый раз, когда кто-либо обращается к конфиденциальным данным, создается запись аудита. В случаях, когда системные администраторы запрашивают доступ к данным отчета, которые они обычно не должны просматривать, исключения регистрируются.
Клиент должен внедрить бизнес-процесс для регулярной проверки любых исключений в журнале аудита. Это должно одновременно служить сдерживающим фактором для злоупотребления системой и позволять проводить расследования постфактум, если кто-то действительно станет мошенником.
В общем, я подошел к этому следующим образом:
SQL-сервер имеет функцию шифрования - либо прозрачное шифрование (которое не подходит для вашего случая, поскольку вы увидите расшифрованные данные в запросах), либо шифрование на основе ключа, когда учетные записи пользователей имеют ACL на ключе. С помощью этого метода вы создаете сертификат X509 на самом сервере SQL, а затем генерируете симметричные ключи с подходящими ACL. Затем в ваших хранимых процедурах вы можете открыть симметричный ключ, чтобы вернуть незашифрованные данные вашему приложению. Конечно, вы должны подключаться к SQL с помощью безопасных средств - вы можете поместить сертификат X509 на SQL-сервер для защиты подключений.
Конечно, теперь у вас возникла проблема управления ключами. Вы можете создать конкретную учетную запись Windows для запуска вашего приложения со случайным надежным паролем, который будет сброшен, как только вы настроите пул приложений, а затем добавите эту учетную запись NT в SQL (если вы находитесь в среде домена, это легко для этого в рабочих группах необходимо зеркалировать учетную запись на сервере IIS и SQL). Для отладки вам понадобится еще одна учетная запись с доступом к ключам. Пароль для этой учетной записи должен быть настроен в виде «разбитого стекла» - храниться где-то, что можно проверить, или половина пароля используется двумя или более людьми, которые должны согласиться, с формальным подтверждением того, что это необходимо (и затем он изменяется после использования )
Здесь есть введение в шифрование SQL , но оно не распространяется на ACL. В MSDN есть целый раздел , который также охватывает аутентификаторы и различные доступные вам опции.
Или вы можете использовать веб-службу шифрования, которую вы вызываете для шифрования данных, она возвращает ссылку GUID на ключ и зашифрованный текст. Таким образом, ключ может храниться в хорошо защищенной базе данных, а функции дешифрования могут быть защищены для каждой учетной записи. Опять же, вам придется иметь счет в битком стекле. Я делал это, когда клиенты не чувствовали себя достаточно уверенно, чтобы самостоятельно управлять шифрованием SQL.
Поскольку мы работали в команде с аналогичной проблемой, нам пришлось использовать огромное хранилище фиктивных данных. Производство ВСЕГДА было наугад. Никому не разрешалось знать какие-либо шифры.
РЕДАКТИРОВАТЬ
Если вы хотите быть в полной безопасности, вы позволите сторонней компании обрабатывать данные, это поставит их в положение защиты данных и гарантирует, что вам не будут предъявлены иски в случае ошибки. Только мой .02