Olá Fábio. > Não faça isso! Ter vários usuários autenticando diretamente do seu > SGDB pode ser um verdadeiro pesadelo! Eu sei, também já cometi este > equívoco e sei até que existem muitos desenvolvedores que gostam desta > idéia. Mas vou dizer os motivos pelo qual é melhor não fazê-lo:
R = Pois é eu concordo em partes contigo, mais já aderi a idéia, em questão dos usúario não terei muitos logados, mais todas as conceções seram persistêntes, mais tenho como servidor um Risc/6000 ela aguenta. > 1) Segurança: se cada usuário possui acesso direto a base, eles > poderão configurar um ODBC, ou utilizar qualquer ferramenta gráfica > (existem muitas) baixadas pela internet e se conectar direto na base. > Você não vai querer seus usuários apagando e alterando dados > diretamente no SGDB sem passar pela aplicação. R = Eu acho que é uma arrogância da minha parte, pensar que eu posso criar um mecanismo de seguranca melhor que o pessoal que desenvolve o DB. Usando o login do próprio DB, e um bom esquema de permissões, o usuário pode até ter acesso via linha de comando, ou outra coisa, mas não vai conseguir fazer muito mais do que faria usando a própria aplicação. > 2) Controle de Acesso: se você quiser controlar o acesso a telas > específicas do sistema, ou restringir a consulta do usuário a uma > faixa de valores (por exemplo os dados dos clientes que ele gerencia), > o Banco de Dados não vai lhe permitir isto, então você vai ter que > criar uma estrutura separada em uma tabela para controlar isto, ou > seja vai ter mais trabalho que antes! R = Eu acredito que não, no meu caso aqui estou trabalhando em uma instuição militar, imaginando o seguinte cenário, eu tenho três usúarios, "Coronel", "Major", "Atendente", o atendente pode ver os registros, exceto pelo campo Viatures, que é um campo secreto. O Major pode ver o campo Viatures, mais não pode aterá-lo. O Coronel pode fazer o que ele quiser, eu tentaria algo assim mais ou menos assim. Coronel: sql> GRANT ALL ON db.ocorrencias TO [EMAIL PROTECTED]; Major: sql> GRANT SELECT(ID, Name, Viatures), INSERT(ID, Name), UPDATE(Name) ON db.ocorrencias TO [EMAIL PROTECTED]; Atendente: sql> GRANT SELECT(ID, Name), INSERT(ID, Name), UPDATE(Name) ON db.ocorrencias TO [EMAIL PROTECTED]; > 3) Backup: os usuários do SGDB não entram no dump ao fazer backup do > banco de dados. Você tem que fazer isto manualmente acessando as > tabelas ou views de sistema do banco, como o "Information Schema". > Como o normal é ter apenas um punhado usuários no banco, normalmente > desenvolvedores, DBAs e "usuáios muito especiais", não chega a ser um > problema. R = Concordo com você aqui. > 4) Sincronia de senhas: se você quiser atualizar uma base de dados de > teste com os dados do banco de dados de produção, verá que os usuários > do SGDB não serão atualizados, o que é bom para os desenvolvedores, > mas pode ser ruim, se você quiser que um usuário teste uma nova > funcionalidade da aplicação e não lembre a senha antiga dele. Se os > dados do usuário estiverem numa tabela a parte, isto não será > problema, pois os usuários e senhas serão atualizados automaticamente. R = Posso utilizar um outro banco para testes, em questão das senhas dos usúario eles iram autenticar em uma base de dados Ldap. > 5) Manutenção: é função do DBA verificar quais usuários tem ou não > acesso direto ao Banco de Dados, você não vai querer ter de ficar > atento a todas as novas contratações, férias e demissões na empresa > para ficar criando, apagando, ativando e desativando contas. Também > não vai querer que sua aplicação tenha poder para fazer isto direto no > banco de dados, não seria bom para a segurança da sua aplicação fazer > isso. R = Por que não, eu penso em fazer isso na aplicação sim, porém essa parte da aplicação só teram acesso o pessoal que será administrador do sistema, e existe o DBA que fará a manutenção no DB. Enfim essa é uma questão polêmica ou até gosto, mais é a primeira vez que estou utilizando banco de dados para uma aplicação, pois o cliente exige, em outros casos eu ustilizava serialização em C++. Abraço edm. On 2/9/07, Fabio Telles <[EMAIL PROTECTED]> wrote: > Caro Eder, se você é iniciante em Banco de Dados, vou lhe dar uma dica > de quem já pastou um pouco por aí! > > Não faça isso! Ter vários usuários autenticando diretamente do seu > SGDB pode ser um verdadeiro pesadelo! Eu sei, também já cometi este > equívoco e sei até que existem muitos desenvolvedores que gostam desta > idéia. Mas vou dizer os motivos pelo qual é melhor não fazê-lo: > > 1) Segurança: se cada usuário possui acesso direto a base, eles > poderão configurar um ODBC, ou utilizar qualquer ferramenta gráfica > (existem muitas) baixadas pela internet e se conectar direto na base. > Você não vai querer seus usuários apagando e alterando dados > diretamente no SGDB sem passar pela aplicação. > > 2) Controle de Acesso: se você quiser controlar o acesso a telas > específicas do sistema, ou restringir a consulta do usuário a uma > faixa de valores (por exemplo os dados dos clientes que ele gerencia), > o Banco de Dados não vai lhe permitir isto, então você vai ter que > criar uma estrutura separada em uma tabela para controlar isto, ou > seja vai ter mais trabalho que antes! > > 3) Backup: os usuários do SGDB não entram no dump ao fazer backup do > banco de dados. Você tem que fazer isto manualmente acessando as > tabelas ou views de sistema do banco, como o "Information Schema". > Como o normal é ter apenas um punhado usuários no banco, normalmente > desenvolvedores, DBAs e "usuáios muito especiais", não chega a ser um > problema. > > 4) Sincronia de senhas: se você quiser atualizar uma base de dados de > teste com os dados do banco de dados de produção, verá que os usuários > do SGDB não serão atualizados, o que é bom para os desenvolvedores, > mas pode ser ruim, se você quiser que um usuário teste uma nova > funcionalidade da aplicação e não lembre a senha antiga dele. Se os > dados do usuário estiverem numa tabela a parte, isto não será > problema, pois os usuários e senhas serão atualizados automaticamente. > > 5) Manutenção: é função do DBA verificar quais usuários tem ou não > acesso direto ao Banco de Dados, você não vai querer ter de ficar > atento a todas as novas contratações, férias e demissões na empresa > para ficar criando, apagando, ativando e desativando contas. Também > não vai querer que sua aplicação tenha poder para fazer isto direto no > banco de dados, não seria bom para a segurança da sua aplicação fazer > isso. > > Bom, acho que é isso.... o barato pode sair caro, principalmente em > termos de segurança. > > []s > Fábio Telles > > > > Em 08/02/07, Euler Taveira de Oliveira<[EMAIL PROTECTED]> escreveu: > > Eder wrote: > > > > > R = Euler como eu disse, não entendo muito de banco de dados, mais > > > discordo de você, em relação a maior controle. O controle efetuado > > > pelo banco de dados é definitivo, um bom gerenciamento de acesso no > > > banco ira assegurar a minha aplicacao e qualquer outra coisa que o > > > usuario utilize para acessar o banco. > > > > > Acho que você me entendeu mal. O controle a que refiro é o controle > > sobre os dados. O SGBD faz um controle a nível de estrutura (colunas, > > tabelas, visões, funções, etc), mas ele não consegue controlar se um > > dado registro na tabela 'foo' pode ser acessado pelo usuário 'bar'. > > > > > Eu olhei a documentação, mais não encontrei nada em relação ao que eu > > > quero fazer, eu precessaria arrumar alguma forma do usúario do próprio > > > SGBD ver a sua matricula, onde estará suas permissões de acesso, pelo > > > menos por enquando. > > > > > Ainda não entendi o que deseja fazer. Você queria que o usuário 'fulano' > > consultasse a matrícula que está em uma tabela e utilizar esta matrícula > > para fazer o acesso? Se for isso você vai ter que utilizar uma variável > > de sessão para que a informação 'matricula' "propage" pelo sistema. > > Caso queira fazer as permissões pelo SGBD mesmo, porque não criar o > > usuário como sendo o número da matrícula? > > > > regression=# create user "001234"; > > CREATE ROLE > > regression=# create user "001234-07"; > > CREATE ROLE > > regression=# \du > > Lista de roles > > Nome da role | Super-usuário | Cria role | Cria BD | Conexões | Membro > > de > > --------------+---------------+-----------+---------+-----------+----------- > > 001234 | não | não | não | ilimitado | > > 001234-07 | não | não | não | ilimitado | > > postgres | sim | sim | sim | ilimitado | > > (3 registros) > > > > regression=# > > > > > > -- > > Euler Taveira de Oliveira > > http://www.timbira.com/ > > > > _______________________________________________ > > 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 > > > > > -- > 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 > -- Ederson de Moura Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie) _______________________________________________ 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
