Os bancos de dados que contêm informações do cliente devem entrar em uma DMZ?

Question

Estamos implantando um aplicativo de newsletter simples em uma plataforma LAMP autônoma na empresa DMZ. Há alguma discussão sobre se o servidor MySQL deve ser removido da DMZ e colocado na rede interna.

O servidor está atrás de um firewall com apenas a porta 80 aberta e o MySql será conectado a uma porta não padrão. O banco de dados contém endereços de e-mail de clientes.

Esta é uma configuração segura (ou segura o suficiente)? Quanto mais seguro seria colocando os dados atrás de um segundo firewall? (Eu sou mais um desenvolvedor, então eu não estou realmente ciente de todos os aspectos de segurança aqui - alguém pode me esclarecer!)

Atualizar Apenas para esclarecimentos e para atrair mais comentários, aqui está nossa configuração atual:

internet - firewall1 - servidor http - firewall2 - appserver - firewall3 - recursos corporativos

Este novo aplicativo deveria estar completamente dentro da DMZ entre os firewalls 1 e 2. Atualmente, estamos discutindo a remoção do servidor MySQL atrás do segundo firewall.

    

Answer 1

Para permitir conexões da DMZ para a LAN interna está quebrando o conceito de uma DMZ.

Ligar o MySQL ao localhost não será menos seguro do que colocar o MySQL em outro lugar. Se o roubo de dados for sua preocupação, você deve assumir que as duas máquinas foram separadas e a parte do Apache foi comprometida, então os detalhes da conexão do MySQL armazenados na máquina comprometida poderiam simplesmente ser reutilizados por um invasor para ler os dados de qualquer maneira. / p>

Editar para adicionar:

Mesmo com uma DMZ de salto duplo, como você descreve, você não está se beneficiando de qualquer segurança real ao separar os serviços, ao mesmo tempo em que torna a configuração mais complicada. Você possivelmente está aumentando a superfície de ataque tendo mais máquinas e enviando dados pelo fio que, de outra forma, estaria em loopback.

    

Answer 2

Eu colocaria o banco de dados na rede interna (atrás de um segundo firewall).

Isso reduz enormemente a superfície de ataque do banco de dados porque você define as regras de firewall para o segundo firewall (DMZ para Interno) para SOMENTE permitir conexões na porta XXXX (a porta DB) do servidor web.

Portanto, mesmo que sua DMZ esteja comprometida, ainda há proteção para seu banco de dados.

    

Answer 3

Eu acho que a parte do MySQL foi adequadamente coberta e eu certamente concordo com o que já foi dito. Gostaria apenas de salientar que, como primeiro passo, você deve descobrir quais são os requisitos legais em sua parte do mundo, pois eles variam consideravelmente. Muito possivelmente isso determinará sua configuração.

    

Answer 4

O servidor de banco de dados deve ser protegido por firewall a partir de qualquer conexão com a Internet externa, para que apenas o servidor do aplicativo (mais qualquer coisa necessária para administração) possa se conectar ao banco de dados. Se for separado do servidor de aplicativos, há várias razões para isso: configure o firewall e a segurança adequadamente.

O comprometimento do servidor de aplicativos provavelmente tornará as credenciais de login do aplicativo disponíveis para o invasor do BD, portanto, algum nível de segurança do nível do banco de dados ou do aplicativo pode ajudar. Por exemplo, você poderia fazer algum tipo de separação de responsabilidades ao longo das linhas de:

Configure a propriedade do objeto DB para que o aplicativo não possa ler diretamente os dados do cliente, mas deve passar por um procedimento armazenado. Números completos de cartão de crédito podem ser gravados somente - um sproc pode permitir que eles sejam atualizados, mas apenas ler os últimos 4 dígitos da tela 'detalhes da atualização'. Qualquer coisa que necessitasse do número CC poderia estar em um servidor diferente e conectar-se por meio de uma conta diferente.

Se as finanças são gerenciadas em um servidor fisicamente diferente (talvez com firewall da internet pública), você pode, na melhor das hipóteses, emitir ordens falsas ou semelhantes sem comprometer o servidor. A obtenção de informações de cartão de crédito exigiria o comprometimento de duas máquinas (o servidor de aplicativos e o servidor de banco de dados ou o servidor financeiro). Você também teria que lançar o ataque do servidor web comprometido. Isso fornece uma janela mais longa para detectar atividades, pois o invasor não pode comprometer as duas máquinas simultaneamente.

As máquinas servidoras DB e financeiras também têm um conjunto muito específico de interações com o servidor da web. Isso permite que você presuma que a maioria das atividades, se não todas, não relacionadas a aplicativos é suspeita e configura um IDS nessas máquinas com uma configuração ultra-paranóica.

    

Answer 5

Vamos avaliar os dois cenários e ver qual deles é melhor. Eu suponho que você configurou a conta MySQL para ter acesso somente READ / WRITE às tabelas específicas do aplicativo.

Vou atacar o servidor usando um exploit zeroday. Agora tenho acesso de administrador ao servidor da Web e posso acessar totalmente o sistema de arquivos local. Eu também posso enviar comunicação de rede originária deste servidor web. Eu obtive acesso às credenciais necessárias para acessar o banco de dados do aplicativo.

Se o servidor de banco de dados estiver na mesma máquina, agora também tenho acesso direto e total ao banco de dados. Eu posso ler e gravar em todas as tabelas no banco de dados, criar novas e ouvir todas as outras comunicações com esse servidor de banco de dados. Avaliação: Este é o pior cenário. O banco de dados do aplicativo e todos os outros bancos de dados agora são afetados.

Se o servidor de banco de dados estiver em uma máquina diferente na mesma DMZ, posso me comunicar completamente com o servidor de banco de dados. Agora posso usar uma exploração no serviço Windows File Sharing para obter acesso de administrador a esse servidor. Avaliação: posso acessar o servidor de banco de dados usando a conta do aplicativo da Web, mas isso pode me dar apenas direitos limitados. Eu preciso de uma exploração diferente para obter acesso total ao servidor de banco de dados. Eu posso explorar qualquer serviço disponível no servidor de banco de dados.

Se o servidor de banco de dados estiver em uma rede totalmente diferente, só posso acessar a porta do banco de dados. Qualquer outra comunicação é filtrada por um firewall. Isso significa que só posso usar uma exploração no programa de banco de dados para obter acesso de administrador. Se eu obtiver acesso de administrador, toda a rede interna estará comprometida. Avaliação: posso acessar o servidor de banco de dados usando a conta do aplicativo da Web, mas isso pode me dar apenas direitos limitados. Eu só posso explorar a porta do banco de dados para obter acesso total. Se eu fizer isso, a rede do servidor de banco de dados estará comprometida.

    

Answer 6

Se a máquina estiver comprometida, não importaria se o servidor MySQL estivesse na DMZ ou não. As credenciais para acessar o banco de dados MySQL estarão no código do aplicativo da Web em algum lugar e a máquina na DMZ terá que ter acesso a ele para que os firewalls não mantenham seus dados seguros nesta instância.

Um design melhor pode ser fazer com que o aplicativo da web escreva uma fila que é então puxada para um banco de dados MySQL dentro de sua rede protegida. Isso limitaria a exposição dos dados do cliente ao que está na fila. Apenas pensando em voz alta aqui. Isso pode não funcionar ou ser prático para seu aplicativo específico.

    

Answer 7

Você não permitirá tráfego da DMZ para a rede interna. É uma péssima ideia! Se alguém puder obter o controle do seu aplicativo da web, o dmz, será possível abrir uma conexão com um servidor dentro de sua rede interna e obter controle total sobre toda a sua rede. Se você quiser separar o aplicativo da Web da sua rede, sugiro que você crie outro DMZ e coloque o seu DB lá. O único tráfego permitido para o outro DMZ i do seu servidor web. Eu vi alguns projetos de firewalls terríveis, e este é um deles.

Håkan Winther Senior DBA e ex-proprietário de uma empresa de segurança.