Log de segurança

Problema e finalidade

O log de segurança é um fluxo separado de registros sobre quem entrou no cluster, quem alterou papéis e configurações e o que aconteceu com as máquinas virtuais. Ele fica em uma tabela própria no banco de dados do vStack Center, separado dos logs de diagnóstico dos componentes, e é aberto em uma tela dedicada — Security Event Log.

Seus requisitos são diferentes dos de um log de diagnóstico. Um registro do log de segurança não pode ser substituído nem removido sem que isso seja detectado: investigações de incidentes e auditorias regulatórias dependem dele. Por isso, cada registro carrega um hash SHA-256 que o vincula aos demais, e o cluster pode percorrer a cadeia inteira e informar onde ela está rompida.

Isso levanta perguntas que os administradores precisam responder. Quais eventos exigem ação e quais são atividade de fundo? O que significa o status "cadeia rompida"? Para onde vai o log quando a tabela cresce, e em que um arquivo compactado difere de uma exportação?

Esta página explica o modelo. Para ler e filtrar eventos, consulte Como ler o log e filtrar eventos; para exportar o log, baixar um arquivo compactado e iniciar uma verificação de integridade, consulte Como exportar o log, baixar um arquivo compactado e verificar a integridade.

Modelo e entidades

Registro de evento

Um registro é um conjunto plano de campos. Ele tem três partes: o que aconteceu e quando, quem foi o ator e qual objeto foi afetado.

Campo	O que mostra
id	ID numérico do registro; usado para ordenação e endereçamento
event_uuid	UUID do evento
ts	horário do evento, um timestamp Unix em segundos
event_type	código do tipo de evento, como auth.login.success
user_id	ID do usuário que executou a ação
username	nome do usuário que executou a ação
object_type	tipo do objeto sobre o qual a ação foi executada
object_id	ID do objeto
object_name	nome do objeto
result	resultado: success ou failure
details	informações adicionais
remote_ip	endereço do cliente
request_id	UUID da requisição ao cluster que gerou o registro
record_hash	hash SHA-256 do registro — um elo da cadeia
acknowledged	a marca do usuário atual indicando que o evento foi lido

Os campos de ator e de objeto ficam vazios quando o evento não os tem: o login no cluster não tem objeto, e um evento do sistema não tem usuário. O campo request_id vincula o evento à requisição ao cluster que o gerou — um ponto de partida útil para uma investigação quando uma única ação produziu vários registros.

Esses mesmos campos se tornam colunas do arquivo quando o log é exportado para CSV ou JSON. A tabela na tela mostra apenas alguns deles; os demais aparecem no cartão do registro individual.

Catálogo de tipos

Um tipo de evento é um código em string com pontos: auth.login.success, auth.login.failure. O cluster mantém a lista de tipos: cada código tem uma categoria, um nível de severidade e um nome legível. Esse catálogo alimenta o filtro de tipo de evento e os rótulos da tabela, portanto é a versão do cluster que determina o conjunto de tipos, e não o cliente.

Eventos dos próprios nós

Antes da 3.0.5, o log registrava apenas eventos do plano de gerenciamento. Na 3.0.5, foram adicionados eventos do sistema operacional dos nós e do software de virtualização — eles chegam dos agentes dos nós e entram na mesma cadeia de hashes.

Tipo de evento	O que o registro descreve	Categoria	Severidade
os.ssh_login_success	login SSH bem-sucedido em um nó	auth	info
os.ssh_login_failure	login SSH malsucedido em um nó	auth	warning
os.user_local_created	criação de uma conta local em um nó	auth	notice
os.user_local_deleted	exclusão de uma conta local em um nó	auth	notice
os.sysctl_changed	alteração de um parâmetro do kernel do nó (sysctl)	config	warning
os.boot	inicialização do nó	system	notice
os.shutdown	desligamento normal do nó	system	notice
os.shutdown_unclean	desligamento anormal do nó	system	error
os.kernel_panic	kernel panic no nó	system	critical
system.service_stopped_unclean	encerramento anormal do software de virtualização: término do processo, falha ou queda de energia na máquina de gerenciamento	system	error
vm.console_connected	conexão a um console de VM por WSS	vm	info
vm.console_connect_failed	conexão malsucedida a um console de VM	vm	warning

Desses eventos, apenas os.kernel_panic entra na contagem de eventos críticos: sua severidade é critical, e o contador conta os três níveis mais altos. Os desligamentos anormais tanto de um nó quanto do software de virtualização têm severidade error: eles não entram no contador, mas disparam notificações por e-mail quando o limite é error ou inferior.

Os registros os.shutdown_unclean e system.service_stopped_unclean aparecem na próxima inicialização, e não no momento da falha: até lá, nada pode informá-la. Em uma instalação limpa, a primeira inicialização não cria um registro falso.

Categorias e severidade

Uma categoria agrupa tipos por área. Os registros e as exportações usam um código curto, enquanto o painel de filtros mostra o rótulo da interface — três dos seis são diferentes:

Código no registro	Rótulo no painel de filtros	Área
auth	authentication	autenticação e gerenciamento de acesso
vm	virtual machines	máquinas virtuais
config	configuration	configuração da infraestrutura
role	role	gerenciamento de papéis
system	system	eventos do sistema
integrity	integrity	monitoramento de integridade

A severidade tem sete níveis, do mais alto ao mais baixo: emergency, alert, critical, error, warning, notice, info. O cluster considera críticos os três níveis mais altos — emergency, alert, critical. Esses são os níveis usados no contador de não lidos e nas configurações de notificações por e-mail.

Como funciona

Cadeia de hashes

Cada registro armazena seu próprio hash SHA-256 no campo record_hash, que o vincula aos registros vizinhos do log. Remover ou substituir um registro no meio rompe o vínculo: os hashes dos registros seguintes deixam de corresponder, e a verificação informa o ID do registro em que a cadeia se rompeu.

Esse design dá ao log sua principal propriedade: ele é somente de acréscimo (append-only). O log pode ser lido, marcado como lido, exportado e arquivado — registros individuais não podem ser editados nem excluídos. O arquivamento é a única forma de reduzir o tamanho da tabela.

Verificação de integridade

A verificação da cadeia é executada em segundo plano. Ao ser iniciada, o cluster distribui imediatamente o trabalho: divide o log em partes iguais e as atribui a workers que processam suas partes simultaneamente. Enquanto a verificação está em execução, o botão de início mostra o percentual de conclusão; quando ela termina, aparece ao lado um relatório com o horário, o resultado e o número de registros verificados.

O resultado é um de cinco status. O cluster mantém o conjunto de status e seus rótulos.

Status	Significado
Never Started	nenhuma verificação foi iniciada no cluster ainda
Running	a verificação está em execução; o relatório mostra o percentual de conclusão
Completed	a verificação terminou; a cadeia está íntegra
Failed	a verificação não terminou
Chain Broken	a cadeia está rompida; o relatório mostra o ID do registro em que ela se rompeu

Os workers individuais têm status próprios: Running, Completed, Failed, Chain Broken, Stopped, Pending. Eles ajudam a investigar uma verificação que travou: mostram se um worker ou todos os workers falharam.

Apenas uma verificação é executada no cluster por vez. Até que ela termine, outra solicitação de início é rejeitada.

Eventos críticos e respostas

A marca de leitura é pessoal. Ela responde "o usuário atual revisou este evento?", e não "a equipe o investigou?": dois administradores veem valores diferentes para o mesmo evento.

Dois mecanismos dependem dessa marca. O indicador no cabeçalho mostra o número de eventos críticos não lidos do usuário atual, e as linhas desses eventos são destacadas na tabela do log. Marcar os eventos como lidos limpa ambos — seja para eventos selecionados, seja para todos os eventos críticos não lidos de uma vez. Marcar o mesmo evento novamente não causa erro.

O terceiro mecanismo é o e-mail. O cluster envia notificações para uma lista de endereços, com um limite de severidade: eventos abaixo do limite não geram e-mails. O limite padrão é alert, que abrange apenas violações de integridade. Os e-mails são enviados pelo dispatcher do vStack Center por meio de um servidor SMTP configurado na VM de gerenciamento. Sem ele, as notificações não funcionam, mesmo quando ativadas na interface. A configuração é descrita em Como configurar notificações por e-mail do log de segurança.

Crescimento da tabela e arquivamento

O log é somente de acréscimo, então sua tabela cresce, e esse crescimento precisa ser limitado. O arquivamento automático move os registros antigos para um arquivo CSV compactado quando a tabela ultrapassa o limite de tamanho.

Configuração	O que controla	Limites
security_log_archive_enabled	se o arquivamento automático está ativado	—
security_log_archive_target_size	limite de tamanho da tabela do log, em bytes	de 10 MB a 16 GB
security_log_archive_path	diretório de armazenamento dos arquivos compactados	comprimento do nome de 1–256
security_log_disk_alert_threshold	limite de espaço livre abaixo do qual o cluster emite um aviso, em bytes	no mínimo 100 MB

Uma chave acima da tabela do log ativa e desativa o arquivamento automático. As outras três configurações ficam no formulário de configurações de arquivamento; os dois tamanhos nesse formulário são especificados em megabytes.

Um arquivo compactado é um arquivo .csv.gz com um nome como security_log_a3f1b2c4_03_01_2025.csv.gz. Para um arquivo concluído, a lista mostra o período, o tamanho, a contagem de registros, o horário do arquivamento e o checksum SHA-256. Um arquivo ainda em criação também aparece na lista, mas sem esses campos — ainda é cedo para baixá-lo.

Um arquivo compactado e uma exportação têm finalidades diferentes. Uma exportação é uma seleção pontual baseada em filtros: o arquivo é criado em um diretório temporário no nó de gerenciamento, enviado ao navegador e excluído. Um arquivo compactado armazena permanentemente os registros removidos da tabela: o arquivo fica no diretório de arquivos compactados e permanece lá após o download.

Quem pode ver o quê

O log de segurança é um objeto de nível de cluster. Ele está disponível para dois papéis globais: Cluster master (papel 1) e Security Admin (papel 6). Os papéis de VDC não podem ver o log: seus eventos abrangem todo o cluster.

O acesso é concedido por privilégios, e não pelo número do papel, portanto verifique o privilégio.

id	Nome no cartão do papel	Concedido a	O que permite
10000	View Security Log	Cluster master, Security Admin	ler eventos, o catálogo de tipos, a contagem de eventos críticos e o status da verificação
10001	Export Security Log	Cluster master, Security Admin	exportar eventos para CSV e JSON
10002	Verify Security Log	Cluster master, Security Admin	iniciar a verificação da cadeia de hashes
10003	View Security Archive	Cluster master, Security Admin	listar arquivos compactados
10004	Export Security Archive	Cluster master, Security Admin	baixar um arquivo compactado
10005	View Security Archive Settings	Cluster master, Security Admin	ler as configurações de arquivamento
10006	Edit Security Archive Settings	somente Cluster master	editar as configurações de arquivamento
10007	Acknowledge Security Event	Cluster master, Security Admin	marcar um evento como lido
10008	View Security Notify Settings	Cluster master, Security Admin	ler as configurações de e-mail
10009	Edit Security Notify Settings	somente Cluster master	editar as configurações de e-mail

Há também dois privilégios de configurações de segurança: View Security Settings (9000) e Edit Security Settings (9001). Além de editar, o segundo permite ler as configurações de bloqueio — consulte Sessões e configurações de login.

A distinção entre ler e editar tem consequências práticas. O Security Admin pode ver o log, os arquivos compactados e os dois grupos de configurações, mas somente o Cluster master pode alterar os limites de arquivamento e a lista de destinatários de e-mail. O modelo de privilégios e escopos é descrito na referência de papéis e privilégios.

Limitações

Uma exportação é limitada a 100 000 registros. Uma única exportação não pode retornar mais: o arquivo é criado no disco do nó de gerenciamento, e o limite se aplica ao tamanho dessa operação. Solução alternativa — restrinja a seleção com filtros e um intervalo de tempo ou obtenha o log em partes; os registros históricos ficam armazenados em arquivos compactados.

As exportações não são armazenadas no cluster. O arquivo é criado em um diretório temporário, enviado ao navegador e excluído. Solução alternativa — use um arquivo compactado para armazenamento de longo prazo, e não uma exportação; para obter a mesma seleção novamente, repita a exportação.

Apenas uma verificação da cadeia é executada por vez. Uma segunda solicitação de início é rejeitada até que a primeira verificação termine. Solução alternativa — aguarde a verificação atual: seu progresso aparece como percentual no botão, e o ID do registro em que a cadeia se rompeu aparece no relatório da última verificação.

Um arquivo compactado incompleto não pode ser baixado. Um arquivo ainda em criação aparece na lista, mas as solicitações de download são rejeitadas. Solução alternativa — aguarde até que a entrada mostre um checksum, uma contagem de registros e um horário de arquivamento.

A marca de leitura é pessoal. Ela não pode ser usada para avaliar o trabalho de um turno: reflete apenas o usuário atual. A solução alternativa é um processo combinado, e não uma solução técnica: acompanhe se um evento foi investigado por meio de um processo externo e use a marca como filtro pessoal.

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, security-event-export, security-event-archive-list, security-event-archive-export, security-event-archive-settings-get, security-event-archive-settings-set, security-event-log-verify, security-event-log-status, security-verification-statuses — consulte a referência da API.

Leitura adicional

• Como ler o log e filtrar eventos — a tela do log, os filtros da lista, um registro individual e a marca de leitura.
• Como exportar o log, baixar um arquivo compactado e verificar a integridade — exportação para CSV e JSON, arquivos compactados, configurações de arquivamento e início da verificação da cadeia.
• Como configurar notificações por e-mail do log de segurança — o servidor SMTP, os destinatários, o limite de severidade e o conteúdo dos e-mails.
• Papéis e privilégios — como o acesso é determinado por privilégio e escopo.
• Um arquivo compactado do log de segurança baixado não abre — solução de problemas de um arquivo .csv.gz corrompido.