Caro Chiappa, Concordo que quem está com a versão Standard está em desvantagens em relação a features, algumas inclusive considero injustificadas, mas isso é outro assunto. Agora a diferença de preço entre as versões não é tão pequena assim, vamos fazer um exercício simples: 2 servidores com 2 processadores cada em RAC, custo Standard: US$ 60 mil, Enterprise: US$ 240 mil, por essa diferença dá para encarar o "re-desenvolvimento da roda" :-) Sobre as alternativas ao FGA/VPD nos pareceu muito mais trabalhoso, sobre as aplicações de terceiros, tem cada uma que dá nojo, mas eu estou curioso em saber como aplicações conceituadas como SAP ou mesmo o Oracle Business Suite fazem, se eles usam contas do BD ou possuem um controle próprio, eu realmente desconheço, se alguém puder me esclarecer eu agradeço, acho que estes sistemas são boas referências, quanto ao Resource Manager, a mesma restrição para a versão Standard. Abraços, Carlos Alfredo M. de Menezes Analista de Suporte Sr. S/A Usina Coruripe Açúcar e Álcool E-mail: [EMAIL PROTECTED] Fone: (82)3217-2121
________________________________ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: terça-feira, 3 de julho de 2007 10:32 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Autenticação de usuários da aplicação Carlos, realmente se não é Oracle full com certeza se está em desvantagem, há razões pra que o Oracle completo custe mais e uma delas é realmente o nível maior de recursos técnicos embutidos nela (e aí vem aquela "economia" linda, a pessoal "economiza" X não comprando full mas depois gasta X*n em homens-hora "re-desenvolvendo a roda", e quase sempre com resultado inferior), mas é fato... No caso específico dos seus coments, eu diria : 1. da falta de FGA, de forma alguma isso seria impedimento, vc tranquilamente PODERIA ter views parametrizadas que usem o código da empresa/filial como parâmetro via context (cfrme http://asktom.oracle.com/pls/asktom/f? <http://asktom.oracle.com/pls/asktom/f?> p=100:11:0::::P11_QUESTION_ID:1448404423206#6998345721195 ), ou ainda poderia fazer o que imho é ainda melhor, onde possível encapsular o SQL em *** PROCEDURES *** de banco que façam o necessário, daí (óbvio) vc só dá grant de execute na dita procedure 2. realmente, tem aplicações de terceiros por aí abaixo de qquer crítica, que não usam quase NENHUM recurso do banco, que forçam a se ter "segurança", entre aspas totais, pelo aplicativo, a partir do momento em que se tem a má sorte de se cair com uma dessas, é se lamentar e ver o que dá pra remendar, se der, se não der, não se tem o que fazer, ponto 3. para isso é que existem PROFILEs e Resouce Manager nas versões ** modernas ** de banco Oracle, para se limitar a ação de SQLs eventuais, embora a opção de SQL encapsulado não deixe de ser útil em alguns casos pra isso também []s Chiappa --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , "Carlos Alfredo Martins Menezes" <[EMAIL PROTECTED]> escreveu > > Colega, > O texto está muito bem escrito e levanta quase todos os questionamentos envolvidos, eu também acho que o IDEAL seria trabalhar com contas individuais no BD, mas a minha realidade me fez fazer o contrário, veja os motivos: > > 1- A empresa não trabalha com a versão Enterprise, logo a feature FGA não está disponível, o que invialbilizaria construir o nível de segurança apenas usando contas Oracle, por exemplo, não tem como fazer restrições de acesso por empresa/filial, sendo empresa/filial atributos valorados; > > 2- Não tenho apenas aplicações construídas inhouse, tenho aplicações de terceiros que utilizam contas/senhas armazenadas no BD, logo a opção de contas de banco teria alcance limitado; > > 3- Apesar das regras de integridade estarem no BD, a ideía do usuário poder conectar no banco de produção e poder rodar qq SQL sem a devida preocupação com otimização ou fazer uma deleção em massa sem querer, me dá um frio na espinha; > > Atualmente, estamos desenvolvendo uma abordagem mista para as aplicações inhouse, o cadastro de contas dos colaboradores internos estarão marcados com uma flag de autenticação por AD, assim não guardaremos mais as senhas no BD. A autenticação se dá através de Single Sign On através de métodos construídos em Java no BD para validar usuário/senha nos meus servidores controladores de domínio, mas apenas para validar o par usuário/senha, com isso eu elimino a tarefa do usuário decorar mais uma credencial. A aplicação continua se conectando no banco usando apenas uma conta e o controle do que ele pode ou não fazer é feita pela aplicação. > > Esse é um tema polêmico, mas eu acho que não está restrito apenas às considerações técnicas de DBA, é preciso envolver outras opiniões de quem está envolvido com segurança, considerar a cultura organizacional e os recursos de software e o time de técnicos disponíveis. > > Abraços, > > Carlos Alfredo M. de Menezes > Analista de Suporte Sr. > S/A Usina Coruripe Açúcar e Álcool > > > ________________________________ > > De: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> [mailto:oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> ] Em nome de Fabio Telles > Enviada em: terça-feira, 3 de julho de 2007 06:46 > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > Assunto: [oracle_br] Autenticação de usuários da aplicação > > > > Olá senhores e senhoritas, gostaria de uma opinião de vocês sobre um > texto um pouco polêmico que escrevi estes dias a respeito de técnicas > para a aplicação autenticar os seus usuários no banco de dados. > > Gostaria de saber se existem soluções melhores do que as que eu > apontei no texto em: > http://www.midstorm.org/~telles/2007/06/21/autenticacao-de-usuarios- > <http://www.midstorm.org/~telles/2007/06/21/autenticacao-de-usuarios-> em-banco-de-dados/ <http://www.midstorm.org/~telles/2007/06/21/autenticacao-de-usuarios- <http://www.midstorm.org/~telles/2007/06/21/autenticacao-de-usuarios-> em-banco-de-dados/> > > Um abraço para todos, > Fábio Telles > -- > blog: http://www.midstorm.org/~telles/ <http://www.midstorm.org/~telles/> <http://www.midstorm.org/~telles/ <http://www.midstorm.org/~telles/> > > e-mail / jabber: [EMAIL PROTECTED] <mailto:fabio.telles%40gmail.com> > > > > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas]