Descripción general del endurecimiento de MySQL

No disimulemos la verdad: hay atacantes que fácilmente pueden analizar todo Internet en minutos y descifrar contraseñas en segundos. Si bien a veces es necesario dejar una base de datos accesible a través de una red IP pública, esto hace que la base de datos sea exponencialmente más vulnerable. Una forma de mitigar los riesgos de la IP pública es limitar el acceso a la base de datos a un conjunto restringido de direcciones IP.

Dicho esto, la mejor solución es permitir el acceso solo dentro de una nube privada virtual (VPC) y solo permitir conexiones de operadores dentro de un host de bastión. En Google Cloud, esta solución se llama IP privada. Si solo se puede acceder a la instancia de MySQL dentro de una VPC, el atacante primero deberá vulnerar la VPC para intentar vulnerar la instancia.

Cada versión secundaria de MySQL tiene notas de la versión y, de manera casi invariable, contienen una sección sobre las actualizaciones de seguridad. Si tu instancia tiene varias versiones desactualizadas, hay varias versiones de correcciones de seguridad que tu base de datos no tiene.

Además de solucionar los problemas de seguridad con el tiempo, MySQL también presenta varias características de seguridad completamente nuevas de forma periódica. Por ejemplo, MySQL 8.0 introdujo muchas formas de endurecer los esquemas y los usuarios de MySQL, como los roles, el seguimiento de errores de acceso y la generación de contraseñas aleatorias.

Supongamos que trabajas en una cafetería y quieres ejecutar algunas consultas para conectarte a MySQL a través de la red Wi-Fi gratuita de la tienda. Si no usaste TLS (seguridad de la capa de transporte), estás gritando tu nombre de usuario y tu contraseña mediante TCP (el Protocolo de control de transmisión, uno de los protocolos principales de Internet). Aplica TLS en tu instancia de MySQL para que puedas trabajar en tu café con leche sin preocuparte de si otros clientes espían en la red.

inyección de SQL

A menudo, no es la base de datos, sino la aplicación que es más vulnerable a un ataque. Muchas aplicaciones han sido víctimas de ataques de inyección de SQL, en los que un atacante inserta una entrada maliciosa que tu aplicación considera como una instrucción de SQL válida. La mejor protección contra estos ataques es usar declaraciones preparadas cuando se crean instrucciones de SQL en lugar de concatenar entradas del usuario con instrucciones de SQL.

Secretos en su repositorio

Se ha violado la seguridad de innumerables bases de datos debido a que un desarrollador envía inadvertidamente su nombre de usuario y su contraseña a su repositorio de código fuente. En su lugar, usa una herramienta como Secret Manager de Google Cloud, que administra todo tipo de secretos, incluida la contraseña de tu base de datos.

Registra contraseñas

Por último, usa las herramientas de filtrado del framework de registro para filtrar la contraseña de la base de datos fuera de los registros de la aplicación. Los ejemplos incluyen filtros Log4j o Rails ParameterFilter, pero la mayoría de los frameworks de registro deben tener un equivalente. De lo contrario, deberás asegurarte de que los registros de tu aplicación sean seguros para que tu base de datos esté protegida.

Considera usar la validación de contraseñas para asegurarte de que todas las contraseñas de tu base de datos sean lo suficientemente complejas. En el caso de las contraseñas de la aplicación, hazlas largas y complejas, y rótalas con frecuencia. Los administradores de secretos son especialmente útiles para que no tengas que memorizar contraseñas complejas y que cambian con frecuencia. 

Si una persona (y no una aplicación) usa un usuario de base de datos, sigue los estándares del NIST y prioriza la longitud por sobre todo lo demás. Las fechas de vencimiento de las contraseñas y los requisitos de contraseña demasiado complejos suelen generar que las personas deleguen su memoria a archivos sin formato y notas adhesivas, lo que socava el propósito de estas reglas. 

Mejor aún, considera aprovechar la autenticación de IAM para usuarios que no son de aplicaciones. La autenticación de IAM delega el establecimiento de la conexión a la oferta de IAM de Google Cloud, lo que significa que el riesgo se mitiga solo al usuario de IAM, en lugar del usuario de IAM y el de la base de datos.

Por último, la configuración predeterminada de MySQL genera hash, no sal, en la contraseña de tu base de datos. Esto significa que los usuarios con la misma contraseña tendrán strings de autenticación idénticas, lo que facilitará descifrar las contraseñas débiles con un ataque de tabla de arcoíris. Observa que los dos usuarios de MySQL siguientes tienen la misma authentication_string.

Considera configurar la marca default_authentication_plugin como cache_sha2_password. Esto garantiza que dos usuarios con la misma contraseña tengan un hash diferente. Observa cómo los dos usuarios tienen valores de authentication_string diferentes en el siguiente ejemplo.

Limitar el acceso no solo implica proteger el acceso desde el exterior; también significa auditar con regularidad el acceso desde dentro.

Audita tu aplicación: Si solo lee desde las tablas de facturación, producto y cliente, ¿realmente necesita acceder a todo lo demás? Si dejas el acceso raíz disponible para tu base de datos, un atacante puede causar un gran daño a la base de datos. En su lugar, piensa en cada requisito que tiene tu instancia, detalla los privilegios que requieren y, luego, crea un usuario de base de datos para cada uno. Si un atacante viola la seguridad de tu base de datos mediante uno de estos usuarios de la base de datos, habrás limitado el alcance del daño.

Audita a tus usuarios: ¿Cuántos de los usuarios de tu base de datos realmente necesitan privilegios de administrador en tus instancias? ¿Cuántos de estos usuarios aún están en tu organización, están vinculados a proyectos inactivos o están inactivos por sí mismos? Los tokens de acceso pueden tener filtraciones, y la amenaza de usuarios con información privilegiada es una preocupación constante para la mayoría de los sistemas. Asegurarte de tener la menor cantidad posible de usuarios puede ayudarte a proteger tu instancia contra esta clase de problemas.

Audita a tu "admin": considera quitar usuarios o cambiar los nombre como "root" o "admin". Estos son blancos fáciles para los atacantes y, si no existen, tu sistema es un poco más difícil de vulnerar. Esto se denomina seguridad a través de la oscuridad y, si bien no debería ser la primera línea de defensa, puede agregar una delgada capa de seguridad a tu base de datos de MySQL.

Las copias de seguridad de datos frecuentes y los planes de recuperación de datos verificables son fundamentales para la administración de bases de datos en buen estado. Pero incluso con las copias de seguridad regulares, aún puedes perder todos los datos escritos después de la última copia de seguridad. Uno de los beneficios del ecosistema de MySQL es la recuperación de un momento determinado (PITR, por sus siglas en inglés), que te permite recuperar datos en cualquier momento. Para que la PITR sea posible, habilita los registros binarios en tus instancias de Cloud SQL para MySQL.

Si ya hiciste todo lo anterior, te preparaste y te protegiste de buena manera. Dicho esto, ningún diseño de seguridad estaría completo sin vigilancia continua: la auditoría de bases de datos. El complemento de auditoría de Cloud SQL para MySQL te ayuda a hacer un seguimiento de los comportamientos inusuales en caso de incumplimiento.

Con la implementación de lo anterior, habrás hecho que cualquier ruta hacia una vulneración de la base de datos sea mucho más difícil para un atacante. Un atacante tendría que vulnerar tu aplicación y esperar que el usuario de la base de datos tenga suficientes privilegios para su ataque. De lo contrario, tendría que vulnerar tu VPC, encontrar un nombre de usuario existente, descifrar esa información y esperar que el usuario tenga los privilegios suficientes para ejecutar su ataque. Mientras tanto, puedes ver los registros de la base de datos de MySQL o los registros de auditoría para supervisar cualquier comportamiento inusual en la base de datos y reaccionar según corresponda.

Esto es lo que significa el diseño de seguridad integral. Los atacantes seguirán descubriendo formas de explotar máquinas. Por eso es importante diseñar tu sistema con tantas capas de protección como sea posible para mantener tu base de datos protegida.