A sabedoria de expor um servidor de banco de dados na internet?

Question

A liderança da pequena empresa em que trabalho ficou muito empolgada com o SaaS e está impulsionando nosso produto para uma implantação de SaaS - tenho uma preocupação sobre isso porque parte da funcionalidade do produto é baseada na capacidade de os usuários use ferramentas de business intelligence para gravar relatórios no banco de dados subjacente do aplicativo.

Quando pergunto como planejamos fornecer essa funcionalidade no modelo SaaS, sou recebido com olhares em branco e a resposta é simplesmente que exporemos o servidor de banco de dados na Internet e permitiremos que as pessoas consultem o banco de dados como se fosse estavam funcionando dentro de sua rede corporativa.

Isso assusta os bejeebers fora de mim, mas eu não sei se estou apenas sendo paranóico, ou se há motivos significativos para me preocupar.

Então, minha pergunta é: é possível endurecer adequadamente a segurança de um servidor de banco de dados Oracle para que não precisemos nos preocupar com o fato de que ele ficará exposto na Internet? E, em caso afirmativo, que recursos eu deveria estar pesquisando para aprender a fazer isso? O banco de dados armazenará informações proprietárias que nossos clientes não gostariam de expor ao mundo e, no entanto, uma proposta para colocar essa funcionalidade por trás de uma VPN foi totalmente rejeitada.

Minhas pesquisas sobre o endurecimento de um banco de dados oracle têm praticamente todas as declarações incluídas ao longo das linhas de "Nunca faça um buraco no seu firewall", então pode ser que a resposta correta seja "Atualize seu currículo o mais rápido possível" , mas agradeço qualquer conselho que você possa dar.

    

Answer 1

Expor um banco de dados não é realmente um problema gigante comparado a alguns dos outros serviços que são frequentemente expostos ao mundo + cão ... exceto que é um sistema complicado com muitas vulnerabilidades potenciais , incluindo escalonamento de permissões. Eu me certificaria de que você não exponha o banco de dados a consultas públicas e execute com SSL necessário, etc. Eu diria que é possível, mas sim, você deve ser paranóico e manter uma instalação de banco de dados separada para o público. Se a sua empresa não está disposta a pagar os custos de licenciamento para isso, sim, skedaddle.

Do lado do cliente / suporte, conectar-se diretamente ao banco de dados pode ser um problema se o ISP do cliente bloquear determinados tipos de portas ou tráfego.

Em um modelo SaaS, o que você geralmente quer que seus programadores façam é escrever uma API que possa ser consultada no aplicativo. APIs dessa natureza normalmente operam em https e fornecem dados de volta ao aplicativo na resposta HTTP. Bônus adicional: Ele funciona em qualquer lugar onde a web funciona, é MUITO fácil armazenar conjuntos de resultados em cache usando memcached ou outras tecnologias de cache para reduzir a carga no servidor db, e a autenticação http é bastante bem suportada e testada.

    

Answer 2

Eu configuraria um segundo servidor de banco de dados na DMZ e importaria despejos para esse banco de dados e disponibilizaria essa publicidade de banco de dados.

    

Answer 3

Como tenho certeza de que você concordará, praticamente por definição o acesso e a segurança são uma desvantagem. E você está sendo encarregado de disponibilizar dados confidenciais.

A resposta curta é que você pode atenuar muitos riscos com truques de firewall, arquitetura de rede sólida, conjuntos de patches atualizados, auditoria de acesso e backups copiosos.

O gerenciamento de senhas também é uma tarefa complicada, geralmente as contas de aplicativos têm senhas que nunca expiram e controles de acesso físico / de rede são colocados em prática para garantir que ex-funcionários com conhecimento de senha não tenham acesso ao dados. Se o seu servidor de banco de dados é exposto a toda a Internet, isso parece algo que seria difícil de fazer.

Você provavelmente também desejará definir um 'estamos comprometidos, o que fazemos agora?' estratégia, para que você ajuste as expectativas para todos os envolvidos e tenha um plano de ação para quando a sua sorte acabar.

    

Answer 4

Eu diria para usar os serviços da API ou da Web, com os serviços da Web preferidos, pois deve haver mais flexibilidade na qual os usuários finais (clientes) se conectam a eles.

Parte 2, a gerência vai dizer "nozes para isso, precisamos obter mercado agora!" e não quer gastar dinheiro desenvolvendo isso.

Parte 3, você precisa convencer o gerenciamento do motivo pelo qual expor o banco de dados diretamente é ruim, e depois criar um monte de white papers, relatórios de segurança, etc. Além disso, se eu estava pensando em usar seu software e SaaS , gostaria de saber tudo sobre a sua segurança e, assim que descobrisse, você está expondo o banco de dados o acordo está cancelado.

    

Answer 5

SaaS é mercadoria.

Expondo um servidor de banco de dados à Internet - não tão bom.

Por que eles precisam ser expostos? É por causa do RPC e eles não querem usar portas RPC Estáticas?

Mas existem alguns ótimos firewalls de aplicativos e se você bloquear a porta endmapper do BD e depois o firewall - você pode fazer coisas boas com ACLs, restrições de IP, etc.

E você precisará auditar logs de eventos, verificações de vulnerabilidades, etc.

    

Answer 6

Mantenha o servidor de banco de dados em segurança atrás do firewall. Se necessário, escreva os serviços da web que residem em um site público que tenha um túnel para o servidor de banco de dados. Certifique-se de que os serviços da Web tenham acesso limitado ao banco de dados. Se o requisito é que eles estão fazendo relatórios, os serviços da Web precisam apenas de acesso somente leitura. Eu provavelmente criaria exibições dos dados que queria apresentar e concederia acesso de leitura a eles, e não às próprias tabelas subjacentes.

Como Rob disse, faça uma auditoria de tudo, execute varreduras de vulnerabilidades, inclua o registro de acesso nos próprios aplicativos de serviço da web, para que você possa ver quem acessou o que e quando.

    

Answer 7

Usamos vários aplicativos SaaS no curso de nossos negócios e eles fazem isso de duas maneiras.

1. Fornecer recursos de relatórios baseados na web
2. Permitir a exportação do banco de dados em um formato padrão para o cliente escrever seus próprios relatórios "offline" (CSV, MDB, etc)
3. Exponha os dados subjacentes por meio de serviços da web

Além da segurança, você precisa se preocupar com o desempenho em um sistema multi-tantante. Você não deseja que um relatório mal escrito de um usuário no Crystal afete todos os outros usuários de relatórios.