Especifica onde e como a trilha de auditoria é avaliada no backend, frontend, jobs, caches e integrações. Esta referência define o limite de adoção, comportamento em caso de falha e evidências observáveis, deixando os limites específicos do ambiente configuráveis.
Status do pacote: contexto de referência pronto para revisão humana. O contrato e os cenários de teste estão completos, mas não há garantia de que uma implementação adotante os tenha aprovado.
Decisão
Para a trilha de auditoria, adote uma decisão de política centralizada no lado do servidor usando contexto autenticado de sujeito e recurso. Use um limite próprio, modelo de estado explícito e interfaces versionadas; mantenha as decisões de política separadas dos adaptadores e efeitos colaterais. Este pacote é um contrato de referência: a equipe adotante deve escolher limites numéricos, provedores, jurisdições e responsáveis operacionais a partir das evidências em seu próprio ambiente.
Escopo
- Os atores, entradas, saídas, estados, versões de política ou esquema e resultados visíveis externamente descritos por este bloco de arquitetura da trilha de auditoria.
- Interfaces primárias e alternativas, trabalho em segundo plano, caches, integrações, caminhos de suporte e evidências que podem exercer o mesmo limite.
- Configuração específica de adoção, implantação, recuperação e responsabilidades de verificação necessárias para aplicar a referência com segurança.
Fora deste bloco
- Escolher um fornecedor universal, framework, jurisdição, limite numérico, período de retenção ou objetivo de nível de serviço para todos os adotantes.
- Afirmar que os cenários empacotados foram executados contra uma implementação a jusante ou que esta referência concede certificação legal, de segurança ou acessibilidade.
Contrato
- Negar por padrão quando sujeito, ação, propriedade do recurso, locatário ou versão da política estiver ausente ou contraditório.
- Aplicar o mesmo escopo de recurso a registros primários, índices, caches, arquivos, jobs, exportações, agregados e ferramentas de suporte.
- Não tratar um controle oculto de UI, reivindicação do cliente, nome de rota ou identificador difícil de adivinhar como evidência de autorização.
- Registrar versão da política, sujeito, recurso, ação, resultado e motivo seguro para decisões privilegiadas e negadas.
- Documentar propriedade dos componentes e direção permitida de dependência, incluindo quais dados podem cruzar cada limite.
- Fazer com que os caminhos síncronos, assíncronos e em lote implementem as mesmas invariantes de autoridade e estado.
- Acrescentar um registro à prova de adulteração para cada ação material com ator, autoridade delegada, alvo, significado antes e depois, versão da política, tempo, causa e identidade de correlação.
- Autorizar acesso à auditoria separadamente, redigir cargas úteis sem quebrar o significado do evento e testar retenção, exportação, descompasso de relógio, falha de ingestão e reconstrução de rastreamento do investigador.
Orientações de implementação
- Comece com o estado do domínio e contrato de interface, depois conecte adaptadores, armazenamento, filas e código específico do provedor.
- Modele entradas, saídas, atores, estados, invariantes, efeitos colaterais e evidências da trilha de auditoria antes de selecionar detalhes do framework ou fornecedor.
- Armazene o contrato ou versão da política aplicável da trilha de auditoria com o estado material para que migrações, reprodução e decisões de suporte permaneçam atribuíveis.
- Introduza o caminho por trás da implantação controlada, compare resultados esperados e observados e mantenha uma rota de recuperação testada até que as evidências de adoção estejam completas.
Tratamento de falhas e salvaguardas
- Falha no serviço de política ou contexto nega a operação protegida e emite um sinal de investigação limitado e não sensível.
- Estado inválido ou contraditório da trilha de auditoria é rejeitado ou colocado em quarentena; a implementação nunca supõe um valor que amplie autoridade ou duplique um efeito.
- Retentativas são limitadas e usam identidade durável; após esgotamento, o trabalho alcança um estado terminal inspecionável com um responsável contabilizável.
Verificação e operações
- Exercite o contrato através de cada adaptador e prove que uma dependência falha não pode contornar o limite autoritativo.
- Monitore sucesso, negação, falha de validação, falha de dependência, esgotamento de retentativas e recuperação da trilha de auditoria por versão do contrato sem dimensões sensíveis da carga útil.
- Reexecute fixtures positivos e negativos pareados após mudanças em política, esquema, dependência, migração ou limite e preserve as evidências resultantes.
Suposições de adoção
- Nomes e valores no exemplo são um fixture concreto, não padrões universais; os adotantes os substituem por meio de evidências documentadas e propriedade.
- O sistema adotante pode fornecer identidade autenticada, versões duráveis de operação ou registro, telemetria limitada e um caminho controlado para mudança.
Os exemplos com aparência executável neste pacote são fixtures e contratos de aceitação. Execute o validador da coleção para verificar estrutura e metadados, depois traduza e execute os cenários no repositório alvo antes de registrar evidências de implementação.