Segurança de banco de dados

A segurança de banco de dados diz respeito ao uso de uma ampla gama de controles de segurança da informação para proteger bancos de dados (incluindo potencialmente os dados, os aplicativos de banco de dados ou funções armazenadas, os sistemas de banco de dados, os servidores de banco de dados e os links de rede associados) contra comprometimento de sua confidencialidade, integridade e disponibilidade. Envolve vários tipos ou categorias de controles, como técnicos, processuais/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 de banco de dados autorizados, 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 confidenciais, metadados ou funções dentro de bancos de dados, ou alterações inadequadas nos programas, estruturas ou configurações de segurança);
• Infecções por malware causando 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 imprevista de serviços de banco de dados;
• Sobrecargas, restrições de desempenho e problemas de capacidade, resultando na incapacidade de usuários autorizados de usar bancos de dados conforme pretendido;
• Danos físicos aos servidores de banco de dados causados por incêndios ou inundações na sala de computadores, superaquecimento, raios, derramamentos acidentais de líquidos, descarga estática, avarias eletrônicas/falhas de equipamentos e obsolescência;
• Falhas de esquema e programação em bancos de dados, programas e sistemas associados, criando várias vulnerabilidades de segurança (por exemplo, escalonamento de privilégios não autorizado), perda/corrupção de dados, degradação de desempenho e etc.;
• Corrupção e/ou perda de dados causada pela entrada de dados ou comandos inválidos, erros nos processos de administração do banco de dados ou do sistema, sabotagem/danos criminais e etc.
• Ross J. Anderson disse muitas vezes que, por sua natureza, grandes bancos de dados nunca estarão livres de abuso por violações de segurança; se um sistema grande for projetado para facilitar o acesso, torna-se inseguro; se for estanque torna-se impossível de usar. Isso às vezes é conhecido como Regra de Anderson.

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

• Controle de acesso
• Auditoria de banco de dados
• Autenticação
• Encriptação
• Controles de integridade
• Cópias de segurança
• Segurança de aplicativos
• Segurança de banco de dados aplicando o método estatístico

Os bancos de dados foram 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 permaneçam valiosos a esse respeito, proteger os próprios sistemas de banco de dados e os programas/funções e dados dentro deles, sem dúvida, tornou-se mais crítico à medida que as redes estão cada vez mais abertas a um acesso mais amplo, em particular o acesso da Internet. Além disso, controles de acesso de sistema, programa, função e dados, juntamente com as funções associadas de identificação de usuário, 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 à segurança do banco de dados, trabalhando de fora para dentro e de dentro para fora, por assim dizer.

Muitas organizações desenvolvem seus próprios padrões e esquemas de segurança de "linha de base" detalhando medidas básicas de controle de segurança para seus sistemas de banco de dados. Isso pode refletir requisitos gerais de segurança da informação ou obrigações impostas pelas políticas corporativas de segurança da informação e leis e regulamentos aplicáveis ​​(por exemplo, sobre privacidade, gerenciamento financeiro e sistemas de relatórios), juntamente com boas práticas de segurança de banco de dados geralmente aceitas (como proteção adequada dos sistemas subjacentes) e talvez recomendações de segurança do sistema de banco de dados relevante e fornecedores de software. 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 relatório de direitos de acesso do usuário, gerenciamento e análise de registros, replicação/sincronização de banco de dados e cópias de segurança) juntamente com vários controles de segurança de informações orientados aos negócios dentro do bancos de dados, programas e funções (por exemplo, validação de entrada de dados e trilhas/registros de auditoria). Além disso, várias atividades relacionadas à segurança (controles manuais) são normalmente incorporadas aos procedimentos, diretrizes e etc. relacionados ao esquema, desenvolvimento, configuração, uso, gerenciamento e manutenção de bancos de dados.

Privilégios

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

Privilégios de sistema

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

Privilégios de objeto

Privilégios de objeto permitem o uso de certas operações em objetos de banco de dados conforme autorizado por outro usuário. Os exemplos incluem: uso, seleção, inserção, atualização e referências.

O principal de privilégio mínimo e separação de funções:

As bases de dados que se enquadram nos controles internos (ou seja, dados usados para divulgação pública, relatórios anuais e etc.) estão sujeitas à 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 (através de código passo a passo/novos olhos) por uma terceira pessoa que não está escrevendo o código real. O desenvolvedor de banco de dados não deve ser capaz de executar nada em produção sem uma revisão independente da(o) documentação/código do trabalho que está sendo executado. Normalmente, a função do desenvolvedor é passar o código para um DBA; no entanto, devido aos cortes resultantes da desaceleração 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 conduza uma revisão de código. Isso garante que o papel do desenvolvedor seja claramente separado.^{[carece de fontes]}

Outro ponto de controle interno é a adesão ao princípio de fornecer o mínimo de privilégios, principalmente na produção. Para permitir que os desenvolvedores tenham mais acesso para realizar seu trabalho, é muito mais seguro usar a representação para exceções que exigem privilégios elevados (por exemplo, executar como ou sudo para fazer isso temporariamente). Muitas vezes, os desenvolvedores podem descartar isso como “sobrecarga” enquanto estão no caminho para a glória da codificação. No entanto, esteja ciente de que os DBAs devem fazer tudo o que for considerado responsável, porque eles são os administradores de dados de fato da organização e devem cumprir os regulamentos e a lei.

Avaliações de vulnerabilidade para gerenciar riscos e conformidade

Uma técnica para avaliar a segurança de banco de dados envolve a realização de avaliações de vulnerabilidade ou testes de penetração em banco de dados. Os testadores tentam encontrar vulnerabilidades de segurança que podem ser usadas para vencer ou burlar os controles de segurança, invadir o banco de dados, comprometer o sistema e etc. Os administradores de banco de dados ou administradores de segurança da informação podem, por exemplo, usar varreduras de vulnerabilidade automatizadas para pesquisar configurações incorretas de controles (geralmente chamadas de "drift") nas camadas mencionadas acima, juntamente com vulnerabilidades conhecidas em software de banco de dados. Os resultados de tais verificações são usados para fortalecer o banco de dados (melhorar a segurança) e fechar as vulnerabilidades específicas identificadas, mas outras vulnerabilidades geralmente permanecem não reconhecidas 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 melhora a segurança. A conformidade de segurança requer, entre outros procedimentos, o gerenciamento de correções e a revisão e gerenciamento de permissões (especialmente públicas) concedidas a objetos dentro de bancos de dados. Objetos de bancos de dados podem incluir tabelas ou outros objetos listados no link de tabelas. As permissões concedidas para comandos da linguagem SQL em objetos são consideradas neste processo. O monitoramento de conformidade é semelhante à avaliação de vulnerabilidade, exceto que os resultados das avaliações de vulnerabilidade geralmente orientam os padrões de segurança que levam ao programa de monitoramento contínuo. Essencialmente, a avaliação de vulnerabilidade é um procedimento preliminar para determinar o risco onde um programa de conformidade é o processo de avaliação de risco contínua.

O programa de conformidade deve levar em consideração quaisquer dependências no nível de software aplicativo, pois as alterações no nível de banco de dados podem ter efeitos no software aplicativo ou no servidor de aplicação.

Abstração

Os mecanismos de autenticação e autorização em nível de aplicativo podem ser meios eficazes de fornecer abstração da camada de banco de dados. O principal benefício da abstração é o de um recurso de início de sessão único em vários bancos de dados e plataformas. Um sistema de início de sessão único armazena as credenciais de usuário do banco de dados e se autentica em bancos de dados em nome do usuário. A abstração é a ideia de tornar ideias complexas mais fáceis de entender.

Monitoramento de atividade de banco de dados (DAM)

Outra camada de segurança de natureza mais sofisticada inclui o monitoramento das atividades de bancos de dados em tempo real, seja analisando o tráfego de protocolo (SQL) na rede ou observando as atividades locais de bancos de dados em cada servidor usando agentes de software, ou ambos. O uso de agentes ou registro nativo é necessário para capturar as atividades executadas nos servidores de bancos de dados, que normalmente incluem as atividades do(s) administrador(es) de bancos de dados. Os agentes permitem que essas informações sejam capturadas de uma forma que não possa ser desabilitada pelo(s) administrador(es) de bancos de dados, que tem a capacidade de desabilitar ou modificar registros de auditoria nativos.

A análise pode ser realizada para identificar explorações conhecidas ou violações de política, ou as linhas de base podem ser capturadas ao longo do tempo para criar um padrão normal usado para detecção de atividade anômala que possa ser indicativa de intrusão. Esses sistemas podem fornecer um(a) registro/trilha de auditoria de bancos de dados abrangente, além dos mecanismos de detecção de intrusão, e alguns sistemas também podem fornecer proteção encerrando sessões de usuário e/ou colocando em quarentena usuários que demonstrem comportamento suspeito. Alguns sistemas são projetados para suportar a separação de funções (SOD), que é um requisito típico dos auditores. A SOD requer que os administradores de bancos de dados que normalmente são monitorados como parte do DAM não possam desabilitar ou alterar a funcionalidade do DAM. Isso requer que a trilha de auditoria do DAM seja armazenada com segurança em um sistema separado não administrado pelo grupo de administração dos bancos de dados.

Auditoria nativa

Além de usar ferramentas externas para monitoramento ou auditoria, os recursos nativos de auditoria de bancos de dados também estão disponíveis para muitas plataformas de bancos de dados. As trilhas de auditoria nativas são extraídas regularmente e transferidas para um sistema de segurança designado onde os administradores de bancos de dados não devem ter acesso. Isso garante um certo nível de segregação de funções que pode fornecer evidências de que as trilhas de auditoria nativas não foram modificadas por administradores autenticados e devem ser conduzidas por um grupo sênior de DBAs orientado à segurança com direitos de leitura na produção. Ativar o nativo afeta o desempenho do servidor. Geralmente, as trilhas de auditoria nativas dos bancos de dados não fornecem controles suficientes para impor a separação de funções; portanto, os recursos de monitoramento baseados em host em nível de módulo de rede e/ou núcleo fornecem um grau mais alto de confiança para análise forense e preservação de evidências.

Processos e procedimentos

Um bom programa de segurança de bancos de dados inclui a revisão regular de privilégios concedidos a contas de usuários e contas usadas 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 usadas por processos automatizados exigem controles apropriados sobre o armazenamento de senhas, como criptografia suficiente e controles de acesso para reduzir os riscos de comprometimento.

Em conjunto com um programa de segurança de bancos de dados sólido, um programa de recuperação de desastres apropriado pode garantir que o serviço não seja interrompido durante um incidente de segurança ou qualquer incidente que resulte em uma interrupção de ambientes de bancos de dados primários. Um exemplo é o de replicação de bancos de dados primários para sites localizados em diferentes regiões geográficas.

Após a ocorrência de um incidente, a análise forense de bancos de dados pode ser empregada para determinar o escopo da violação e identificar as alterações apropriadas nos sistemas e processos.

Ver também

• Firewall de aplicativos web

Ligações externas

• Listas de verificação de segurança (em inglês)
• Guias de implementação técnica de segurança (em inglês)