Gestão de Segurança em Banco de Dados

Além da aplicação que é a interface com os usuários, existem outros recursos que trabalham em conjunto, cooperando entre si para que seu serviço consiga entregar valor a quem o usa e que se não estiverem protegidos adequadamente poderão ser explorados por um atacante, comprometendo seus investimentos.

Quando se discute segurança em aplicações geralmente a primeira coisa a se pensar é fazer um trabalho de Pentest na interface da aplicação para encontrar vulnerabilidades. Por outra perspectiva, eu pergunto: "e seu Banco de Dados, está seguro?".

Nesta dissertiva será evitado especificar uma tecnologia como DB2, Oracle, SQL Server, PostgreSQL, MySQL etc. Inclusive os Bancos de Dados conhecidos como NoSQL. Veremos uma versão global de gestão para proteção de repositórios de dados.

De acordo com a estrutura da NBR ISO/IEC 27001, o Item 3 (três) que especifica os "Termos e Definições", podemos destacar três importantes itens (existem outros que não será foco da nossa proposta atual) que descrevem bem o que será tratato aqui:

• Disponibilidade: propriedade de estar acessível e utilizável sob demanda por uma entidade autorizada
• Confidencialidade: propriedade de que uma informação não esteja disponível ou revelada a indivíduos, entidades ou processos não autorizados.
• Integridade: propriedade de salvaguarda da exatidão e completeza de ativos

Imagine uma Aplicação Web que precisa acessar um Banco de Dados para exibir informações à usuários. Como nosso foco é o Banco de Dados deixemos de lado os usuários que interagem com a camada de visão da aplicação. Nesse exemplo, a "entidade autorizada" pelo Banco de Dados é a "Aplicação Web" que tem nome de usuário, senha e limites sobre o que pode acessar sempre que for solicitado, isto é, sob demanda. Por fim, tudo que foi dito é o que define a Disponibilidade.

Você pode estar se perguntando sobre a demanda que não é um termo de segurança da informação e sim apenas uma questão de recursos computacionais como configuração, adicionar mais memória, usar um melhor processador, adicionar redundância ou distribuição dos recursos. Mas existe uma outra faceta da disponibilidade. Imagine agora se o seu servidor de Banco de Dados estiver sofrendo um ataque de Denial of Service (DoS). Isto, também, pode afetar no atendimento a sua demanda. E pior, isso pode deixar o serviço indisponível. Logo disponibilidade por demanda é, também, item de segurança da informação.

Outro ponto importante é a administração de usuários de um Banco de Dados. É comum encontrar um mesmo usuário que tenha acesso a várias databases sem que as databases se relacionem. Ou seja, uma mesma empresa com diferentes aplicações e um único usuário no Banco de Dados. Esta prática é condenável, pois se alguém indevidamente consegue as credenciais de uma aplicação todas as databases serão afetadas e não apenas uma. Para piorar não é novidade aplicações usarem a senha de administrador (ou de root ou do system) do Banco de Dados que, em posse do atacante, dará autonomia completa ao repositório de dados.

Para mitigar esse problema é necessário que cada diferente aplicação tenha seu próprio usuário (diferente do usuário administrador ou root ou system) no Banco de Dados limitado a certa(s) database(s). Para cada database é possível, também, dizer se o usuário tem acesso apenas read-only (só leitura) e/ou de escrita. Indo mais além, é possível limitar o acesso por endereço IP de origem. Isso completa o que chamamos de Confidencialidade.

A grande maioria dos SGDBs (Sistemas Gerenciadores de Banco de Dados) tem o conceito de ACID (Atômicidade, Consistência, Isolamento e Durabilidade) que caracteriza as transações em um Banco de Dados. Transações são unidades lógicas de trabalho. Ou seja, quando iniciadas não devem sofrer interferências externas até chegar ao seu fim.

• Atômicidade: Uma transação não pode ser dividida.
• Consistência: Uma transação deve ser iniciada a partir de um estado consistente do Banco de Dados para outro estado, também, consistente.
• Isolamento: Conjunto de técnicas para que transações paralelas não interfiram uma nas outras.
• Durabilidade: Os efeitos de uma transação devem ser persistidas (commit) no Banco de Dados

Com isso fechamos o item Integridade, converse com seu DBA se seu Banco de Dados possui essa importante característica.

Outras dicas importantes:

• Se todas as conexões do seu Banco de Dados são realizadas de um único IP de origem configure-o para só aceitar conexões deste IP.
• Atualize sempre o executável e as bibliotecas do Banco de Dados, atento as correções de falhas de segurança.
• Faça com que o sistema de arquivos onde fica os dados do banco fique protegido para que só o Administrador de Sistemas (ou, no caso do Linux, o root) tenha acesso.
• Utilize senhas fortes para o usuário administrador ou root ou system.