sistema de banco de dados - pearson.pdf

576 Sistemas de banco de dados

uma categoria de ataque geral em que o acesso a aplicaes ou dados da rede nega-do aos usurios legtimos devido ao esrouro do buffer ou esgotamento de recursos.

Autenticao fraca. Se o esq uema de auten-ticao do usurio for fraco, um atacante pode person ificar a identidade de um usu-rio legtimo ao obter suas credenciais de login.

24.4.1 Mtodos de lnjeo de SQL Conforme discutimos no Captulo 14, progra-

mas e aplicaes Web que acessam um banco de da-dos podem enviar comandos e dados ao banco de dados, bem como exibir dados recuperados do banco de dados por meio do navegador Web. Em um ata-que de lnjeo de SQL, o atacante injeta uma entrada de cadeia de caracteres pela aplicao, que muda ou manipula a instruo SQL para o proveito do atacan-te. Um ataque de Injeo de SQL pode prejudicar o banco de dados de vrias maneiras, como na mani-pulao no autorizada do banco de dados, ou recu-perao de dados confidenciais. Ele tambm pode ser usado para executar comandos em nvel do sistema que podem fazer o sistema negar servio aplicao. Esta seo descreve tipos de ataques de injeo.

Manipulao de SQL. Um ataque de manipulao, que o tipo mais comum de ataque de injeo, muda um comando SQL na aplicao - por exemplo, ao acrescentar condies clusula WHERE de uma con-sulta, ou ao expandir mna consulta com componen-tes de consulta adicionais, usando operaes de unio como UNION, INTERSECT ou MINUS. Outros tipos de ataques de manipulao tambm so possveis. Um ara-que de manipulao tpico ocorre durante o login do banco de dados. Por exemplo, suponha que um pro-cedimento de autenticao simplista emita a seguinte consulta c verifique se alguma linha foi retornada:

SELECT * FROM usuario WHERE nomeusuario = 'jaque' and SENHA= 'senhajaque'.

O atacante pode tentar alterar (ou manipular) a instruo SQL, alterando-a da seguinte forma:

SELECT * FROM users WHERE nomeusuario = 'jaque' and (SENHA = 'senhajaque' or 'x' = 'x')

Como resultado, o atacante que sabe que ' jaque' um login vlido de algum usurio pode se togar no sistema de banco de dados como 'jaque' sem conhe-cer sua senha e ser capaz de fazer tudo o que ' jaque' pode estar autorizado a fazer nesse sistema de banco de dados.

lnjeo de cdigo. Esse tipo de ataque tenta acres-centar instrues SQL ou comandos adicionais ins-truo SQL existente, explorando um bug do com-putador, que causado pelo processamento de dados invlidos. O atacante pode injetar ou introduzir c-digo em um programa de computador para alterar o curso da execuo. A injeo de cdigo uma tcni-ca popular para a invaso ou penetrao do sistema para obter informaes.

lnjeo de chamada de funo. Nesse tipo de ata-que, uma funo do banco de dados ou uma chama-da de funo do sistema operacional inserida em uma instruo SQL vulnervel para manipular os dados ou fazer urna chamada do sistema privilegia-da. Por exemplo, possvel explorar uma funo que realiza algum aspecto relacionado comunicao na rede. Alm disso, as funes que esto contidas em um pacote de banco de dados persona lizado, ou qualquer funo de banco de dados personalizada, podem ser executadas como parte de uma consulta SQL Em particular, consultas SQL criadas dinamica-mente (ver Captulo 13) podem ser exploradas, visto que so construdas em tempo de execuo.

Por exemplo, a tabela dual usada na clusula FROM da SQL no Oracle quando um usurio precisa executar uma SQL que no tenha logicamente um nome de tabela. Para obter a data de hoje, podemos usar:

SELECT SYSDATE FROM dual;

O exemplo a seguir demonstra que at mesmo as instrues SQL mais simples podem ser vulnerveis.

SELECT TRANSLATE ('user input', 'from_string', ' to_string') FROM dual;

Aqui, TRANSLATE usado para substituir uma cadeia de caracteres por outra cadeia de caracteres. A funo TRANSLATE citada substituir os caracteres de 'from_string' pelos caracteres de 'to_string' um por um. Isso significa que o f ser substitudo pelo t, o r, pelo o, o o, pelo _, e assim por diante.

Esse tipo de instruo SQL pode estar sujeito a um ataque de injeo de funo. Considere o exem-plo a seguir:

SELECT TRANSLATE (" 11 UTL_H I I P.REQUEST ('http://129.1 07.2.1f) 11 ",'98765432', '9876') FROM dual;

O usurio pode inserir a string(' 11 UTL_H 1'1 P.RE-QUEST ('hrtp://129.107.2.1/') 11 '),onde 11 o operador de concatenao, solicitando assim uma pgina de um servidor Web. A UTL_HTIP faz chamadas do Hyper-text Transfer Protocol (HTIP) com base na SQL. O ob-

jeto REQUEST recupera um URL ('http:/1129.107.2.11' neste exemplo) como um parmetro, entra em contato com esse site e retorna os dados (normalmente HTML) obtidos desse site. O atacante poderia manipular a string que ele insere, bem como o URL, para incluir ou-tras funes e realizar outras operaes ilegais. Apenas usamos um exemplo fictcio para mostrar a converso de '98765432' para '9876', mas a inteno do usurio seria acessar o URL e obter informaes confidenciais. O atacante pode ento recuperar informaes teis do servidor de banco de dados - localizado no URL que passado como parmetro - e envi-las ao servidor Web (que chama a funo TRANSLATE).

24.4.2 Riscos associados lnjeo de SQL A In jeo de SQL prejudicial e os riscos asso-

.ciados a ela oferecem motivao para os atacantes. Alguns dos riscos associados a a taques de Injeo de SQL so explicados a seguir.

Impresso digital do banco de dados. O ata-cante pode determinar o ripo de banco de dados que est sendo usado no back-end de modo que possa utilizar ataques especficos ao banco de dados que correspondem a pontos fracos em um SGBD em particular.

Negao de servio. O atacante pode inundar o servidor com solicitaes, negando assim o servio a usurios legtimos, ou ento eles po-dem excluir a lguns dados.

Contornar a autenticao. Esse um dos ris-cos mais comuns, em que o atacante pode obter acesso ao banco de dados como um usurio autorizado e realizar rodas as tarefas desejadas.

Identificar parmetros injetveis. Nesse tipo de ataque, o atacante rene informaes im-portantes sobre o tipo e a estrutura do banco de dados de back-end de uma aplicao Web. Esse ataque se torna possvel pelo fato de a pgina de erro padro retornada pelos servi-dores de aplicao normalmente ser bastante descritiva.

Executar comandos remotos. Isso oferece aos atacantes uma ferramenta para executar co-mandos quaisquer no banco de dados. Por exemplo, um usurio remoto pode executar procedimentos armazenados e funes do banco de dados com base em uma interface interativa SQL remota.

Realizar escalada de privilgios. Esse tipo de ataque tira proveito das falhas lgicas dentro do banco de dados para aumentar o nvel de acesso.

Capitulo 24 Segurana de banco de dados 577

24.4.3 Tcnicas de proteo contra lnjeo de SQL

A proreo contra ataques de Injeo de SQL pode ser obtida ao aplicarem-se cerras regras de pro-gramao a rodos os procedimentos e funes aces-sveis pela Web. Esta seo descreve algumas dessas tcnicas.

Variveis de ligao (usando comandos parame-trizados). O uso de variveis de ligao (tambm conhecidas como parmetros; ver Captulo 13) pro rege contra ataques de injeo e tambm melhora o desempenho.

Considere o seguinte exemplo usando Java e JDBC:

Pre paredStatement stmt = conn. prepa reStatement( "SELECT * FROM FUN-CIONARIO WHERE FUNCIONARIO_ID=? AND SENHA=?");

stmt.setString(1, funcionario_id);

stmt.setString(2, senha);

Em vez de embutir a entrada do usurio na ins-truo, ela dever ser vinculada a um parmetro. Neste exemplo, a entrada '1' atribuda (vinculada) varivel de ligao 'funcionario_id' e a entrada '2' varivel de ligao 'senha', em vez de passar parme-tros de cadeia de caracteres direramenre.

Filtragem da e ntrada (validao da entrada). Esta tcnica pode ser usada para remover caracteres de escape das cadeia de caracteres de entrada ao uti-lizar a funo Replace da SQL. Por exemplo, o deli-mitador de aspa simples (') pode ser substitudo por duas aspas simples ("). Alguns ataques de manipula-o de SQL podem ser impedidos com essa tcnica, pois os caracteres de escape podem ser usados para in jetar a taques de man ipulao. Porm, como pode haver um grande nmero de caracteres de escape, essa tcnica no confiveL

Segurana da funo. As funes de banco de dados, tanto padro q uanto personalizadas, devem ser restringidas, pois podem ser exploradas nos ata-ques de injeo de funo SQL.

24.5 Introduo segurana do banco de dados estatstico

Bancos de dados estatsticos so usados princi-palmente para produzir estatsticas sobre vrias po-pulaes. O banco de dados pode conter dados con-fidenciais sobre indivduos, que devem ser protegidos contra acesso do usurio. Contudo, os usurios tm


permisso para recuperar informaes estatsticas sobre populaes, como mdias, somas, contadores, valores mximo e mnimo e desvios padres. As tc-nicas que foram desenvolvidas para proteger a pri-vacidade de informaes individuais esto alm do escopo deste livro. Vamos ilustrar o problema com um exemplo muito simples, que se refere relao mostrada na Figura 24.3. Essa uma relao PES-SOA com os atributos Nome, Cpf, Renda, Endereco, Cidade, Estado, Cep, Sexo e Escolaridade.

Uma populao um conjunto de rupias de uma relao (tabela) que satisfazem alguma condio de seleo. Logo, cada condio de seleo na relao PESSOA especificar uma populao em particular de tu pias de PESSOA. Por exemplo, a condio Sexo = 'M' especifica a populao do sexo masculino; a condio ((((Sexo= 'F' ANO (Escolaridade= 'M.S.' OR Escolaridade = 'Ph.D.')) especifica a populao do sexo feminino que tem um ttulo M.S. ou Ph.D. como seu ttulo mais alto; e a condio Cidade= 'So Paulo' especifica a populao que mora em So Paulo.

As consultas estatsticas envolvem a aplicao de funes estatsticas a uma populao de rupias. Por exemplo, podemos querer recuperar o nmero de indivduos em uma populao ou a renda mdia na populao. No entanto, usurios estatsticos no tm permisso para recuperar dados individuais, como a renda de uma pessoa especfica. Tcnicas de segurana de banco de dados estatstico precisam proibir a recuperao de dados individuais. Isso pode ser obtido proibindo-se consultas que recupe-ram valores de atributo e permitindo apenas consul-tas que envolvem funes de agregao estatstica, como COUNT, SUM, MIN, MAX, AVERAGE e STAN-DARD DEVIATION . Estas s vezes so chamadas de consultas estatsticas.

responsabilidade de um sistema de gerencia-mentO de banco de dados garantir a confidencia lida-de da informao sobre indivduos, enquanto ainda oferece resumos estatsticos teis de dados sobre es-ses indivduos aos usurios. A proviso da proteo da privacidade dos usurios em um banco de dados estatstico fundamental; sua violao ilustrada no exemplo a seguir.

Em alguns casos, possvel deduzir os valores de rupias individuais com base em uma sequncia de consultas estatsticas. Isso particularmente verda-

PESSOA

deiro quando as condies resultam em uma popula-o que consiste em um pequeno nmero de rupias. Como uma ilustrao, considere as seguintes consul-

' . tas estatlstlcas:

C1 : SELECT COUNT () FROM PESSOA WHERE ;

C2: SELECT AVG (Renda) FROM PESSOA WHERE ;

Agora suponha que estejamos interessados em descobrir o Salario de Jane Si lva, e sabemos que ela tem um ttulo de Ph.D. e que mora na cidade de San-to Andr, So Paulo. Emitimos a consulta estatstica C1 com a seguinte condio:

(Escolaridade='Ph.D.' ANO Sexo='F' ANO Cidade='Santo Andre' ANO Estado='Sao Paulo')

Se obtivermos um resultado de 1 para essa con-sulta, podemos emitir C2 com a mesma condio e descobrir o Salario de Jane Silva. Mesmo que o re-sultado de C1 na condio anterior no seja 1, mas seja um nmero pequeno - digamos, 2 ou 3 -, podemos emitir consultas estatsticas usando as fun-es MAX, MIN e AVERAGE para identificar o poss-vel intervalo de valores para o Salario de Jane Silva.

A possibilidade de deduzir informaes indi-viduais de consultas estatsticas reduzida se ne-nhuma consulta estatstica for permitida sempre que o nmero de rupias na populao especifica-da pela condio de seleo for abaixo de algum limite. Outra tcnica para proibir a recuperao de informaes individuais proibir sequncias de consultas que se referem repetidamente mesma populao de tuplas. Tambm possvel introduzir pequenas imprecises ou rudo nos resultados das consultas estatsticas de maneira deliberada, para tornar difcil deduzir informaes individuais dos resultados. O utra tcnica o particionamento do banco de dados. O particionamento implica que os registros sejam armazenados em grupos de algum tamanho mnimo; as consu ltas podem se referir a qualquer grupo completo ou conj unto de grupos, mas nunca a subconjuntos de registras dentro de um grupo. O leitor interessado deve consultar a bibliografia ao final deste captulo para uma dis-cusso a respeito dessas tcnicas.

Nome Renda Endereco Cidade Estado Cep Sexo Escolaridade

Figura 24.3 O esquema de relao PESSOA para ilustrar a segurana do banco de dados estatstico.

24.6 Introduo ao controle de fluxo O controle de fluxo regula a distribuio ou flu-

xo de informaes entre objetos acessveis. Um fluxo entre o objeto X e o objeto Y ocorre quando um programa l valores de X e grava valores em Y. Os controles de fluxo verificam que a informao con-tida em alguns objetos no flui explicta ou implici-tamente para objetos menos protegidos. Assim, um usurio no pode obter indiretamente em Y o que ele ou ela no pode obter de maneira direta em X. O controle de fluxo ativo comeou no incio da dcada de 1970. A maioria dos controles de fluxo emprega algum conceito de classe de segurana; a transfern-cia de informaes de um emissor para um recep-tor s permitida se a classe de segurana do receptor for pelo menos to privilegiada quanto a do emissor. Alguns exemplos de um controle de fluxo incluem impedir que um programa de servio vaze dados con-fidenciais de um cliente e bloquear a transmisso de dados militares secretos para um usurio confiden-cial desconhecido.

Uma poltica de fluxo especifica os canais ao lon-go dos quais a informao tem permisso para mo-ver. A poltica de fluxo mais simples especifica apenas duas classes de informao - confidencial (C) e no .confidencial (N) - e permite todos os fluxos, exceto aqueles da classe C para a classe N. Essa poltica pode solucionar o problema de confinamento que surge quando um programa de servio trata de dados como informaes do cliente, alguns dos quais podem ser confidenciais. Por exemplo, um servio de clculo de imposto de renda poderia ter permisso para reter o endereo do cliente e apresentar a conta dos servios, mas no a receita ou as dedues de um cliente.

Os mecanismos de controle de acesso so res-ponsveis por verificar as autorizaes dos usurios para acesso ao recurso: somente operaes conced.i-das so executadas. Os controles de fluxo podem ser impostos por um mecanismo estendido de controle de acesso, que envolve atribuir uma classe de segu-rana (normalmente chamada de autorizao) a cada programa em execuo. O programa rem permisso para ler determinado segmento de memria somen-te se sua classe de segurana for to alta quanto a do segmento . Ele s rem permisso para gravar em um segmento se sua classe for pelo menos a mesma que a do segmento. Isso automaticamente garante que nenhuma informao transmitida pela pessoa pode passar de uma classe mais alta para uma mais baixa. Por exemplo, um programa militar com aurorizao secreta s pode ler de objeros que so pblicos e con-fidenciais, e s pode gravar em objetos que sejam se-cretos ou altamente secretos.


Dois tipos de fluxo podem ser distinguidos: flu-xos explcitos, que ocorrem como uma consequncia das instrues de atribuio, como Y:= f(X 1.Xn)' e fluxos implicitos, gerados por instrues condicio-nais, como se ((X,.1 ... X) ento Y:= ( (X1.X,).

Os mecanismos de controle de fluxo precisam verificar que apenas fluxos autorizados, explcitos e implcitos, sejam executados. Um conjunto de regras precisa ser satisfeito para garantir fluxos de informa-o seguros. As regras podem ser expressas usando relaes de fluxo entre as classes e atribudas in-formao, indicando os fluxos autorizados dentro de um sistema. (Um fluxo de informao de A para B ocorre quando a infonnao associada a A afera o valor da informao associada a B. O fluxo resulta de ope-raes que causam transferncia de informaes de um objero para outro.) Essas relaes podem defi-nir, para uma classe, o conjunto de classes em que a informao (confidencial nessa classe) pode fluir, ou podem indicar as relaes especficas a serem verifi-cadas entre duas classes para permitir que a informa-o flua de uma para a outra. Em geral, os mecanis-mos de controle de fluxo implementam os controles ao atribuir um rtulo a cada objeto e ao especificar a classe de segurana do objeto. Os rtulos so ento utilizados para verificar as relaes de fluxo definidas no modelo .

24.6.1 Canais secretos Um canal secreto permite uma transferncia de

informao que viola a segurana ou a poltica. Es-pecificamente, um can al secreto permite que infor-maes passem de um nvel de classificao mais alto para um nvel de classificao mais baixo por meios imprprios. Os canais secretos podem ser classifica-dos em duas categorias gerais: canais de temporiza-o e armazenamento. O recurso diferenciador entre as duas que em um canal de temporizao a infor-mao transmitida pela temporizao de eventos ou processos, enquanto os canais de armazenamen-to no exigem qualquer sincronismo temporal, visto que a informao transmitida ao acessar informa-es do sistema ou o que, de outra forma, inacess-vel ao usurio.

Em um exemplo simples de canal secreto, con-sidere um sistema de banco de dados distribudo em que dois ns tenham nveis de segurana do usurio secreto (S) e no classificado (U). Para que uma transao seja confirmada, os dois ns pre-cisam concordar com isso. Eles s podem rea lizar operaes mutuamente que so consistentes com a propriedade , que afirma que, em qualquer transa-o, o nS no pode gravar ou passar informaes para o n U. Contudo, se esses dois ns combina-


rem para estabelecer um cana l secreto entre eles, uma transao envolvendo dados secretos poder ser confirmada de maneira incondicional pelo n U, mas o n S pode fazer isso de alguma maneira previamente combinada, de modo que cerras infor-maes possam ser passadas do n S para o n U, violando a propriedade . Isso pode ser alcana-do onde a transao executada repetidamente, mas as aes tomadas pelo n S de modo implcito transmitem informaes ao n U. Medidas como bloqueio, que discutimos nos captulos 22 e 23, impedem a gravao simult nea das informaes pelos usurios com diferentes nveis de segurana nos mesmos objetos, impedindo os canais secretos da categoria de armazenamento. Os sistemas ope-racionais e os bancos de dados distribudos oferecem controle sobre a multiprogramao de operaes, o que permite um compartilbamento de recursos sem a possibilidade de invaso de um programa ou processo na memria ou outros recursos do sis-tema, impedindo assim os canais de temporizao secretos. Em geral, os cana is secretos no so um grande problema nas implementaes de banco de dados robustas e bem implementadas. Contudo, certos esquemas que implicitamente transferem informaes podem ser idea lizados por usurios inteligentes.

Alguns especialistas em segurana acreditam que uma forma de evitar os canais secretos impe-dir que os programadores realmente tenham acesso aos dados confidenciais que um programa processar depois que tiver entrado em operao. Por exemplo, um programador de um banco no tem necessidade de acessar os nomes ou saldos nas contas dos clien-tes. Os programadores de firmas de corretagem no precisam saber quais ordens de compra e venda exis-tem para os clientes. Durante o teste do programa, o acesso a uma forma de dados reais ou alguns dados de teste de exemplo pode ser justificvel, mas no de-pois de o programa ser aceito para uso regular.

24.7 Criptografia e infraestruturas de chave pblica

Os mtodos de acesso anteriores e o controle de fluxo, apesar de serem medidas de controle for-tes, podem no ser capazes de proteger os bancos de dados contra algumas ameaas. Suponha que co-muniquemos dados, mas eles caiam nas mos de um usurio ilegtimo. Nessa situao, ao usar a cripto-grafia, podemos disfarar a mensagem de modo que, mesmo que a transmisso seja desviada, a mensagem

no ser revelada. A criptografia a converso de dados para um formato, chamado texto cifrado, que no pode ser facilmente entendido por pessoas no autorizadas. Ela melhora a segurana e a privacidade quando os controles de acesso so evitados, pois em casos de perda ou roubo de dados, aqueles cripto-grafados no podem ser facilmente entendidos por pessoas no autorizadas.

Com essa base, aderimos s seguintes definies padro:6

Texto cifrado: dados criptografados {codifi-cados).

Texto limpo (ou texto claro): dados intelig-veis que tm significado e podem ser lidos ou atuados sem a aplicao da descriptografia.

Criptografia: o processo de transformar texto limpo em texto cifrado.

Descriptografia: o processo de transformar texto cifrado de volta para texto limpo.

A criptografia consiste em aplicar um algoritmo de criptografia aos dados usando alguma chave de criptografia pr-especificada. Os dados resultantes precisam ser descriptografados usando uma chave de descriptografia para recuperar os dados originais.

24.7.1 Os padres Data Encryption e Advanced Encryption

O Data Encryption Standard {DES) lLm sistema desenvolvido pelo governo dos EUA para uso pelo p-blico em geral. Ele foi bastante aceito como padro criptogrfico nos Estados Unidos e no exterior. ODES pode oferecer criptografia de ponta a ponta no canal entre o emissor A e o receptor B. O algoritmo DES uma combinao cuidadosa e complexa de dois blocos de montagem fundamentais da criptografia: substitui-o e permutao (transposio). O algoritmo deriva sua robustez da aplicao repetida dessas duas tcni-cas para um rotai de 16 ciclos. O texto limpo (a forma original da mensagem) criptografado como blocos de 64 bits. Embora a chave tenha 64 bits de extenso, na verdade a chave pode ser qualquer nmero de 56 bits. Aps questionar a adequao do DES, o NIST introduziu o Advanced Encryption Standard (AES). Esse algoritmo tem um tamanho de bloco de 128 bits, comparado com o tamanho de 56 bits do DES, e pode usar chaves de 128, 192 ou 256 bits, em comparao com a chave de 56 bits do DES. O AES introduz mais chaves possveis, em comparao com oDES, e, assim, exige muito mais tempo para quebrar uma chave.

8Essas defnes so do NIST (Nationallnstitute ol Standards and Technology). JSJ)ClllI/eiS em: .

24.7.2 Algoritmos de chave simtrica Uma chave simtrica uma chave uti lizada para

criptografia e descriptografi a. Ao usar uma chave si-mtrica, a criptografia e a descriptografia rpidas so possveis para emprego rotineiro com dados sensveis no banco de dados. Uma mensagem criptografada com uma chave secreta pode ser descriptografada ape-nas com a mesma chave secreta. Os algoritmos usados para a criptografia de chave simtrica so chamados algoritmos de chave secreta. Como tais algoritmos so utilizados principalmente para criptografar o conte-do de uma mensagem, eles tambm so chamados de algoritmos de criptografia de contedo.

A principal desvantagem associada aos algorit-mos de chave secreta a necessidade de compartilhar essa chave. Um mtodo possvel derivar a chave se-Creta de uma cadeia de carateres de senha fornecida pelo usurio ao aplicar a mesma funo cadeia de carateres no emissor e no receptor; isso conhecido como algoritmo de crif;tografia baseado em senha. A robustez da criptografia de chave simtrica depende do tamanho da chave utilizada. Para o mesmo algo-ritmo, a criptografia que uti liza uma chave mais lon-ga mais difcil de ser quebrada do que aquela que usa uma chave mais curta.

24.7.3 Criptografia de chave pblica (assimtrica)

Em 1976, Diffie e Hellman propuseram um novo tipo de sistema criptogrfico, que eles chamaram de criptografia de chave pblica. Os algoritmos de chave pblica so baseados em funes matemticas em vez de em operaes em padres de bits. Eles resolvem um problema da criptografia de chave simtrica, a saber, que tanto o emissor quanto o destinatrio precisam trocar a chave comum de uma maneira segura. Nos sistemas de chave pblica, duas chaves so utilizadas para criptografia/descriptografia. A chave pblica pode ser transmitida de uma maneira no segura, en-quanto a chave privada no transmitida. Esses al-goritmos - que usam duas chaves relacionadas, uma chave pblica e uma chave privada, para realizar ope-raes complementares (criptografia e descriptografia) - so conhecidos como algoritmos de criptografia de chave assimtrica. O emprego de duas chaves pode ter consequncias profundas nas reas de confidenciali-dade, distribuio de chave e autenticao. As duas chaves usadas para a criptografia de chave pblica so conhecidas como chave pblica e chave privada. A ltima mantida em segredo, mas referenciada como chave privada em vez de chave secreta (a chave usada na criptografia convencional) para evitar confu-so com a criptografia convencional. As duas chaves


so matematicamente relacionadas, pois uma de-las serve para realizar a criptografia e a outra, para realizar a descriptografia. Contudo, muito difcil derivar a chave privada com base na chave pblica.

Um esquema de criptografia de chave pblica, ou infraestrutura, tem seis ingredientes:

1. T exto limpo. Trata-se dos dados ou mensa-gem legvel que alimenrada no algoritmo como entrada.

2. Algoritmo de criptografia. Esse algoritmo rea-liza d iversas transformaes no texto limpo.

3. e 4. Chaves pblica e privada. Trata-se de um par de chaves que foram selecionadas de modo que, se uma for usada para cripto-grafia, a outra uti lizada para descriptogra-fia . As transformaes exatas realizadas pelo algoritmo de criptografia dependem da chave pblica ou privada que fornecida corno en-trada. Por exemplo, se uma mensagem crip-tografada com a chave pblica, ela s pode ser descriptografada com a chave privada.

5. T exto cifrado. Essa a mensagem misturada produzida como sada. Ela depende do texto limpo e da chave. Para determinada mensa-gem, duas chaves diferenres produziro dois textos cifrados diferentes.

6. Algoritmo de descriptografia. Esse algoritmo aceita o texto cifrado e a chave correspon-dente, e produz o texto limpo original.

Como o nome sugere, a chave pblica do par se torna pblica para outros a usarem, enquanto a chave privada conhecida apenas por seu proprie-trio. Um algoritmo criptogrfico de chave pblica para uso geral conta com uma chave para criptogra-fia e uma chave diferente, porm relacionada, para descriptografia. As etapas essenciais so as seguintes:

1. Cada usurio gera um par de chaves a serem usadas para criptografar e descriptografar as mensagens.

2. Cada usurio coloca uma das duas chaves em um registrador pblico ou outro arquivo acessvel. Essa a chave pblica. A chave cor-respondente mantida privada.

3. Se um emjssor deseja enviar uma mensagem privada a um receptor, o emissor criptografa a mensagem usando a chave pblica do receptor.

4. Quando o receptor recebe a mensagem, ele ou ela a descriprografa com a chave privada do receptor. Nenhum outro destinatrio pode descriptografar a mensagem porque somente o receptor conhece sua chave privada.


O algoritmo de criptografia de chave pblica RSA. Um dos primeiros esquemas de chave pblica foi introduzido em 1978 por Ron Rivest, Adi Shamir e Len Adleman no MIT e recebeu o nome de esquema RSA devido s iniciais de seus sobrenomes. O esque-ma RSA, desde ento, tem sido afirmado como a tc-nica mais aceita e implementada para a criptografia de chave pblica. O algoritmo de criptografia RSA incorpora resultados da teoria dos nmeros, com-binados com a dificuldade de determinar os fatores primos de um a lvo. O algoritmo RSA tambm opera com a aritmtica modular- mod n.

Duas chaves, d e e, so usadas para criptogra-fia e descriprografia. Uma propriedade importante que elas podem ser trocadas. n escolhida como um inteiro grande, que um produto de dois nmeros primos distintos grandes, a e b, n =a x b. A chave de criptografia e um nmero escolhido aleatoriamente entre 1 e n que seja relativamente primo de (a - 1) x (b - 1). O bloco de texto limpo P criptografado como P< = P mod n. Como a exponenciao rea lizada como mod n, a fatorao de P para des-vendar o texto limpo criptografado difcil. Porm, a chave de descriptografia d cuidadosamente escolhi-da de modo que (f

dados, devemos at mesmo limitar a realizao da minerao e anlise de dados em grande escala. Uma das tcnicas mais comuns para resolver esse proble-ma evitar a criao de warehouses centrais imensos como um nico repositrio de informaes vitais. Outra medida possvel modificar ou perturbar da-dos intencionalmente.

Se todos os dados estivessem disponveis em um nico warehouse, a violao da segurana de um nico repositrio poderia expor todos os dados. Evitar warehouses centrais e usar algoritmos de mi-nerao de dados distribudos minimiza a troca de dados necessria para desenvolver modelos global-mente vlidos. Ao modificar, atrapalhar e tornar os dados annimos, tambm podemos aliviar os riscos de privacidade associados minerao de dados. Isso pode ser feito ao remover informaes de identidade dos dados liberados e ao injetar rudo aos dados. Po-rm, ao usar essas tcnicas, devemos prestar ateno qualidade dos dados resultantes no banco de da-dos, que podem sofrer muitas modificaes. Tambm devemos poder estimar os erros passveis de serem introduzidos por essas modificaes.

A privacidade uma rea importante de pesquisa contnua no gerenciamento de banco de dados. Isso complicado devido a sua natureza multidisciplinar e suas questes relacionadas subjetividade na inter-pretao da privacidade, confiana, e assim por dian-te. Como exemplo, considere registras e transaes mdicos e legais, que devem manter certos requisitos de privacidade enquanto esto sendo definidos e im-postos. Oferecer controle de acesso e privacidade para dispositivos mveis tambm est recebendo cada vez mais ateno. Os SGBDs precisam de tcnicas robus-tas para o armazenamento eficiente de informaes relevantes segurana em pequenos dispositivos, bem como tcnicas de negociao de confiana. Onde manter informaes relacionadas a identidades, perfis, credenciais e permisses e como us-las para a iden-tificao confivel do usurio ainda um problema importante. Como fluxos de dados de grande tama-nho so gerados em tais ambientes, preciso elaborar tcnicas eficientes para controle de acesso, integrando-as com tcnicas de processamento para consultas con-tnuas. Por fim, preciso que se garanta a privacidade dos dados de localizao do usurio, adquiridos de sen-sores e redes de comunicao.

24.9 Desafios da segurana do banco de dados

Considerando o grande crescmenro em volu-me e velocidade das ameaas aos bancos de dados e informaes, preciso dedicar esforos de pesquisa


s seguintes questes: qualidade dos dados, direitos de propriedade intelectual c sobrevivncia do banco de dados. Estes so apenas alguns dos principais desa-fios que os pesquisadores em segurana de banco de dados esto tentando resolver.

24.9.1 Qualidade dos dados A comunidade de banco de dados precisa de tc-

nicas e solues organizacionais para avaliar e ates-tar a qualidade dos dados. Essas tcnicas podem in-cluir mecanismos simples, como rtulos de qualidade que so postados no sites Web. Tambm precisamos de tcnicas que ofeream verificao eficaz da semn-tica de integridade e ferramentas para a avaliao da qualidade dos dados, com base em tcnicas como a ligao de regisrros. Tcnicas de recuperao em n-vel de aplicao tambm so necessrias para reparar automaticamente os dados incorretos. As ferramen-tas de ETL (Extract, Transform, Load - extrao, transformao, carga), bastante usadas para carregar dados em data warehouses (ver Seo 29.4), atual-mente esto atacando essas questes.

24.9.2 Direitos de propriedade intelectual

Com o uso generalizado da Internet e de intraners, aspectos legais e informativos dos dados esto se tor-nando preocupaes importantes das organizaes. Para enfrentar esses problemas, tm sido propostas tc-nicas de marca d'gua para dados relacionais. A finali-dade principal da marca d'gua digital proteger o con-tedo contra duplicao e distribuio no autorizadas, habilitando a proprietrio provvel do contedo. Isso tradicionalmente tem ficado por conta da disponibili-dade de um grande domnio de rudo, dentro do qual o objeto pode ser alterado enquanto retm suas pro-priedades essenciais. Porm, preciso que haja pesquisa para avaliar a robustez dessas tcnicas e para investigar diferentes tcnicas visando preveno de violaes dos direitos de propriedade intelectual.

24.9.3 Sobrevivncia do banco de dados Os sistemas de banco de dados precisam operar

e continuar suas funes, mesmo com capacidades reduzidas, apesar de eventos destruidores, como ata-ques de busca de vantagem competitiva. Um SGBD, alm de realizar rodos os esforos para impedir um ataque e detectar um, caso ocorra, deve ser capaz de fazer o seguinte:

Confi namento. Tomar ao imediata para eli-minar o acesso do atacante ao sistema e isolar ou conter o problema para impedir que se es-palhe mais.


Avaliao de danos. Determina a extenso do problema, incluindo funes que falharam e dados adulterados.

Reconfigurao. Reconfigurar para permitir que a operao continue em um modo redu-zido enquanto a recuperao prossegue.

Reparo. Recuperar dados adulterados ou per-didos e reparar ou reinstalar funes do sistema que falharam, para restabelecer um nvel de operao normal.

T ratamento de falha. Ao mximo possvel, identificar os pontos fracos explorados no ataque e tomar medidas para impedir uma

nova ocorrcncta.

O objetivo do atacante em busca de vantagem competitiva prejudicar a operao da organizao e a realizao de sua misso, por meio de danos a seus sistemas de informao. O alvo especfico de um ataque pode ser o prprio sistema ou seus dados. Embora os ataques que paralisam totalmente o sis-tema sejam graves e dramticos, eles tambm devem ser bem temporizados para alcanar o objetivo do atacante, pois os ataques recebero ateno imediata e concentrada, a fim de retornar o sistema condio operacional, diagnosticar como ocorreu o ataque e instalar medidas preventivas.

At o momento, questes relacionadas sobrevi-vncia do banco de dados ainda no foram suficien-temente investigadas. preciso que se dedique muito mais pesquisa s tcnicas e metodologias que garan-tam a sobrevivncia do sistema de banco de dados.

24.10 Segurana baseada em rtulo no Oracle

Restringir o acesso a tabelas inteiras ou isolar dados confidenciais em bancos de dados separados uma operao dispendiosa para se administrar. A Oracle Label Sccurity evita a necessidade dessas me-didas ao habilitar o controle de acesso em nvel de linha. Ela estava disponvel no Oracle Database llg Release 1 (11 .1) Enterprise Edition no momento em que este livro foi escrito. Cada tabela ou viso do banco de dados tem uma poltica de segurana asso-ciada a ela. Essa poltica executada toda vez que a tabela ou viso consultada ou alterada. Os desen-volvedores podem prontamente acrescentar o con-trole de acesso baseado em rtulo as suas aplicaes em Oracle Database. A segurana baseada em rtulo oferece uma forma adaptvel de controlar o acesso a dados confidenciais. Tanto usurios quanto dados

possuem rtulos associados a eles. A Oracle Label Security usa esses rrulos para oferecer segurana.

24.10.1 Tecnologia Virtual Private Database (VPD)

O Virtual Privare Databases (VPDs) um recurso do Oracle Enterprise Edition que acrescenta predicados aos comandos do usurio para limitar seu acesso de uma maneira transparente ao usurio e aplicao. O conceito de VPD permite o controle de acesso imposto pelo servidor, detalhado, para uma aplicao segura.

O VPD oferece controle de acesso baseado em po-lticas. Essas polticas de VPD impem controle de aces-so em nvel de objeto ou segurana em rvel de linha. Isso fomece uma interface de programao de aplicao (API) que permite que as polticas de segmana sejam ligadas s tabelas ou vises do banco de dados. Ao utili-zar PUSQL, uma linguagem de programao hospedeira usada em aplicaes Oracle, os desenvolvedores e admi-nistradores de segurana podem implementar polticas de segurana com a ajuda de procedimentos armazena-dos.' As politicas VPD permitem que os desenvolvedo-res removam os mecanismos de segurana de acesso das aplicaes e os centralizem no Oracle Data base.

O VPD habilitado ao associar-se uma 'polti-ca' de segurana a uma tabela, viso ou sinnimo. Um administrador usa o pacote PUSQL fornecido, SGBD_RLS, para vincular uma funo da poltica a um objeto do banco de dados. Quando um objeto que tem uma poltica de segurana associada a ela acessado, a funo que implementa essa politica consultada. A funo da poltica retorna um predi-cado (uma clusula WHERE) que ento anexado ao comando SQL do usurio, modificando assim, de forma transparente e dinmica, o acesso aos dados pelo usurio. A Oracle Label Security uma tcnica de imposio da segurana em nvel de linha na for-ma de uma poltica de segurana .

24.10.2 Arquitetura La bel Security A Oracle Label Security est embutida na tec-

nologia VPD entregue no Oracle Database 11.1 En-terprise Edition. A Figura 24.4 ilustra como os dados so acessados sob a Oracle Label Security, mostran-do a sequncia de verificaes do DAC e da seguran-a de rtulo.

A Figura 24.4 mostra a sequncia de verificaes do DAC e da segurana de rtulo. A parte da esquerda da figura mostra um usurio de aplicao em uma ses-so do Oracle Data base 11g Release 1 (11.1) envian-do uma requisio em SQL. O SGBD Oracle verifica

' Procedimentos armazenados (ou stored proceclures) foram discutidos na Seo 5.2.2.

Usurio do Oracle

+ Solicitao de dados em SQL

+ Verifica DAC

(Discretionary Access Control)

+ ~ Verifica poltica VPD (Virtual Private Databa se)

+ Impe segurana baseada em rtu lo

+ Processa e executa requisio de dados

Figura 24.4 Arquitetura Oracle Label Security.

Fonte: Oracle (2007)

'-""'

~

os privilgios do DAC do usurio, garantindo que ele ou ela tenha privilgios SELECT na tabela. Depois, ele verifica se a rabeia rem uma poltica de Virtual Privare Darabase (VPD) associada para determinar se a tabela est protegida ao usar a Oracle La bel Securiry. Se ri ver, a modificao SQL da poltica VPD (clusula WHERE) acrescenrada instruo SQL original para encon-trar o conjunto de linhas acessveis que o usurio pode ver. Depois, a Oracle La bel Security verifica os rtulos em cada linha, para determinar o subconjunto de li-nhas s quais o usurio rem acesso (conforme explica-remos na prxima seo). Essa consulta modificada processada, orimizada e executada.

24.10.3 Como rtulos de dados e rtulos de usurio trabalham juntos

O rtulo de um usurio indica a informao que este tem permisso para acessar. Ele tambm determi-na o r.ipo de acesso (leitura ou gravao) que o usu-rio tem sobre essa informao. O rtulo de uma linha mostra a sensibilidade da informao que a linha con-tm, bem como a propriedade da informao. Quando uma tabela no banco de dados tem um acesso baseado em rtulo associado a ela, uma linha s pode ser aces-sada se o rtulo do usurio atender a certos critrios definidos nas definies da poltica. O acesso conce-dido ou negado com base no resultado da comparao do rtulo de dados e do rtulo de sesso do usurio.

Os compartimentos permitem uma classificao mais detalhada da sensibilidade dos dados rotulados.


Servidor de dados Oracle

Privilgios em Polticas de nvel de tabela segurana de rtulo

Tabela

Linhas de dados na tabela Controle de acesso

em nvel de linha

Polticas de VPD

Controle baseado definidas pelo usurio

emVPD

Todos os dados relacionados ao mesmo projeto po-dem ser rotulados com o mesmo compartimento. Os compartimentos so opcionais; um rtulo pode con-ter zero ou mais compartimentos.

Os grupos so usados para identificar organiza-es como proprietrias dos dados com rtulos de gru-po correspondentes. Os grupos so hierrquicos; por exemplo, um grupo pode ser associado a um grupo pai.

Se um usurio tiver um nvel mximo de SENSI-TIVE, ento o usurio potencialmente tem acesso a to-dos os dados com nveis SENSITIVE, CONFIDENTIAL e UNCLASSIFIED. Esse usurio no tem acesso a dados HIGHLY_SENSITIVE. A Figura 24.5 mostra como os rtulos de dados e de usurio trabalham juntos para oferecer controle de acesso na Oracle La bel Security.

Corno vemos na Figura 24.5, o Usurio 1 pode ter acesso s linhas 2, 3 e 4, pois seu nvel mximo HS (H ighly_Sensirive). Ele tem acesso ao compartimento FIN (Finanas), e seu acesso ao grupo WR (Wesrern Region) hierarquicamenre inclui o grupo WR_SAL (WR Sales). Ele no pode acessar a linha 1 porque no rem o compartimento CHEM (Chemical). impor-tante que um usurio tenha autorizao para todos os compartimentos no rtulo de dados de uma linha para poder acess-la. Com base nesse exemplo, o usurio 2 pode acessar as linhas 3 e 4, e rem um nvel mximo de S, que menor que o HS na linha 2. Portanto, embora o usurio 2 tenha acesso ao compartimento FIN, ele pode acessar apenas o grupo WR_SAL, e, dessa for-ma, no pode acessar a linha 1.


Rtulo de usurio

Rtulo de dados

Nvel de acesso mximo

Nvel de acesso mnimo

exigido

Todos os compartimentos aos quais o usurio tem acesso

Todos os compartimentos aos quais o usurio deve ter acesso

Rtulos de usurio Linhas na tabela Rtulos de dados

Figura 24.5

HS l FIN : WR

s i FIN : WR_SAL

enda dos rtulos = Altamente sensvel

Leg HS S = C=

Sensvel Confidencial

u = Pblico

Rtulos de dados e rtulos de usurio no Oracle. Fonte: Oracle (2007)

Resumo

Linh

Lint

unt

Lint

Neste captulo, discutimos vrias tcnicas para impor a segurana do sistema de banco de dados. Apresentamos diferentes ameaas aos bancos de da-dos em relao perda de integridade, disponibili-dade e confidencialidade. Discutimos os tipos de medidas de controle para lidar com esses problemas: controle de acesso, controle de inferncia, controle de fluxo e criptografia. a introduo, abordamos diversas questes relacionadas segurana, incluindo sensibilidade de dados e tipo de exposies, ofere-cendo segu rana versus preciso no resul tado quando um usurio solicita informaes, e o relacionamento entre segurana e privacidade das informaes.

A imposio da segurana lida com o controle do acesso ao sistema de banco de dados corno um todo e com o controle da autorizao para acessar panes especficas de um banco de dados. O primeiro nor-malmente feito ao atribuir contas com senhas aos usurios. O segundo pode ser realizado com o uso de um sistema de concesso e revogao de privilgios a contas individuais para acessar partes especficas do banco de dados. Essa tcnica geralmente conhe-cida como controle de acesso discricionrio (DAC). Apresentamos alguns comandos SQL para conce-der e revogar privilgios, e ilustramos seu uso com exemplos. Depois, oferecemos uma viso geral dos mecanismos de controle de acesso obrigatrio (MA C) que impem a segurana mu ltinvel. Estes exigem

a 1 Is CHEM, FIN : WR

a 2 I HS i FIN : WR_SAL

a3 I u FIN

a4 I c i FIN : WR_SAL

as classificaes de usurios e valores de dados em classes de segurana e impem as regras que pro-bem o fluxo de informaes dos nveis de segurana mais altos para os mais baixos. Alguns dos principais conceitos nos quais o modelo relaciona l multinvel se baseia, incluindo filtragem c poli-instanciao, fo-ram apresentados. O controle de acesso baseado em papis (RBAC) foi introduzido, e atribui privi lgios com base nos papis que os usurios desempenham. Abordamos a noo de hierarquias de papis, exclu-so mtua de papis c segurana baseada em linha e r tulo. Discutimos rapidamente problema de con-t role de acesso a bancos de dados estatsticos para proteger a privacidade de informaes individuais e, ao mesmo tempo, oferecer acesso estatstico a popu-laes de registros. Explicamos as principa is ideias por trs da ameaa da lnjeo de SQL, os mtodos nos quais ela pode ser induzida c os v1rios t ipos de riscos associados a ela. Depois, demos uma ideia das diversas formas como a lnjeo de SQL pode ser im-pedida. As questes re lacionadas a controle de fluxo e os problemas associados a canais secretos foram discutidos em seguida, bem como a criptografia e as infraestruturas baseadas em chave pblica/privada. A ideia de algoritmos de chave simtrica e o uso do popular esquema de infraestrutura de chave pblica (PKI) baseada em chave assimtr ica foram explica-dos. Tambm abordamos os conceitos de assinaturas digitais e certificados digirais. Destacamos a impor-

tncia de questes de privacidade e sugerimos algu-mas tcnicas de preservao da privacidade. Discu-timos uma srie de desafios segurana, incluindo qualidade de dados, direitos de propriedade intelec-tual e sobrevivncia do banco de dados. Terminamos o captulo introduzindo a implementao de polticas de segura na ao usar uma combinao da segurana baseada em rtulo e os bancos de d ados privados vir-tuais no Oracle llg.

Perguntas de reviso

24.1. Discuta o significado de cada um dos seguintes termos: autorizao de banco de dados, controle de acesso, criptografia de dados, conta privile-giada (sistema), auditoria de banco de dados, trilha de auditoria.

24.2. Que conta designada como proprietria de uma relao? Que privilgios o proprietrio de uma relao possui?

24.3. Como o mecanismo de viso usado como um mecanismo de autorizao?

24.4. Discuta os tipos de privilgios no nvel de conta c aqueles no nvel de relao.

24.5. O que significa a concesso de um privilgio? O que significa a revogao de um privilgio?

24.6. Discuta o sistema de propagao de privilgios e as restries impostas pelos limi tes de propaga-o horizontais e verticais.

24.7. Liste os tipos de privilgios disponveis em SQL.

24.8. Qual a diferena entre controle de acesso dis-cricionrio e obrigatrio?

24.9. Quais so as classificaes de segurana tpicas? Discuta a propriedade de segurana simples e a propriedade *, e explique a justificativa por trs dessas regras para impor a segurana mulrinvel.

24.10. Descreva o modelo de dados relacional multin-vel. Defina os seguintes termos: chave aparente, poli-instanciao, filtragem.

24.11. Quais so os mritos relativos do uso do DAC o u do MAC?

24.12. O que controle de acesso baseado em papel? De que maneiras ele superior ao DAC e ao MAC?

24.13. Quais so os dois tipos de excluso mtua no controle de acesso baseado em papel?

24.14. O que significa controle de acesso em nvel de linha?

24.15. O que a segurana de rwlo? Como um admi-nistrador a impe?

24.16. Quais so os diferentes tipos de ataques de lnje-o de SQL?

24.17. Que riscos esto associados aos ataques de lnje-o de SQL?

Capitulo 24 Segurana de banco de dados 58'7

24.18. Que medidas preventivas so possveis contra os ataques de Lnjeo de SQL?

24.19. O que um banco de dados estatstico? Discuta o problema da segurana do banco de dados es-, . tattStiCO.

24.20. Como a privacidade est relacionada se-gurana do banco de dados estat stico? Que medidas podem ser tomadas para garantir a l-gum g rau de privacidade nos bancos de dados estatsticos?

24.21. O que controle de Auxo como uma medida de segurana? Que tipos de controle de Auxo existem?

24.22. O que so canais secretos? D um exemplo de c a na I secreto.

24.23. Qual o objerivo da criptografia? Que processo est envolvido na criptografia de dados e sua re-cuperao na outra ponta?

24.24. D um exemplo de algoritmo de criptografia e explique como ele funciona.

24.25. Repita a pergunta anterior para o a lgoritmo po-pular RSA.

24.26. O que algoritmo de chave assimtrica para a segurana baseada em chave?

24.27. O que esquema de infraestrutura de chave p-blica? Como ele oferece segurana?

24.28. O que so assinaturas digitais? Como elas fun-cionam?

24.29. Que tipo de informao um certificado digital inclui?

Exerccios

24.30. Como a p rivacidade dos dados pode ser preser-vada em um banco de dados?

24.31. Quais so alguns dos maiores desafios atuais para a segurana do banco de dados?

24.32. Considere o esquema de banco de dados re-lacional da Figura 3.5. Suponha que todas as relaes tenha m sido criadas pelo (e, p o r-tanto, pertencem ao) usurio X, que deseja conceder os seguintes privilgios s contas de usurio A, B, C, D e E: a. A conta A pode recuperar ou modificar qual-

quer relao, exceto DEPENDENTE, e pode conceder qualquer um desses privilgios a outros usurios.

b. A conta B pode recuperar rodos os atributos de FUNCIONARIO e DEPARTAMENTO, exce-to Salario, Cpf_ger e Data_inicio_ger.

c. A conta C pode recuperar ou modificar TRABALHA_EM, mas s pode recuperar os atributos Pnome, Minicial, Unome e Cpf de FUNCIONARIO e os atributOs Projnome e Projnumero de PROJETO.


d. A conta D pode recuperar qualquer atributo de FUNCIONARIO ou DEPENDENTE e pode modificar DEPENDENTE.

e. A conta E pode recuperar qualquer atributo de FUNCIONARIO, mas somente para rupias de FUNCIONARIO que tm Dnr = 3.

f. Escreva instrues SQL para conceder esses privilgios. Use vises onde for apropriado.

24.33. Suponha que o privilgio (a) do Exerccio 24.32 deva ser dado com GRANT OPTION, mas so-mente para que a conta A possa conced-lo a no mximo cinco contas, e cada uma dessas contas possa propagar o privilgio a outras contas, mas sem o privilgio GRANT OPTION. Quais seriam os limites de propagao horizontal e vertical nesse caso?

24.34. Considere a relao mostrada na Figura 24.2(d). Como ela apareceria para um usurio com clas-sificao U? Suponha que um usurio com classi-ficao Utente atualizar o salrio de 'Silva' para R$50.000; qual seria o resultado dessa ao?

Bibliografia selecionada A autorizao baseada na concesso e revogao

de privilgios foi proposta para o SGBD experimental SYSTEM R e apresentada em Griffiths e Wade (1976). Vrios livros discutem a segurana nos bancos de dados e sistemas de computao cm geral, incluindo os livros de Leiss (1982a) c Fernandez et ai. (1981), e Fugini et ai. (1995). atan (2005) um livro prtico sobre questes de segurana e auditoria em todos os principais SGBDRs.

Muitos artigos discutem as difercnrcs tcnicas para o projeto e proteo de bancos de dados estatsticos. En-tre eles esto McLeish (1989), Chin e Ozsoyoglu (1981), Leiss (1982), Wong (1984) e Denning (1980). Ghosh (1984) discute o uso de bancos de dados estatsticos para o controle da qualidade. H tambm muitos artigos que discutem a criptografia e a criptografia de dados, incluin-do Diffie e Hellman (1979), Rivest et ai. (1978), Akl (1983), Pfleeger e Pfleeger (2007), Omura et ai. (1990), Stallings (2000) e Jyer et ai. (2004).

Halfond et ai. (2006) ajudam a entender os concei-tos de ataques de lnjeo de SQL e as vrias ameaas impostas por eles. O documento oficial Oracle (2007a)

explica como o Oracle menos passvel a um ataque de lnjeo de SQL cm comparao com o SQL Servcr. Ele tambm oferece uma rpida explicao de como esses ataques podem ser impedidos. Outras estruturas propos-tas so discutidas em Boyd e Keromytis (2004), Halfond e Orso (2005) e McCiure e Krger (2005).

A segurana multinvcl discutida em j ajodia e Sandhu (1991 ), Denning et ai. (1987), Smith e Winsletr (1992), Stachour e Thuraisingham (1990), Lum et ai. (1990) e Bertino et ai. (2001). Vises gerais de ques-tes de pesquisa em segurana de banco de dados so dadas por Lunt e Fernandez (1990), jajodia c Sandhu (1991), Bertino (1998), Casrano er ai. (1995) e Tlm-raisingham et ai. (2001 ). Os efeitos da segurana mul-tinvel no controle de concorrncia so discutidos em Atluri et ai. (1997). A segurana nos bancos de dados da prxima gerao, semnticos e orientados a objeto discutida em Rabbiti et ai. (1991), Jajodia e Kogan (1990) e Smith (1990). Oh (1999) apresenta um mo-delo para a segurana discriciomria e obrigatria. Os modelos de segurana para aplicaes baseadas na Web e o controle de acesso baseado em papel so discutidos em Joshi et ai. (2001). As questes de segurana para gerentes no contexto das aplicaes de e-cornmerce e a necessidade de modelos de avaliao de risco para a se-leo de medidas apropriadas de controle de segurana so discutidos em Farahmand et ai. (2005). O controle de acesso em nvel de linha explicado com detalhes em Oracle (2007b) e Sybase (2005). O ltimo tambm oferece detalhes sobre hierarquia de papel e excluso mtua. Oracle (2009) explica como o Oracle usa o con-ceito de gerenciamento de identidade.

Avanos recentes, bem como desafios futu ros para segurana e privacidade de bancos de dados, so discu-tidos em Berrino e Sandhu (2005). U.S. Govt. (1978), OECD (1980) e NRC (2003) so boas referncias sobre a viso da privacidade por importantes agncias do go-verno. Karat et ai. (2009) discutem uma estrutura pol-tica para segurana e privacidade. XML e controle de acesso so discutidos em Naedele (2003 ). Mais dera lhes podem ser encontrados sobre as tcnicas de preservao da privacidade em Vaidya e Clifton (2004 ), direitos de propriedade intelectual em Sion et ai. (2004) e sobrevi-vncia de banco de dados em Jajodia et ai. (1999). A tec-nologia de VPD e a segurana b!lSeada em rtulo do Ora-d e so discutidas com mais detalhes em Oracle (2007b).

~ ::::; ,~ -o. ro o

Neste captulo, voltamos nossa ateno para os bancos de dados distribudos (BDDs), sistemas de gerenciamento de bancos de dados distribudos (SGBDDs), e de que forma a arquitetura cliente-ser-vidor usada como uma plataforma para o desenvol-vimento de aplicaes de banco de dados. Os bancos de dados distribudos levam as vantagens da compu-tao distribuda para o domnio do gerenciamento de banco de dados. Um sistema de computao distri-budo consiste em uma srie de elementos de proces-samento, no necessariamente homogneos, que so interconectados por uma rede de computadores e que cooperam na realizao de cerras tarefas atribudas. Como um objetivo gera l, os sistemas de computao distribudos dividem um grande problema, d ifcil de ser administrado em partes menores, solucionando--o de modo eficiente de uma maneira coordenada. A viabilidade econmica dessa tcnica tem duas razes: mais poder de computao aproveitado para solu-cionar uma tarefa complexa, e cada elemento de pro-cessamento autnomo pode ser gerenciado indepen-dentemente para desenvolver as prprias aplicaes.

A tecnologia de BDD o resultado de uma fuso de duas tecnologias: tecnologia de banco de dados e tecnologia de rede e comunicao de dados. As redes de computadores permitem o processamento distri-budo de dados. Bancos de dados tradicionais, por sua vez, enfocam o fornecimento de acesso centra-lizado e controlado aos dados. Os bancos de dados distribudos permitem uma integrao de informa-es e seu processamento por aplicaes que podem, por si mesmas, ser centralizadas ou distribudas.

Diversos sistemas de prottipo de banco de da-dos distribudo foram desenvolvidos na dcada de 1980 para resolver as questes de d istribuio de da-dos, consulta distribuda e processamento de transa-

Bancos de dados distribudos

o, gerenciamento de metadados de banco de dados distribudo e outros assuntos. Porm, um SGBDD abrangente em escala completa, que implementa a funcionalidade e as tcnicas propostas na pesquisa em BDD, nunca surgiu como um produto comercial-mente vivel. A maioria dos principais vendedores redirecionou seus esforos de desenvolvimento de um produto SGBDD puro para o desenvolvimento de sistemas com base nos conceitos cliente-servidor, ou para o desenvolvimento de tecnologias para aces-sar fontes de dados heterogneas distribudas.

As organizaes continuam a estar interessadas na descentralizao do processamento (no nvel de sistema) enquanto alcanam uma integrao dos re-cursos de informao (no nvel lgico) dentro de seus sistemas de bancos de dados, aplicaes e usurios distribudos geograficamente. Agora, existe um en-dosso geral da abordagem cliente-servidor para o de-senvolvimento de aplicaes, e a abo rdagem de trs camadas para o desenvolvimento de aplicaes Web (ver Seo 2.5).

Neste captulo, discutimos os bancos de dados distribudos, suas variaes arqui tetn icas e concei-tos centrais distribuio de dados e ao gerencia-mento de dados distribudos. Alguns detalhes dos avanos nas tecnologias de com unicao que facili-tam o desenvolvimento de BDDs esto fora do esco-po deste livro; veja os textos sobre comunicaes de dados e redes, listados na bibliografia selecionada ao final deste captulo .

A Seo 25.1 introduz conceitos de gerencia-mento de banco de dados distribudo e outros rela-cionados. As sees 25.2 e 25.3 apresentam diferen-tes tipos de sistemas de bancos de dados distribudos e suas arquiteturas, incluindo sistemas federados e multibanco de dados. Os problemas de heterogenei-


dade e as necessidades de autonomia nos sistemas de bancos de dados federados tambm so destacados. Questes detalhadas sobre projeto de banco de da-dos distribudo, envolvendo fragmentao de dados e sua distribuio por vrios locais com possvel repli-cao, so discuridas na Seo 25.4. As sees 25.5 e 25.6 apresentam as tcnicas de processamento de transao e consulta de banco de dados distribudo, respectivamente. A Seo 25.7 oferece uma viso ge-ral do controle de concorrncia e recuperao nos bancos de dados distribudos. A Seo 25.8 discute os esquemas de gerenciamento de catlogo nos ban-cos de dados d istribudos. Na Seo 25.9, aborda-mos rapidamente as tendncias atuais nos bancos de dados distribudos, como a computao em nuvem e os bancos de dados peer-to-peer. A Seo 25.10 dis-cute os recursos de banco de dados distribudo do SGBDR Oracle. No fina l do captulo h um resumo.

Para obter uma rpida introduo ao assunto de bancos de dados distribudos, as sees 25.1, 25.2 e 25.3 podem ser estudadas.

25.1 Conceitos de banco de dados distribudo1

Podemos definir um banco de d ados distribudo (BDD) como uma coleo de mltiplos bancos de da-dos logicamenre inter-relacionados, distribudos por uma rede de computadores, e um sistema de geren-ciamento de banco de dados distribudo (SGBDD) como um sistema de software que gerencia um banco de dados distribudo enquanto torna a distribuio transparente ao usurio. 2

Os bancos de dados distribudos so diferentes dos arquivos Web da Internet. As pginas Web so basicamente uma coleo muito grande de arquivos armazenados em diferentes ns em uma rede - a Internet - com inter-relacionamemos entre os ar-quivos, representados por hyperlinks. As funes comuns do gerenciamento de banco de dados, in-cluindo o processamento de consulta uniforme e o processamento de t ransao, ainda no se aplicam a esse cenrio. A tecnologia, no entanto, est mudando para uma direo tal que os bancos de dados dis-t ribudos da World Wide Web (WWW) se tornaro uma realidade no futuro. Discutimos algumas das questes de acesso a bancos de dados na web nos ca-prulos 12 e 14. A proliferao de dados em milhes de sites Web em vrias formas no se qualifica como um BDD pela definio dada anteriormente.

25.1.1 Diferenas entre sistemas multi processadores e BDD

Precisamos dist inguir os bancos de dados distribu-dos dos sistemas multi processadores que usam armaze-namenro compartilhado (memria primria ou disco). Para um banco de dados ser chamado de distribudo, as seguintes condies mnimas devem ser satisfeitas:

Conexes de ns de banco de dados por uma rede de computadores. Existem vrios com-putadores, chamados sites ou ns. Esses sites devem ser conectados por uma rede de co-municao bsica para transmitir dados eco-mandos entre s ites, como mostramos adiante na Figura 25 .3(c).

lnter-relao lgica dos bancos de dados conec-tados. essencial que as informaes nos ban-cos de dados sejam relacionadas logicamente.

Ausncia de restrio de homogeneidade en-tre os ns conectados. No necessrio que rodos os ns sejam idnticos em relao aos dados, hardware e software.

Todos os sites podem estar localizados nas proxi-midades fsicas - digamos, dentro do mesmo prdio ou um grupo de prdios adjacentes-e conectados por uma rede local, ou podem estar distribudos geograficamen-te por grandes distncias e conectados por uma rede de longa distncia ou rede remota. As redes locais cosru-mam utilizar hubs sem fio ou cabos, enquanto as redes de longa distncia utilizam linhas telefnicas ou satlites. Tambm possvel usar uma combinao de redes.

As redes podem ter diferentes topologias que defi-nem os caminhos de comunicao diretos entre os sites. O tipo e a topologia da rede utilizada podem ter um im-pacto significativo no desempenho e, portanto, nas es-tratgias para o processamento de consulta distribudo e o projeto de banco de dados distribudo. Para ques-tes arquitetnicas de alto nvel, porm, no in1porta o tipo da rede utilizada; o que importa que cada site seja capaz de se comunicar, direta ou indiretamente, com rodos os outros sites. Para o restante deste captulo, consideramos que existe algum tipo de rede de comu-nicao entre os sites, independentemente de qualquer topologia em particular. No abordaremos quaisquer questes especficas da rede, embora seja importante entender que, para uma operao eficiente de um siste-ma de banco de dados distribudo (SBDD), questes de projeto e desempenho da rede so crticos e fazem parte integral da soluo geral. Os detalhes da rede de comu-nicao bsica so invisveis ao usurio final.

Agradecemos a Narasimhan Srinivasan por sua contnbuio substancial a esta e a vrias outras sees deste captulo. 1 Esta deflllio e as discusses nesta seo so baseadas em grande parte em Ozsu e \lalduriez (1999).

25.1.2 Transparncia O conceito de transparncia estende a ideia geral

de ocultar detalhes da implementao dos usurios finais. Um sistema altamente transparente oferece muita flexibilidade ao usurio finaVdesenvolvedor de aplicao, pois requer pouco ou nenhum conheci-mento dos detalhes bsicos de sua parte. No caso de um banco de dados centra lizado tradicional, a trans-parncia simplesmente perrence independncia l-gica e fsica de dados para desenvolvedores de apli-cao. Contudo, em um cenrio de BDD, os dados e software so distribudos por vrios sites conectados por uma rede de computado res, de modo que tipos adicionais de transparncias so introduzidos.

Considere o banco de dados de empresa da Fi-gura 3.5, que usamos como exemplo no decorrer do livro . As tabelas FUNCIONARIO, PROJETO e TRABA-LHA_EM podem ser fragmentadas horizontalmente (ou seja, em conjuntos de linhas, conforme discuti-remos na Seo 25.4) e armazenadas com possvel replicao, como mostra a Figura 25.1. Os seguintes tipos de transparncias so possveis:

Transparncia da organizao dos dados (tambm conhecida como transparncia de distribuio ou de rede). Isso se refere li-berdade para o usurio de detalhes operacio-nais da rede e o posicionamento dos dados no sistema distribudo. Ela pode ser dividida em transparncia de local e transparncia de no-mes. T ransparncia de local refere-se ao faro

FUNCIONARIOS

PROJETOS

Captulo 25 Bancos de dados distribudos 591

de que o comando usado para realizar uma tarefa independente do local dos dados e do local do n onde o comando foi emitido. T ransparncia de nomes implica que, quando um nome associado a um objeto, os objetos nomeados podem ser acessados sem ambigui-dade, sem especificao adicional quanto ao local onde os dados se encontram.

T ransparncia de replicao. Como mostramos na Figura 25.1, as cpias dos mesmos objeros de dados podem ser armazenadas em vrios sites para melhor disponibilidade, desempenho e coo-fiabilidade. A transparncia de replicao toma o usuJio desavisado da existncia dessas cpias.

Transparncia de fragmentao. Dois tipos de fragmentao so possveis. A fragmentao horizontal distribui uma relao {tabela) em sub-relaes que so subconjuntos de rupias (Linhas) na relao original. A fragmentao vertical distribui uma relao em sub-relaes em que cada uma definida por um subcon-junto das colunas da relao original. Uma consulta global pelo usurio precisa ser trans-formada em vrias consultas de fragmento. A transparncia de fragmentao torna o usu-rio desavisado da existncia de fragmentos.

Outras transparncias incluem transparncia de projeto e transparncia de execuo- re-ferindo-se liberdade de saber como o banco de dados distribudo projetado e onde uma transao executada.

Todos

Todos FUNCIONARIOS Belo Horizonte e Rio de Janeiro TRABALHA_EM Todos FUNCIONARIOS So Paulo

PROJETOS

TRABALHA_EM

Belo Horizonte

Funcionrios de Belo Horizonte

Belo Horizonte

Rio de Janeiro

FUNCIONARIOS Rio de Janeiro

PROJETOS Rio de Janeiro e Belo Horizonte

TRABALHA_ EM Funcionrios de Rio de Janeiro

Figura 25.1

Braslia (sede)

1

Rede de comunicaes

Distribuio e replicao de dados entre bancos de dados distribudos.

PROJETOS

TRABALHA_EM

So Paulo

Curitiba

FUNCIONARIOS

PROJETOS

TRABALHA_EM

Tod os

ncionrios So Paulo

Fu de

Curitiba

Curitiba

Funcionrios de Curitiba


25.1.3 Autonomia A autonomia determina a extenso qual os ns

individuais ou BDs em um BDD conectado podem operar independentemente. Um alto grau de autono-mia desejvel para maior flexibilidade e manuteno personalizada de um n individual. A autonomia pode ser aplicada ao projeto, comunicao e execuo. A autonomia de projeto refere-se independncia do uso do modelo de dados e tcnicas de gerenciamenro de transao entre ns. A autonomia de comunicao determina a extenso qual cada n pode decidir so-bre o compartilhamento de informaes com outros ns. A autonomia de execuo refere-se independn-cia dos usurios para aruarem conforme desejarem.

25.1.4 Confiabilidade e disponibilidade Confiabilidade e disponibilidade so duas das

vantagens em potencial mais comuns citadas para ban-cos de dados distribudos. A confiabilidade definida em termos gerais como a probabilidade de um siste-ma estar funcionando (no parado) em certo ponto no tempo, enquanto a disponibilidade a probabilidade de que o sistema esteja continuamente disponvel du-rante um intervalo de tempo. Podemos relacionar di-retamente confiabilidade e disponibilidade do banco de dados aos defeitos, erros e falhas associadas a ele. Uma falha pode ser descrita como um desvio de um comportamento do sistema daquele especificado a fim de garantir a execuo correta das operaes. Erros constituem o subconjunto de estados do sistema que causam a falha. Falha a causa de um erro.

Para construir um sistema que seja confivel, po-demos adorar vrias tcnicas. Uma tcn ica comum enfatiza a tolerncia a correes; ela reconhece que as falhas ocorrero, e projeta mecanismos que po-dem detectar e remover fa lhas antes que elas possam resultar em uma fa lha do sistema. Outra tcnica mais rigorosa tenta garantir que o sistema final no ter falha alguma. Isso feito por meio de um processo de projeto abrangente, seguido por controle de qualida-de e teste abrangentes. Um SGBDD confivel tolera fa lhas dos componentes bsicos e processa solicita-es do usurio desde que a coerncia do banco de dados no seja violada. Um gerenciador de recupera-o do SGBDD precisa lidar com falhas que surgem de transaes, hardware e redes de comunicao. As falhas de hardware podem ser aquelas que resul-tam em perda do contedo da memria principal ou perda de contedo do armazenamenro secundrio. As falhas de comunicao ocorrem devido a erros as-sociados a mensagens e falhas na linha. Os erros de mensagem podem incluir sua perda, adulterao ou chegada fora de ordem no destino.

25.1.5 Vantagens dos bancos de dados distribudos

As organizaes lanam mo do gerenciamemo de banco de dados distribudo por diversos motivos. Algumas vantagens importantes so listadas a seguir.

1. Maior facilidade e fl exibilidade de desenvol-vimento da aplicao. O desenvolvimento e a manuteno de aplicaes em sites geografi-camente distribudos de uma organizao so facilitados devido transparncia da distri-buio e controle de dados.

2. Maior confiabilidade e disponibilidade. Isso obtido pelo isolamento de falhas ao seu site de origem, sem afetar os outros bancos de dados conectados rede. Quando os da-dos e o software de SGBDD so distribudos por vrios sites, um destes pode apresentar fa lha enquanto outros continuam a operar. Apenas os dados e software que existem no site defeituoso no podero ser acessados. Isso melhora tanto a confiabilidade quanto a disponibilidade. Uma melhoria ainda maior obtida pela devida replicao dos dados e software em mais de um sire. Em um sistema centralizado, uma fa lha em um nico site tor-na o sistema inteiro indisponvel a todos os usurios. Em um banco de dados distribudo, alguns dos dados podem ficar inalcanveis, mas os usurios ainda podem ser capazes de acessar outras partes do banco de dados. Se os dados no site que apresentou falha tiverem sido duplicados em outro site antes da falha, ento o usurio no ser aferado de forma alguma.

3. Maior desempenho. Um SGBD distribudo fragmenta o banco de dados ao manter os dados mais prximos de onde eles so mais necessrios. A localizao de dados reduz a disputa pela CPU e servios de E/S e, ao mesmo tempo, reduz os atrasos no acesso envolvidos nas redes remotas. Quando um banco de dados grande distribudo por v-rios sites, existem bancos de dados menores em cada site. Como resultado, consultas e transaes locais que acessam dados em um nico site possuem melhor desempenho por causa dos bancos de dados locais menores. Alm disso, cada site tem um nmero menor de transaes executando do que se rodas as transaes fossem submetidas a um nico banco de dados centralizado. Ainda, o para-lelismo entre consultas e dentro da consulta pode ser alcanado ao executar vrias con-

sultas em diferentes sites, ou ao desmembrar uma consulta em uma srie de subconsultas executadas em paralelo. Isso contribui para melhorar o desempenho.

4. Expanso mais fcil. Em um ambiente distri-budo, a expanso do sistema em matria de incluso de mais dados, aumento dos tama-nhos do banco de dados ou incluso de mais processadores muito mais fcil.

As transparncias que discutimos na Seo 25 .1.2 levam a um comprometimento entre a facilidade de uso e o custo de overhead da proviso da transparn--cia. A transparncia total oferece ao usurio global uma viso do SBDD inteiro como se fosse um ni-CO sistema centralizado. A transparncia forneci -da como um complemento autonomia, que d aos usurios um controle mais estrito sobre os bancos de dados locais. Os recursos de transparncia podem ser implementados como uma parte da linguagem do usurio, que pode traduzir os servios requisitados em operaes apropriadas. Alm disso, a transparncia afeta os recursos que devem ser fornecidos pelo siste-ma operacional e pelo SGBD.

25.1.6 Funes adicionais dos bancos de dados distribudos

A distribuio leva a uma maior complexidade no projeto e implementao do sistema. Para conse-guir as vantagens em potencial j listadas, o software de SGBDD precisa ser capaz de oferecer as seguintes funes, alm daquelas de um SGBD centrazado:

Acompanhar a distribuio de dados. A ca-pacidade de acompanhar a distribuio de dados, fragmentao e replicao ao expan-dir o catlogo do SGBDD.

Processamento de consulta distribudo. A ca-pacidade de acessar sites remotos e t ransmi-tir consul tas e dados entre os vrios s ites por meio de uma rede de comunicao.

Gerenciamento de transao distribudo. A capacidade de criar estratgias de execu-o para consultas e transaes que acessem dados de mais de um site e de sincronizar o acesso aos dados distribudos, mantendo a integridade do banco de dados geral.

Gerenciamento de dados replicado. A capaci-dade de decidir qual cpia de um item de dados replicado acessar e de manter a consistncia das cpias de um item de dados replicado.

Recuperao de banco de dados distribudo. A capacidade de recuperar-se de falhas no si te

Capitulo 25 Bancos de dados distribudos 593

individual e de novos tipos de falhas, como a dos links de comunicao.

Segurana. As rransaes distribudas pre-cisam ser executadas com o gerenciamenro apropriado da segurana dos dados e dos pri-vilgios de autorizao/acesso dos usurios.

Gerenciamento de diretrio (catlogo) dis-tribudo. Um diretrio contm informaes (metadados) sobre os dados no banco de da-dos. O diretrio pode ser global, para o BDD inteiro, ou local para cada site. O posiciona-mento e a distribuio do diretrio so ques-tes de projeto e diretriz.

Essas prprias fun es aumentam a complexidade de um SGBDD em relao a um SGBD centralizado. Antes que possamos observar todas as vantagens em potencial da distribuio, temos de encontrar solu-es satisfatrias para essas questes e problemas de projeto. difci l conseguir a incluso de roda essa funciona lidade adicional, e encontrar solues ideais um passo alm.

25.2 Tipos de sistemas de bancos de dados distribudos

O termo sistema de gerenciamento de banco de dados distribudo pode descrever diversos sistemas que diferem um do outro em muitos aspectos. O item principal que todos os sistemas tm em comum o faro de os dados e software serem distribudos por vrios sites conectados por a lguma forma de rede de comunicao. Nesta seo, discutimos uma s-rie de tipos de SGBDDs e os critrios e fatores que tornam alguns desses sistemas diferentes.

O primeiro faror que consideramos o grau de homogeneidade do software de SGBDD. Se todos os servidores (ou SGBDs locais individuais) usarem software idntico e rodos os usurios (clientes) uti-lizarem software idntico, o SGBDD chamado de homogneo; caso contrrio, ele chamado de hetero-gneo. Outro fator relacionado ao grau de homoge-neidade o grau de autonomia local. Se no houver proviso para o sitc local funcionar como um SGBD independente, ento o sistema no tem autonomia local. Contudo, se o acesso direto por rransaes lo-cais a um servidor for permitido, o sistema rem al-gum grau de autonomia local.

A Figura 25.2 mostra a classificao das alterna-tivas do SGBDD junto com eixos ortogonais de distri-buio, autonomia e heterogeneidade. Para um ban-co de dados centralizado, existe autonomia completa, mas uma total falta de distribuio e heterogeneidade (Ponto A na figura). Vemos que o grau de autonomia


Distribuio

O B I

I I

I. I. I I I

I I I I I I I

I I I I I I I I

I I 1 I I 1 I I

I I I I I I 1 I

I I I I I

I I

I

I I I

J--i-1-----,:..---r1:..--

geneidade semntica que deve ser resolvida em um SBDF heterogneo.

Diferenas nos modelos de dados. Os bancos de dados em uma organizao vm de uma srie de modelos de dados, incluindo os cha-mados modelos legados (hierrquicos e de rede, ver apndices D e E na Web), o modelo de dados re lacional, o modelo de dados de objero e at mesmo arquivos. As capacidades de modelagem variam. PortantO, lidar com os modelos uniformemente por meio de um nico esquema global ou process-los em uma nica linguagem algo desafiador. Mes-mo que dois bancos de dados sejam ambos do ambiente do SGBDR, a mesma informa-o pode ser representada como um nome de atributo, como um nome de relao ou como um valor em bancos de dados diferentes. Isso exige um mecanismo inteligente de processa-mento de consulta, que possa relacionar in-formaes com base nos metadados.

Diferenas nas restr ies. As facilidades de restrio para a especificao e a implementa-o variam de um sistema para outro. Existem recursos comparveis que devem ser reconci-liados na construo de um esquema global. Por exemplo, os relacionamentos dos mode-los ER so representados como restries de integridade referencial no modelo relacional. Triggers podem precisar ser usados para im-plementar certas restries no modelo relacio-nal. O esquema global tambm deve lidar com conflitos em potencial entre as restries.

D iferenas nas linguagens de consulta . At com o mesmo modelo ele dados, as linguagens e suas verses variam. Por exemplo, a SQL tem diversas verses, como SQL-89, SQL-92, SQL-99 e SQL:2008, e cada sistema tem o prprio conjunto de tipos de dados, operado-res de comparao, recursos de manipulao de string etc.

Heterogeneidade sem ntica. A heterogeneidade semntica ocorre quando existem diferenas no signi-ficado, interpretao e uso intencionado dos mesmos dados ou dados relacionados. A heterogeneidade se-mntica entre os sistemas de banco de dados (SBDs) componentes cria o maior obstculo no projeto de esquemas globais de bancos de dados heterogneos. A autonomia de projeto dos SBDs componentes refe-re-se a sua liberdade de escolher os seguintes parme-tros de projeto, que, por sua vez, afetam a eventual complexidade do SBDF:


O universo de discurso do qual os dados so re-tirados. Por exemplo, para duas contas de clien-te, os bancos de dados na federao podem ser dos Estados Unidos e do Japo e ter conjuntos de atributos totalmente diferentes sobre comas de clienre, exigidos pelas prticas contbeis. Flutuaes de taxa de cmbio tambm apresen-tam um problema. Logo, as relaes desses dois bancos de dados que possuem nomes idnticos - CLIENTE ou CONTA - podem ter algu-mas informaes comuns e outras totalmente distintas.

Representao e nomeao. A representao e a nomeao dos elementos de dados e da estrutura do modelo de dados podem ser pre-viamente especificadas para cada banco de dados local.

O conhecimento, significado e interpretao subjetiva dos dados. Essa uma contribuio importante para a heterogeneidade semntica.

Restries de transao e de di retriz. Lidam com critrios de serial izao, transaes de compensao e outras diretrizes de transao.

D erivao de resumos. Agregao, resumo e outros recursos e operaes de processamen-to de dados admitidos pelo sistema.

Esses problemas relacionados heterogeneidade semntica esto sendo encarados por todas as princi-pais organizaes multinacionais e governamentais em todas as reas de aplicao. No ambiente comercial de hoje, a maioria das empresas est lanando mo de SBDFs heterogneos, investindo pesado no desenvol-vimento de sistemas de banco de dados individuais, usando diversos modelos de dados em diferentes pla-taformas nos ltimos 20 a 30 anos. As empresas esto uti lizando diversas formas de software- normalmen-te chamado de middleware, ou pacotes baseados na Web, chamados servidores de aplicao (por exemplo, WebLogic ou WebSphere), e at mesmo sistemas gen-r icos, chamados sistemas de Enterprise Resource Plan-ning (ERP) (por exemplo, SAP, J . D. Edwards ERP)-para gerenciar o transporte de consultas e transaes da aplicao global para bancos de dados individuais (com possvel processamento adicional para regras de negcios) e os dados dos servidores de banco de dados heterogneos para a aplicao global. Uma discusso detalhada desses tipos de sistemas de software est fora do escopo deste livro.

Assim como oferecer a transparncia definitiva o objerivo de qualquer arquitetura de banco de dados distribudo, os bancos de dados componentes locais lutam para preservar a autonomia. A autonomia de


comunicao de um SBD componente refere-se a sua capacidade de decidir se ir se comunicar com outro SBD componente. A autonomia da execuo refere-se capacidade de um SBD componente executar ope-raes locais sem interferncia das operaes exter-nas por outros SBDs componentes e sua capacidade de decidir a ordem em que sero executadas. A au-tonomia da associao de um SBD componente im-plica que ele tem a capacidade de decidir se e quanto compartilhar de sua funcionalidade (operaes que ele suporta) e recursos (dados que ele gerencia) com outros SBDs componentes. O maior desafio do pro-jeto de SBDFs permitir que os SBDs componenres interoperem enquanto ainda lhes fornecem os tipos de autonomias apresentados anteriormente.

25.3 Arquiteturas de banco de dados distribudas

Nesta seo, primeiro mostramos rapidamente a distino entre arquiteruras de banco de dados pa-ralela e distribuda. Embora ambas estejam bastante presentes na indstria hoje, existem diversas mani-festaes das arquiteturas distribudas que esto con-tinuamente evoluindo enrre as grandes empresas. A arquitetura paralela mais comum na computao de alto desempenho, em que h uma necessidade de arquiteturas multiprocessadoras para enfrentar ovo-lume de dados passando por aplicaes de processa-mento de transao e warehousing. Depois, apresen-tamos a arquitetura genrica de um banco de dados distribudo. Isso seguido por discusses sobre a arquitetura dos sistemas de banco de dados de trs camadas clienre-servidor e federados.

25.3.1 Arquiteturas paralelas versus distribudas

Existem dois tipos principais de arquiteturas de sis-tema multiprocessador que so comumente utilizados:

Arqui tetura de memria compartilhada (al-tamente acoplada). Mltiplos processadores compartilham armazenamento secundrio (disco) e tambm memria principal.

Arquitetura de disco compartilhado (livre-mente acoplada). Mltiplos processadores compartilham armazenamento secundrio (disco), mas cada um tem a prpria memria principal.

Essas arquiteturas permitem que os processado-res se comuniquem sem o overhead de trocar men-sagens por uma rede.4 Os sistemas de gerenciamento

de banco de dados desenvolvidos que utilizam esses tipos de arquiteturas so chamados de sistemas de gerenciamento de banco de dados paralelos, em vez de SGBDDs, pois utilizam a tecnologia de processa-dores paralelos. Outro tipo de arquitetura de multi-processador chamado de arquitetura nada compar-t ilhado. Nessa arquitetura, cada processador tem a prpria memria principal e secundria (disco), no existe memria comum e os processado res se comu-nicam por uma rede de interconexo de alta veloci-dade (barramento ou switch). Embora a arquitetura nada comparti lhado seja semelhante a um ambiente de computao de banco de dados distribudo, exis-tem diferenas importantes no modo de operao. Nos sistemas de multiprocessador nada comparti-lhado, h simetria e homogeneidade de ns; isso no acontece no ambiente de banco de dados distribudo, no qual a heterogeneidade do hardware e do sistema operacional cm cada n muito comum. A arquite-tura nada compartilhado tambm considerada um ambiente para bancos de dados paralelos. A Figu-ra 25.3a ilustra um banco de dados paralelo (nada compartilhado), enquanto a Figura 25.3b ilustra um banco de dados centralizado com acesso distribudo e a Figura 25.3c mostra um banco de dados distri-budo puro. No vamos nos aprofundar aqui nas ar-quireruras paralelas e em questes de gerenciamento de dados relacionadas.

25.3.2 Arquitetura geral de bancos de dados distribudos puros

Nesta seo, discutimos os modelos arquiteturais lgicos e de componente de um BDD. Na Figura 25.4, que descreve a arquitetura de esquema genrico de um BDD, a empresa apresentada com uma viso consis-tente, unificada, que mostra a estrutura lgica dos da-dos bsicos por todos os ns. Essa viso representa-da pelo esquema conceituai global (ECG), que oferece transparncia de rede (ver Seo 25.1..2). Para acomo-dar a heterogeneidade em potencial no BDD, cada n aparece como tendo o prprio esquema interno local (EIL) com base nos detalhes da organizao fsica nes-se s ite em particular. A organizao lgica dos dados em cada site especificada pelo esquema conceituai lo-cal (ECL). O ECG, ECL e seus mapeamentos bsicos oferecem a transparncia de fragmentao e replicao discutida na Seo 25.1.2. A Figura 25.5 mostra a ar-quitetura componente de um BDD. Ela uma extenso de sua correspondente centralizada (Figura 2.3) doCa-ptulo 2. Para simplificar, os elementos comuns no so mostrados aqui. O compilador de consulta global refe-rencia o esquema conceituai global com base no catlo-

Se as memrias principal e secundria forem compartillladas. a arquitetura tambm conhecida como arquitetura tudo compartilhado.


(a) Sistema de computao 1 Sistema de computao 2

I CPU I BD I CPU L BD I Memria I Memria !

I Switch

I Sistema de computao n

I CPU ~ BD Memria

(b) Site Central

1-BD1 (Brasilia) BD2

Si te l Si te (Belo Horizonte) (So Paulo)

Rede de comunicaes

Site Site (Rio de Janeiro) (Curitiba)

(c)

I Site 5 r I

H Site 4 l Site 1 -Rede de

comunicaes

H Site 3 Site 2 f-

Figura 25.3 Algumas arquiteturas de sistema de banco de dados diferentes. (a) Arquitetura nada compartilhado. (b) Uma arquitetura em rede com um banco de dados centralizado em um dos sites. (c) Uma arquitetura de banco de dados verdadeiramente distribuda.

go global do sistema para verificar e impor as restries defin idas. O otimizador de consulta global referencia os esquemas conceituais globais e locais e gera consul-tas locais otimizadas com base nas consultas globais. Ele avalia rodas as estratgias candidatas usando uma funo de custo que estima o custo com base no tempo de resposta (CPU, fJS e latncias de rede) e tamanhos estimados de resultados intermedirios. O ltimo par-ticularmente importante em consultas que envolvem junes. Aps calcular o custo para cada candidato, o orimizador seleciona o candidato com o menor custo para execuo. Cada SGBD local teria seu otimizador de consulta local, gerenciador de transao e mecanis-

mos de execuo, bem como o catlogo do sistema lo-cal, que abriga os esquemas locais. O gerenciador de transao global responsvel por coordenar a execu-o por vrios sites em conjunto com o gerenciador de transao local nesses sires.

25.3.3 Arquitetura do esquema de banco de dados federado

A arquitetura tpica do esquema de cinco niveis para dar suporte a aplicaes globais no ambiente de SBDF aparece na Figura 25 .6. Nessa arquitetura, o esquema local o esquema conceituai (definio de


Usurio Usurio

t Viso Viso

externa '.. / externa Esquema conceituai global (ECG)

/ '.. Esquema conceituai local (ECL) Esquema conceituai local (ECL)

t Esquema interno local (EIL) Esquema interno local (E I L)

!"" ......_

!"" ......,

I' / '- /

Dados Dados ~rmazenados armazenados

v ......_ !"" ......_ ...... / ...... /

Site 1 Sites 2 a n - 1 Site n

Figura 25.4 Arquitetura do esquema para bancos de dados distribudos.

banco de dados completa) de um banco de dados componente, e o esquema d e componente deriva-do ao se traduzir o esquema local para um modelo de dados cannico ou um modelo de dados comum (MDC) para o SBDF. A traduo de esquema de um esquema local para o esq uema componente acompanhada pela gerao de mapea mentos para transformar comandos em um esquema componen-te em comandos no esquema local correspondente. O esquema de exportao representa o subconjun-to de um esquema componente que est dispon-vel ao SBDF. O esquema federado o esquema ou viso globa l, que o resultado da integrao de todos os esquemas de exportao compartilhveis. Os esq uemas externos d efinem o esquema para um grupo de usurios ou uma aplicao, assim como na arquitetura de esquema em trs nveis.5

T odos os problemas relacionados ao processa-mento de consulta, processamento de transao e ge-renciamento e recuperao de diretrio e metadados se aplicam aos SBDFs com consideraes adicionais. No est em nosso escopo discutir esses problemas com detalhes aqui.

25.3.4 Viso geral da arquitetura cliente--servidor de trs camadas

Conforme indicado na introduo do captulo, os SGBDDs em escala completa no foram desenvol-vidos para dar suporte a todos os tipos de funciona-lidades discutidos at aqui. Em vez disso, aplicaes de banco de dados distribudo esto sendo desenvol-vidas no contexto das arquiteturas cliente-servidor. Apresentamos a arquitetura cliente-servidor de duas camadas na Seo 2.5. Agora, mais comum usar uma arq

sistema de banco de dados - pearson.pdf

Documents