Ó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]