¿Cuándo es apropiado para SSL encriptar las conexiones de la base de datos?

Parece que las dos respuestas anteriores a esta pregunta recomiendan una mayor o menor recomendación de activar SSL de todas formas, pero me gustaría sugerir un ángulo de razonamiento diferente (aunque no recomiendo no activar SSL).

Los dos puntos clave para evaluar si necesita SSL o no son (a) contra qué SSL lo protege y (b) cuál es el modelo de subproceso: enumere las amenazas potenciales.

SSL / TLS protege el transporte de información entre un cliente (en este caso, su servidor web) y un servidor (en este caso, su servidor de base de datos) de manipulaciones y escuchas ilegales por parte de cualquier persona en la red que se encuentre en medio (incluido el poder ponerse en esas dos máquinas).

Para evaluar si el SSL es útil, debe asumir que el atacante está en condiciones de realizar el ataque. SSL está diseñado para protegerlo. Es decir, el atacante tendría que estar en posición de detectar paquetes en la red o en cualquiera de las máquinas.

• Si alguien que está en posición de detectar paquetes del servidor de la base de datos, es probable que tenga acceso de administrador / administrador a ese servidor. El uso de SSL / TLS en esa etapa no hará ninguna diferencia.

• Si alguien está en posición de detectar paquetes en la red entre el servidor web y el servidor de la base de datos (excluyendo esas máquinas), el uso de SSL / TLS evitará que vean / alteren el contenido de la aplicación. Si cree que existe la posibilidad de que esto sea posible, active SSL . Una forma de mitigar esto sería usar dos tarjetas de red en el servidor web: una para el mundo exterior y otra para la LAN interna donde se encuentra el servidor de DB (sin otras máquinas, o de manera que pueda tratarlas a todas como si fueran una sola máquina más grande). Esta red que forma la agrupación o conjunto de servidores web en general (como quiera que se llame) estaría separada físicamente y solo tendría un punto de entrada desde el exterior: el servidor web en sí (el mismo principio para un nodo de cabeza de proxy inverso).

• Si alguien está en posición de rastrear paquetes en el nodo principal (el servidor web), es probable que tengan acceso a la raíz allí (los procesos ejecutados por usuarios no root en la máquina, no deberían poder leer paquetes que no son para ellos). En este caso, tendría un gran problema de todos modos.

  Lo que dudo aquí es si habilitar SSL realmente te protege mucho en este escenario.

  Alguien con acceso root en el servidor web podrá leer la configuración de su aplicación, incluidas las contraseñas de DB, y debería poder conectarse al servidor de DB de forma legítima, incluso utilizando SSL.

  En contraparte, si asumió que esto garantiza el uso de SSL (porque podría ser más difícil ver qué hacen los procesos en lugar de solo mirar la red, incluso si tiene control de raíz en la máquina), esto significaría que también querría recurrir a las comunicaciones de host local (por ejemplo, si tiene otros servicios en su servidor web, o en la situación en la que tanto el servidor de base de datos como el servidor web estuvieran en la misma máquina).

No es necesariamente algo malo ser demasiado cauteloso, pero debe hacer su pregunta en el contexto de qué podrían hacer los atacantes si estuvieran en condiciones de realizar un ataque contra lo que protege la medida de seguridad (SSL) está en contra, y si esta medida de seguridad les impediría alcanzar su objetivo de todos modos, una vez en esta posición.

Creo que la ventana es bastante estrecha allí (suponiendo que su red de back-end realmente esté asegurada, físicamente, no solo por un firewall entre varias máquinas).

Cuando la red local que incluye el servidor de base de datos y los clientes puede incluir otros procesos, debe cifrar la conexión entre los dos.

Este es casi siempre el caso, ya que incluso si asume que la red local es impenetrable (no debería), además del cliente y el servidor de la base de datos, por lo general hay

1. los administradores que necesitan poder iniciar sesión y solucionar problemas o hacer actualizaciones
2. los recolectores de registros que necesitan capturar archivos sin datos confidenciales y moverlos a otra parte
3. los replicadores que necesitan copiar el contenido de la base de datos para realizar copias de seguridad fuera del sitio o para alimentar grandes tablas de baja sensibilidad a los sistemas de minería de datos
4. monitores que necesitan verificar para ver si los otros aún están vivos

De ellos, solo los replicadores deben tener acceso a las tablas con datos confidenciales, pero cualquiera de estos procesos puede verse comprometido por los malos actores dentro de su departamento de TI.

El cifrado de todos los canales que llevan datos confidenciales mantiene a las personas honestas honestas, le brinda una defensa profunda y le ayuda a limitar la búsqueda cuando surgen problemas.

Tenga en cuenta que cualquier persona que esté en la misma red que su servidor podría ser capaz de detectar el tráfico o realizar un ataque de intermediario. SSL debería evitar esto, asumiendo que está configurado correctamente. También debe configurar un firewall en el servidor de base de datos y solo permitir conexiones desde direcciones IP confiables.

Mi sugerencia es activarlo, luego desactivarlo solo si cree que está causando problemas de rendimiento (u otros). De esa forma, habrá reducido significativamente los vectores de ataque.

En realidad, la sobrecarga del cifrado SSL en la red será mínima, especialmente cuando se compara con la carga de procesamiento de consultas SQL. Obtendría más rendimiento al optimizar sus consultas y la configuración del rendimiento del servidor que deshabilitando SSL.

  

Supongamos que tengo un servidor web que instalo y luego un servidor de base de datos ... me comunico localmente y estoy detrás del firewall

Dejando de lado el hecho de que esta arquitectura apesta en términos de disponibilidad ...

• ¿confías en todos y en todo "detrás del firewall"?
• ¿Crees que tu firewall es perfecto?
• ¿puede predecir que nunca necesitará conectarse de forma remota para admitir una mayor disponibilidad, migrar su centro de datos o realizar una copia de seguridad?
• ¿Es el mecanismo de autenticación predeterminado para los dbms tan seguro que no se puede subvertir?
• ¿Tiene un proceso de implementación que garantice que las credenciales de la base de datos no puedan verse comprometidas?

Si su respuesta a cualquiera de estas preguntas no es definitiva, puede beneficiarse de las garantías adicionales de utilizar una conexión SSL configurada adecuadamente. El costo de rendimiento es insignificante incluso sin depender de conexiones persistentes (aunque esto también puede eliminarse al enrutar el tráfico a través de un túnel persistente). Se reduce a simplemente calcular si el costo de configurar el SSL (un par de horas de trabajo) es más que la responsabilidad.