Pular para o conteúdo principal

Como ler o log e filtrar eventos

Quando usar​

Quando você precisa entender o que aconteceu no cluster: quem entrou e quando, quais tentativas de login falharam e o que mudou em papéis e configurações. Este também é o ponto de partida para investigar um incidente — primeiro selecione os eventos por horário e categoria e, em seguida, examine um registro individual por completo.

Tudo o que é descrito abaixo está em uma única tela — Security Event Log. Ela contém a tabela de eventos, o painel de filtros, o cartão do registro individual e as configurações de notificações por e-mail para eventos críticos.

Este procedimento não aborda exportação de arquivos nem verificação da cadeia de hashes: consulte Como exportar o log, baixar um arquivo compactado e verificar a integridade. O modelo de eventos e de severidade é descrito em Log de segurança.

Pré-requisitos​

  • um papel global de nível de cluster — Cluster master ou Security Admin; ler eventos exige ViewSecurityLog, marcá-los como lidos exige AcknowledgeSecurityEvent, e editar as configurações de e-mail exige EditSecurityNotifySettings (somente Cluster master);
  • versão do vStack Center — 3.0.3.

Os botões e itens de menu para os quais você não tem o privilégio necessário não são exibidos. Um botão ausente significa permissões insuficientes.

Etapas​

Etapa 1. Abra o log​

  1. Abra Sites → o cluster desejado.
  2. Na árvore de navegação à esquerda, selecione Security Event Log. O caminho de navegação é Sites → cluster → Security Event Log.
  3. Permaneça na guia Current events — esses são os eventos da tabela do log. A guia Archived events mostra os arquivos compactados; o trabalho com eles é abordado em um procedimento separado.

Etapa 2. Leia a tabela​

A tabela na guia Current events tem as colunas ID, Created, Event type, Severity, Result, User, Category — ID do registro, horário, tipo, severidade, resultado, usuário e categoria. Acima da tabela fica Search in table; abaixo dela, a paginação com um seletor de tamanho de página (10, 25 ou 50 registros).

Leia três colunas em conjunto. Severity separa os eventos críticos da atividade de fundo, Result com o valor Failure identifica ações malsucedidas, e User responde "quem executou esta ação?". Os eventos não lidos dos três níveis de severidade mais altos têm as linhas destacadas — você os vê ao navegar, sem precisar pesquisar.

Search in table pesquisa na página exibida por ID, horário, tipo, severidade, categoria e usuário. Ela não substitui os filtros — para restringir o log inteiro, e não apenas a página, vá para a etapa 3.

Etapa 3. Restrinja a seleção com filtros e um intervalo de tempo​

O botão de funil à direita da pesquisa abre o painel de filtros. Ele tem cinco campos:

CampoO que você seleciona
Categoryárea do evento: authentication, virtual machines, configuration, role, system, integrity
Severitynível de severidade: emergency, alert, critical, error, warning, notice, info
Resultresultado: Success ou Failure
Typeum tipo de evento específico da lista mantida pelo cluster
Usero usuário que executou a ação, da lista de usuários do cluster

O painel mostra os rótulos da interface, enquanto o registro e a exportação usam códigos curtos para as mesmas categorias: authentication é auth, virtual machines é vm e configuration é config; role, system e integrity são iguais. O resultado no registro é success ou failure. A severidade corresponde ao rótulo. Isso é importante ao ler CSV e JSON: filtre a exportação pelos códigos, e não pelos rótulos do painel.

Categoria, severidade e resultado permitem, cada um, um único valor selecionado: clicar novamente no valor selecionado limpa o filtro. Tipo e usuário são selecionados em listas; o valor selecionado aparece abaixo do campo e pode ser removido com o X. Reset limpa os cinco filtros de uma vez.

O intervalo de tempo é definido separadamente com Select date acima da tabela. Ele abre um calendário para selecionar um período; o período selecionado restringe a tabela junto com os filtros do painel.

A lista é atualizada imediatamente após cada alteração; não é necessária confirmação. O contador abaixo da tabela mostra quantos registros há na página e quantos há na seleção inteira.

Log de segurança com o painel de filtros aberto: a categoria authentication está selecionada, com a tabela de eventos filtrada abaixo

Etapa 4. Abra um registro individual por completo​

Clique no ID do registro na coluna ID para abrir o cartão Additional Information. Ele contém campos que não estão nas colunas da tabela:

Campo do cartãoO que mostra
Object name, Object type, Object IDo objeto sobre o qual a ação foi executada; um traço para um evento sem objeto
Detailsinformações adicionais sobre o evento
Remote IPendereço do cliente
Event UUIDUUID do evento
Request IDUUID da requisição ao cluster que gerou o registro
Record Hashhash SHA-256 do registro — um elo da cadeia

Cartão Additional Information: campos do objeto, Details, Remote IP, Event UUID, Request ID e Record Hash

Continue a investigação usando Request ID. Esse ID vincula o evento à requisição que o gerou: se uma única ação produziu vários registros, eles terão o mesmo Request ID.

Etapa 5. Trate os eventos críticos​

Enquanto houver eventos críticos não lidos — dos três níveis de severidade mais altos —, o cabeçalho mostra o indicador critical event com a quantidade deles. Clicar no indicador abre o log filtrado por esses três níveis.

O cluster informa um novo evento crítico por meio de uma notificação pop-up: clicar nela abre o cartão do registro mais recente.

Marque os eventos revisados como lidos com Mark all as read acima da tabela — isso limpa o indicador do cabeçalho e remove o destaque das linhas. O botão aparece somente quando há eventos críticos não lidos.

A marca de leitura é pessoal. Ela responde "o usuário atual revisou este evento?", e não "a equipe o investigou?": o mesmo evento continua não lido para outro administrador.

Etapa 6. Configure e-mails para eventos críticos​

  1. Clique em Actions acima da tabela e selecione Notification settings.
  2. Ative a chave Enable email notifications.
  3. Em Recipients, insira o endereço de um destinatário e pressione Enter — o endereço aparece na lista abaixo do campo. Adicione vários endereços dessa forma; remova os indesejados com o X.
  4. Em Minimum severity for email, selecione o limite de severidade. Eventos abaixo do limite não geram e-mails.
  5. Clique em Save.

Save permanece desativado enquanto o endereço não passar na validação ou nada no formulário tiver mudado. Após salvar, aparece a mensagem "Notification settings updated".

Somente o papel Cluster master pode editar as configurações de e-mail. O Security Admin pode visualizar as configurações, mas não pode salvá-las.

Os e-mails em si são enviados pelo dispatcher do vStack Center por meio de um servidor SMTP cujo endereço é definido na VM de gerenciamento, e não neste formulário. Até que o servidor seja definido, nenhum e-mail é enviado, embora as configurações sejam salvas sem erros. O limite padrão é alert: com ele, os e-mails chegam apenas para violações de integridade. A configuração do servidor, a escolha do limite e a verificação da entrega são abordadas em Como configurar notificações por e-mail do log de segurança.

Verifique o resultado​

Compare a tabela e o cartão do mesmo evento. Pegue um ID da coluna ID, abra o cartão e confirme que ele se refere ao mesmo evento: Event UUID e Record Hash estão preenchidos, e todos os registros de uma mesma ação têm um Request ID.

Verifique o filtro: selecione Category — authentication e Result — Failure; apenas as tentativas de login malsucedidas devem permanecer na tabela. Reset deve restaurar a lista completa.

Verifique a marca de leitura: após Mark all as read, o indicador critical event desaparece do cabeçalho, o destaque das linhas é removido e o próprio botão desaparece até o próximo evento crítico.

Solução de problemas​

O cartão do registro não abre, evento não encontrado (-11202). Um registro com esse ID não está mais na tabela do log — o arquivamento automático o moveu para um arquivo compactado. Solução alternativa — procure o evento nos arquivos compactados da guia Archived events.

A lista não carregou, erro de banco de dados (-24000). O cluster não conseguiu ler o log. Nenhum dado foi perdido: atualize a página; se a falha persistir, verifique o estado do banco de dados do vStack Center.

A seleção tem registros demais para navegar com conforto. Restrinja-a com filtros e um intervalo de tempo, e não com o tamanho da página: Search in table funciona apenas na página exibida e não oferece o panorama completo.

As configurações de e-mail não são salvas (-24007). Um valor não passou na validação: o endereço do destinatário foi digitado incorretamente, ou Enter não foi pressionado e o endereço não foi adicionado à lista. Verifique os endereços na lista abaixo do campo e tente salvar novamente — as configurações já salvas não mudam quando o salvamento falha.

O menu Actions não tem o item Notification settings. O papel não tem o privilégio para as configurações de e-mail. Somente o Cluster master pode editá-las.

O indicador de eventos críticos permanece após marcar os eventos como lidos. A marca de leitura é pessoal, e o indicador conta os eventos não lidos do usuário atual. Verifique se você marcou os eventos com a mesma conta de usuário que está usando para visualizar o log.

Métodos da API​

Operações da API abordadas nesta página: security-event-list, security-event-get, security-event-types, security-event-critical-count, security-event-acknowledge, security-event-notify-settings-get, security-event-notify-settings-set — consulte a referência da API.

Veja também​