Auditoria da base de dados MySQL

Este tópico descreve a auditoria de bases de dados do Cloud SQL para MySQL e o plug-in de auditoria do Cloud SQL para MySQL. Para usar a auditoria de bases de dados agora, consulte o artigo Use a auditoria de bases de dados do MySQL.

O que é a auditoria de bases de dados?

A auditoria da base de dados permite-lhe acompanhar ações específicas dos utilizadores na base de dados, como atualizações de tabelas, consultas de leitura, concessões de privilégios de utilizadores e outras. A auditoria da base de dados é útil para as organizações que precisam de ter um registo da atividade do utilizador por motivos de segurança ou para agir em conformidade com vários regulamentos financeiros, governamentais e ISO. A auditoria de bases de dados é suportada para o Cloud SQL para MySQL 5.7, 8.0 e 8.4.

Plug-in de auditoria do Cloud SQL para MySQL

A auditoria da base de dados é ativada pelo plug-in de auditoria do Cloud SQL para MySQL ou cloudsql_mysql_audit. Este plug-in usa a API de auditoria do MySQL aberta para monitorizar e registar a atividade no MySQL. O plug-in envia registos para os registos de auditoria de acesso a dados do Cloud Logging. Os registos de auditoria de acesso a dados estão desativados por predefinição porque podem ser bastante grandes. Tem de ativar explicitamente os registos para usar o plug-in.

Quando o plug-in está ativo, as regras de auditoria existentes que criou são aplicadas para gerar registos de auditoria para a base de dados. Quando o plug-in está desativado, não são gerados registos de auditoria.

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

Quem usa a auditoria de bases de dados?

Existem três tipos de utilizadores envolvidos na auditoria de bases de dados:

  • Administradores: utilizadores que administram a base de dados. Os administradores são utilizadores de auditoria responsáveis por ativar e desativar a auditoria na instância e por criar novos utilizadores. Também concedem autorização de auditoria aos auditores. Os administradores também podem criar, eliminar e atualizar regras de auditoria.
  • Auditores: utilizadores que têm autorização para criar, eliminar e atualizar as regras de auditoria. O acesso é concedido pelos administradores.
  • Clientes: utilizadores cuja atividade é auditada através das regras de auditoria, mas que não são utilizadores de auditoria e não têm privilégios administrativos nem de auditoria. O acesso é regido pelos administradores.

Os administradores e os auditores também são denominados utilizadores de auditoria.

Regras de auditoria

A auditoria de bases de dados usa regras de auditoria para definir combinações de utilizadores, bases de dados, objetos, operações e estados que devem acionar a criação de um registo de auditoria. Uma regra de auditoria contém as seguintes informações:

  • Id: identificador da regra autonumérico. Cada regra de auditoria tem um ID de auditoria que lhe é atribuído automaticamente quando a regra é criada. Não é possível alterar o ID de auditoria depois de o criar.
  • Nome de utilizador: lista separada por vírgulas de utilizadores e/ou padrões de carateres universais. Pode usar asteriscos (*) como carateres universais para o utilizador e o anfitrião. Use o asterisco como sufixo, prefixo ou ambos. Além disso, os utilizadores podem usar o caráter universal % apenas para o anfitrião. O máximo é de 2048 carateres.
  • Dbname: lista separada por vírgulas de nomes de bases de dados e/ou padrões de carateres universais. Pode usar asteriscos (*) como carateres universais para o utilizador e o anfitrião. Use o asterisco como sufixo, prefixo ou ambos. O máximo é de 2048 carateres.
  • Objeto: lista separada por vírgulas de nomes de objetos da base de dados (tabelas, funções, procedimentos armazenados, etc.) e/ou padrões de carateres universais. Pode usar asteriscos (*) como carateres universais para o utilizador e o anfitrião. Use o asterisco como sufixo, prefixo ou ambos. O máximo é de 2048 carateres.
  • Operação: lista separada por vírgulas de operações da base de dados. O plug-in suporta operações de grupo (como DDL, DML, etc.), operações únicas (como atualização, eliminação, etc.) e carateres universais (*) para todas as operações. Consulte a Lista completa de operações suportadas. O plug-in também suporta grupos de operações que pode usar para auditar um grupo de operações. O máximo é de 2048 carateres.

  • Op_result: resultado da operação.

    • S para auditar operações bem-sucedidas
    • U para auditar operações sem êxito
    • B para acompanhar as operações bem-sucedidas e as que não foram bem-sucedidas
    • E para criar regras exclusivas

Tipos de operações

Os tipos de operações são os vários tipos de atividades ou operações que pode auditar na base de dados:

  • DQL – Ler dados da base de dados (ou seja, declarações SELECT)
  • DML – Adicionar, eliminar ou modificar dados
  • DDL – Criar ou modificar a estrutura de objetos da base de dados na base de dados
  • DCL – Faça a gestão dos privilégios dos utilizadores na base de dados
  • Show - Descreva as objeções à base de dados ou indique o estado da base de dados
  • Call: invocar um procedimento armazenado

Considerações que afetam o registo de auditoria

Cópias de segurança

Quando restaura uma instância a partir de uma cópia de segurança ou de uma recuperação num determinado momento (PITR), as regras de auditoria também são revertidas para o momento da cópia de segurança ou da PITR. Isto acontece porque as regras de auditoria fazem parte dos dados armazenados na base de dados, tal como os alvos (os utilizadores e os objetos) que a regra está a auditar.

Réplicas de leitura

As regras de auditoria são replicadas automaticamente de uma instância principal para as respetivas réplicas de leitura. Os clientes não podem adicionar, remover nem modificar regras de auditoria em réplicas de leitura. Se quiser alterar as regras de auditoria de uma réplica, tem de atualizar as regras de auditoria da instância principal.

Se atualizar as regras do registo de auditoria na instância principal, tem de recarregar a regra de auditoria na réplica para garantir que as novas regras de auditoria também são atualizadas nas réplicas de leitura. O seguinte comando recarrega a regra de auditoria:

CALL mysql.cloudsql_reload_audit_rule(1)

Os utilizadores podem ativar o registo de auditoria em réplicas independentemente da instância principal. Depois de fazer alterações na instância principal, tem de executar o comando reload ou reiniciar a instância da réplica para que as regras do registo de auditoria entrem em vigor.

Disponibilidade da base de dados durante a falha do registo de auditoria

Se uma operação de auditoria falhar, o Cloud SQL não impede que a atividade da base de dados seja concluída. Por exemplo, quando uma instância fica sem espaço em disco e o Cloud SQL não consegue gerar um registo de auditoria, a base de dados continua a permitir que o utilizador execute consultas de leitura, mesmo que esta atividade gere normalmente um registo de auditoria.

Instâncias só de leitura

Se uma instância tiver a flag read_only definida como true, não pode adicionar nem atualizar regras de auditoria, porque estas são armazenadas nas tabelas. Antes de poder criar, atualizar ou eliminar regras, tem de remover a flag read_only.

Limitações e problemas conhecidos

Taxa de carregamento de registos

Antes de o Cloud SQL enviar registos de auditoria para o Cloud Logging, estes são escritos temporariamente no disco da instância, usando espaço em disco. Os registos 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 registos excede a taxa de carregamento, a instância sofre um aumento na utilização do disco, o que pode fazer com que a base de dados fique sem espaço em disco e falhe. Mesmo que os aumentos automáticos do armazenamento em disco estejam ativados, o aumento da utilização do disco aumenta os custos.

Ao usar esta funcionalidade, recomendamos que:

  • Ative os aumentos automáticos de armazenamento.
  • Monitorize a utilização geral do disco. Não pode monitorizar a carga da geração de registos 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 registos limitando a atividade da base de dados ou reduzindo a auditoria.

Audite operações sem êxito

Se as suas regras de auditoria incluírem a auditoria de operações sem êxito (op_result está definido como U para operações sem êxito ou B para operações com e sem êxito), alguns utilizadores podem sobrecarregar a instância da base de dados com registos de auditoria executando continuamente operações sem êxito. Se a velocidade de geração de registos exceder a taxa de carregamento de registos, pode ocorrer um crescimento indesejável na utilização do disco, o que esgota o espaço em disco. Em alternativa, quando auditar operações sem êxito:

  • Controle o acesso ao nível da instância.
  • Configure um sistema de monitorização ou alertas para o aumento anormal dos registos de operações sem êxito.

Regras de auditoria

Não pode criar mais de um total de 1000 combinações de regras de auditoria por instância da base de dados. Uma combinação de regras de auditoria é um conjunto único de um utilizador, uma base de dados, um objeto e operações. Por exemplo, uma regra de auditoria que audite user1,user2, db1,db2, table1,table2, select,delete gera 2 x 2 x 2 x 2 = 16 combinações. A criação ou a atualização de regras de auditoria falha se o número total de combinações de regras de auditoria exceder 1000.

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, a cláusula WHERE, consultas aninhadas, subconsultas, etc.
    • Em UPDATE, DELETE, INSERT e REPLACE extratos.

    Por exemplo, se tiver uma regra de auditoria para auditar o objeto func1, os seguintes elementos não sã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 operadores e sem uma cláusula WHERE é auditada:

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

  • De momento, a filtragem por endereço IP não é suportada.

O que se segue?