Segurança de banco de dados

A segurança de bancos de dados diz respeito ao uso de uma ampla gama de controles de segurança da informação para proteger os bancos de dados contra comprometimentos de sua confidencialidade, integridade e disponibilidade.^[1] Envolve vários tipos ou categorias de controles, como técnicos, procedimentais ou administrativos e físicos.

Os riscos de segurança para sistemas de banco de dados incluem, por exemplo:

• Atividade não autorizada ou não intencional ou uso indevido por usuários autorizados do banco de dados, administradores de banco de dados ou gerentes de rede/sistemas, ou por usuários não autorizados ou hackers (por exemplo, acesso inadequado a dados sensíveis, metadados ou funções dentro dos bancos de dados, ou alterações inadequadas nos programas, estruturas ou configurações de segurança do banco de dados);
• Infecções por malware que causam incidentes como acesso não autorizado, vazamento ou divulgação de dados pessoais ou proprietários, exclusão ou dano aos dados ou programas, interrupção ou negação de acesso autorizado ao banco de dados, ataques a outros sistemas e falha inesperada dos serviços de banco de dados;
• Sobrecargas, restrições de desempenho e problemas de capacidade que resultam na incapacidade dos usuários autorizados de usar os bancos de dados conforme o esperado;
• Danos físicos aos servidores de banco de dados causados por incêndios ou inundações em salas de computadores, superaquecimento, raios, derramamento acidental de líquidos, descarga eletrostática, falhas eletrônicas/de equipamentos e obsolescência;
• Falhas de projeto e erros de programação em bancos de dados e nos programas e sistemas associados, criando diversas vulnerabilidades de segurança (por exemplo, escalonamento de privilégios não autorizado), perda/corrupção de dados, degradação de desempenho etc.;
• Corrupção e/ou perda de dados causadas pela entrada de dados ou comandos inválidos, erros nos processos de administração de banco de dados ou sistemas, sabotagem/danos criminosos etc.

Ross J. Anderson [en] costuma dizer que, por sua natureza, grandes bancos de dados nunca estarão livres de abusos por meio de falhas de segurança; se um sistema grande for projetado para facilitar o acesso, ele se torna inseguro; se for projetado para ser à prova de falhas, torna-se impossível de usar. Isso é conhecido como Regra de Anderson.^[2]

Várias camadas e tipos de controle de segurança da informação são apropriados para bancos de dados, incluindo:

• Controle de acesso
• Auditoria [en]
• Autenticação
• Encriptação
• Controles de integridade
• Backups
• Segurança de aplicativos [en]

Os bancos de dados têm sido amplamente protegidos contra hackers por meio de medidas de segurança de rede, como firewalls e sistemas de detecção de intrusão baseados em rede. Embora os controles de segurança de rede continuem valiosos nesse aspecto, a segurança dos próprios sistemas de banco de dados, bem como dos programas/funções e dados neles contidos, tornou-se indiscutivelmente mais crítica à medida que as redes se tornam cada vez mais abertas a um acesso mais amplo, em particular o acesso pela Internet. Além disso, os controles de acesso a sistemas, programas, funções e dados, juntamente com as funções associadas de identificação de usuários, autenticação e gerenciamento de direitos, sempre foram importantes para limitar e, em alguns casos, registrar as atividades de usuários e administradores autorizados. Em outras palavras, essas são abordagens complementares para a segurança de bancos de dados, funcionando tanto de fora para dentro quanto de dentro para fora, por assim dizer.

Muitas organizações desenvolvem seus próprios padrões e projetos de segurança "base", detalhando medidas de controle de segurança para seus sistemas de banco de dados. Esses padrões podem refletir requisitos ou obrigações gerais de segurança da informação impostos por políticas corporativas de segurança da informação e leis e regulamentos aplicáveis (por exemplo, relativos à privacidade, gestão financeira e sistemas de relatórios), juntamente com boas práticas de segurança de banco de dados geralmente aceitas (como o endurecimento adequado dos sistemas subjacentes) e, possivelmente, recomendações de segurança dos fornecedores de software e sistemas de banco de dados relevantes. Os projetos de segurança para sistemas de banco de dados específicos normalmente especificam funções adicionais de administração e gerenciamento de segurança (como administração e geração de relatórios de direitos de acesso do usuário, gerenciamento e análise de logs, replicação/sincronização de banco de dados e backups), além de vários controles de segurança da informação orientados aos negócios dentro dos programas e funções do banco de dados (por exemplo, validação de entrada de dados e trilhas de auditoria [en]). Além disso, várias atividades relacionadas à segurança (controles manuais) são normalmente incorporadas aos procedimentos, diretrizes etc. relativos ao projeto, desenvolvimento, configuração, uso, gerenciamento e manutenção de bancos de dados.

Dois tipos de privilégios são importantes em relação à segurança do banco de dados dentro do ambiente de banco de dados: privilégios de sistema e privilégios de objeto.

Os privilégios de sistema permitem que um usuário local execute ações administrativas em um banco de dados.

Os privilégios de objeto permitem o uso de certas operações em objetos do banco de dados [en], conforme autorizado por outro usuário. Exemplos incluem: uso, seleção, inserção, atualização e referências.^[3]

Bancos de dados que se enquadram em controles internos (ou seja, dados usados para relatórios públicos, relatórios anuais, etc.) estão sujeitos à separação de funções, o que significa que deve haver segregação de tarefas entre desenvolvimento e produção. Cada tarefa deve ser validada (por meio de revisão de código/análise externa) por uma terceira pessoa que não esteja escrevendo o código em si. O desenvolvedor do banco de dados não deve ser capaz de executar nada em produção sem uma revisão independente da documentação/código do trabalho que está sendo realizado. Normalmente, o papel do desenvolvedor é passar o código para um DBA; No entanto, dados os cortes orçamentários resultantes da crise econômica, um DBA pode não estar prontamente disponível. Se um DBA não estiver envolvido, é importante, no mínimo, que um colega realize uma revisão de código. Isso garante que o papel do desenvolvedor esteja claramente separado.

Outro ponto de controle interno é a adesão ao princípio de fornecer o mínimo de privilégios possível, especialmente em produção. Para permitir que os desenvolvedores tenham mais acesso para realizar seu trabalho, é muito mais seguro usar a representação (impersonation) para exceções que exigem privilégios elevados (por exemplo, EXECUTE AS ou sudo para fazer isso temporariamente). Muitas vezes, os desenvolvedores podem descartar isso como "sobrecarga" enquanto buscam a excelência na programação. Esteja ciente, no entanto, de que os DBAs devem fazer tudo o que for considerado responsável, pois são os guardiões de dados de fato da organização e devem cumprir as regulamentações e a legislação.^[4]

Uma técnica para avaliar a segurança de bancos de dados envolve a realização de avaliações de vulnerabilidade ou testes de penetração. Os testadores buscam vulnerabilidades de segurança que possam ser exploradas para burlar ou contornar os controles de segurança, invadir o banco de dados, comprometer o sistema etc. Administradores de banco de dados ou administradores de segurança da informação podem, por exemplo, usar varreduras automatizadas de vulnerabilidades para detectar configurações incorretas de controles (frequentemente chamadas de "desvio") nas camadas mencionadas acima, juntamente com vulnerabilidades conhecidas no software do banco de dados. Os resultados dessas varreduras são usados para endurecer o banco de dados (melhorar a segurança) e corrigir as vulnerabilidades específicas identificadas, mas outras vulnerabilidades muitas vezes permanecem desconhecidas e sem solução.

Em ambientes de banco de dados onde a segurança é crítica, o monitoramento contínuo da conformidade com os padrões aprimora a segurança. A conformidade com a segurança exige, entre outros procedimentos, o gerenciamento de patches e a revisão e o gerenciamento das permissões (especialmente públicas) concedidas a {ill|en|Objeto de banco de dados|Database object|objetos}} dentro do banco de dados. Os objetos do banco de dados podem incluir tabelas ou outros objetos listados no link Tabela. Neste processo, são consideradas as permissões concedidas para comandos da linguagem SQL em objetos. O monitoramento de conformidade é semelhante à avaliação de vulnerabilidades, com a diferença de que os resultados das avaliações de vulnerabilidades geralmente orientam os padrões de segurança que levam ao programa de monitoramento contínuo. Essencialmente, a avaliação de vulnerabilidades é um procedimento preliminar para determinar o risco, enquanto um programa de conformidade é o processo de avaliação contínua de riscos.

O programa de conformidade deve levar em consideração quaisquer dependências no nível do software aplicativo, visto que alterações no nível do banco de dados podem afetar o software aplicativo ou o servidor de aplicativos.

Mecanismos de autenticação e autorização em nível de aplicação podem ser meios eficazes de fornecer abstração da camada de banco de dados. O principal benefício da abstração é a capacidade de autenticação única [en] (SSO) em múltiplos bancos de dados e plataformas. Um sistema de SSO armazena as credenciais do usuário do banco de dados e autentica-se no banco de dados em nome do usuário. Abstração é a ideia de tornar conceitos complexos mais fáceis de entender.

Outra camada de segurança, de natureza mais sofisticada, inclui o monitoramento da atividade do banco de dados [en] em tempo real, seja analisando o tráfego de protocolo (SQL) na rede, seja observando a atividade local do banco de dados em cada servidor usando agentes de software, ou ambos. O uso de agentes ou de registro nativo é necessário para capturar as atividades executadas no servidor de banco de dados, que normalmente incluem as atividades do administrador do banco de dados. Os agentes permitem que essas informações sejam capturadas de uma forma que não pode ser desativada pelo administrador do banco de dados, que tem a capacidade de desativar ou modificar os registros de auditoria nativos.

A análise pode ser realizada para identificar vulnerabilidades/explorações conhecidas ou violações de políticas, ou linhas de base podem ser capturadas ao longo do tempo para construir um padrão normal usado na detecção de atividades anômalas que possam indicar uma intrusão. Esses sistemas podem fornecer uma trilha de auditoria abrangente do banco de dados, além dos mecanismos de detecção de intrusão, e alguns sistemas também podem fornecer proteção encerrando sessões de usuários e/ou colocando em quarentena usuários que apresentem comportamento suspeito. Alguns sistemas são projetados para suportar a separação de funções (SoD), que é um requisito típico de auditores. A segregação de funções (SoD) exige que os administradores de banco de dados, que normalmente são monitorados como parte do DAM, não possam desativar ou alterar a funcionalidade do DAM. Isso requer que o registro de auditoria do DAM seja armazenado com segurança em um sistema separado, não administrado pelo grupo de administração do banco de dados.

Além do uso de ferramentas externas para monitoramento ou auditoria, recursos de auditoria de banco de dados [en] nativa também estão disponíveis para muitas plataformas de banco de dados. Os registros de auditoria nativa são extraídos regularmente e transferidos para um sistema de segurança designado, ao qual os administradores de banco de dados não têm/deveriam ter acesso. Isso garante um certo nível de segregação de funções, o que pode fornecer evidências de que os registros de auditoria nativa não foram modificados por administradores autenticados e devem ser conduzidos por um grupo de DBAs sênior com foco em segurança e com direitos de leitura em produção. A ativação da auditoria nativa impacta o desempenho do servidor. Geralmente, os registros de auditoria nativa dos bancos de dados não fornecem controles suficientes para impor a segregação de funções; portanto, os recursos de monitoramento em nível de rede e/ou módulo do kernel oferecem um grau maior de confiabilidade para análises forenses e preservação de evidências.

Um bom programa de segurança de banco de dados inclui a revisão regular dos privilégios concedidos às contas de usuário e às contas utilizadas por processos imediatos. Para contas individuais, um sistema de autenticação de dois fatores melhora a segurança, mas aumenta a complexidade e o custo. As contas utilizadas por processos automatizados exigem controles adequados em relação ao armazenamento de senhas, como criptografia suficiente e controles de acesso para reduzir o risco de comprometimento.

Em conjunto com um programa robusto de segurança de banco de dados, um programa adequado de recuperação de desastres pode garantir que o serviço não seja interrompido durante um incidente de segurança ou qualquer incidente que resulte em uma indisponibilidade do ambiente de banco de dados primário. Um exemplo é a replicação dos bancos de dados primários para sites localizados em diferentes regiões geográficas.^[5]

Após a ocorrência de um incidente, a perícia forense de banco de dados [en] pode ser empregada para determinar a extensão da violação e identificar as alterações apropriadas nos sistemas e processos.

• Banco de dados negativo [en]
• Banco de dados privado virtual [en]
• FIPS 140-2 [en] – padrão federal americano para autenticação de um módulo de criptografia
• Firewall de banco de dados [en]

• «Security Technical Implementation Guides». The DoD Cyber Exchange. 2021  – Os guias de implementação técnica de 2021 da Defense Information Systems Agency.