Você está na página 1de 40

CAPITULO 16

Segurana
16.1 INTRODUO
As questes de segurana de dados esto frequentemente
associadas a questes de integridade de dados (pelo menos em
contextos informais), mas os dois conceitos so na realidade
bastante diferentes. Segurana se refere proteo de dados
contra revelao, alterao ou destruio no autorizadas;
integridade se refere exatido ou validade desses dados. Em
outras palavras:
- Segurana significa proteger os dados contra usurios no
autorizados.
- Integridade significa proteg-los contra usurios
autorizados.
De modo ainda mais informal: segurana significa garantir que
os usurios tero permisso de fazer aquilo que esto
tentando fazer; integridade envolve ter certeza de que aquilo
que eles esto tentando fazer est correto.
E claro que tambm existem algumas semelhanas: em ambos os
casos, o sistema precisa estar ciente de certas restrio que
os usurios no devem violar; nos dois casos, essas
restries devem ser especificadas (tipicamente pelo DBA) em
alguma linguagem adequada e tm de ser mantidas no catlogo
do sistema; e, nos dois casos, o SGBD deve monitorar
operaes de usurios para assegurar que as restries sero
impostas. Neste captulo, examinaremos a segurana em
particular (naturalmente, a integridade j foi discutida em
profundidade no Captulo 8 e em outras partes do livro).
Nota: a principal razo para separarmos to claramente nosso
exame dos dois tpicos o fato de considerarmos a
integridade absolutamente fundamental, enquanto vemos a
segurana como uma questo mais secundria.
Consideraes gerais
H numerosos aspectos a considerar no problema de segurana.
Entre outros:
- Aspectos legais, sociais e ticos (por exemplo, a pessoa
que faz a solicitao, digamos quanto ao crdito de um
cliente, tem direito legal informao solicitada?).
- Controles fsicos (por exemplo, a sala do computador ou
terminal trancada ou protegida de algum outro modo?).
- Questes de normas (por exemplo, como a empresa
proprietria do sistema decide quem deve ter acesso a que?).
- Problemas operacionais (por exemplo, se usado um esquema
de senha, como conservado o segredo das prprias senhas?
Com que frequncia elas so trocadas?).
438
- Controles de hardware (por exemplo, a unidade de
processamento fornece recursos de segurana, tais como chaves
de proteo de armazenamento ou um modo protegido de
operao?).
- Suporte do sistema operacional (por exemplo, o sistema
operacional subjacente apaga o contedo da memria principal
e dos arquivos de disco quando termina de trabalhar com
eles?).
e, finalmente:
- Questes que so de interesse especifico do prprio sistema
de banco de dados (por exemplo, o sistema de banco de dados
tem um conceito de propriedade de dados?).
Por razes bvias, vamos considerar neste captulo
principalmente questes dessa ltima categoria.
Os SGBDs modernos em geral admitem agora uma ou as duas
abordagens gerais para segurana de dados. As abordagens so
conhecidas como controle discricionrio e mandatrio,
respectivamente. Em ambos os casos, a unidade de dados ou o
objeto de dados que poderia necessitar de proteo pode
variar de um banco de dados inteiro por um lado, at um
componente especifico dentro de uma tupla especfica no outro
lado. A maneira como as duas abordagens diferem indicada
pelo seguinte esboo:
- No caso de controle discricionrio, um dado usurio ter em
geral direitos de acesso (tambm conhecidos como privilgios)
diferentes sobre objetos diferentes. Alm disso, h bem
poucas limitaes ou seja, limitaes inerentes sobre
quais usurios podem ter quais direitos sobre quais objetos
(por exemplo, o usurio Ul pode ser capaz de ver A, mas no
B, enquanto o usurio U2 pode ser capaz de ver B, mas no A).
Assim, os esquemas discricionrios so muito flexveis.
- Em contraste, no caso de controle mandatrio, cada objeto
de dados assinalado com um certo nvel de classificao, e
cada usurio recebe um certo nvel de liberao. O acesso a
um determinado objeto de dados s pode ser feito por usurios
com a liberao apropriada. Os esquemas mandatrios tendem
assim a ser hierrquicos por natureza e, desse modo,
comparativamente rgidos. (Se o usurio Ul pode ver A mas no
B, ento a classificao de B deve ser maior que a de A, e
ento nenhum usurio U2 poder ver B sem poder ver A.)
Discutiremos esquemas discricionrios na Seo 16.2 e os
esquemas mandatrios na Seo 16.3. Independente de estarmos
lidando com um esquema discricionrio ou um esquema
mandatrio, todas as decises quanto aos usurios que tero
permisso para executar quais operaes sobre quais objetos
so decises de poltica, no tcnicas. Como tais, elas esto
claramente fora da jurisdio do SGBD; tudo que o SGBD pode
fazer impor essas decises, uma vez que elas sejam tomadas.
Decorre que:
- Os resultados dessas decises polticas (a) devem ser
levados ao conhecimento do sistema (isso feito por meio de
instrues em alguma linguagem de definio apropriada), e
(b) deve ser memorizado pelo sistema (isso feito gravando-
se esses resultados no catlogo).
- preciso que haja um meio de verificar uma dada
solicitao de acesso em relao s restries de segurana
aplicveis no catlogo. (Por solicitao de acesso queremos
indicar aqui a combinao de operao solicitada mais objeto
solicitado mais usurio solicitante, em geral.) Essa
verificao feita pelo subsistema de segurana do SGBD,
tambm conhecido por subsistema de autorizao.
- Para decidir quais restries de segurana so aplicveis a
uma determinada solicitao de acesso, o sistema precisa ser
capaz de reconhecer a origem dessa solicitao isto ,
precisa ser capaz de reconhecer o usurio solicitante. Por
isso, quando os usurios se conectam ao sistema, em geral
eles so obrigados a fornecer no apenas sua ID de usurio
(para dizerem quem so), mas tambm uma senha (para provar
que so quem dizem ser). A senha supostamente conhecida
apenas pelo sistema e por usurios legtimos da ID de usurio
em questo.*
* A verificao de que os usurios so quem dizem ser
chamada autenticao. Observamos de passagem que agora esto
disponveis tcnicas de autenticao muito mais sofisticadas
que a simples verificao de senhas, envolvendo uma grande
variedade de dispositivos hiomtricos (leitoras de impresses
digitais, scanners de retina, verificadores de imagem da
geometria da mo, verificadores de voz, dispositivos de
reconhecimento de assinaturas etc.). Tais dispositivos podem
todos efetivamente ser usados
para verificar caractersticas pessoais que ningum pode
roubar [16.3]. 439
Quanto a esse ltimo ponto, observe a propsito que qualquer
nmero de usurios distintos poderia partilhar da mesma ID.
Assim, o sistema pode admitir grupos de usurios e pode,
portanto, fornecer um meio que permita (digamos) a qualquer
pessoa do departamento de contabilidade compartilhar os
mesmos privilgios sobre os mesmos objetos. As operaes de
adicionar usurios individuais ou remover usurios
individuais de um dado grupo podem ento ser realizadas de
forma independente da operao de especificar quais
privilgios sobre quais objetos se aplicam a esse grupo.
Porm, observe que o lugar evidente para manter um registro
de quais usurios esto em quais grupos uma vez mais o
catlogo (ou talvez o prprio banco de dados). Nessa conexo,
chamamos sua ateno para a referncia [16.9], que descreve
um sistema no qual grupos de usurios podem estar aninhados.
Citando a referncia: a capacidade de classificar usurios
em uma hierarquia de grupos fornece uma ferramenta poderosa
para a administrao de sistemas de grande porte, com
milhares de usurios e objetos.
16.2 CONTROLE DE ACESSO DISCRICIONRIO
Repetindo o que foi dito na seo anterior, a maior parte dos
SGBDs admite controle discricionrio, controle mandatrio ou
ambos. Na verdade, seria mais exato dizer que a maioria dos
sistemas admite o controle discricionrio, e alguns sistemas
admitem tambm o controle mandatrio; assim, na prtica
mais provvel encontrar o controle discricionrio e ento
vamos lidar com ele primeiro.
Como j observamos, preciso que haja uma linguagem que
admita a definio de restries de segurana
(discricionrias). Porm, por razes bastante bvias, mais
fcil declarar o que permitido do que enunciar o que no
permitido; por essa razo, as linguagens em geral admitem a
definio, no de restries de segurana em si, mas de
autoridades, que so efetivamente o oposto das restries de
segurana (se algo autorizado, no restringido).
Comeamos pois por descrever rapidamente uma linguagem para
definir autoridades.* Primeiro, um exemplo simples:
AUTHORITY AF3
GRANT RETRIEVE ( F#. FNOME. CIDADE ), DELETE
ON F
TO Jim, Fred, Mary ;
Esse exemplo ilustra o fato de que (em geral) autoridades tm
quatro componentes, como:
1. Um nome (AF3 autoridade de fornecedores trs no
exemplo). A autoridade ser registrada no catlogo sob esse
nome.
2. Um ou mais privilgios (RETRIEVE sobre certos atributos
apenas e DELETE, no exemplo), especificados por meio da
clusula GRANT.
3. A varivel de relao qual a autoridade se aplica (no
exemplo, a varivel de relao F), especificada por meio da
clusula ON.
4. Um ou mais usurios (mais precisamente, IDs de usurios)
a quem devem ser concedidos os privilgios especificados
sobre a varivel de relao especificada, definidos por meio
da clusula TO.
Ento, aqui temos a sintaxe geral:
AUTHORITY <nome de autoridade>
GRANT <lista_com_vrgulas de privilgios>
ON <nome de varivel de relao>
TO <lista_com_vrgulas de IDs de usurios>
Explicao: os itens <nome de autoridade>, <nome de varivel
de relao> e <lista_com_vigulas de iDs de usurios> so
auto-explicativos (exceto pelo fato de considerarmos ALL,
representando todos os usurios conhecidos, como uma ID de
usurio vlida nesse contexto). Cada <privilgio> um dos
seguintes:
* A definio original de Tutorial D [3.3] no inclua
qualquer recurso de definio de autoridade mas a linguagem
hipottica 440 desta seo pode ser considerada no esprito
de Tutorial D.
RETRIEVE [ ( <lista com vrgulas de nomes de atributos> ) ]
INSERT [ ( <lista com vrgulas de nomes de atributos> ) 1
UPDATE [ ( <lista com vrgulas de nomes de atributos> ) j
DELETE
ALL
RETRIEVE (no qualificado), INSERT (no qualificado), UPDATE
(no qualificado) e DELETE so auto-explicativos.' Se uma
lista_com_vrgulas de nomes de atributos for especificada com
RETRIEVE, ento o privilgio se aplicar somente aos
atributos especificados. INSERT e UPDATE com uma
lista_com_vrgulas de nomes de atributos so definidos de
maneira anloga. A especificao ALL uma abreviao para
todos os privilgios: RETRIEVE (todos os atributos), INSERT
(todos os atributos), UPDATE (todos os atributos) e DELETE.
Nota: para simplificar, ignoramos a questo de saber se so
ou no necessrios privilgios especiais para a execuo de
operaes gerais de atribuio relaciona!. Alm disso,
estamos de!iberadamente limitando nossa ateno a operaes
de manipulao de dados apenas; na prtica, claro, h
muitas outras operaes que tambm gostaramos de submeter a
regras de segurana, tais como as operaes para definir e
descartar variveis de relaes e para definir e descartar as
prprias autoridades. Deixamos de lado a considerao
detalhada de tais operaes por razes de espao.
O que deve acontecer se algum usurio tentar alguma operao
sobre algum objeto para o qual no est autorizado?
Evidentemente, a opo mais simples apenas rejeitar a
tentativa (e, claro, fornecer informaes de diagnstico
adequadas); com certeza essa resposta ser a mais comumente
necessria na prtica, de modo que poderamos torn-la o
default. Porm, em situaes mais delicadas, alguma outra
ao talvez fosse mais adequada; por exemplo, poderia ser
necessrio encerrar o programa ou bloquear o tec!ado do
usurio. Tambm poderia ser desejvel registrar tais
tentativas em um log especial (monitoramento de ameaas) para
permitir a anlise subsequente de tentativas de romper a
segurana, e tambm para servir por si s como preveno
contra infiltrao ilegal (consulte a discusso sobre trilhas
de auditoria no final desta seo).
E claro que tambm precisamos de um modo de descartar
autoridades:
DROP AUTHORITY <nome de autoridade>
Por exemplo:
DROP AUTHORITY AF3 ;
Para simplificar, vamos supor que a ao de descartar uma
determinada varivel de relao ir descartar automaticamente
quaisquer autoridades que se apliquem a essa varivel de
relao.
Aqui esto mais alguns exemplos de autoridades, a maioria
delas auto-explicativa:
1. A1JTHORITY EX1
GRANT RETRIEVE ( P#, PNOME, PESO
ON P
TO Jacques, Anne, Charley
Os usurios Jacques, Anne e Charley podem ver um subconjunto
vertical da varivel de relao
bsica P. Temos ento um exemplo de autoridade independente
de valor.
2. AUTHORITY EX2
GRANT RETRIEVE, UPDATE ( FNOME, STATUS ), DELETE
ON LF
TO Dan, Misha
* Bem, talvez no de todo; o privilgio RETRIEVE tambm
necessrio apenas para mencionar o objeto relevante (por exem
plo em uma definio de viso ou restrio de integridade),
bem como para o acesso em si. 441
Aqui, a varivel de relao LF uma viso (fornecedores de
Londres consulte a Seo 9.4 no Captulo 9). Os usurios
Dan e Misha podem ver um subconjunto horizontal da varivel
de relao bsica F. Esse , portanto, um exemplo de
autoridade dependente de valor. Observe tambm que, embora os
usurios Dan e Misha possam usar DELETE para remover certas
tuplas de fornecedores (por meio da viso LF), eles no podem
usar INSERT para inseri-las nem podem usar UPDATE nos
atributos F# ou CIDADE.
3. VAR FFPPR VIEW
F JOIN FP JOIN ( P WHERE CIDADE = Roma' ) { P#
{ ALL BUT P#, QDE
AUTHORITY EX3
GRANT RETRIEVE
ON FFPPR
TO Giovanni
Esse outro exemplo de autoridade dependente de valor: o
usurio Giovanni pode buscar informaes de fornecedores, mas
apenas para fornecedores que forneam alguma pea armazenada
em Roma.
4. VAR FFQ VIEW
SUMMARIZE FP PER F { F# } ADD SUM ( QDE ) AS FQ ;
AUTHORITY EX4
GRANT RETRIEVE
ON FFQ
TO Fidel ;
O usurio Fidel pode ver quantidades totais de remessas por
fornecedor mas no quantidades de remessas individuais.
Assim, o usurio Fidel v um resumo estatstico dos dados
bsicos subjacentes.
5. AUTHORITY EX5
GRANT RETRIEVE, UPDATE ( STATUS
ON F
WHEN DAY O IN ( Seg, `Ter', `Qua, `Qui', `Sex
AND NOW O $ TIME 09:00:00
AND NOW O _ TIME `17:00:00
TO Compras
Estamos ampliando aqui nossa sintaxe de AUTHORITY para
incluir uma clusula WHEN, cuja finalidade especificar
certos controles de contexto; tambm estamos supondo que o
sistema fornece dois operadores nildicos isto ,
operadores que no utilizam operandos chamados DAYO e NOWO,
com as interpretaes evidentes. A autoridade EXS garante que
valores de status de fornecedores podem ser alterados pelo
usurio Compras (presumivelmente significando qualquer
pessoa no departamento de compras) apenas em um dia til e
somente durante o expediente. Esse um exemplo do que s
vezes se chama autoridade dependente de contexto, porque uma
dada solicitao de acesso ser ou no permitida, dependendo
do contexto no caso, a combinao de dia da semana e hora
do dia em que ela emitida.
Outros exemplos de operadores embutidos que o sistema
provavelmente deve admitir de qualquer forma e que poderiam
ser teis para autoridades dependentes de contexto incluem:
TODAY() valor = a data atual
USER() valor = a 10 do usurio atual
TERMINAL() valor a ID do terminal de origem da solicitao
atual
Voc provavelmente j percebeu que, falando-se
conceitualmente, as autoridades so todas reunidas por OR.
Em outras palavras, uma dada solicitao de acesso
(significando, repetimos, a combinao de
442 operao solicitada mais objeto solicitado mais usurio
solicitante) aceitvel se e somente se pelo menos
uma autoridade a permite. Contudo, observe que (por exemplo),
se (a) uma autoridade permitir que a usuria Nancy obtenha
cores de peas e (b) outra permitir que ela leia pesos de
peas, isso no quer dizer que ela possa ler cores e pesos de
peas juntos ( necessria uma autoridade separada para a
combinao).
Finalmente, demos a entender mas nunca realmente declaramos,
que os usurios podem fazer apenas aquilo que explicitamente
lhes permitido pelas autoridades definidas. Tudo que no
for explicitamente autorizado ser implicitamente proibido!
Modificao de solicitao
Para ilustrar algumas das idias introduzidas na seo
anterior, vamos descrever agora rapidamente os aspectos de
segurana do prottipo University Ingres e de sua linguagem
de consulta QUEL, pois eles adotam uma interessante abordagem
para o problema. Basicamente, qualquer solicitao dada em
QUEL modificada de forma automtica antes da execuo, de
tal modo que no tenha a possibilidade de violar qualquer
restries de segurana especificada. Por exemplo, suponha
que o usurio U tenha permisso somente para recuperar peas
armazenadas em Londres:
DEFINE PERMIT RETRIEVE ON P TO U
WHERE P.CIDADE = Londres
(veja a seguir os detalhes da operao DEFINE PERMIT). Agora,
vamos supor que o usurio U emita a seguinte solicitao de
QUEL:
RETRIEVE ( P.P# P.PESO )
WHERE P.COR = Vermelho
Usando a permisso para a combinao da varivel de relao
P e usurio U armazenada no catlogo, o sistema modifica
automaticamente essa solicitao, de tal modo que ela seja
semelhante a:
RETRIEVE ( P.P# P.PESO )
WHERE P.COR = Vermelho
AND P.CIDADE = Londres
claro que essa solicitao modificada no tem a
possibilidade de violar a restrio de segurana. A
propsito, observe que o processo de modificao
silencioso: o usurio U no informado de que o sistema
executou uma instruo um pouco diferente da solicitao
original, porque esse fato poderia ele prprio ser
confidencial (talvez o usurio U no tenha sequer permisso
para saber que existem peas no de Londres).
O processo de modificao de solicitao que acabamos de
descrever na verdade idntico tcnica usada para a
implementao de vises [8.20], e tambm especificamente no
caso do prottipo Ingres restries de integridade [9.15].
Assim, uma vantagem do esquema o fato de ser muito fcil
implement-lo grande parte do cdigo necessrio j existe
no sistema. Outra vantagem o fato de ser ele
comparativamente eficiente o gasto para imposio da
segurana ocorre em tempo de compilao e no em tempo de
execuo, pelo menos em parte. Outra vantagem que alguns
descasamentos que poderiam ocorrer com a abordagem de SQL
quando um determinado usurio precisasse de privilgios
diferentes sobre partes diferentes da mesma varivel de
relao (consulte a Seo 16.6) no surgem nesse caso.
Uma desvantagem que nem todas as restries de segurana
podem ser tratadas dessa forma simples. Como um contra-
exemplo trivial, suponha que o usurio U no tenha permisso
alguma para acesso varivel de relao P. Ento, nenhuma
forma modificada simples da operao RETRIEVE mostrada
antes pode preservar a iluso de que a varivel de relao P
no existe. Em vez disso, uma mensagem de erro explcita
semelhante a Voc no ter permisso para acesso a esta
varivel de relao deve necessariamente ser produzida. (Ou
talvez o sistema pudesse simplesmente mentir e dizer Essa
varivel de relao no existe.)
443
Aqui est ento a sintaxe de DEFINE PERMIT:
DEFINE PERMIT <lista com vrgulas de nomes de operaes>
ON <nome de varivel de relao> [ ( <lista_com_vrgulas de
nomes de atributos> ) 1 TO <ID de usurio> ]
[ AT <lista com vrgul as de nomes de terminais> 1
FROM <hora> TO <hora> ]
ON <dia> TO <dia> ]
WHERE <expresso booleana> 1
Conceitualmente, essa instruo bem semelhante nossa
instruo AUTHORITY, exceto pelo fato de admitir uma clusula
WHERE. Aqui temos um exemplo:
DEFINE PERMIT APPEND, RETRIEVE, REPLACE
ON F ( F#, CIDADE
TO Joe
AT TTA4
FROM 9:00 TO 17:00
ON Sb TO Dom
WHERE F.STATUS < 50
AND F.F# = FP.P#
AND FP.P# = P.P#
AND P.COR = `Vermelho
Nota: APPEND e REPLACE so os anlogos de QUEL para nossos
operadores INSERT e UPDATE, respectivamente.
Trilhas de auditoria
importante no supor que o sistema de segurana seja
perfeito. Um candidato a invasor que seja suficientemente
determinado, em geral, encontrar um meio de romper os
controles, em especial se a recompensa por essa ao for
grande. Por essa razo, em situaes em que os dados so
confidenciais o bastante, ou onde o processamento executado
sobre os dados suficientemente crtico, uma trilha de
auditoria se torna necessria. Se, por exmplo, discrepncias
nos dados gerarem a suspeita de que o banco de dados foi
violado, a trilha de auditoria poder ser usada para examinar
o que est acontecendo e verificar se tudo est sob controle
(ou para ajudar a identificar o invasor, em caso contrrio).
Uma trilha de auditoria em essncia um arquivo ou banco de
dados especial em que o sistema automaticamente acompanha
todas as operaes realizadas por usurios sobre os dados
normais. Em alguns sistemas, a trilha de auditoria pode estar
fisicamente integrada ao log de recuperao (consulte o
Captulo 14) e em outros os dois sistemas podem ser
distintos; de qualquer modo, os usurios devem ser capazes de
examinar a trilha de auditoria usando sua linguagem de
consulta normal (desde que estejam autorizados de forma
adequada, claro!). Uma entrada tpica de trilha de
auditoria poderia conter as seguintes informaes:
Solicitao (texto de origem).
Terminal de onde a operao foi chamada.
Usurio que invocou a operao.
Data e hora da operao.
Varivel (is) de relao(es), tupla(s), atributo(s)
afetados.
Valores antigos.
Novos valores.
444
Conforme mencionamos antes nesta seo, o simples fato de uma
trilha de auditoria estar sendo mantida pode ser suficiente
para deter o candidato a invasor em algumas situaes.
16.3 CONTROLE DE ACESSO MANDATRIO
Controles mandatrios so aplicveis a banco de dados nos
quais os dados tm uma estrutura de classificao bastante
esttica e rgida, como tende a ocorrer em certos ambientes
(por exemplo) militares ou governamentais. Como explicamos
rapidamente na Seo 16.1, a idia bsica que cada objeto
de dados tem um nvel de classificao (por exemplo,
altamente secreto, secreto, confidencial etc.), e cada
usurio tem um nvel de liberao (com as mesmas
possibilidades que vimos para os nveis de classificao).
Suponha-se que os nveis formem uma ordenao estrita (por
exemplo, altamente secreto > secreto > confidencial, etc.).
As regras simples a seguir, criadas por Bell e La Padula
[16.1] so ento impostas:
1. O usurio i s pode ver o objeto j se o nvel de liberao
de i maior ou igual ao nvel de classificao de j (a
propriedade de segurana simples).
2. O usurio i s pode atualizar o objeto j se o nvel de
liberao de i igual ao nvel de classificao de j (a
propriedade estrela).
No caso, a primeira regra bastante bvia, mas a segunda
requer algumas explicaes. Primeiro, observe que outro modo
de enunciar essa segunda regra dizer que, por definio,
qualquer coisa escrita pelo usurio i adquire automaticamente
um nvel de classificao igual ao nvel de liberao de i.
Essa regra necessria para evitar que um usurio com,
digamos, classificao secreta copie dados secretos em um
arquivo com classificao inferior, subvertendo assim o
objetivo do esquema de classificao. Nota: do ponto de vista
de operaes puras de gravao (INSERT) apenas, seria
suficiente dizer, no caso da segunda regra, que o nvel de
liberao de i tem de ser menor ou igual ao nvel de
classificao dej e a regra com frequncia enunciada dessa
forma na literatura. Porm, assim os usurios poderiam gravar
coisas que no pudesem ler! (de outro modo, algumas pessoas
de fato tm dificuldade de ler o que escreveram... talvez por
isso a regra mais fraca no to irrealista assim).
Os controles mandatrios comearam a receber muita ateno no
mundo de bancos de dados no incio dos anos noventa, porque
foi nessa poca que o Departamento de Defesa dos EUA (DoD
US Department of Defense) comeou a exigir que qualquer
sistema que adquirisse tivesse suporte para esses controles.
Por isso, os fornecedores de SGBDs vm disputando uns com os
outros a primazia de implementar tais controles. Os controles
em questo esto documentados em duas importantes publicaes
do DoD, conhecidas informalmente como Orange Book [16.19] e
Lavender Book [16.20], respectivamente. O Orange Book define
um conjunto de exigncias de segurana para toda Trusted
Computing Base (TCB), e o Lavender Book define uma
interpretao das exigncias do TCB especificamente para
sistemas de banco de dados.
Os controles mandatrios definidos nas referncias [16.19 e
16.20], na verdade, fazem parte de um esquema mais geral de
classificao de segurana global, que resumimos aqui para
fins de referncia. Primeiro, os documentos definem quatro
classes de segurana (D, C, B e A). De modo geral, a classe D
a menos segura, a classe C mais segura que a classe D e
assim por diante. Dizemos que a classe D fornece proteo
mnima, a classe C proteo discricionria, a classe B
proteo mandatria e a classe A proteo verificada.
- Proteo discricionria: a classe C se divide em duas
subclasses, Cl e C2 (onde Cl menos segura que C2). Cada uma
admite controle de acesso discricionrio, o que significa que
o controle de acesso est sujeito discrio (ao critrio)
do proprietrio dos dados (como descrevemos na Seo 16.2
anterior). Alm disso:
1. A classe Cl distingue entre propriedade e acesso; isto ,
admite o conceito de dados compartilhados, enquanto permite
aos usurios terem tambm seus prprios dados privados.
2. A classe C2 exige suporte contbil adicional atravs de
procedimentos de inscrio, auditoria e
isolamento de recursos. 445
1
Proteo mandatria: a classe B a classe que lida com
controles mandatrios. Ela se divide ainda nas subclasses Bi,
B2 e B3 (onde Bi a menos segura das trs e B3 a mais
segura), da seguinte maneira:
1. A classe BI exige proteo de segurana rotulada (isto
, exige que cada objeto de dados seja marcado com seu nvel
de classificao secreto, confidencial, etc.). Ela tambm
exige uma declarao informal da poltica de segurana
adotada.
2. A classe B2 exige uma declarao formal da mesma norma.
Ela tambm exige que canais encobertos sejam identificados e
eliminados. Exemplos de canais encobertos seriam (a) a
possibilidade de inferir a resposta a uma consulta invlida a
partir da resposta a uma consulta vlida (veja a Seo 16.4),
ou (b) a possibilidade de deduzir informaes confidenciais a
partir do tempo necessrio para executar algum clculo vlido
(consulte a anotao referncia [16.121).
3. A classe B3 exige especificamente suporte de auditoria e
recuperao, bem como um administrador de segurana
designado.
- Proteo verificada: a classe A, a mais segura, exige uma
prova matemtica de que (a) o mecanismo de segurana
consistente e que (b) ele adequado para admitir a norma de
segurana especificada (!).
Vrios produtos comerciais de SGBDs fornecem atualmente
controles mandatrios no nvel Bi. Em geral, eles tambm
fornecem controles discricionrios no nvel C2. Terminologia:
os SGBDs que admitem controles mandatrios so chamados
frequentemente sistemas seguros em vrios nveis (multi
levei) [16.13], [16.16] e [16.21] (consulte a subseo
imediatamente seguinte), O termo confivel (trusted) tambm
usado quase com o mesmo significado [16.17], [16.19] e
[16.20].
Segurana em vrios nveis
Vamos supor que queremos aplicar as idias de controle de
acesso mandatrio varivel de relao de fornecedores F.
Para manter a preciso e a simplicidade, suponhamos que a
unidade de dados qual desejamos controlar o acesso a
tupla individual dentro dessa varivel de relao. Ento,
cada tupla precisa ser identificada com seu nvel de
classificao, talvez da maneira mostrada na Figura 16.1 (4 =
altamente secreto, 3 = secreto, 2 = confidencial etc.).
FIGURA 16.1 A varivel de relao F com nveis de
classificao (exemplo)
Agora, suponha que os usurios Ul e U2 tenham nveis de
liberao 3 (secreto) e 2 (confidencial), respectivamente.
Ento, Ul e U2 vero a varivel de relao F de forma
diferente! Uma solicitao para recuperar todos os
fornecedores retornar quatro tuplas ou seja, as tuplas de
Fi, F2, F3 e F5 se emitida por Ul, mas apenas duas tuplas,
isto , as tuplas de Fi e F3 se emitida por U2. Alm disso,
nenhum dos dois usurios ver a tupla correspondente a F4.
Um modo de raciocinar sobre o que foi visto , mais uma vez,
pensar em termos de modificao de solicitao. Considere a
consulta a seguir (Obter fornecedores em Londres):
F
446 F WHERE CIDADE = Londres'
F FNO STAT CIDAD CLAS
# ME US E
SE

2
F
i
Smi
th
20 Londres
F
2
Jon
es
10 Paris 3
F
3
Bla
ke
30 Paris 2
F
4
Cla
rk
20
Londr
es
4
F
5
Ada
ms
30
Atena
s
3
O sistema modificar esse pedido de forma que ele fique
semelhante a:
F WHERE CIDADE = `Londres AND CLASSE _ liberao do usurio
Consideraes anlogas se aplicam a operaes de atualizao.
Por exemplo, o usurio Ul no est ciente de que a tupla para
F4 existe. Ento, para esse usurio, a operao INSERT a
seguir parece razovel:
INSERT INTO F RELATION { TUPLE { F# F# ( `F4 ),
FNOME NOME ( `Baker' ),
STATUS 25,
CIDADE `Roma'
O sistema no deve rejeitar essa INSERT, porque faz-lo
significaria efetivamente informar ao usurio Ul que o
fornecedor P4 afinal existe. Ento, o sistema a operao, mas
a modifica para:
INSERT INTO F RELATION { TUPLE { F# F# ( `F4' ),
FNOME NOME ( `Baker ),
STATUS 25,
CIDADE Roma,
CLASSE CLASS ( 3)
Observe que, por essa razo, a chave primria para
fornecedores no apenas {F#}, mas a combinao {F#,CLASSE}.
Nota: para simplificar, estamos supondo que existe apenas uma
chave candidata e que, portanto, podemos consider-la (sem
danos) como a chave primria.
Mais terminologia: a varivel de relao de fornecedores um
exemplo de uma varivel de relao em vrios nveis. O fato
de os mesmos dados parecerem diferentes para usurios
distintos chamado poli-instanciao. Por exemplo, seguindo
a operao INSERT recm-discutida, uma solicitao para
acessar o fornecedor F4 retorna um resultado para um usurio
com a liberao altamente secreta, outra para o usurio Ul
(com liberao secreta) e outra ainda para o usurio U2 (com
liberao confidencial).
UPDATE e DELETE so tratadas de modo anlogo (omitimos os
detalhes aqui, mas observamos que vrias referncias no final
do captulo discutem essas questes em profundidade). Uma
pergunta:
voc acha que as idias discutidas antes constituem uma
violao do Princpio da Informao? Justifique sua resposta!
16.4 BANCOS DE DADOS ESTATISTICOS
Nota: grande parte do material desta seo e da seguinte
surgiu originalmente em uma forma um pouco diferente na
referncia [16.4].
Um banco de dados estatstico (no contexto atual) um banco
de dados que permite consultas que derivam informaes
agregadas (por exemplo, totais, mdias), mas no consultas
que derivam informaes individuais. Por exemplo, a consulta
Qual a mdia de salrios de programadores? poderia ser
permitida, enquanto a consulta Qual o salrio da
programadora Mary? no seria.
O problema com esses bancos de dados que s vezes
possvel fazer inferncias a partir de consultas vlidas para
deduzir as respostas a consultas invlidas. Como observa a
referncia 16.6}: Os totais contm vestgios das informaes
originais; um usurio curioso poderia ser capaz de
(re)construir essas informaes processando totais em nmero
suficiente. Isso se chama deduo de informaes
confidenciais por inferncia. Observamos que esse problema
tem probabilidade de se tornar cada vez mais significativo
medida que aumentar o uso de data warehouses (consulte o
Captulo 21).
447
FIGURA 16.2 A varivel de relao STATS (amostra de valores)
Aqui est um exemplo detalhado. Vamos supor que o banco de
dados contenha apenas uma varivel de relao, STATS (ver
Figura 16.2). Para simplificar, suponha que todos os
atributos sejam definidos sobre tipos de dados primitivos
(basicamente, nmeros e strings). Suponha ainda que algum
usurio U esteja autorizado a executar consultas estatsticas
(apenas) e que sua inteno seja descobrir o salrio de Alf.
Finalmente, suponha que U sabe de fontes externas que Alf
um programador e do sexo masculino. Agora, considere as
consultas 1 e 2 a seguir:*
1. WITH ( STATS WHERE SEXO = `M' AND
OCUPAO = Programador' ) AS X
COUNT ( X )
Resultado: 1.
2. WITH ( STATS WHERE SEXO = `M' AND
OCUPAO = `Programador' ) AS X
SUM ( X, SALRIO
Resultado: 50 K. -
A segurana do banco de dados foi claramente comprometida,
embora o usurio U tenha emitida apenas consultas
estatsticas legitimas. Como o exemplo ilustra, se o usurio
puder encontrar uma expresso booleana que identifique algum
indivduo, ento as informaes a respeito desse indivduo
no mais sero seguras. Esse fato sugere que o sistema deve
se recusar a responder a uma consulta para a qual a
cardinalidade do conjunto a ser totalizado menor que algum
limite inferior b. Do mesmo modo, ele sugere que o sistema
tambm deve se recusar a responder se essa cardinalidade for
maior que o limite superior N b (onde N a cardinalidade
da relao recipiente), porque o compromisso anterior poderia
ser obtido igualmente bem a partir da sequncia de consultas
3 a 6 a seguir:
3. COUNT ( STATS
Resultado: 12.
4. WITH ( STATS WHERE NOT ( SEXO = `M' AND
OCUPAO = `Programador' ) ) AS X
COUNT ( X )
Resultado: 11; 12- 11 = 1.
* Para poupar digitao, as consultas desta seo sero todas
expressas em uma forma abreviada de Tutorial D. Por exemplo,
a expresso COUNT(X) na consulta 1 deve ser, de forma mais
apropriada, EXTEND TABLE_DEE ADD COUNT(X) AS
448 RESULT 1.
NOM
E
SEX
O
FILH
OS
OCUPAO
SALR
IO
IMPOST
OS
AUDI
TS
Alf M 3
Programad
or
50K 10K 3
Bea F 2 Fsico 130K 10K O
Car
y
F O
Programad
or
56K 18K 1
Daw
n
F 2
Construto
r
60K 12K 1
Ed M 2
Escritur
rio
44K 4K O
Fay F 1 Artista 30K 0K O
Guy M O Advogado 190K 0K O
Hal M 3
Dona de
casa
44K 2K O
Ivy F 4
Programad
or
64K 10K 1
Joy F 1
Programad
or
60K 20K 1
5. SUM ( STATS, SALRIO
Resultado: 728 K.
6. WITH ( STATS WHERE NOT ( SEXO `M' AND
OCUPAO = Programador ) ) AS X
SUM ( X, SALRIO
Resultado: 678 K; 728 K - 678 K = 50 K. -
Infelizmente, fcil mostrar que a simples restrio de
consultas quelas para as quais o conjunto a ser totalizado
tem cardinalidade c no intervalo b _ c _ N b em geral
inadequada para evitar o comprometimento. Considere mais uma
vez a Figura 16.2 e suponha b = 2; as consultas sero
respondidas somente se c estiver no intervalo 2 _ c _ 8.
Portanto, a expresso booleana:
SEXO = M' AND OCUPAO = Programador'
no mais admissvel. Porm, considere a sequncia de
consultas de 7 a 10:
7. WITH ( STATS WHERE SEXO = `M' ) AS X
COUNT ( X )
Resultado: 4.
8. WITH ( STATS WHERE SEXO = `M' AND NOT
OCUPAO = `Programador ) ) AS X
COUNT ( X )
Resultado: 3.
Das consultas 7 e 8, o usurio U pode deduzir que existe
exatamente um programador do sexo masculino, o qual deve
ento ser Alf (pois U j sabe que essa descrio se encaixa
em Alf). O salrio de Alf pode assim ser descoberto da
seguinte maneira:
9. WITH ( STATS WHERE SEXO = `M ) AS X
SUM ( X, SALRIO
Resultado: 328 K.
10. WITH ( STATS WHERE SEXO = `M AND NOT
OCUPAO = `Programador' )
SUM ( X, SALRIO
Resultado: 278 K; 328 K - 278 K = 50 K. -
A expresso booleana SEXO = `M' AND OCUPAO = `Programador'
chamada localizador individual para Alf [16.6], porque
permite ao usurio localizar informaes referentes ao
indivduo Alf. Em geral, se o usurio conhecer uma expresso
booleana BE que identifica algum indivduo 1 especfico, e se
BE pode ser expressa na forma BEl AND BE2, ento a expresso
booleana BEl AND NOT BE2 um localizar para 1 (desde que BEl
e BEl AND NOT BE2 sejam ambas admissveis ou seja,
identifiquem ambas conjuntos de resultados com cardinalidade
c no intervalo b _ c _ N b). A razo para isso que o
conjunto identificado por BE idntico diferena entre o
conjunto identificado por BEl e o conjunto identificado por
BEl AND NOT BE2:
set ( BE ) = set (BEl AND BE2
= set ( BEl ) minus set ( BEl AND NOT BE2
Consulte a Figura 16.3.
A referncia [16.6] generaliza as idias precedentes e mostra
que, para quase qualquer banco de dados estatstico, um
localizador geral (em oposio a um conjunto de localizadores
individuais) sempre pode ser encontrado. Um localizador geral
uma expresso booleana que pode ser usada para encontrar
a resposta de qualquer consulta inadmissvel ou seja,
qualquer consulta que envolve uma expresso inadmissvel. (Em
contraste, um localizador individual funciona apenas para
consultas envolvendo alguma expresso inadmissvel
especfica.) De fato, qualquer expresso com uma
cardinalidade c do conjunto de resultados no intervalo 2b _ c
_ N 2b um localizador geral (b deve ser menor que N/4, o
que em geral ocorrer em qualquer situao realista). Depois
de se encontrar um localizador, uma consulta envolvendo uma
expresso inadmissvel BE pode ser respondida da maneira
ilustrada no exemplo a seguir. (Por preciso, consideramos o
caso em que a cardinalidade do conjunto de resultados
correspondente a BE menor que b. O caso em que ela maior
que N b tratada de forma anloga.) Observe que uma
consequncia da definio que T um localizador geral se e
somente se NOT T tambm um localizador geral.
FIGURA 16.3 O localizador individual BE 1 AND NOT BE2
Exemplo: suponha mais uma vez que b = 2; ento, um
localizador geral qualquer expresso com a cardinalidade do
conjunto de resultados c no intervalo 4 _ c _ 6. Suponha
novamente que o usurio U sabe de fontes externas que Alf
um programador do sexo masculino isto , a expresso
booleana inadmissvel BE (como antes):
SEXO = M AND OCUPAO = Programador
e suponha que U deseja descobrir o salrio de Alf. Usaremos
um localizador geral duas vezes, primeiro para averiguar se
BE de fato identifica Alf de forma exclusiva (Passos de 2 a 4
a seguir), e depois para determinar o salrio de Alf (Passos
de 5 a 7).
Passo 1: fazer uma suposio de um localizador, T. Como nossa
suposio, escolhemos T como a expresso:
AUDITS = O
Passo 2: obter o nmero total de indivduos no banco de
dados, usando as expresses Te NOT T:
WITH ( STATS WHERE AUDITS = O ) AS X
COUNT ( x )
Resultado: 5.
WITH ( STATS WHERE NOT ( AUDITS = O ) ) AS X
COUNT ( X )
Resultado: 5; 5 + 5 = 10.
Agora podemos ver facilmente que nossa suposio T
realmente um localizador geral.
450
conjunto identificado
por BEl
conjunto
identificado por
BEl
AND conjunto
identificado
NOT por BEl e BE2
L BE2 -- isto , { 1
conjunto identificado
por BE2
Passo 3: obter o resultado da soma (a) do nmero de
indivduos no banco de dados mais (b) o nmero que satisfaz
expresso inadmissvel BE, usando as expresses BE OR T e BE
OR NOT T.
WITH ( STATS WHERE ( SEXO = M AND
OCUPAO = Programador
OR AUDITS = O ) AS X
COUNT ( X )
Resultado: 6.
WITH ( STATS WHERE ( SEXO M AND
OCUPAO = Programador
OR NOT ( AUDITS = O ) ) AS X
COUNT ( X )
Resultado: 5; 6 + 5 = 11.
Passo 4: a partir dos resultados obtidos at agora, temos que
o nmero de indivduos que satisfazem a BE um s (o
resultado do Passo 3 menos o resultado do Passo 2); ou seja,
BE designa Alf exclusiva- mente.
Agora, repetimos (nos Passos 5 e 6) as consultas dos Passos 2
e 3, mas usando SUM em lugar de
COUNT.
Passo 5: obter o salrio total de indivduos no banco de
dados, usando as expresses T e NOT T.
WITH ( STATS WHERE AUDITS = O ) AS X
SUM ( X, SALRIO
Resultado: 438 K.
WITH ( STATS WHERE NOT ( AUDITS = O ) ) AS X
SUM ( X, SALRIO
Resultado: 290 K; 438 K + 290 K = 728 K.
Passo 6: obter a soma de salrios de Alf e o salrio total,
usando as expresses BE OR T e BE OR
NOT T.
WITH ( STATS WI-IERE ( SEXO = `M' AND
OCUPAO = `Programador
OR AUDITS = O ) AS X
SUM ( X, SALRIO
Resultado: 488 K.
WITH ( STATS WHERE ( SEXO = M AND
OCUPAO = Programador
OR NOT ( AUDITS = O ) ) AS X
SUM ( X, SALRIO
Resultado: 290 K; 488 K + 290 K = 778 K.
451
Passo 7: obter o salrio de Alf, subtraindo o salrio total
(encontrado no Passo 5) do resultado do Passo 6.
Resultado: 50 K. -
A Figura 16.4 ilustra o localizador geral.
set ( BE ) = ( set ( BE OR T ) plus set ( BE OR NOT T )
minus set ( T OR NOT T )
set ( BE ) = ( set ( BE OR T ) plus set ( BE OR NOT T )
minus set ( T OR NOT T )
FIGURA 16.4 O localizador geral T
Se a suposio inicial estivesse errada (isto , T no fosse
um localizador geral), ento uma ou ambas j as expresses (BE
OR Te (BE OR NOT 7) poderiam ser inadmissveis. Por exemplo,
se as cardinalidades
dos conjuntos de resultados para BE e T so p e q,
respectivamente, onde p <b e b _ q _ 2b, ento possvel que
a cardinalidade do conjunto de resultados para (BE OR 1) que
no pode exceder p + q, seja menor que 2b). Em tal situao,
necessrio fazer outra suposio de um localizador e tentar
novamente. A referncia [16.6] sugere que o processo de
encontrar um localizador geral no difcil na prtica. Em
nosso exemplo particular, a suposio inicial um
localizador geral (a cardinalidade de seu conjuntos de
resultados 5), e as consultas no Passo 3 so ambas
admissveis.
Em resumo: quase sempre existe um localizador geral e
normalmente fcil encontr-lo e fcil utiliz-lo; na
verdade, com frequncia possvel encontrar rapidamente um
localizador apenas por suposio [16.6]. Mesmo nos casos em
que no existe um localizador geral, a referncia [16.6]
mostra que localizadores especficos normalmente podem ser
encontrados para consultas especficas. E difcil escapar
concluso que a segurana em um banco de dados estatstico
um problema real.
Ento, o que pode ser feito? Surgiram diversas sugestes na
literatura mas no est claro que qualquer delas seja
totalmente satisfatria. Por exemplo, uma possibilidade a
troca de dados isto , a troca de valores de atributos
entre tuplas, de tal modo que a preciso estatstica global
seja mantida, para que at mesmo se um valor especfico
(digamos um salrio especfico) for identificado, no exista
nenhum meio de saber a qual indivduo particular esse valor
pertence. A dificuldade dessa abordagem reside em encontrar
conjuntos de entradas cujos valores possam ser trocados dessa
maneira. Limitaes semelhantes se aplicam maioria das
outras solues sugeridas. Por essa razo, no momento, parece
que devemos concordar com as concluses do Denning [16.6]: O
comprometimento direto e econmico. A exigncia de completo
segredo de informaes confidenciais no consistente com a
exigncia de produo de medidas estatsticas exatas para
subconjuntos arbitrrios da populao. Pelo menos uma dessas
exigncias deve ser relaxada antes de se poder confiar nas
garantias de segredo.
16.5 CRIPTOGRAFIA DE DADOS
At agora neste captulo, dissemos que qualquer candidato a
invasor estaria usando os recursos normais do sistema para
obter acesso ao banco de dados. Agora, voltamos nossa ateno
para o caso de um usurio que tenta contornar ilegalmente o
sistema (por exemplo, removendo fisicamente parte do banco de
dados ou penetrando em uma linha de comunicaes). A
contramedida mais eficaz diante de tais ameaas a
criptografia
452 de dados isto , o armazenamento e a transmisso de
dados confidenciais em forma criptografada.
conjunto
identificado por T
conjunto
identificado
conjunto
identificado por NOT
T
por BE isto ,
{I}
Para discutir alguns dos conceitos de criptografia de dados,
precisamos introduzir mais alguma terminologia. Os dados
originais (no criptografados) so chamados texto comum. O
texto comum criptografado quando submetido a um algoritmo
de criptografia, cujas entradas so o texto comum e uma chave
de criptografia; a sada desse algoritmo a forma
criptografada do texto comum chamada texto cifrado.* Os
detalhes do algoritmo de criptografia se tornam pblicos, ou
pelo menos no so ocultados de modo especial, mas a chave de
criptografia mantida secreta. O texto cifrado, que deve ser
ininteligvel para qualquer pessoa que no possua a chave de
criptografia, o que fica armazenado no banco de dados ou
transmitido pela linha de comunicaes.
Exemplo: considere que o texto comum seja o string:
AS KINGFISHERS CATCH FIRE
(para simplificar, vamos supor que os nicos caracteres de
dados com que temos de lidar so letras maisculas e espaos
vazios). Seja a chave de criptografia o string:
E LI 01
e seja o algoritmo de criptografia dado a seguir.
1. Divida o texto comum em blocos de comprimento igual ao da
chave de criptografia:
AS-KI NGFIS HERS+ CATCH +FIRE
(os espaos em branco agora so mostrados explicitamente como
+).
2. Substitua cada caractere do texto comum por um inteiro
entre 00 e 26, usando branco = 00, A =
01, ..., Z = 26:
0119001109 1407060919 0805181900 0301200308 0006091805
3. Repita o Passo 2 para a chave de criptografia:
0512091520
4. Para cada bloco de texto comum substitua cada caractere
pela soma de mdulo 27 de sua codificao inteira com a
codificao inteira do caractere correspondente da chave de
criptografia:
0119001109 1407060919 0805181900 0301200308 0006091805
0512091520 0512091520 0512091520 0512091520 0512091520
0604092602 1919152412 1317000720 0813021801 0518180625
5. Substitua cada codificao inteira no resultado do Passo 4
pelo caractere equivalente:
FOIEB SSOXL MQ-GT HMBRA ERRFY
O procedimento de descriptografia para esse exemplo direto,
dada a chave. (Exerccio: descriptografe o texto cifrado
mostrado anteriormente.) A questo : qual o grau de
dificuldade para um candidato a invasor determinar a chave
sem conhecimento anterior, dados textos comuns e textos
cifrados correspondentes? Em nosso exemplo simples, a
resposta bastante bvia, no muito; porm, igualmente
bvio que podem ser elaborados facilmente esquemas muito mais
sofisticados. No caso ideal, o esquema empregado deve ser tal
que o trabalho necessrio para romp-lo pese muito mais que
qualquer vantagem que possa ser obtida ao faz-lo. (Na
verdade, uma observao que siga as mesmas linhas gerais se
aplicar a todos os aspectos da segurana: a inteno deve
sempre ser a de tornar o custo de quebrar o sistema
significativamente maior que a recompensa potencial.) O
objetivo final aceito para esses esquemas que o inventor do
esquema, de posse do texto comum e do texto cifrado
correspondente, deva ser incapaz de determinar a chave e,
portanto, incapaz de decifrar outro fragmento de texto
cifrado.
*Texto que deve ser decifrado posteriormente posteriormente.
(N.R.T.) 453
j
O default de criptografia de dados
O exemplo anterior utilizou um procedimento de substituio:
uma chave de criptografia foi empregada com o objetivo de
determinar, para cada caractere do texto comum, um caractere
de texto cifrado que seria o substituto para esse caractere.
A substituio uma das duas abordagens bsicas para a
criptografia, tal como tradicionalmente praticada. A outra
a permutao, na qual os caracteres do texto comum so
simplesmente reorganizados em alguma sequncia diferente.
Nenhuma dessas abordagens particularmente segura em si, mas
algoritmos que combinam as duas podem fornecer um grau
bastante elevado de segurana. Um desses algoritmos o Data
Encryption Standard (DES), que foi desenvolvido pela IBM e
adotado como default federal nos EUA em 1977 [16.18].
Para usar o DES, o texto comum dividido em blocos de 64
bits e cada bloco criptografado com o uso de uma chave de
64 bits (na verdade, a chave consiste em 56 bits de dados e
mais oito bits de paridade; assim, no existem 264, mas
apenas 256 chaves possveis). Um bloco criptografado pela
aplicao de uma permutao inicial a ele, sujeitando-se
ento o bloco permutado a uma sequncia de 16 etapas
complexas de substituio, e finalmente aplicando-se outra
permutao, a inversa da permutao inicial, ao resultado da
ltima dessas etapas. A substituio no i-simo passo no
controlada diretamente pela chave de criptografia original K,
mas por uma chave Ki calculada a partir dos valores K e i.
Para ver detalhes, consulte a referncia [16.18].
O DES tem a propriedade de que o algoritmo de descriptografia
idntico ao algoritmo de criptografia, exceto pelo fato de
que os valores de Ki so aplicados em ordem inversa.
Criptografia de chave pblica
Com o passar dos anos, muitas pessoas sugeriram que o DES
poderia no ser verdadeiramente seguro. De fato, o advento de
processadores muito rpidos e altamente paralelos sugere que
o DES poderia ser rompido por fora bruta, se no o fosse por
meios mais inteligentes. Muitas pessoas tambm consideram que
os esquemas de criptografia de chave pblica mais recentes
tornam tecnologicamente obsoletos o DES e as abordagens
tradicionais semelhantes. Em um esquema de chave pblica,
tanto o algoritmo de criptografia quanto a chave de cri
ptogra fia esto totalmente disponveis; assim, qualquer
pessoa pode converter texto comum em texto cifrado. Porm, a
chave de descriptografia correspondente, mantida secreta
(os esquemas de chave pblica envolvem duas chaves, uma para
criptografia e outra para descriptografia). Alm disso, no
vivel deduzir a chave de descriptografia a partir da chave
de criptografia; ento, at mesmo a pessoa que executa a
criptografia original no pode executar a descriptografia
correspondente, se no estiver autorizada a faz-lo.
A idia original da criptografia de chave pblica se deve a
Diffie e Hellman [16.7]. Descrevemos a abordagem especfica
mais conhecida, criada por Rivest, Shamir e Adleman [16.15],
a fim de mostrar como um esquema desse tipo funciona
normalmente na prtica. Sua abordagem (agora conhecida como o
esquema RSA, formado pelas iniciais de seus criadores) se
baseia nos dois fatos seguintes:
1. Existe um algoritmo rpido conhecido para determinar se um
dado nmero primo.
2. No existe nenhum algoritmo rpido conhecido para
localizar os fatores primos de um dado nmero composto (isto
, no primo).
A referncia [16.10] oferece um exemplo no qual se determina
(em uma dada mquina) se um
certo nmero de 130 dgitos primo, e essa determinao
demora cerca de sete minutos, enquanto a
localizao de dois fatores primos (na mesma mquina) de um
nmero obtido pela multiplicao de
dois primos de 63 dgitos levaria aproximadamente 40
quatrilhes de anos (um quatrilho igual a
1.000.000.000.000.000). *
Ainda assim, h algumas dvidas sobre a segurana do esquema
RSA. A referncia [16.10] surgiu em 1977. Em 1990, Arjen
[.enstra e Marlc Manasse conseguiram fatorar com sucesso um
nmero de 155 dgitos [16.221; eles calcularam que o trabalho
de computao envolvido, que estava distribudo entre mais de
1000 computadores, era equivalente a executar um milho de
instrues por segundo em uma mquina durante 273 anos. O
nmero de 155 dgitos em questo foi o nono nmero de Fermat,
2512 + 1 (observe que 512 = 2). Consulte tambm a referncia
[16.12], que relata uma abordagem completamente diferente
454 e bem-sucedida! para romper a criptografia RSA.
O esquema RSA funciona assim:
1. Escolha aleatoriamente dois nmeros primos grandes
distintos p e q, e calcule o produto r = p * q.
2. Escolha aleatoriamente um inteiro grande e que seja primo
isto , que no tenha nenhum fator comum com o produto (p
- 1) * (q 1). O inteiro e a chave de criptografia. Nota:
escolher e simples; por exemplo, qualquer primo maior que p
e q servir.
3. Tome a chave de descriptografia d como sendo o nico
inverso multiplicativo de e mdulo (p 1)
* (q 1); isto :
d * e = 1 mdulo (p - 1) * (q - 1)
O algoritmo para se calcular d, sendo dados e, p e q,
direto, e foi apresentado na referncia
[16.15].
4. Torne pblicos os inteiros r e e, mas no d.
5. Para criptografar um fragmento de texto comum P (que
supomos para simplificar ser um inteiro menor que r),
substitua-o pelo texto cifrado C, calculado desta forma:
C = pe mdulo r
6. Para descriptografar um fragmento de texto cifrado C,
substitua-o pelo texto comum P, calculado como a seguir:
P c' mdulo r
A referncia [16.15] prova que esse esquema funciona - isto
, que a descriptografia de C usando d de fato recupera o P
original. Porm, o clculo de d conhecendo-se apenas r e e
(no p ou q) invivel, como afirmamos antes. Portanto,
qualquer um pode criptografar texto comum, mas somente
usurios autorizados (conhecendo d) podem descriptografar
texto cifrado.
Damos um exemplo trivial para ilustrar o procedimento
anterior. Por razes bvias, vamos nos limitar a nmeros
muito pequenos em todo o texto.
Exemplo: sejamp = 3, q = 5; ento r = 15 e o produto (p - 1)
* (q - 1) = 8. Seja e = 11 (um primo maior que p e q). Para
calcular d, temos:
d * 11 = 1 mdulo 8
e, ento, d = 3.
Agora, seja o texto comum P consistindo no inteiro 13. Ento,
o texto cifrado C dado por:
C = p mdulo r
= 1311 mdulo 15
= 1.792.160.394.037 mdulo 15
=7
Agora o texto comum P dado por:
p = mdulo r
= 73 mdulo 15
= 343 mdulo 15
= 13 -
Tendo em vista que e e d so inversos um do outro, os
esquemas de criptografia de chave pblica tambm permitem que
mensagens criptografadas sejam assinadas de tal modo que o
destinatrio possa ter certeza de que a mensagem teve origem
na pessoa que a mensagem declara como remetente (isto ,
assinaturas no podem ser forjadas). Suponha que A e B
sejam dois usurios que desejam se comunicar um com o outro
usando um esquema de criptografia de chave pblica. Ento, A
e B publicaro cada um um algoritmo de criptografia
(incluindo em cada caso a chave de criptografia
correspondente) mas, claro, conservaro em segredo o
algoritmo e a chave de descriptografia, mesmo um do outro.
Sejam os algo- ritmos de criptografia ECA e ECB (para
criptografar mensagens a serem enviadas para A e B,
respectiva- mente), e sejam os algoritmos de descriptografia
correspondentes DCA e DCB, respectivamente. ECA e DCA so
inversos um do outro, assim como ECB e DCB.
Agora, suponha que A deseja enviar um fragmento de texto
comum P a B. Em vez de simplesmente calcular ECB(P) e
transmitir o resultado, A primeiro aplica o algoritmo de
descri ptogra fia DCA a P, ento criptografa o resultado e o
transmite como texto cifrado C:
C = ECB ( DCA ( P ) )
Ao receber C, o usurio B aplica o algoritmo de
descriptografia DCB, e depois o algoritmo de criptogra fia
ECA, produzindo o resultado final P:
ECA ( DCB ( C ) )
= ECA ( DCB ( ECB ( DCA ( P ) ) ) )
= ECA ( DCA ( P ) ) /* porque DCB e ECB se cancelam */
= P / porque ECA e DCA se cancelam */
Agora, B sabe que a mensagem de fato veio de A, porque ECA
produzir P somente se o algoritmo DCA tiver sido usado no
processo de criptografia, e esse algoritmo s conhecido por
A. Ningum, nem mesmo B, pode forjar a assinatura de A.
16.6 RECURSOS DE SQL
O default SQL atual [8.1] admite apenas controle de acesso
discricionrio. Dois aspectos mais ou menos independentes
esto envolvidos o mecanismo de viso, que (como sugerimos
no Captulo 8) pode ser usado para ocultar dados
confidenciais de usurios no autorizados, e o prprio
subsistema de autorizao, que permite a usurios que tm
privilgios especficos concederem de forma seletiva e
dinmica esses privilgios a outros usurios e,
subsequentemente, revogarem esses privilgios, se desejarem.
Ambos os recursos sero discutidos a seguir.
Vises e segurana
Para ilustrar o uso de vises para fins de segurana em SQL,
primeiro damos anlogos em SQL dos exemplos de vises
(Exemplos de 2 a 4) da Seo 16.2.
2. CREATE VIEW LF AS
SELECT F.F#, F.FNOME, F.STATUS F.CIDADE
FROM F
WHERE F.CIDADE = Londres'
A viso define os dados sobre os quais a autorizao deve ser
concedida. A prpria concesso feita por meio da instruo
GRANT por exemplo:
GRANT SELECT, UPDATE ( FNOME, STATUS ), DELETE
ON LF
TO Dan, Misha
Observe que por serem definidas atravs de uma instruo
GRANT especial como mostrado, em vez de alguma instruo
hipottica CREATE AUTHORITY, as autoridades no tm nome em
456 SQL. (Ao contrrio, as restries de integridade tm
nomes, como vimos no Captulo 8.)
3. CREATE VIEW FFPPR AS
SELECT F.F#, F.FNOME, F.STATUS, F.CIDADE
FROM F
WHERE EXISTS
( SELECT * FROM FP
WHERE EXISTS
( SELECT * FROM P
WHERE F.F# = FP.F#
AND FP.P# = P.P#
AND P.CIDADE Roma'
GRANT correspondente:
GRANT SELECT ON FFPPR TO Giovanni
4. CREATE VIEW FFQ AS
SELECT F.F#, ( SELECT SUM ( FP.QDE )
FROM FP
WHERE FP.F# = F.F# ) AS FQ
FROM F ;
GRANT correspondente:
GRANT SELECT ON FFQ TO Fidel
O Exemplo 5 da Seo 16.2 envolvia uma autoridade dependente
de contexto. A SQL admite uma variedade de operadores
nildicos embutidos CURRENT_USER, CURRENT_DATE,
CURRENT_TIME, etc. que podem ser usados entre outras coisas
para definir vises dependentes de contexto (porm, observe
que a SQL no admite um anlogo do operador DAYO que usamos
em nosso Exemplo 5 original). Aqui est um exemplo:
CREATE VIEW F NINE TO FIVE AS
SELECT F.F#, F.FNOME, F.STATUS, F.CIDADE
FROM F
WHERE HORA_ATUAL > TIME `09:00:00'
AND HORA_ATUAL _ TIME `17:00:00'
GRANT correspondente:
GRANT SELECT, UPDATE ( STATUS
ON FNINETOFIVE
TO Compras
Entretanto, observe que F NINE_TO_FIVE um tipo muito
estranho de viso! seu valor muda com o tempo, mesmo que os
dados subjacentes nunca mudem. Alm disso, uma viso cuja
definio envolve o operador embutido CURRENT-USER pode at
mesmo ter (de fato, provavelmente ter) valores diferentes
para usurios distintos. Essas vises so na realidade
diferentes em espcie das vises normais na verdade, elas
so parametrizadas. Pode ser prefervel, pelo menos
conceitualmente, permitir que os usurios definam suas
prprias funes com valor de relao (potencialmente
parametrizadas), e depois tratem vises como F_NINE_TO_FIVE
apenas como casos especiais dessas funes.
De qualquer modo, os exemplos anteriores ilustram o fato de
que o mecanismo de vises fornece uma importante medida de
segurana de graa (de graa, porque o mecanismo est
includo no sistema para outros fins). Alm disso, muitas
verificaes de autorizao at mesmo as dependentes de
valor, podem ser feitas em tempo de compilao, em vez de
serem realizadas em tempo de execuo, uma vantagem
significativa para o desempenho. Porm, a abordagem baseada
em vises para a segu
rana ocasionalmente sofre de uma leve dificuldade em
particular, se algum usurio especfico necessitar de
privilgios diferentes sobre subconjuntos diferentes da mesma
tabela ao mesmo tempo. Por exemplo, considere a estrutura de
uma aplicao que tem permisso para varrer e imprimir todas
as peas de Londres, e tambm tem a permisso para atualizar
algumas delas (digamos, apenas as peas vermelhas) durante
essa varredura.
GRANT e REVOKE
O mecanismo de vises permite que o banco de dados seja
conceitualmente dividido em fragmentos de vrios maneiras, de
tal modo que informaes confidenciais possam ser ocultas de
usurios no autorizados. Entretanto, ele no permite a
especificao das operaes que usurios autorizados tm
permisso para executar sobre esses fragmentos. Essa funo
(como j vimos nos exemplos anteriores) executada pela
instruo GRANT, que discutiremos agora com mais detalhes.
Primeiro, observe que o criador de qualquer objeto recebe
automaticamente a concesso de todos os privilgios que fazem
sentido para esse objeto. Por exemplo, o criador de uma
tabela bsica T recebe automaticamente a concesso dos
privilgios SELECT, INSERT. UPDATE, DELETE e REFERENCES sobre
T (veja a seguir uma explicao desses privilgios). Alm
disso, esses privilgios so concedidos com autoridade para
concesso em cada caso, o que significa que o usurio que
detm o privilgio pode conced-lo a outros usurios.
Aqui temos ento a sintaxe para a instruo GRANT:
GRANT <lista com vrgulas de privilgios>
ON <objeto>
TO <lista_com_vrgulas de IDs de usurios>
E WITH GRANT OPTION 1 ;
Explicao:
- Os <privilgios> vlidos so USAGE, SELECT, INSERT, UPDATE,
DELETE e REFERENCES.* O privilgio USAGE necessrio para se
utilizar um domnio especificado (no estilo de SQL); o
privilgio REFERENCES necessrio para fazer referncia a
uma tabela nomeada especfica em uma restrio de
integridade; os outros privilgios devem ser auto-
explicativos. Contudo, observe que os privilgios INSERT,
UPDATE e REFERENCES (porm, estranhamente, no o privilgio
SELECT) podem ser especficos para colunas. Nota: tambm
possvel especificar ALL PRIVILEGES, mas a semntica no
direta [4.191.
- Os valores vlidos de <objetos> so DOMAIN <nome de
domnio> e TABLE <nome de tabela>. Nota: nesse contexto
diferente da maioria dos outros em SQL a palavra-chave
TABLE (de fato opcional) inclui tanto vises quanto tabelas
bsicas.
- A <lista_com_vrgulas de IDs de usurios> pode ser
substituda pela palavra-chave especial PUBLIC, significando
todos os usurios conhecidos pelo sistema.
- WITH GRANT OPTION, se especificada, significa que os
usurios especificados recebem a concesso dos privilgios
especificados sobre o objeto especificado com autoridade de
concesso significando, como indicamos antes, que eles
podem conceder esses privilgios sobre esse objeto para algum
(uns) outro(s) usurio(s). E claro que WTTH GRANT OPTION s
pode ser especificada se o usurio que emite a instruo
GRANT tem a necessria autoridade de concesso.
Em seguida, se o usurio A conceder algum privilgio a algum
outro usurio B, o usurio A poder subsequentemente revogar
tal privilgio do usurio B. A revogao de privilgios se
faz por meio da declarao REVOKE, com a sintaxe:
458 * Um privilgio EXECUTE foi acrescentado quando o recurso
PSM (Persistent Stored Modules) foi includo no default em
1996 [4.22].
REVOKE [ GRANT OPTION FOR ] <lista com vrgulas de
privilgios> ON <objeto>
FROM <lista com vrgulas de IDs de usurios>
<Opo>
Aqui, (a) GRANT OPTION FOR significa que (somente) a
autoridade para concesso revogada; (b) <lista_com_vrgulas
de privilgios>, <objeto> e <lista _com_vrgulas de IDs de
usurios> so como os de GRANT; e (c) <opo> RESTRICT ou
CASCADE, discutida a seguir. Exemplos:
1. REVOKE SELECT ON F FROM Jacques, Anne, Charley RESTRICT;
2. REVOKE SELECT, UPDATE ( FNOME, STATUS ), DELETE
ON LF FROM Dan, Misha CASCADE
3. REVOKE SELECT ON FFPPR FROM Giovanni RESTRICT
4. REVOKE SELECT ON FFQ FROM Fidel RESTRICT
RESTRICT versus CASCADE: vamos supor que p algum privilgio
sobre algum objeto e que o usurio A concede p ao usurio B
que, por sua vez, o concede ao usurio C. O que aconteceria
se A agora revogasse p de B? Suponha por um momento que
REVOKE tenha sucesso. Ento, o privilgio p mantido por C
seria abandonado seria derivado de um usurio, ou seja B,
que j no o possui. O objetivo da opo RESTRICT versus CAS
CADE evitar a possibilidade de privilgios abandonados.
Para sermos especficos, RESTRICT faz com que REVOKE falhe se
seu sucesso puder conduzir a privilgios abandonados; CASCADE
faz com que esses privilgios tambm sejam revogados.
Finalmente, a remoo de um domnio, uma tabela bsica, uma
coluna ou uma viso revoga automaticamente de todos os
usurios todos os privilgios sobre o objeto removido.
16.7 RESUMO
Discutimos os vrios aspectos do problema de segurana de
bancos de dados. Comeamos comparando segurana e
integridade: a segurana envolve a garantia de que os
usurios tm permisso para fazer aquilo que esto tentando
fazer; a integridade envolve a garantia de que o que eles
esto tentando fazer est correto. Em outras palavras, a
segurana envolve a proteo de dados contra revelao,
alterao ou destruio no autorizadas.
A segurana imposta pelo subsistema de segurana do SGBD,
que verifica todas as solicitaes de acesso, comparando-as
com as restries de segurana armazenadas no catlogo do
sistema. Primeiro, consideramos esquemas discricionrios, nos
quais o acesso a um dado objeto feito a critrio do
proprietrio do objeto. Toda autoridade em um esquema
discricionrio tem um nome, um conjunto de privilgios
(RETRIEVE, UPDATE, etc.), uma varivel de relao
correspondente (isto , os dados aos quais a restrio se
aplica) e um conjunto de usurios. Essas autoridades podem
ser usadas para fornecer controles dependentes de valor,
independentes de valor, de resumo estatstico e dependentes
de contexto. Uma trilha de auditoria pode ser usada para
registrar tentativas de romper a segurana. Examinamos
rapidamente uma tcnica de implementao de esquemas
discricionrios conhecida como modificao de solicitao.
Essa tcnica foi lanada primeiro pelo prottipo Ingres em
conexo com a linguagem QUEL.
Em seguida, discutimos os controles mandatrios, em que cada
objeto tem um nvel de classificao e cada usurio tem um
nvel de liberao. Explicamos as regras para acesso sob tal
esquema. Tambm resumimos o esquema de classificao de
segurana definido pelo Departamento de Defesa dos EUA nas
referncias [16.19 e 16.201 e discutimos rapidamente as
idias de variveis de relaes em vrios nveis e
poliinstanciao.
Depois, discutimos os problemas especiais de bancos de dados
estatsticos. Um banco de dados estatstico um banco de
dados que contm vrios itens de informaes individualmente
confidenciais, mas que deve fornecer apenas informaes de
resumos estatsticos a seus usurios. Vimos que a segurana
de tais bancos de dados facilmente comprometida por meio de
localizadores (um fato que deve servir como advertncia,
considerando-se o nvel crescente de interesse em sistemas de
armazns de dados
consulte o Captulo 21). 459
Examinamos em seguida a criptografia de dados, mencionando as
idias bsicas de substituio e permutao, explicando o que
o Data Encryption Standard e descrevendo em linhas gerais
como funcionam os esquemas de chave pblica. Em particular,
fornecemos um exemplo simples do esquema RSA (de nmeros
primos). Tambm discutimos o conceito de assinaturas
digitais.
Tambm descrevemos rapidamente os aspectos de segurana de
SQL em particular, o uso de vises para esconder
informaes e o uso de GRANT e REVOKE para controlar quais
usurios tm quais privilgios sobre quais objetos
(principalmente tabelas bsicas e vises).
Concluindo, talvez valha a pena enfatizar que no bom que o
SGBD fornea um grande conjunto de controles de segurana, se
for possvel contornar esses controles de algum modo. Por
exemplo, no DB2, o banco de dados est fisicamente armazenado
sob a forma de arquivos do sistema operacional; assim, o
mecanismo de segurana do DB2 seria quase intil se fosse
possvel obter acesso a esses arquivos a partir de um
programa convencional por meio de servios convencionais do
sistema operacional. Por essa razo, o DB2 trabalha em
harmonia com seus vrios sistemas complementares em
particular, o sistema operacional subjacente para garantir
que o sistema total seguro. Os detalhes esto alm do
escopo deste captulo, mas a mensagem deve ser clara.
EXERCICIOS
16.1 Seja a varivel de relao bsica STATS vista na Seo
16.4:
STATS { NOME, SEXO, FILHOS. OCUPAO, SALRIO, IMPOSTO,
AUDITS
PRIMARY KEY { NOME
Usando a linguagem hipottica introduzida na Seo 16.2
defina as restries de segurana necessrias para dar:
a. Ao usurio Ford privilgios RETRIEVE sobre toda a varivel
de relao.
b. Ao uurio Smith privilgios INSERT e DELETE sobre toda a
varivel de relao.
c. A cada usurio privilgios RETRIEVE sobre a tupla do
prprio usurio (somente).
b. Ao usurio Nash privilgios RETRIEVE sobre toda a varivel
de relao e privilgios UPDATE sobre os atributos SALARIO e
IMPOSTO (apenas).
e. Ao usurio Todd privilgios RETRIEVE sobre os atributos
NOME, SALRIO e IMPOSTO (apenas).
f. Ao usurio Ward privilgios RETRIEVE como os de Todd e
privilgios UPDATE sobre os atributos SALARIO e IMPOSTO
(apenas).
g. Ao usurio Papa privilgios completos (RETRIEVE, UPDATE,
INSERT, DELETE) sobre tuplas para religiosos (somente).
h. Ao usurio Jones privilgios DELETE sobre tuplas para
pessoas que executem trabalho no especializado, onde
trabalho no especializado definido como sendo aquele que
executado por mais de dez pessoas.
i. Ao usurio King privilgios RETRIEVE para salrios mximo
e mnimo por ocupao.
16.2 Considere as aes includas na extenso da sintaxe de
instrues AUTHORITY para incluir controle sobre operaes
tais como definir e descartar variveis de relaes bsicas,
definir e descartar vises, definir e descartar autoridades,
e assim por diante.
16.3 Considere a Figura 16.2 uma vez mais. Vamos supor que
sabemos de fontes externas que Hal uma dona de casa com
pelo menos dois filhos. Escreva uma sequncia de consultas
estatsticas que revelaro os valores dos impostos de Hal,
usando um localizador individual. Suponha, como na Seo
16.4, que o sistema no responder a consultas com uma
cardinalidade de conjunto de resultados menor que 2 ou maior
que 8.
16.4 Repita o Exerccio 16.3, mas use um localizador geral em
vez de um localizador individual.
16.5 Descriptografe o texto cifrado a seguir, produzido de
maneira semelhante ao que foi usado no exemplo de AS
KINGFISHERS CATCH FIRE na Seo 16.5, mas utilize uma chave
de criptografia de cinco caracteres diferentes:
FNWAL
J PvJ C
FPEXE
ABWN E
AYEIP
460 SUSVD
16.6 Execute o esquema RSA de criptografia de chave pblica
comp = 7, q = Se = 17 para o texto comumP = 3.
16.7 Voc poderia imaginar algum problema de implementao ou
outras desvantagens que pudessem ser causa- das pela
criptografia?
16.8 D solues de SQL para o Exerccio 16.1.
16.9 Escreva instrues de SQL para descartar os privilgios
concedidos na sua soluo ao exerccio anterior.
REFERNCIAS E BIBLIOGRAFIA
Para uma ampla viso geral sobre segurana, consulte o livro
de Castano eta!. [16.21. Para ver um tratamento tcnico mais
detalhado, consulte o livro de Denning [16.51. As demais
referncias so, em sua maioria, documentos sobre padres ou
artigos tcnicos (tutoriais ou contribuies de pesquisa)
sobre vrios aspectos especficos do problema de segurana;
h tambm alguns artigos de peridicos.
16.1 D. E. Beil e L. J. La Padula: Secure Computer Systems:
Mathematical Foundations and Model, MITRE Technical Report
M74-244 (maio de 1974).
16.2 Silvana Castano, Mariagrazia Fugini, Giancarlo Martelia
e Pierangela Samarati: Database Security. Nova York, N.Y.:
ACM Press!Reading, Mass.: Addison-Wesley (1995).
16.3 James Daly: Fingrrinting a Computer Security Code,
Computerwor!d (27 de julho de 1992).
16.4 C. J. Date: Security, Captulo 4 de An Introduction to
Database Systems: Volume II. Reading, Mass.:
Addison-Wesley (1983).
16.5 Doroty E. Denning: Ciyptography and Data Security.
Reading, Mass.: Addison-Wesley (1983).
16.6 Doroty E. Denning e Peter J. Denning: Data Security
ACM Comp. Surv: 11, Nmero 3 (setembro de
1979).
Um bom tutorial focalizando controles de acesso
discricionrio, controles de acesso mandatrio (aqui chamados
controles de fluxo), criptografia de dados e controles de
inferncia (o problema especial de bancos de dados
estatsticos).
16.7 W. Diffie e M. E. Hellman: New Directions in
Cryptography, IEEE Transactions on Information Theory
IT-22 (novembro de 1976). -
16.8 Ronald Fagin: On An Authorization Mechanism, ACM TODS
3. Nmero 3 (setembro de 1978).
Uma extensa correo referncia [16.111. Sob certas
circunstncias, o mecanismo da referncia [16.111 revogaria
um privilgio que no deveria ser revogado. Esse artigo
corrige tal falha.
16.9 Roberto Gagliardi, George Lapis e Bruce Lindsay: A
Flexible and Efficient Database Authorization Facility, IBM
Research Report RJ6826 (11 de maio de 1989).
16.10 Martin Gardner: A New Kind of Cipher That Would Take
Millions of Years to Break, ScientificAmerican
237, Nmero 2 (agosto de 1977).
Uma boa introduo informal ao trabalho sobre criptografia de
chave pblica. O ttulo talvez seja um exagero.
16.11 Patricia P. Griffiths e Bradford W. Wade: An
Authorization Mechanism for a Relational Data Base System,
ACM TODS 1, Nmero 3 (setembro de 1976).
Descreve o mecanismo de GRANT e REVOKE proposto originalmente
para o System R. O esquema agora includo no default SQL
baseado naquele mecanismo, embora diferindo de forma
significativa nos detalhes.
16.12 Nigel Hawkes: Breaking into the Internet, London
Times (18 de maro de 1996).
Descreve como um especialista em informtica rompeu o esquema
RSA medindo o tempo que o sistema demorava para
descriptografar mensagens o equivalente eletrnico de
adivinhar a combinao de uma tranca olhando algum girar os
botes e ver quanto tempo demora cada giro.
16.13 Sushil Jajodia e Ravi Sandhu: Toward a Multilevel
Secure Relational Data Model, Proc. 1991 ACM
SIGMOD Int. Conf. on Management of Data, Denver, Cobrado
(junho de 1991). 461
Como explicamos na Seo 16.3, a expresso em vrios nveis
em um contexto de segurana se refere a um sistema que admite
controles de acesso mandatrio. Esse artigo sugere que grande
parte da atividade atual na rea ad hoc pois existe
pouqussimo consenso sobre conceitos bsicos e prope um
incio de formalizao dos princpios de sistemas de vrios
nveis.
16.14 Abraham Lempel: Cryptology in Transition, ACM Comp.
Surv: 11, Nmero 4: Special Issue on Cryptology (dezembro de
1979).
Um bom tutorial sobre criptografia e assuntos relacionados.
16.15 R. L. Rivest, A. Shamir e L. Adleman: A Method for
Obtaining Digital Signatures and Public Key Cryptosystems,
CACM 21, Nmero 2 (fevereiro de 1978).
16.16 Ken Smith e Marianne Winslett: Entity Modeling in the
MLS Relational Model, Proc. l8th Int. Conf. on Very Large
Data Bases, Vancouver, Canad (agosto de 1992).
A sigla MLS no ttulo desse artigo significa seguro em
vrios nveis (multi-level secure) [16.131. Esse artigo se
concentra no significado de bancos de dados MLS e prope uma
nova clusula BELIEVED BY em operaes de recuperao e
atualizao para orientar essas operaes at o estado
particular do banco de dados entendido ou acreditado por um
usurio especfico. Essa abordagem afirma ser capaz de
resolver muitos problemas existentes em abordagens
anteriores. Consulte tambm a referncia [16.2 1].
16.17 Bhavani Thuraisingham: Current Status of R&D in
Trusted Database Management Systems, ACM SIGMOD Record 21,
Nmero 3 (setembro de 1992).
Uma breve pesquisa e um extenso conjunto de referncias sobre
sistemas confiveis ou de vrios nveis (como eram no
incio dos anos noventa).
16.18 U. S. Department of Commerce/National Bureau of
Standards: Data Encryption Standard. Federal Information
Processing Standards Publication 46 (15 de janeiro de 1977).
Define o Data Encryption Standard (DES) oficial, a ser usado
por rgos federais e qualquer outra pessoa que desejar us-
lo. O algoritmo de criptografia/descriptografia (consulte a
Seo 16.5) apropriado para implementao em um chip de
hardware, o que significa que dispositivos que o incorporam
podem operar a uma taxa de dados elevada. Vrios dispositivos
desse tipo esto disponveis comercialmente.
16.19 U. 5. Department of Defense: Trusted ComputerSystem
Evaluation Criteria (o Orange Book), Documento Nmero DoD
5200-28-ETD. DoD National Computer Securit Center (dezembro
de 1985).
16.20 U. S. National Computer Security Center: Trusted
Database Management System Interpretation ofTrusted Computer
System Evaluation Criteria (o Lavender Book). Documento
Nmero NCSC-TG-201, Verso 1 (abril de 1991).
16.2 1 Marianne Winslett, Kenneth Smith e Xiaolei Qian:
Formal Query Languages for Secure Relational Databases, ACM
TODS 19, Nmero 4 (dezembro de 1994).
Continua o trabalho da referncia [16.161.
16.22 Ron Wolf: How Safe Is Computer Data? A Lot of Factors
Govern the Answer, San Jose Mercury News (15 de julho de
1990).
RESPOSTAS A EXERCICIOS SELECIONADOS
16.1 a. AUTHORJTY AAA
GRANT RETRIEVE ON STATS TO Ford ;
b. AUTHORITY BBB
GRANT INSERT, DELETE ON STATS TO Smith ;
c. AIJTI-IORITY CCC
GRANT RETRIEVE
ON STATS
WHEN USER O = NOME
TO ALL
Estamos supondo que cada usurio tem seu prprio nome e sua
ID de usurio. Observe o uso de uma clusula WHEN e do
operador nildico embutido USERO.
462
d. AUTHORITY DOO
GRANT RETRIEVE, UPOATE ( SALRIO, IMPOSTO
ON STATS
TO Nash
e. AUTHORITY EEE
GRANT RETRIEVE ( NOME, SALRIO, IMPOSTO
ON STATS
TO Todd
f. AUTHORITY FFF
GRANT RETRIEVE ( NOME, SALRIO, IMPOSTO ),
UPOATE ( SALRIO, IMPOSTO
ON STATS
TO Ward
g. VAR PREACHERS VIEW
STATS WHERE OCUPAO = Preacher
AUTHORITY GGG
GRANT ALL
ON PREACHERS
TO Pape
Observe que necessrio utilizar uma viso nesse exemplo.
h. VAR NONSPECIALIST VIEW
WITH ( STATS RENAME OCUPAO AS X ) AS Ti,
( EXTEND STATS
AOO COUNT ( Ti WHERE X = OCUPAO ) AS Y ) AS T2,
( T2 WHERE Y > iO ) AS T3
T3 { ALL BUT Y }
AUTHORITY HHH
GRANT OELETE
ON NONSPECIALIST
TO Jones
i. VAR JOBMAXMIN VIEW
WITH ( STATS RENAME OCUPAO AS X ) AS Ti,
( EXTENO STATS
AOD MAX ( Ti WHERE X = OCUPAO, SALRIO ) AS MAXSAL,
MIN ( Ti WHERE X = OCUPAO, SALRIO ) AS MINSAL
AS T2
T2 { OCUPAO, MAXSAL, MINSAL )
AUTHORITY III
GRANT RETRIEVE ON JOBMAXMIN TO King
16.2 Fazemos apenas uma observao aqui: um usurio que tenha
autoridade para criar uma nova varivel de relao bsica e
de fato crie uma tal relao pode ser considerado como o
proprietrio dessa nova varivel de relao. O proprietrio
de uma dada varivel de relao bsica automaticamente deve
ter a concesso de todos os privilgios possveis sobre essa
varivel de relao, incluindo no apenas privilgios
RETRIEVE, INSERT, UPDATE e DELETE (naturalmente), mas tambm
o privilgio de definir autoridades que concedem privilgios
sobre essa varivel de relao a outros usurios.
16.3 Um localizador individual para Hal :
FILHOS > i AND NOT ( OCUPAO = Dona de casa
Considere esta sequncia de consultas:
COUNT ( STATS WHERE FILHOS > 1
Resultado: 6. 463
COUNT ( STATS WHERE FILHOS > 1 AND NOT
OCUPAO = `Dona de casa
Resultado: 5.
Conclumos que a expresso:
FILHOS > 1 AND OCUPAO = `Dona de casa
identifica Hal de modo exclusivo.
SUM ( STATS WHERE FILHOS > 1, IMPOSTO
Resultado: 48 K.
SUM ( STATS WHERE FILHOS > 1 AND NOT
OCUPAO = Dona de casa' ), IMPOSTO
Resultado: 46 K.
Da, o valor dos impostos de Hal 2 K. -
16.4 Localizador geral: SEXO = `F'.
SUM ( STATS WHERE SEXO = `F', IMPOSTO
Resultado: 70 K.
SUM ( STATS WHERE NOT ( SEXO = `F' ), IMPOSTO
Resultado: 16 K.
Portanto, o imposto total 86 K.
SUM ( STATS WHERE ( FILHOS > 1 AND
OCUPAO = `Dona de casa' ) OR
SEXO = F', IMPOSTO
Resultado: 72 K.
SUM ( STATS WHERE ( FILHOS > 1 AND
OCUPAO = `Dona de casa ) OR NOT
SEXO = `F' ), IMPOSTO
Resultado: 16 K.
Somando esses resultados e subtraindo o total calculado
anteriormente, temos o valor dos impostos de Hal
=88K-86K=2K. -
16.5 O texto comum :
EVES 1 DARE NOT MEET IN DREAMS
Qual a chave de criptografia?
16.7 Um problema que, mesmo em um sistema que admita a
criptografia, os dados ainda tm de ser processados
internamente em sua forma de texto coum (por exemplo, para
que as comparaes operem corretamente), Cportanto ainda
existe o risco de dados confidenciais se tornarem acessveis
para aplicaes em execuo concorrente ou aparecerem em um
despejo de memria. Alm disso, h graves problemas tcnicos
para a indexao de dados criptografados e para manter
registros no log correspondentes a esses dados.
16.8 a. GRANT SELECT ON STATS TO Ford
b. GRANT INSERT. DELETE ON STATS TO Smith
c. CREATE VIEW MINE AS
SELECT STATS.*
FROM STATS
WHERE STATS.NOME = CURRENTUSER
GRANT SELECT ON MINE TO PUBLIC
464
Estamos supondo que cada usurio tem seu prprio nome e sua
ID de usurio. Observe o uso de uma clusula WHEN e do
operador nildico embutido CURRENT_USER.
d. GRANT SELECT, UPDATE ( SALRIO, IMPOSTO ) ON STATS TO Nash
e. CREATE VIEW UST AS
SELECT STATS.NOME, STATS.SALRIO, STATS. IMPOSTO
FROM STATS
GRANT SELECT ON UST TO Todd
A SQL tem de usar uma viso nesse caso, porque ela no admite
privilgios SELECT especficos de colunas.
f. GRANT SELECT, UPDATE ( SALRIO, IMPOSTO ) ON UST TO Ward
Essa soluo utiliza a mesma viso que a anterior.
g. CREATE VIEW PREACHERS AS
SELECT STATS.*
FROM STATS
WHERE STATS.OCUPAO = Preacher'
GRANT ALL PRIVILEGES ON PREACHERS TO Pope
Observe o uso da abreviao ALL PRIVILEGES nesse exemplo.
(Porm, ALL PRIVILEGES no significa literalmente todos os
privilgios significa todos os privilgios sobre o objeto
relevante para os quais o usurio que emite GRANT tem
autoridade de concesso.)
h. CREATE VIEW NONSPECIALIST AS
SELECT STX.*
FROM STATS AS STX
WHERE ( SELECT COUNT(*)
FROM STATS AS STY
WHERE STY.OCUPAO = STX.OCUPAO ) > 10 ;
GRANT DELETE ON SPECIALISTS TO Jones
i. CREATE VIEW JOBMAXMIN AS
SELECT STATS.OCUPAO,
MAX ( STATS.SALRIO ) AS MAXSAL,
MIN ( STATS.SALRIO ) AS MINSAL
FROM STATS
GROUP BY STATS.OCUPAO ;
GRANT SELECT ON JOBMAXMIN TO King ;
16.9 a. REVOKE SELECT ON STATS FROM Ford RESTRICT
b. REVOKE INSERT, DELETE ON STATS FROM Smith RESTRICT
c. REVOKE SELECT ON MINE FROM PUBLIC RESTRICT
d. REVOKE SELECT, UPDATE ( SALRIO, IMPOSTO
ON STATS FROM Nash RESTRICT ;
e. REVOKE SELECT ON UST FROM Todd RESTRICT
f. REVOKE SELECT, UPDATE ( SALRIO, IMPOSTO
ON UST FROM Ward RESTRICT
g. REVOKE ALL PRIVILEGES ON PREACHERS FROM Pope RESTRICT ;
h. REVOKE DELETE ON SPECIALISTS FROM Jones RESTRICT
i. REVOKE SELECT ON SALS FROM King RESTRICT ;
465