Auditoria de banco de dados MySQL

Este tópico descreve a auditoria de banco de dados do Cloud SQL para MySQL e o plugin de auditoria do Cloud SQL para MySQL. Para usar a auditoria de banco de dados agora, consulte Usar auditoria de banco de dados MySQL .

O que é auditoria de banco de dados?

A auditoria de banco de dados permite rastrear ações específicas do usuário no banco de dados, como atualizações de tabelas, consultas de leitura, concessões de privilégios de usuário e outras. A auditoria de banco de dados é útil para organizações que precisam manter um registro da atividade do usuário por motivos de segurança ou para cumprir diversas regulamentações financeiras, governamentais e ISO. A auditoria de 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 de banco de dados é habilitada pelo plugin de auditoria do Cloud SQL para MySQL, ou cloudsql_mysql_audit . Este plugin usa a API de auditoria aberta do MySQL para monitorar e registrar atividades no MySQL. O plugin envia logs para os logs de auditoria de acesso a dados do Cloud Logging . Os logs de auditoria de acesso a dados são desabilitados por padrão, pois os logs de auditoria podem ser muito grandes. Você deve habilitar explicitamente os logs para usar o plugin.

Quando o plugin está ativo, as regras de auditoria existentes que você criou são aplicadas para gerar logs de auditoria para o banco de dados. Quando o plugin está desativado, nenhum log de auditoria é gerado.

Para obter mais informações sobre plugins do MySQL, consulte Plugins do servidor MySQL .

Quem usa auditoria de banco de dados?

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

  • Administradores - Usuários que administram o banco de dados. Administradores são usuários de auditoria responsáveis ​​por habilitar e desabilitar 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. O acesso é concedido a eles pelos administradores.
  • Clientes - Usuários cuja atividade é auditada pelas regras de auditoria, mas que não são usuários de auditoria e não possuem privilégios administrativos ou de auditoria. Seu acesso é controlado por administradores.

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

Regras de auditoria

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

  • Id - Identificador de regra autonumérico. Cada regra de auditoria tem um ID de auditoria atribuído automaticamente quando é criada. O ID de auditoria não pode ser alterado após a criação.
  • Nome de usuário - Lista de usuários separados por vírgulas e/ou padrões curinga. Você pode usar asteriscos ( * ) como curingas tanto para o usuário quanto para o host. Use o asterisco como sufixo, prefixo ou ambos. Além disso, os usuários podem usar o caractere curinga % apenas para o host. O máximo é de 2.048 caracteres.
  • Dbname - Lista separada por vírgulas de nomes de bancos de dados e/ou padrões curinga. Você pode usar asteriscos ( * ) como curingas tanto para o usuário quanto para o host. Use o asterisco como sufixo, prefixo ou ambos. Máximo de 2.048 caracteres.
  • Objeto : Lista separada por vírgulas de nomes de objetos de banco de dados (tabelas, funções, procedimentos armazenados, etc.) e/ou padrões curinga. Você pode usar asteriscos ( * ) como curingas para o usuário e o host. Use o asterisco como sufixo, prefixo ou ambos. O máximo é 2.048 caracteres.
  • Operação - Lista de operações de banco de dados separadas por vírgulas. O plugin suporta operações de grupo (como DDL, DML, etc.), operações individuais (como atualização, exclusão, etc.) e curingas ( * ) para todas as operações. Consulte a lista completa de operações suportadas . O plugin também suporta grupos de operações que você pode usar para auditar um grupo de operações. O máximo é 2.048 caracteres.

  • Op_result - Resultado da operação.

    • S para auditoria de operações bem-sucedidas
    • U para auditoria de operações malsucedidas
    • B para rastrear operações bem-sucedidas e malsucedidas
    • 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 - Ler dados do banco de dados (ou seja, instruções SELECT )
  • DML - Adicionar, excluir ou modificar dados
  • DDL - Cria ou modifica a estrutura de objetos de banco de dados no banco de dados
  • DCL - Gerenciar privilégios para usuários no banco de dados
  • Show - Descreva objeções do banco de dados ou forneça o status do banco de dados
  • Call - Invocar um procedimento armazenado

Considerações que afetam o registro de auditoria

Backups

Ao restaurar uma instância a partir de um backup ou recuperação pontual (PITR), as regras de auditoria também revertem para o momento do backup ou do PITR. Isso ocorre porque as regras de auditoria fazem parte dos dados armazenados no banco de dados, assim como os alvos (os usuários e objetos) que a regra está auditando.

Ler réplicas

As regras de auditoria são replicadas automaticamente de uma instância primária para suas 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 primária.

Se você atualizar as regras de log de auditoria na instância primária, 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 recarrega a regra de auditoria:

CALL mysql.cloudsql_reload_audit_rule(1)

Os usuários podem habilitar o registro de auditoria em réplicas independentemente da instância primária. Após fazer alterações na instância primária, você precisa executar o comando reload ou reiniciar a instância de réplica para que as regras de registro de auditoria entrem em vigor.

Disponibilidade do banco de dados durante falha do log 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 consegue gerar um log de auditoria, o banco de dados ainda permite que o usuário execute consultas de leitura, mesmo que essa atividade normalmente gerasse um log de auditoria.

Instâncias somente leitura

Se uma instância tiver o sinalizador read_only definido como true , você não poderá adicionar ou atualizar regras de auditoria, pois elas são armazenadas nas tabelas. Antes de criar, atualizar ou excluir regras, você precisa remover o sinalizador read_only .

Limitações e problemas conhecidos

Taxa de ingestão de log

Antes de o Cloud SQL enviar logs de auditoria para o Cloud Logging, eles são gravados temporariamente no disco da instância, utilizando espaço em disco. Os logs são carregados para o Cloud Logging e removidos do disco a uma taxa de 4 MB por segundo. Quando a carga da geração de logs excede a taxa de upload, a instância sofre um aumento no uso do disco, o que pode fazer com que o banco de dados fique sem espaço em disco e trave. Mesmo que o aumento automático de armazenamento em disco esteja habilitado, o aumento no uso do disco aumenta os custos.

Ao usar esse recurso, recomendamos que você:

  • Habilitar aumentos automáticos de armazenamento .
  • Monitore o uso geral do disco. Não é possível monitorar a carga da geração de logs separadamente. Use a métrica cloudsql.googleapis.com/database/disk/utilization no Explorador de Métricas .
  • Se necessário, reduza a taxa de geração de logs limitando a atividade do banco de dados ou reduzindo a auditoria.

Auditar operações malsucedidas

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

  • Controle o acesso no nível da instância .
  • Configure um sistema de monitoramento ou alerta para o aumento anormal de 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ário, banco de dados, objeto 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 não suportadas

Atualmente, as seguintes operações não são suportadas.

  • As seguintes funções não são suportadas quando usadas conforme descrito:

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

    Por exemplo, se você tiver uma regra de auditoria para auditar o objeto func1 , os seguintes itens não serão auditados:

    • 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 é suportada no momento.

O que vem a seguir