You are on page 1of 9

Um Modelo de Controle de Acesso com Poltica Compulsria

Implementvel em Catlogo
Antnio Eustquio Ferreira Galvo, Ilmrio Reis Silva, Joo Nunes de Souza
Faculdade de Computao - Universidade Federal de Uberlndia (UFU)
e-mail: aefgalvao@triang.com.br, {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 segurana para controle de
acesso a banco de dados relacional utilizando uma nova abordagem da poltica
compulsria (mandatory policy). A principal contribuio do modelo reside em um novo
enfoque, que viabilize a implementao via catlogo do banco de dados, porm mantendo
os princpios da poltica.
1. Introduo
O desenvolvimento de sistemas gerenciadores de bancos de dados (SGBDs) de grande eficcia, com
licena gratuita, contribui para a popularizao de aplicaes de banco de dados. Dispomos hoje de
gerenciadores de bancos de dados de cdigo aberto, capazes de manipular grandes volumes de
informaes de forma confivel e com excelente desempenho, mesmo em face de um nmero
considervel de transaes [01]. Porm, no tocante ao controle de acesso, questo fundamental para a
segurana das informaes, estes gerenciadores carecem de recursos, no dispondo, por exemplo, de
funcionalidades que auxiliem a implementao de uma poltica compulsria de controle de acesso
[02][03][04].
Como veremos na seo 2, uma poltica compulsria de controle de acesso capaz de
melhorar substancialmente a segurana de um sistema, possibilitando um maior controle no fluxo de
informaes e criando uma nova camada de segurana independente do administrador do banco de
dados. Tais requisitos de segurana so importantes em qualquer sistema que tenha como requisito a
confidencialidade das informaes.
Porm, os modelos de poltica compulsria propostos na literatura so de implementao
complexa, necessitando mudanas no ncleo do SGBD, no existindo nenhuma implementao em
SGBDs de cdigo aberto e poucas implementaes em SGBDs comerciais. Como exemplo, temos
que um dos mais populares softwares para gerenciamento de banco de dados, o Microsoft SQL
Server 2000 [11], no possui implementada esta poltica. A principal implementao disponvel
comercialmente o software Oracle10g Database [05], porm sendo comercializada como um
produto adicional verso bsica do produto, com um custo equivalente a 200% da verso Standard
do produto (Dados obtidos em 28/04/2004) [06].
Propomos neste trabalho um modelo que viabilize a implementao de poltica compulsria
com esforo de implementao reduzido, se comparado aos modelos sobre os quais falaremos na
seo 2, e sem que sejam necessrias mudanas no ncleo do gerenciador, visando principalmente os
SGBDs de cdigo aberto.
Na seo 2 apresentaremos uma viso geral de polticas e modelos de controle de acesso. Na
seo 3 descreveremos o modelo proposto e finalmente, na concluso, discutiremos as vantagens do
modelo e sua contribuio para a melhoria na segurana dos bancos de dados.
2. Polticas de segurana e controle de acesso
A implementao do controle de acesso em sistemas de banco de dados tem como objetivo garantir o
acesso s informaes disponveis segundo as regras estipuladas pela poltica de controle adotada
[07]. Neste contexto temos trs componentes:
- Sujeitos: Usurios ou processos que requisitam operaes ao SGBD;
- Objetos: Dados ou Funcionalidades (Tabelas, Vises, Rotinas Armazenadas, Funes ...);
- Operaes: Requisies que podem ser feitas pelos sujeitos (Ler, Escrever, Inserir,
Executar).
Atravs de mecanismos de segurana, o SGBD dever ser capaz de analisar as requisies de
acesso dos sujeitos, permitindo, recusando ou modificando-as, limitando o acesso a dados no
autorizados, de acordo com as regras estabelecidas.
Uma poltica de segurana define a estratgia a ser utilizada no controle de acesso a
informaes contidas no banco de dados. So definidos os princpios pelos quais o acesso
permitido ou negado.
Regras de acesso estabelecem como e por quem as operaes (leitura, escrita, ...) podero ser
executadas, definindo os privilgios dos sujeitos. A poltica de segurana define como estas regras
sero administradas.
Polticas de controle de acesso estabelecem como objetos e sujeitos podem ser agrupados para
compartilhar as autorizaes e regras estabelecidas de acordo com a poltica de segurana. Tambm
podem definir se e como os privilgios podem ser transferidos de um sujeito para outro. Agrupando
ou classificando sujeitos que compartilham privilgios, simplificamos a especificao da poltica de
segurana a ser adotada e tambm a implementao dos mecanismos de segurana e sua
administrao.
Polticas de controle de acesso podem ser classificadas em discricionrias ou compulsrias. A
seguir descreveremos estas polticas.
2.1. Polticas Discricionrias
Numa poltica de controle de acesso discricionria, so especificadas para cada sujeito, as regras e
privilgios de acesso aos objetos do sistema. As requisies de acesso so analisadas por um
mecanismo de segurana discricionrio e o acesso concedido de acordo com as regras de
autorizao.
Polticas discricionrias se baseiam na concesso e revogao de privilgios. O controle
poder ser centralizado, isto , a autorizao administrada por um controle central, normalmente o
administrador do banco de dados. Podem ter tambm um controle descentralizado de maneira que o
proprietrio da informao possui o direito de conceder ou revogar os privilgios.
Estas polticas tm a vantagem de serem flexveis podendo ser utilizadas por vrios tipos de
sistemas e aplicaes comerciais e industriais e, conseqentemente, so atualmente as mais utilizadas.
Vrios modelos foram propostos e implementados em vrios sistemas operacionais e SGBDs, porm
no satisfazem totalmente certos requisitos de segurana, como no caso em que um usurio com
permisso de leitura a determinada informao poder transferi-la para um objeto de outro usurio
que no possui esta permisso. Podemos ento concluir que as polticas discricionrias protegem os
objetos do sistema, mas no so capazes de controlar o fluxo das informaes.
No caso especfico de aplicaes de banco de dados, as polticas de controle de acesso
discricionrias no permitem classificar os objetos e sujeitos no que diz respeito confidencialidade.
Com isto, no possvel criar uma poltica que possa restringir os privilgios de acesso a informaes
confidenciais com base na classificao dos sujeitos, independentemente de especificaes
determinadas pelo administrador. Este tipo de poltica importante quando se deseja limitar a
autoridade do administrador do banco de dados, protegendo informaes confidenciais, muitas vezes
vitais, como no caso dos sistemas militares. Mas sua aplicao pode ser bem mais abrangente, sendo
fundamental em qualquer sistema onde a confidencialidade das informaes for importante.
2.2. Polticas Compulsrias
O primeiro modelo de poltica de controle de acesso compulsria (Mandatory Access Control -
MAC) foi apresentado por Bell e La Padula [10] como uma extenso ao modelo discricionrio
baseado em matriz de acesso [07]. O modelo foi orientado para a proteo de recursos de Sistemas
Operacionais em face ao problema de sigilo de informaes, porm se tornou um modelo conceitual
que deu origem a outros com aplicaes especficas, inclusive em bancos de dados relacionais.
As polticas compulsrias se caracterizam pela definio de classes de segurana para os
sujeitos e objetos. As classes de segurana so determinadas por duas caractersticas: O nvel de
classificao e a categoria.
O nvel de classificao reflete a sensibilidade da informao, como por exemplo: Pblico,
confidencial, secreto e ultra secreto.
J as categorias buscam refletir reas ou departamentos das organizaes. Em uma indstria,
por exemplo, poderamos ter as seguintes reas:
- Produo
- Comercial
- Administrao, etc ...
Cada objeto possui um nvel de classificao 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 nvel de classificao for igual ou superior ao do objeto e se
pertencer a pelo menos a uma classe a que o objeto tambm pertena.
Foram propostos modelos com poltica compulsria, voltados para proteo de bancos de
dados relacionais como o SeaView (Secure dAta VIEW) [07], que agrega poltica discricionria com
poltica compulsria, o modelo proposto por Jajodia and Sandhu [07] e o modelo Smith and
Winslett [07].
Estes modelos tm em comum o fato de que o nvel de classificao da informao definido
para cada tupla de uma relao, sendo que cada atributo desta instncia poder ter um nvel diferente
(relaes multi-nvel). Tomando como base o modelo SeaView, temos que cada tupla de uma relao
representada na forma (a
1
|c
1
, ..., a
n
|c
n
, t) onde a
i
|c
i
representa respectivamente o valor e a classe do
atributo i e t a classe de acesso associada tupla.
Neste caso, a nvel de implementao, cada elemento a
i
de uma tupla deve ser acompanhado
de um rtulo c
i
, o que denominado por Labeled Security Protection [09].
Este tipo de implementao requer modificaes no ncleo do SGBD, pois envolve o
armazenamento das informaes de segurana associadas a cada linha. Alm disso, as avaliaes de
segurana para o retorno de informaes aos usurios so realizadas aps a recuperao das
informaes do banco de dados. Conclumos que este tipo de implementao da poltica compulsria
em SGBDs requer um grande esforo de desenvolvimento, pois determinam mudanas no ncleo.
Motivados pela importncia das polticas compulsrias, propomos neste trabalho, a discusso
de um modelo alternativo, que possa contar com a maior parte das vantagens da aplicao destas
polticas em bancos de dados relacionais, mas que propicie uma implementao com menor esforo.
3. O Modelo Proposto
Nossa proposta parte da premissa de que as caractersticas de uma dada relao, bem com os
significados de seus atributos (em detrimento do seus valores), so suficientes para se definir sua
classificao quanto segurana.
A poltica se baseia na organizao hierrquica dos componentes do banco de dados. A
organizao e os componentes so:
- Base de dados
- Tabela (Relao)
- Coluna (Atributo)
As polticas compulsrias se caracterizam pela definio de classes de segurana para os
sujeitos e objetos. As classes de segurana so determinadas pelo nvel de classificao que reflete a
sensibilidade da informao e a categoria, ou rea de aplicao.
Nos modelos SeaView (Secure dAta VIEW)[07], Jajodia and Sandhu [07] e Smith and
Winslett [07], as classe de segurana so tratadas considerando o contedo do banco de dados, isto ,
podem variar de acordo com instncias de uma relao. O modelo aqui proposto trata as classes de
segurana de acordo com o esquema do banco de dados, independentemente de seu contedo,
facilitando a implementao.
Cabe salientar que a poltica compulsria vem complementar a poltica discricionria, de
forma que a autorizao de acesso primeiramente deve ser concedida atravs de regras da poltica
discricionria e confirmada ou negada pela poltica compulsria. A poltica compulsria ento
aplicada somente nas operaes de leitura e escrita de dados (SELECT, UPDATE, INSERT).
3.1. Nvel de classificao
De forma semelhante ao modelo SeaView dividimos os nveis de classificao em quatro: Ultra-
secreto (US); Secreto (S); Confidencial (C); Publico (P). Estes nveis so assim ordenados: US > S >
C > P.
Tratemos aqui como objetos, a base de dados, as tabelas (relaes) e as colunas (atributos).
Cada objeto pode ser classificado segundo os nveis de classificao acima, ou simplesmente no ser
classificado (Nvel N), o mesmo ocorrendo com os sujeitos (usurios).
Chamamos de Cs o nvel de classificao do sujeito, dado pelo administrador do sistema e Co
o nvel de classificao do objeto que obtido analisando a hierarquia de objetos do banco de dados.
3.1.1. Determinando o nvel de classificao do objeto (Co)
A seguir descrevemos os passos para a obteno do nvel de classificao do objeto.
Passo 1: Inicialmente consideramos o nvel de classificao Co como No Classificado (N ou
NULL).
Passo 2: Verificamos o nvel de classificao da base de dados qual os dados solicitados pertencem
ou na qual os dados sero gravados. Caso possua classificao, esta passar a ser a classificao Co
do Objeto, caso contrrio Co continuar como N.
Passo 3: Verificamos o nvel de classificao da tabela qual os dados solicitados pertencem ou na
qual sero gravados. Caso possua classificao, esta passar a ser a classificao Co, caso contrrio
permanecer com a classificao obtida no passo 2. Observamos que caso uma tabela no possua
classificao, esta herdar a classificao da base de dados a que pertence. Portanto uma tabela no
classificada difere de uma tabela classificada como pblica.
Passo 4: Por fim so analisadas as colunas. A classificao Co ser a maior classificao das colunas
requisitadas para a operao. Caso uma coluna no possua classificao, a mesma ter a classificao
obtida no passo 3. Da mesma forma que as tabelas, uma coluna no classificada herda a classificao
da tabela a qual pertence.
Na seo seguinte exemplificaremos a aplicao destes passos para a obteno do nvel de
classificao do objetos de acordo com a operao solicitada.
3.1.2. Obtendo a permisso de acesso
A permisso de acesso ser concedida se o nvel de classificao do sujeito (Cs) for maior ou igual ao
nvel de classificao do objeto (Co). A Tabela 3.1 apresenta um exemplo.
Tabela3.1 Tabela3.1 Tabela3.1 Tabela3.1- -- -AplicaodoNveldeclassificao AplicaodoNveldeclassificao AplicaodoNveldeclassificao AplicaodoNveldeclassificao
Base de Dados: Administracao Co = P (Publico)
Tabela: Funcionarios Co = NULL (No classificada)
Nome - Co = P Departamento - Co = C Salario - Co = S
Paulo Dep1 1000
Roberto Dep2 1000
Srgio Dep2 1000
Um sujeito com nvel de classificao Confidencial (Cs = C), poder executar a pesquisa:

SELECT Nome, Departamento FROM FUNCIONARIOS

Aplicando os passos da seo 3.1.1. para obter o nvel de classificao Co correspondente
pesquisa temos:
Passo 1: Inicialmente faremos Co = N.
Passo 2: O nvel de classificao da base de dados Administracao, conforme a Tabela 3.1 P,
portanto o objeto passa a ter Co = P.
Passo 3: - Ao verificarmos o nvel de classificao da tabela Funcionarios vemos que a mesma no
classificada. Portanto ela herda a classificao da base de dados. Neste caso continuamos com Co =
P.
Passo 4: Finalmente analisamos os nveis de classificao das colunas solicitadas pela consulta, no
caso Nome e Departamento. O maior nvel de classificao Confidencial, fazendo ento Co = C.
A operao ser permitida, pois Cc = Co. Devido herana do nvel de classificao, nos
casos em que todas as colunas tiverem a mesma classificao, no ser necessrio classificarmos
individualmente cada coluna, bastando classificar a tabela qual pertencem, facilitando a
administrao.
Aplicando os mesmo passos acima conclumos que sujeito no ser autorizado a executar a
consulta:

SELECT * FROM FUNCIONARIOS

Isto ocorre porque no Passo 4 a maior classificao ser da coluna Salario, fazendo Co = S.
Com isto temos Cc < Co, isto , o nvel de classificao do objeto superior ao do sujeito.
Opcionalmente a implementao poder definir que neste caso o sujeito ter permisso de executar a
consulta, porm a coluna Salario no ser mostrada, ou retornar com valores nulos. Neste caso o
item 4 da seo 3.1.1 dever ser alterado e o nvel de classificao do objeto ser obtido considerando
individualmente como objeto cada coluna requisitada.
3.2. Categoria
Complementando a organizao em classes de segurana, os objetos so agrupados em categorias. A
classificao em categorias sugerida neste trabalho se baseia nos princpios do modelo Bell-Lapadula
[10], adaptado para aplicao no controle de acesso a Bancos de Dados Relacionais. As categorias
podem representar os mais diversos aspectos de acordo com a aplicao do banco de dados. Uma
empresa industrial, por exemplo, pode representar os diversos departamentos, como: Compras,
Produo, Vendas, Financeiro, Pessoal, etc .... Neste caso, cada departamento representado por uma
categoria.
Os sujeitos e objetos podem pertencer a mais de uma categoria, ou no serem classificados.
Ao classificar o sujeito, determinamos para cada categoria, qual ele pertencer, que tipo de operao
ele poder realizar: SELECT, INSERT, UPDATE, DELETE. Para que seja concedido acesso de um
sujeito a determinado objeto, duas condies devem ser satisfeitas. A primeira que ele dever
pertencer a pelo menos uma categoria qual o objeto tambm pertena, ou o objeto no ser
classificado. A segunda que o sujeito deve estar autorizado a realizar a operao requisitada sobre
esta categoria.
De acordo com a hierarquia dos componentes do banco de dados, os componentes de nvel
hierrquico inferior herdam as categorias dos nveis superiores.
Dado o conjunto de categorias C
1
, C
2
, .., C
N
temos os seguintes subconjuntos de acordo com a
hierarquia dos componente:
- CT
b
[C
1
, C
2
, .., C
Nb
] Conjunto de categorias da base de dados que contm o objeto
- CT
t
[C
1
, C
2
, .., C
Nt
] Conjunto de categorias da tabela qual o objeto pertence
- CT
c
[C
1
, C
2
, .., C
Nc
] Conjunto de categorias da coluna cujos dados so solicitados
O conjunto de categorias do objeto (CT) a ser acessado ser dado por:
- CT = CT
b
CT
t
CT
c

Caso o conjunto CT seja vazio significa que o objeto no est classificado, podendo ser
acessado por sujeitos de qualquer categoria, desde que a permisso no tenha sido negada pelo nvel
de classificao ou pela poltica discricionria.
A organizao por categorias no pode ser confundida com o controle de acesso atravs de
papis (Roles), presente em SGDBs comerciais, como o Microsoft SQL Server 2000 [11]. Neste
tipo de controle no ocorre a classificao dos objetos, mas somente dos sujeitos, de forma a
compartilharem privilgios determinados pela poltica discricionria.
3.3. Sugestes para Implementao
A maioria dos SGBDs relacionais modernos possuem um catlogo [08]. No catlogo se encontram
armazenadas informaes como nome de tabelas, nomes de colunas, descries de restries (chaves,
NULL/NOT NULL., etc...) e outras informaes referentes estrutura do banco de dados. Alm
disso, o catlogo inclui informaes de segurana para implementao de polticas de controle de
acesso discricionrias. prtica comum, armazenar o prprio catlogo sob a forma de tabelas,
podendo utilizar o software do SGBD para consultar e atualizar o catlogo, por meio de linguagens de
consulta como a SQL.
As informaes de nvel de classificao e categoria propostas em nosso modelo, podero ser
implementadas como novos dados no catlogo do SGBD, o que no ocorre nos outros modelos
propostos que dependem do contedo do banco de dados. Se o SGBD utiliza tabelas para
armazenamento do catlogo, poderemos acrescentar as informaes em tabelas j existentes, ou criar
novas tabelas para estas informaes. A vantagem de criar novas tabelas que uma nova verso do
software do SGBD poder ser compatvel com bases de dados j instaladas, no necessitando nenhum
tipo de converso de dados.
4. Concluso
A unio do controle de acesso discricionrio e compulsrio possibilita a implementao de uma
poltica de segurana mais verstil e eficaz, tornando o SGBD capaz de atender a um nmero cada
vez maior de aplicaes, principalmente as que requerem um nvel de segurana mais elevado.
A grande vantagem do modelo proposto reside em um novo enfoque da poltica compulsria
de controle de acesso, facilitando sua implementao e possibilitando sua utilizao inclusive em
SGBSs de cdigo aberto. Como dito anteriormente, a implementao das polticas j propostas
requer mudanas no ncleo dos SGBDs, pois as informaes de segurana devero estar registradas
em cada linha das tabelas e, no caso das relaes multi-nvel, associadas a cada campo de
informao. Estas mudanas requerem um grande esforo de desenvolvimento.
Ao o tratarmos a segurana da informao com base apenas em suas caractersticas (base de
dados-relao-atributo) e no em seu contedo com nos modelos j propostos, possibilitamos seu
armazenamento no catlogo do SGBD, no se fazendo necessria a recuperao dos dados para
autorizar o acesso. Se dividirmos uma operao em um banco de dados em duas etapas, controle de
acesso e recuperao ou atualizao da informao, no modelo proposto as duas fases so
distintas. Isto ocorre porque o controle de acesso depende apenas das informaes do catlogo do
SGBD, tornando mais rpida a concesso ou negao do direito de acesso. Nos modelos existentes o
controle de acesso depender da recuperao da informao para sua tomada de deciso, levando em
muitos casos a esforos desnecessrios do SGBD, no caso de uma resposta negativa solicitao de
acesso.
A proposta apresentada ponto de partida para implementao de poltica compulsria em
SGBDs de baixo custo de propriedade (Software livre), possibilitando que um maior nmero de
usurios utilizem estas tecnologias. Um prottipo foi desenvolvido utilizando linguagem de alto
nvel, possibilitando a verificao da facilidade da implementao. Porm importante esclarecer
que apesar do modelo proposto ser de implementao mais simples, qualquer tipo de implementao
em um SGDB depende do estudo detalhado de seu cdigo fonte, motivo pelo qual esta
implementao no foi feita por ocasio deste trabalho.
5. Referncias

[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 Bblia, Traduo Edson Furmankiewicz, Ed. Campus, 2002

[04] The PostgreSQL Global Development Group, PostgreSQL 7.3.2 - Administrators 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
Aplicaes, 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

You might also like