Em Ter 05 Dez 2006 08:16, Fabio Telles escreveu: > Em 05/12/06, Euler Taveira de Oliveira<[EMAIL PROTECTED]> escreveu: > > Fabio Telles wrote: > > > Hum... passo por isso diariamente... e vou dizer o que aconteceu: > > > > > > Fui demonstrar o perigo desta abordagem para um fornecedor e peguei um > > > Access e em 1 minuto apaguei uma tabela inteira do sistema... > > > > > > O problema não é só a dificuldade de administrar, mas principalmente > > > de segurança. Os usuários devem ter GRANT para excluir um determinado > > > registro a partir da aplicação, mas não devem se conectar no SGDB e > > > fazer isto diretamente. > > > > > > Você concorda comigo ou tem alguma forma de evitar isto? > > > > Concordo contigo quando você afirma que fica mais inseguro. Mas isso é > > como dar uma shell a um usuário comum num sistema *NIX. Você considera > > isso inseguro? Se as permissões de acesso estiverem bem definidas, você > > pode deixar o usuário fazer somente aquilo que ele pode efetivamente > > fazer. É claro que utilizando este método, um usuário mais esperto > > *pode* utilizar o psql e se conectar ao banco de dados; e mais, pode > > executar comandos perigosos como "DELETE FROM foo" mas isso é o risco > > que você corre. > > Se quiser um ambiente mais seguro, utilize uma metodologia de 3 camadas, > > onde o cliente *não* terá acesso direto ao banco de dados; isso não quer > > dizer que seu banco de dados esteja seguro, apenas que você corre menos > > risco de um usuário esperto fazer alguma besteira. Particularmente, essa > > metodologia traz menos dor de cabeça ao DBA (acho que era essa sua > > queixa, né?). :-) > > Bom... vou citar mais detalhes do caso para colocar mais cor no quadro: > > - Uma aplicação corporativa Client-Server com mais de 2 mil tabelas > feita com Genexus (uma aplicação RAD para gerar código em várias > linguagens) da forma mais idiota possível: sem utilizar praticamente > nenhum recurso do SGDB, nem mesmo FK. A aplicação é de uma empresa > contratada com pouca vontade de concertar tudo. São mais de 1000 > usuários, com 400 a 600 conexões simultâneas diariamente. > > O sistema abrange várias áreas críticas e sensíveis, como toda a > movimentação financeira, folha de pagamento, etc. Num local com mais > de 1500 computadores em rede, a chance de sofrer ataques internos, > fraudes, e usuários fazendo besteira é muito, muuuuito grande!!! > > Estou propondo novas metodologias de autenticação para a aplicação > deles. Eles dizem que precisam da conexão por usuário para poder logar > todas as operações no banco de dados sabendo qual usuário realizou > cada operação. Esta parte eu já consegui resolver para eles. O passo > agora é convencê-los a fazer a aplicação Cliente-Servidor se > autenticar de forma segura e flexível (permitir a troca de senha do > usuário principal). > > A solução que eu sugeri foi uma das apontadas aqui: criar um usuário > com acesso apenas a uma tabela que contenha a senha principal > criptografada. > Outro problema que eu não citei foi de que, ao se conectar com o usuário A, mesmo tendo acesso somente a uma tabela, ainda é possivel consultar as tabelas do sistema (pg_*). Por causa disso, caso alguém descubra a senha de acesso do usuário A, ele pode obter o código fonte de todas as funções que residem no banco. Isso é um problema quando as regras de negócio são colocadas no SGDB na forma de funções e triggers.
> Bem, deu para perceber que o assunto é polêmico, né? > > Mas sem dúvida, como outras pessoas sugeriram aqui... se estivessa na > minha governabilidade, a aplicação COM CERTEZA seria reescrita em > várias camadas. Uma aplicação deste porte leva muita vantagem quando > escrita em 3 ou mais camadas. Mas isto não acontece da noite para o > dia... > > []s > Fábio Telles _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
