http://my.opera.

com/maicokrause/blog/seguranca-em-banco-de-dados-parte1-politicas-de-seguranca-da-informacao

Segurana em Banco de Dados - Parte 1 - Polticas de Segurana da Informao

Tuesday, 14. July 2009, 23:10 Atualmente a informao um recurso crtico no dia-a-dia das organizaes. Atravs da informtica, todas as operaes bsicas das empresas esto sendo automatizadas, como por exemplo, controle de estoque, faturamento, pagamentos, alm de suporte a diversas funes da administrao como previso, oramento e controle financeiro. Para que essas funes sejam possveis, necessria a utilizao de um banco de dados. De acordo com MATTOSO (s.d), um banco ou base de dados uma coleo de dados inter-relacionados logicamente e dados so fatos que podem ser armazenados ex:nomes, telefones, endereos. Um banco de dados pode ser criado e mantido por um conjunto de aplicaes desenvolvidas especialmente para esta tarefa ou por um Sistema Gerenciador de Banco de Dados (SGBD). Um SGBD permite aos usurios criar e manipular bancos de dados de propsito geral. O conjunto formado por um banco de dados mais as aplicaes que manipulam o mesmo chamado de Sistema de Banco de Dados. Os bancos de dados so utilizados para armazenar diversos tipos de informao, desde dados simples at informaes confidenciais ou de grande importncia para empresas, como por exemplo detalhes dos registros dos recursos humanos, sobre os clientes, pedidos de compras e informaes sobre cartes de crdito, portanto muito importante que haja alguma forma de proteger estas informaes a fim de evitar que algum faa mau uso dessas informaes ou de alguma forma mal-intencionada, divulgue, altere, exclua ou adicione registros no banco e alm disso, de acordo com o MANUAL DE REFERNCIA DO MySQL (2008a) e com a MICROSOFT CORPORATION (2004), no basta apenas proteger o SGBD, necessrio proteger completamente o servidor, mesmo que este no esteja diretamente conectado Internet. Neste post, que dividido em duas partes, irei apresentar os aspectos fundamentais relacionados segurana de bancos de dados utilizando o SGBD MySQL. Para isso, descreverei as principais ameaas segurana dos dados e as medidas a serem tomadas pelo administrador de banco de dados (DBA), alm de aspectos sobre a proteo da integridade e disponibilidade de dados. Na primeira parte do post, irei analisar o papel da informao nas empresas e a importncia de mant-las confiveis e acessvel somente por pessoas autorizadas e tentarei ressaltar a importncia de se estabelecer polticas de controle e monitoramento do acesso as informaes armazenadas no banco de dados propondo um entendimento geral dos princpios utilizados para permitir que um usurio utilize formalmente as credenciais de segurana que lhe foram cedidas. Na segunda parte do post, irei apresentar os principais comandos utilizados para fornecer maior segurana ao SGBD MySQL e mostrarei alguns aspectos relacionados a segurana da integridade e disponibilidade dos dados, bem como apresenta alguns mtodos de preveno e deteco/correo de problemas.

A IMPORTNCIA DA SEGURANA

O DICIONRIO AURLIO (2004) define informao como 1. Ato ou efeito de informar(-se); informe. 2. Dados acerca de algum ou de algo. 3. Conhecimento, participao, e seguro (segurana) da seguinte forma: 1.Livre de perigo. 2.Livre de risco; protegido, acautelado, garantido (...) 8.Em quem se pode confiar; constante, leal. 9.Certo, indubitvel, incontestvel (...). 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. 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. A norma NBR ISO/IEC 17799 (2005, p.9) define segurana da informao como a proteo da informao de vrios tipos de ameaas para garantir a continuidade do negcio, minimizar o risco ao negcio, maximizar o retorno sobre os investimentos e as oportunidades de negcio. 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.

SEGURANA DE ACESSO AOS DADOS

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 noautorizados 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 prestabelecidas, e observadas por polticas de proteo. A figura 1 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).

Figura 1 Sistema de Controle de Acesso - Fonte: (CARDOSO & DA SILVA apud CASTANO et al. 1995, p.4) Esta 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 (como por exemplo o MySQL) 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. 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 (MANUAL DE REFERNCIA DO MYSQL, 2008b). 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. Para garantir a segurana do acesso aos dados, o MANUAL DE REFERNCIA DO MYSQL (2008a) recomenda algumas medidas, como:

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 comando prejudicial ao banco, como por exemplo DROP DATABASE ou outros. Portanto sempre procurar alguma forma de tratar as entradas digitadas pelos usurio a fim de evitar esse tipo de ataque.

http://homepages.dcc.ufmg.br/~nvieira/projeto/proj/node5.html

Controle de inferncia recursiva

bem sabido que o problema de determinar se uma frmula consequncia lgica de um conjunto de frmulas, no contexto de lgica de primeira ordem, indecidvel (semi-decidvel) (veja (Enderton, 1972), por exemplo). Sistemas de processamento de conhecimento expresso neste formalismo tm duas opes bsicas para contornar tal problema:

restringir a expressividade do formalismo (por exemplo: (PatelSchneider, 1990)); obter um procedimento de inferncia incompleto, no sentido de que s vezes pode falhar (Bibel, 1987) (Bundy, 1983) (Loveland, 1978).

Em qualquer dos dois casos, se no forem impostas restries adicionais quanto s frmulas que podem ser inseridas para processamento, o problema , de qualquer forma, intratvel (Delgrande & Mylopolous, 1986) (Bundy, 1983). Assim, justifica-se o uso de heursticas dependentes ou no do domnio que se formalizar. consenso que, em geral, o uso de heursticas independentes de domnio avana muito pouco no sentido de dar maior abrangncia com relao ao espectro de problemas tratveis; o procedimento de inferncia, caso se deseje manipular problemas de complexidade razovel, deve embutir heursticas baseadas nas caractersticas da classe de problemas que se quizer tratar. Apesar dos problemas apontados acima, ou por causa deles, o problema da representao de conhecimento em Lgica (de primeira ordem, de ordem superior, lgicas no clssicas, etc.) um dos tpicos em que se concentra enorme esforo por parte dos pesquisadores em Inteligncia Artificial (basta ver os principais peridicos da rea). O problema que se pretende abordar neste projeto tem a ver com o corte, o mais prematuro possvel, de sees do espao de pesquisa que sejam comprovadamente redundantes ou infrutferos. Embora tal corte no se encaixe em nenhuma das opes acima, perfeitamente justificvel, j que pode diminuir substancialmente o espao de pesquisa, o qual, em seguida, pode ser explorado por meio do uso de heursticas. O contexto em que se pretende trabalhar geral o suficiente para englobar uma variedade de formalismos de representao, desde que baseados, em essncia, em Lgica de Primeira Ordem. Exemplos de reas que podero ser contempladas com os resultados que se pretende obter so: Prova Automtica de Teoremas, Programao em Lgica, Bancos de Dados Dedutivos, Sistemas Baseados em Conhecimento. Em suma, qualquer rea que envolva processamento de conhecimento representado em Lgica.

A linha principal de investigao estar concentrada no processamento de sees recursivas do espao de pesquisa. Este problema tem sido tratado principalmente nos contextos de Programao em Lgica (ou melhor, de Prolog) (Covington, 1985a, 1985b) (De Schreye, 1990) (Naish, 1986) (Nute, 1985) (Poole & Goebel, 1985) (Smith et al., 1986) (Van Gelder, 1987) e de Bancos de Dados (Henshen & Naqvi, 1984) (Sagiv & Ullman, 1984) (Ullman & Van Gelder, 1985, 1988) (Ullman, 1985), em que se analisa, no apenas a deteco de loops ocasionados pela explorao de sees recursivas, mas tambm (em certo sentido, como efeito colateral) o problema de se coletar, de forma ordenada, as respostas propiciadas por frmulas recursivas. Tambm na rea de Prova Automtica de Teoremas, sob a abordagem de reduo de problemas (como usual em Prolog e em bancos de dados), o problema tem sido analisado, mas de uma forma restrita (Loveland & Reddy, 1981). Nesta abordagem resta saber se as tcnicas desenvolvidas para Prolog e bancos de dados se aplicam para o caso mais geral de prova de teoremas para Lgica de Primeira Ordem, ou que adaptaes eventuais devem ser feitas. Em outras abordagens, principalmente aquelas baseadas em resoluo, o problema tratado parcialmente pelo uso do conceito de subjugao (Loveland, 1978) (Woos et al., 1984). No entanto, tal conceito no pode ser aplicado indiscriminadamente quando h possibilidade de extrao de mltiplas respostas, como observado em (Vieira, 1989), onde se apresenta o problema e um esboo de soluo da adaptao do conceito de subjugao para tratamento de mltiplas respostas. Tal conceito (com adaptaes) pode ser til at mesmo na rea de Programao em Lgica, como evidenciado em (Lopes & Vieira, 1991). Alm de no enfocar de forma geral o controle de recurso em sistemas baseados em lgica, as tcnicas que tem sido discutidas na literatura no vm acompanhadas de um estudo adequado de custos de aplicao das mesmas. Assim, em linhas gerais, este projeto consta de uma investigao de inferncia recursiva para os principais modelos de procedimentos de inferncia (basicamente, resoluo, sistemas tipo Gentzen e tableau semntico) (Ramsay, 1988) (Fitting, 1996), assim como de uma anlise custo/benefcio para as tcnicas existentes e as que forem eventualmente desenvolvidas.

http://www.devmedia.com.br/post-16016-Auditoria-em-Bancos-de-DadosRelacionais.html

Auditoria em Bancos de Dados Relacionais

I. Introduo

Com o surgimento dos sistemas computacionais as empresas passaram a confiar seus dados rea de tecnologia da informao. Ela se tornou responsvel pela proteo e garantia da consistncia dos dados. Como essas informaes ficam armazenadas no banco de dados, ele o ponto de partida para iniciar uma auditoria ou conferncia, nos dados recebidos e enviados pelas aplicaes e sistemas corporativos. A. Metodologias para auditoria em bases de dados Uma das funes da auditoria monitorar quando e como o dado foi inserido, a fim de prevenir e detectar problemas no cumprimento das regras de negcio. Pode-se definir tabelas para armazenar logs com informaes a respeito da utilizao das bases de dados. Isso vai crescer medida que o banco for sendo utilizado e os auditores podero definir quais tabelas, colunas, etc, valem a pena ser revisados, de acordo com as necessidades da empresa. As metodologias para auditar bases de dados podem ser desenvolvidas pela prpria empresa. De acordo com suas caractersticas, elas se dividem em dois grupos: tradicional e excluso de riscos. Metodologia tradicional Com o auxlio de uma lista de conferncia (checklist) o auditor obtm informaes a respeito da poltica de bancos de dados, no que diz respeito aos usurios de acesso, permisses, autorizaes etc, permitindo a identificao de falhas. Exemplo de itens que podem fazer parte de um checklist de auditoria: As responsabilidades de administrao das bases de dados esto definidas e documentadas? So utilizados dispositivos de segurana e procedimentos de autorizao de acesso aos dados da base? Existe um controle sobre as mudanas realizadas na base de dados? O desempenho do banco de dados analisado? O sistema monitorado? As atividades so armazenadas em log para anlise? O processo de instalao e configurao do Sistema Gerenciador de Banco de Dados (SGBD) foi feito de acordo com as normas de segurana conhecidas? Existem procedimentos de backup e restore das bases de dados? Enfim, o checklist deve conter questes relacionadas s atividades que devem ser desempenhadas para garantir a segurana e consistncia dos dados. uma conferncia dos procedimentos que esto ou no sendo feitos. Excluso de riscos Essa metodologia tem a caracterstica principal de identificar os riscos que correm uma base de dados, a fim de elimin-los ou diminu-los. Consiste em identificar o objetivo do controle e definir tcnicas para que seja alcanado. Por exemplo, no caso de o objetivo ser a preservao da confiabilidade dos dados, as tcnicas para alcanar esse objetivo poderiam ser descritas com base no estabelecimento de perfis de tipos de usurios e privilgios necessrios para controlar o acesso as bases de dados.

Cada objetivo pode ter vrias formas de ser alcanados, ou seja, podemos definir vrias tcnicas para alcanar um objetivo. Essas tcnicas podem ser preventivas ou corretivas. A partir dos objetivos identificados e das tcnicas descritas para cada um, possvel verificar se realmente funcionam atravs das provas de cumprimento. Dependendo do resultado, pode ser necessria a comprovao de outros pontos atravs de outras provas, como a prova substantiva. Todos os responsveis e envolvidos das reas afetadas pela avaliao de riscos devem conhecer o resultado e concluses das provas, do resultado da auditoria. O auditor o responsvel por documentar as situaes, os riscos e os problemas que identificou nos processos descritos. B. Ciclo de vida de uma base de dados O ciclo de vida de uma base de dados compreende toda a parte de anlise at sua implementao. Vejamos algumas dessas fases: Estudo prvio e planejamento Esta fase importante e necessita de um estudo tecnolgico de viabilidade onde se contemplem distintas alternativas para alcanar os objetivos do projeto acompanhados de uma anlise de custo-benefcio para cada uma das opes. Deve-se levar em conta a alternativa de no se levar a frente o projeto, assim como a diferena entre comprar um produto j existente no mercado, com suas caractersticas e solues prontas ou desenvolver uma nova aplicao. O auditor deve comprovar que a direo da empresa possui informaes de estudos de viabilidade e que ela quem decide desenvolver ou no o projeto. Apenas o conhecimento dos tcnicos no suficiente para se levar um projeto frente. Precisa ter respaldo da Diretoria ou corre o risco de fracassar. O COBIT (Control Objectives for Information and related Technology), um conjunto de informaes e ferramentas para prticas de gesto, apresenta a importncia da gesto de riscos, informando que fundamental o plano-diretor e que o auditor o responsvel por verificar se ele est sendo seguido dentro dos procedimentos de gesto aprovados na organizao. Outras atividades que devem ser documentadas so as dos administradores de dados e dos administradores das bases de dados. Podem at ser feitas pela mesma pessoa, mas devem ser divididas por funes e novos controles alternativos devem ser desenvolvidos. As bases de dados e seleo da equipe As bases de dados so construdas a partir de diagramas e informaes coletadas dos futuros usurios dos sistemas que vo manipular os dados. Tudo deve ser documentado de acordo com os padres definidos pela empresa. Os auditores verificam que muitas vezes, essas atividades so deixadas para depois, gerando um custo maior do que se tivessem sido feitas realmente na fase inicial do projeto. Para identificar isso, ele deve conhecer os padres da empresa no que diz respeito documentao e comprovar se foram corretamente utilizados. Como j sabemos, uma documentao de banco de dados deve conter no mnimo um modelo lgico e fsico, e desejvel que contenha o conceitual tambm.

O COBIT sugere que a rea de tecnologia tenha bastante cuidado para escolher os softwares e a equipe que vai administrar os bancos de dados. Eles devem conhecer as ferramentas e estas, por sua vez, precisam atender s expectativas tcnicas desenhadas nos modelos de dados. Aqui vemos outra importncia da modelagem. Os diagramas e o contedo das bases de dados O auditor vai analisar se a situao atual das bases de dados est de acordo com o que foi apresentado nos diagramas: definies de dados, estruturas, relacionamentos, restries e armazenamento. Todos os tipos de objetos sero avaliados: tabelas, ndices, vises... Os dados cadastrados pelos usurios tambm vo ser auditados, a fim de verificar se o banco de dados os trata e armazena da forma como foi especificado. uma forma de conferir, tambm, o papel dos usurios na manuteno da consistncia e integridade dos dados. Manuteno Essa fase confirma que houve um bom desenvolvimento do que j foi definido para as bases de dados, que os tcnicos esto prontos para construlas e os usurios prontos para us-las de maneira adequada. Aqui so definidos os comportamentos que cada um deve ter para manter as bases de dados ntegras e seguras. Reviso ps-implantao Por falta de tempo ou recursos, algumas empresas no estabelecem um plano de reviso aps a implantao de bases de dados. Seria interessante se pudessem verificar se obtiveram os resultados esperados, se as necessidades dos usurios foram satisfeitas ou se os custos-benefcios coincidiram com as previses. C. A auditoria Antes de iniciar, o auditor deve conhecer o SGBD em uso para que possa identificar como podem ser mantidas a integridade, segurana e controle dos dados inseridos nas bases. Deve tambm estudar o negcio da aplicao, entender o papel de cada objeto do banco de dados e sua utilidade no contexto. Alguns softwares de auditoria podem ser usados para facilitar o trabalho do auditor. Eles extraem dados das bases, mostram o caminho das transaes, etc. Outros sistemas monitoram e otimizam as bases de dados, facilitando a resoluo de problemas principalmente de performance. D. Concluso O ponto-chave para construir bases de dados ntegras e seguras correlacionar as informaes de usurios, analistas de sistemas, programadores, administradores de dados e administradores de bancos de dados, de forma a documentar o desenvolvimento para todas as partes envolvidas. A equipe deve ser treinada para usar os softwares escolhidos e deve compreender as regras de negcio que sero responsabilidade do SGBD ou da aplicao. Os erros dos usurios devem ser previstos e testados. O gerenciamento de riscos importante para identificar falhas em todas as atividades ligadas aos bancos de dados.