Как я могу запретить программистам захватывать данные, введенные пользователями?

Я разрабатываю веб-приложение с упором на безопасность. Какие меры могут быть приняты, чтобы не дать тем, кто работает с приложением (программистам, администраторам баз данных, персоналу по обеспечению качества), захватывать введенные пользователем значения, которые должны быть надежно защищены, такие как пароли, номера социального страхования и т. Д.?

security Питер Смит
источник

Я бы посоветовал вам опубликовать вопрос в: security.stackexchange.com/?as=1

NoChance

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

Роберт Харви

Технические термины для технологий, которые вам нужны: хеширование и шифрование.

Роберт Харви

Ответы:

Это довольно просто. Банки делают это все время.

В вас вовлечены три группы людей. Это группы безопасности. С разными разрешениями.

Разработчики не могут назначать авторизации безопасности и не могут видеть производственные данные.

Операторы не могут назначать разрешения безопасности и не могут создавать программное обеспечение.

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

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

С. Лотт
источник

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

Дауд ибн Карим

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

Крис

Да, но наличие ключей, для которых требуется более одного человека (например, режим просмотра кода), означает, что вам нужно двое, чтобы «сбиться с пути», прежде чем вы скомпрометированы, и это менее вероятно, чем «только один» сотрудник сбился с пути и злоупотребил ключом, данным для их. Все зависит от баланса доверия и последствий злоупотребления этим доверием. И не забывайте, что люди и обстоятельства меняются. Человек, которому доверяют, когда ему дают ключи, может иметь в жизни вещи, благодаря которым он становится менее заслуживающим доверия ...

Марьян Венема

@ EmmadKareem: правильно. Специалист по безопасности устанавливает и сбрасывает группы и пароли, но не может видеть данные. Только операторы могут видеть реальные данные. Думайте о данных как о реальных деньгах, с которыми обращаются настоящие кассиры. Программисты не трогают деньги; только кассирам. Точно так же охранники не касаются денег; только кассиры касаются денег.

S.Lott

@EmmadKareem: администраторы баз данных не являются разработчиками. Есть две группы: безопасность и данные. DBA данных - это особая часть «операций». Они не должны иметь разрешения на изменение безопасности; они не могут писать код; однако они будут видеть данные и должны рассматриваться как операторы, а не разработчики.

S.Lott

Программисты не имеют доступа к рабочим серверам. Но кто-то должен иметь доступ. Там нет никакого способа обойти это. И всегда есть шанс, что кто-то может сойти с ума и злоупотребить своим доступом.

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

Лорд тидус
источник