# Registros locais apoiam evidências SOC 2 CC7

Registros locais de execução com evidência de adulteração podem apoiar evidências SOC 2 CC7, mas não sustentam CC7.1 ou CC7.2 sozinhos. Eles mostram qual processo de agente local iniciou uma sessão, quais chamadas com credenciais ele tentou, como terminaram e se o histórico armazenado mudou. Não mostram que todo sistema no escopo recebeu monitoramento de vulnerabilidades nem que alguém investigou anomalias no prazo definido.

Esse limite importa. Já vi equipes entregarem ao auditor uma exportação de logs perfeitamente assinada e chamá-la de controle de monitoramento. A exportação provava que eventos existiam. Não provava cobertura, lógica de detecção, revisão, encaminhamento ou correção. O registro local é útil como uma fonte de evidência dentro de um sistema de controles. Quando vira sinônimo do controle inteiro, as lacunas aparecem na amostragem.

O teste prático é simples: ligue cada afirmação a um campo, procedimento, responsável e evidência corroborante. Se faltar uma dessas partes, documente a limitação antes que o auditor o faça.

## CC7.1 e CC7.2 fazem perguntas diferentes

CC7.1 pergunta se a entidade usa procedimentos de detecção e monitoramento para identificar mudanças de configuração que introduzem novas vulnerabilidades e exposição a vulnerabilidades recém-descobertas. CC7.2 pergunta se ela monitora componentes e sua operação em busca de anomalias ligadas a atos maliciosos, desastres naturais ou erros, e analisa essas anomalias para decidir se são eventos de segurança. O registro de uma ação API ou SSH de agente contribui para ambos, mas de formas diferentes.

Para CC7.1, um registro de execução costuma ser evidência de mudança. Ele pode mostrar que um agente alterou uma regra de firewall, implantou um pacote, mudou uma configuração de identidade ou executou um comando em um host. A evidência ajuda a ligar um desvio de configuração ou uma nova exposição ao processo que a causou. O registro não detecta uma vulnerabilidade recém-publicada sem um scanner, feed de avisos, inventário ou procedimento de revisão que compare componentes implantados com a nova informação.

Para CC7.2, o mesmo registro é telemetria operacional. Uma chamada negada, destino inesperado, falhas repetidas de autenticação, comando incomum ou ação fora de uma sessão aprovada podem alimentar a detecção de anomalias. Ainda assim, armazenar um evento não equivale a monitorá-lo. A organização precisa definir como selecionar eventos, reconhecer padrões suspeitos, encaminhá-los a um revisor e registrar a decisão.

Essa distinção evita um erro comum: igualar logging a detecção. Uma fonte de logs registra observações. Um controle de detecção aplica lógica ou julgamento humano a elas. O auditor costuma testar desenho e operação, portanto uma evidência que só prova coleta responde metade da pergunta.

Os Trust Services Criteria da AICPA oferecem pontos de foco, não uma lista universal de ferramentas. Isso permite controles adequados aos riscos da empresa, mas elimina a ideia de um prazo mágico de retenção ou categoria obrigatória de produto. Descrição do sistema, avaliação de risco, redação do controle e procedimento real determinam se os dados locais são relevantes.

Uma declaração estreita e defensável poderia dizer: «A equipe de segurança revisa, em cada dia útil, ações de produção intermediadas por agentes, procurando chamadas negadas ou malsucedidas, novos destinos e comandos SSH privilegiados; o revisor registra a decisão e encaminha eventos suspeitos pelo procedimento de incidentes.» Ela identifica população, sinais, frequência, responsável e acompanhamento. «Mantemos logs com evidência de adulteração» identifica apenas uma propriedade do armazenamento.

## A identidade da sessão descreve o processo, não a pessoa

Um registro de sessão útil identifica o processo do agente com precisão suficiente para distinguir uma execução de outra. Registre ao menos identificador único, início e fim, caminho do executável, identidade de assinatura ou resumo binário, processo pai, identificador do host, conta local, decisão de autorização, quem autorizou e estado de revogação. Preserve como cada campo foi obtido, pois um valor informado pelo agente merece menos confiança que um observado pelo gateway ou sistema operacional.

Não transforme identidade de processo em identidade humana. Uma autoridade de assinatura pode dizer quem assinou o binário. Uma conta local indica o contexto do sistema que o iniciou. Nenhuma prova qual funcionário escreveu o prompt, aprovou cada ação ou pretendia determinado comando. Se o controle exige atribuição humana, una a sessão a registros do provedor de identidade, gestão do dispositivo, aprovações, propriedade de tickets ou atribuição controlada da estação.

A mesma cautela vale para relações entre processos. Um shell pode iniciar o agente, que inicia um auxiliar, que pede uma ação SSH. Registre a cadeia observada, mas defina qual processo é sujeito do controle. Caso contrário, uma equipe agrupa pelo agente principal, outra pelo auxiliar e a população muda no meio da auditoria.

Um objeto compacto torna explícito o contrato de evidência:

```json
{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}
```

As reticências marcam um exemplo abreviado, não um identificador aceitável em produção. A evidência real precisa do valor completo e de uma regra documentada de unicidade. Também precisa de prova de sincronização dos relógios. Se timestamps de endpoint, gateway, identidade e ticket divergirem, o auditor não reconstrói a sequência com confiança, ainda que cada fonte seja internamente coerente.

No Sallyport, o diário Sessions registra execuções de agentes, enquanto a aprovação da primeira chamada mostra primeiro a autoridade de assinatura do processo e vale até ele terminar. É boa evidência local de sessão, mas registros externos continuam necessários quando o controle afirma um funcionário, dispositivo gerenciado, mudança aprovada ou login corporativo.

## O resultado da chamada precisa permitir uma decisão

O registro de uma chamada deve responder o que o processo tentou, onde, qual referência de credencial ou classe de chave o gateway usou, se era necessária aprovação, qual decisão ocorreu, se a execução começou e como terminou. Capture timestamps e duração, canal, destino normalizado, tipo de ação, classes de resultado e erro e um identificador estável de correlação. Guarde detalhes suficientes para investigar sem copiar segredos ou respostas sensíveis para a trilha de auditoria.

O vocabulário precisa ser rigoroso. «Negada» significa que um controle impediu a execução antes da ação externa. «Malsucedida» significa que a execução começou, mas retornou erro, expirou ou perdeu transporte. «Bem-sucedida» significa que a interface remota informou sucesso segundo uma regra documentada. «Desconhecida» cobre a situação em que o cliente perdeu a confirmação depois de enviar a ação. Misturar chamadas negadas e malsucedidas destrói a evidência de que o controle preventivo operou.

O status HTTP raramente conta tudo. Uma resposta `200` pode conter erro de aplicação. `202` pode indicar apenas que o trabalho entrou na fila. Código SSH zero mostra que o shell remoto relatou sucesso, não que o estado pretendido mudou. Defina normalização por tipo de ação e preserve o status bruto ao lado do resultado normalizado.

Um registro prático pode ser assim:

```json
{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}
```

Não registre bearer token, chave privada, cabeçalho completo de autorização ou resposta bruta só para a evidência parecer completa. Um log que vaza segredos cria outra falha de controle. Use referência estável de credencial e registre o método de injeção, mantendo o segredo fora do agente e da evidência exportada.

Para CC7.1, revisores podem correlacionar chamadas capazes de mudar configurações com desvios, implantações e achados de vulnerabilidade. Para CC7.2, podem selecionar ações negadas, malsucedidas, desconhecidas, de destino incomum ou alto risco. O registro só apoia esses procedimentos se a organização enumerar a população completa. Uma captura de cinco eventos prova que cinco eventos existiram, não que todos os relevantes foram avaliados.

## A integridade prova coerência, não a verdade do evento

Uma cadeia de hashes detecta remoção, inserção, reordenação ou alteração depois que os registros entram na cadeia, desde que o verificador parta de formato e âncora confiáveis. Ela não prova que a fonte capturou todas as ações, que cada campo estava correto ao ser escrito ou que um invasor nunca contornou o logger. A distinção é direta: integridade dos registros não é completude da coleta.

Armazenamento cifrado sem reescrita reduz a chance de um leitor ou caminho de análise comprometido alterar o passado. Cifragem protege confidencialidade. Encadeamento protege continuidade verificável. Chaves apoiadas por hardware podem reforçar acesso. Esses mecanismos respondem a perguntas diferentes, então documente-os separadamente em vez de chamar todo o desenho de «imutável».

Um procedimento de integridade precisa de entradas repetíveis e resultados retidos. Com Sallyport, o revisor verifica a cadeia cifrada offline sem chave:

```text
$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid
```

A saída exata deve vir da versão instalada. O formato acima define o que guardar: comando, versão, identificador ou resumo do arquivo, contagem, limites de tempo, resultado, horário e operador. Se o comando real usa outros rótulos, preserve sua saída em vez de reescrevê-la para combinar com o exemplo.

Execute um teste negativo antes de confiar no procedimento. Copie uma exportação fora de produção, altere ou remova um registro com um artefato de teste aprovado pela engenharia e confirme que a verificação falha. Guarde método, falha esperada, saída real, versão e aprovação. Uma verificação correta mostra que um arquivo passou; um teste negativo mostra que o verificador detecta a alteração alegada.

Reconcilie também os limites. Compare a última contagem e âncora de uma exportação com o primeiro estado esperado da próxima. Investigue lacunas, reinícios, reinstalações, saltos de relógio e substituições de hosts. Se administradores locais podem apagar log e âncora, a cadeia talvez valide fielmente apenas o histórico substituto. Envie âncoras, resumos ou recibos assinados a um local controlado separadamente na frequência exigida pelo risco.

NIST Special Publication 800-92 recomenda proteger a integridade de logs arquivados e verificar logs transferidos, geralmente comparando resumos. A orientação continua correta, mas um resumo ou cadeia não substitui o monitoramento de cobertura. Use-o para revelar falhas de transferência e retenção, depois teste se todas as fontes no escopo reportam.

## A retenção começa pelo período e pela investigação

SOC 2 não define um número universal de dias para evidências CC7.1 ou CC7.2. Defina retenção pelo período de auditoria, obrigações legais e contratuais, investigação, atraso de detecção, sensibilidade e tempo para produzir uma amostra. A política deve nomear classes retidas, local, responsável, restrições de acesso, descarte e exceções.

Em um exame Type 2, o auditor testa a operação durante um período. Se a equipe guarda apenas o histórico local recente, pode não apoiar amostras iniciais nem provar continuidade. Mantenha evidência por todo o período, preparação, trabalho de campo e uma margem para acompanhamento. Jurídico ou compliance deve resolver obrigações mais longas em vez de copiar a duração do relatório de outra empresa.

Retenção apenas local tem uma falha previsível. Um notebook é trocado em abril, seu diário desaparece e a amostra de outubro inclui fevereiro. A equipe tem uma cadeia perfeita no aparelho novo e nenhuma evidência da data escolhida. Exporte registros e âncoras para armazenamento da organização em calendário definido e guarde prova de que as exportações rodaram.

Teste recuperação, não só configuração. Escolha uma data antiga, localize a população de sessões, recupere chamadas, verifique integridade e ligue um evento à decisão de revisão. Registre tempo e falhas. Uma captura de configuração mostra desenho; a recuperação de período antigo mostra operação.

Privacidade e segurança continuam valendo. Comandos, destinos, contas e erros podem conter dados pessoais ou detalhes sensíveis. Restrinja acesso, oculte dados das cópias por regra documentada e preserve uma fonte completa somente quando autorizado. A ocultação não deve mudar a ordem nem invalidar a verificação sem manter um original verificável separadamente.

## A frequência de revisão precisa deixar prova

Um controle funciona quando um papel nomeado examina uma população definida na frequência declarada, aplica critérios escritos e registra a decisão. «Os logs são revisados regularmente» não permite amostragem confiável. Revisão em cada dia útil pode servir para produção, aprovação por chamada para poucas chaves poderosas e revisão semanal para destinos de desenvolvimento menos arriscados. A avaliação de risco deve explicar a escolha.

Separe aprovação preventiva de revisão de detecção. A aprovação decide se a ação prossegue. A revisão pergunta se ações permitidas, negadas, malsucedidas e contornadas indicam anomalia. Aprovar uma chamada arriscada não prova que alguém conferiu o resultado, correlacionou chamadas ou reconheceu sessão comprometida.

Defina seletores em linguagem clara antes da ferramenta. Um procedimento pode escolher todos os `result` iguais a `failed` ou `unknown`, aprovações negadas, destinos novos, usos de credenciais de produção, sessões com autoridade desconhecida e falhas de integridade. O revisor classifica cada item como esperado, problema operacional, desvio de política ou possível evento. Eventos suspeitos recebem identificador e horário de encaminhamento.

Guarde evidência de resultado zero. Num dia tranquilo, consulta salva, janela, horário, identidade do revisor e contagem zero provam a execução. Um mês só com tickets positivos gera dúvida sobre os dias sem tickets. Auditores amostram a operação do controle, não apenas casos interessantes.

A evidência de revisão inclui:

- A consulta de população ou critérios de exportação e sua versão.
- Início e fim, fuso horário e número de registros.
- Identidade do revisor, conclusão e explicação de atrasos.
- Cada anomalia selecionada, decisão e justificativa.
- Referências de incidente, mudança ou problema quando houver encaminhamento.

Não deixe o produtor dos eventos ser o único revisor. Uma equipe pequena pode usar revisão compensatória por outra pessoa, inspeção periódica da gestão e exportações controladas separadamente. Descreva a realidade. Uma segregação inventada é pior que uma limitação honesta com controle compensatório sensato.

A frequência também se aplica à saúde do controle. Confirme que hosts esperados produziram dados, exportações terminaram, relógios continuaram sincronizados, verificações passaram, seletores ainda combinam com o esquema e filas foram fechadas. Mudança de esquema pode quebrar silenciosamente uma consulta. Inclua evento de teste conhecido ou limite de volume para notar quando o pipeline fica mudo.

CC7.2 exige análise para decidir se anomalias são eventos de segurança. Fechar um ticket como «falso positivo» sem motivo não demonstra análise. O registro deve dizer o que ocorreu, por que ameaçou ou não os objetivos, qual evidência apoiou a decisão, quem decidiu e se o acompanhamento mudou detector ou procedimento.

## Monte o pacote em torno das afirmações

O auditor costuma pedir primeiro evidência de desenho e depois evidência operacional de datas ou eventos selecionados. Organize os registros para que cada artefato responda a uma afirmação. Não entregue um arquivo bruto esperando que o auditor descubra seu controle.

Use este mapa como índice:

| Pedido do auditor | Evidência local útil | Corroboração habitual |
| --- | --- | --- |
| Mostrar quem ou o que iniciou | ID de sessão, executável, assinatura, host e conta | Login de identidade, inventário do aparelho, atribuição de pessoal |
| Mostrar atividade de mudança | Destino, comando, credencial, horário e resultado | Ticket, histórico do repositório, estado remoto |
| Mostrar monitoramento | População completa, seletores, negações e falhas | Configuração, roteamento, revisões e incidentes |
| Mostrar ausência de alteração | Saída de verificação, versão, resumo, âncoras e teste negativo | Controles de exportação, acesso separado, teste de cobertura |
| Mostrar retenção | Registros mais antigo e recente recuperáveis, histórico de exportação | Política, armazenamento, descarte e exceções |
| Mostrar análise | Planilha de revisão, decisão, motivo, referência de encaminhamento | Procedimento de incidente, resposta e correção |

Para cada controle, mantenha uma definição de uma página com texto, responsável, frequência, populações, procedimento, artefatos, local e exceções. Adicione um dicionário de campos. O auditor não deve adivinhar se `actor` significa funcionário, conta local, processo ou autoridade de assinatura.

Prepare dois caminhos de amostra. O primeiro parte de uma data aleatória e prova que a revisão completa ocorreu no prazo. O segundo parte de uma chamada de alto risco, volta à autorização e segue até resultado remoto, revisão e tickets. A amostra de data testa recorrência; a de evento testa rastreabilidade.

Reconcilie totais em cada transferência. A contagem do diário Sessions deve combinar com a exportação sob os filtros documentados. Contagens de chamadas devem combinar antes e depois do envio. Entradas de revisão devem fechar com itens selecionados, excluídos e pendentes. Explique diferenças legítimas, como testes, exclusões aprovadas, tentativas duplicadas ou registros fora da janela.

Um relatório Type 1 avalia o desenho em um momento. Type 2 também avalia se o controle operou durante o período. Uma captura atual, verificação recente ou procedimento novo pode ajudar no Type 1, mas não recria meses de operação Type 2 ausente. Se o histórico não existe, declare a lacuna e ajuste o cronograma em vez de fabricar aprovações retroativas.

Antes do trabalho de campo, pergunte como o auditor quer receber evidência cifrada ou sensível, quais atributos espera e se escolherá datas, sessões, chamadas ou alertas. A conversa muda a embalagem, não o controle. O controle deve operar de forma consistente antes da amostra.

## Colete cobertura e resposta em outros sistemas

Registros locais cobrem apenas ações que passam pelo caminho local. Não provam que todas as mudanças de produção usam esse caminho. Administradores podem usar console de nuvem, SSH direto, credenciais CI/CD, suporte do fornecedor, contas de emergência, tarefas agendadas ou outra estação. Inventarie os caminhos e coloque-os no controle ou colete seus logs separadamente.

CC7.1 também precisa de:

- Inventário atual de ativos e software ligado ao escopo.
- Padrões de configuração e versões de referência aprovadas.
- Configuração, cobertura, resultados e saúde dos scans.
- Processo para novos avisos e componentes afetados.
- Tickets de correção, aceites de risco, prazos, novos testes e exceções.

Uma chamada que instala a versão X é evidência útil da mudança. Ela não informa que X ficou vulnerável três semanas depois. O sistema de vulnerabilidades, entrada de avisos, inventário e correção precisam completar a história.

CC7.2 precisa de fontes mais amplas. Colete telemetria de endpoint, identidade, rede, plano de controle da nuvem, aplicação, banco e disponibilidade conforme os riscos. Guarde definições de detector, inventários de fontes, testes de roteamento, plantões ou revisores, histórico de alertas, decisões, incidentes e ações posteriores. Desastres e erros podem exigir alarmes e continuidade que um gateway de ações não vê.

Prove completude por reconciliação. Compare aparelhos gerenciados com os que exportam, credenciais de produção com as disponíveis no gateway e mudanças de nuvem com chamadas e automação aprovada. Investigue divergências nos dois sentidos: mudança remota sem chamada pode mostrar desvio; chamada bem-sucedida sem mudança pode indicar normalização ruim ou reversão.

Colete também governança. A avaliação de risco explica por que agentes importam para CC7.1 e CC7.2. Políticas atribuem responsabilidades por logs, vulnerabilidades, monitoramento, revisão, incidente e retenção. Treinamento cobre aprovadores e revisores. Revisões de acesso mostram quem pode ler, exportar, administrar ou apagar evidência e mudar a detecção.

NIST Special Publication 800-92 trata gestão de logs como geração, transmissão, armazenamento, análise e descarte. Esse ciclo testa bem um desenho local demais. Se geração e armazenamento estão cobertos, mas transmissão, análise e descarte não, o desenho continua incompleto mesmo com boa criptografia.

Mantenha um registro explícito de lacunas com sistema descoberto, período ausente, controle afetado, risco, procedimento temporário, responsável e data-alvo. Auditores não esperam que um pequeno log veja a empresa inteira. Esperam que a gestão conheça o escopo e limite suas afirmações às provas.

## Use registros como componente limitado e testável

Registros locais valem quando a declaração coincide com o que observam. Eles fornecem detalhes de sessão e chamada, preservam tentativas negadas que o sistema remoto nunca recebe e tornam alterações posteriores detectáveis. São especialmente úteis para agentes de IA, pois APIs remotas costumam ver uma identidade compartilhada e perder o contexto local.

Ficam fracos quando a equipe exagera a identidade, ignora caminhos alternativos, guarda tudo em endpoints substituíveis ou confunde cadeia válida com monitoramento completo. A solução não é outro adjetivo criptográfico. É uma afirmação menor, população documentada, revisão recorrente, resultados separados e junções com sistemas de referência.

Antes de confiar nos registros, execute um teste de ponta a ponta com evento semeado. Inicie sessão identificável, tente uma ação aprovada e outra negada, confirme os resultados, exporte o período, verifique a cadeia, rode o seletor, registre a decisão e reconcilie o evento remoto. Depois repita a recuperação num período antigo. Cada quebra é uma lacuna real.

Entregue ao auditor o resultado da cadeia, mas também inventário de fontes, seletor, prova de revisão, exceções e corroboração externa. Esse pacote sustenta um controle CC7.1 ou CC7.2 defensável. A cadeia sozinha sustenta apenas a afirmação modesta de que o histórico fornecido mantém a estrutura esperada pelo verificador.