Ótima idéia. Agradeço a ti e a todos pelas sugestões.
Obrigada!
Bia.
----- Mensagem original ----
De: jlchiappa <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 16:27:34
Assunto: Re: Res: Res: Res: [oracle_br] Segurança
argh, várias pessoas usando o mesmo account Oracle ** E ** regras de
negócio e integridade fora do banco, negocinho triste, horroroso, mas
já dei minha opinião sobre isso em outras msgs, todos já a conhecem
imagino....
Bom, o que vc pode fazer na sua situação, além de lamentar muito a
arquitetura desse sistema, seria :
a) alterar o sistema, de modo que haja um usuário "público", que
todo mundo sabe a senha, mas usuário esse que não tem acesso NENHUM
aos dados de Prod, como o usuário com o qual a tela inicial do
sistema se conecta, só depois do usuário do sistema passou ok da tela
inicial, aí sim o sistema fecha a conexão com o usuário "público" e
abre (numa rotina CRIPTOGRAFADA, sem o usuário final enxergar")
conexão com o usuário real
ou
b) o sistema conecta no banco com um usuário "secreto" que os
operadores não sabem qual é, na tela inicial do sistema, de modo
ESCONDIDO o sistema "guarda" alguma informação num local acessível ao
banco (num arquivo-texto via utl_file, por exemplo) e depois conecta
no usuário atual. Para esse usuário atual há uma ** trigger de logon
** que tenta buscar a informação "guardada", logicamente se o usuário
conectou fora do sistema a tela inicial não guardou a informação, o
trigger de logon não a acha e rejeita a conexão
ou derivadas disso, como o já sugerido (mais de uma vez) trigger de
logon que procura o nome do programa na V$SESSION. Repito, isso está
*** LONGE *** de ser uma segurança inquebrável, apresenta o enorme
problema de possuir uma chave (a tal informação, ou o nome do
usuário, ou a coluna PROGRAM) residindo no banco, ficando portanto
por sua conta "protegê-la" - key management é mesmo um caso sério,
imho a melhor coisa ainda é NÂO TER CHAVE alguma no banco...
[]s
Chiappa
--- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald <dbaemapuros@ ...>
escreveu
>
> Pessoal,
>
> Há um usuário de conexão que tem grants de update, select, insert
e delete nas tabelas do sistema e mais resource e connect.
> Os operadores só tem acesso ao sistema via este usuário. Mas
estavam conectando via TOAD e SQLPLUS e alterando dados. Quero que
este usuário só sirva para conectar via meu sistema .
> Há regras de negócio no sistema..
>
> Obrigada,
> Bia.
>
> ----- Mensagem original ----
> De: jlchiappa <[EMAIL PROTECTED] ...>
> Para: [EMAIL PROTECTED] os.com.br
> Enviadas: Quinta-feira, 24 de Maio de 2007 15:03:43
> Assunto: Re: Res: Res: [oracle_br] Segurança
>
> repito : os dados JÁ DEVIAM estar sendo protegidos diretamente pelo
> banco, via constraints, GRANTs, views, triggers, etc, caso esse em
> que seria *** ABSOLUTAMENTE INDIFERENTE *** se está se fazendo
acesso
> e/ou alterando-os via sistema ou via plus ou via o que for, ok ??
> SE isso não é indiferente, vc NÂO ESTÁ usando esse método mais
> recomendado - provavelmente como eu disse deve estar tendo
> integridade/ regras de negócio sendo efetuadas FORA DO BANCO, pelo
> aplicativo somente, o que não só engessa os dados como disse mas
> também EXIGE alguma codificação especializada e complexa, e NÂO É
> GARANTIDO, certo ? Se esse é o seu caso, é ir pra trigger de logon
> mesmo provavelmente , MAS SABENDO que não está fazendo o correto e
> idela, há FRAQUEZA inerente à essa lógica, sim ?
>
> []s
>
> Chiappa
> --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald
<dbaemapuros@ ...>
> escreveu
> >
> > A intenção é proteger os dados. Que eles não sejam alterados via
> aplicativos, somente pelo executável do próprio sistema. O usuário
X,
> só poderá fazer acesso ao BD via sistema e não pelos aplicativos de
> acesso ao Oracle.
> > Obrigada pela ajuda,
> > Bia.
> >
> >
> > ----- Mensagem original ----
> > De: jlchiappa <jlchiappa@ ..>
> > Para: [EMAIL PROTECTED] os.com.br
> > Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
> > Assunto: Re: Res: [oracle_br] Segurança
> >
> > Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no
> bd
> > Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem
> está
> > conectando, não há MESMO nenhum código no kernel que tente
> > identificar. ... Isso faz TODO o sentido inclusive, já que
> informações
> > do cliente estão FORA DO CONTROLE do banco, e podem ser
> falsificadas
> > de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos
> > colegas e tentar capturar o nome do programa numa trigger, E SE
> > alguém fizer um rename sqlplus.exe to nomepermitido. exe, por
> > exemplo ???? Acho muito muito ** frágil ** essa lógica....
> > Segundo item : idealmente, as regras de negócio estão NO BANCO DE
> > DADOS, via triggers, constraints, relacionamentos, views, etc,
> assim
> > NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão
> lá,
> > os grants estão lá, as views estão lá, e cada usuário final do
> > sistema tem o seu usuário de banco, o qual só ele sabe a senha,
> então
> > o usuário final *** só vai enxergar *** o que pode, ** só vai
fazer
> > ** o que tem direito, independente da tool, ok ? Normalmente quem
> > tenta fazer restrição desse tipo baseado no aplicativo é porque
tem
> > regras de negócio NO APLICATIVO, aí as coisas realmente podem
> quebrar
> > se a pessoa conectar com outra coisa que não o aplicativo.. . ..
Sem
> > sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA",
> ela
> > NUNCA vai poder aposentar esse aplicativo sem perda de dados,
NUNCA
> > vai poder usar tools de query/busioness intelligence sem extensa
> > customização .... Afora o desenvolvedor do aplicativo (que tem
> > serviço garantido), acho que NINGUÉM fica feliz com isso.
> >
> > ==> o meu ponto asim é : SE realmente vc tiver que fazer esse
> enrome
> > contra-senso, conheça os pontos fracos, ok ?
> >
> > []s
> >
> > Chiappa
> >
> > --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald
> <dbaemapuros@ ...>
> > escreveu
> > >
> > > ahhh, sim.. Muito obrigada.
> > > :)
> > >
> > >
> > > ----- Mensagem original ----
> > > De: Gustavo Venturini de Lima <gventurini@ ...>
> > > Para: [EMAIL PROTECTED] os.com.br
> > > Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> > > Assunto: Re: [oracle_br] Segurança
> > >
> > > Na verdade a trigger não fica ligada a ninguém... Ela fica
> > escutando o
> > > "banco todo" no geral...
> > > Se "algo" satisfazer a condição da trigger, ela será ativada....
> > > No caso, utilize uma "AFTER LOGON ON DATABASE"
> > > Parecido com isso:
> > >
> > > CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> > > BEGIN
> > > .
> > > {suas condições e ações}
> > > .
> > > END;
> > >
> > > Em 23/05/07, Bia Fitzgerald <dbaemapuros@ yahoo.com. br>
escreveu:
> > > >
> > > > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o
> tempo
> > > > inteiro.
> > > > Mas uma Trigger ficaria ligada a quem??
> > > > Obrigada.
> > > >
> > > > ----- Mensagem original ----
> > > > De: Gustavo Venturini de Lima <gventurini@ gmail.
> com<gventurini%
> > 40gmail.com>
> > > > >
> > > > Para: [EMAIL PROTECTED] os.com.br <oracle_br%40yahoog
> > rupos..com. br>
> > > > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > > > Assunto: Re: [oracle_br] Segurança
> > > >
> > > > Bia, para o Oracle a conexão será a mesma (independente do
> método
> > > > utilizado).
> > > > Porém, podes fazer uma trigger que consulte o campo "program"
da
> > > > v$session..
> > > > Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para
> > desconectar
> > > > o
> > > > usuário...
> > > > Ou então colocar que se for <> de NOME_DA_SUA_ APP ele
> desconecta
> > o
> > > > cara...
> > > >
> > > > Em 23/05/07, Bia Fitzgerald <dbaemapuros@ yahoo.com. br>
> escreveu:
> > > > >
> > > > > Olá pessoal...
> > > > >
> > > > > Alguém sabe como impedir que um determinado usuário acesse
o
> BD
> > via
> > > > > aplicativos como sqlplus e TOAD e somente acesse via
sistema?
> > > > > Obrigada,
> > > > > Bia.
> > > > >
> > > > > ____________ _________ _________ _________ _________ __
> > > > > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > > > > http://br.messenger .yahoo.com/
> > > > >
> > > > > [As partes desta mensagem que não continham texto foram
> > removidas]
> > > > >
> > > > >
> > > > >
> > > >
> > > > [As partes desta mensagem que não continham texto foram
> removidas]
> > > >
> > > > ____________ _________ _________ _________ _________ __
> > > > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > > > http://br.messenger .yahoo.com/
> > > >
> > > > [As partes desta mensagem que não continham texto foram
> removidas]
> > > >
> > > >
> > > >
> > >
> > > [As partes desta mensagem que não continham texto foram
removidas]
> > >
> > >
> > >
> > >
> > > ____________ _________ _________ _________ _________ __
> > > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > > http://br.messenger .yahoo.com/
> > >
> > > [As partes desta mensagem que não continham texto foram
removidas]
> > >
> >
> >
> >
> >
> > ____________ _________ _________ _________ _________ __
> > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > http://br..messenge r .yahoo.com/
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
> ____________ _________ _________ _________ _________ __
> Fale com seus amigos de graça com o novo Yahoo! Messenger
> http://br.messenger .yahoo.com/
>
> [As partes desta mensagem que não continham texto foram removidas]
>
__________________________________________________
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
[As partes desta mensagem que não continham texto foram removidas]
