EC2 e segurança do MySQL

Question

A infraestrutura atual contém dois servidores localizados no Amazon EC2: servidor de aplicativos e servidor MySQL.

Preocupação: segurança de comunicação entre o servidor de aplicativos e o banco de dados, sem prejudicar o desempenho.

Configuração atual: o servidor MySQL tem um IP elástico, que o aplicativo usa para se conectar ao servidor. A razão é que o IP interno muda na reinicialização, enquanto o elástico permanece constante. A conexão no MySQL é protegida por firewall para o servidor de aplicativos, e o próprio MySQL tem o usuário atribuído ao IP do servidor de aplicativos.

Idealmente, queremos que os dois servidores se comuniquem usando os IPs internos. Preferimos não implementar a comunicação por SSL, por motivos de desempenho.

Perguntas:

1. Estou correto em dizer que um ataque man-in-the-middle é possível, porque a comunicação acontece na rede que usa os IPs elásticos?

2. Qual o impacto de um desempenho implementando a comunicação SSL entre os dois servidores?

3. Existe uma alternativa, além do script personalizado, para lidar com as alterações no IP interno?

4. Sem SSL, um ataque man-in-the-middle ainda pode ocorrer pela rede interna, de um vizinho do EC2?

Answer 1

Usar um VPC resolverá muitos dos seus problemas, pois os endereços IP privados serão estáticos lá. A Amazon está incentivando strongmente as pessoas a migrarem para o VPC por motivos como este. Depois de ter um, seus dois sistemas devem poder falar pela rede interna da AWS.

Para responder à sua pergunta sobre a exposição ao longo do aws-public < --- > rota aws-public, é teoricamente exposta. No entanto, é provável que tudo ocorra sobre o fabric interno de switches da Amazon, de modo que a exposição a bad-actors seja provavelmente a mesma que seria para o roteamento de tráfego interno.

    

Answer 2

Como recomendado na resposta do sysadmin1138 , esse tipo de situação explica por que as VPCs foram adicionadas ao Amazon Web Services: assim você pode tem uma intranet privada entre instâncias do EC2. Na minha opinião, essa é a parte 1 da solução: colocar seu servidor de banco de dados em um VPC com seu servidor de aplicativos e permitir acesso apenas ao servidor de banco de dados da rede interna (não voltada para a Internet) e rejeitar acesso ao TCP 3306 da rede externa (voltada para a Internet).

O segundo passo é "sim, você deve usar SSL e não, os custos de desempenho não são muito significativos". Você pode certamente testar conexões com seu banco de dados sobre SSL versus texto simples, mas a sobrecarga será relativamente pequena na melhor das hipóteses. Seu custo real de desempenho varia de acordo com o uso.

Seu aplicativo:

1. Criar novas conexões com o banco de dados para cada operação SQL?
   • Em caso afirmativo, você terá mais um custo de desempenho, embora ainda seja relativamente menor.
2. Cache / pool de várias conexões de banco de dados e reutilizá-las conforme necessário?
   • Se sim, não há quase nenhuma razão para não usar SSL.

Pessoalmente, se eu tiver a opção de usar SSL, eu uso SSL. A utilização de chaves RSA de 2048 bits versus chaves RSA de 4096 bits pode acelerar o tempo inicial de handshake, bem como reduzir a lista de cifras para tempo de aceleração até o primeiro byte ; você terá que inspecionar quais são suas opções para o MySQL.

Em uma nota de segurança, use códigos com PFS e não use SSLv3; use somente TLSv1.2 se puder (ou seja: se você estiver executando qualquer versão do MySQL / SSL posterior a 2008). Eu não tenho certeza do quanto o MySQL permite que você personalize isso.

TL; DR : Exponha sua porta MySQL pela rede interna da VPC ao seu servidor de aplicativos, definitivamente use SSL, mas faça um benchmark se você estiver preocupado com a velocidade e se não estiver reutilizando conexões.