Os servidores de produção devem ter acesso aos servidores de banco de dados?

2

Atualmente, nossa empresa possui um cluster voltado para clientes para nossas inscrições e gerenciamento de contas de clientes que têm acesso direto ao banco de dados ativo (um mestre e vários escravos somente para leitura).

Nós tivemos algumas discussões recentemente sobre como melhorar a segurança dessa configuração (além dos firewalls existentes). A ideia (vinda do gerenciamento) é que os servidores de produção não devem ter acesso direto de leitura ou gravação no banco de dados, mas que algo deve ser executado a partir do servidor de banco de dados ou de algum outro servidor interno que se conecta aos servidores de produção e solicita informações de alguma fila temporária existente lá.

Então

Atualmente:

O aplicativo grava novas inscrições no db Aplicação lê dados sobre clientes do banco de dados

(App -> DB)

Proposta:

O aplicativo grava novas inscrições no cache local temporário (pode ser sistema de arquivos, banco de dados temporário, memcached, etc) Cron / daemon da rede interna conecta o OUT ao servidor de aplicativos e busca solicitações db enfileiradas Cron / daemon grava novos dados em db ou lê dados antigos do banco de dados conforme solicitado

Cron / daemon envia de volta o resultado para o servidor de aplicativos

(App <- Daemon -> DB)

Como um desenvolvedor (não um administrador de sistema), isso parece ridículo para mim, mas eu admito prontamente não ser um especialista em segurança. Como alternativa, propus que, se não pudermos ter acesso direto ao banco de dados, poderíamos ter uma camada intermediária que aceita solicitações estruturadas e gera consultas de banco de dados e retorna os dados. Isso seria algo parecido com

(App -> Proxy -> DB)

A resposta da gerência é que isso é sub-ótimo (mas ainda está aberto para debate).

Suponho que esse tipo de argumento tenha ocorrido muitas vezes em muitos lugares, mas não vi nada que abordasse especificamente os prós ou contras de sua arquitetura proposta. A abordagem proxy reversa proposta é realmente tão mais segura que vale a pena construí-la? Se não, o que seria usado para fazer backup do seu argumento se você fosse solicitado a implementar tal arquitetura.

    
por Rob Van Dam 06.11.2010 / 02:39

2 respostas

4

Qual vulnerabilidade específica eles estão procurando atenuar? Parece muito sobrecarga extra e complexidade (o que inevitavelmente leva a problemas de um tipo ou outro).

Se os servidores de aplicativos ainda tiverem acesso aos servidores de banco de dados, por meio de um proxy ou outro intermediário, um servidor de aplicativos com raiz ainda poderá criar uma solicitação que melhore o banco de dados. Eu não vejo nenhuma segurança adicional específica na proposta; talvez eu esteja sentindo falta de algo.

A segurança não é uma "coisa" nebulosa ou fungível que você pode adicionar através da obscuridade ou da complexidade. Segurança é medida (s) específica (s) tomada (s) para mitigar ameaça (s) específica (s).

    
por 06.11.2010 / 03:11
2

Os servidores de produção não devem ser externos. O modelo típico é um modelo de três zonas, Externo, DMZ (zona desmilitarizada) e Interno. Externo nunca deve poder acessar Interno. No entanto, os servidores de produção devem estar na DMZ. Os servidores DMZ devem ter acesso limitado à rede interna. O acesso da DMZ deve ser uma base de privilégio mínimo.

Para este tipo de aplicativo, eu daria acesso a serviços na rede interna que executam as ações necessárias. Estes devem ser um conjunto limitado de ações que podem atualizar os dados de um cliente por vez.

O acesso genérico do DMZ arrisca seus dados se alguém invadir um servidor da web de produção.

    
por 06.11.2010 / 03:40