Um middleware para Gestão e Execução de Controle Refinado de Acesso a Dados

Transcrição

1 Um middleware para Gestão e Execução de Controle Refinado de Acesso a Dados Aluno: Sergio Gonçalves Puntar Filho Orientador: Leonardo Guerreiro Azevedo Co-orientadora: Fernanda Araujo Baião Núcleo de Pesquisa e Prática em Tecnologia (NP2Tec) Programa de Pós-Graduação em Informática Departamento de Informática Aplicada (DIA) Universidade Federal do Estado do Rio de Janeiro (UNIRIO) {sergio.puntar, azevedo, fernanda.baiao}@uniriotec.br Nível: Mestrado; Ingresso: Fevereiro de 2011; Conclusão prevista: Dezembro de 2012; Etapas Concluídas: Concepção da Proposta Resumo. Este trabalho apresenta uma proposta de middleware para controle de acesso refinado para bancos dados em ambientes heterogêneos, onde é necessário garantir a confidencialidade dos dados de diversas fontes, em diversas aplicações, independentemente de tecnologia. Esta proposta baseiase em mecanismos de controle de acesso já conhecidos como RBAC, RDBAC e re-escrita de consulta. No entanto, a abordagem tem menor impacto nas aplicações, em comparação com outras abordagens, para sua utilização, e ela facilita a definição de regras através de mapeamento de conceitos. Palavras Chave: Data Authorization, Privacy and Security, Fine-grained Access Control 1. Introdução Segurança de Dados, e mais especificamente controle de acesso a dados, é um tema extremamente relevante [Rizvi et al., 2004]. A especificação do controle de acesso aos dados para um conjunto de aplicações pode ser formalizada através de regras de autorização, que especificam uma prerrogativa ou privilégio para uma ou mais ações. A declaração de uma regra de autorização restringe a quem é permitido realizar uma ação na organização sobre quais dados [BRG, 2000]. Em grandes organizações, é frequente a existência de diversas aplicações, em diferentes plataformas, que acessam bases de dados disponibilizadas em diferentes SGBDs. Quando há necessidade de integração dos dados armazenados nas diferentes bases de dados (através de sistemas de Integração de Informações SII), algumas dificuldades encontradas são a heterogeneidade dos SGBDs, dos modelos de dados, dos esquemas e da semântica dos dados [Py et al., 2009]. Nestes cenários, aplicar a segurança através dos mecanismos disponibilizados por cada SGBD cria uma forte dependência de tecnologia e, consequentemente, uma dependência com o fornecedor da 1

2 tecnologia. Dessa forma, segurança em banco de dados independente da implementação do SGBD é um importante desafio na literatura. O objetivo desse trabalho é desenvolver um middleware de controle de acesso a dados baseado em RBAC e RDBAC (os quais são apresentados na seção 2), que faça a intermediação entre a aplicação e o SGBD. Dessa forma, os seguintes requisitos serão tratados: garantia da confidencialidade dos dados; independência de plataformas, causando o menor impacto possível nas aplicações existentes, ou seja, sem alterar a forma com que as aplicações conectam-se e executam operações na base de dados; facilidade na definição de regras de autorização, ou seja, permitir a definição de regras de autorização por usuários de negócio de uma forma mais genérica e natural, mas que possam ser aplicadas nas diferentes fontes de dados existentes. 2. Fundamentação teórica Regras de autorização são tradicionalmente implementadas através de mecanismos simples de controle de acesso disponibilizados pela maioria dos SGBDs [Jeloka et al., 2008][Elmasri e Navathe, 2010]. Dois mecanismos comumente utilizados são o DAC (Discricionary Access Control) e o MAC (Mandatory Access Control), ambos originalmente propostos pelo Departamento de Defesa norte-americano [DoD, 1983]. O mecanismo DAC restringe o acesso a objetos baseado na identidade de usuários e/ou grupos aos quais eles pertencem. Mecanismos MAC, também conhecidos como label security, baseiam-se em regulamentações mandatórias determinadas por uma autoridade central [Yang, 2009]. A forma mais comum de MAC é a política de segurança de múltiplos níveis usando classificação de sujeitos (usuários ou grupos) e objetos (dados) dos sistemas. Esses mecanismos tradicionais de controle de acesso esbarram no recente e crescente interesse em controle de acesso refinado em bancos de dados relacionais (fine-grained access control - FGAC), ou controle de acesso de baixo nível. O FGAC restringe o acesso a nível de linha e até de célula de uma tabela, e pode ser apontado como controle de acesso baseado em conteúdo, pois muitas vezes as regras de autorização são definidas baseadas em dados já presentes nos registros das tabelas [Wang et al., 2007]. Uma possível forma de aplicação do FGAC é através da utilização de predicados de segurança que, adicionados às operações executadas pelos usuários sobre os objetos, limitam o seu nível de acesso. Um exemplo de mecanismo que utiliza essa abordagem é o Virtual Private Database (VPD) do Oracle [Jeloka et al., 2008]. Tanto o DAC quanto o MAC são menos flexíveis que o FGAC. O DAC só permite o controle de acesso ao nível de objeto. O MAC apesar de permitir o controle de acesso ao nível de linha, o faz através da inclusão de rótulos (novos dados) na linha, ao invés de aproveitar os dados já existentes. Por essas limitações, as aplicações tipicamente deixam de lado os mecanismos de controle de acesso providos pelos SGBDs, e aplicam o controle de acesso refinado diretamente na interface de acesso aos dados, na camada da aplicação. Apesar de ser amplamente utilizada, essa abordagem possui importantes desvantagens [Rizvi et al., 2004], como: controle de acesso deve ser aplicado em cada ponto em que aplicações acessam dados protegidos; mudança na política de controle de acesso requer a mudança de uma grande quantidade de código; e dado o tamanho do código de uma aplicação, é mais fácil haver um descuido que acarrete em uma falha de segurança. 2

3 Por essas razões, o controle de acesso refinado deveria ser idealmente implementado na camada de dados [Rizvi et al., 2004]. Uma forma de obter isso é através da utilização de dois mecanismos de controle de aceso, o RBAC (Role-Based Access Control) proposto por [Ferraiolo e Khun, 1992], e o RDBAC (Reflective Database Access Control) proposto por [Olson et al., 2008]. No mecanismo RBAC, o controle de acesso considera funções, além dos dados. Neste caso, o interesse principal é proteger a integridade do dado: quem pode realizar qual ação sobre qual dado [Ferraiolo e Khun, 1992]. O mecanismo RDBAC propõe que a definição das regras de autorização seja feita de forma reflexiva, ou seja, baseando-se em dados já presentes no banco de dados. Exemplos de políticas de controle de acesso refinadas que podem ser alcançadas com esses dois mecanismos são: Um aluno deve ter acesso somente as suas próprias notas. Um professor deve ter acesso as notas de todos alunos matriculados nas disciplinas que leciona. (R1) (R2) Nesses exemplos, as políticas foram definidas através do RBAC, onde aluno e professor são papéis com responsabilidades e direitos definidos. Além disso, as regras foram definidas através do RDBAC, pois os dados que serão utilizadas para aplicar a regra de autorização já estão presentes na base de dados (por exemplo, matrícula do aluno e código da disciplina). Apesar de existirem implementações de mecanismos RBAC tanto em SGBDs comerciais [Yang, 2009] como em SGBDs de código aberto [Veil, 2010], essas implementações não são padronizadas, e requerem um grande conhecimento do SGBD e do esquema de dados. Além disso, uma política RBAC definida em um SGBD não pode ser facilmente aplicada a outro. 3. Caracterização da contribuição Este trabalho busca desenvolver um middleware de controle de acesso a dados, que centralize o acesso aos dados corporativos e aplique as regras de controle de acesso definidas sobre esses dados. Pode-se listar uma série de desafios a serem vencidos para que um middleware de controle de acesso seja capaz de assegurar a confidencialidade desses dados: (I) Capturar as operações realizadas através das aplicações nas diferentes formas de comunicação utilizadas; (II) Identificar e autenticar o usuário responsável pela operação, e definir o seu nível de autorização nos dados a partir de regras definidas em alto nível; (III) Traduzir as regras definidas em alto nível para o esquema de dados sendo acessado e garantir a integridade e confidencialidade desses dados após a execução da operação enviada pela aplicação; (IV) Permitir a inclusão de novas bases de dados, aplicando regras pré-existentes através do mapeamento do esquema de dados dessa nova base para os conceitos utilizados na definição das regras de alto nível. Dentre estes desafios, essa proposta busca atender a captura das operações (I), a definição de regras de autorização a partir de conceitos em alto nível mapeados nos esquemas de dados utilizados (II) e a tradução e aplicação das regras (III). A Figura 1 ilustra a arquitetura proposta para o middleware, e em seguida são descritos os seus módulos. Interceptador de consultas: Módulo responsável por interceptar as consultas realizadas pelas aplicações. Ao invés das aplicações conectarem-se diretamente com o banco de dados, a conexão ocorre de forma transparente com o interceptador de 3

4 consultas. O interceptador de consultas captura as consultas destinadas aos SGBDs de forma que as aplicações pré-existentes não precisam alterar a sua forma de conexão. Figura 1 - Arquitetura do middleware de controle de acesso a dados Re-escritor de consultas: Módulo responsável por receber as consultas interceptadas e as re-escrever incorporando restrições de acesso a dados de acordo com as regras definidas para cada usuário, por exemplo, adicionando predicados (nas cláusulas WHERE). As consultas resultantes são executadas na fonte de dados correta e o seu resultado é retornado para a aplicação cliente. Interpretador de conceitos e Base de mapeamento de conceitos: Módulo responsável por identificar conceitos representados nas bases de dados. Este módulo informa ao módulo re-escritor de consultas quais conceitos estão sendo acessados na consulta. Da mesma forma, este módulo é capaz de, a partir dos conceitos utilizados para definir uma regra, informar ao módulo re-escritor de consultas quais objetos e atributos representam aquele conceito em cada base para que o predicado possa ser gerado. Motor de regras e Base de regras de acesso: Módulo responsável por identificar as regras de acesso que devem ser aplicadas a partir dos conceitos sendo acessados e da do usuário que está realizando o acesso. A partir dos dados presentes na base de regras de acesso, este módulo é capaz de informar ao módulo re-escritor de consultas quais regras deverão ser aplicadas sobre cada conceito para um determinado usuário. No ambiente de um sistema acadêmico, a aplicação da regra R1 segue o seguinte fluxo. No passo 1, através da Aplicação Cliente 1, um usuário que tem o perfil de aluno realiza uma consulta em uma tabela protegida pela regra R1 (por exemplo, select NM_ALUNO, MAT_ALUNO from VW_ALUNOS_MESTRADO). Esta consulta é interceptada pelo módulo interceptador de consultas (passo 2) que encaminha a consulta para o módulo re-escritor de consultas. Este analisa a consulta e identifica os objetos 4

5 (tabelas e visões) e atributos (colunas) sendo acessados. No passo 3, esse objetos e atributos são passados para o módulo interpretador de conceitos que retorna (passo 4) os conceitos equivalentes. Por exemplo, se a consulta está acessando os atributos NM_ALUNO e MAT_ALUNO da visão VW_ALUNOS_MESTRADO, o interpretador de consulta retorna os conceitos nome do aluno, matrícula do aluno e alunos do curso de mestrado. No passo 5, o módulo re-escritor de consultas passa a lista de conceitos sendo acessados para o motor de regras, que identifica as regras a serem aplicadas ao conceito (neste caso R1) e as retorna (passo 6) ao re-escritor de consultas. As regras são definidas em forma de parâmetros por conceito e papel do usuário, e os valores dos parâmetros das regras são definidos a partir do usuário realizando o acesso. Uma regra para o conceito alunos do curso de mestrado para o papel Aluno pode possuir o parâmetro matrícula do aluno =?, e o valor desse parâmetro será diferente para cada usuário, podendo até mesmo vir de outra tabela da base. De posse das regras, o re-escritor de consultas envia os conceitos utilizados na definição da regra para o módulo interpretador de conceitos (passo 7), que retorna o mapeamento destes conceitos para os objetos do esquema de dados (passo 8), de forma parecida aos passos 3 e 4. No entanto, dessa vez, o valor enviado é por exemplo alunos do curso de mestrado e o valor retornado é VW_ALUNOS_MESTRADO. No passo 9, o re-escritor de consultas reescreve a consulta original de acordo com as regras definidas e com o mapeamento dos conceitos. Neste caso, a consulta será select NM_ALUNO, MAT_ALUNO from VW_ALUNOS_MESTRADO where MAT_ALUNO = 'mat_usuario'. No passo 10, a consulta então é executada pelo SGBD na fonte de dados correta, que foi identificada durante a conexão com o interceptador de consultas. Por exemplo, se a conexão foi realizada com o interceptador alocado em um IP e em uma porta específica, sabe-se a fonte de dados original cujas consultas estão sendo interceptadas. Após a execução, o SGBD passa o resultado da consulta para o middleware que retorna o resultado final para a aplicação cliente (passo 11). 4. Estado atual do trabalho Em trabalho anterior, um framework de controle de acesso baseado em RBAC e RDBAC foi implementado no Oracle Database 10g utilizando o seu mecanismo de FGAC nativo, chamado Virtual Private Database (VPD) [Azevedo et al., 2010a]. Esse trabalho é apresentado em detalhes por Puntar [2010] e Azevedo et al. [2010b]. Nesse framework foi implementada uma base de regras de acesso e um motor de regras que acessa essa base e monta o predicado de acordo com os objetos consultados e o usuário realizando a consulta. Contudo, o framework é fortemente dependente de tecnologia e as regras são definidas diretamente como predicados, o que depende de um conhecimento profundo no esquema de dados e da SQL, dificultando enormemente a sua gestão. O foco da presente proposta é generalizar o framework existente, através de um middleware que facilite a definição e aplicação da regras em diferentes SGBDs, removendo a dependência de tecnologia existente no framework e facilitando a gestão das regras. Para isso serão implementados os quatro módulos apresentados na seção 3, onde parte do motor de regras será aproveitado do trabalho já desenvolvido. Testes realizados sobre o trabalho já desenvolvido mostraram que a proposta é eficaz para as principais operações de seleção, inserção, atualização e remoção 5

6 [Azevedo et al., 2010]. Além disso, testes de desempenho mostraram que a proposta é tão eficiente quanto os mecanismos padrões de FGAC do Oracle [Puntar et al., 2010]. 5. Bibliografia AZEVEDO, L. G.; PUNTAR, S.; THIAGO, R.; BAIAO, F.; CAPPELLI, C., 2010a. A Flexible Framework for Applying Data Access Authorization Business Rules, in: 12th International Conference on Enterprise Information Systems, pp , Funchal, Madeira, Portugal. AZEVEDO, L.; PUNTAR, S.; MELO, R.; BAIAO, F.; CAPPELLI, C. 2010b. Avaliação Prática de Funcionalidades para Autorização de Informações (Label Security e Virtual Private Database), Relatórios Técnicos do DIA/UNIRIO (RelaTe-DIA), RT-0002/2010. BRG, Defining Business Rules ~ What Are They Really?, disponível em: Acessado em setembro DoD, Trusted Computer Security Evaluation Criteria, Department of Defense, DoD STD. ELMASRI, R., NAVATHE, S., Fundamentals of Database Systems, Addison Wesley. FERRAIOLO, D.F. e KHUN, D. R., Role-Based Access Control. in: 15th National Computer Security Conference, pp , Baltimore, Maryland, USA. JELOKA, S.; MULAGUND, G.; LEWIS N. et al., Oracle Database Security Guide, Oracle RDBMS 10gR2. Oracle Corporation. Disponível em: Acessado em setembro OLSON, L. E.; GUNTER, C. A.; E MADHUSUDAN, P., A formal framework for reflective database access control policies, in: Proceedings of the 15th ACM Conference on Computer and Communications Security, pp , Alexandria, Virginia, USA. PUNTAR, S Framework flexível para regras de autorização de acesso a dados, Monografia apresentada à Escola de Informática Aplicada da UNIRIO para obtenção do grau de bacharel em Sistemas de Informação. PUNTAR, S.; AZEVEDO, L.; BAIÃO, F.; CAPPELLI, C., Testes de desempenho comparando modelo flexível com VPD tradicional, Relatórios Técnicos do DIA/UNIRIO (RelaTe-DIA), RT-0013/2010. PY, H., CASTRO, L., BAIÃO, F. A., TANAKA, A., A service-based approach for data integration based on business process models, in 11th International Conference on Enterprise Information Systems, pp , Milão, Itália. RIZVI, S., MENDELZON, A., SUDARSHAN, S., ROY, P Extending Query Rewriting Techniques for FineGrained Access Control, in Proceedings of the 2004 ACM SIGMOD international conference on Management of data, pp , New York, NY, USA. VEIL. Veil Project, PostgreSQL Community. Disponível em: Acessado em maio WANG, Q., YU, T., LI, N., LOBO, J., BERTINO, E On the Correctness Criteria of FineGrained Access Control in Relational Databases, in Proceedings of the 33rd international conference on Very large data bases, pp , Vienna, Austria YANG, L., Teaching database security and auditing, in Proceedings of the 40th ACM technical symposium on Computer science education, pp , New York, NY, USA 6