# Os backups de evidências de auditoria devem conter credenciais? Um arquivo de incidente deve ajudar você a responder quem fez o quê, quando, por qual caminho aprovado e se alguém alterou o registro depois. Ele não deve entregar à pessoa que o abre um token de API funcional, uma chave privada SSH ou a capacidade de criar qualquer um dos dois. As equipes erram nisso com frequência porque o software de backup faz tudo parecer igual. Um dump de banco de dados, uma exportação de cofre e um diário de auditoria podem ser arquivos criptografados em repouso. Mas suas funções de segurança são diferentes. Um backup do cofre restaura autoridade. Um backup de evidências preserva a responsabilidade. Coloque os dois no mesmo arquivo e ele herdará a propriedade mais perigosa do cofre. Essa distinção importa ainda mais com agentes autônomos de programação. Em uma execução curta, um agente pode realizar muitas ações externas: alterações em repositórios, chamadas de implantação, atualizações de tickets, administração da nuvem e comandos remotos. Depois de um incidente, as pessoas precisam de um registro durável dessas ações. Elas não precisam de um pacote portátil com as credenciais que as tornaram possíveis. ## Um backup de evidências não pode restaurar autoridade Um arquivo sem credenciais é um pacote de evidências que não consegue se autenticar como usuário, serviço ou máquina depois de restaurado. Seu conteúdo pode ser confidencial, mas nada nele pode, de forma independente, causar uma ação externa. Isso significa que o pacote pode conter um registro como este: ```text 2026-07-22T02:14:09Z session=ses_8f0d... process_authority=Developer ID Application: Example Engineering LLC channel=http method=POST host=api.internal.example path=/deployments credential_ref=prod-deploy-token authorization=approved result=201 Created entry_hash=2ebc6f... previous_hash=78dd91... ``` Ele não deve conter o token bearer representado por `credential_ref`. Também não deve conter uma chave privada SSH, um cookie de sessão, um token de atualização OAuth, um código de recuperação, um banco de dados do cofre descriptografado ou uma senha de exportação armazenada ao lado do arquivo. Se algum desses artefatos aparecer, você já não tem um backup de evidências puro. Às vezes alguém argumenta que uma cópia do cofre é necessária para uma reconstrução completa. Ela só é necessária quando o objetivo é recuperar a autoridade em caso de desastre. Essa é outra operação, com outro modelo de ameaças. Tratá-la como evidência comum de incidente cria um arquivo que precisa ser protegido como um acesso de produção, muitas vezes por mais tempo do que a credencial original deveria permanecer válida. Use duas classificações explícitas no inventário de backups: - **Material de recuperação de autoridade** pode restaurar a capacidade de agir. Ele pertence a procedimentos de recuperação do cofre com controle rigoroso. - **Material de preservação de evidências** pode explicar e verificar ações concluídas. Ele pertence a um fluxo de arquivamento criado para retenção e análise. Não enfraqueça essa separação com rótulos como «exportação sanitizada do cofre». Uma exportação do cofre que inclua blobs de segredos criptografados, chaves de dados protegidas ou os meios para desembalá-las ainda é material do cofre. Um revisor talvez não consiga usá-la hoje, mas você preservou outro alvo que pode se tornar utilizável depois de um comprometimento separado. O teste prático é simples: restaure o arquivo em uma máquina limpa, sem acesso ao sistema de credenciais. Se um usuário puder transformar qualquer artefato desse arquivo em uma solicitação autenticada ativa, corrija o desenho. ## Criptografia e integridade das evidências respondem a perguntas diferentes A criptografia responde a «quem pode ler este arquivo?». As evidências de integridade respondem a «este registro foi alterado, reordenado ou interrompido?». Você precisa das duas respostas, e uma não substitui a outra. Um arquivo ZIP protegido por senha pode manter a linha do tempo de um incidente em sigilo, mas oferecer poucas evidências relevantes de que seu conteúdo permaneceu íntegro. Um invasor que consiga descriptografá-lo, editá-lo e criptografá-lo novamente pode deixar um arquivo organizado, sem uma forma confiável de distinguir o original da versão reescrita. Uma cadeia de hashes segue outro caminho. Cada evento inclui o resumo do evento anterior e o resumo do seu próprio conteúdo canônico. Altere uma entrada antiga e os hashes posteriores deixarão de corresponder. Remova uma entrada intermediária e a seguinte deixará de apontar para o predecessor esperado. O arquivo pode então provar que a sequência exportada é internamente consistente ou mostrar exatamente onde a consistência foi interrompida. Isso não torna a cadeia de hashes mágica. Se um invasor controlar o processo de gravação antes que ele emita um registro, a cadeia não poderá provar que o evento ausente aconteceu. Se o invasor controlar todas as cópias do log e puder substituir a cadeia inteira, uma cadeia sozinha não identificará qual é a verdadeira. Você ainda precisará de checkpoints protegidos, exportação controlada e armazenamento independente. A RFC 5848, «Signed Syslog Messages», é útil porque separa afirmações que as pessoas costumam misturar. Ela descreve autenticação da origem, integridade das mensagens, resistência a replay, ordenação e detecção de mensagens ausentes. Também deixa claro que um registro de log autenticado não prova que o host de origem foi honesto. Esse limite é saudável. Logs são evidências do que um sistema de registro observou e emitiu, não uma visão sobrenatural da realidade. Para um arquivo de incidente, registre a afirmação de integridade que você consegue realmente sustentar: - Os bytes do arquivo correspondem ao manifesto criado no momento da exportação. - A sequência do diário está completa até um checkpoint assinado ou mantido externamente. - Uma entrada alterada depois da captura faz a verificação falhar. - O arquivo não prova que uma ação não registrada jamais ocorreu. Essa última frase evita investigações equivocadas. Um resultado de auditoria limpo sustenta uma afirmação sobre o diário. Ele não absolve um administrador que usou um caminho de credenciais separado, fora do gateway registrado. ## Mantenha diários e recuperação do cofre em domínios de proteção separados Arquivos separados são um começo. Domínios de proteção separados são o requisito real. Grupos de acesso, procedimentos de recuperação, prazos de retenção e regras de exclusão diferentes impedem que um backup conveniente se transforme em um caminho lateral para a produção. Uma organização sensata tem três armazenamentos: 1. O cofre ativo contém as credenciais e o material necessário para usá-las. Seu processo de recuperação é raro, altamente autorizado e registrado. 2. O diário ativo contém registros recentes de atividade e o estado de integridade. Os operadores precisam dele para investigações e análises contínuas. 3. O arquivo de evidências contém segmentos exportados do diário, manifestos, instruções de verificação e checkpoints retidos. Investigadores podem acessá-lo por outro caminho de aprovação, sem receber autoridade sobre credenciais ativas. Não use a mesma senha de criptografia para a cópia de recuperação do cofre e para a cópia de evidências. Não coloque as duas cópias no mesmo bucket de nuvem porque «o bucket já tem criptografia». Não coloque seus contatos de recuperação no mesmo grupo pequeno por padrão. Esses atalhos eliminam a separação quando uma única conta de administrador, função de backup ou integração de armazenamento é comprometida. A retenção também deve ser diferente. As credenciais devem ser rotacionadas, expirar ou ser revogadas quando sua finalidade operacional terminar. As evidências talvez precisem sobreviver por muito mais tempo porque o incidente pode ser descoberto depois, um cliente pode pedir uma explicação ou uma análise interna pode durar meses. Quando um arquivo antigo de evidências contém um segredo antigo, essa retenção mais longa prolonga silenciosamente a vida útil do segredo. Há outra falha que aparece durante o desligamento de funcionários. Um engenheiro que está saindo perde acesso ao cofre atual, mas ainda tem um backup criptografado antigo em uma unidade pessoal de recuperação. Se esse backup contiver credenciais que continuaram válidas, o processo de desligamento tem uma brecha. Se a unidade contiver apenas um arquivo de diário sem credenciais, ainda poderá conter evidências sensíveis, mas não conseguirá reanimar uma identidade de produção. A separação também facilita a destruição. Você pode destruir evidências conforme o cronograma de retenção sem se perguntar se acabou de apagar a única cópia de recuperação utilizável. Pode rotacionar ou retirar credenciais sem executar uma limpeza em massa dos arquivos. Essas tarefas nunca devem estar acopladas. ## Exporte um pacote de verificação, não um relatório bonito Uma linha do tempo em PDF é útil para uma reunião. Ela é uma evidência primária ruim. Perde a estrutura dos registros, normalmente esconde a representação exata do campo que foi submetido ao hash e deixa o revisor sem condições de verificar se a sequência original estava completa. Exporte um pacote com conteúdo verificável por máquina e um índice legível por pessoas. Um layout concreto poderia ser: ```text agent-evidence-2026-07-22/ manifest.json entries.ndjson checkpoints.ndjson activity-summary.txt VERIFYING.md hashes.sha256 ``` `entries.ndjson` contém um objeto de evento canônico por linha. Mantenha os campos estáveis. Se precisar remover o corpo de uma solicitação, informe isso na entrada e preserve um resumo do campo protegido original quando for seguro mantê-lo. Não substitua silenciosamente um valor por `[REDACTED]` e deixe o revisor tentando adivinhar se ele estava ausente, foi suprimido ou foi alterado depois. `checkpoints.ndjson` contém as informações que ancoram os segmentos do diário. Dependendo do seu desenho, isso pode incluir um resumo assinado, um valor raiz armazenado externamente, um recibo de testemunho ou um registro de uma transferência de arquivamento concluída. Uma cadeia sem um checkpoint retido prova apenas que seus links internos concordam. `manifest.json` deve descrever o arquivo como um objeto, em vez de depender do nome de um diretório. Inclua o identificador da exportação, o intervalo de tempo, os identificadores da primeira e da última sequência, a quantidade de registros, a versão do esquema, a versão da canonização, o algoritmo de hash, o identificador da política de redação e o valor final esperado da cadeia. Adicione a versão do exportador e a identidade do host quando essas informações forem relevantes para a investigação. O resumo da atividade é deliberadamente secundário. Ele pode informar que uma execução fez sete chamadas HTTP e duas chamadas SSH, recebeu uma aprovação de sessão e incluiu um comando que falhou. Uma pessoa consegue lê-lo rapidamente. As entradas detalhadas continuam sendo o registro autoritativo. Um manifesto pode ter este formato pequeno: ```json { "archive_id": "evd_2026_07_22_001", "window_start": "2026-07-22T00:00:00Z", "window_end": "2026-07-22T23:59:59Z", "entry_count": 184, "canonicalization": "journal-json-v1", "hash_algorithm": "SHA-256", "first_sequence": 9012, "last_sequence": 9195, "final_entry_hash": "2ebc6f...", "redaction_policy": "evidence-redaction-v3" } ``` Um relatório pode ser gerado novamente a partir desse pacote. O contrário raramente é possível. Mantenha as evidências estruturadas e crie relatórios quando necessário. ## Os backups falham quando as exportações só acontecem depois do incidente A sequência conhecida parece inofensiva até que alguém precise do registro. Um agente faz uma implantação incomum à 1h40. Um responsável percebe o impacto para os clientes mais tarde naquela manhã. A equipe começa a examinar o host, reinicia o aplicativo, rotaciona credenciais e copia os logs que por acaso estão por perto. Ao meio-dia, o diário local já foi sobrescrito, o estado original do processo desapareceu e o arquivo copiado não tem manifesto nem checkpoint. Ninguém necessariamente agiu de forma maliciosa. Mesmo assim, a equipe não consegue estabelecer um histórico defensável. Ela tem um trecho incompleto, não um arquivo de evidências. A NIST SP 800-92 descreve o gerenciamento de logs como algo que vai além da coleta. Ele inclui geração, transmissão, armazenamento, acesso e descarte dos dados de log. Essa visão mais ampla está correta. Se seu plano termina em «o aplicativo grava logs», você planejou a geração, não a preservação. A NIST também alerta que registrar tudo indiscriminadamente pode criar problemas operacionais e até causar perda de dados de log. Registre o suficiente para reconstruir as ações do agente, mas não despeje segredos brutos, corpos completos de resposta e conteúdos arbitrários de arquivos em todos os eventos. Inclua as exportações nas operações normais antes que exista um incidente. A frequência depende do volume de ações e da perda tolerada, mas precisa haver um responsável e um teste. Acione uma exportação depois de uma execução de agente de alto impacto, antes de uma manutenção que possa afetar o estado local e em uma cadência regular para as atividades comuns. Teste o caso problemático. Comece com um arquivo restaurado em outra máquina. Não dê ao testador acesso ao cofre. Peça que responda às perguntas abaixo usando apenas o pacote: - Qual processo de agente iniciou a ação? - Qual decisão de autorização a permitiu ou negou? - Qual destino e operação foram escolhidos? - A sequência do diário foi verificada até o checkpoint arquivado? - Quais entradas foram redigidas e segundo qual regra declarada? Se o teste exigir reabrir o aplicativo original, localizar um colega ausente, lembrar uma senha ou copiar um segredo do sistema ativo, o arquivo está incompleto para uso em incidentes. ## A redação deve preservar o formato da ação As equipes costumam escolher entre dois extremos ruins: despejar todas as solicitações e respostas no diário ou remover tanto conteúdo que o registro já não consegue explicar o evento. A primeira abordagem transforma o diário em outro armazenamento de segredos. A segunda o transforma em um adereço de conformidade. Preserve os fatos necessários para identificar e avaliar a ação. Para uma chamada HTTP, isso normalmente significa a identidade da sessão, a autoridade de assinatura de código ou identidade equivalente do processo, o host de destino, o método, o caminho, a referência da credencial, o resultado da aprovação, o timestamp, o status do resultado e uma representação adequada da solicitação e da resposta. Para SSH, registre o destino, a identidade da conta ou a referência da credencial, o comando ou uma representação cuidadosamente projetada, o resultado da aprovação, o status de saída e a classificação da saída relevante. A expressão «representação adequada» exige bom senso. Uma solicitação `POST /deployments` com um identificador de versão e o nome do ambiente pode ser mantida em texto claro. Um corpo de solicitação que carregue um token de acesso, um registro de cliente ou uma chave privada não deve. Você pode armazenar um marcador fixo de redação e um resumo do campo original se a comparação posterior for importante. O resumo permite que um investigador veja se dois valores protegidos eram idênticos sem revelá-los. Tenha cuidado com identificadores. Um cabeçalho de autorização é obviamente secreto. Um parâmetro de consulta na URL pode ser igualmente perigoso. Uma linha de comando pode conter uma senha, um token de acesso à nuvem ou um caminho para dados de clientes. Corpos de resposta frequentemente contêm URLs temporárias de download, dados pessoais ou configurações de serviços. As ferramentas de log não conhecem bem o suficiente a semântica do seu negócio para tomar todas as decisões de redação por você. Escreva a regra no arquivo. Por exemplo: ```text redaction_policy=evidence-redaction-v3 request_body=retained only for allowlisted JSON fields authorization_header=omitted query_parameters=names retained, values digested response_body=classified and omitted unless allowlisted ssh_command=stored after secret argument filtering ``` Essa declaração permite que um revisor entenda por que certas informações estão ausentes. Ela também dá aos engenheiros algo concreto para testar quando uma API mudar. Não redija os resultados de autorização, as identidades de destino ou os detalhes de falhas apenas porque são desconfortáveis. Uma solicitação negada, uma tentativa de autenticação malsucedida e um host inesperado costumam ser as partes que explicam o incidente. ## Uma cadeia íntegra ainda precisa de retenção independente A cadeia de hashes impede alterações silenciosas dentro de uma sequência preservada. Ela não impede que alguém com controle do sistema de origem exclua toda a sequência e comece outra. Um plano sério de arquivamento dá à cadeia um ponto de referência externo. O método mais simples é exportar checkpoints periodicamente. Em um intervalo definido, grave o resumo final do diário, o número da sequência e o timestamp em um arquivo controlado separadamente. Mantenha várias cópias com autoridade de gravação separada. Um invasor que altere o diário local terá de alterar também todos os checkpoints retidos, sem deixar uma discrepância. Você pode fortalecer isso com checkpoints assinados, um processo confiável de timestamp ou um desenho de armazenamento somente para anexação. A escolha correta depende do seu ambiente, mas não adote uma infraestrutura elaborada se não conseguir executar testes de restauração e verificação. Um checkpoint modesto e repetido, que alguém realmente confere, é melhor que um desenho impressionante que ninguém testou. Mantenha o processo de verificação capaz de funcionar offline. É aqui que o desenho de auditoria do Sallyport é útil: seu log criptografado, encadeado por hash e somente para gravação pode ser verificado sobre o texto cifrado com `sp audit verify`, sem uma chave do cofre. Um verificador sem credenciais evita a situação absurda em que a pessoa que verifica se um agente abusou de um segredo precisa primeiro obter acesso a esse segredo. Seu procedimento de evidências deve preservar o próprio verificador ou uma forma documentada de obter a versão exata usada para o formato do arquivo. Registre no manifesto um resumo criptográfico do binário do verificador ou da revisão do código-fonte. Um revisor futuro não precisa de um laptop antigo, mas precisa de informações suficientes para não verificar silenciosamente dados antigos com regras alteradas. Um resultado esperado de verificação deve ser inequívoco: ```text $ sp audit verify evidence/journal.enc verified: 184 entries chain: intact range: sequence 9012 through 9195 checkpoint: matched ``` Quando a verificação falhar, preserve a saída da falha e pare de tratar o arquivo como uma sequência íntegra. A falha não prova automaticamente uma ação maliciosa. Ela pode revelar danos na transferência, um exportador defeituoso, incompatibilidade de formato ou alteração deliberada. O ponto é que o arquivo tornou a divergência visível, em vez de aceitar silenciosamente uma história revisada. ## O acesso às evidências deve ser amplo o bastante para investigar e restrito o bastante para proteger as pessoas É mais seguro compartilhar evidências do que credenciais, mas elas não são públicas por padrão. Registros de auditoria podem revelar nomes de repositórios, topologia interna de serviços, ações de funcionários, identificadores de clientes e erros operacionais. Remova a autoridade do arquivo e controle o acesso às evidências de acordo com a sensibilidade do que restar. Dê aos investigadores acesso de leitura ao pacote e ao verificador, não acesso de gravação ao local autoritativo do arquivo. Dê aos operadores do sistema uma função de exportação documentada, mas torne cada exportação visível no mesmo rastro de auditoria sempre que possível. Forneça a advogados externos, clientes ou avaliadores um pacote derivado e redigido quando eles não precisarem dos detalhes internos brutos. Evite um único grupo de «arquivos de segurança» que possa ler material de recuperação do cofre, alterar configurações de retenção e baixar evidências. Esse grupo acumulará acesso porque isso facilita as emergências. Também fará com que uma conta comprometida possa apagar tanto sua capacidade de recuperação quanto sua capacidade de explicar o que aconteceu. Defina um registro de custódia do arquivo. Ele não precisa de teatralidade de tribunal. Precisa de fatos básicos: ID do arquivo, criador, horário da exportação, intervalo de origem, classe do local de armazenamento, concessões de acesso, eventos de transferência, resultados de verificação e aprovação da destruição. Se você entregar um pacote a um investigador por um sistema de compartilhamento de arquivos, registre o hash do pacote antes e depois da transferência. O benefício aparece quando o incidente fica complicado. Um engenheiro pode verificar se um agente chamou um endpoint de produção sem receber o token de produção. Um revisor de segurança pode verificar a cadeia sem acesso por Touch ID ao cofre. Um gerente pode receber um relato legível dos eventos sem receber os corpos brutos das solicitações. Cada pessoa obtém a menor quantidade de informação e autoridade necessária para sua função. ## Torne o arquivo entediante antes de precisar dele O melhor backup de evidências é aquele que sua equipe consegue criar e verificar enquanto nada está pegando fogo. Ele tem um layout fixo, uma regra explícita de redação, um checkpoint independente e um teste de restauração que não depende do cofre ativo. Faça um exercício com uma cópia deliberadamente danificada. Altere um byte de uma entrada, remova um registro intermediário e altere a quantidade no manifesto. O verificador deve falhar em cada caso de uma forma que um responsável cansado consiga entender. Depois, execute a cópia íntegra pelo mesmo processo e confirme que o pacote responde quem autorizou a ação, o que aconteceu e se a sequência permaneceu intacta. Mantenha a recuperação de credenciais em outro lugar. Quando um incidente obrigar você a preservar o histórico, o arquivo deve facilitar a investigação sem criar silenciosamente mais um lugar de onde a produção possa ser acessada.