Olá Euler.
Concordo com você em relação a segurança dos dados de empresas diferentes em
um mesmo banco.
Mas, se o Veil realmente for implementado, será uma ótima solução.
Pois controlar os dados em uma única tabela é muito mais prático.


At.te,
Alisson Viegas
[EMAIL PROTECTED]
---
Acsiv Sistemas
www.acsiv.com.br


-----Mensagem original-----
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Em nome de Euler
Taveira de Oliveira
Enviada em: quarta-feira, 10 de dezembro de 2008 18:15
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] RES: Banco Multiempresa

Adriano Espinoza de Oliveira escreveu:
> hummm qdo eu fiz isso eu fiz na aplicação...
> Mas no banco seria interessante...talvez colocando em duas tabelas
> diferentes... com um usuario que tem permissao somente para uma tabela e
> outro usuario que tem permissao para as duas... 
Isso se chama permissão a nível de registros. Existe um projeto chamado veil
[1] que faz exatamente isso. Seguindo a mesma linha, está em processo de
revisão o SE-PostgreSQL [2] que é um controle de acesso baseado na política
de
segurança do SELinux; se tudo correr bem, ele estará no 8.4.

Sobre o assunto, eu *não* misturaria dados de empresas distintas em uma
mesma
tabela sem utilizar um controle de permissões a nível de registros (como os
descritos acima) porque seria fácil, senão trivial, conseguir dados
indevidos.
Como alguns colegas sugeriram, eu optaria por utilizar esquemas para separar
empresas e utilizaria a nomenclatura nomedomodulo_nomedoobjeto para designar
os objetos (tabelas, funções, visões, etc).


[1] http://pgfoundry.org/projects/veil/
[2] http://wiki.postgresql.org/wiki/SEPostgreSQL


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a