Res: Res: Res: Res: [oracle_br] Segurança
Ó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 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 > 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 > > 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 > > exe
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 oracle_br@yahoogrupos.com.br, Bia Fitzgerald <[EMAIL PROTECTED]> 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: oracle_br@yahoogrupos.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 > 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 > > 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 ? Normalment
RES: Res: Res: [oracle_br] Segurança
Porque voce não cria uma senha específica para esse usuário do oracle e coloque dentro do seu sistema sem que ninguém tenha acesso? Qual a plataforma do sistema? Se for windows/WEB pode criar por exemplo um arquivo UDL com a senha gravada (fica exposto porque não criptografa) mas aí vc tira as permissões do diretório e só deixa o administrador e o IUSR ter acesso a ele. Se for desktop, coloque dentro do sistema. O problema é que terá que recompila-lo em caso de alteração de senha. Depois disso, o pessoal terá que entrar no sistema para mexer no banco visto que ninguém mais saberá a senha. abraços -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Bia Fitzgerald Enviada em: quinta-feira, 24 de maio de 2007 15:31 Para: oracle_br@yahoogrupos.com.br Assunto: Res: Res: Res: [oracle_br] Segurança 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] <mailto:jlchiappa%40yahoo.com.br> com.br> Para: [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> 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 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 <[EMAIL PROTECTED] ..> > 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 > escreveu > > > > ahhh, sim.. Muito obrigada. > > :) > > > > > > - M
Res: Res: Res: [oracle_br] Segurança
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: oracle_br@yahoogrupos.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
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 <[EMAIL PROTECTED] ..>
> 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
> escreveu
> >
> > ahhh, sim.. Muito obrigada.
> > :)
> >
> >
> > - Mensagem original
> > De: Gustavo Venturini de Lima
> > 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 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 40gmail.com>
> > > >
> > > Para: [EMAIL PROTECTED] os.com.br 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
