Em 31/10/2011 18:46, Dickson S. Guedes escreveu: > Em 31 de outubro de 2011 17:21, Flávio Alves Granato > <flavio.gran...@gmail.com> escreveu: >> Senhores, >> >> estou em um dilema pessoal. Como proceder para evitar que dados >> sensíveis sejam lidos por invasores em uma máquina? Penso que posso >> fazer mil voltas na aplicação, colocar GRANT em todas as tabelas, mas se >> houver alguém com acesso à máquina onde estão os dados e isso ocorre não >> só por meios ilícitos, como vocês costumam proteger os dados deste tipo >> de acesso não autorizado? > Se elas ocorrem por problemas ilícitos o problema em si é outro. Todas > as camadas precisam estar bem protegidas, inclusive o sistema > operacional. Este deve proporcionar uma infraestrutura confiável para > que você defina permissões para o usuário que executa o serviço do > banco. Se alguém que tem acesso burlar isso, seus problemas são outros > na realidade. > >> Penso em criptografar os dados sensíveis, seria uma boa idéia? > É um custo elevado para o banco e consequentemente para a aplicação. > Criptografar o backup até vai, mas chegar ao ponto de utilizar um > sistema de arquivos criptografado pode ser um tiro no pé. > >> Como ficaria a auditoria dos dados se pela elevação >> do nível de segurança forçar a troca das chaves criptográficas? Pois >> assim teria que re-criptografar os dados novamente. Ou teria que ter uma >> aplicação de visualização dos dados descriptografados. Qual a >> experiência de vocês com este tipo de questão? > É um ponto delicado, trate as demais camadas primeiramente. Monitore > logs, gere alertas com ferramentas de segurança como snort por > exemplo, crie proteções robustas com regras de firewall bem definidas. > Acho que o começo é por ai... a partir disso você vai começar a ouvir > seu ambiente e provavelmente ele vai te dizer o quão profundo na > segurança você terá que ir. Entendo, mas a solução que você deu não resolve o problema pois por mais que algum funcionário assine um termo de confidencialidade, por mais que você selecione a pessoa, faça testes e muitos outros requisitos de confiabilidade, o que importa são a consistência dos dados e a inviolabilidade do acesso a eles. E encher o kernel de patchs, o firewall de regras e snort + portsentry + ossec ou qualquer outra solução não vai mitigar o risco que levantei. Se por questões de desempenho eu não tomo medidas para manter os dados inacessíveis, por questões de performance também é justo não mantê-los consistentes. Eu gostaria de saber como mitigar este risco absurdo mas que é plausível quando os valores das informações compensarem para alguém quebrar toda a sua ética profissional e roubá-la. Só para não ficar vago, já participei de um projeto em que houve tal situação, antes de eu chegar, mas houve.
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
