Registo de auditoria¶

O registo de auditoria responde a uma única pergunta: quem fez isto. Cada alteração feita pelo painel ou pela API — um stream criado, uma entrega retirada, as definições de uma máquina alteradas, um administrador criado — deixa um lançamento com a hora, o autor e o nome daquilo que mudou. Para lá vão também os inícios de sessão no painel, os bem-sucedidos e os falhados.

Isto não são os logs nem a monitorização. Os logs respondem a «o que aconteceu dentro do processo»; o diário responde a «o que fez uma pessoa». Por isso há poucos lançamentos, leem-se a olho e o painel não os consegue apagar.

Quem vê o diário¶

A secção Registo de auditoria é vista por dois papéis:

• security — o papel de supervisão: o registo de auditoria e a própria conta (entrar, alterar a sua palavra-passe, sair). As definições, os streams e o estado observado estão-lhe totalmente fechados, leitura incluída.
• superadmin — como tudo o resto no painel.

Os papéis admin e viewer não têm acesso: a supervisão dos operadores não pertence aos próprios operadores, e a um espectador o diário revelaria os logins dos administradores e os endereços de onde entram. A proibição é aplicada pelo servidor, não pelo menu: a um papel sem acesso a ligação direta também é recusada.

Os papéis são atribuídos na secção Contas. A quem vigia o que os operadores fazem cria-se uma conta própria com o papel security, em vez de lhe dar um superadministrador.

O que entra no diário¶

Deixa lançamento uma alteração que chegou a acontecer e o início de sessão:

• a edição de definições — de um stream, de uma máquina, de um modelo, de uma fonte da guia, do acesso, da própria instalação de controlo;
• o trabalho com as máquinas do cluster — registo, revogação, remoção, abertura e fecho da janela de adesão;
• o trabalho com as contas — criação, edição, remoção, alteração da palavra-passe;
• a migração de definições do Flussonic v3 — tanto a construção do plano como a sua aplicação;
• a execução manual da atribuição;
• o início de sessão de um administrador e a tentativa falhada;
• o trabalho com o registo de clientes — criar, editar e eliminar um cliente, vincular e desvincular uma conta.

Uma operação em massa deixa um lançamento por cada objeto afetado, não um por chamada: migrar trezentos streams aparece como trezentos lançamentos, e a procura por nome encontra qualquer um deles.

À parte fica a revelação de um token de adesão válido: é uma leitura, mas revelar um segredo equivale a entregá-lo, por isso o lançamento mantém-se. O valor do token nunca entra nele.

O que não há no diário¶

O diário cala-se sobre o que não é ação de uma pessoa:

• As tentativas falhadas. Uma recusa por permissões, uma recusa de validação, um conflito de versão do documento não são uma alteração. Essas tentativas veem-se nos logs e nos contadores. Há uma exceção: o início de sessão falhado é registado, porque adivinhar palavras-passe é precisamente o que a supervisão vigia.
• A repetição sem alteração. Guardar um documento idêntico ao já guardado não deixa lançamento.
• As decisões próprias da máquina. A atribuição planeada dos streams, as limpezas por retenção, a mudança do detentor do mandato pertencem aos logs e ao diário de decisões de atribuição, não à auditoria. A execução manual da atribuição é registada: foi uma pessoa que a fez.
• A renovação da sessão e a saída. Registam-se o início de sessão e a tentativa falhada; renovar a sessão e sair, não.

Nos lançamentos nunca há segredos: nem palavras-passe, nem chaves, nem tokens, nem documentos de definições completos. De uma edição regista-se que campos foram tocados, não o que neles foi escrito.

A lista e as suas colunas¶

Os lançamentos vão dos novos para os antigos. O botão Carregar mais traz a página seguinte: a lista não acaba nos primeiros cinquenta lançamentos.

A tabela tem cinco colunas:

• Hora — o momento da ação.
• Ator — quem agiu. Ou o login de um administrador, ou um dos tipos de serviço: chave estática (entrada com as credenciais de emergência de /etc/mcaster/secrets.env, comuns a todos e por isso sem nome atrás) e nó (o registo de uma máquina do cluster, em que o ator é o seu identificador).
• Ação — o que foi feito, com um nome de máquina da forma <recurso>.<verbo>: stream_config.put, node_config.patch, admin.create, auth.login. Os nomes são estáveis, o que é cómodo para procurar e filtrar.
• Recurso — sobre o quê: tipo e nome, por exemplo stream/program-a.
• Resultado — sucesso numa ação consumada e falha num início de sessão falhado.

A seta à esquerda da linha abre os detalhes do lançamento: o endereço de onde veio o pedido, o papel do administrador, a versão do documento depois da edição, a lista de campos alterados e — se o pedido chegou com um cabeçalho de rastreio — o seu identificador, com o qual o lançamento se cruza com os logs.

Procura no diário¶

Por cima da lista há cinco campos que funcionam em conjunto:

• Tipo de recurso e Nome do recurso — «tudo o que foi feito a este stream».
• Ator — «tudo o que esta pessoa fez».
• De e Até — uma janela de tempo em formato RFC 3339, por exemplo 2026-08-14T14:00:00Z.

Aplicar relê a lista desde o início. Um campo vazio significa «não filtrar».

Um incidente costuma ser analisado em duas consultas: primeiro por recurso — o que aconteceu a este stream — e depois pelo ator do lançamento encontrado — que mais fez essa mesma pessoa nesse dia.

Conservação e proteção¶

O diário vive na mesma base de dados que o resto do estado da máquina e sobrevive ao reinício do processo. Não cria ficheiros no disco.

Os lançamentos apenas se acrescentam: editar ou apagar um lançamento concreto não existe nem no painel nem na API. A retenção — sete dias por omissão — é definida pela definição de processo audit_log_ttl_secs em /etc/mcaster/, e pelo painel não se altera. É deliberado: quem quiser esconder a sua ação não deve poder encurtar a retenção com o mesmo acesso com que a cometeu. O valor zero significa «conservar tudo», não «apagar tudo».

Perante quem tem acesso à própria base de dados o diário não oferece proteção nem a promete.

Exportação para um SIEM¶

Para fora o diário é entregue de uma única forma: por leitura. O Mcaster não abre ficheiros, sockets nem ligações de saída para um recetor.

Um recoletor externo lê GET /central/api-v4/audit-log com a mesma autorização de operador que o resto da API de gestão e segue o diário por cursor: a resposta traz o campo next, que se passa como parâmetro cursor no pedido seguinte. A ordem é estável — dos novos para os antigos — e cada evento tem um identificador global derivado da identidade da instalação e do número do lançamento. Por isso uma página relida depois de uma quebra devolve os mesmos identificadores e o recetor descarta os duplicados sozinho; os eventos de duas instalações diferentes nunca coincidem.

Os filtros são os do painel: resource_type, resource_name, actor, from, to, limit (até 1000 lançamentos por página).

O diário e a licença¶

O registo de auditoria é uma opção de licença à parte. Enquanto não está concedida nada é gravado, e a secção di-lo diretamente: a lista está vazia e por cima dela há uma mensagem a indicar que o diário não está incluído na licença. Uma lista vazia sem explicação seria indistinguível de «não há nada no diário», e uma supervisão avariada pareceria uma supervisão a funcionar.

A opção é lida em cada pedido, por isso assim que é concedida o diário começa a funcionar sem reiniciar: as novas ações são gravadas e a lista abre. O que aconteceu enquanto a opção não estava concedida não aparecerá: esses lançamentos nunca foram criados.