Конфиденциальность пользователей и безопасность данных в базах данных - PullRequest
1 голос
/ 13 сентября 2011

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

Например, личные данные могут быть ценными, даже если они не связаны напрямую с финансовыми операциями или паролями. [Номера телефонов, адреса электронной почты и т. Д. Могут быть перепроданы]

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

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

У меня вопрос: как можно защитить личные данные, не отвлекаясь от реального назначения данных?

Я вижу необходимость в шифровании всей информации, но это помешает группам получить доступ к данным, связанным с пользователем. Например, вы можете зашифровать почтовые индексы пользователя с помощью закрытого ключа, но как бы вы сохранили возможность использовать информацию о местоположении почтового индекса. [Может быть, предъявить претензию пользователю «эти люди могут быть рядом с вами»]

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

Ответы [ 3 ]

1 голос
/ 13 сентября 2011

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

1 голос
/ 13 сентября 2011

Я предполагаю, что вы указываете, что злоумышленник получил не только доступ к машине, но и любые пароли MySQL.

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

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

Другой вариант - разделить приложение так, чтобы веб-сайт и база данных не использовали одну и ту же систему. И, конечно же, обычно запуск сайта с пользователем, доступным только для чтения, является хорошей идеей & trade; :)

Хранение данных в базе данных в хешированном или зашифрованном виде - хорошее начало, но вам все равно нужен доступ к ключу дешифрования, иначе это будет бред.

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

Эта проблема периодически появляется в прессе, если / когда доступ к списку клиентов банка или магазина осуществляется неавторизованным способом - данные защищены только через интерфейс / приложение: они по-прежнему в открытом тексте в какой-то момент под всем остальным.

0 голосов
/ 13 сентября 2011

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

...