Um Modelo de Controle de Acesso com Política Compulsória
Implementável em Catálogo
Antônio Eustáquio Ferreira Galvão, Ilmério Reis Silva, João Nunes de Souza
Faculdade de Computação - Universidade Federal de Uberlândia (UFU)
e-mail: [email protected], {ilmerio, Nunes}@ufu.br
Abstract. The purpose of this work is introduce a relational database control access security
model using a new approach of mandatory policy. The main contribution of the model is a
new focus, making feasible implementation in database catalog, but maintaining the
principles of the policy.
Resumo. O objetivo deste trabalho é apresentar um modelo de segurança para controle de
acesso a banco de dados relacional utilizando uma nova abordagem da política
compulsória (mandatory policy). A principal contribuição do modelo reside em um novo
enfoque, que viabilize a implementação via catálogo do banco de dados, porém mantendo
os princípios da política.
1. Introdução
O desenvolvimento de sistemas gerenciadores de bancos de dados (SGBDs) de grande eficácia, com
licença gratuita, contribui para a popularização de aplicações de banco de dados. Dispomos hoje de
gerenciadores de bancos de dados de código aberto, capazes de manipular grandes volumes de
informações de forma confiável e com excelente desempenho, mesmo em face de um número
considerável de transações [01]. Porém, no tocante ao controle de acesso, questão fundamental para a
segurança das informações, estes gerenciadores carecem de recursos, não dispondo, por exemplo, de
funcionalidades que auxiliem a implementação de uma política compulsória de controle de acesso
[02][03][04].
Como veremos na seção 2, uma política compulsória de controle de acesso é capaz de
melhorar substancialmente a segurança de um sistema, possibilitando um maior controle no fluxo de
informações e criando uma nova camada de segurança independente do administrador do banco de
dados. Tais requisitos de segurança são importantes em qualquer sistema que tenha como requisito a
confidencialidade das informações.
Porém, os modelos de política compulsória propostos na literatura são de implementação
complexa, necessitando mudanças no núcleo do SGBD, não existindo nenhuma implementação em
SGBDs de código aberto e poucas implementações em SGBDs comerciais. Como exemplo, temos
que um dos mais populares softwares para gerenciamento de banco de dados, o “Microsoft SQL
Server 2000“ [11], não possui implementada esta política. A principal implementação disponível
comercialmente é o software “Oracle10g Database” [05], porém sendo comercializada como um
produto adicional à versão básica do produto, com um custo equivalente a 200% da versão “Standard”
do produto (Dados obtidos em 28/04/2004) [06].
Propomos neste trabalho um modelo que viabilize a implementação de política compulsória
com esforço de implementação reduzido, se comparado aos modelos sobre os quais falaremos na
seção 2, e sem que sejam necessárias mudanças no núcleo do gerenciador, visando principalmente os
SGBDs de código aberto.
Na seção 2 apresentaremos uma visão geral de políticas e modelos de controle de acesso. Na
seção 3 descreveremos o modelo proposto e finalmente, na conclusão, discutiremos as vantagens do
modelo e sua contribuição para a melhoria na segurança dos bancos de dados.
2. Políticas de segurança e controle de acesso
A implementação do controle de acesso em sistemas de banco de dados tem como objetivo garantir o
acesso às informações disponíveis segundo as regras estipuladas pela política de controle adotada
[07]. Neste contexto temos três componentes:
-
Sujeitos: Usuários ou processos que requisitam operações ao SGBD;
-
Objetos: Dados ou Funcionalidades (Tabelas, Visões, Rotinas Armazenadas, Funções ...);
-
Operações: Requisições que podem ser feitas pelos sujeitos (Ler, Escrever, Inserir,
Executar).
Através de mecanismos de segurança, o SGBD deverá ser capaz de analisar as requisições de
acesso dos sujeitos, permitindo, recusando ou modificando-as, limitando o acesso a dados não
autorizados, de acordo com as regras estabelecidas.
Uma política de segurança define a estratégia a ser utilizada no controle de acesso a
informações contidas no banco de dados. São definidos os princípios pelos quais o acesso é
permitido ou negado.
Regras de acesso estabelecem como e por quem as operações (leitura, escrita, ...) poderão ser
executadas, definindo os privilégios dos sujeitos. A política de segurança define como estas regras
serão administradas.
Políticas de controle de acesso estabelecem como objetos e sujeitos podem ser agrupados para
compartilhar as autorizações e regras estabelecidas de acordo com a política de segurança. Também
podem definir se e como os privilégios podem ser transferidos de um sujeito para outro. Agrupando
ou classificando sujeitos que compartilham privilégios, simplificamos a especificação da política de
segurança a ser adotada e também a implementação dos mecanismos de segurança e sua
administração.
Políticas de controle de acesso podem ser classificadas em discricionárias ou compulsórias. A
seguir descreveremos estas políticas.
2.1. Políticas Discricionárias
Numa política de controle de acesso discricionária, são especificadas para cada sujeito, as regras e
privilégios de acesso aos objetos do sistema. As requisições de acesso são analisadas por um
mecanismo de segurança discricionário e o acesso é concedido de acordo com as regras de
autorização.
Políticas discricionárias se baseiam na concessão e revogação de privilégios. O controle
poderá ser centralizado, isto é, a autorização é administrada por um controle central, normalmente o
administrador do banco de dados. Podem ter também um controle descentralizado de maneira que o
proprietário da informação possui o direito de conceder ou revogar os privilégios.
Estas políticas têm a vantagem de serem flexíveis podendo ser utilizadas por vários tipos de
sistemas e aplicações comerciais e industriais e, conseqüentemente, são atualmente as mais utilizadas.
Vários modelos foram propostos e implementados em vários sistemas operacionais e SGBDs, porém
não satisfazem totalmente certos requisitos de segurança, como no caso em que um usuário com
permissão de leitura a determinada informação poderá transferi-la para um objeto de outro usuário
que não possui esta permissão. Podemos então concluir que as políticas discricionárias protegem os
objetos do sistema, mas não são capazes de controlar o fluxo das informações.
No caso específico de aplicações de banco de dados, as políticas de controle de acesso
discricionárias não permitem classificar os objetos e sujeitos no que diz respeito à confidencialidade.
Com isto, não é possível criar uma política que possa restringir os privilégios de acesso a informações
confidenciais com base na classificação dos sujeitos, independentemente de especificações
determinadas pelo administrador. Este tipo de política é importante quando se deseja limitar a
autoridade do administrador do banco de dados, protegendo informações confidenciais, muitas vezes
vitais, como no caso dos sistemas militares. Mas sua aplicação pode ser bem mais abrangente, sendo
fundamental em qualquer sistema onde a confidencialidade das informações for importante.
2.2. Políticas Compulsórias
O primeiro modelo de política de controle de acesso compulsória (Mandatory Access Control MAC) foi apresentado por Bell e La Padula [10] como uma extensão ao modelo discricionário
baseado em matriz de acesso [07]. O modelo foi orientado para a proteção de recursos de Sistemas
Operacionais em face ao problema de sigilo de informações, porém se tornou um modelo conceitual
que deu origem a outros com aplicações específicas, inclusive em bancos de dados relacionais.
As políticas compulsórias se caracterizam pela definição de classes de segurança para os
sujeitos e objetos. As classes de segurança são determinadas por duas características: O nível de
classificação e a categoria.
O nível de classificação reflete a sensibilidade da informação, como por exemplo: Público,
confidencial, secreto e ultra secreto.
Já as categorias buscam refletir áreas ou departamentos das organizações. Em uma indústria,
por exemplo, poderíamos ter as seguintes áreas:
- Produção
- Comercial
- Administração, etc ...
Cada objeto possui um nível de classificação e pode pertencer a mais de uma categoria, o
mesmo acontecendo com os sujeitos. De forma simplificada, podemos dizer que um sujeito poderá
ter acesso a determinado objeto se seu nível de classificação for igual ou superior ao do objeto e se
pertencer a pelo menos a uma classe a que o objeto também pertença.
Foram propostos modelos com política compulsória, voltados para proteção de bancos de
dados relacionais como o “SeaView (Secure dAta VIEW)” [07], que agrega política discricionária com
política compulsória, o modelo proposto por Jajodia and Sandhu [07] e o modelo “Smith and
Winslett” [07].
Estes modelos têm em comum o fato de que o nível de classificação da informação é definido
para cada tupla de uma relação, sendo que cada atributo desta instância poderá ter um nível diferente
(relações multi-nível). Tomando como base o modelo SeaView, temos que cada tupla de uma relação
é representada na forma (a1|c1, ..., an|cn, t) onde ai|ci representa respectivamente o valor e a classe do
atributo i e t a classe de acesso associada à tupla.
Neste caso, a nível de implementação, cada elemento ai de uma tupla deve ser acompanhado
de um rótulo ci, o que é denominado por “Labeled Security Protection” [09].
Este tipo de implementação requer modificações no núcleo do SGBD, pois envolve o
armazenamento das informações de segurança associadas a cada linha. Além disso, as avaliações de
segurança para o retorno de informações aos usuários são realizadas após a recuperação das
informações do banco de dados. Concluímos que este tipo de implementação da política compulsória
em SGBDs requer um grande esforço de desenvolvimento, pois determinam mudanças no núcleo.
Motivados pela importância das políticas compulsórias, propomos neste trabalho, a discussão
de um modelo alternativo, que possa contar com a maior parte das vantagens da aplicação destas
políticas em bancos de dados relacionais, mas que propicie uma implementação com menor esforço.
3. O Modelo Proposto
Nossa proposta parte da premissa de que as características de uma dada relação, bem com os
significados de seus atributos (em detrimento do seus valores), são suficientes para se definir sua
classificação quanto à segurança.
A política se baseia na organização hierárquica dos componentes do banco de dados. A
organização e os componentes são:
-
Base de dados
-
Tabela (Relação)
-
Coluna (Atributo)
As políticas compulsórias se caracterizam pela definição de classes de segurança para os
sujeitos e objetos. As classes de segurança são determinadas pelo nível de classificação que reflete a
sensibilidade da informação e a categoria, ou área de aplicação.
Nos modelos “SeaView (Secure dAta VIEW)”[07], “Jajodia and Sandhu” [07] e “Smith and
Winslett” [07], as classe de segurança são tratadas considerando o conteúdo do banco de dados, isto é,
podem variar de acordo com instâncias de uma relação. O modelo aqui proposto trata as classes de
segurança de acordo com o esquema do banco de dados, independentemente de seu conteúdo,
facilitando a implementação.
Cabe salientar que a política compulsória vem complementar a política discricionária, de
forma que a autorização de acesso primeiramente deve ser concedida através de regras da política
discricionária e confirmada ou negada pela política compulsória. A política compulsória é então
aplicada somente nas operações de leitura e escrita de dados (SELECT, UPDATE, INSERT).
3.1. Nível de classificação
De forma semelhante ao modelo SeaView dividimos os níveis de classificação em quatro: Ultrasecreto (US); Secreto (S); Confidencial (C); Publico (P). Estes níveis são assim ordenados: US > S >
C > P.
Tratemos aqui como objetos, a base de dados, as tabelas (relações) e as colunas (atributos).
Cada objeto pode ser classificado segundo os níveis de classificação acima, ou simplesmente não ser
classificado (Nível N), o mesmo ocorrendo com os sujeitos (usuários).
Chamamos de Cs o nível de classificação do sujeito, dado pelo administrador do sistema e Co
o nível de classificação do objeto que é obtido analisando a hierarquia de objetos do banco de dados.
3.1.1. Determinando o nível de classificação do objeto (Co)
A seguir descrevemos os passos para a obtenção do nível de classificação do objeto.
Passo 1: Inicialmente consideramos o nível de classificação Co como Não Classificado (N ou
NULL).
Passo 2: Verificamos o nível de classificação da base de dados à qual os dados solicitados pertencem
ou na qual os dados serão gravados. Caso possua classificação, esta passará a ser a classificação Co
do Objeto, caso contrário Co continuará como N.
Passo 3: Verificamos o nível de classificação da tabela à qual os dados solicitados pertencem ou na
qual serão gravados. Caso possua classificação, esta passará a ser a classificação Co, caso contrário
permanecerá com a classificação obtida no passo 2. Observamos que caso uma tabela não possua
classificação, esta herdará a classificação da base de dados a que pertence. Portanto uma tabela não
classificada difere de uma tabela classificada como pública.
Passo 4: Por fim são analisadas as colunas. A classificação Co será a maior classificação das colunas
requisitadas para a operação. Caso uma coluna não possua classificação, a mesma terá a classificação
obtida no passo 3. Da mesma forma que as tabelas, uma coluna não classificada herda a classificação
da tabela a qual pertence.
Na seção seguinte exemplificaremos a aplicação destes passos para a obtenção do nível de
classificação do objetos de acordo com a operação solicitada.
3.1.2. Obtendo a permissão de acesso
A permissão de acesso será concedida se o nível de classificação do sujeito (Cs) for maior ou igual ao
nível de classificação do objeto (Co). A Tabela 3.1 apresenta um exemplo.
Base de Dados: Administracao – Co = P (Publico)
Tabela: Funcionarios – Co = NULL (Não classificada)
Nome - Co = P
Departamento - Co = C
Salario - Co = S
Paulo
Dep1
1000
Roberto
Dep2
1000
Sérgio
Dep2
1000
Um sujeito com nível de classificação Confidencial (Cs = C), poderá executar a pesquisa:
SELECT Nome, Departamento FROM FUNCIONARIOS
Aplicando os passos da seção 3.1.1. para obter o nível de classificação Co correspondente à
pesquisa temos:
Passo 1: Inicialmente faremos Co = N.
Passo 2: O nível de classificação da base de dados Administracao, conforme a Tabela 3.1 é P,
portanto o objeto passa a ter Co = P.
Passo 3: - Ao verificarmos o nível de classificação da tabela Funcionarios vemos que a mesma não é
classificada. Portanto ela herda a classificação da base de dados. Neste caso continuamos com Co =
P.
Passo 4: Finalmente analisamos os níveis de classificação das colunas solicitadas pela consulta, no
caso Nome e Departamento. O maior nível de classificação é Confidencial, fazendo então Co = C.
A operação será permitida, pois Cc = Co. Devido à herança do nível de classificação, nos
casos em que todas as colunas tiverem a mesma classificação, não será necessário classificarmos
individualmente cada coluna, bastando classificar a tabela à qual pertencem, facilitando a
administração.
Aplicando os mesmo passos acima concluímos que sujeito não será autorizado a executar a
consulta:
SELECT * FROM FUNCIONARIOS
Isto ocorre porque no Passo 4 a maior classificação será da coluna Salario, fazendo Co = S.
Com isto temos Cc < Co, isto é, o nível de classificação do objeto é superior ao do sujeito.
Opcionalmente a implementação poderá definir que neste caso o sujeito terá permissão de executar a
consulta, porém a coluna Salario não será mostrada, ou retornará com valores nulos. Neste caso o
item 4 da seção 3.1.1 deverá ser alterado e o nível de classificação do objeto será obtido considerando
individualmente como objeto cada coluna requisitada.
3.2. Categoria
Complementando a organização em classes de segurança, os objetos são agrupados em categorias. A
classificação em categorias sugerida neste trabalho se baseia nos princípios do modelo Bell-Lapadula
[10], adaptado para aplicação no controle de acesso a Bancos de Dados Relacionais. As categorias
podem representar os mais diversos aspectos de acordo com a aplicação do banco de dados. Uma
empresa industrial, por exemplo, pode representar os diversos departamentos, como: Compras,
Produção, Vendas, Financeiro, Pessoal, etc .... Neste caso, cada departamento é representado por uma
categoria.
Os sujeitos e objetos podem pertencer a mais de uma categoria, ou não serem classificados.
Ao classificar o sujeito, determinamos para cada categoria, à qual ele pertencer, que tipo de operação
ele poderá realizar: SELECT, INSERT, UPDATE, DELETE. Para que seja concedido acesso de um
sujeito a determinado objeto, duas condições devem ser satisfeitas. A primeira é que ele deverá
pertencer a pelo menos uma categoria à qual o objeto também pertença, ou o objeto não ser
classificado. A segunda é que o sujeito deve estar autorizado a realizar a operação requisitada sobre
esta categoria.
De acordo com a hierarquia dos componentes do banco de dados, os componentes de nível
hierárquico inferior herdam as categorias dos níveis superiores.
Dado o conjunto de categorias C1, C2, .., CN temos os seguintes subconjuntos de acordo com a
hierarquia dos componente:
-
CTb[C1, C2, .., CNb] – Conjunto de categorias da base de dados que contém o objeto
-
CTt[C1, C2, .., CNt] – Conjunto de categorias da tabela à qual o objeto pertence
-
CTc[C1, C2, .., CNc] – Conjunto de categorias da coluna cujos dados são solicitados
O conjunto de categorias do objeto (CT) a ser acessado será dado por:
-
CT = CTb ∪ CTt ∪ CTc
Caso o conjunto CT seja vazio significa que o objeto não está classificado, podendo ser
acessado por sujeitos de qualquer categoria, desde que a permissão não tenha sido negada pelo nível
de classificação ou pela política discricionária.
A organização por categorias não pode ser confundida com o controle de acesso através de
papéis (Roles), presente em SGDBs comerciais, como o “Microsoft SQL Server 2000“ [11]. Neste
tipo de controle não ocorre a classificação dos objetos, mas somente dos sujeitos, de forma a
compartilharem privilégios determinados pela política discricionária.
3.3. Sugestões para Implementação
A maioria dos SGBDs relacionais modernos possuem um catálogo [08]. No catálogo se encontram
armazenadas informações como nome de tabelas, nomes de colunas, descrições de restrições (chaves,
NULL/NOT NULL., etc...) e outras informações referentes à estrutura do banco de dados. Além
disso, o catálogo inclui informações de segurança para implementação de políticas de controle de
acesso discricionárias. É prática comum, armazenar o próprio catálogo sob a forma de tabelas,
podendo utilizar o software do SGBD para consultar e atualizar o catálogo, por meio de linguagens de
consulta como a SQL.
As informações de nível de classificação e categoria propostas em nosso modelo, poderão ser
implementadas como novos dados no catálogo do SGBD, o que não ocorre nos outros modelos
propostos que dependem do conteúdo do banco de dados. Se o SGBD utiliza tabelas para
armazenamento do catálogo, poderemos acrescentar as informações em tabelas já existentes, ou criar
novas tabelas para estas informações. A vantagem de criar novas tabelas é que uma nova versão do
software do SGBD poderá ser compatível com bases de dados já instaladas, não necessitando nenhum
tipo de conversão de dados.
4. Conclusão
A união do controle de acesso discricionário e compulsório possibilita a implementação de uma
política de segurança mais versátil e eficaz, tornando o SGBD capaz de atender a um número cada
vez maior de aplicações, principalmente as que requerem um nível de segurança mais elevado.
A grande vantagem do modelo proposto reside em um novo enfoque da política compulsória
de controle de acesso, facilitando sua implementação e possibilitando sua utilização inclusive em
SGBSs de código aberto. Como dito anteriormente, a implementação das políticas já propostas
requer mudanças no núcleo dos SGBDs, pois as informações de segurança deverão estar registradas
em cada linha das tabelas e, no caso das relações multi-nível, associadas a cada campo de
informação. Estas mudanças requerem um grande esforço de desenvolvimento.
Ao o tratarmos a segurança da informação com base apenas em suas características (base de
dados-relação-atributo) e não em seu conteúdo com nos modelos já propostos, possibilitamos seu
armazenamento no catálogo do SGBD, não se fazendo necessária a recuperação dos dados para
autorizar o acesso. Se dividirmos uma operação em um banco de dados em duas etapas, “controle de
acesso” e “recuperação ou atualização da informação”, no modelo proposto as duas fases são
distintas. Isto ocorre porque o controle de acesso depende apenas das informações do catálogo do
SGBD, tornando mais rápida a concessão ou negação do direito de acesso. Nos modelos existentes o
controle de acesso dependerá da recuperação da informação para sua tomada de decisão, levando em
muitos casos a esforços desnecessários do SGBD, no caso de uma resposta negativa à solicitação de
acesso.
A proposta apresentada é ponto de partida para implementação de política compulsória em
SGBDs de baixo custo de propriedade (Software livre), possibilitando que um maior número de
usuários utilizem estas tecnologias. Um protótipo foi desenvolvido utilizando linguagem de alto
nível, possibilitando a verificação da facilidade da implementação. Porém é importante esclarecer
que apesar do modelo proposto ser de implementação mais simples, qualquer tipo de implementação
em um SGDB depende do estudo detalhado de seu código fonte, motivo pelo qual esta
implementação não foi feita por ocasião deste trabalho.
5. Referências
[01] Timothy Dyck , “Server Databases Clash”, eWEEK Enterprise News and Reviews,
http://www.eweek.com/article2/0,4149,293,00.asp, 2000
[02] Inprise/Borland, Interbase 6 – Operations Guide, 1999
[03] Steve Suehring, MySQL, a Bíblia, Tradução Edson Furmankiewicz, Ed. Campus, 2002
[04] The PostgreSQL Global Development Group, PostgreSQL 7.3.2 - Administrator´s Guide, 2002
[05] Oracle Corporation, “Oracle10g Label Security”, 2004
[06] http://oraclestore.oracle.com - Acesso em 28/04/2004
[07] Silvana Castano, Mariagrazia Fugini, Giancarlo Martella, e Pierangela Samarati,
Database Security, ACM Press, 1995
[08] Ramez Elmasri, Shamkant B. Navathe, Sistemas de Banco de Dados - Fundamentos e
Aplicações, LTC Editora, 2002
[09] Systems Security Organization National Security Agency, “LABELED SECURITY
PROTECTION PROFILE Version 1.b Information”, NSA, 1999
[10] Bell D.E. and La Padula L.J. , “Secure computer systems: unified exposition and Multics
Interpretation”, The MITRE Corp., Bedford, MA, 1975
[11] Waymire, Richard e Thomas, Bem., “Microsoft SQL Server 2000 Security”, Microsoft Press,
2000