Capítulo 15 — Evidências e medição

Mapa da aula

Aula 15 publicada. Mapa, exemplo, EX043.

flowchart TD
  N0["15.1 Por que os logs precisam de proteção"]
  N1["Laboratório — Log de auditoria encadeado por hashes"]
  N2["15.2 Ler a cadeia"]
  N3["15.3 Medir os controles"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX043"]

Desenho lógico

flowchart LR
  N0["15.1 Por que os logs precisam de proteção"]
  N1["Laboratório — Log de auditoria encadeado por hashes"]
  N2["15.2 Ler a cadeia"]
  N3["15.3 Medir os controles"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX043"]

[15.1 Por que os logs precisam de proteção]
    |
    v
[Laboratório — Log de auditoria encadeado por hashes]
    |
    v
[15.2 Ler a cadeia]
    |
    v
[15.3 Medir os controles]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX043]

Objetivos de aprendizagem

Você vai (1) tornar os logs evidentes a adulterações com cadeias de hashes; (2) medir os controles de segurança com definições claras; (3) interpretar as evidências com honestidade.

15.1 Por que os logs precisam de proteção

Quando um leitor reclama que alguém acessou seu registro, a Tidewell confere o log de acesso. Mas um insider que tivesse usado os dados indevidamente também poderia editar o log. Priya aprende que as evidências precisam ser evidentes a adulterações (tamper-evident): as mudanças precisam ser detectáveis. Uma cadeia de hashes faz isso incluindo o hash de cada entrada na entrada seguinte, de modo que editar qualquer entrada muda todos os hashes posteriores. Publicar ou guardar separadamente o hash mais recente, chamado de cabeça (head), permite a um auditor detectar edições. Os logs do Certificate Transparency, definidos na RFC 6962, usam uma estrutura relacionada, uma árvore de Merkle, em escala de internet.

Laboratório — Log de auditoria encadeado por hashes

"""Tamper-evident audit log: each entry's hash includes the previous hash (SHA-256)."""
import hashlib
def chain(entries):
    prev, out = "0" * 64, []
    for e in entries:
        prev = hashlib.sha256((prev + e).encode()).hexdigest(); out.append(prev)
    return out

def main():
    log = ["2026-05-01 admin login", "2026-05-01 patron export", "2026-05-02 key rotated"]
    good = chain(log)
    print("head:", good[-1][:16])
    log[1] = "2026-05-01 report viewed"
    bad = chain(log)
    print("head after editing entry 2:", bad[-1][:16])
    print("first differing entry:", next(i + 1 for i, (x, y) in enumerate(zip(good, bad)) if x != y))

if __name__ == "__main__":
    main()

Execute com python3 lab_chain.py. Saída verificada:

head: 4492b592d8b729f0
head after editing entry 2: c36641715cd10666
first differing entry: 2

15.2 Ler a cadeia

O log de três entradas tem uma cabeça que começa com 4492b592. Quando a segunda entrada é editada de "patron export" para "report viewed", a cabeça passa a ser c3664171, e o primeiro hash diferente está na entrada 2, mostrando exatamente onde a adulteração começou. Priya anota o limite: se um insider puder reescrever a cadeia inteira e a cabeça guardada, nada é detectado. A cabeça precisa, portanto, ser guardada onde o insider não possa alterá-la, por exemplo enviada diariamente ao sistema de um auditor separado ou assinada por outra equipe.

15.3 Medir os controles

Priya define medidas para os controles da Tidewell: a porcentagem de contas da equipe que usam chaves de segurança, o número de dias de antecedência com que os certificados são renovados antes da expiração e a proporção de entradas do log de acesso revisadas. Cada medida tem uma definição precisa e uma fonte de dados. Ela relata as linhas de base com honestidade: até agora, apenas 40 por cento da equipe usa chaves de segurança, e as revisões de log acontecem mensalmente, e não semanalmente. Ela resiste a apresentar apenas os números favoráveis, porque as decisões da direção dependem de um quadro preciso. Ela mostra cada medida como uma tendência ao longo dos meses, para que a direção veja se os controles estão melhorando ou piorando.

Exemplo resolvido

Priya constrói um log encadeado por hashes, mostra que uma edição muda a cabeça de 4492b592 para c3664171 e a localiza na entrada 2, e relata as linhas de base dos controles, incluindo a adoção de 40 por cento das chaves de segurança.

Caso sintético. As entradas do log e as linhas de base são inventadas; a RFC 6962 é real.

Erros e limites

As cadeias de hashes só detectam adulterações se a cabeça for protegida separadamente. Medidas sem definição produzem números inconsistentes.

Exercícios

• EX043 — Propriedade da cadeia. Por que editar uma entrada muda todos os hashes posteriores?

  Mostrar critérios de avaliação

  Rubrica: 3 = o hash de cada entrada inclui o hash anterior;; 2 = encadeamento;; 1 = não muda;; 0 = nenhuma.

• EX044 — Cabeças do laboratório. Informe a cabeça antes e depois da edição e onde começa a diferença.

  Mostrar critérios de avaliação

  Rubrica: 3 = 4492b592 e depois c3664171, diferindo a partir da entrada 2;; 2 = cabeças;; 1 = errado;; 0 = nenhuma.

• EX045 — Proteger a cabeça. Onde a cabeça precisa ser guardada, e por quê?

  Mostrar critérios de avaliação

  Rubrica: 3 = num lugar que o insider não possa alterar, por exemplo o sistema de um auditor separado ou assinada por outra equipe;; 2 = separada;; 1 = no mesmo servidor;; 0 = nenhuma.

Síntese

Logs à prova de adulteração e medidas relatadas com honestidade transformam afirmações de segurança em evidências que outros podem conferir.