ImmutableLog / Arquitetura técnica

Do evento à evidência.
Confiança por arquitetura.

Arquitetura construída para transformar cada evento em confiança verificável, da observação à prova criptográfica.

Cada componente existe por um motivo: tornar eventos críticos verificáveis, com adulteração detectável e defensáveis.

11 estágios. Nenhum opcional.01 / Core ↗02 / SIEM ↗03 / Verificação ↗

01 / Pipeline ponta a ponta

Uma requisição não é apenas armazenada. Ela é transformada em evidência.

Quando um evento entra no ImmutableLog, ele passa por validação, idempotência, selagem criptográfica, ordenação, consenso e persistência append-only antes de fazer parte do ledger.

INRequisiçãoProva auditávelOUT

É isso que transforma um log em algo que pode ser provado.

Estágios obrigatórios: 11; Nenhum opcional
Modelo de consenso: PoA; Proof of Authority
Nós em consenso: N; Maioria qualificada
Operações destrutivas: 0; Sem update, sem delete

02 / O núcleo imutável

Cada etapa,
uma garantia.

11 estágios. Nenhum opcional. É isso que transforma um log em algo que pode ser provado.

01
Papel / Origem do evento
Cliente
Sua aplicação envia eventos críticos por uma API segura.
✓ Garante
Origem identificada e autenticada por chave e endereço de rede.
↳ Sem ele
Sem autenticação na origem, qualquer agente externo poderia injetar eventos forjados.
02
Papel / Porta de entrada
API de Ingestão
A API recebe eventos, valida a estrutura, autentica a requisição e prepara o payload para processamento no ledger.
✓ Garante
Cada evento entra com carimbo de tempo do servidor e identidade do cliente.
↳ Sem ele
Sem timestamp confiável do servidor, a ordem cronológica seria controlada pelo cliente — e manipulável.
03
Papel / Porteiro do ledger
Validação + Enriquecimento
Eventos são normalizados, enriquecidos com metadados e verificados antes de entrar no pipeline do ledger.
✓ Garante
Eventos malformados são rejeitados antes de tocar o ledger; o hash é calculado a partir de uma representação canônica única.
↳ Sem ele
Sem canonização, dois clientes serializariam o mesmo evento de formas diferentes e gerariam hashes distintos.
04
Papel / Defesa contra duplicação
Idempotência
Retries não devem criar verdades duplicadas. A idempotência garante que o mesmo evento seja registrado apenas uma vez, mesmo em falhas ou requisições repetidas.
✓ Garante
A mesma operação produz um único registro, independentemente de retries de rede ou de cliente.
↳ Sem ele
Sem idempotência, instabilidade de rede vira evento duplicado — e duplicação corrompe a história.
05
Papel / Buffer ordenado
Mempool
Eventos válidos entram em uma fila temporária onde são ordenados e preparados para consenso.
✓ Garante
Picos de carga não derrubam o sistema; a ordem de chegada é preservada.
↳ Sem ele
Sem mempool, ou você processa cada evento sincronamente (lento), ou descarta sob carga (perde história).
06
Papel / Distribuição entre nós
Gossip / Propagação interna
Os nós trocam eventos pendentes internamente para que a rede convirja para o mesmo estado do ledger.
✓ Garante
Nenhum nó isolado controla o que está sendo proposto à rede.
↳ Sem ele
Sem gossip, um nó comprometido poderia esconder eventos dos outros antes do consenso.
07
Papel / Acordo coletivo
Consenso PoA
ImmutableLog utiliza um modelo permissionado de Proof of Authority entre nós confiáveis. Blocos são acordados, não presumidos.
✓ Garante
A história é uma decisão coletiva auditável, não a opinião de um único processo.
↳ Sem ele
Sem consenso, um administrador com acesso a um nó reescreveria o histórico sozinho.
08
Papel / Encadeamento criptográfico
Produção de blocos
Eventos são agrupados em blocos. Cada bloco referencia o anterior, criando uma cadeia criptográfica de histórico.
✓ Garante
Alterar qualquer evento passado quebra o hash do bloco e de todos os blocos posteriores — a adulteração se torna matematicamente detectável.
↳ Sem ele
Sem encadeamento por hash, eventos antigos poderiam ser editados sem deixar rastro verificável.
09
Papel / Armazenamento append-only
Persistência append-only
Depois de gravados, os registros não são atualizados nem apagados. A imutabilidade é garantida pela arquitetura, não por política.
✓ Garante
Eventos não podem ser editados nem apagados, nem por administradores de banco.
↳ Sem ele
Sem append-only, qualquer DBA com permissão consegue reescrever o passado e o sistema vira só mais um log.
10
Papel / Redundância da história
Replicação
O ledger é replicado entre nós para preservar disponibilidade e impedir manipulação unilateral do histórico.
✓ Garante
Falha de hardware ou desastre em um nó não apaga a história.
↳ Sem ele
Sem replicação, perder o disco de um nó é perder evidência.
11
Papel / Estado final verificável
Verificação independente
Qualquer parte autorizada pode verificar que um evento existe e que a cadeia permanece íntegra sem confiar no operador.
✓ Garante
Qualquer auditor consultando qualquer nó obtém a mesma resposta — e pode verificar a prova localmente, sem depender do operador.
↳ Sem ele
Sem consistência, dois auditores teriam respostas diferentes para a mesma pergunta — e a evidência perde valor probatório.

03 / Camada SIEM — processamento & leitura

Dois motores, uma fonte da verdade

O core sela os eventos na chain imutável. Um hook alimenta o SIEM, que normaliza para ECS e enriquece — IP real do usuário, geolocalização, threat intel e detecção por regras. O painel lê do SIEM por quatro endpoints, enquanto a prova de inclusão continua vindo do core.

Fluxo real ponta a ponta

01Navegador
02Backend do cliente (meta.client_ip)
03Core — sela na chain
04Hook
05SIEM — ECS + GeoIP + threat + detecção
06Painel do cliente

01 / CORE

Core — imutabilidade e prova

Validação, selagem, ordenação, consenso e persistência append-only. A prova de inclusão (Merkle) mora aqui.

02 / SIEM

SIEM — leitura enriquecida e segurança

Normalização ECS, GeoIP, threat intel e alertas por regra. Somente leitura e isolado por tenant.

Processamento assíncrono

O que a API SIEM faz com cada evento

O core sela e dispara um hook. A partir daí o SIEM processa cada evento por um pipeline assíncrono — nada aqui bloqueia a selagem na chain.

01
Ingestão (hook do core)
Recebe o evento selado por um hook autenticado (token de serviço, comparação em tempo constante), deduplica por idempotência e enfileira.
Garante: A fila assíncrona desacopla o SIEM do core — enriquecer nunca atrasa a selagem.
02
Normalização ECS
Mapeia o meta→ECS de forma determinística e deriva event.action/category a partir do event_type do core.
Garante: Todo evento vira o mesmo schema consultável, independente do formato que o cliente enviou.
03
IP real do usuário
Resolve source.ip por precedência client_ip › XFF (1º hop) › X-Real-IP › conexão, carimbando a proveniência em source_ip_origin.
Garante: Geo, threat e detecção rodam sobre o usuário final — não sobre o proxy ou balanceador.
04
Enriquecimento (GeoIP + threat)
Geolocaliza o source.ip e cruza com feeds de threat intelligence.
Garante: Degrada com elegância: feed fora do ar não bloqueia a indexação do evento.
05
Indexação por tenant
Persiste o documento ECS no índice siem-logs, isolado por tenant.
Garante: Toda leitura é escopada pelo tenant e filtrada no servidor — sem vazamento entre clientes.
06
Detecção (scheduled queries)
Cada regra roda sobre uma janela deslizante em intervalo fixo (brute-force, IP novo, hit de threat); a supressão evita alerta repetido.
Garante: Uma regra que falha não derruba as outras — detecção resiliente por regra.
07
Alertas & notificação
Detecções viram alertas ligados ao tx exato do evento e são entregues por canal.
Garante: Do alerta você chega ao evento imutável — e à prova de inclusão no core.

Quatro endpoints de leitura

/searchlistagem enriquecida de eventos
/aggregateagregações nomeadas (timeline, IPs, países…)
/alertsdetecções por regra
/events/{tx}evento ECS completo + auditoria de leitura

Isolamento por tenant nas duas pontas — a leitura é sempre escopada pelo User Token, filtrada no servidor.
Consistência eventual — o SIEM pode atrasar segundos vs. a chain; a prova sempre vem do core.

04 / Escolhas de engenharia

Princípios de design

Cinco escolhas que definem como a infraestrutura é construída — e por quê.

01
Prova
acima de
presunção
02
Imutabilidade
acima de
conveniência
03
Ordenação determinística
acima de
ambiguidade
04
Verificação independente
acima de
confiança no operador
05
Performance enterprise
acima de
overhead de blockchain pública

Rede permissionada

Criptografia de nível blockchain, sem a rede pública

ImmutableLog usa primitivas criptográficas de nível blockchain, mas não depende de redes públicas, tokens, mineração ou validadores externos. Opera como uma rede fechada, mantida pela própria ImmutableLog, com múltiplos nós para resiliência.

É um ledger privado e permissionado projetado para auditabilidade enterprise.

Sem token
Sem mineração
Sem rede pública
Sem validadores de terceiros

05 / Verificação

A prova vive nos dados.

A verificação não exige confiar no ImmutableLog, nos administradores de banco ou nos logs da aplicação.

Se os hashes validam e a cadeia está íntegra, o histórico pode ser provado. Se algo foi alterado, a quebra se torna visível.

verify-proofExemplo ilustrativo

$ immutablelog verify --event evt_48291

✓ block_id        48291
✓ block_hash      0x4f2b...c9a1
✓ prev_hash       0x91a3...22ef
✓ merkle_proof    valid
✓ chain_integrity intact

status: VERIFIED

Da arquitetura à sua operação

Construa o pipeline que transforma eventos em visibilidade, detecção e prova verificável.

Ver documentação

Do evento à evidência.Confiança por arquitetura.

Uma requisição não é apenas armazenada. Ela é transformada em evidência.

Cada etapa,uma garantia.

Cliente

API de Ingestão

Validação + Enriquecimento

Idempotência

Mempool

Gossip / Propagação interna

Consenso PoA

Produção de blocos

Persistência append-only

Replicação

Verificação independente

Dois motores, uma fonte da verdade

Core — imutabilidade e prova

SIEM — leitura enriquecida e segurança

O que a API SIEM faz com cada evento

Ingestão (hook do core)

Normalização ECS

IP real do usuário

Enriquecimento (GeoIP + threat)

Indexação por tenant

Detecção (scheduled queries)

Alertas & notificação

Quatro endpoints de leitura

Princípios de design

Prova

Imutabilidade