Auditoría de la base de datos de MySQL

En este tema, se describen la auditoría de la base de datos de Cloud SQL para MySQL y el complemento de auditoría de Cloud SQL para MySQL. Para usar la auditoría de la base de datos ahora, consulta Usa la auditoría de la base de datos de MySQL.

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

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

Complemento de auditoría de Cloud SQL para MySQL

El complemento de auditoría de Cloud SQL para MySQL, o cloudsql_mysql_audit, habilita la auditoría de la base de datos. Este complemento usa la API de auditoría de MySQL abierta para supervisar y registrar la actividad en MySQL. El complemento envía registros a los registros de auditoría de acceso a los datos de Cloud Logging. Estos registros están inhabilitados de forma predeterminada, ya que pueden ser bastante extensos. Debes habilitar los registros de forma explícita para usar el complemento.

Cuando el complemento está activo, las reglas de auditoría existentes que creaste se aplican a fin de generar registros de auditoría para la base de datos. Cuando el complemento se desactiva, 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 la base de datos?

Existen tres tipos de usuarios que participan en la auditoría de la base de datos:

  • Administradores: Usuarios que administran la base de datos. Los administradores son usuarios de auditoría que son responsables de habilitar o inhabilitar la auditoría en la instancia, y de crear usuarios nuevos. También otorgan permisos de auditoría a los auditores. Los administradores también pueden crear, borrar y actualizar reglas de auditoría.
  • Auditores: Usuarios que tienen permiso para crear, borrar y actualizar las reglas de auditoría. Los administradores les otorgan acceso.
  • Clientes: Usuarios cuya actividad se audita a través de las reglas de auditoría, pero que no son usuarios de auditoría y no tienen privilegios de administrador ni de auditoría. Los administradores rigen su acceso.

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

Reglas de auditoría

La auditoría de la base 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 regla automático. Cada regla de auditoría tiene un ID de auditoría asignado de forma automática cuando se crea la regla. Una vez creado, el ID de auditoría no se puede cambiar.
  • Nombre de usuario: Lista de usuarios o patrones de comodines separados por comas. Puedes usar asteriscos (*) como comodines para el usuario y el host Usa el asterisco como sufijo, prefijo o ambos. Además, los usuarios pueden usar el carácter comodín % solo para el host. El máximo es de 2,048 caracteres.
  • Dbname: Lista de nombres de bases de datos o patrones comodín separados por comas. Puedes usar asteriscos (*) como comodines para el usuario y el host. Usa el asterisco como sufijo, prefijo o ambos. El máximo es de 2,048 caracteres.
  • Objeto: Lista de objetos de bases de datos separados por comas (tablas, funciones, procedimientos almacenados, etc.) o patrones comodín. Puedes usar asteriscos (*) como comodines para el usuario y el host. Usa el asterisco como sufijo, prefijo o ambos. El máximo es de 2,048 caracteres.
  • Operación: Lista de operaciones de base de datos separadas por comas. El complemento admite operaciones de grupos (como DDL, DML, etc.), operaciones individuales (como actualización, eliminación, 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 2,048 caracteres.

  • Op_result: Es el resultado de la operación.

    • S para auditar las operaciones exitosas
    • U para auditar las operaciones que no se realizaron de forma correcta
    • B para hacer un seguimiento de las operaciones exitosas y fallidas
    • E para crear reglas exclusivas

Tipos de operación

Los tipos de operaciones son los múltiples tipos de operaciones o actividades que puedes auditar en la base de datos:

  • DQL: Lee datos de la base de datos (es decir, declaraciones SELECT).
  • DML: Agrega, borra o modifica datos.
  • DDL: Crea o modifica la estructura de los objetos de la base de datos en ella.
  • DCL: Administra 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 el registro de auditoría

Copias de seguridad

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

Réplicas de lectura

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

Si actualizas las reglas de registro de auditoría en la instancia principal, debes volver a cargar la regla de auditoría en la réplica para asegurarte de que las reglas de auditoría nuevas 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 sin importar la instancia principal. Después de realizar cambios en la instancia principal, debes ejecutar el comando de carga nueva o reiniciar la instancia de réplica para que las reglas de registro de auditoría sean efectivas.

Disponibilidad de la base de datos durante una falla de registro de auditoría

Si una operación de auditoría falla, Cloud SQL no impide que se complete la actividad de la base de datos. Por ejemplo, cuando una instancia se queda sin espacio en el disco y Cloud SQL no puede generar un registro de auditoría, la base de datos aún permite al usuario realizar consultas de lectura, incluso si esta actividad genera un registro de auditoría.

Instancias de solo lectura

Si una instancia tiene la marca read_only configurada en true, no puedes agregar ni actualizar reglas de auditoría, ya que se almacenan en las tablas. Antes de crear, actualizar o borrar reglas, debes quitar la marca read_only.

Limitaciones y problemas conocidos

Aplica registros binarios

El complemento de auditoría de Cloud SQL para MySQL no es compatible con los registros binarios de una instancia.

En algunos casos, si intentas aplicar registros binarios mientras el complemento de auditoría de Cloud SQL para MySQL está habilitado, es posible que falle la instancia de la base de datos.

Si deseas aplicar registros binarios con la utilidad mysqlbinlog, primero debes inhabilitar la auditoría de la base de datos mediante la configuración de cloudsql_mysql_audit=OFF.

Tasa de transferencia de registros

Antes de que Cloud SQL envíe registros de auditoría a Cloud Logging, se escriben de forma temporal en el disco de la instancia mediante el espacio en el disco. Los registros se suben a Cloud Logging y se quitan del disco a una velocidad de 4 MB por segundo. Cuando la carga de la generación de registros supera la tasa de carga, la instancia experimenta un aumento en el uso del disco, lo que puede hacer que tu base de datos se quede sin disco y falle. Incluso si los aumentos automáticos de almacenamiento en el disco están habilitados, el aumento en el uso del disco incrementa los costos.

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

  • Habilitar los aumentos de almacenamiento automáticos.
  • Supervisa el uso general del disco. No puedes supervisar 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 mediante la limitación de la actividad de la base de datos o la auditoría.

Audita operaciones fallidas

Si tus reglas de auditoría incluyen auditorías para operaciones fallidas (op_result se establece en U para operaciones fallidas o en B para operaciones fallidas y correctas), es posible que algunos usuarios puedan sobrecargar la instancia de base de datos con los registros de auditoría mediante la ejecución continua de operaciones fallidas. Si la velocidad de generación de registros supera la tasa de transferencia de registros, puede ocurrir un crecimiento no deseado en el uso del disco, lo que agotaría el espacio en el disco. En cambio, cuando se auditan las operaciones que no se realizaron de forma correcta, sucede lo siguiente:

  • Controla el acceso a nivel de instancia.
  • Configura un sistema de supervisión o alertas para el aumento anormal de los registros de operaciones fallidos.

Reglas de auditoría

No puedes crear más de un total de 1,000 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 usuarios, bases de datos, objetos y operaciones. Por ejemplo, una regla de auditoría que audita user1,user2, db1,db2, table1,table2, select,delete genera 2 combinaciones de 2 × 2 × 2 = 16. La creación o actualización de reglas de auditoría falla si la cantidad total de combinaciones de las reglas de auditoría supera las 1,000.

Operaciones no admitidas

Por el momento, no se admiten las siguientes operaciones.

  • Las siguientes funciones no son compatibles cuando se usan como se describe a continuación:

    • Dentro de las consultas SELECT con UNION, INTERSECT, la cláusula WHERE, consultas anidadas, subconsultas, etcétera.
    • En UPDATE, DELETE, INSERT o declaraciones REPLACE.

    Por ejemplo, si tienes una regla de auditoría para auditar el objeto func1, no se audita 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 que SELECT llama directamente sin ningún operador y sin una cláusula WHERE:

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

  • En este momento, no se admite el filtrado por dirección IP.

¿Qué sigue?