que precisa? (Nao e lindo quando um usuario vem com aquela: preciso do mesmo acesso de fulano! eu adoro isso)O que o usuario quer? (querer e precisar sao coisas bem diferentes ne?)O que ele vai ter! Com essas perguntas podemos peneirar bem e chegar ao perfil mais adequado a cada usuario.Existe tambem a regra ou lei do menor privilegio, ela determina que o usuario dever ter permissao somente para o que ele precisa fazer nada mais.Conforme outras necessidades forem surgindo novas permissoes serao concedidas.(ao inves de liberar tudo de cara). Assim o usuario de banco e criado, definimos as permissoes e concedemos as roles e cada role a um tipo de usuario, lindo.Como as coisas podem sair erradas assim?Facil nunca duvide da capacidade humana de certos individuos em fazer merda!Um fulaninho pode passar seu usuario e senha para o ciclaninho, um espertao pode ficar de olho na senha de outro usuario ou simplesmente alguem que saiba a senha de maior acesso pode passar, por querer ,para alguem com menor privilegio de acesso.Enfim, o ser humano e muito criativo, e quando e trata de fazer coisas erradas alguns se superam.Pode-se tambem sofrer ataques externos de engenharia social ou mesmo digital para roubo de senhas, isso acontece o tempo todo.Recentemente descobri alguns programadores marotoes usando um usuario que so a aplicacao deveria usar, logo tomei a acao mais logica para mim avisei meus colegas e superiores e sugeri a troca da senha da aplicacao.Ai vira a aquela choradeira, o povo que cuida da aplicacao chora, por que eles tem que alterar a senha na aplicacao em mil lugares, da trabalho, nunca tem tempo para isso, o mimi de sempre.Como responsavel pelo banco o DBA tambem nao pode permitir a brecha de seguranca, assim os DBAs devem ser criativos para resolver problemas.Entao surge o cenario do nosso artigo, como restringir o acesso dos programadores ao banco sem mudar a senha do usuario que eles nao deveriam estar usando? Eu ja havia feito algo parecido antes em outra empresa , criando uma trigger que permitia a conexao em um determinado usuario somente por um lista de ips.Vejam o codigo abaixo da trigger: CREATE OR REPLACE TRIGGER dba_logon_trigger AFTER LOGON ON DATABASE BEGIN IF SYS_CONTEXT('USERENV','IP_ADDRESS') in ('192.168.12.23','192.168.12.19','192.168.12.21','192.168.12.22','192.168.12.29','192.168.12.50') and user in ('BASERO','ETRO','SLC','SLG','SLGTEC','SLT',FUNDO','SIG') THEN RAISE_APPLICATION_ERROR(-20003,'Voce nao tem permissao para logar no Banco de Dados'); END IF; END; Certo, no caso acima todos que tentarem se conectar com os usuarios especificados no in so poderao se conectar se a origem da conexao vier dos ips definidos no if ,se nao recebem a mensagem 'Voce nao tem permissao para logar no Banco de Dados na cara e sao desconectados. Tudo gracas a funcao SYS_CONTEXT que nos permite coletar algumas informacoes a nivel de sessao, no caso usei o parametro IP_ADDRES para coletar o ip de origem da conexao, existem varios parametros bem legais e podem ser conferido no seguinte link de documentacao da Oracle: http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions165.htm Certo mas no meu caso atual nao da para usar o ip como delimitador pois todos usam o mesmo ip, assim bolei o script abaixo: CREATE