Em 01/11/2011 11:02, Dickson S. Guedes escreveu:
>> 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 forem bem aplicadas vão mitigar, mas provavelmente não o suficiente
> para o cenário que você está propondo.
vão mesmo e acabei esquecendo de um zabbix que pode vigiar também quando
há acesso à máquina fora de horário e mesmo no horário de trabalho. Vai
mitigar mais o risco, assim aumentando um 9 nos 99,... do projeto.
>
>> 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.
> Por isso que eu disse que utilizar um sistema de arquivos
> criptografado *pode ser* um tiro no pé. Você *tem* que tomar medidas
> para manter os dados inacessíveis sim! Concordo com você, mas IMHO
> existe um limiar que você tem que definir: até que ponto você vai para
> manter esses dados assegurados durante o transporte?
Concordo e realmente tem que ser levado em conta este limiar.
>
> O PostgreSQL nativamente não possui suporte para manipular dados
> criptografados, no nível de coluna por exemplo, como você encontra num
> SQL Server por exemplo. Você até consegue alguns cenários com
> granularidade bem configurada utilizando SE/PostgreSQL mas não diz
> respeito à criptografia e si mas sim contextos de acesso.
Não conheço SQL Server e nem outro qualquer a um nível deste. Mas seria
interessante uma feature destas no PostgreSQL, mas a idéia é impedir o
acesso deixando apenas um usuário com token, senha, autenticação 2 ou 3
fatores, sei lá...
>
> Você pode ter um sistema de arquivos criptografado como um EFS por
> exemplo, comunicação inter-processos criptografadas, cache de
> controladora criptografado e pode até tentar fazer o swap
> criptografado também, entretanto o PostgreSQL tem suporte a SSL entre
> o banco e a aplicação. Essas medidas vão mitigar a maior parte dos
> riscos.
concordo e já ajuda muito!
>
>> Só para não ficar vago, já participei de um projeto em que houve tal
>> situação, antes
>> de eu chegar, mas houve.
> E foi um caso de sucesso? Que dificuldades foram encontradas? Quais os
> pontos fortes e fracos?
na realidade eles partiram para o ditado "gato escaldado tem medo de
água fria", ou seja, passaram a dúvidar do programador e o programador
ficava 1 ano sem acesso a internet e nunca poderia ser admin de sua
máquina, depois disso ele passaria a acessar a internet, ou seja depois
de provado sua "confiabilidade". Apesar de ser um ótimo caso de sucesso
de postgres ainda faltava muita coisa no datacenter, eles só tinham uma
máquina com o banco e escalavam muito bem a aplicação. Esta aplicação
dava conta sorrindo de 2 milhões de transações diárias, envolvia outros
sistemas legados e o SGBD deles nunca reclamou de nada, mesmo não tendo
um dba na equipe... quando deixei o projeto eles já estavam pensando em
melhorar a infra de persistência das informações e já estava havendo
brainstorms para isso.
>
> Enfim, é um assunto vasto e interessante, vamos ver com o quê os
> outros colegas com mais experiência podem contribuir.
>
É um assunto muito inressante mesmo e envolve várias áreas da computação.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
