Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["11.1 Isolamento e privilégio"]
N1["11.2 Provedores criptográficos"]
N2["11.3 Atualizações e boot"]
N3["11.5 Atividade prática"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["11.1 Isolamento e privilégio"]
N1["11.2 Provedores criptográficos"]
N2["11.3 Atualizações e boot"]
N3["11.5 Atividade prática"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX021"]
[11.1 Isolamento e privilégio]
|
v
[11.2 Provedores criptográficos]
|
v
[11.3 Atualizações e boot]
|
v
[11.5 Atividade prática]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem
Você vai (1) descrever processos, isolamento de memória, permissões de arquivos e serviços do sistema; (2) explicar como os sistemas operacionais oferecem serviços criptográficos e armazenamento de chaves; (3) identificar as dependências no nível do sistema operacional que controlam uma migração; e (4) raciocinar sobre os canais de atualização e as suas assinaturas.
11.1 Isolamento e privilégio
Um sistema operacional isola os processos em espaços de endereçamento separados, impõe permissões de arquivos e concede privilégios a usuários e serviços. Chaves guardadas num arquivo que todos podem ler anulam tudo isso; chaves mantidas por um serviço privilegiado, ou por hardware como um TPM, só são alcançáveis por interfaces definidas. O menor privilégio — dar a cada componente apenas o acesso de que ele precisa — se aplica ao material criptográfico tanto quanto aos arquivos.
O inventário da HCU registra, portanto, onde cada chave fica, além do algoritmo que ela usa.
11.2 Provedores criptográficos
As aplicações raramente implementam a criptografia elas mesmas. Elas chamam um provedor: os provedores do OpenSSL no Linux, o framework CNG no Windows, os repositórios de chaves da plataforma nos sistemas móveis. O provedor e a sua versão decidem quais algoritmos uma aplicação pode usar, então uma migração pós-quântica muitas vezes começa como uma atualização do sistema operacional ou de uma biblioteca. As políticas criptográficas de todo o sistema, em algumas distribuições Linux, definem os algoritmos permitidos num só lugar; isso é valioso para a agilidade, porque uma única mudança de política pode ativar um grupo híbrido em muitos serviços, e perigoso se for mudado sem testes.
11.3 Atualizações e boot
Os sistemas operacionais confiam em atualizações assinadas e, pelo boot seguro, em componentes de boot assinados. Hoje essas assinaturas usam tipicamente RSA ou ECDSA. Como os ataques de falsificação posterior visam âncoras de confiança de vida longa, os fornecedores estão planejando assinaturas pós-quânticas ou baseadas em hash para o firmware e as cadeias de boot; a SP 800-208 aprova os esquemas baseados em hash com estado LMS e XMSS, adequados à assinatura de firmware quando o signatário consegue gerenciar o estado com cuidado. Os dispositivos cuja ROM de boot só consegue verificar RSA não podem ser atualizados apenas por software.
Esses dispositivos precisam de um plano de substituição.
11.4 Exemplo resolvido
Os servidores das agências da HCU rodam uma distribuição Linux cuja versão atual do OpenSSL suporta o grupo híbrido X25519MLKEM768 no TLS. A equipe descobre que o middleware bancário central traz a sua própria biblioteca TLS, mais antiga e ligada estaticamente, e ignora o provedor do sistema operacional. Atualizar o sistema operacional não muda nada para esse middleware; o fornecedor precisa entregar uma nova versão. A visão no nível do sistema operacional revelou uma dependência oculta que uma lista de verificação servidor a servidor teria deixado escapar.
A equipe acrescenta ao inventário uma coluna que registra se cada aplicação usa a biblioteca do sistema ou a sua própria e pede a cada fornecedor um roteiro.
11.5 Atividade prática
Numa máquina virtual de laboratório que você controla, liste as bibliotecas criptográficas instaladas e as suas versões e encontre onde está configurada a política criptográfica do sistema (se houver). Registre quais aplicações ligam as suas próprias cópias.
Procure aplicações que trazem a sua própria biblioteca TLS, como alguns bancos de dados, ambientes de execução de linguagens e agentes de fornecedores. As suas versões podem estar anos atrás da biblioteca do sistema. Faça isso apenas numa máquina que você controla e não mude a política criptográfica durante o exercício. O seu registro se torna uma pequena versão do inventário de dependências que a HCU constrói para os seus servidores, e as mesmas perguntas valem em escala.
11.6 Erros comuns e limites
- Supor que uma atualização do sistema operacional migra todas as aplicações.
- Editar uma política criptográfica de todo o sistema diretamente na produção.
- Deixar de lado as assinaturas da cadeia de boot e das atualizações.
As aplicações que trazem as suas próprias bibliotecas não mudam quando o sistema operacional muda. As mudanças de política de todo o sistema podem quebrar serviços de maneiras difíceis de rastrear, então teste-as num laboratório e implante-as gradualmente. As assinaturas de boot e de atualização são fáceis de esquecer porque funcionam em silêncio, mas protegem o código mais confiável da máquina e muitas vezes têm os prazos de migração mais longos.
Exercícios
- EX021 — Dependência de provedor. Explique por que uma aplicação que liga estaticamente a sua biblioteca TLS é um item de migração separado. Rubrica: 3 = consequências de dependência, de responsabilidade e de testes.
- EX022 — Cadeia de boot. Por que as assinaturas baseadas em hash com estado são adequadas à assinatura de firmware, mas arriscadas para um servidor web? Rubrica: 3 = menciona o gerenciamento do estado, o volume de assinaturas e a recuperação.
Síntese
Os sistemas operacionais fornecem os provedores criptográficos, o armazenamento de chaves e as cadeias de atualização assinadas de que as aplicações dependem. A migração, portanto, passa pelas camadas do sistema operacional e das bibliotecas — e por todo componente que as contorna.