Como impedir que os programadores capturem os dados inseridos pelos usuários?

Estou desenvolvendo um aplicativo da Web com um forte foco em segurança. Que medidas podem ser tomadas para impedir que aqueles que trabalham no aplicativo (programadores, DBAs, equipe de garantia de qualidade) capturem valores inseridos pelo usuário que devem ser bem protegidos, como senhas, números de previdência social e assim por diante?

security

— Peter Smith
fonte

Gostaria de sugerir que você postar a pergunta em: security.stackexchange.com/?as=1

— NoChance

"Prevenir" é uma palavra muito forte. Você não pode impedir que atores ruins façam coisas ruins. O que você pode fazer é aprender e aplicar princípios fundamentais de segurança como "menos privilégio", "separação de tarefas" e "negação implícita", arquitetar as coisas de maneira segura e contratar pessoas em quem você possa confiar. Tenha planos viáveis para mitigar os danos quando o inevitável eventualmente ocorrer.

— Robert Harvey

Os termos técnicos para as tecnologias necessárias: hash e criptografia.

— Robert Harvey

Respostas:

Isto é bem simples. Os bancos fazem isso o tempo todo.

Você tem três grupos de pessoas envolvidas. Estes são grupos de segurança. Com autorizações distintas.

Os desenvolvedores não podem atribuir autorizações de segurança e não podem ver dados de produção.

Os operadores não podem atribuir autorizações de segurança e não podem criar software.

Pessoal de segurança que define as autorizações e não pode criar software nem operar o software.

Os desenvolvedores criam software. Os operadores instalam e operam. O pessoal de segurança garante que os dois grupos sejam mantidos separados.

— S.Lott
fonte

OK, mas um desenvolvedor ainda pode adicionar algo ao sistema que envia por e-mail os dados de produção para sua conta privada; ou grava dados de produção em algum servidor em que ele os coleta. Eu acho que a única maneira de contornar isso é com um rigoroso regime de revisão de código.

— Dawood ibn Kareem

Sempre existe esse nível de confiança que é dado aos funcionários. Alguém tem que ter as chaves do palácio, e se você não pode confiar que eles entendem o poder que lhes é dado, talvez não devamos dar essas chaves para essa pessoa em primeiro lugar.

— Chris

Sim, mas possuir chaves que exijam mais de uma pessoa (como o regime de revisão de código) significa que você precisa de duas para se "desviar" antes de ser comprometido e isso é menos provável que "apenas um" funcionário se desvie e abuse da chave dada a eles. É tudo uma questão de equilibrar a confiança e as consequências dessa confiança sendo abusada. E não esqueça que as pessoas e as circunstâncias mudam. A trustwhorthy pessoa quando as chaves são dadas pode ter coisas acontecem na vida pelo qual ele (a) se torna menos confiável ...

— Marjan Venema

@EmmadKareem: Correto. O responsável pela segurança define e redefine grupos e senhas, mas não pode ver dados. Somente operadores podem ver dados reais. Pense em dados como dinheiro real manipulado por caixas reais. Programadores não tocam no dinheiro; apenas caixas para. Da mesma forma, as pessoas da segurança não tocam no dinheiro; somente caixas tocam dinheiro.

— S.Lott

@EmmadKareem: os DBAs não são desenvolvedores. Existem dois grupos: segurança e dados. DBAs de dados são uma parte especial de "operações". Eles não devem ter autorização para alterar a segurança; eles não podem escrever código; eles verão dados, no entanto, e devem ser tratados como operadores, não como desenvolvedores.

— S.Lott

Os programadores não têm acesso aos servidores de produção. Mas alguém tem que ter acesso. Não há maneira de contornar isso. E sempre há uma chance de alguém ficar louco e abusar de seu acesso.

Os dados que são hash / salgados são teoricamente seguros, mesmo das pessoas que têm acesso total para visualizá-los. Mas a maioria dos dados não é apropriada para o hash.

— Lord Tydus
fonte