Как хранить данные в БД, чтобы никто не имел доступа к ним? - PullRequest
2 голосов
/ 27 октября 2011

Скоро мы выпустим приватную бета-версию веб-сайта национальной экономики.

Сайт, конечно же, собирает информацию из личной финансовой ситуации пользователя (идентифицируемой только по электронной почте): зарплата, аренда, счета, ссуды и т. Д. Все это действительно конфиденциальная информация и не должна быть доступна никому, даже нам. , техн. чел.

Каковы оптимальные методы хранения данных в нечитаемом виде? Конечно, пароли членов уже хэшированы в БД.

Я думаю о том, чтобы зашифровать все данные с помощью какого-то ключа. Но опять же, приложению необходим доступ к этому ключу. И я не хочу хранить это в БД. Если предоставлено пользователем, я думаю, я мог бы сохранить его в сеансе для расшифровки каждого полученного результата БД. Но как насчет накладных расходов?

Пожалуйста, кто-нибудь с руководящими принципами?

Ответы [ 3 ]

1 голос
/ 27 октября 2011

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

Могут существовать стандарты, применимые к вашим данным, в зависимости от того, где вы находитесь и с какими отраслями вы работаете.Ищите их и следуйте за ними.

1 голос
/ 27 октября 2011

Любой пользователь с правами администратора (например, ваши технические специалисты) может получить доступ к любым ключам дешифрования, хранящимся на машине.Что касается сеанса, любой администратор может делать дампы памяти, чтобы извлекать ключи из сеанса.

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

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

0 голосов
/ 27 октября 2011

Как насчет второй ключевой фразы, защищенной пользовательской ключевой фразой?Когда он войдет в систему, его второй будет расшифрован и сохранен.

...