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. 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 -- site: http://www.midstorm.org/~telles/ e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ 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
