Arquitetura projetada para prova, não apenas armazenamento.
Cada componente existe por um motivo: tornar eventos críticos verificáveis, resistentes à adulteração e defensáveis.
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.
É 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
- 01
Cliente
Papel: Origem do eventoSua aplicação envia eventos críticos por uma API segura.
GaranteOrigem identificada e autenticada por chave e endereço de rede.
Sem eleSem autenticação na origem, qualquer agente externo poderia injetar eventos forjados.
- 02
API de Ingestão
Papel: Porta de entradaA API recebe eventos, valida a estrutura, autentica a requisição e prepara o payload para processamento no ledger.
GaranteCada evento entra com carimbo de tempo do servidor e identidade do cliente.
Sem eleSem timestamp confiável do servidor, a ordem cronológica seria controlada pelo cliente — e manipulável.
- 03
Validação + Enriquecimento
Papel: Porteiro do ledgerEventos são normalizados, enriquecidos com metadados e verificados antes de entrar no pipeline do ledger.
GaranteEventos malformados são rejeitados antes de tocar o ledger; o hash é calculado a partir de uma representação canônica única.
Sem eleSem canonização, dois clientes serializariam o mesmo evento de formas diferentes e gerariam hashes distintos.
- 04
Idempotência
Papel: Defesa contra duplicaçãoRetries 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.
GaranteA mesma operação produz um único registro, independentemente de retries de rede ou de cliente.
Sem eleSem idempotência, instabilidade de rede vira evento duplicado — e duplicação corrompe a história.
- 05
Mempool
Papel: Buffer ordenadoEventos válidos entram em uma fila temporária onde são ordenados e preparados para consenso.
GarantePicos de carga não derrubam o sistema; a ordem de chegada é preservada.
Sem eleSem mempool, ou você processa cada evento sincronamente (lento), ou descarta sob carga (perde história).
- 06
Gossip / Propagação interna
Papel: Distribuição entre nósOs nós trocam eventos pendentes internamente para que a rede convirja para o mesmo estado do ledger.
GaranteNenhum nó isolado controla o que está sendo proposto à rede.
Sem eleSem gossip, um nó comprometido poderia esconder eventos dos outros antes do consenso.
- 07
Consenso PoA
Papel: Acordo coletivoImmutableLog utiliza um modelo permissionado de Proof of Authority entre nós confiáveis. Blocos são acordados, não presumidos.
GaranteA história é uma decisão coletiva auditável, não a opinião de um único processo.
Sem eleSem consenso, um administrador com acesso a um nó reescreveria o histórico sozinho.
- 08
Produção de blocos
Papel: Encadeamento criptográficoEventos são agrupados em blocos. Cada bloco referencia o anterior, criando uma cadeia criptográfica de histórico.
GaranteAlterar qualquer evento passado quebra o hash do bloco e de todos os blocos posteriores — a adulteração se torna matematicamente detectável.
Sem eleSem encadeamento por hash, eventos antigos poderiam ser editados sem deixar rastro verificável.
- 09
Persistência append-only
Papel: Armazenamento append-onlyDepois de gravados, os registros não são atualizados nem apagados. A imutabilidade é garantida pela arquitetura, não por política.
GaranteEventos não podem ser editados nem apagados, nem por administradores de banco.
Sem eleSem append-only, qualquer DBA com permissão consegue reescrever o passado e o sistema vira só mais um log.
- 10
Replicação
Papel: Redundância da históriaO ledger é replicado entre nós para preservar disponibilidade e impedir manipulação unilateral do histórico.
GaranteFalha de hardware ou desastre em um nó não apaga a história.
Sem eleSem replicação, perder o disco de um nó é perder evidência.
- 11
Verificação independente
Papel: Estado final verificávelQualquer parte autorizada pode verificar que um evento existe e que a cadeia permanece íntegra sem confiar no operador.
GaranteQualquer auditor consultando qualquer nó obtém a mesma resposta — e pode verificar a prova localmente, sem depender do operador.
Sem eleSem consistência, dois auditores teriam respostas diferentes para a mesma pergunta — e a evidência perde valor probatório.
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
Core — imutabilidade e prova
Validação, selagem, ordenação, consenso e persistência append-only. A prova de inclusão (Merkle) mora aqui.
SIEM — leitura enriquecida e segurança
Normalização ECS, GeoIP, threat intel e alertas por regra. Somente leitura e isolado por tenant.
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.
GaranteA 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.
GaranteTodo 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.
GaranteGeo, 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.
GaranteDegrada 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.
GaranteToda 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.
GaranteUma 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.
GaranteDo 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.
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
Não é blockchain pública. Não é observabilidade. Não é analytics.
ImmutableLog usa primitivas criptográficas de nível blockchain, mas não depende de redes públicas, tokens, mineração ou validadores externos.
É um ledger privado e permissionado projetado para auditabilidade enterprise.
- ✕Sem token
- ✕Sem mineração
- ✕Sem rede pública
- ✕Sem validador externo
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.