Tema: logging
-
Logs de auditoria: o que registrar, como mantê-los íntegros e quem pode lê-los
Um log de auditoria responde a quem fez o quê, em qual objeto, quando e com que resultado. É gravado pela aplicação para cada ação relevante para a segurança, mantido separado dos logs de depuração, protegido contra alterações ao ser enviado rapidamente para armazenamento append-only ou write-once, e lido apenas mediante acesso restrito e registrado.
-
Política do sudo em arquivos drop-in em /etc/sudoers.d, verificados com visudo -c
Adicionar uma regra restrita como arquivo próprio em /etc/sudoers.d, validado com o visudo antes de entrar em vigor, mantém a política do sudo auditável e evita que um erro de sintaxe bloqueie o acesso de todos. Esta metodologia também aborda o risco de regras NOPASSWD amplas e onde o sudo registra suas decisões.
-
Logging em scripts de administração: logger e systemd-cat no Linux, Write-EventLog/New-WinEvent e Start-Transcript no Windows
Cada plataforma oferece um meio de enviar a saída de um script de administração para um local onde uma pessoa ou outra ferramenta a encontre depois, diferente de escrever em stdout: logger(1) ou systemd-cat no log do sistema no Linux; o Event Log do Windows via Write-EventLog (apenas no Windows PowerShell 5.1) ou New-WinEvent; e Start-Transcript para uma captura bruta da sessão. Nenhum deles deve jamais receber um segredo.
-
Amostragem de logs para eventos de alto volume: mantenha todos os erros e amostre as linhas repetitivas
A amostragem descarta de propósito uma fração de eventos de log semelhantes. As formas úteis são um a cada N, rajada seguida de taxa por período, regras por nível que não tocam em avisos e erros, e amostragem no pipeline com base no ID da requisição, para que uma requisição inteira seja mantida ou descartada em conjunto, com a taxa aplicada gravada nos eventos que sobrevivem.
-
journald forwarding and remote collection: ForwardToSyslog, systemd-journal-upload/-remote, and rate limits
journald can hand its entries to a local syslog daemon with ForwardToSyslog=, or ship them directly over HTTPS with systemd-journal-upload to a systemd-journal-remote listener that writes its own journal files. Both paths are subject to journald's own per-service rate limiting, which drops excess messages once a burst threshold is crossed and records only a count of what it dropped.
-
Sequências de escape de terminal em saídas não confiáveis: por que bytes brutos não devem chegar a um terminal ou a um visualizador de logs
O texto exibido num terminal pode conter sequências de controle que movem o cursor, ocultam linhas, alteram o título da janela ou, em alguns terminais, criam links clicáveis. Saídas não confiáveis de ferramentas, logs ou arquivos devem ser neutralizadas antes da exibição, tanto para operadores humanos quanto para agentes que leem capturas de terminal.
-
Windows Event Forwarding: assinatura iniciada pela origem, wecutil e o grupo EventLog Readers
Em uma assinatura WEF iniciada pela origem, cada computador de origem obtém sua configuração de um coletor via Group Policy e envia a ele os eventos correspondentes; o wecutil gerencia a assinatura no coletor, e o encaminhamento do log Security exige adicionar a conta NETWORK SERVICE ao grupo EventLog Readers em cada origem.
-
Mitigação de força bruta com fail2ban: jails, backends, status e como desbanir o próprio endereço
O fail2ban monitora logs em busca de falhas repetidas de autenticação e bane a origem com uma ação de firewall; a configuração deve ficar em sobrescritas no jail.local, e não no jail.conf do pacote, e é o ignoreip que impede que um endereço de administração acabe banindo a si mesmo.
-
Onde o Solaris guarda seus logs e como usar fmadm/fmdump para falhas de hardware e software
As mensagens gerais do sistema se acumulam em /var/adm/messages (o que o dmesg exibe), cada instância SMF registra a saída do seu método de início em /var/svc/log/, e a Fault Management Architecture (fmadm, fmdump) diagnostica separadamente falhas de hardware e algumas de software, gerando um registro correlacionado com UUID.
-
Incidente do LiteLLM de outubro de 2026: exposição confirmada de token e cuidados com logs do gateway
A análise posterior do LiteLLM substituiu a hipótese inicial de roubo de logs por evidências de exposição de token por uma API da Agent Platform. O incidente ainda ilustra por que credenciais de agentes, corpos de respostas e automação privilegiada precisam de limites de acesso separados.
-
Encaminhar syslog com rsyslog via TCP usando uma fila assistida por disco
Um arquivo drop-in em /etc/rsyslog.d/ pode encaminhar todas as mensagens a um coletor central via TCP, enquanto uma fila de ação assistida por disco armazena as mensagens localmente, de modo que uma queda do coletor ou da rede não faça perder logs. O comando rsyslogd -N1 valida a sintaxe antes de a alteração ser aplicada.
-
Onde os sistemas operacionais guardam seus logs e como consultar cada um
Um agente que diagnostica um serviço precisa saber qual subsistema guarda o log antes de poder lê-lo. Esta referência lista o armazenamento de logs e o comando de consulta no Linux (journald/rsyslog), no unified log do macOS, no Event Log do Windows, no error report do AIX e nos arquivos de syslog do FreeBSD.
-
Logs de acesso a dados pessoais: registrar quem leu qual registro
Um log de acesso a dados pessoais registra leituras, e não apenas gravações: ator, titular, objeto, motivo e momento, emitidos no caminho de leitura da aplicação e conciliados com o log de instruções do banco de dados para os caminhos que o contornam. Ele deve responder a perguntas centradas no titular, como quem consultou o registro de determinada pessoa no último ano.
-
Minimizar dados pessoais em evidências
Guarde o menor registro de evidência necessário para reproduzir uma decisão, excluindo dados de identidade e de conteúdo que não tenham relação com ela.
-
Minimização de dados como disciplina de schema e de logging
Guarde apenas os dados pessoais de que uma funcionalidade precisa, na menor precisão que a atende, e mantenha identificadores fora dos logs por meio de allowlists de campos; cada coluna, campo de log e armazenamento derivado que contenha dados pessoais é uma decisão de projeto com finalidade, responsável e prazo de validade, não uma escolha padrão.
-
Retenção de logs e orçamento de disco em um host: journald, logrotate e dimensionamento do log de eventos do Windows
O SystemMaxUse do journald limita o espaço em disco ocupado pelo próprio journal, o maxage e a contagem de rotate do logrotate limitam os arquivos rotacionados em outros locais, e o wevtutil sl define o tamanho máximo de um log de eventos do Windows. As três são configurações de orçamento de disco escolhidas pelo operador ou por um agente; por quanto tempo os registros devem ser mantidos por razões legais ou organizacionais é uma decisão de política que este artigo não toma.
-
Consultar o journal do systemd com journalctl: unidade, boot, prioridade, intervalo de tempo e saída JSON
O journalctl filtra o journal do systemd por unidade, boot, prioridade e intervalo de tempo e gera saída legível por máquina, mas só se o journal estiver configurado para persistir entre reinicializações. Esta metodologia cobre consultas precisas, armazenamento persistente e os limites de tamanho em journald.conf.
-
Oculte segredos antes de gravar logs
Grave nos logs um registro de diagnóstico restrito a uma allowlist, em vez das requisições brutas de ferramentas, e verifique a ocultação em cada destino de saída.
-
JSON Lines: um valor por linha para logs, datasets e respostas em streaming
JSON Lines (também chamado de NDJSON) coloca um valor JSON completo por linha, em UTF-8 sem BOM e com terminador de linha; os arquivos podem receber novos registros, ser divididos, filtrados com grep e comprimidos, e um stream truncado perde apenas a última linha. As sequências de texto JSON da RFC 7464 adicionam um byte separador de registro para recuperação. Use um dos dois no lugar de um único array JSON grande sempre que os registros forem produzidos ou consumidos um a um.
-
O framework de auditoria do Linux: escrever regras do auditd, monitorar arquivos e consultar os resultados
As regras do auditd ficam em /etc/audit/rules.d e são mescladas com augenrules --load; as regras de chamadas de sistema e de monitoramento alimentam o ausearch e o aureport, e definir a flag enabled como 2 torna a configuração em execução imutável até a próxima reinicialização.
Legível por máquina: JSON