Segurana em Banco de Dados

Arthur Henrique Atade de Azevedo Edkarla Andrade de Castro Paulo Roberto de Lima Serro

Segurana em Banco de Dados

Aspectos Gerais de segurana; Evitar violao de consistncia dos dados; Segurana de acesso(usurios e aplicaes); Segurana contra falhas(recovery); Manuteno de histrico de atualizaes backups do BD;
(Log) e

Segurana em Banco de Dados

Segurana com Banco de dados livres (mysql); Segurana com Banco de dados proprietrios (Oracle);

Consequencias de no ter um ambiente seguro; Recomendaes para um ambiente seguro; Referncias.

Aspectos Gerais de Segurana

Porque devemos ter segurana em um Banco de Dados?
Possuir informao hoje ganhar agilidade, competitividade, previsibilidade, dinamismo, portanto, possuir informao o mesmo que possuir um diferencial, uma vantagem competitiva.

Uma informao til pode ser usada a favor ou contra voc ou sua empresa. Por isso importante que se possua informaes corretas e uma forma eficiente de proteg-las, j que se algum dado crtico for alterado, destrudo, ou divulgado sem autorizao pode acarretar em prejuzos tanto para a empresa ou instituio, como para seus clientes ou usurios.

Aspectos Gerais de Segurana

Os princpios da segurana da informao so:

confidencialidade: garantia de que a informao acessvel somente por pessoas autorizadas a terem acesso;

integridade: a informao alterada somente pelas pessoas autorizadas;

disponibilidade: garantia de que as pessoas autorizadas obtenham acesso informao e aos ativos correspondentes sempre que necessrio.

Dessa forma, garantir a segurana da informao fazer com que as informaes permaneam confidenciais, integras e disponveis para a pessoa certa na hora certa.

Aspectos Gerais de Segurana

De acordo com SMOLA (2003, p.12), os principais motivos para se proteger uma informao so :
o seu valor, o impacto de sua ausncia, o impacto resultante de seu uso por terceiros, a importncia de sua existncia e a relao de dependncia com a sua atividade, e a informao deve ser protegida em todo o seu ciclo de vida, desde sua criao, manuseio, armazenamento transporte e descarte.

Os SGBDs para garantir a segurana das informaes, devem possuir controles de redundancia, concorrencia e a capacidade de manter os dados integros, aplicando as restries de integridade.

Controle de Redundncia

A redundncia caracterizada pela presena de um elemento de informao duplicado. Sistemas de banco de dados devem ter capacidade de garantir que os dados no sejam redundantes. Esse controle usualmente conhecido como integridade referencial. O controle de redundncia no permite incluir dois registros com a mesma chave primria e excluir um registro que possua relacionamento com outras tabelas (chave estrangeira). Com isto, o controle de redundncia evita a inconsistncia de dados. Este padro de integridade o fundamento do modelo relacional, por isso necessrio que o banco de dados tenha a capacidade de gerenciar o controle de redundncia.

Controle de Concorrncia

um esquema usado para garantir que as transaes so executadas de forma segura.

Uma das qualidades dos sistemas desenvolvidos a multiprogramao que permite a execuo de diversas transaes visando o compartilhamento do processador. Nesse ambiente multiprogramado diversas transaes podem executar concorrentemente. Por isso os sistemas precisam controlar a interao entre transaes concorrentes com o objetivo de prevenir a violao da consistncia do banco de dados.

Esse controle feito por um conjunto de mecanismos definidos como esquemas de controle de concorrncia. Quando as transaes so executadas concorrentemente a consistncia do banco pode ser violada mesmo que cada transao individual esteja correta.
Cabe ressaltar que nesse ambiente importante o conceito da seriabilidade. necessrio que qualquer escalonamento produzido ao se processar um conjunto de transaes concorrentemente seja computacionalmente equivalente a um escalonamento produzindo executando essas transaes serialmente em alguma ordem.

Diz-se que um sistema que garante esta propriedade assegura a seriabilidade.

Controle de Concorrncia

Os escalonamentos podem ser seriais e no-seriais. Escalonamentos seriais consistem de uma seqncia de instrues de vrias transaes onde as instrues pertencentes a uma nica transao aparecem juntas. No escalonamento no serial as operaes de uma transao so executadas intercaladas com operaes de outra transao. Os mecanismos de controle de concorrncia so classificados em mecanismos otimistas e pessimistas. Os mecanismos de controle de concorrncia pessimistas so aqueles que buscam impedir antecipadamente os tipos de acesso concorrente a dados que podem gerar inconsistncias. Isso pode ser feito bloqueando temporariamente o acesso de dados a algumas aplicaes enquanto outra est acessando. Os mecanismos de controle de concorrncia otimistas, ao invs de tentar evitar antecipadamente acessos inconsistentes permitem o livre acesso. No final da execuo das aplicaes iniciado um processo que examina a incidncia de inconsistncia nos dados graas ao acesso concorrente.

Restrio de Integridade

As restries de integridade oferecem meios de assegurar que mudanas feitas no banco de dados por usurios autorizados no resultem em perda de consistncia dos dados. As restries de integridade podem resguardar o banco de dados contra danos acidentais. Uma restrio de integridade pode ser um predicado arbitrrio que reaplica ao banco de dados. No entanto, os predicados arbitrrios podem ser custosos para testes. Dessa forma preciso limitar-se em restries de integridade que possam ser testadas com um mnimo custo adicional. A forma mais elementar de restrio de integridade a restrio de domnio. Em um sistema possvel que diversos atributos tenham um mesmo domnio. A definio de restrio de domnio no somente permite testar os valores inseridos no banco de dados como possibilita testar as consultas assegurando que as comparaes faam sentido.

Restrio de Integridade

A integridade referencial usada para garantir que um valor que aparece em uma relao para um dado conjunto de atributos tambm aparea para um certo conjunto de atributos em outra relao. No modelo E-R (Entidade Relacionamento), o esquema do banco de dados relacional derivado de diagramas E-R resulta em um conjunto de relacionamentos que possui regras de integridade referencial. Outro ponto de origem de restries de integridade referencial so os conjuntos de entidades fracas. Isto porque o esquema relacional para cada conjunto de entidades fracas inclui uma chave estrangeira que leva a uma restrio de integridade referencial. As modificaes em banco de dados podem violar as regras de integridade referencial.

Evitar violao de consistncia dos dados

Para evitar a violao dos dados e garantir a consistncia, confiabilidade, podemos adotar algums mecanismos de segurana entre esses mecanismos podemos destacar:

Mecanismos de controles fisicos

portas / trancas / paredes / blindagem /etc...

Mecanismos de controles lgicos

Mecanismos de criptografia Assinatura digital Mecanismos de garantia da integridade da informao Mecanismos de controle de acesso e etc...

Dentre os mecanismos de controle lgico, vamos destacar a criptografia.

Criptografia

A Criptografia a tcnica pela qual a informao pode ser transformada da sua forma original para outra ilegvel, de forma que possa ser conhecida apenas por seu destinatrio, o que a torna difcil de ser lida por algum no autorizado. Assim sendo, s o receptor da mensagem pode ler a informao com facilidade.

A criptografia principais :

tem

quatro

objetivos

confidencialidade da mensagem: s o destinatrio autorizado deve ser capaz de extrair o contedo da mensagem da sua forma cifrada. Alm disso, a obteno de informao sobre o contedo da mensagem (como uma distribuio estatstica de certos caracteres) no deve ser possvel, uma vez que, se o for, torna mais fcil a anlise criptogrfica. integridade da mensagem: o destinatrio dever ser capaz de determinar se a mensagem foi alterada durante a transmisso. autenticao do remetente: o destinatrio dever ser capaz de identificar o remetente e verificar que foi mesmo ele quem enviou a mensagem. no-repdio ou irretratabilidade do emissor: no dever ser possvel ao emissor negar a autoria da mensagem.

Criptografia

Nem todos os sistemas ou algoritmos criptogrficos so utilizados para atingir todos os objetivos listados acima. Normalmente, existem algoritmos especficos para cada uma destas funes. Mesmo em sistemas criptogrficos bem concebidos, bem implementados e usados adequadamente, alguns dos objetivos acima no so prticos (ou mesmo desejveis) em algumas circunstncias. Por exemplo, o remetente de uma mensagem pode querer permanecer annimo, ou o sistema pode destinar-se a um ambiente com recursos computacionais limitados. Tipos de Criptografia, MD2, MD4, SHA, Hash, MD5, MD6 (no utilizavl). Os mais indicados e comuns so o MD5, o SHA e o Hash

Criptografia

MD5 (Message-Digest algorithm 5) um algoritmo de hash de 128 bits unidirecional desenvolvido pela RSA Data Security, Inc., descrito na RFC 1321, e muito utilizado por softwares com protocolo ponto-a-ponto (P2P, ou Peer-to-Peer, em ingls) na verificao de integridade de arquivos e logins. Foi desenvolvido em 1991 por Ronald Rivest para suceder ao MD4 que tinha alguns problemas de segurana. Por ser um algoritmo unidirecional, uma hash md5 no pode ser transformada novamente no texto que lhe deu origem. O mtodo de verificao , ento, feito pela comparao das duas hash (uma da mensagem original confivel e outra da mensagem recebida). O MD5 tambm usado para verificar a integridade de um arquivo atravs, por exemplo, do programa md5sum, que cria a hash de um arquivo. Isto pode-se tornar muito til para downloads de arquivos grandes, para programas P2P que constroem o arquivo atravs de pedaos e esto sujeitos a corrupo dos mesmos. Como autenticao de login utilizada em vrios sistemas operacionais unix e em muitos sites com autentificao.

Criptografia

SHA (Secure Hash Algorithm) est relacionada com as funes criptogrficas. A funo mais usada nesta famlia, a SHA-1, usada numa grande variedade de aplicaes e protocolos de segurana, incluindo TLS, SSL, PGP, SSH, S/MIME e IPSec. SHA-1 foi considerado o sucessor do MD5. Ambos tm vulnerabilidades comprovadas. Em algumas correntes, sugerido que o SHA-256 ou superior seja usado para tecnologia crtica. Os algoritmos SHA foram desenhados pela National Security Agency (NSA) e publicados como um padro do governo Norte-Americano. O primeiro membro da famlia, publicado em 1993, foi oficialmente chamado SHA; no entanto, frequentemente chamado SHA-0 para evitar confuses com os seus sucessores. Dois anos mais tarde, SHA-1, o primeiro sucessor do SHA, foi publicado. Desde ento quatro variantes foram lanadas com capacidades de sada aumentadas e um design ligeiramente diferente: SHA-224, SHA256, SHA-384, e SHA-512 por vezes chamadas de SHA-2 .

Segurana de acesso
(usurios e aplicaes)
A preocupao com a criao e manuteno de ambientes seguros tm sido tarefas cruciais de administradores de redes, de sistemas operacionais e de bancos de dados. Pesquisas mostram que boa parte dos ataques, roubos de informaes e acessos no-autorizados so feitos por pessoas que pertencem organizao alvo. Isso faz com que estes profissionais se desdobrem para criar e usar artifcios para eliminar os acessos no-autorizados ou minimizar as chances de sucesso das tentativas de invaso (internas ou externas). Os controles de acesso em sistemas de informao devem assegurar que todos os acessos diretos ao sistema ocorram exclusivamente de acordo com as modalidades e as regras pr-estabelecidas, e observadas por polticas de proteo.

Segurana de acesso
(usurios e aplicaes)

A figura abaixo apresenta um sistema de controle de acesso incluindo assuntos (usurios e processos) que alcanam objetos (dados e programas) com as operaes (ler, escrever e executar).

Segurana de acesso
(usurios e aplicaes)
A figura mostra um sistema de controle de acesso composto basicamente de dois componentes:

as Polticas de Acesso, que indica as modalidades e tipos de acesso a serem seguidas, e os Procedimentos de Acesso, que, com base nas regras de acesso, os pedidos de acesso podem ser permitidos, negados ou podem ser pedidas modificaes no pedido de acesso.

Grande parte dos SGBDs atuais controla o acesso aos dados armazenados atravs de Listas de Controle de Acesso (Access Control List, ACL) . As ACLs so tabelas especiais que possuem informaes sobre os privilgios que cada usurio pode ter em determinado banco de dados.

Segurana de acesso
(usurios e aplicaes)

Quando um usurio se conecta ao banco de dados sua identidade determinada pela mquina de onde ele conectou e o nome de usurio que ele especificou. O sistema concede privilgios de acordo com sua identidade e com o que ele deseja fazer. Assim possvel que usurios provenientes de diferentes lugares da internet possuam o mesmo nome de usurio e privilgios totalmente diferentes um do outro. O controle de acesso feito em duas etapas: primeiramente o servidor confere se voc pode ter acesso ou no, em seguida, assumindo que voc pode conectar, o servidor verifica cada requisio feita para saber se voc tem ou no privilgios suficientes para realizar a operao. Por exemplo, se voc tentar selecionar linha de uma tabela em um banco de dados ou apagar uma tabela do banco de dados, o servidor se certifica que voc tem o privilgio select para a tabela ou o privilgio drop para o banco de dados.

SQL injection
O que ?
A Injeo de SQL, mais conhecida atravs do termo americano SQL Injection, um tipo de ameaa de segurana que se aproveita de falhas em sistemas que interagem com bases de dados via SQL. A injeo de SQL ocorre quando o atacante consegue inserir uma srie de instrues SQL dentro de uma consulta (query) atravs da manipulao das entrada de dados de uma aplicao.

SQL injection

Para ilustrar o conceito de SQL Injection, a seguinte simulao pode ser realizada. Imaginemos que um script de validao de acesso de usurios tenha sido desenvolvido como segue:

Nas linhas 3 e 4, as variveis $usuario e $senha, respectivamente, recebem o contedo submetido por um formulrio atravs do mtodo POST. Eis a fonte do problema. Suponha que a seguinte entrada tenha sido informada no campo usurio no formulrio chamador do script de validao.

SQL injection

Logo, a query string resultante ser:

Se nenhuma outra validao for realizada, o usurio mal intencionado ter efetuado login no sistema, sem ao menos informar um usurio contido na tabela. Isto foi possvel pois o valor de entrada informado no recebeu o tratamento devido, sendo adicionado instruo para ser executado. Vale ressaltar que as validaes apresentadas no exemplo so apenas ilustrativas, havendo a necessidade de checagens mais eficazes para um script de validao de acesso.

SQL injection
Impossibilitando o uso de SQL Injection

Para que se esteja livre da utilizao da SQL Injection, certas providncias devem ser tomadas. Algumas das aes sero realizadas no servidor de banco de dados, outras devem ser garantidas pelo cdigo fonte. Deve-se tomar cuidado com a configurao do usurio que estabelece a conexo com o banco de dados. O ideal que as permisses de acesso deste usurio estejam restritamente limitadas s funes que ir realizar, ou seja, para a exibio de um relatrio, a conexo com o banco de dados deve ser realizada por um usurio com permisses de leitura e acesso somente s tabelas necessrias para sua operao.

SQL injection

Todos os valores originados da coleta de dados externos, devem ser validadas e tratadas a fim de impedir a execuo de eventuais instrues destrutivas ou operaes que no sejam as esperadas. Um tratamento bsico para a execuo de querys com variveis contendo valores informados pelo usurio:

SQL injection

Com a utilizao da funo addslashes() ser adicionada uma barra invertida antes de cada aspa simples e aspa dupla encontrada, processo conhecido como escape. Se a diretiva de configurao do PHP magic_quotes_gpc estiver ativada, o escape realizado automaticamente sobre os dados de COOKIES e dados recebidos atravs dos mtodos GET e POST. Neste caso, no deve ser efetuado o tratamento com addslashes(). A funo get_magic_quotes_gpc(), disponvel nas verses do PHP a partir da 3.0.6, retorna a configurao atual da diretiva magic_quotes_gpc. Abaixo, a query string resultante da aplicao do tratamento mencionado:

SQL injection

Em muitos bancos de dados, existem funes especficas para o tratamento de variveis em query strings, o que diminui a compatibilidade do cdigo fonte para operao com outros sistemas de banco de dados. Outra dica importante evitar a exibio das mensagem de erro em um servidor de aplicao em produo, pois geralmente nos erros ou alertas so exibidos caminhos de diretrios do sistema de arquivos e informaes respeito do esquema do banco de dados, podendo comprometer a segurana do sistema.

Segurana contra falhas (recovery)

A recuperao/tolerncia a falhas tem por objetivo restaurar o BD para um estado de integridade, aps a ocorrncia de uma falha; Os mecanismos de recuperao baseiam-se na utilizao de formas de redundncia que quase duplicam o BD, utilizando: Backup e transaction log

Manuteno de histrico de atualizaes(Log) e backups do BD

Os backups so cpias de segurana do BD, que so executados periodicamente e constituem um ponto de partida para a recuperao do BD aps a ocorrncia de uma falha, independentemente da sua gravidade; Refletem uma situao passada, donde a reposio a partir de um backup implica perder todas as atualizaes posteriores realizao do mesmo.

Manuteno de histrico de atualizaes(Log) e backups do BD

Uma forma de minimizar esta situao aumentando a periodicidade dos backups, o que um processo pesado, consumidor de recursos e que pode obrigar a paradas dos sistemas; A periodicidade dos backups depende do valor dos dados, do seu volume e da frequncia com que so acedidos e alterados;

Manuteno de histrico de atualizaes(Log) e backups do BD

O backup um mecanismo de reposio do BD. Os transaction logs so mecanismos de repetio das transaces ocorridas desde o ltimo backup (rollforward); Normalmente para se refazer uma transao necessrio o ficheiro de transaction log, onde est guardada uma identificao da transao e uma cpia dos dados atualizados por ela (after image);

Manuteno de histrico de atualizaes(Log) e backups do BD

Sendo esta a forma mais comum de resolver os problemas provocados por uma falha, tm que existir outros mecanismos que permitam o roll back das transaces no terminadas, ocorridos durante a execuo no sucedida das mesmas; Donde o ficheiro transaction log necessita igualmente de guardar os dados anteriores ao incio da execuo da transaco (beforeimages)

Manuteno de histrico de atualizaes(Log) e backups do BD

da conjugao destes dois mecanismos backups e transaction logs , que se garantem duas das caractersticas fundamentais das transaes: Atomicidade (desfazendo uma transao no sucedida) Persistncia (refazendo os efeitos de uma transao bem sucedida)

Tipo de Falhas
Falha de disco - o(s) disco(s) onde o BD est armazenado fica(m) inutilizado(s). a falha considerada mais grave e que obriga reconstruo de todo o SGBD; Falha de sistema - pode resultar de problemas de hardware ou software, no sendo possvel garantir a validade dos dados. Implica repor a BD a partir do seu ltimo estado de integridade.

Tipo de Falhas
Falha de transao - a mais inofensiva e recupera-se recorrendo ao ficheiro transaction log e s before images da transao que no foi bem sucedida.
Em qualquer processo de recuperao recorrese ao rollback das transaes efetuadas at ao momento em que os transaction log e os ficherios da base esto sincronizados, para se poderem desfazer todas as transaes decorridas desde ento.

Tipo de Falhas
Esse momento coincide com o ltimo backup, o qual se muito afastado no tempo, obriga a um processo moroso e complexo de recuperao do BD.
Tn Tn+1 Tn+2 Tn+3

ltimo backup

Falha de disco

Tipo de Falhas
Para evitar este tipo de situaes, recorrese a marcas de segurana, conhecidas por checkpoints. Basicamente, para reduzir o nmero de acessos aos discos, nos ficheiros de transaction log as atualizaes so realizadas na memria RAM, em buffers, sendo posteriormente escritos em disco;

Tipo de Falhas
Quando ocorre uma falha, o contedo desses buffers pode perder-se, ou pelo menos pode no existir uma garantia de validade do seu contedo; Assim os checkpoints registram os momentos em que o contedo dos buffers foi escrito nos discos, definindo-se um momento em que o transaction log e o BD esto sincronizados.

Tipo de Falhas

Tn

Tn+1

Tn+2 Tn+3

ltimo backup

Falha de Sistema

Auditoria em Banco de Dados

o conjunto de aes para verificar o que os usurios esto fazendo. Muitas empresas fazem isso para os fins de segurana. Isso para garantir que usurios no autorizados no esto acessando uma parte do banco de dados ou a estrutura principal que no permitida. A maioria das informaes crticas de uma empresa, 90% ou mais, mantida no banco de dados. por isso que a auditoria do banco de dados to crucial para a proteo da segurana. Se determinada informao comprometida, ela pode ser crtica para suas operaes.

Segurana em Banco de dados Livres (Mysql)

O MySQL sem dvida nenhuma, o banco de dados open source mais conhecido do mercado e provavelmente o mais utilizado. Ele rpido, simples, funcional e hoje implementa recursos que o colocam prximo a grandes nomes como Oracle. At pouco tempo um recurso extremamente til e que era fator que impedia utilizao em vrias empresas, o suporte transao. Desde o lanamento da verso MAX,o MySQL j d suporte a transaes, derrubando este impeclio sua utilizao. Mais tarde, com a introduo das tabelas InnoDB, o MySQL ganhou mais um poderoso recurso: integridade referencial. Assim o MySQL passa a implementar os principais conceitos que aprendemos nos livros sobre banco de dados, fazendo-o ser uma alternativa vivel para ser adotado no desenvolvimento de aplicativos.

Segurana no sistema (Mysql)

Antes mesmo de pensar como um administrador de banco de dados (DBA), devemos pensar na segurana do sistema. Algumas consideraes devem ser analisadas para evitar que, mesmo implementando controles de acessos a tabelas, banco de dados, o administrador seja surpreendido pela perda de dados pelo fato de algum ter "acidentalmente" apagado o repositrio do MySQL. Apesar de implementar um sistema de validao robusto, o MySQL no tem como controlar acessos que deveriam ser bloqueados pelo sistema operacional. Acesso a arquivos, permisses de usurios do sistema, ou mesmo do usurio sob o qual roda o servidor devem ser especialmente preparados para evitar que haja corrupo ou quebra da privacidade dos dados. Resumindo, apenas o banco de dados MySQL deve ter acesso aos arquivos de dados do MySQL.

Sistema de arquivos (Mysql)

Como j foi falado anteriormente, apenas o banco de dados deveria ter acesso aos arquivos onde so armazenados os dados. No mundo Linux, esta restrio bem simples de ser implementada, j que ele tem um esquema bem forte de autenticao que restringe o poder dos usurios do sistema. Apenas o usurio root no pode ter o acesso bloqueado, j que ele pode redefinir as restries estabelecidas. Para evitar qualquer tipo de problemas, apenas o usurio sob o qual o servidor vai rodar, deve ter acesso ao diretrio onde o MySQL guarda os arquivos de dados. Qualquer outro usurio deve ter o acesso a este diretrio bloqueado tanto para leitura como para escrita. O acesso de escrita deve ser bloqueado por motivos bvios: ningum, a no ser o prprio banco de dados deve escrever nos arquivos de dados.

Sistema de arquivos (Mysql)

J a permisso de leitura merece uma explicao mais detalhada.

Ao bloquear o acesso escrita nos arquivos do MySQL, garantimos que ningum poder fazer alteraes nos arquivos, porm no conseguimos garantir o sigilo destes dados. No preciso nem decifrar o contedo dos arquivos para ler os dados ali armazenados, basta pegar os arquivos e, em outra mquina copiar os arquivos no diretrio do MySQL e pronto. Voc tem acesso a tudo que o outro banco de dados guardou. Para preservar o sigilo nos dados portanto, o acesso de leitura tambm deve ser bloqueado para os outros usurios que no o responsvel pelo banco de dados.

Usurios do sistema (Mysql)

Para acessar o banco de dados, no necessrio criar uma conta no sistema operacional, pois o MySQL tem sua prpria estrutura de validao desvinculando os usurios do banco de dados dos usurios do sistema. O nico usurio do sistema que deve ter um tratamento especial o que possui o processo servidor. O MySQL, como qualquer processo no Linux possui um dono e conseqentemente ele vai ter os mesmos privilgios que este dono tem no sistema. Assim a poltica adotada para este usurio como em qualquer outra: a do menor privilgio. Se o servidor acessa s o banco de dados, por que dar poder ao dono do processo servidor para ler ou escrever arquivos externos ao banco de dados? Se o propsito do dono do banco de dados apenas fazer o servidor funcionar, por que dar acesso de login a ele?

Usurios do sistema (Mysql)

Existem algumas situaes que o admistrador deve dar acesso ao sistema de arquivos para o dono do banco de dados, pois algumas funes no MySQL precisam deste acesso (LOAD DATA por exemplo). Se este for o caso, o administrador deve ter o cuidado para no deixar aberto acesso a arquivos importantes. bvio, mas existem administradores que esquecem deste detalhe. Com um banco de dados preparado e um comando LOAD DATA possvel pegar, por exemplo, os dados do arquivo /etc/passwd para tentar obter as senhas dos usurios. Uma observao importante que o dono do banco de dados NUNCA deve ser o root. O motivo bvio: este usurio tem acesso a tudo, e acabamos de ver acima que este acesso indesejado extremamente perigoso ao sistema.

Usurios do sistema (Mysql)

Um administrador inexperiente poderia pensar que apenas o superusurio do sistema pode ter acesso ao banco de dados e assim ele estaria seguro, mas o que acontece que do outro lado, existe algum desconhecido que vai enviar uma consulta ao banco de dados que est funcionando como super-usurio e que pode fazer qualquer coisa. O ideal portanto que exista um usurio apenas para o banco de dados, sem direito a fazer mais nada que no seja manipular os dados do prprio banco de dados. Aplicando estes procedimentos no servidor, estaremos garantindo a integridade do sistema, pois o usurio dono do servidor MySQL no tem privilgios. Tambm garantimos o sigilo dos dados, pois nenhum outro usurio vai ter acesso aos arquivos do banco de dados. Assim estamos implementando segurana no MySQL antes mesmo de fazer o servidor MySQL funcionar.

Sistema de autenticao (MySQL)

O MySQL implementa um sistema de autenticao bastante robusto que realizado em dois estgios. O primeiro verifica se o usurio pode conectar ao banco de dados e o segundo verifica se o usurio tem privilgios para realizar operaes no banco de dados. O segundo estgio, portanto, verificado a cada operao realizada pelo usurio.

Este sistema de privilgios armazenado usando a prpria estrutura do sistema em um banco de dados especial chamado mysql. Pela natureza dos dados que este banco de dados armazena, ele deve ter o acesso permitido apenas para o usurio root do MySQL. Os usurios comuns no necessitam de acessar este banco de dados, principalmente a tabela user, onde esto armazenadas as senhas dos usurios.

Sistema de autenticao (MySQL)

Para aceitar a conexo de um usurio, o MySQL no considera apenas o prprio usurio, mas tambm a mquina de onde o usurio est conectando. Dessa forma, voc pode permitir o acesso de um determinado usurio somente de algumas mquinas especficas, bloqueando seu acesso de outros hosts que podem no ser confiveis. Existem duas maneiras de conceder privilgios aos usurios: Usando os comandos GRANT e REVOKE, ou Alterando diretamente as tabelas do banco de dados mysql.

A melhor escolha usar os comandos GRANT/REVOKE, pois o MySQL j altera as tabelas automaticamente, no sendo necessrio entender em detalhes o significado de cada tabela e suas respectivas colunas. Se voc alterar os privilgios manualmente alm do risco de manipular dados de forma errada, voc pode se esquecer de executar o comando FLUSH PRIVILEGES para tornar as alteraes ativas.

Sistema de autenticao (MySQL)

Ao criar um novo banco de dados, deixe que apenas o administrador do banco de dados tenha acesso completo. Aos usurios comuns permita apenas acesso aos dados, evitando o acesso estrutura do banco de dados. Assim um usurio comum com acesso "completo" deveria ter acesso aos comandos INSERT, DELETE, UPDATE e SELECT. Apenas o administrador do banco de dados deve ter acesso a comandos como DROP, CREATE ou ALTER. Dessa forma voc est permitindo a cada um apenas o que ele necessita para o processamento de dados. Exemplificando, vamos definir um certo "Alfredo" como administrador do banco de dados "expedicao" que vai ter como usurios um tal "Luciano" que, por ser desenvolvedor, pode alterar a estrutura do banco de dados e o "Thiago" que o usurio final, ou seja, ele apenas precisa manipular os dados armazenados.

Sistema de autenticao (MySQL)

Para definir estes trs usurios, basta executar a seguinte seqncia de comandos SQL: > GRANT ALL PRIVILEGES ON expedicao.* TO Alfredo@localhost IDENTIFIED BY senha_do_alfredo; > GRANT SELECT,INSERT,UPDATE,DELETE,DROP,ALTER ON expedicao.* TO Luciano@localhost IDENTIFIED BY senha_do_luciano; > GRANT SELECT,INSERT,UPDATE,DELETE ON expedicao.* TO Thiago@localhost IDENTIFIED BY senha_do_thiado; Note que no exemplo acima, todos os usurios cadastrados tm acesso ao banco de dados apenas se estiverem conectando da mquina local, ou seja diretamente na mquina onde o servidor MySQL est rodando. Para permitir acesso de outros hosts basta repetir a consulta para um usurio alterando localhost para o nome ou endereo IP da mquina de onde ser permitido ao usurio conectar ao banco de dados.

Sistema de autenticao (MySQL)

Voc poderia ainda usar o curinga % indicando que o usurio pode se conectar de qualquer host, mas isto no recomendado, pois a priori voc no deve confiar em mquinas s quais voc no tem informaes. muito importante que o administrador entenda pelo menos basicamente o funcionamento do sistema de privilgios do MySQL para evitar conceder a um usurio mais poder do que ele necessita. So vrios tipos de privilgios que um determinado usurio pode ter alm de SELECT,INSERT,UPDATE,DELETE,DROP e ALTER mostrados acima. altamente recomendado fazer uma leitura no manual do MySQL para ver os privilgios disponveis e como utiliz-los de forma correta.

Conexo via rede (MySQL)

Ao conectar ao servidor MySQL localmente, tendo um sistema bem configurado o MySQL j pode ser considerado bem seguro. Ao disponibilizar o acesso via rede, porm, criamos mais um ponto de vulnerabilidade deixando o sistema merc de ataques dos mais variados tipos. O simples fato de deixar uma porta aberta j agua a curiosidade de certos usurios para tentar usar esta porta aberta como entrada para derrubar servios ou outras formas de "atrapalhar" o funcionamento do sistema. Em sua instalao padro, o MySQL inicia permitindo conexes locais e conexes via rede. Na seo anterior, vimos como permitir que um usurio se conecte a partir de um host. O simples fato de no permitir a conexo de um usurio no siginifica que no teremos mais problemas porque a porta continua aberta para a rede. Pensando nesta "porta aberta", necessrio implementar mecanismos para que os dados que trafegam por esta porta no sejam lidos por algum que no o servidor e o cliente.

Conexo via rede (MySQL)

Para ajudar a decidir como "esconder" os dados de crackers, devemos ter em mente como ser desenvolvido o aplicativo que vai usar o banco de dados. Se for um ambiente web, onde o servidor web e o MySQL estejam na mesma mquina, no h motivos para liberar o acesso via rede. Neste caso o servidor deve ser iniciado com a opo --skipnetworking que faz com que o MySQL funcione apenas com conexes locais via sockets. Se o aplicativo estiver em uma mquina e o servidor em outra como em ambientes cliente/servidor, ou mesmo web onde o servidor web est em uma mquina e o servidor MySQL em outra, esta opo no pode ser utilizada. Nos casos onde o acesso a rede deve ser necessrio, a primeira providncia a ser tomada permitir conexes aos usurios apenas das mquinas de onde eles tm permisso para acessar o banco de dados. Isto deve ser feito atravs dos comandos GRANT e REVOKE vistos anteriormente.

A segunda providncia estabelecer uma conexo segura com o servidor. A senha no momento da autenticao no transmitida em texto plano, porm o algoritmo de criptografia no forte e pode ser facilmente quebrado. Outro problema com a conexo estabelecida entre cliente e servidor que todos os dados (requisies SQL e retorno dos dados) trafegam em texto plano e qualquer um rodando um sniffer pode ver o dilogo entre o servidor e o cliente. Existem pelo menos duas solues para este problema. A partir da verso 4.0.0, o MySQL tem suporte a SSL, que um protocolo que utiliza diferentes algoritmos de criptografia para assegurar que os dados recebidos por uma rede pblica so confiveis. Outra soluo criar uma VPN usando aplicativos como SSH que criam um tnel criptogrfico entre dois hosts e o host remoto passa a enxergar o servidor como se estivesse rodando localmente. Usando o MySQL com suporte a SSL, voc pode, ao criar um usurio, informar ao servidor que este usurio precisa ser autenticado usando tambm atributos do SSL alm dos dados padro (usurio, senha, nome/IP do host). Basta para isto acrescentar a clusula REQUIRE no comando GRANT.

Exemplificando, vamos fazer com que a autenticao do usurio Alfredo seja feita com SSL. > GRANT ALL PRIVILEGES ON expedicao.* TO Alfredo@localhost IDENTIFIED BY senha_do_alfredo REQUIRE SSL; O manual do MySQL d todas as informaes passo a passo para criar certificados para o MySQL e como configurar o MySQL para utilizar acesso seguro via SSL. Recomendamos a sua leitura para implementar este recurso. Se o servidor MySQL deve ser visto apenas na rede local, o acesso externo deve ser bloqueado. Voc pode fazer isto com o prprio esquema de privilgios do MySQL, mas assim apenas o acesso ao banco de dados estar restrito e a porta continuar aberta para a rede externa.

A melhor alternativa para evitar este acesso indesejado com a implementao de um firewall. Se a rede externa no deve acessar o MySQL o prprio firewall se encarrega de filtrar o acesso. Dessa forma a porta de acesso ao MySQL ser fechada para conexes externas.

Segurana em Banco de dados Proprietrio (Oracle)

A segurana do banco de dados pode ser classificada em duas categorias distintas: segurana de sistema e segurana de dados. A segurana de sistema contm os mecanismos que controlam o acesso e o uso do banco de dados em um determinado nvel do sistema. Os mecanismos de segurana do sistema verificam se um usurio est autorizado a se conectar ao banco de dados, se a auditoria do banco de dados est ativa e quais operaes de sistemas um usurio pode executar. A segurana de sistema inclui combinaes vlidas de nome de usurios e senha, a quantidade de espao em disco disponvel para os objetos de esquema de um usurio e os limites de recurso de um usurio.

Segurana em Banco de dados Proprietrio (Oracle)

A segurana de dados inclui os mecanismos que controlam o acesso e o uso do banco de dados no nvel de objeto de esquema incluindo quais usurios tm acesso a um objeto e a tipos especficos de aes que cada um pode executar. Existem ferramentas adicionais que incrementam a segurana do Oracle Server, possibilitando um ambiente multiplataforma de maior escala. Entre elas podemos citar : Oracle Enterprise Manager (conhecido como OEM) Oracle Security Server Manager (conhecido como OSS).

Segurana em Banco de dados Proprietrio (Oracle)

O Oracle Enterprise Manager ( OEM) um conjunto de utilitrios que so disponibilizados numa interface grfica em modo usurio (GUI), que provm meios para gerenciar uma ou mais bases de dados de um nico computador. O OEM composto por:

Um conjunto de ferramentas administrativas; Um monitor de eventos que pode ser configurado para inspecionar situaes especficas em sua base de dados; Um agendador de tarefas para executar tarefas de manuteno em horrios definidos; Uma interface grfica para o Recovery Manager Tools.

Segurana em Banco de dados Proprietrio (Oracle)

O Oracle Security Server Manager (OSS) pode ser utilizado para implementar uma estrutura mais complexa de segurana para dados mais sensveis, com os seguintes aspectos: Autenticao de usurio atravs de credenciais eletrnicas; Assinatura Digital; Single Sign On (SSO) .

Segurana em Banco de dados Proprietrio (Oracle)

Por se tratar de um banco de dados multiplataforma, sua segurana no pode ser resguardada na segurana do sistema operacional em que foi instalado. Para isso, a instalao do Oracle segue uma poltica de depender o mnimo possvel do sistema operacional, atravs da implementao de diversas medidas de segurana. A primeira, e tambm mais bsica, a alterao das senhas dos usurios padro do banco. Usurios como System (senha: manager), Sys (senha: change_on_install) e DBSNMP (senha: dbsnmp) so instalados com tais senhas padro e tm um alto nvel de acesso ao banco, o que pode comprometer por completo a segurana do mesmo.

Segurana em Banco de dados Proprietrio (Oracle)

O servidor Oracle fornece controle arbitrrio de acesso, o que um meio de restringir o acesso s informaes privilegiadas. O privilgio apropriado deve ser atribudo por um usurio para que ele acesse um objeto de esquema. Os usurios com privilgios apropriados podem conced-los a outros segundo o seu critrio.

O Oracle gerencia a segurana do banco de dados usando diversos recursos diferentes. Entre eles: usurios, domnio de segurana, privilgios, Papeis e auditoria.

Opes de Autenticao (Oracle)

Para acesso ao banco de dados, existem quatro formas de autenticao: Atravs de um arquivo de senhas; Autenticao herdada do sistema operacional (usurio autenticado previamente no sistema operacional); Arquivo de senhas e do sistema operacional; Autenticao nativa do banco de dados.

As trs primeiras vo herdar confiabilidade do sistema operacional, o que pode vir a causar problemas. A poltica sempre confiar no banco de dados, autenticando somente por ele e implementando uma boa poltica de senhas. Tal mtodo de autenticao consta na view V$SYSTEM_PARAMETER

Usurios (Oracle)

Abrange usurios e esquema do banco de dados onde cada banco de dados tem uma lista de nomes de usurios. Para acessar um banco de dados, um usurio deve tentar uma conexo com um nome de usurio valido. Cada nome de usurio tem uma senha associada para evitar o uso sem autorizao. So implementados ainda diferentes perfis de usurio para diferentes tarefas no Oracle, tendo em vista que cada aplicao/usurio tem a sua necessidade de acesso. Existe ainda a possibilidade de proteger os perfis com senha, o que uma excelente medida. Alm dessas medidas, existe o uso de cotas que aumenta a restrio de espao em disco a ser utilizado por usurios/aplicativos.

Domnio de Segurana (Oracle)

Conjunto de propriedades que determinam restries como : Aes (privilgios e papeis) disponveis para o usurio; Cota de tablespaces (espao disponvel em disco) do usurio; Limites de recursos de sistema do usurio.

Cada usurio tem um domnio de segurana, As tabelas (tablespaces) do sistema, como a system, devem ser protegidas de acessos de usurios diferentes dos usurios de sistema. A liberao de escrita e alterao de dados em tais tabelas totalmente desaconselhvel em ambientes de produo.

Privilgios (Oracle)

Um privilgio um direito para executar um determinado tipo de declarao SQL. Alguns exemplos de privilgios incluem: Direito de conectar-se ao banco de dados; Direito de criar uma tabela em seu esquema; Direito de selecionar linhas da tabela de outra pessoa; Direito de executar o procedimento armazenado de outra pessoa.

Os privilgios so concedidos aos usurios para que eles possam acessar e modificar os dados do banco de dados.

Privilgios (Oracle)
Os privilgios de um banco de dados Oracle podem se dividir em duas categorias distintas:

Privilgios de sistema Permitem que os usurios executem determinada ao no nvel de sistema ou em determinado tipo de objeto de esquema. Alterao de qualquer linha de uma tabela por exemplo, so privilgios do sistema.

Privilgios do objeto de esquema Permitem que os usurios executem determinada ao em um objeto de esquema tambm especifico. O privilegio de excluso de uma linha em uma tabela especifica por exemplo, um privilegio de objeto.

Papis (Oracle)

Os papis so grupos nomeados de privilgios relacionados que so concedidos aos usurios ou a outros papeis.

O Oracle fornece o gerenciamento fcil e controlado dos privilgios por meio dos papis.

Auditoria (Oracle)

Atividade que tem como fim o exame/avaliao das operaes, processos, sistemas e responsabilidades gerenciais de uma determinada entidade, com intuito de verificar sua conformidade com certos objetivos e polticas institucionais, oramentos, regras, normas ou padres.

O Oracle permite a auditoria seletiva (monitoramento registrado) das aes do usurio para auxiliar na investigao de um suposto uso suspeito do banco de dados.

Auditoria (Oracle)

A auditoria pode ser executada em trs nveis diferentes: Auditoria de declarao : Faz a auditoria nas instrues SQL pelo tipo de instruo independente dos objetos de esquema especfico que esto sendo acessados Auditoria de privilegio : Audita os privilgios de sistema, como por exemplo, CREATE TABLE ou ALTER INDEX. Auditoria de objeto de esquema: Audita as instrues especficas que operam em um especfico objeto de esquema

Auditoria (Oracle)

Para todos os tipos de auditoria, o Oracle permite a auditoria seletiva das execues bem-sucedidas das declaraes, das execues que falharam ou de ambas. Isso permite o monitoramento de declaraes suspeitas, independente do usurio que a emite ter os privilgios apropriados ou no para produzi-la. O uso de disparadores (triggers) para gravar informaes personalizadas adicionais que no esto includos automaticamente nos registros de auditoria junto com a auditoria do sistema so indispensveis para manter o sistema sempre otimizado e resguardado de acessos indevidos.

Auditoria (Oracle)

Para habilitar a auditoria, necessrio mudar o parmetro de inicializao audit_trail, para que o Oracle inicie e possa reconhecer o tipo de auditoria. Como o audit_trail no um parmetro dinmico, necessrio que ele seja mudado em nvel de SPFILE. Ele suporta os seguintes valores, cada um com a seguinte funo: OS: Auditoria Habilitada, os registros vo ser gravados em diretrios do sistema em arquivos de auditoria. DB ou TRUE: Auditoria habilitada, os registros de auditoria sero armazenadas no database (SYS.AUD$) XML: Auditoria habilitada, os registros sero armazenados em formatos XML. NONE ou FALSE: Auditoria desabilitada. DB_EXTENDED: Trabalha igual ao parmetro DB, mais as colunas SQL_BIND e SQL_TEXT so preenchidas.

Quando se seleciona os modos OS ou XML, arquivos so criados com os registros de auditoria, eles se localizam no parmetro audit_file_dest.

Auditoria (Oracle)
Fases de uma Auditoria Planejamento Analisar e estabelecer os recursos necessrios para a execuo dos trabalhos (auditoria), a rea de verificao, metodologias, os objetivos de controle e os procedimentos a serem adotados.

Execuo Juno de evidncias que sejam suficientemente confiveis, relevantes e teis para a realizao dos objetivos da auditoria.

Relatrio Informao sobre a organizao auditada, que contenham comprovaes, recomendaes e/ou determinaes.

Auditoria (Oracle)
Para verificar ou ativar a auditoria devemos fazer o seguinte: Conectar ao banco como sys : connect / as sysdba; Checar se a auditoria est ativada : show parameter audit; Se AUDIT_TRAIL=NONE no est ativa, ento executamos: alter system set audit_trail=db SCOPE=spfile;

Baixar o banco : shutdown immediate; Levantar de novo : startup open; Consultar os parmetros novamente : show parameter audit;

Dicas de Segurana (Oracle)

A Oracle indica 5 principais itens de segurana bsica para aumentar o nvel de segurana em Bancos de Dados Oracle 10G: Proteger o dicionrio de dados;
Configurar o valor do parmetro de sistema O7_DICTIONARY_ACCESSIBILITY para FALSE. Isso impede que usurios com privilgios ANY TABLE acessem tabelas do dicionrio de dados, alm de forar o usurio SYS a se conectar como SYSOPER ou SYSDBA.

Dicas de Segurana (Oracle)

Revogar privilgios pblicos em packages que oferecem riscos de segurana;

Revogar os privilgios de execuo pblica nas packages UTL_SMTP, UTL_TCP, UTL_HTTP, UTL_FILE e DBMS_OBFUSCATION_TOOLKIT. Isso impede que usurios maliciosos executem essas packages de forma indevida, reduzindo deste modo, os riscos de segurana.

Restringir privilgios administrativos aos usurios do BD;

Se um ou mais usurio(s) possuir(em) a role DBA e/ou o privilgio de sistema SYSDBA, sem necessidade ou indevidamente devem ter esse privilgio retirado.

Dicas de Segurana (Oracle)

Restringir acesso aos diretrios do Sistema Operacional ;

Verificar o valor do parmetro de sistema UTL_FILE_DIR. Se este parmetro tiver um valor apontando para um ou mais diretrio(s) do sistema de arquivos, configure no Sistema Operacional, privilgios de gravao reduzidos (valor de cota mxima de gravao em disco) neste(s) diretrio(s) para o usurio do SO que executa os processos do Oracle (normalmente usurio "oracle"). Se isso no for possvel, pode-se configurar no parmetro UTL_FILE_DIR um diretrio em um volume lgico separado do volume lgico em que esto os arquivos e software Oracle. Isso reduz o risco de um script malicioso ser executado no BD para gravar arquivos nesta pasta at estourar o limite de tamanho do volume lgico e "parar" o Banco de Dados quando o volume lgico "estourar".

Dicas de Segurana (Oracle)

Desativar autenticao remota do Sistema Operacional

Na configurao padro do Oracle 10G, o Banco de Dados permite que usurios autenticados no sistema operacional faam conexo local sem fornecer usurio e senha do Banco de Dados. Para permitir esse modo de conexo somente para usurios locais do Sistema Operacional, deve-se configurar o valor do parmetro REMOTE_OS_AUTHENT para FALSE. Essa configurao evita que usurios remotos (usurios de qualquer computador em uma rede) se conectem no Banco de Dados sem fornecer usurio e senha.

Consequencias

Sabe o que essas empresas tem em comum ?

Consequencias de Banco de Dados no seguros.

Invaso em banco de dados coloca em risco 2 milhes de clientes da Honda

Clientes da Honda esto correndo risco. No, no se trata de um recall nos automveis fabricados, mas sim uma invaso no banco de dados de e-mails dos clientes da empresa. Cerca de dois milhes de endereos foram roubados, alm de informaes pessoais como endereo, senha e modelo e identificao do veculo. A empresa est investigando como o crime aconteceu e tentando identificar os principais culpados. At agora, quem est na mira da investigao a empresa de marketing Silverpop Systems, responsveis pelas newsletters da fabricante. A Honda avisou todos os clientes em um comunicado oficial enviado ao e-mail de cada um. Afinal, com posse de todos esses dados, simples receber um comunicado como se fosse o representante Honda local, com todos os seus dados e pedindo mais informaes pessoais. Um perigo. Fonte: http://bit.ly/gJoUcW

Consequencias de Banco de Dados no Seguros.

Utilizando tcnica de injeo de SQL, dupla de invasores obteve lista de credenciais de acesso de diversos domnios ligados ao produto da Oracle. O site MySQL.com, para clientes do banco de dados adquirido pela Oracle com a compra da Sun, foi aparentemente comprometido no fim de semana por uma dupla de hackers que publicaram nomes de usurios - e, em alguns casos, senhas - dos usurios dos site. Identificando-se como "TinKode" e "Ne0h", os hackers afirmaram ter utilizado - ironicamente - um ataque de injeo SQL, mas no forneceram detalhes sobre a operao. Os domnios vulnerveis foram listados como www.mysql.com, www.mysql.fr, www.mysql.de, www.mysql.it e www-jp.mysql.com. De acordo com um post da lista de discusso de bugs Full Disclosure, o MySQL.com mantm diversos bancos de dados internos em um servidor web Apache. A informao postada incluiu diversos cdigos hash de senhas - algumas das quais j foram quebradas.

Consequencias de Banco de Dados no Seguros.

Entre as credenciais que constavam de uma lista de dados publicada no Pastebin estavam senhas para diversos usurios dos bancos de dados MySQL instalados no servidor, e as senhas admin para blogs corporativos de dois ex-funcionrios da MySQL: o ex-diretor de gerenciamento de produtos Robin Schumacher e o ex-vicepresidente de relaes com a comunidade, Kaj Arn. Schumacher atualmente diretor de estratgia de produtos na EnterpriseDB, enquanto Arn trabalha como vice-presidente executivo de produtos na SkySQL. O blog de Schumacher no foi tocado desde junho de 2009; o de Arn est inativo desde janeiro de 2010. A Oracle, que obteve o controle da MySQL com a aquisio da Sun Microsystems em abril de 2009, no comentou o incidente. Uma empresa de segurana que monitora ataques feitos a sites, Sucuri, aconselhou aos usurios com uma conta no MySQL.com a mudar suas senhas o mais rapidamente possvel, especialmente se eles usam a mesma senha em vrios sites. Fonte: http://bit.ly/eU3CN6

Recomendaes para um ambiente seguro

Nunca fornecer a ningum (exceto aos usurios administrativos) acesso a tabela da ACL, caso uma pessoa tenha acesso as senhas de acesso da ACL, ela poder facilmente se conectar ao banco com qualquer conta; Conceder apenas os privilgios necessrios para cada usurio, nunca mais do que isso; No manter senhas em texto puro no banco de dados, em vez disso, utilizar alguma funo de criptografia de via nica, com SHA1 ou MD5; No escolher senhas que contenham palavras existentes em dicionrios; Utilizar um firewall; No confiar em nenhum dado inserido pelos usurios, muitos deles podem tentar atacar o sistema inserindo caracteres especiais nas entradas dos formulrios contendo algum.

Referncias
KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistemas de Banco de Dados. 3 ed.So Paulo. Makron Books, 1999. MANUAL DE REFERNCIA DO MYSQL. Como o Sistema de Privilgios Funciona. 2008b Disponvel em < http://dev.mysql.com/doc/refman/4.1/pt/privileges.html>. Acesso em 01 abr. 2011, Marcos SMOLA . A importncia da gesto de segurana da informao. 2003. Disponvel em <http://www.linorg.cirp.usp.br/SSI/SSI2003/Palest/P03-Apresentacao.pdf>. Acesso em 01 abr. 2011. SQL Injection FAQ. Disponvel em <http://www.sqlsecurity.com/FAQs/SQLInjectionFAQ/tabid/56/Default.aspx>. Acesso em 01 abr. 2011. Maico KRAUSE. Segurana em Banco de Dados. Disponvel em <http://bit.ly/i9diim>. Acesso em 20 mar. 2011. Wikipdia. Segurana da informao. Disponivel em <http://pt.wikipedia.org/wiki/Seguran %C3%A7a_da_informa%C3%A7%C3%A3o>. Acesso em 25 mar. 2011. SQL Injection. Disponivel em <http://imasters.com.br/artigo/5179/sql_injection_no_php_o_que_e_e_como_se_proteger >. Acesso em 01 abr. 2011. * Alguns dos links esto usando encurtador de URLs*