Pra complementar, esse _rls da package DBMS_RLS é de Row Level Security, é ainda outra sigla pra mesma coisa, como mostrado em http://www.securityfocus.com/infocus/1743 , por exemplo. Não tem muito jeito, na área de TI nós (DBAs , DAs, SAs, programadores, nós todos enfim) adoramos uma siglazinha...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "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 > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > ------------------------------------------------------ > > 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 > > > -------------------------------------------------------------------------------------------------------------------------- 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
