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

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

security

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

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

— NoChance

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

— Роберт Харви

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

— Роберт Харви

Ответы:

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

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

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

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

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

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

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

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

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

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

— Крис

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

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

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

— S.Lott

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

— S.Lott

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

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

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