Auditoria de banco de dados MySQL

Neste tópico, descrevemos a auditoria do banco de dados do Cloud SQL para MySQL e o plug-in de auditoria do Cloud SQL para MySQL. Para usar a auditoria do banco de dados agora, consulte Usar a auditoria do banco de dados MySQL.

O que é a auditoria do banco de dados?

A auditoria do banco de dados permite rastrear ações específicas do usuário no banco de dados, como atualizações de tabela, consultas de leitura, concessões de privilégios de usuários, entre outras. A auditoria de banco de dados é útil para organizações que precisam acompanhar a atividade do usuário por motivos de segurança ou para obedecer a várias regulamentações financeiras, governamentais e ISO. A auditoria do banco de dados é compatível com o Cloud SQL para MySQL 5.7 e 8.0.

Plug-in de auditoria do Cloud SQL para MySQL

A auditoria do banco de dados é ativada pelo plug-in de auditoria do Cloud SQL para MySQL ou cloudsql_mysql_audit. Esse plug-in usa a API de auditoria do MySQL aberta para monitorar e registrar atividades no MySQL. O plug-in envia registros para registros de auditoria de acesso a dados do Cloud Logging. Os registros de auditoria de Acesso a dados estão desativados por padrão porque os registros de auditoria podem ser bem grandes. É preciso ativar explicitamente os registros para usar o plug-in.

Quando o plug-in está ativo, as regras de auditoria atuais que você criou são aplicadas para gerar registros de auditoria para o banco de dados. Quando o plug-in é desativado, nenhum registro de auditoria é gerado.

Para mais informações sobre os plug-ins do MySQL, consulte Plug-ins do servidor MySQL.

Quem usa a auditoria de banco de dados?

Há três tipos de usuários envolvidos na auditoria do banco de dados:

  • Administradores: os usuários que administram o banco de dados. Os administradores são usuários de auditoria responsáveis por ativar e desativar a auditoria na instância e por criar novos usuários. Eles também concedem permissão de auditoria aos auditores. Os administradores também podem criar, excluir e atualizar regras de auditoria.
  • Auditores: usuários que têm permissão para criar, excluir e atualizar as regras de auditoria. Eles recebem acesso dos administradores.
  • Clientes: usuários cuja atividade é auditada por meio das regras de auditoria, mas que não são usuários de auditoria e não têm privilégios administrativos ou de auditoria. O acesso é regido pelos administradores.

Administradores e auditores também são chamados de usuários de auditoria.

Regras de auditoria

A auditoria do banco de dados usa regras de auditoria para definir combinações de usuários, bancos de dados, objetos, operações e status que precisam acionar a criação de um registro de auditoria. Uma regra de auditoria contém as seguintes informações:

  • Código: identificador automático de regras. Cada regra de auditoria tem um ID que é atribuído automaticamente quando ela é criada. Depois de criado, o ID de auditoria não poderá ser alterado.
  • Nome de usuário: lista separada por vírgulas de usuários e/ou padrões de caracteres curinga. É possível usar asteriscos (*) como caracteres curinga para o usuário e o host. Use o asterisco como sufixo, prefixo ou ambos. Além disso, os usuários só podem usar o caractere curinga % para o host. O máximo é 2048 caracteres.
  • Dbname: lista separada por vírgulas de nomes de bancos de dados e/ou padrões de caracteres curinga. É possível usar asteriscos (*) como caracteres curinga para o usuário e o host. Use o asterisco como sufixo, prefixo ou ambos. O máximo é de 2.048 caracteres.
  • Objeto: lista separada por vírgulas de objetos de banco de dados (tabelas, funções, procedimentos armazenados etc.) e/ou padrões de caracteres curinga. Você pode usar asteriscos (*) como caracteres curinga para o usuário e o host. Use o asterisco como sufixo, prefixo ou ambos. O máximo é de 2.048 caracteres.
  • Operação: lista separada por vírgulas de operações do banco de dados. O plug-in é compatível com operações de grupo, (como DDL, DML etc.), operações únicas (como atualização, exclusão etc.) e caracteres curinga (*) em todas as operações. Veja a lista completa de operações compatíveis. O plug-in também é compatível com grupos de operações que podem ser usados para auditar um grupo de operações. O máximo é de 2.048 caracteres.

  • Op_result: resultado da operação.

    • S para auditar operações bem-sucedidas
    • U para auditoria de operações com falha
    • B para rastrear operações bem-sucedidas e com falha
    • E para criar regras exclusivas

Tipos de operação

Os tipos de operação são os vários tipos de atividades ou operações que você pode auditar no banco de dados:

  • DQL: lê dados do banco de dados (ou seja, instruções SELECT).
  • DML: adiciona, exclui ou modifica dados
  • DDL: cria ou modifica a estrutura dos objetos de banco de dados.
  • DCL: gerencia privilégios para usuários no banco de dados.
  • Show: descreve objeções do banco de dados ou informar o status dele
  • Call: invoca um procedimento armazenado

Considerações que afetam a geração de registros de auditoria

Backups

Ao restaurar uma instância a partir de um backup ou recuperação pontual (PITR, na sigla em inglês), as regras de auditoria também revertem para o horário do backup ou da PITR. Isso acontece porque as regras de auditoria fazem parte dos dados armazenados no banco de dados, assim como os destinos (usuários e objetos) que a regra audita.

Réplicas de leitura

As regras de auditoria são replicadas automaticamente de uma instância primária para as réplicas de leitura. Os clientes não podem adicionar, remover ou modificar regras de auditoria em réplicas de leitura. Se você quiser alterar as regras de auditoria de uma réplica, precisará atualizar as regras de auditoria da instância principal.

Se você atualizar as regras de auditoria na instância principal, precisará recarregar a regra de auditoria na réplica para garantir que as novas regras de auditoria também sejam atualizadas nas réplicas de leitura. O comando a seguir atualiza a regra de auditoria:

CALL mysql.cloudsql_reload_audit_rule(1)

Os usuários podem ativar a geração de registros de auditoria em réplicas, independentemente da instância principal. Depois de fazer alterações na instância principal, execute o comando de atualização ou reinicie a instância da réplica para tornar as regras de registro de auditoria em vigor.

Disponibilidade do banco de dados durante a falha no registro de auditoria

Se uma operação de auditoria falhar, o Cloud SQL não interromperá a conclusão da atividade do banco de dados. Por exemplo, quando uma instância fica sem espaço em disco, e o Cloud SQL não pode gerar um registro de auditoria, o banco de dados ainda permite que o usuário realize consultas de leitura, mesmo que essa atividade normalmente gere um registro de auditoria.

Instâncias somente leitura

Se uma instância tiver a sinalização read_only definida como true, não será possível adicionar ou atualizar regras de auditoria, porque elas são armazenadas nas tabelas. Antes de criar, atualizar ou excluir regras, você precisa remover a sinalização read_only.

Limitações e problemas conhecidos

Aplicar registros binários

O plug-in de auditoria do Cloud SQL para MySQL não é compatível com registros binários em uma instância.

Em alguns casos, se você tentar aplicar registros binários enquanto o plug-in de auditoria do Cloud SQL para MySQL estiver ativado, talvez a instância do banco de dados falhe.

Se você quiser aplicar registros binários usando o utilitário mysqlbinlog, primeiro será necessário desativar a auditoria do banco de dados definindo cloudsql_mysql_audit=OFF.

Taxa de ingestão de registros

Antes de enviar registros de auditoria para o Cloud Logging, o Cloud SQL é gravado temporariamente no disco da instância usando o espaço em disco. Os registros são enviados para o Cloud Logging e removidos do disco a uma taxa de 4 MB por segundo. Quando a carga da geração de registros excede a taxa de upload, a instância passa por um aumento no uso do disco, o que pode fazer com que o banco de dados fique sem disco e falhar. Mesmo que os aumentos automáticos de armazenamento em disco estejam ativados, o aumento no uso do disco aumenta os custos.

Ao usar esse recurso, recomendamos o seguinte:

  • Ativar aumento automático de armazenamento.
  • Monitore o uso geral do disco. Não é possível monitorar a carga da geração de registros separadamente. Use a métrica cloudsql.googleapis.com/database/disk/utilization no Metrics Explorer.
  • Se necessário, reduza a taxa de geração de registros limitando a atividade do banco de dados ou reduza a auditoria.

Auditar operações com falha

Se as regras de auditoria incluírem auditoria para operações malsucedidas (op_result estiver definida como U para operações malsucedidas ou B para operações malsucedidas e bem-sucedidas), alguns usuários poderão sobrecarregar instância de banco de dados com registros de auditoria executando operações malsucedidas continuamente. Se a velocidade de geração de registros exceder a taxa de ingestão de registros, poderá ocorrer um crescimento indesejado no uso do disco, esgotando o espaço em disco. Em vez disso, ao auditar operações com falha:

  • Controle o acesso no nível da instância.
  • Configure um sistema de monitoramento ou alerta para aumentar os registros de operações malsucedidas.

Regras de auditoria

Não é possível criar mais de 1.000 combinações de regras de auditoria por instância de banco de dados. Uma combinação de regras de auditoria é um conjunto exclusivo de usuários, bancos de dados, objetos e operações. Por exemplo, uma regra de auditoria que audita user1,user2, db1,db2, table1,table2, select,delete gera 2 x 2 x 2 x 2 = 16 combinações. A criação ou atualização de regras de auditoria falhará se o número total de combinações de regras de auditoria exceder 1.000.

Operações incompatíveis

As operações a seguir não são compatíveis.

  • As funções a seguir não são compatíveis, quando usadas conforme descrito:

    • Nas consultas SELECT com UNION, INTERSECT, na cláusula WHERE, consultas aninhadas, subconsultas etc.
    • Nas instruções UPDATE, DELETE, INSERT, REPLACE.

    Por exemplo, se você tiver uma regra de auditoria para o objeto de auditoria func1, o seguinte não será auditado:

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

    Uma função chamada diretamente por SELECT sem nenhum operador e sem uma cláusula WHERE é auditada:

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

  • A filtragem por endereço IP não é compatível no momento.

A seguir