Endurecimiento de la información general de MySQL

La verdad es dura: hay atacantes que pueden analizar fácilmente todo Internet en cuestión de minutos y descifrar contraseñas en cuestión de segundos. Aunque a veces es necesario dejar una base de datos accesible a través de una red IP pública, esto hace que tu base de datos sea cada vez más vulnerable. Una forma de mitigar los riesgos de la IP pública es restringir el acceso a la base de datos a un conjunto limitado de direcciones IP.

Dicho esto, la mejor solución es permitir únicamente el acceso dentro de una nube privada virtual (VPC) y únicamente permitir las conexiones de operadores dentro de una pasarela de aplicaciones. En Google Cloud, esta solución se denomina IP privada. Si solo se puede acceder a tu instancia de MySQL dentro de una VPC, un atacante tendrá que acceder a la VPC primero para intentar infringir la instancia.

Todas las versiones secundarias de MySQL tienen notas de la versión y casi siempre incluyen una sección relativa a las actualizaciones de seguridad. Si tu instancia tiene varias versiones obsoletas, hay varias versiones de correcciones de seguridad que no tiene la base de datos.

Además de solucionar los problemas de seguridad con el tiempo, MySQL también introduce varias funciones de seguridad completamente nuevas. Por ejemplo, MySQL 8.0 introdujo muchas formas de endurecer los esquemas y los usuarios de MySQL, como los roles, el seguimiento de inicio de sesión fallido y las generaciones de contraseñas aleatorias.

Imagina que estás trabajando en una cafetería y quieres hacer algunas consultas para conectarte a MySQL a través de la red Wi‐Fi gratuita. Si no usas TLS (Seguridad en la capa de transporte), lo que haces es decir tu nombre de usuario y contraseña a través de TCP (el protocolo de control de la transmisión, uno de los principales protocolos de Internet). Aplica TLS en tu instancia de MySQL y trabaja con tu café con leche al lado sin preocuparte de que otros clientes estén espiando en la red.

Inyección de SQL

A menudo, no es la base de datos, sino la aplicación la que es más vulnerable a un ataque. Muchas aplicaciones han sido víctimas de ataques de inyección de SQL, que es el momento en el que un atacante inserta una entrada maliciosa que la aplicación cree que es una declaración SQL válida. La mejor protección contra estos ataques es usar declaraciones preparadas al crear declaraciones SQL en lugar de concatenar entradas de usuario con declaraciones SQL.

Secretos en tu repositorio

Se han vulnerado la seguridad de innumerables bases de datos porque un desarrollador ha introducido su nombre de usuario y contraseña por error en su repositorio de código fuente. En vez de eso, usa una herramienta como Secret Manager de Google Cloud, que gestiona todo tipo de secretos, incluida la contraseña de la base de datos.

Contraseñas de registro

Por último, utiliza las herramientas de filtrado del framework de registro para excluir la contraseña de tu base de datos de los registros de la aplicación. Por ejemplo, en los filtros Log4j o en Rails ParameterFilter, pero la mayoría de los frameworks de registro deberían tener un equivalente. Si no lo haces, asegúrate de que los registros de la aplicación estén protegidos para que tu base de datos esté protegida.

Te recomendamos que utilices 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 aplicación, hazlas largas y complejas, y rótalas con frecuencia. Los administradores de secretos son especialmente útiles, de modo que no es necesario memorizar contraseñas complejas y que cambian con frecuencia. 

Si las personas utilizan una aplicación de base de datos y no una aplicación, sigue los estándares de NIST, y da prioridad a la longitud de las demás. Las fechas de vencimiento de las contraseñas y los requisitos de contraseña, que son excesivamente complejos, suelen provocar que las personas deleguen su memoria en archivos de texto sin formato y en notas adhesivas, lo que socava todo el objetivo de estas reglas. 

De hecho, te recomendamos que utilices la autenticación de IAM para los usuarios que no utilizan aplicaciones. La autenticación de IAM delega el establecimiento de conexión a la oferta de IAM de Google Cloud, lo que significa que se mitiga el riesgo solo al usuario de IAM, en lugar del usuario de IAM y al usuario de la base de datos.

Por último, el hash predeterminado de MySQL, no salt, la contraseña de la base de datos. Esto significa que los usuarios con la misma contraseña tendrán cadenas de autenticación idénticas, trivializando las quiebras débiles con un ataque de tabla de arcoíris. Observa que los dos usuarios de MySQL que se indican a continuación tienen el mismo valor de authentication_string.

Te recomendamos que asignes a la marca default_authentication_plugin el valor cache_sha2_password. De este modo, se garantiza que dos usuarios con la misma contraseña tengan un hash diferente. Observa que los dos usuarios tienen valores de Authentication_string diferentes en el siguiente ejemplo.

Limitar el acceso no solo garantiza el acceso desde el exterior; también implica auditar periódicamente el acceso desde dentro.

Audita tu aplicación: si solo lee las tablas de facturación, productos y clientes, ¿necesitas realmente acceso a todo lo demás? Si permites el acceso raíz a tu base de datos, los atacantes podrían sufrir graves daños. Piensa en todos los requisitos que tiene tu instancia, desglosa los privilegios que necesita y, a continuación, crea un usuario de base de datos para cada uno. Si un atacante vulnera tu base de datos con uno de estos usuarios, tendrás el alcance de los daños.

Audita a los usuarios: ¿Cuántos de los usuarios de tu base de datos necesitan ver privilegios de administrador en tus instancias? ¿Cuántos de estos usuarios siguen en tu organización o están vinculados a proyectos inactivos o están inactivos? Los tokens de acceso pueden filtrarse y la amenaza interna es una preocupación permanente para la mayoría de los sistemas. Si tienes el menor número de usuarios posible, puedes proteger mejor tu instancia contra este tipo de problemas.

Audita a los administradores: recomendamos quitar el nombre de usuario, como "raíz" o "administrador", o cambiarle el nombre. Se trata de objetivos sencillos para los atacantes y, si no existen, tu sistema es mucho más difícil de infringir. Esto se denomina seguridad a través de la oscuridad y, aunque no debe ser la primera línea de defensa, puede añadir una capa fina de seguridad a tu base de datos de MySQL.

Las copias de seguridad de datos y los planes de recuperación de datos verificables son esenciales para la gestión de bases de datos en buen estado. Pero incluso si tienes copias de seguridad normales, puedes perder todos los datos escritos después de la última copia de seguridad. Una de las ventajas del ecosistema de MySQL es la recuperación a un momento dado (PITR), que te permite recuperar datos en cualquier momento. Para que el PITR sea posible, habilita los registros binarios en tus instancias de Cloud SQL para MySQL.

Si has seguido todos los consejos anteriores, estás bien preparado y bien protegido. Dicho esto, ningún diseño de seguridad estaría completo sin una vigilancia continua: auditoría de bases de datos. El complemento de auditoría de Cloud SQL para MySQL te ayuda a hacer un seguimiento de comportamientos inusuales en caso de que se produzca una quiebra de seguridad.

Con todo lo anterior, has hecho que cualquier ruta a una quiebra de seguridad de base de datos sea mucho más difícil para un atacante. Un atacante podría infringir tu aplicación y esperar que el usuario de la base de datos tenga los privilegios suficientes para sufrir el ataque, o bien haber tenido que escapar de tu VPC y encontrar un nombre de usuario que haya pirateado la contraseña y esperas que el usuario tenga suficientes privilegios para ejecutar su ataque. Mientras tanto, puedes ver los registros de base de datos MySQL o de auditoría para monitorizar cualquier comportamiento habitual en la base de datos y tomar las acciones pertinentes.

Esto es lo que significa "seguridad por diseño". Los atacantes seguirán buscando formas de explotar las máquinas. Por eso, es importante que diseñes tu sistema con el mayor número de capas de protección posible para proteger tu base de datos.