Chiappa, primeiramente, gostaria de agradecer sua ajuda, suas colocações e soluções são sempre de muita valia, OBRIGADO. Em resposta às suas solicitações, sequem minhas respostas:
01 -- se há um POOL de conexões aí ou não (e qual é ele, se houver, especificando softwares/APIs/versões/modo pelo qual o pool foi implementado/criado); NÃO existe pool de conexão. 02 -- diga se cada comando SQL é executado numa nova sessão ou não, que aí a gente pode tentar te dar alternativas para permissão POR SESSÃO, isso sim existe; SIM, cada comando SQL é executado numa nova sessão. O controle desejado seria justamente POR SESSÃO CRIADA. Em um cenário onde os usuários que acessam o sistema via web e que estão CADASTRADOS no DB com ROLES ATRIBUÍDAS de "CONNECT", "RESOURCE", e uma "ROLE_X" específica com permissão de ALTER, DELETE, EXECUTE,INSERT,SELECT,UPDATE em tabelas do sistema, como política de segurança, o que se deseja é que os usuários fiquem apenas com permissão de sistema de "CREATE SESSION" adquirindo as ROLES de "CONNECT", "RESOURCE", e uma "ROLE_X" específica com permissão de ALTER, DELETE, EXECUTE,INSERT,SELECT,UPDATE em tabelas do sistema PELA SESSÃO CRIADA/ABERTA, E QUE QUANDO ESTA SESSÃO FOSSE FECHADA, VIA SISTEMA OU DERRUBADA DO BROWSE, ESTA SESSÃO FOSSE DESFEITA E ESTAS PERMISSÕES FOSSEM REVOGADAS. 03 -- isso vai passar por roles não-default ou por contextos globais sendo acessados por trigger de logon ou coisas assim. SIM. O desejável seria que fossem roles não DEFAULT que seriam ativadas por conta da conexão e desativadas quando do logoff, ou término da sessão. Ps.: Atualmente, com adaptações ao meu cenário, foi implementado trigger de logon e logoff. Fonte da Implementação: http://www.dba-oracle.com/art_builder_sec_audit.htm e livro "Physical Database Design Using Oracle" de "Donald K. Burleson". Gostaria ainda de sua sugestão nesta trigger para o acréscimo do usuário do S.O., OSuser e dos IP´s das máquinas. 2.2 Re: PROXY USER Qua, 21 de Out de 2015 8:01 pm . Enviado por: jlchiappa Opa, blz ? Sobre o PROXY USER, entre outras fontes vc pode dar uma olhada no meu blog, em https://jlc1967.wordpress.com/2015/02/12/conectar-como-outro-usuario/ eu dou um exemplo curtinho. O mecanismo de funcionamento dele é bem simples : o usuário X que já existe no database e que recebeu o privilégio de connect proxy para o schema Y, vai poder criar uma sessão no database conectado como se fosse o usuário Y - ou seja, o usuário X que recebeu o priv de proxy em Y para todos os efeitos práticos dentro do database, se tornou o usuário Y, é como se Y estivesse conectado.... OBVIAMENTE, se a pessoa está conectada na prática como se fosse Y, ela vai poder fazer *** TUDO *** o que Y faz - inclusive , se Y é dono de tabelas, CLARO que vai poder fazer qualquer coisa, INCLUSIVE dropar, o dono faz TUDO que quiser com suas tabelas... Um exemplinho disso : => crio um usuário zemanéqualquer, que não tem priv de nada: SQL@system:XE> create user zezinho identified by zezinho; Usußrio criado. SQL@system:XE> grant create session to zezinho; ConcessÒo bem-sucedida. => dou permissão pro zezinho se tornar na prática o HR (dono de tabelas) : SQL@system:XE> alter user HR grant connect THROUGH zezinho; Usußrio alterado. ===> prontinho : fornecendo a sua própria senha o zezinho vai poder se tornar o HR, conectar como se fosse o HR,mesmo sem saber a senha do HR : SQL@system:XE> connect zezinho[HR]/zezinho Conectado. SQL@zezinho:XE> select * from departments; DEPARTMENT_ID DEPARTMENT_NAME MANAGER_ID LOCATION_ID ------------- ------------------------------ ---------- ----------- 10 Administration 200 1700 20 Marketing 201 1800 30 Purchasing 114 1700 40 Human Resources 203 2400 50 Shipping 121 1500 ... 270 Payroll 1700 27 linhas selecionadas. ==> como o zezinho "virou" o HR, pode até dropar as tabelas do HR, pode MESMo fazer tudo o que o HR faz : SQL> drop table hr.tab_teste; Tabela eliminada. SQL> Blz ???? COM ABSOLUTA CERTEZA **** não é isso **** que vc quer, não é portanto caso pro PROXY USER, ** a não ser ** que vc dê permissão de fazer proxy para um usuário que só tenha recebido os GRANTs de INSERT/UPDATE/DELETE que vc quer dar - proxy pro usuário dono das tabelas da aplicação não faz O MENOR SENTIDO...... Já que vc fala de dar GRANTs de INSERT/UPDATE/DELETE, o que eu faria na verdade é o simples : como DBA, crio (apenas uma vez) uma role ROLE_INS_UPD_DEL_APPLIC, dou os GRANTs de INSERT, UPDATE e DELETE nas tabelas em questão paraa role, e ok : daí pra frente , quando e se cada usuário necessitar, eu como DBA (ou a Aplicação via uma tela específica, enfim, se tiver que ser Automatizado) dou o grant da Role parao usuário, e quando necessário retiro o aceso à role via REVOKE.... ===> O único senão é que vc diz : ".... determinadas permissões do dono do sistema/tabelas para efetuar ** transações ** específicas tais como: Insert, Update, Delete...." - vamos deixar bem claro, primeiro, que no RDBMS Oracle uma TRANSAÇÃO é o que é aberto automaticamente pelo primeiro INSERT/UPDATE/DELETE que o banco receber numa sessão , e ela é Encerrada com COMMIT ou ROLLBACK - INSERT/UPDATE/DELETE ** não ** representam em si e por si uma Transação... Segundo, rigorosamente **** NÃO EXISTE **** o conceito de permissão apenas para uma Transação num RDBMS , e em especial no RDBMS Oracle : as permissões valem imediatamente após o GRANT, e VÃO PERMANECER presentes até que um REVOKE as elimine,TENHA ou NÃO sido aberta uma transação, tenha ou não desconectado a sessão que fez o grant, não importa.... []s Chiappa OBS : estando CLARO que permissão por Transação ** não existe **, se for o caso, Explica direitinho pra gente sobre o seu ambiente (ie, se há um POOL de conexões aí ou não (e qual é ele, se houver, especificando softwares/APIs/versões/modo pelo qual o pool foi implementado/criado), diga se cada comando SQL éexecutado numa nova sessão ou não, que aí a gente pode tentar te dar alternativas para permissão POR SESSÃO, isso sim existe : isso vai passar por roles não-default ou por contextos globais sendo acessados por trigger de logon ou coisas assim, mas Só COm os DETALHES todos a gente pode te indicar mais direitinho as alternativas... Amigos, Boa noite... Meu oracle é: banner ---------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 version_bit ------------------------ 10.2.0.3.0 - 64bi Arquivamento -------------------- STARTED Amigos, estou precisando implementar o recurso "PROXY USER" e estou tendo dificuldades, gostaria que algum dos amigos com maior experiência no oracle demonstrasse com detalhes como o processo ocorre. Em uma aplicação que é acessada via web, onde o usuário cadastrado no banco tem apenas o privilégio de sistema de "create session", preciso que o mesmo, ao conectar-se no sistema adquira o "CONNECT, RESOURCE " e determinadas permissões do dono do sistema/tabelas para efetuar transações específicas tais como: Insert, Update, Delete, as quais poderiam ser repassadas ao usuário que se conecta via web por uma role específica se for o caso, e ao sair, que essas permissões fossem revogadas. Agradeço a atenção e a ajuda... Atenciosamente, [image: Foto Cristiano Vasconcelos Barbosa] *Cristiano Vasconcelos Barbosa.'.* * Analista de Sistemas & Banco de Dados* | Cel: +55 (85) 9691.8331 ------------------------------ http://br.linkedin.com/in/cristianovasconcelos *DEUS MEUMQUE JUS*.'. *DÓMINI SUMUS*.'. Contact me: [image: Google Talk] cvasconcel...@gmail.com [image: Skype] cvasconcelosb [image: MSN] cvasconcel...@hotmail.com [image: Y! Messenger] cvasconcel...@yahoo.com.br [image: My QR VCard] <http://s.wisestamp.com/links?url=http%3A%2F%2Fbr.linkedin.com%2Fin%2Fcristianovasconcelos&sn=Y3Zhc2NvbmNlbG9zYkBnbWFpbC5jb20%3D>
