Um log é uma frase, e frases são feitas de vocabulário. No Zscaler Internet Access (), esse vocabulário é literal: um feed de log é um template de campos que você compõe - %s{login}, %s{csip}, %s{action} - e o feed emite exatamente a frase que você projetou, registro após registro, transmitida para onde quer que o seu SIEM more. Este artigo é sobre o vocabulário em si: quais campos carregam quais respostas, e as três sutilezas documentadas que derrubam projetistas de feed de primeira viagem. Fundamentado na documentação de formatos de feed NSS da Zscaler, verificada em 2026-07-21.

Dois logs, dois tipos de pergunta

O Web Log fala em transações: quem (login, departamento, localidade), buscou o quê (URL e sua categoria), por qual desfecho de política (ação, a regra que disparou), carregando quais vereditos de risco - o registro do proxy fazendo seu trabalho. O Firewall Log fala em sessões: endereços e portas de origem e destino (csip, csport e seus equivalentes de destino), protocolo, o serviço de rede e a aplicação identificados, a ação, contagens de bytes em cada direção, e o contexto de túnel pelo qual o fluxo chegou. A divisão de trabalho é ouro diagnóstico: "o usuário alcançou o site" é pergunta de web log; "a sessão sequer saiu, e quanto se moveu" é pergunta de firewall log - e a investigação que começa no log errado gasta sua primeira hora descobrindo isso.

As três sutilezas que a documentação sinaliza

Primeira, os campos de ofuscação: campos selecionados existem num gêmeo preservador de privacidade com prefixo o - a contraparte ofuscada de um campo de IP de origem emite uma string aleatória em vez do endereço - então um feed pode nascer pseudônimo por construção, para consumidores que precisam de padrões sem identidades. Segunda, o hex-encoding de URLs: qualquer byte de URL igual ou abaixo de 0x20, ou igual ou acima de 0x7F, é codificado como %HH antes de o log partir, porque uma URL contendo uma quebra de linha crua é um ataque de parser contra o seu , e o serviço a desarma na origem. Terceira - a que gera surpresas de planejamento de capacidade - na assinatura Standard do Firewall, sessões permitidas são logadas em agregado enquanto sessões bloqueadas logam individualmente e em detalhe: menos registros para o grosso permitido, fidelidade total onde a política disse não. O volume de um feed de firewall, portanto, acompanha a sua taxa de bloqueio tanto quanto o seu tráfego, e uma observação de "nossos logs de firewall são minúsculos" pode significar exatamente que a política raramente bloqueia.

Projetando um feed como um operador

O ofício é escolher campos para as perguntas que você de fato fará às 2 da manhã. O esqueleto de que quase toda investigação precisa: tempo, usuário, identidade do dispositivo, IP de origem do cliente, destino, a ação, e o rótulo da regra que a produziu - porque "bloqueado" sem o nome da regra manda você de volta ao console para reproduzir a ordem da política à mão. Contagens de bytes nas duas direções transformam o firewall log num instrumento de exfiltração. E o template de campos é por feed, o que significa que o projeto certo costuma ser vários feeds: um feed enxuto de alertas em tempo real, um feed de investigação em fidelidade total, um feed ofuscado de analytics - o mesmo Nanolog, três frases, cada uma escrita para o seu leitor. A sintaxe de entregar essas frases - servidores, feeds, limites e semântica de falha - é o assunto inteiro do próximo artigo.