ustify>
Clique aqui para ler todos os artigos desta edição
Banco de dados privados virtuais no Oracle 10g
Uma solução robusta para a segurança dos dados.
Márcio Alexandre de Oliveira Pinto
A solução adotada para a atribuição de privilégios e perfis aos usuários de um sistema normalmente é baseada na aplicação, ou seja, existe um módulo do sistema corporativo responsável pela autenticação e atribuição de direitos aos usuários.
Porém, existe um problema na adoção deste tipo de solução que normalmente passa despercebido: caso um usuário conecte-se ao banco através de qualquer outro aplicativo que não seja o da empresa, sem acessar esse módulo de controle de acesso, este poderá ter acesso a informações indevidas.
O SGBD Oracle provê ferramentas necessárias para construir aplicações seguras e que evitam que esse problema aconteça, bastando para isso combinar o uso do controle de acesso refinado e do contexto de aplicação.
O Virtual Private Database (VPD)
A partir do Oracle 8i, a Oracle introduziu o conceito de Banco de Dados Privado Virtual (Virtual Private Database). Este oferece um controle de acesso refinado (FGAC - Fine-Grained Access Control) para um acesso seguro aos dados. Isso garante que os usuários apenas tenham acesso aos dados que pertencem a eles, implementando a segurança ao nível de linha da tabela. Usando esta opção, podemos armazenar, por exemplo, dados de várias empresas no mesmo esquema do banco de dados, sem que elas saibam disso.
O VPD é uma solução robusta e confiável que dá a impressão ao usuário final de que existe um banco de dados distinto para cada usuário, daí o nome de banco de dados privado virtual.
Com o VPD, você estabelece as políticas na forma de predicados (cláusulas where) que são anexadas a cada “select” ou comandos DML que os usuários fazem ao banco de dados. Ao utilizar o VPD, só é preciso criar a estrutura de segurança uma vez no servidor de dados. Como as políticas de segurança estão anexadas aos dados e não à aplicação, as regras de segurança são implantadas sempre e com qualquer abordagem de acesso. Assim sendo, os dados apresentados a partir de uma consulta são idênticos independentes do modo de conexão realizado: de uma aplicação, do SQL plus, ou de um driver ODBC.
Em outras palavras, uma instrução “select” em uma tabela, visão ou sinônimo controlado por um VPD retornará um subconjunto de linhas com base em uma cláusula where gerada automaticamente pela função da diretiva de segurança baseada no contexto da aplicação.
A segurança pelo VPD fornece uma maneira inteiramente nova de controlar o acesso aos dados do Oracle. A mais interessante é a natureza dinâmica de um VPD. Em tempo de execução, o Oracle executa os seguintes passos modificando o SQL do usuário final:
1. O Oracle recupera a informação do contexto da aplicação e chama então a função da política, que retorna um predicado. Um predicado é uma cláusula “where” que qualifica um conjunto particular de linhas de uma tabela.
2. O Oracle reescreve dinamicamente a consulta adicionando o predicado às consultas SQL dos usuários.
Como os predicados são gerados de forma transparente durante a análise sintática da instrução, a aplicação não precisará utilizar tabelas especiais, visões etc. para implementar a diretiva. Como resultado, o Oracle pode otimizar a consulta utilizando índices, visões materializadas e operações paralelas onde, do contrário, talvez ele não fosse capaz. Portanto, utilizar um VPD talvez incorra em menos overheads que uma consulta cujos resultados são filtrados utilizando aplicações ou outros meios.
O controle de acesso refinado (FGAC)
O controle de acesso refinado (FGAC - Fine-Grained Access Control) é baseado na modificação dinâmica das expressões do usuário.
Quando usamos o controle de acesso refinado, criamos políticas de segurança que ficam acopladas às tabelas, visões, ou sinônimos em que a aplicação está baseada. Quando um usuário executa um SELECT ou uma expressão DML (INSERT, UPDATE ou DELETE) no objeto, o Oracle dinamicamente modifica a expressão do usuário, de forma transparente, implementando nessa expressão o controle de acesso correto. Podemos também garantir a política de segurança nas operações de manutenção de índices executadas com as expressões CREATE INDEX e ALTER INDEX (ler Nota 1).
Nota 1. Dica
Usuários precisam de acesso completo à tabela para criar os índices. Consequentemente, um usuário que tenha privilégio para manutenção de um índice terá direito de ver todas as linhas da tabela, embora o usuário não tenha acesso completo a tabela quando executa uma simples consulta. Para prevenir isto, aplique a política de VPD nas expressões de INDEX.
Essa modificação dinâmica é baseada na condição “where” (predicado) que é retornada por uma função que implementa a política de segurança. Essa função utilizada pra retornar os predicados a fim de impor a diretiva é criada como qualquer outra função PL/SQL, exceto que a função tem dois parâmetros requeridos (obj_schema e obj_name ambos varchar2) e retorna um VARCHAR2.
As funções que retornam o predicado também podem incluir chamadas externas a outras funções. Dentro do pacote PL/SQL, podemos embutir chamadas a programas C ou Java que podem acessar qualquer informação do sistema operacional, ou retornar uma cláusula “where” a partir de um arquivo no sistema operacional ou de um repositório central de políticas. Uma função de política pode retornar diferentes predicados para cada usuário, para cada grupo de usuários ou para cada aplicação.
Podemos ver na Figura 1 como empregados só têm acessos aos dados do seu próprio departamento usando o Controle de Acesso Refinado. Dois usuários aplicam a mesma instrução SQL no banco de dados: SELECT * FROM PEDIDOS. Para cada usuário, a função de política de segurança adiciona um predicado (de acordo com o departamento do empregado), e cada um dos SQL retornam linhas diferentes do banco de dados.
Figura 1. Esquema de funcionamento do VPD.
Um empregado executa a consulta:
SELECT * FROM PEDIDOS;
A função implementada pela política de segurança retorna o predicado “dep_id =
SELECT * FROM PEDIDOS WHERE DEP_ID = 1;
Suponha que queiramos colocar na tabela “PEDIDOS” a seguinte política de segurança: “Clientes só podem ver seus próprios pedidos”. O processo é descrito a seguir.
Criamos uma função para adicionar um predicado à expressão DML do usuário. Neste caso, podemos criar uma função que adiciona o seguinte predicado:
Cliente_no = (SELECT Cli_no FROM Clientes WHERE Cliente_name = SYS_CONTEXT ('userenv','session_user'))
Um usuário entra com a seguinte expressão:
SELECT * FROM Pedidos;
O Oracle chama a função que foi criada para implementar a política de segurança. Com isso, dinamicamente a função modifica a expressão do usuário para a seguinte:
SELECT * FROM PEDIDOS WHERE Cliente_no =
(SELECT Cli_no FROM Clientes WHERE Cliente_name = SYS_CONTEXT ('userenv','session_user'))
Feito isto, o Oracle executa a expressão que foi alterada.
A função emprega o “username” retornado por SYS_CONTEXT (“userenv”, “session_user”) para procurar o cliente correspondente e para limitar os dados retornados da tabela PEDIDOS para os dados somente desse cliente.
O contexto da aplicação
O conceito de contexto da aplicação é análogo às variáveis globais que estamos acostumados, no sentido de que uma vez que um valor é definido para um atributo de um contexto, este pode ser referenciado durante toda a sessão do usuário no banco de dados. Entretanto, essa similaridade termina por aí. O maior diferenciador é a maneira que esta atribuição é feita, e a segurança que é fornecida.
Em outras palavras, o contexto da aplicação é uma parte da memória do banco de dados que pode ser referenciada por uma função específica (SYS_CONTEXT), e fica acessível durante toda a sessão do usuário com o banco de dados.
Você define um contexto da aplicação da seguinte forma:
create context teste_ctx
using set_teste_ctx;
Observe a segunda linha, “using…”. Aqui está a diferença entre o contexto de aplicação e as variáveis globais. Isto indica que os atributos do contexto podem somente ser atribuídos pelo procedimento set_teste_ctx. Obviamente, precisamos criar tal procedimento (ver Listagem 1).
...
