Estou tentando descobrir a melhor abordagem para lidar com solicitações externas. Estou trabalhando em um sistema em que o aplicativo está atualmente do lado de fora (DMZ) e o BD está dentro. A porta específica necessária para acesso ao BD foi aberta da máquina DMZ para a máquina BD.
Após discutir com minha equipe, concordamos que a DMZ não deveria se conectar diretamente ao DB. Após mais discussões, selecionamos as duas abordagens a seguir como possíveis soluções.
Para mim, ambos parecem ser iguais no que diz respeito à segurança, já que temos os mesmos protocolos de comunicação sendo usados e o mesmo número de camadas.
Meu entendimento está correto? Se sim, seria Ba opção mais lógica? Asignificaria que temos um serviço de acesso a dados personalizado que lida com solicitações do APPe lê/grava dados.
Por fim, se optarmos por B, seria recomendável que ainda usássemos o , Data Access Servicemas seria interno (ou seja APP -> Data Access Service -> DB)
Não importa se o aplicativo está atrás de um proxy reverso ou diretamente na DMZ, ele provavelmente tem algumas vulnerabilidades. O Data Access Service extra envolve a comunicação do banco de dados e a limita a certas chamadas de API estruturadas em vez de permitir consultas brutas ao banco de dados. Portanto, ele protege o banco de dados de vulnerabilidades no aplicativo.
Não direi que nunca faça uma conexão IP com um SGBD em uma zona de firewall diferente, mas é difícil fazer isso corretamente.
Os DBMS não são normalmente expostos ao tráfego público via rede IP, porque não foram reforçados para tal propósito. Seu protocolo on the wire deve ser bem definido, usando criptografia, autenticação forte e controle de acesso. Mas na prática é muito fácil configurar algo fraco que não deveria estar na internet.
Em contraste com, por exemplo, o ssh, um padrão de internet projetado para redes inseguras e usado na prática em bilhões de hosts na internet.
Ou http. Os verbos http também mapeiam bem para coisas genéricas, então APIs http estão em todos os lugares, inclusive na arquitetura de seu aplicativo proposto. Convenientemente, servidores http bem conhecidos foram fortalecidos após anos de enfrentamento público para serviço de página da web. Como proxies, eles são bem adequados como uma camada de front-end de qualidade de produção.
Embora qualquer uma das suas ideias mova o tráfego do DBMS para uma zona de firewall diferente, também importa o quão maduro o software front-end voltado para o usuário é. Analisar entradas arbitrárias, como solicitações de aplicativos fora do tráfego de rede, é muito difícil de fazer com segurança. Considere um proxy na frente do aplicativo em ambos os casos. Um bom proxy de propósito geral é um transporte reforçado, uma quantidade conhecida em segurança e balanceamento de carga.
Um design de rede ainda melhor pode fazer um pouco mais de segmentação e um pouco menos de confiança. Isole a camada intermediária do aplicativo mais longe do DBMS. Não há razão para que o aplicativo, por exemplo, obtenha um shell para o DB, então negue ssh e outros protocolos não utilizados com regras de firewall.