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]
