Mas eu pensei em dar os grants por SESSAO e nao PERMANENTEMENTE para o usuário... Até pq se o infeliz fechar a aplicação essas permissões vao ficar para o usuário..
Como eu faço para que o próprio usuário dê direito de grant em uma role para ele permanentemente? Thiago. Ederson escreveu: > Neste ponto vc pode abstrair que se a conexão do Reports é com o mesmo > usuário que se conectou no Forms, ele já possui as roles habilitadas, > então: > NO PROBLEM ! > > > Ederson Elias de Oliveira > DBA Oracle > Setransp - Goiânia-GO > ------------------------------------------------------------------- > > -----Mensagem original----- > De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em > nome de Thiago Lazzarotto > Enviada em: sexta-feira, 31 de março de 2006 16:04 > Para: oracle_br@yahoogrupos.com.br > Assunto: Re: [oracle_br] RES: Estratégia de segurança > > Ok, solução interessante, mas como eu faço com os reports? > Em cada report aberto eu tenho que fazer essa assinatura? Isso pq o > report abre outra conexão no banco... > > Ederson escreveu: > > > Thiago, > > > > Estou trabalhando em uma empresa que já tinha política de segurança, > onde > > algumas coisas ainda precisam ser melhoradas, mas coloco aqui o > modelo prá > > vc avaliar: > > > > - Cada usuário tem um user no banco, direito de > connect/create_session(sem > > resource) > > - os usuários são criados pela aplicação (uma senha restrita que tem > > direito > > de create user), que criptografa a senha do usuário e informa ao > oracle a > > senha criptografada. Assim, se o usuário colocou a senha "b5128", > ela será > > informada ao banco (por exemplo) "gg¨^*(" sempre entrando caracteres > > especiais não printáveis, para dificultar a digitação. Assim, o > > usuário não > > sabe a senha dele, jamais poderá se conectar com o SqlPlus, nem com o > > PLSqlDeveloper, etc... > > - quando o usuário carrega a aplicação, abre-se uma tela pedindo > usuário e > > senha. O usuário informa (por exemplo) joao/b5128, a aplicação > > criptografa a > > senha informada e passa ao banco um "connect joao/[EMAIL PROTECTED]" e o > > banco > > aceita a conexão ou a recusa, se os dados informados estiverem errados. > > - existe o owner dos dados, e a senha deste é de conhecimento > restrito ao > > DBA e (em documento) do gerente da área. > > - para os objetos do owner, foi criado um sinônimo público (calma!) > > - foi criado roles de privilégios, separando por categoria de usuários. > > - Para estas roles, cada uma tem direitos nos objetos do owner de > > acordo com > > o que se precisa utilizar dele > > - aos usuários, é dado o grant da role que ele precisa para usar o > > sistema. > > - Do lado do sistema, existe um controle de permissão que INIBE o > > menu/opção_de_menu que aquele usuário não terá acesso. Então, só > liberar a > > opção do menu NÃO libera consulta nos dados e liberar só a role de > > direitos > > não libera a opção no menu. > > > > Teste de segurança: > > > > - Se abrir um SqlPlus e digitar: joao/[EMAIL PROTECTED] vai dar "invalid > > username/password" > > - caso a rede seja invadida e alguém "snifou" e conseguiu separar um > > pacote > > que continha o connect, ele conseguirá se conectar ao SqlPlus, com > alguma > > dificuldade, mas ao fazer o select * from cat; não virá nenhum objeto, > > pois > > o usuário não possui nenhum. > > - caso o invasor conheça a view ALL_OBJECTS, aí já será um problema > a ser > > barrado pelas roles. > > - existe um recurso que "recusa" conexões do SqlPlus de um usuário, > > isto tb > > pode ser usado para melhorar a segurança. > > > > > > Uma sugestão (Utópica, possível implementar): > > - não dar o grant das roles ao usuário: > > - no momento da conexão, uma trigger database é disparada e insere uma > > linha > > em uma tabela do owner dos dados, informando também uma assinatura da > > conexão em MODULE (informada à V$session via dbms.application_info) > > - aquela tabela possui uma trigger que executa uma procedure que > > verifica se > > aquela assinatura é da aplicação e se for, dá o grant das roles daquele > > usuário (lendo em uma tabela). Caso a conexão seja por ferramentas de > > terceiros, não será "assinado" a conexão e a procedure não dará os > > direitos > > das roles para o usuário conectado. Então o cara está conectado, vê > o nome > > das tabelas em ALL_OBJECTS mas não consegue fazer select, nem > update, nem > > insert, nem delete em nenhuma daquelas tabelas ... > > > > Que tal ?? > > > > > > Ederson Elias de Oliveira > > DBA Oracle > > Setransp - Goiânia-GO > > ------------------------------------------------------------------- > > > > -------------------------------------------------------------------------------------------------------------------------- > Atenção! As mensagens deste grupo são de acesso público e de inteira > responsabilidade de seus remetentes. > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ > > Este Grupo recebe o apoio da SQL Magazine - > www.devmedia.com.br/sqlmagazine > __________________________________________________________________ > O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, > tenha o link do mesmo para evitar trafego(pedidos) desnecessário. > > > ------------------------------------------------------------------------ > *Links do Yahoo! Grupos* > > * Para visitar o site do seu grupo na web, acesse: > http://br.groups.yahoo.com/group/oracle_br/ > > * Para sair deste grupo, envie um e-mail para: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do > Serviço do Yahoo! <http://br.yahoo.com/info/utos.html>. > > -- -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __________________________________________________________________ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
