Auditar logs e ciclo de vida de chaves

Evento, tentativa e confirmação

Começa pelo contrato: o que conta como ação, como se identifica uma tentativa e quando se pode apagar a cópia do produtor? Um emissor pode reutilizar a sequência após um reinício. Neste modelo, a identidade é (source, epoch, id); receivedAt descreve uma receção, não cria outra ação. Guarda entregas repetidas para diagnóstico e constrói uma vista de ações únicas separada. Se usares apenas source e sequência, um novo arranque pode apagar logicamente um evento legítimo.

Num protocolo de exemplo, o produtor elimina a cópia após ACK de persistência. Se o ACK sair quando os bytes ainda estão apenas em memória, uma falha nessa janela pode perder a única cópia. Ensaiar esta condição exige uma definição de persistência adequada ao sistema e uma falha controlada. O laboratório desta aula escreve JSONL e chama fsync, mas não corta energia nem demonstra garantias do disco, controlador ou sistema de ficheiros perante essa falha. Usa-o para observar o fluxo, não para concluir durabilidade de produção.

Fixar os bytes e minimizar antes de autenticar

O produtor serializa apenas o evento em JSON com chaves ordenadas, separadores sem espaços, ensure_ascii=False e UTF-8. A sequência exata fica em payloadB64; o HMAC-SHA256 é calculado sobre os bytes descodificados, não sobre o envelope JSONL. O verificador lê inicialmente campos ainda não confiáveis para procurar a chave e produzir diagnósticos. Compara os bytes com compare_digest; aceitar a interpretação como autenticada depende dessa comparação e da política. Trocar 7 por 7.0 ou reordenar bytes pode alterar o resultado mesmo quando a análise numérica parece igual. Uma transformação legítima deve ser documentada e não apresentada como o mesmo objeto autenticado.

O HMAC não cifra. Se o evento guardar um número de conta em texto legível, esse número continua visível a quem lê o payload. Num serviço que só precisa do identificador de processo P, retira o número no produtor e autentica a representação minimizada. Apagá-lo no coletor mantendo o MAC original muda os bytes que a referência protege. receivedAt, acrescentado pelo coletor, está fora do payload: qualquer afirmação sobre essa hora exige evidência própria.

Quatro resultados, sem atalhos para verde

Usa quatro colunas no papel de trabalho. Disponibilidade: foi possível carregar a geração de chave indicada? Matemática: o MAC calculado sobre os bytes coincide com o recebido? Política: o uso dessa geração e desse período é admissível? Completude: o inventário esperado está representado, sem identidades inesperadas ou duplicações indevidas? A falta de K1 produz macMatches=null, e não false. Uma chave errada presente produz false. Uma chave comprometida pode produzir true na comparação e ser recusada pela política.

No lote A, seis identidades foram emitidas. A variante omitted conserva cinco MACs válidos mas falta A103; a variante duplicated conserva sete receções válidas para seis identidades. Nenhuma equivale ao lote normal exatamente uma vez. O inventário do produtor é um ficheiro separado escrito antes do coletor: serve como referência didática de emissão. Está sob o mesmo utilizador local e não prova custódia independente. Num sistema real, identifica quem pode alterar inventário, política e eventos antes de atribuir força à reconciliação.

Rodar sem confundir emissão e histórico

Associa cada geração a um identificador imutável, material protegido e janelas de utilização. A política do laboratório permite criar eventos K1 antes de rotationTick e usar K2 a partir daí; ambas as gerações podem ser consultadas historicamente até ao tick 200. A verificação ocorre no tick fictício 100. Não são prazos recomendados pela NIST nem regras de um KMS. Servem para tornar visível a diferença entre aplicar proteção nova e processar informação já protegida.

Antes de mudar um produtor, confirma que todos os consumidores necessários conseguem verificar a geração nova. Exemplo: C2 suporta K2 às 10:10, a emissão K1 termina às 10:15 e teste mais mudança demoram no máximo dois minutos. Testar a compatibilidade e mudar nessa janela preserva continuidade; retirar K1 dos verificadores eliminaria a capacidade histórica ainda exigida. Um nome K1 reciclado com bytes novos torna o histórico ambíguo. A autorização de uso antigo não deve voltar a permitir emissão nova só para resolver uma falha de consulta.

Compromisso não altera a matemática

Na variante compromised, a mesma chave continua disponível e todos os MACs podem conferir, mas a tabela de confiança assinala-a como comprometida. O programa conserva os dois factos. Mudar o campo compromised para false faz o verificador aceitar novamente a política; esse resultado prova que a configuração influencia a decisão, não que a chave deixou de estar exposta. Não uses o tempo declarado por um payload como prova externa de que foi criado antes do compromisso: um detentor da chave pode escolher esse campo.

Num caso diferente, um arquivo com custódia independente conserva bytes e MAC desde as 10:30 e a primeira exposição possível é às 11:00. Essa referência pode satisfazer uma política explícita de confiança histórica. Um segundo registo recebido às 12:00 e datado de 10:00, sem âncora anterior, não tem a mesma sustentação. Conserva-o e reporta a incerteza; falta de corroboração não demonstra falsificação. A análise de um segredo comprometido deve ocorrer sob autorização e com consequências explicadas.

Detentores do segredo e atribuição

Qualquer entidade que conheça a chave HMAC e o formato pode gerar um MAC que o verificador aceite matematicamente. A variante holder-forged acrescenta um evento EXTRA com o mesmo segredo, fora do inventário do produtor. A comparação passa; a reconciliação deteta a identidade inesperada. Esta variante deteta a identidade EXTRA. O inventário do verificador compara apenas identidades: o detentor também pode substituir amount de uma identidade esperada e recalcular o MAC. Nesse caso, allLayersPass pode continuar true mesmo sem alterar o inventário. Não equivale a atribuição individual nem a reconciliação integral de valores. Se também alterar a referência, o detentor pode ainda esconder identidades inesperadas. producerId dentro do payload não transforma um segredo partilhado numa assinatura individual.

O exercício usa subprocessos reais, mas todos pertencem ao mesmo utilizador do SO. Os ficheiros de chave são descartáveis e têm permissões locais restritas; não são HSM, KMS ou fronteiras administrativas independentes. Para avaliar um desenho real, pede evidência sobre geração, distribuição, permissões de uso, exportação, gestão do trust store e recuperação. Uma chave não exportável ainda pode ser utilizada indevidamente através de uma API Decrypt autorizada em excesso. Avalia a operação permitida e o objeto protegido, além do armazenamento do segredo.

Executar e prever as oito variantes

Descarrega o pacote de materiais desta aula, extrai-o numa pasta de trabalho e abre aí o terminal. Não precisa de Docker, rede, credenciais ou bibliotecas adicionais. Executa python3 lab.py run --fixture fixture-A.json --out run-A e depois python3 check_expected.py run-A. Repete com fixture-B.json e run-B. Cada destino tem de ser novo. Os dois inventários têm seis e sete eventos; as chaves aleatórias descartáveis tornam os bytes dos resultados diferentes entre execuções.

Antes de abrir result.json, prevê: baseline passa; omitted tem uma identidade em falta; duplicated tem duas receções do alvo; modified tem um MAC divergente; rotation usa duas gerações; old-key-missing tem três comparações não realizadas; compromised tem comparações válidas e política recusada; holder-forged tem uma identidade inesperada apesar do MAC válido. O oráculo separado usa listas literais de IDs e valores para A/B e matrizes de resultados, sem importar o verificador. Isto dá independência do cálculo, não revisão humana independente. Os ficheiros emitted.jsonl, collected.jsonl, producer-inventory.json e policy.json permitem refazer a comparação.

Modificar uma hipótese e escrever o parecer

Usa uma cópia da política compromised. Mantém os eventos e altera apenas o estado da chave para não comprometida; o README dá o comando verify para gerar outro ficheiro de resultado sem substituir o anterior. Prevê quais colunas mudam. Repõe o estado comprometido e move a janela de criação para excluir o último evento; compara policyDecision com macMatches. Também podes devolver K1.withheld-for-exercise ao keyring numa cópia da variante old-key-missing e repetir. Esta alteração recupera uma capacidade de comparação, não certifica custódia da chave.

Caso guiado: recebes seis eventos, um deles duplicado no transporte; três precisam de K1 e a tabela assinala compromisso. Escreve quatro conclusões separadas e uma limitação sobre a fonte do inventário. Identifica os controlos adicionais para confiança histórica e o responsável por aprovar a utilização. Resumo: não substituas resultados desconhecidos por falha ou sucesso; não elimines originais para obter um relatório verde; não atribuas tempos de receção à cobertura do MAC. Relaciona este exercício com PKI, retenção de evidência, revogação, monitorização e controlos de custódia.

Verificar o contexto do conteúdo protegido

Define o que uma verificação criptográfica protege e o que a aplicação ainda tem de associar. Neste modelo didático, a etiqueta autentica o conteúdo cifrado e um contexto escolhido. Se o contexto não inclui o registo, mover um bloco completo com a sua etiqueta pode preservar a verificação e alterar a sua associação de negócio.

A aplicação deve fornecer os IDs esperados de uma fonte fiável e incluí-los no contexto autenticado. Aceitar simplesmente os IDs que acompanham o bloco permite mover o conjunto inteiro. O exemplo pressupõe que o mecanismo rejeita um contexto diferente; não especifica um algoritmo, uma biblioteca ou um esquema de nonces.

Exercício: troca dois blocos entre clientes e compara os resultados com contexto ausente, contexto movido com o bloco e contexto esperado independentemente. Resumo: integridade do conteúdo e associação ao objeto pretendido são propriedades a verificar em conjunto.

Armadilhas comuns

Confundir MAC válido com lote completo; reutilizar identificadores de chave; considerar processos locais como fronteiras de segurança; transformar indisponibilidade da chave em divergência matemática.