Impedindo acesso não autorizado ao banco de dados
Autor: Mario Leonel Martinez Junior | Publicado: 2014-05-10T15:45:00-04:00

&nbsp; O tema de Hoje,&nbsp; em mundo ideal, seria desnecessário, porem como não vivemos em um mundo ideal, vamos lá.Imaginem a seguinte situação: Em uma empresa, instituição organização ou whatever que seja, existem aplicações , programas e pessoas, todas com suas necessidades de acesso em relação ao banco de dados, a rede, servidor de impressão, arquivos etc..OK , mas para manter a ordem e a segurança, é necessário seguir alguns critérios para que o caos não se instaure.Em relação a segurança podemos dizer que o usuário deve possuir permissões para realizar o seu trabalho, nem mais nem menos.Assim o correto é que se defina os níveis de acesso baseado na atividade a ser realizada.É muito comum todos solicitarem acesso a tudo sem critério ou sem a mínima preocupação em mapear a real necessidade do usuário. Eu uso as seguintes perguntas para definir o acesso: O que o usuário faz?(qual sua função)Por que ele faz ?(Quantos usuários desse tipo teremos?)Como ele Faz? (aqui as vezes detectamos rotinas de trabalho erradas e ai podemos sugerir melhorias-O famoso ensinar o peão a trabalhar)Qual o objetivo?(o que deve ser atingido?) Certo com isso eu continuo: O que o usuário pensa que precisa? (Não é lindo quando um usuário vem com aquela: preciso do mesmo acesso de fulano! eu adoro isso)O que o usuário quer? (querer e precisar são coisas bem diferentes ne?)O que ele vai ter! Com essas perguntas podemos peneirar bem e chegar ao perfil mais adequado a cada usuário.Existe também a regra ou lei do menor privilegio, ela determina que o usuário dever ter permissão somente para o que ele precisa fazer nada mais.Conforme outras necessidades forem surgindo novas permissões serão concedidas.(ao invés de liberar tudo de cara). Assim o usuário de banco é criado, definimos as permissões e concedemos as roles e cada role a um tipo de usuário, lindo.Como as coisas podem sair erradas assim?Fácil nunca duvide da capacidade humana de certos indivíduos em fazer merda!Um fulaninho pode passar seu usuário e senha para o ciclaninho, um espertão pode ficar de olho na senha de outro usuário ou simplesmente alguém que saiba a senha de maior acesso pode passar, por querer ,para alguém com menor privilegio de acesso.Enfim, o ser humano é muito criativo, e quando e trata de fazer coisas erradas alguns se superam.Pode-se também sofrer ataques externos de engenharia social ou mesmo digital para roubo de senhas, isso acontece o tempo todo.Recentemente descobri alguns programadores marotões usando um usuário que só a aplicação deveria usar, logo tomei a ação mais logica para mim avisei meus colegas e superiores e sugeri a troca da senha da aplicação.Ai vira a aquela choradeira, o povo que cuida da aplicação chora, por que eles tem que alterar a senha na aplicação em mil lugares, da trabalho, nunca tem tempo para isso, o mimi de sempre.Como responsável pelo banco o DBA também não pode permitir a brecha de segurança, assim os DBAs devem ser criativos para resolver problemas.Então surge o cenário do nosso artigo, como restringir o acesso dos programadores ao banco sem mudar a senha do usuário que eles não deveriam estar usando? Eu já havia feito algo parecido antes em outra empresa , criando uma trigger que permitia a conexão em um determinado usuário somente por um lista de ips.Vejam o código abaixo da trigger: &nbsp; 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,'Você não tem permissão para logar no Banco de Dados'); END IF; END; Certo, no caso acima todos que tentarem se conectar com os usuários especificados no in só poderão se conectar se a origem da conexão vier dos ips definidos no if ,se não recebem a mensagem “'Você não tem permissão para logar no Banco de Dados”&nbsp; na cara e são desconectados. Tudo graças a função SYS_CONTEXT que nos permite coletar algumas informações a nivel de sessão, no caso usei o parâmetro IP_ADDRES para coletar o ip de origem da conexão, existem vários parâmetros bem legais e podem ser conferido no seguinte link de documentação da Oracle: http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions165.htm  Certo mas no meu caso atual não da para usar o ip como delimitador pois todos usam o mesmo ip, assim bolei o script abaixo:  CREATE OR REPLACE TRIGGER LOGIN_SCAN_AUT&nbsp;&nbsp; AFTER LOGON&nbsp;&nbsp; ON DATABASEDECLAREBEGIN&nbsp;&nbsp; IF DBMS_STANDARD.LOGIN_USER like&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ('AD_APP%')&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AND SYS_CONTEXT ('USERENV', 'OS_USER') NOT IN ('root','mario.Martinez','Oracle',’app')&nbsp;&nbsp; THEN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RAISE_APPLICATION_ERROR (-20001, 'Login Scan Detectou acesso não autorizado , você será desconectado agora! :) ');&nbsp;&nbsp; END IF;END; Neste caso, se o nome do usuário de banco for parecido com AD_APP e o usuário do sistema operacional não for uns dos listados no SYS_CONTEXT o meliante recebe a seguinte mensagem: Login Scan Detectou acesso não autorizado , você será desconectado agora!na cara e sua conexão cai. Essa função é bem útil, vale lembrar que qualquer usuário que possua a role dba não será bloqueado para trigger, os usuários system e sys então estão livres dessa verificação. Bom para mim isso foi bem útil espero que ajude !