Exportação para SIEM (CEF)¶

A equipa de segurança do cliente reúne os eventos de todos os seus sistemas num único SIEM e analisa-os lá, e não no painel de cada sistema em separado. O Mcaster entrega o registo de auditoria no formato CEF (Common Event Format): um formato de texto, uma linha por evento, com os campos separados por delimitadores. ArcSight, KUMA, MaxPatrol SIEM e outros recetores empresariais aceitam-no sem qualquer adaptação.

A exportação entrega a janela escolhida do diário inteira, num só ficheiro, dos lançamentos mais antigos para os mais recentes. Pode ser obtida de duas maneiras:

• com o botão Exportar para CEF da secção Registo de auditoria — o navegador guarda o ficheiro;
• com um pedido à API — é assim que o recoletor do SIEM recolhe o diário segundo um calendário.

A exportação é a mesma leitura do diário que a lista do painel: as mesmas permissões, a mesma opção de licença, os mesmos lançamentos. Para ela o Mcaster não cria ficheiros na máquina nem abre ligações de saída para um recetor.

Exportar pelo painel¶

O botão Exportar para CEF fica por cima da lista, ao lado de Aplicar. Exporta exatamente o que a lista mostra:

• Tipo de recurso, Nome do recurso e Ator restringem a exportação tal como restringem a lista;
• De e Até definem a janela de tempo;
• campos vazios significam «não filtrar» — exporta-se todo o diário dentro da sua retenção.

A exportação usa os filtros aplicados. Se depois de premir Aplicar um campo foi alterado mas a lista não foi relida, a exportação usa o valor anterior: o ficheiro coincide sempre com o que se vê no ecrã.

O ficheiro chama-se audit-log.cef. Contém todos os lançamentos da janela, e não só as páginas que a lista já carregou.

O botão é visível para os mesmos papéis que o próprio diário — security e superadmin. Quando o diário não está incluído na licença, o botão fica desativado.

O ficheiro é montado na memória do separador do navegador. Para uma janela de vários dias isso chega; o diário de um período de retenção longo é melhor recolher pela API.

Exportar pela API¶

GET /central/api-v4/audit-log/export?format=cef&from=2026-09-27T00:00:00Z&to=2026-09-27T12:00:00Z

A autorização é a mesma autorização de operador que o resto da API de gestão, e os papéis também: security e superadmin.

Parâmetros:

• format — obrigatório; de momento o único valor é cef;
• from, to — os limites da janela no formato RFC 3339, ambos incluídos na janela;
• resource_type, resource_name, actor, actor_type — os mesmos filtros do painel; actor_type aceita admin, static e node.

A resposta é texto (text/plain), como anexo com o nome audit-log.cef. Chega em fluxo: as primeiras linhas chegam de imediato e o servidor mantém em memória uma única página do diário, pelo que o tamanho da janela não é limitado por nada.

Recusas:

• 400 — um limite da janela não está no formato RFC 3339, ou o formato está em falta ou é desconhecido. Um pedido inválido nunca se transforma numa exportação do diário inteiro;
• 403 — o papel não tem acesso ao diário;
• 404 — o registo de auditoria não está incluído na licença.

Se a exportação se interromper a meio da transferência — por exemplo, a base de dados falha do lado da máquina —, a resposta termina como uma transferência incompleta: o curl indica uma ligação interrompida, o navegador marca a transferência como falhada. Um ficheiro que chegou inteiro contém a janela inteira.

Sem to, a janela fica aberta para a frente: os lançamentos feitos enquanto a exportação decorre também entram. Se for precisa uma fronteira fixa, indique to.

A linha CEF¶

Cada evento é uma linha:

CEF:0|Flussonic|mcaster|26.09|stream_config.patch|stream_config.patch|3|rt=1790590530250 externalId=0f6b8a1e-6a3c-5d7e-9b1a-2c3d4e5f6a7b dvchost=11111111-2222-3333-4444-555555555555 suid=admin suser=ivanov outcome=success src=10.20.1.11 cs1=stream cs1Label=resourceType cs2=conference-a cs2Label=resourceName cs3=9c1f07e2 cs3Label=sessionId cs4=4bf92f3577b34da6a3ce929d0e0e4736 cs4Label=traceId cs5={"fields":["labels"],"role":"admin","src_ip":"10.20.1.11","version":7} cs5Label=details cn1=3672 cn1Label=auditId cn2=1 cn2Label=schemaVersion

O cabeçalho, até à sétima barra vertical:

• Device Vendor — Flussonic;
• Device Product — mcaster: é por ele que o SIEM escolhe as suas regras de análise;
• Device Version — a versão do Mcaster instalado;
• Device Event Class ID e Name — a ação, o mesmo nome de máquina da coluna Ação da lista: stream_config.patch, admin.create, auth.login_failed;
• Severity — a gravidade do evento, descrita abaixo.

Seguem-se os campos, na forma chave=valor:

Os campos que um evento não tem ficam de fora da linha por completo: uma chave vazia seria lida pelo SIEM como um valor vazio. Uma ação com a chave estática, por exemplo, não tem suser nem cs3.

Os caracteres especiais são escapados como exige a especificação CEF: no cabeçalho, a barra invertida e a barra vertical; nos campos, a barra invertida e o sinal de igual; as quebras de linha passam a \n. Por isso um evento ocupa sempre exatamente uma linha, seja o que for que os seus valores contenham.

Gravidade do evento¶

A gravidade não é guardada no diário — é deduzida do evento no momento da exportação, por uma mesma tabela:

• 7 — uma ação falhada; de momento, uma tentativa de início de sessão falhada (auth.login_failed);

• 5 — uma ação que a equipa de segurança espera acima do fluxo geral:

  • a remoção de qualquer coisa, a revogação de uma máquina, a reemissão dos bilhetes internos do cluster, a revelação do token de adesão;
  • qualquer ação sobre as contas de administradores;
  • a edição das definições de acesso e das definições da própria instalação de controlo;
  • a abertura e o fecho da janela de adesão;
  • qualquer ação com a chave estática — um início de sessão com as credenciais de emergência merece atenção por si só;

• 3 — todo o resto: edição de streams, modelos, fontes da guia, o início de sessão de um administrador.

As regras apoiam-se na forma da ação, e não numa lista feita de antemão, pelo que as ações que surgirem em versões futuras recebem a sua gravidade pelas mesmas regras.

Recolha periódica num SIEM¶

O recoletor do SIEM recolhe o diário por janelas segundo um calendário: cada pedido usa como from o to do anterior. Os dois limites pertencem à janela, pelo que um lançamento que cai exatamente na junção chega duas vezes — o SIEM descarta o duplicado por externalId. Da mesma forma, uma janela repetida após uma quebra é transferida sem perdas.

Uma janela não deve ir além da retenção do diário — sete dias por omissão (a definição audit_log_ttl_secs, veja Conservação e proteção). Um recoletor que se atrasou mais do que isso só encontrará o que ainda não foi apagado.

A um recoletor que lê JSON também serve a lista do diário com cursor, descrita na secção Exportação para um SIEM da página do diário. Os campos do evento são os mesmos; só muda a forma.