◇ OpenCyber Academy
Engenharia · Capítulo 18 · Português

Capítulo 18 — Arquitetura de segurança

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 18 — Arquitetura de segurança

Mapa da aula

Aula 18 publicada. Mapa, exemplo, EX052.

flowchart TD
  N0["18.1 Âncoras de confiança"]
  N1["18.2 Defesa em profundidade para as chaves"]
  N2["18.3 Centralizado ou distribuído"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX052"]

Desenho lógico

flowchart LR
  N0["18.1 Âncoras de confiança"]
  N1["18.2 Defesa em profundidade para as chaves"]
  N2["18.3 Centralizado ou distribuído"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX052"]

[18.1 Âncoras de confiança]
    |
    v
[18.2 Defesa em profundidade para as chaves]
    |
    v
[18.3 Centralizado ou distribuído]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX052]

Objetivos de aprendizagem

Você vai (1) posicionar âncoras de confiança criptográficas numa arquitetura; (2) projetar defesa em profundidade para as chaves; (3) comparar serviços de chaves centralizados e distribuídos.

18.1 Âncoras de confiança

Toda arquitetura criptográfica se apoia em âncoras de confiança, chaves cuja autenticidade é pressuposta, e não provada, como um certificado raiz ou uma chave pública de assinatura de firmware embutida nos medidores. Aiyana identifica as âncoras da Ridgeway: a chave raiz do firmware, a raiz TLS dos concentradores e a chave mestra no serviço de chaves. O comprometimento de uma âncora é catastrófico, então as âncoras são poucas, mantidas offline sempre que possível e protegidas por procedimentos que exigem várias pessoas. Seu diagrama de arquitetura marca as âncoras em vermelho, para que os revisores vejam imediatamente onde é necessária a maior proteção.

18.2 Defesa em profundidade para as chaves

Aiyana organiza a proteção em camadas: a chave raiz do firmware fica num módulo de segurança de hardware offline, usado apenas em cerimônias de assinatura; chaves de assinatura intermediárias assinam as versões do dia a dia e podem ser revogadas; os medidores só aceitam firmware quando a cadeia é verificada e o número de versão aumenta, o que impede a volta (rollback) a versões antigas e vulneráveis. Cada camada limita o dano causado pela falha de outra. Se uma chave intermediária vazar, a raiz pode revogá-la; se uma versão antiga assinada for reenviada, a verificação de versão a rejeita.

18.3 Centralizado ou distribuído

Um único serviço central de chaves simplifica a auditoria e a rotação, mas se torna um alvo de alto valor e um ponto único de falha. Distribuir as chaves entre serviços regionais melhora a disponibilidade, mas multiplica os lugares a proteger. Aiyana propõe um serviço central com um standby ativo (hot standby) num segundo data center e caches regionais que guardam apenas chaves derivadas de vida curta. Ela avalia o projeto em relação ao modelo de ameaça do Capítulo 15 e registra que um insider num site regional só consegue afetar as chaves de vida curta daquela região. Ela anota que o site de standby duplica os controles físicos a auditar.

Exemplo resolvido

A arquitetura de Aiyana marca três âncoras de confiança, coloca a raiz do firmware offline, com intermediárias para as versões e proteção contra rollback, e escolhe um serviço central de chaves com standby e caches regionais de vida curta.

Caso sintético. A arquitetura é inventada.

Erros e limites

Raízes offline são tão seguras quanto os procedimentos das cerimônias. A proteção contra rollback falha se os contadores de versão puderem ser reiniciados.

Exercícios

Síntese

As arquiteturas devem nomear suas âncoras de confiança, proteger as chaves em camadas e equilibrar o controle central com a disponibilidade, com exposição regional limitada.

Continue estudando — aula 18 (capítulo 18 de 50)

← Capítulo 17 · Índice das aulas · Capítulo 19 →

Continue para a próxima aula já escrita.