Como proteger o tráfego do banco de dados ao contrário, ou seja, do cliente para o servidor

Question

Meu cenário:

Estou tentando desenvolver um serviço que irá consultar diferentes bancos de dados.

Para esclarecer a afirmação acima:

1. Eu uso a palavra serviço em seu sentido mais amplo:um componente de software que fornecerá algum valor ao proprietário do banco de dados.

2. Esses bancos de dados não estarão de forma alguma sob meu controle, pois pertencerão a empresas diferentes.Eles não serão conhecidos de antemão e vários fornecedores serão suportados:Oracle, MS (SQL Server), MySQL, PostgreSQL.Além disso, conexões OLE DB e ODBC serão suportadas.

O problema:a segurança das credenciais do banco de dados e do tráfego geral é uma grande preocupação, mas o esforço de configuração deve ser reduzido ao mínimo.Idealmente, todos os problemas de segurança devem ser abordados programaticamente na implementação do serviço e não exigem nenhum esforço de configuração por parte do proprietário do banco de dados, a não ser fornecer uma cadeia de conexão válida.

Normalmente, o suporte SSL do banco de dados é feito por meio de certificados de servidor que desejo evitar, pois é complicado para o cliente (o proprietário do banco de dados).Tenho procurado como fazer isso sem sucesso.Esperamos que isso possa ser feito com openssl, SSPI, certificado SSL do cliente ou qualquer forma de tunelamento;ou pode ser que simplesmente não seja possível.Alguns conselhos seriam muito apreciados.

Answer 1

Eu estou tendo um pouco de dificuldade em entender como esse serviço funcionaria sem ser extremamente incômodo para o proprietário do banco de dados antes de tentar proteger o tráfego com o banco de dados.

Tome o Oracle em particular (embora eu assuma que haveria problemas semelhantes com outros bancos de dados). Para acessar um banco de dados Oracle, o proprietário do banco de dados teria que abrir um orifício em seu firewall para permitir que seu (s) servidor (s) acesse o banco de dados em uma porta específica para que precejessem saber os endereços IP de seus servidores e há uma boa chance de precisar configurar um serviço que faça toda a sua comunicação em uma única porta (por padrão, o ouvinte Oracle redirecionar com freqüência o cliente para uma porta diferente para a interação real com o banco de dados ). Se eles são em toda consciência de segurança, eles teriam que instalar o Oracle Connection Manager em uma máquina separada para proxy a conexão entre o seu servidor e o banco de dados em vez de expor o banco de dados diretamente para a Internet. Isso é um bom trabalho de configuração que seria necessário internamente e isso é assumindo que a conta do banco de dados já existe com privilégios apropriados e que todos assinam em concessão de acesso ao banco de dados de fora do firewall.

Se você quiser criptografar a comunicação com o banco de dados, você precisará estabelecer uma conexão VPN com a rede do proprietário do banco de dados (que potencialmente eliminaria alguns dos problemas de firewall) ou você precisaria usar algo como Oracle Segurança avançada para criptografar a comunicação entre seus servidores. A criação de conexões VPN para muitas redes de clientes diferentes exigiria um esforço de configuração potencialmente enorme e poderia exigir que você mantenha um servidor por cliente, porque os clientes diferentes terão diferentes requisitos de software VPN que podem ser mutuamente incompatíveis. A opção de segurança avançada é uma licença de custo extra em cima da licença Oracle Enterprise Edition que o cliente teria que sair e comprar (e não seria barato). Você só chegaria ao ponto de se preocupar em obter um certificado SSL apropriado uma vez que todos esses outros aros tivessem sido saltados. A troca de certificado SSL pareceria como a parte mais fácil de todo o processo.

e isso é apenas para suportar a Oracle. O suporte para outros bancos de dados envolverá uma série semelhante de etapas, mas o processo exato tenderá a ser um pouco diferente.

Eu tenderia a esperar que você seria melhor servido, dependendo do problema de negócios que você está tentando resolver, criando um produto que seus clientes poderiam instalar em seus próprios servidores dentro de sua rede que se conectariam a um banco de dados E teria uma interface que enviaria dados para o seu servidor central por meio de algo como https post chamadas ou que ouviria solicitações HTTPS que pudessem ser enviadas ao banco de dados e os resultados retornados por http.

Answer 2

SSL é muito importante para manter o banco de dados de um cliente seguro.Mas há mais do que apenas isso.Você deve garantir que cada conta do banco de dados esteja bloqueada.Cada cliente deve ter acesso apenas ao seu próprio banco de dados.Além disso, todo banco de dados possui outros privilégios que são desagradáveis.Por exemplo, o MySQL tem FILE_PRIV que permite que uma conta leia/grave arquivos.MS-SQL tem xp_cmdshell que permite ao usuário acessar cmd.exe do sql (por que eles fariam isso!?).O PostgreSQL permite que você escreva procedimentos armazenados em qualquer linguagem e a partir daí você pode chamar todos os tipos de funções desagradáveis.

Depois, há outros problemas.Uma consulta malformada pode causar estouros de buffer, o que dará ao invasor as chaves do reino.Você precisa ter certeza de que todos os seus bancos de dados estão atualizados e então rezar para que ninguém perca o dia 0.