ApsaraDB RDS:Use the SQL Explorer and Audit feature

logout! marca um evento de desconexão. A duração de execução mostrada é o tempo ocioso entre a última interação e a desconexão. O código de status 1158 significa desconexão de rede, o que pode ocorrer pelos seguintes motivos:

• A conexão do cliente expirou

• O servidor desconectou

• A conexão excedeu o valor de interactive_timeout ou wait_timeout

Um % na coluna Access Source aparece quando uma stored procedure está envolvida. Isso ocorre porque a stored procedure é definida com um DEFINER que inclui % como host. Exemplo: ` CREATE DEFINER= test_user @% PROCEDURE das () `.

Para reproduzir esse comportamento:

1. No console do ApsaraDB RDS, crie um banco de dados e uma conta padrão e conceda permissões nesse banco de dados para essa conta. Para mais detalhes, consulte Create accounts and databases.

2. Conecte-se à instância usando a conta test_user via CLI. Para mais detalhes, consulte Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.

3. Mude para o banco de dados testdb e crie uma stored procedure:

   -- Switch to testdb
   USE testdb;
   
   -- Create a stored procedure
   DELIMITER $$
   DROP PROCEDURE IF EXISTS `das` $$
   CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
   BEGIN
   SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
   END $$
   DELIMITER;

4. Conecte-se à instância usando uma conta privilegiada. Para mais detalhes, consulte Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.

5. Chame a stored procedure:

   -- Switch to testdb
   USE testdb;
   
   -- Call the stored procedure
   CALL das();

   Saída esperada:

   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
   | ID     | USER      | HOST   | DB     | COMMAND | TIME | STATE     | INFO                                                                    |
   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
   | 487818 | test_user | %:2065 | testdb | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
   +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

O recurso de cache de consulta rápida está ativado. Quando a mesma consulta atinge o cache, o MySQL retorna o resultado armazenado em cache diretamente sem verificar o InnoDB. Portanto, a contagem de linhas verificadas é zero. Para mais detalhes, consulte Fast query cache.

Ambos os tipos de log capturam alterações incrementais na sua instância RDS, mas diferem na cobertura e nos casos de uso:

	Logs do SQL Explorer	Binary logs
Cobertura	Todas as operações DQL, DML e DDL	Apenas operações de adição, exclusão e modificação
Completude	Um pequeno número de registros pode ser perdido sob carga pesada	Preciso dentro do período de retenção de backup
Disponibilidade	Tempo real	Não gerado em tempo real; transferido periodicamente para o Object Storage Service (OSS), retido por 7 dias
Inclui IP de origem e conta	Sim	Não
Ideal para	Auditoria de conformidade, solução de problemas, análise completa de atividades	Recuperação de dados usando dados incrementais precisos

Arquivos de binary log que estão sendo gravados atualmente não podem ser transferidos para o OSS. Como resultado, alguns arquivos podem falhar ao fazer upload ao usar o recurso Upload Binlogs. Para mais detalhes, consulte How do I remotely obtain and parse the binary log file of an ApsaraDB RDS for MySQL instance?

O SQL Explorer and Audit é uma versão atualizada do SQL Explorer. O ponto de entrada agora está rotulado como SQL Explorer and Audit.

Não. Apenas a latest version of SQL Explorer and Audit pode ser ativada em instâncias RDS.

Não. Exportar registros de auditoria não os exclui do sistema.

Não. As configurações de alerta e auditoria do SQL Explorer and Audit aplicam-se no nível da instância e não podem ser diferenciadas para contas de banco de dados individuais. Por exemplo, você não pode configurar "o usuário A não recebe alertas" ou "auditar apenas as operações do usuário B". Para gerenciar notificações de alerta por usuário, filtre-as na camada da sua aplicação ou usando políticas de notificação do Cloud Monitor.

Se os dados da tabela forem excluídos acidentalmente ou maliciosamente, use o SQL Explorer and Audit para identificar a conta e o endereço IP que realizaram a exclusão:

1. Faça login no console do ApsaraDB RDS. Encontre a instância e clique no respectivo ID.

2. No painel de navegação à esquerda, escolha Autonomy Services > SQL Explorer and Audit.

3. Na aba Audit, na seção Logs, defina o intervalo de tempo para cobrir o período em que a exclusão ocorreu e, opcionalmente, filtre pelo nome do banco de dados.

4. Insira DELETE na caixa de pesquisa de palavras-chave SQL e clique no ícone de pesquisa.

5. Nos resultados, localize o registro da operação DELETE e clique nele para visualizar os detalhes, incluindo o nome da conta e o endereço IP do cliente.

Use campos de logs de erros, como o nome do banco de dados e o endereço IP do cliente, como condições de filtro no SQL Explorer and Audit para localizar conexões anômalas. Procedimento:

1. Faça login no console do ApsaraDB RDS e acesse a página de detalhes da instância. No painel de navegação à esquerda, escolha Autonomy Services > SQL Explorer and Audit.

2. Na aba Audit, clique em Enable Advanced Query para expandir as condições avançadas de filtro.

3. No campo Database, insira o nome do banco de dados, por exemplo, battery.

4. No campo Client IP, insira o host do log de erros, por exemplo, 172.25.244.207.

5. Defina o Time Range para cobrir o período em que a conexão anômala ocorreu.

6. Clique em Query para executar a consulta de filtro combinada.

Filtre os resultados de Search (audit) por tipo de operação. Na página SQL Explorer and Audit, abra a aba Search e defina o filtro Operation type como LOGIN para consultar o histórico de logins da instância. A lista de resultados inclui as colunas User (conta de login) e Client IP, que ajudam a identificar quem fez login e de onde.

O SQL Explorer and Audit registra operações no nível da instrução SQL e não fornece comparação de valores antes e depois no nível do campo. Para visualizar o valor de um campo específico, como status, antes e depois de uma alteração, use o recurso de rastreamento de dados do Data Management (DMS) para localizar a origem da mudança.