Pregunta Conexión segura a MySQL - SSL vs Stunnel vs SSH Tunneling de MySQL


Tenemos una aplicación PHP que se conecta a un servidor MySQL, y deseamos asegurar las conexiones entre los servidores web y de aplicaciones y la base de datos.

En las horas punta, los servidores web realizan cientos de conexiones simultáneas a la base de datos y realizan muchas lecturas y escrituras pequeñas. Soy consciente de que esto no es óptimo y estoy trabajando para reducir el número de conexiones de base de datos en paralelo a esto.

Actualmente no tenemos conexiones permanentes con la base de datos activada, y aunque tenemos la intención de hacerlo en el futuro, me gustaría implementar esto independientemente de eso.

En cuanto al hardware, el servidor MySQL es bastante grueso (16 núcleos) al igual que los servidores web. Son servidores dedicados.

Mi pregunta rodea la forma más eficaz de asegurar y cifrar las conexiones al servidor de base de datos.

Mi investigación hasta ahora ha sugerido que la sobrecarga principal del rendimiento es con la configuración de la conexión SSL: una vez que se conecta SSL, hay poca penalización en el rendimiento. Y esto es lo que tengo sobre cada método para asegurar la conexión:

  1. Certificados SSL de MySQL: funciona como SSL normal. Puede utilizar certificados de cliente para evitar conexiones no autorizadas. No hay conexiones persistentes con nuestra configuración existente. Todavía tengo que tener MySQL escuchando en un puerto abierto en el firewall.
  2. stunnel Configurar un puerto a puerto ssl tunnel. No tienes que reconfigurar MySQL. Puede cerrar el puerto de escucha normal de MySQL para evitar intentos de conexión maliciosos de MySQL. No soporta conexiones persistentes. Golpe de rendimiento desconocido.
  3. SSH Tunneling. Cree un túnel SSH entre el cliente y el servidor. No tienes que reconfigurar MySQL. Puede cerrar el puerto de escucha normal de MySQL para evitar intentos de conexión maliciosos de MySQL. Soporta conexiones persistentes, pero estas a veces abandonan. Golpe de rendimiento desconocido.

Esto es lo que he podido conseguir. Soy consciente de las limitaciones de los puntos de referencia: en mi experiencia de ejecutarlos es muy difícil simular el tráfico del mundo real. ¿Esperaba que alguien tuviera algún consejo basado en sus propias experiencias de proteger MySQL?

Gracias


13
2018-04-22 09:39


origen


¿Qué tipo de arquitectura de servidor / red tienes? ¿Qué tipo de escenario estás tratando de prevenir? Si toda la comunicación de servidor a servidor se realiza en un conmutador / VLAN por separado, es posible que no necesite una protección anti-sniff. En cuanto al rendimiento, correr openssl speed y elija cifrados que se ajusten a sus necesidades de protección frente al compromiso de rendimiento. - Marcin
@Marcin - Gracias por la punta de velocidad de openssl. Los escenarios que intento evitar son conexiones no autorizadas a mysql y cifrar la comunicación entre los servidores. Cualquier ayuda adicional que pueda dar comparando los tres enfoques sería recibida con gratitud. - dastra
a 3) usar autossh para reducir el efecto de deserción. Se volverá a conectar automáticamente en caso de una desconexión. Funciona bien aquí en muchas situaciones. - ansi_lumen


Respuestas:


Iría con el túnel ssh y lo haría con autossh en lugar de ssh. Sobre el rendimiento, diría que el protocolo SSH es altamente personalizable y que podría ajustar su conexión, si es necesario.

Pero no esperaría una sobrecarga notable después de que se establezca la conexión.


5
2018-04-29 16:08





Mirando los puntos de referencia de este artículo (MySQL Performance Blog), realmente debería evitar la capacidad SSL nativa de MySQL.


2
2017-10-15 16:02