Processos que vêm direto da fábrica são conhecidos por invasores, que se aproveitam das brechas para invadir os ambientes.

Mesmo com as empresas gastando muito dinheiro em defesa de dados em várias camadas de infraestrutura de TI, muitas delas têm seus esforços sabotados pelo armazenamento da informação feito parcamente em bases de dados configuradas. Seja devido à logística de aplicações legadas, à conveniência de administradores ou a falta de conhecimento de seus administradores (DBAs), as databases configuradas com definições out-of-the-box (pré-definidas direto da fábrica) são muito comuns dentro de empresas.

Essas configurações padrão-facilitam o trabalho de ladrões de dados bem-informados. Definições de credencial de conta-padrão são o primeiro alvo de invasores quando tentam qualquer tipo de acesso às telas de login. Serviços externos e procedimentos armazenados (stored procedures) são a superfície mais ampla de ataque e os invasores vão ao delírio quando encontram as chaves de criptografia armazenadas lado a lado com o banco de dados, no mesmo servidor.

“O único lugar que é seguro usar configuração padrão é na sua televisão”, afirmou David Maman, CTO e fundador da GreenSQL. “Em qualquer outro lugar no mundo de TI isso é um crime, especialmente dentro de sua database. Segurar a base de dados é um passo essencial”.

Pelas configurações fazerem toda a diferença entre a segurança do armazenamento de dados e a vulnerabilidade para o vazamento de Big Data, os especialistas em segurança recomendam que sejam observadas todas as definições padrão, buscando por fraquezas. Mas, em especial, os padrões a seguir são os que causam maiores riscos:

1. Contas e senhas padrão.

“As senhas inseguras são definitivamente o problema mais pernicioso”, afirmou David Litchfiel, arquiteto de segurança da Accuvant LABS. As falhas na configuração em relação à autenticação e às credenciais de conta são abundantes, mas de longe as mais perigosas e as que mais acontecem ao simplesmente permitir que nomes de usuários e senhas padrões permaneçam operacionais.

“Invasores e malwares têm como alvo credenciais conhecidas. Mudar o nome de contas comuns, como  “sa,” ou outras contas administrativas padrão, e no lugar usar senhas complexas para elas, ajuda a adicionar uma camada de segurança”, observou John Likous, diretor de segurança e conformidade da eIQnetworks.

Além disso, permitir configurações padrão que possibilitam logins anônimos é outro risco das definições de permissões. “Os invasores usam ferramentas de análise para sondar bases de dados que permitem logins anônimos e então fazer conexões para determinar a versão deles e outras especificações. Depois usam essas informações para formular um ataque que dê maior acesso”, explicou Cal Jewell, técnico sênior da ExtraHop Networks.

Da mesma forma, contas de serviços compartilhadas podem ser um grande risco porque são difíceis de monitorar e muitas vezes fornecem amplas permissões dentro da database.

2. Permitir acesso direto à tabela

Segundo Ron Rule, vice-presidente de e-commerce da Infusion Brands, e um especialista em desenvolvimento, o maior problema é quando são permitidos acessos diretos à tabela.n“Quando seu aplicativo pode fazer o seu próprio SELECT/UPDATE/INSERT?DELETE e ter acesso direto à tabela, seus dados estão vulneráveis”.

Uma  das melhores medidas é criar acesso ao buffer por meio de stored procedures durante o desenvolvimento. “Codifique seus aplicativos para executar somente as stored procedures, e então dê ao usuário acesso à elas e negue acesso às tabelas”.

3. Manter Stored Procedures padrão

Entretanto, as stored procedures não são necessariamente uma boa medida, explicou Linkous. Algumas stored procedures padrão de fábrica podem ser um grande risco em mãos maliciosas. “o ‘xp_cmdshell’ do Microsoft SQL Server é um exemplo disso: um SP [service pack] permite que qualquer linha de comando arbitrário seja executada, mesmo se o comando seja operado fora do escopo do SQL Server”.

Ele recomenda que a empresa observe de perto estes procedimentos padrões e os desabilite ou elimine completamente.

4. Chaves criptografadas armazenadas com os dados

A criptografia pode adicionar uma camada efetiva de segurança se executada corretamente. Mas a parca configuração pode fazer com que esquemas como o da fornecedora Transparent Data Encryption (TDE) sejam inúteis, afirmou Todd Thiermann, diretor sênior de marketing de produto da Vormetric.

“A abordagem padrão de armazenamento da chave TDE para a base de dados é como deixar uma cópia da chave no beiral da porta ou deixar um lembrete de senha grudado em seu monitor. As chaves criptografadas devem ficar protegidas em um servidor que não seja host da database”.

5. Serviços e aplicativos desnecessários

As bases vêm com vários serviços de suporte, aplicativos e outros componentes que possibilitam o oferecimento de um grande conjunto de funcionalidades para vários casos. Mas cada componente adiciona uma pequena área de ataque para potenciais invasores tirarem vantagem.

“A maioria dos produtos oferece componentes ‘add-on’, como ferramentas de relatórios e análise. Esses componentes podem apresentar vulnerabilidades adicionais para o  sistema geral da base de dado, então devem ser desabilitados ou desinstalados se necessário”, observou Linkous.

Os efeitos disso são exacerbados pelo fato de muitas bases estarem atrasadas em suas correções, explicou Litchfield. Felizmente, muito do risco pode ser reduzido ao reconhecer que a empresa raramente necessita de mais do que uma fração desses conjuntos de recurso para dar suporte a qualquer cenário de instalação da database.

“Em segurança, costumamos ver componentes instalados quando um servidor é ajustado só para o caso de serem necessários. Com um pouco de planejamento, isso pode ser evitado. Desenvolvedores de aplicativos precisam especificar os componentes necessários”.

Tradução: Alba Milena, especial para o IT Web | Revisão: Adriele Marchesini