É, relendo realmente não ficou bem claro no meu texto original, mas é isso mesmo : vc indica o elemento participante do SQL (seja tabela ou view ou similar), o banco "monitora" os SQLs recebidos, assim que um SQL com esse elemento chegar, o SQL é "capturado", alterado adicionando-se o WHERE desejado, e essa versão alterada é que será executada, sim...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, Anderson Haertel Rodrigues <[EMAIL PROTECTED]> escreveu > > >VPD (Virtual Private Database), com esse recurso > >automaticamente o banco vai "interceptar" cada SQL > que >vc indicar > Só para ficar mais claro, você não indica o SQL > (SELECT), e sim a Tabela, View ou Sinônimo. > > No 10g, você ainda pode ir mais longe, além de indicar > a Tabela (como citado acima), tu pode indicar o nome > da Coluna (isto é, se no SELECT enviado, conter o nome > da Tabela e o nome da Coluna), o VPD/RLS/FGAC entra em > ação. > > Anderson Haertel Rodrigues > Administrador de Banco de Dados - DBA > Florianópolis/SC > > > > > --- jlchiappa <[EMAIL PROTECTED]> escreveu: > > > Não é FGA, é FGAC que eu disse (Fine Grained Access > > Control), FGAC > > sim é o mesmo que VPD, sim, é implementado pela > > package citado. > > FGA existe, é sim implementado pela DBMS_FGA sim, > > mas FGA (Fine > > Grained Audit) serve pra auditoria, é coisa > > diferente . > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, [EMAIL PROTECTED] > > escreveu > > > > > > Chiappa, > > > VPD e FGA não são coisas diferentes? VPD > > não seria para > > > controlar a segurança à nivel de linha e a nível > > de coluna, e FGA > > não > > > seria para fazer auditoria de instruções SELECT e > > DMLs? A package > > de > > > manipulação do VPD seria o DBMS_RLS e do FGA o > > DBMS_FGA, correto? > > > > > > > > > Abs > > > Jonathan Barbosa > > > > > > ----- Original Message ----- From: "jlchiappa" > > <[EMAIL PROTECTED]> > > > To: <oracle_br@yahoogrupos.com.br> > > > Sent: Tuesday, March 28, 2006 1:38 PM > > > Subject: [oracle_br] Re: Segurança > > > > > > > > > Bom, não há uma receita de bolo exata e precisa > > pra isso, mas de > > modo geral : > > > > > > necessidade 1, criptografar : vc vai precisar > > escrever uma pequena > > > rotina pra isso, tradicionalmente isso era feito > > com a package > > > DBMS_OBFUSCATION_TOOLKIT, no 10g foi introduzida a > > DBMS_CRYPTO, que > > é > > > uma melhoria dela. No manual 10g de Supplied > > Packages vc acha as > > > sintaxes e alguns exemplos de ambas, em > > > > > > http://www.dbasupport.com/oracle/ora10g/10g_PLSQL01.shtml > > , > > > > > > http://www.dbasupport.com/oracle/ora10g/DBMS_OBFUSCATION_TOOLKIT.shtml > > > e http://asktom.oracle.com (use a opção Search > > procurando por > > > DBMS_CRYPTO) algumas dicas. > > > > > > necessidade 2, restringir acesso de acordo com > > usuário : primeira > > > coisa, o nome do usuário que fez a inserção ** NÃO > > ** fica > > > automaticamente guardado em lugar algum, vc VAI > > ter que guardar > > isso > > > pra poder usar depois na hora de SELECTs - o mais > > comum seria vc > > ter > > > uma coluna NOME_USUARIO nas tabelas, provavelmente > > preenchida > > > automaticamente por um trigger. Uma vez vc já > > tendo a informação > > de > > > quem inseriu (e portanto pode "enxergar") cada > > linha, pra que cada > > > usuário só "veja" os seus registros, OU vc só dá > > pros usuários > > acesso a > > > uma VIEW que filtra isso, tipo CREATE VIEW > > V_TABELA as (select * > > from > > > tabela where NOME_USUARIO=user; , OU então vc usa > > o recurso do FGAC > > > (Fine Grained Access Control), também conhecido > > como VPD (Virtual > > > Private Database), com esse recurso > > automaticamente o banco vai > > > "interceptar" cada SQL que vc indicar e adicionar > > uma condição de > > WHERE > > > , no caso a condição de where NOME_USUARIO=user , > > o que dá o > > resultado > > > desejado também. []s > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br, "Ricardo > > Lyrio" <[EMAIL PROTECTED]> > > escreveu > > > > > > > > Tenho a seguinte situação: > > > > > > > > Oracle 10gR2, e preciso implementar segurança > > em determinadas > > > colunas de > > > > algumas tabelas da seguinte maneira: > > > > > > > > Um usuário que cadastrou um registro na tabela > > A somente ele e > > mais > > > ninguém > > > > poderá ver o registro, inclusive num select com > > permissões de DBA > > > eu não > > > > posso ver o conteúdo do registro, ele precisa > > vir criptografado. > > > > > > > > Alguém tem alguma idéia de qual caminho seguir? > > > > > > > > Abraço a todos e desde já agradeço a ajuda > > > > > > > > Ricardo Lyrio > > Anderson Haertel Rodrigues > Administrador de Banco de Dados - DBA > Florianópolis/SC > > > > > > > > > _______________________________________________________ > Yahoo! doce lar. Faça do Yahoo! sua homepage. > http://br.yahoo.com/homepageset.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
