Você está aqui: Página Inicial / Blog / Proteja-se das 5 principais causas de ataques a banco de dados

Proteja-se das 5 principais causas de ataques a banco de dados

Este artigo analisa os 5 principais cenários e as melhores práticas para prevenção de ataques de banco de dados e ameaças internas.

O desafio: Como proteger bancos de dados?

A proteção de banco de dados enfrenta um desafio multi-dimensional, onde em uma mesma empresa estão presentes diversos tipos de sistemas gerenciadores de banco de dados, aplicações corporativas, e sistemas operacionais.Estes ambientes heterogêneos resultam em uma série de cenários que ameaçam à segurança e violação dos bancos de dados.

Abordagens tradicionais de "fortaleza", tais como firewalls, sistemas de IDS / IPS não são mais
suficientes para proteção contra attackers do século 21 que podem facilmente contornar defesas de perímetro. Estas medidas de segurança não podem impedir tráfegos que parecem ser legítimos.

Os sistemas gerenciadores de banco de dados evoluíram muito nestes últimos anos, criando diversas novas funcionalidades e opções de configuração com o objetivo de se tornarem cada vez mais rápidos, escaláveis e disponíveis. Entretanto, esta complexidade trouxe também vários pontos de vulnerabilidades.

A maioria das organizações utilizam DBAs para gerenciar bancos de dados afim de  garantir a disponibilidade, desempenho e integridade. No entanto, considere as seguintes questões:

  • Qual a percentagem do tempo de um DBA que é dedicado à segurança de banco de dados? 
  • Quanto que o profissional de segurança da informação sabe sobre bancos de dados?
  • Quais medidas de seguranças são utilizadas para proteger-se de DBAs mal intencionados. (para não mencionar outros usuários privilegiados, tais como os desenvolvedores, terceirizados, fornecedores, etc.)?
  • Quantas organizações possuem ferramentas para monitorar e garantir que mudanças de estruturas nas bases de dados estão de acordo com as políticas de gestão de mudanças aprovadas pela companhia. 


Os 5 principais cenários de ataques a banco de dados 

 

Cenário 1: Prevenção de ataques externos

 A maioria dos dados sensíveis do mundo é armazenada em bases de dados comerciais, tais como Oracle, Microsoft SQL Server, IBM DB2, Informix, Sybase, MySQL, Netezza e Teradata - tornando os bancos de dados um dos principais alvos dos cibercriminosos.

De acordo com o relatório de 2011 da Verizon sobre violação de dados, ataques a servidores de banco de dados são responsáveis pelo comprometimento de 95% de todos registros de dados em 2010.

Aplicações web transformaram a maneira de como as empresas fazem negócios, mas também deixaram os banco de dados mais expostos. Esta exposição ocorre pois estes aplicativos agora utilizam os dados para atender a um público muito mais amplo e porque os usuários não estão limitados aos funcionários de dentro da empresa.Os Attackers agora possuem uma passagem direta da aplicação para os banco de dados.

Conheça as principais causas de ataques externos a banco de dados:

 

Os Cyber-criminosos, hackers motivados e associados a sindicatos do crime, os quais estão dispostos a pagar um bom dinheiro para obter informações pessoais roubadas de bancos de dados de clientes.

Cyber-espionagem visando propriedade intelectual, tais como projetos de novos produtos, fórmulas e informações sobre recursos estratégicos, como: petróleo, energia e infra-estrutura.

Hacktivismo, um novo fenômeno motivado por razões políticas, em vez de ganho financeiro.

Estes ataques contornam defesas de perímetro tradicionais, explorando vulnerabilidades em aplicações web, tais como SQL Injection ou roubo de credenciais administrativas para comprometer bancos de dados.

A implementação de um monitoramento de banco de dados e uma solução de segurança ajudam a prevenir ataques de fora, tais como SQL Injection, todos os quais podem ser usados simultaneamente para proporcionar uma defesa em multi-camadas.

Esta implementação pode ser feita através do monitoramento em tempo real por políticas de segurança proativas, tais como:

  • Políticas de acesso que identificam comportamentos anômalos, comparando continuamente todas as atividades de banco de dados com um baseline do comportamento normal. Por exemplo, um ataque de SQL Injection, normalmente exibem padrões de acesso de banco de dados que são pouco característico de suas aplicações padrões. Como na situação que para nomes de tabelas de metadados o attacker pode experimentar executar comandos SQL utilizando diferentes argumentos, como "Credit_Card_Num" ou "CC_Num" - até que ele encontre um nome de tabela válida que não resulta em um erro de banco de dados.
  • Políticas de exceção baseadas em códigos de erros SQL específicos do banco de dados, tais como "ORA-00903: nome de tabela inválido" ou "ORA-00942: tabela inexistente" Esses códigos de erros podem indicar comportamento hacking.
  • Políticas de extrusão examinam os dados que saem do banco de dados com padrões de valores de dados específicos, tais como números de cartão de crédito, ou observa se um alto volume de registros são retornados, o que pode indicar uma violação.
  • Configurações seguindo as boas práticas de segurança evitam que hackers explorem funções ou versões vulneráveis dos bancos de dados.


Cenário 2: Bloqueio de usuários privilegiados que acessam dados sensíveis

Na maioria dos ambientes de TI, usuários privilegiados como, DBAs, desenvolvedores e terceirizados - podem ter acessos irrestritos aos dados sensíveis, com pouco ou nenhum controle de monitoramento em torno de suas atividades.

Estes "super usuários" podem facilmente contornar os pontos de controle de segurança a nível de aplicação ou a nível de rede. Acessos baseados em roles e outros controles internos dos SGBD são projetados para impedir que os usuários finais acessem dados confidenciais em bancos de dados, mas não podem impedir que os DBAs e outros usuários privilegiados que possuem a capacidade de executar qualquer comando de banco de dados em qualquer objeto de banco de dados executem alguma operação não autorizada. 

Muitas organizações têm políticas de segurança de dados formais que regem como e quando
usuários privilegiados podem acessar sistemas de banco de dados. No entanto, estas organizações não têm controles de execução ou de visibilidade granular sobre o que realmente está acontecendo na fonte de armazenamento dos dados. Os desenvolvedores podem ser capazes de acessar os banco de dados usando o usuário da aplicação, mas sem todas as medidas de segurança construídas no aplicativo, pois ele acessará de uma ferramenta externa como SQL * Plus.

Como identificar e lidar com alguém que está abusando credenciais?


Para piorar a situação, o gerenciamento de identidade é raramente encontrado nas empresas, logo muitos usuários privilegiados compartilham suas credenciais para acessar os sistemas de banco de dados.

As organizações que utilizam o auditoria nativa de log de banco de dados estão descobrindo que esta abordagem é impraticável, já que requer alterações nas base de dados e provoca queda do desempenho e estabilidade das aplicações críticas de negócios, como ERP, CRM e sistemas de processamento de cartão de crédito. Também não atende as exigências dos auditores em relação a separação de funções, porque o log de banco de dados não é controlado pelo time de segurança de TI.

Ao implementar funcionalidades de monitoramento e de bloqueio de recursos(fornecidas por uma solução de auditoria e proteção de banco de dados), todas as atividades executadas nas base de dados via rede ou no próprio servidor de banco de dados podem ser controladas, evitando o vazamento de informações na fonte, bem como alterações não autorizadas ao bancos de dados críticos. Além disso, ao utilizar uma tecnologia de monitoramento em tempo real as organizações podem impedir imediatamente o acesso não autorizado ou suspeito nos bancos de dados, mesmo por usuários privilegiados.

Veja algumas maneiras de impedir estes acessos:

  • Monitoramento de todas as operações de banco de dados para criar uma trilha de auditoria contínua de alta granularidade que identifica o "quem, o quê, quando, onde e como" de cada transação. A implementação de políticas de acesso de alta granularidade é exigida pelo os principais regulamentos, tais como Sarbanes-Oxley (SOX), o Payment Card Industry Data Security Standard (PCI-DSS), HIPAA / HITECH, NIST / FISMA SP 800-53 e as leis de privacidade e proteção de dados locais.
  • Analisar continuamente dados monitorados em tempo real para identificar atividades suspeitas ou não autorizadas, e executar de ações de resposta que variam desde bloquear a transação em tempo real até gerar um alerta para a equipe de segurança.


Cenário 3: Identificação de fraude na camada de aplicação 

Aplicações empresariais como Oracle EBS, PeopleSoft, JD Edwards, SAP, Siebel, Business Intelligence e sistemas internos interagem com dados sensíveis, como informações dos funcionários e clientes, informações de propriedade intelectual e financeiras. É difícil proteger estes sistemas pois eles são altamente distribuídos e projetados para permitir o acesso Web a partir de dentro e de fora, como clientes, fornecedores e parceiros.

Além disso, aplicativos empresariais mascaram a identidade dos usuários finais a nível de transação de banco de dados usando um mecanismo de otimização conhecido como "o pool de conexão." Usando conexões do pool, o aplicativo agrega todo o tráfego dos usuários dentro de algumas conexões de banco de dados que só são identificados por um único nome relacionado ao serviço da aplicação.

O pool de conexão dificulta a associação de transações específicas com usuários finais. Como resultado, as transações fraudulentas são difíceis de serem rastreadas. Por último, os dados associados aos aplicativos corporativos também podem ser acessados diretamente por usuários privilegiados através de ferramentas de desenvolvimento, como o SQL * Plus, ignorando os controles dentro do aplicativo.

Com monitoramento de base de dados em tempo real e uma solução de auditoria, as organizações têm a capacidade de captura de transações diretas e indiretas. Com estas soluções, é possível utilizar funcionalidades que asseguraram que as operações realizadas via conexões do pool incluem os IDs de seus usuários de aplicação. Esses recursos, juntamente com o fluxo de trabalho automatizado, asseguraram que as violações de políticas de segurança sejam facilmente rastreadas, investigadas e corrigidas.

Cenário 4: Garantir que apenas pessoas autorizadas tenham acesso aos bancos de dados

Acessos não autorizados à base de dados muitas vezes passam despercebidos, expondo dados sensíveis e potencialmente causando milhões de reais em danos. Uma boa estratégia de segurança da informação e privacidade deve assegurar que a organização seja capaz de identificar quem tem acesso à informação, bem como garantir que o acesso é restrito aos dados que ele precisa para realizar o seu trabalho.

Dois recursos de primários para este tipo de controle são: autenticação e autorização.

A autenticação é o processo que identifica unicamente uma pessoa ou um sistema. A abordagem mais comum é usar um ID de usuário e uma senha. Com a autenticação de usuários é possível atribuir e gerenciar privilégios específicos de um usuário para limitar seu acesso.

A autorização é o mecanismo que controla quais informações e ações estarão disponíveis para um indivíduo em particular, e em quais circunstâncias.

Dentro das bases de dados há tanta complexidade que é muito difícil de entender quem tem acesso a quais objetos e informações e quais são os papéis e autorizações de cada usuário. Auditores normalmente exigem que estas permissões sejam revistas periodicamente. Assim, uma maneira para ajudar a atender essa necessidade é automatizar a verificação das permissões dos usuários de  bancos de dados para avaliar se os acessos foram concedidos corretamente.

Uma solução especializada em segurança de banco de dados inclui capacidades de gerar relatórios automatizados com as informações sobre os direitos de usuário em toda a infra-estrutura de banco de dados heterogêneos da corporação, bem como identificar quais usuários têm determinados privilégios especiais, e que concedeu novos direitos para quem.


Cenário 5: Detectar alterações de banco de dados não autorizadas

A detecção das alterações de banco de dados é importante para o controle dos usuários privilegiados. No entanto, também é importante do ponto de vista de segurança externa. Estas mudanças podem ser indicadores de que um banco de dados foi comprometido, uma vez que os hackers costumam fazer alterações de banco de dados no processo de extração de dados ou a incorporação de malware.

Como resultado, muitas organizações estão buscando monitorar suas infra-estruturas de banco de dados através de controles automatizados e centralizados. Isto lhes permite controlar todas as alterações de banco de dados, mesmo em ambientes complexos, heterogêneos e distribuídos.

Veja alguns tipos de alterações:

Estruturas de banco de dados como tabelas, triggers e procedures. Por exemplo, você pode detectar deleções ou inserções acidentais  de tabelas críticas que impactam o negócio. Você também pode identificar de forma proativa atos maliciosos, tais como "bombas lógicas" plantadas por funcionários descontentes.

Dados críticos, tais como alterações de dados que afetam a integridade das transações financeiras.

Criação de usuários e roles e concessão e revogação de permissões. Por exemplo, um funcionário terceirizado poderia criar uma nova conta de usuário no bancos de dados e em seguida apagar a conta inteira, eliminando todos os vestígios de sua atividade.

Arquivos de banco de dados de configuração e outros objetos externos que podem afetar a condições de segurança de banco de dados, como o  variáveis de registro/ambiente, arquivos de configuração (por exemplo, NAMES.ORA), shell scripts, arquivos executáveis e de sistema operacional, tais como programas Java.

Implementar controles automatizados em tempo real  através de uma solução de segurança de banco de dados pode impedir ações não autorizadas, tais como: consultas em tabelas sensíveis; alteração valores de dados sensíveis; adicionar ou excluir tabelas críticas (alterações de esquema) fora de janelas de mudança; e criar novas contas de usuário ou modificar privilégios.

Conclusão

As organizações devem tratar com prioridade o tema segurança banco de dados, visto que os sistemas gerenciadores e banco de dados armazenam os ativos mais críticos da companhia. Por isso, é necessário que elas implementem um estratégia sólida para segurança de banco de dados com o objetivo de se proteger contra ameaças emergentes, como injeção de SQL, cross-site scripting e das violações de usuários privilegiados.

De acordo com a Forrester, "As empresas estão buscando olhar para além de auditoria e monitoramento, muitas estão à procura de um único fornecedor para apoia-los em todos seus requisitos de segurança de banco de dados, incluindo a auditoria de banco de dados, análise de vulnerabilidade, mascaramento de dados, criptografia e proteção em tempo real". Soluções de um único fornecedor normalmente oferecem uma única aplicação de políticas comuns para um ambiente de diversos fabricantes de SGBD, um painel de controle integrado de monitoramento, e separação de funções.

O IBM InfoSphere Guardium fornece uma solução simples e robusta para monitorar continuamente o acesso a bancos de dados corporativos e simplificar as auditorias de conformidade com controles automatizados e centralizados para ambientes heterogêneos. IBM InfoSphere Guardium software ajuda as organizações a:

  • Impedir violações de dados, fraudes internas e alterações não autorizadas de dados confidenciais.
  • Monitorar usuários privilegiados, tais como os administradores de banco de dados, desenvolvedores e terceirizados.
  • Eliminar a sobrecarga e a complexidade de logs de auditoria de auditoria nativas dos SGBDs.
  • Automatizar os relatórios de conformidade, descoberta de dados, avaliações de vulnerabilidade e de configuração de banco de dados.