Em 31 de outubro de 2011 17:21, Flávio Alves Granato
<[email protected]> 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.

[]s
-- 
Dickson S. Guedes
mail/xmpp: [email protected] - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a