Auditoría de bases de datos MySQL

En este tema se describe la auditoría de bases de datos de Cloud SQL para MySQL y el complemento de auditoría de Cloud SQL para MySQL. Para usar la auditoría de bases de datos ahora, consulta Usar la auditoría de bases de datos de MySQL.

¿Qué es la auditoría de bases de datos?

La auditoría de bases de datos te permite hacer un seguimiento de acciones específicas de los usuarios en la base de datos, como actualizaciones de tablas, consultas de lectura, permisos de usuario y otros. La auditoría de bases de datos es útil para las organizaciones que necesitan tener un registro de la actividad de los usuarios por motivos de seguridad o para cumplir diversas normativas financieras, gubernamentales y de ISO. La auditoría de bases de datos es compatible con Cloud SQL para MySQL 5.7, 8.0 y 8.4.

Plugin de auditoría de Cloud SQL para MySQL

La auditoría de bases de datos se habilita mediante el complemento de auditoría de Cloud SQL para MySQL o cloudsql_mysql_audit. Este complemento usa la API de auditoría de MySQL de código abierto para monitorizar y registrar la actividad en MySQL. El complemento envía registros a los registros de auditoría de acceso a datos de Cloud Logging. Los registros de auditoría de acceso a datos están inhabilitados de forma predeterminada porque pueden ser bastante grandes. Para usar el complemento, debes habilitar los registros de forma explícita.

Cuando el complemento está activo, las reglas de auditoría que hayas creado se aplican para generar registros de auditoría de la base de datos. Cuando el complemento está desactivado, no se generan registros de auditoría.

Para obtener más información sobre los complementos de MySQL, consulta Complementos del servidor MySQL.

¿Quién usa la auditoría de bases de datos?

Hay tres tipos de usuarios implicados en la auditoría de bases de datos:

  • Administradores: usuarios que administran la base de datos. Los administradores son usuarios de auditoría responsables de habilitar e inhabilitar la auditoría en la instancia y de crear nuevos usuarios. También conceden permiso de auditoría a los auditores. Los administradores también pueden crear, eliminar y actualizar reglas de auditoría.
  • Auditores: usuarios que tienen permiso para crear, eliminar y actualizar las reglas de auditoría. Los administradores les conceden acceso.
  • Clientes: usuarios cuya actividad se audita mediante reglas de auditoría, pero que no son usuarios de auditoría y no tienen privilegios de administración ni de auditoría. Los administradores controlan su acceso.

Los administradores y auditores también se denominan usuarios de auditoría.

Reglas de auditoría

La auditoría de bases de datos usa reglas de auditoría para definir combinaciones de usuarios, bases de datos, objetos, operaciones y estados que deben activar la creación de un registro de auditoría. Una regla de auditoría contiene la siguiente información:

  • Id: identificador de la regla autonumérica. Cada regla de auditoría tiene un ID de auditoría que se le asigna automáticamente cuando se crea. El ID de auditoría no se puede cambiar una vez creado.
  • Nombre de usuario: lista separada por comas de usuarios o patrones de comodín. Puedes usar asteriscos (*) como comodines tanto para el usuario como para el host. Usa el asterisco como sufijo, prefijo o ambos. Además, los usuarios solo pueden usar el carácter comodín % en el host. El máximo es de 2048 caracteres.
  • Dbname: lista de nombres de bases de datos o patrones comodín separados por comas. Puedes usar asteriscos (*) como comodines tanto para el usuario como para el host. Usa el asterisco como sufijo, prefijo o ambos. El máximo es de 2048 caracteres.
  • Objeto: lista separada por comas de nombres de objetos de base de datos (tablas, funciones, procedimientos almacenados, etc.) o patrones de comodín. Puedes usar asteriscos (*) como comodines tanto para el usuario como para el host. Usa el asterisco como sufijo, prefijo o ambos. El máximo es de 2048 caracteres.
  • Operación: lista separada por comas de operaciones de base de datos. El complemento admite operaciones de grupo (como DDL, DML, etc.), operaciones individuales (como update, delete, etc.) y comodines (*) para todas las operaciones. Consulta la lista completa de operaciones admitidas. El complemento también admite grupos de operaciones que puedes usar para auditar un grupo de operaciones. El máximo es de 2048 caracteres.

  • Op_result resultado de la operación.

    • S para auditar las operaciones correctas
    • U para auditar las operaciones que no se han realizado
    • B para hacer un seguimiento de las operaciones correctas y las incorrectas
    • E para crear reglas exclusivas

Tipos de operación

Los tipos de operación son los distintos tipos de actividades u operaciones que puedes auditar en la base de datos:

  • DQL: lee datos de la base de datos (es decir, instrucciones SELECT).
  • DML: añade, elimina o modifica datos.
  • DDL: crea o modifica la estructura de los objetos de la base de datos.
  • DCL: gestiona los privilegios de los usuarios de la base de datos
  • Show - Describe las objeciones de la base de datos o proporciona el estado de la base de datos
  • Call: invoca un procedimiento almacenado.

Consideraciones que afectan al registro de auditoría

Copias de seguridad

Cuando se restaura una instancia a partir de una copia de seguridad o de una recuperación a un momento dado (PITR), las reglas de auditoría también se revierten al momento de la copia de seguridad o de la PITR. Esto ocurre porque las reglas de auditoría forman parte de los datos almacenados en la base de datos, al igual que los objetivos (los usuarios y los objetos) que audita la regla.

Réplicas de lectura

Las reglas de auditoría se replican automáticamente de una instancia principal a sus réplicas de lectura. Los clientes no pueden añadir, quitar ni modificar reglas de auditoría en réplicas de lectura. Si quieres cambiar las reglas de auditoría de una réplica, debes actualizar las reglas de auditoría de la instancia principal.

Si actualiza las reglas del registro de auditoría en la instancia principal, debe volver a cargar la regla de auditoría en la réplica para asegurarse de que las nuevas reglas de auditoría también se actualicen en las réplicas de lectura. El siguiente comando vuelve a cargar la regla de auditoría:

CALL mysql.cloudsql_reload_audit_rule(1)

Los usuarios pueden habilitar el registro de auditoría en las réplicas independientemente de la instancia principal. Después de hacer cambios en la instancia principal, debes ejecutar el comando de recarga o reiniciar la instancia de réplica para que las reglas del registro de auditoría surtan efecto.

Disponibilidad de la base de datos durante un fallo del registro de auditoría

Si falla una operación de auditoría, Cloud SQL no impide que se complete la actividad de la base de datos. Por ejemplo, cuando una instancia se queda sin espacio en disco y Cloud SQL no puede generar un registro de auditoría, la base de datos sigue permitiendo que el usuario realice consultas de lectura, aunque esta actividad normalmente generaría un registro de auditoría.

Instancias de solo lectura

Si una instancia tiene la marca read_only definida como true, no puedes añadir ni actualizar reglas de auditoría, ya que se almacenan en las tablas. Antes de crear, actualizar o eliminar reglas, debes quitar la marca read_only.

Limitaciones y problemas conocidos

Tasa de ingestión de registros

Antes de que Cloud SQL envíe los registros de auditoría a Cloud Logging, se escriben temporalmente en el disco de la instancia, lo que ocupa espacio en disco. Los registros se suben a Cloud Logging y se eliminan del disco a una velocidad de 4 MB por segundo. Cuando la carga de la generación de registros supera la velocidad de subida, la instancia experimenta un aumento del uso del disco, lo que puede provocar que tu base de datos se quede sin espacio en el disco y falle. Aunque los aumentos automáticos del almacenamiento en disco estén habilitados, el aumento del uso del disco incrementa los costes.

Mientras usas esta función, te recomendamos que hagas lo siguiente:

  • Habilita los aumentos automáticos de almacenamiento.
  • Monitoriza el uso general del disco. No puedes monitorizar la carga de la generación de registros por separado. Usa la métrica cloudsql.googleapis.com/database/disk/utilization en el explorador de métricas.
  • Si es necesario, reduce la tasa de generación de registros limitando la actividad de la base de datos o reduciendo la auditoría.

Auditar operaciones fallidas

Si tus reglas de auditoría incluyen la auditoría de operaciones fallidas (op_result se define como U para las operaciones fallidas o B para las operaciones fallidas y correctas), algunos usuarios podrían sobrecargar tu instancia de base de datos con registros de auditoría ejecutando continuamente operaciones fallidas. Si la velocidad de generación de registros supera la velocidad de ingestión de registros, puede producirse un aumento no deseado del uso del disco, lo que agotará el espacio en disco. En su lugar, cuando audites operaciones fallidas, haz lo siguiente:

  • Controlar el acceso a nivel de instancia.
  • Configura un sistema de monitorización o de alertas para detectar aumentos anómalos en los registros de operaciones fallidas.

Reglas de auditoría

No puedes crear más de 1000 combinaciones de reglas de auditoría por instancia de base de datos. Una combinación de reglas de auditoría es un conjunto único de un usuario, una base de datos, un objeto y operaciones. Por ejemplo, una regla de auditoría que audite user1,user2, db1,db2, table1,table2, select,delete genera 2 x 2 x 2 x 2 = 16 combinaciones. No se pueden crear ni actualizar reglas de auditoría si el número total de combinaciones de reglas de auditoría supera las 1000.

Operaciones no admitidas

Actualmente no se admiten las siguientes operaciones.

  • Las siguientes funciones no se admiten cuando se usan de la forma descrita:

    • En las consultas SELECT con UNION, INTERSECT, la cláusula WHERE, las consultas anidadas, las subconsultas, etc.
    • En UPDATE, DELETE, INSERT y REPLACE.

    Por ejemplo, si tienes una regla de auditoría para auditar el objeto func1, no se auditará lo siguiente:

    • SELECT func1() FROM table;
    • SELECT * FROM table WHERE a = func1();
    • SELECT func1() != 0;
    • SELECT func1() > 0;
    • SET @x = func1();

    Se audita una función a la que llama directamente SELECT sin operadores y sin una cláusula WHERE:

    • SELECT func1();
    • SELECT db.func1();

  • Por el momento, no se puede filtrar por dirección IP.

Siguientes pasos