Capítulo 6 — Sistemas operacionais e virtualização
Mapa da aula
Aula 06 publicada. Mapa, exemplo, EX011.
flowchart TD
N0["6.1 Provedores e políticas"]
N1["6.2 Contêineres e ligação estática"]
N2["6.3 Virtualização e chaves"]
N3["6.4 Caso resolvido"]
N4["6.5 Atividade prática"]
N5["6.7 Cadência de patches"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX011"]
Desenho lógico
flowchart LR
N0["6.1 Provedores e políticas"]
N1["6.2 Contêineres e ligação estática"]
N2["6.3 Virtualização e chaves"]
N3["6.4 Caso resolvido"]
N4["6.5 Atividade prática"]
N5["6.7 Cadência de patches"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX011"]
[6.1 Provedores e políticas]
|
v
[6.2 Contêineres e ligação estática]
|
v
[6.3 Virtualização e chaves]
|
v
[6.4 Caso resolvido]
|
v
[6.5 Atividade prática]
|
v
[6.7 Cadência de patches]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX011]
Objetivos de aprendizagem
Você vai (1) explicar o isolamento de processos, os privilégios e os repositórios de chaves; (2) identificar os provedores e as políticas criptográficas do sistema; (3) reconhecer bibliotecas ligadas estaticamente e empacotadas em contêineres; e (4) planejar atualizações de sistema operacional e de imagem que habilitem algoritmos pós-quânticos.
6.1 Provedores e políticas
No Linux, a maioria dos serviços se liga a uma biblioteca TLS do sistema; o OpenSSL 3.5 acrescentou suporte ao ML-KEM, ao ML-DSA e ao SLH-DSA e grupos TLS híbridos (notas de versão do OpenSSL 3.5). Algumas distribuições centralizam os algoritmos permitidos numa política criptográfica de todo o sistema. O Windows usa o CNG; as plataformas móveis fornecem repositórios de chaves e o TLS da plataforma. A versão do provedor no host determina em grande parte o que os serviços podem negociar — a menos que o serviço traga a sua própria biblioteca.
Nos nós da KLS, a primeira verificação é, portanto, openssl version mais a política criptográfica da distribuição, que pode remover um grupo que a biblioteca suporta.
6.2 Contêineres e ligação estática
Os contêineres empacotam as suas próprias bibliotecas de espaço de usuário; atualizar o sistema operacional do host não muda a biblioteca TLS dentro de uma imagem. Os binários Go e Rust frequentemente ligam a sua criptografia de forma estática. Os implementadores precisam inventariar imagens e binários, não só hosts, e reconstruir as imagens sobre camadas base atualizadas.
A varredura do registro da KLS encontrou o padrão com clareza: a imagem do ingress NGINX trazia um OpenSSL duas versões menores atrás dos hosts, e três serviços Go foram compilados com um toolchain anterior ao TLS híbrido. Nenhum deles mudou quando a frota de nós foi atualizada. O inventário agora lista as versões de biblioteca e de toolchain por digest de imagem, não por host, e a reconstrução é o mecanismo de mudança registrado para cada um.
6.3 Virtualização e chaves
Hipervisores, TPMs virtuais e KMS na nuvem guardam chaves de discos e cargas de trabalho. As suas APIs e o suporte a algoritmos mudam no calendário do provedor de nuvem. Registre quais tipos de chave e algoritmos de KMS cada carga de trabalho usa.
Na KLS, isso abrange as chaves do KMS na nuvem que envolvem os discos dos bancos de dados, os TPMs virtuais dos runners de CI e o cluster de HSMs por trás da AC interna. As chaves de envolvimento de disco são simétricas e continuam adequadas ao uso; as chaves assimétricas usadas na importação para o KMS e na assinatura da AC são as que devem ser acompanhadas. A lista de algoritmos publicada por cada provedor e a data da última verificação vão para a coluna de evidências de fornecedores do inventário.
6.4 Caso resolvido
A KLS atualiza os seus nós Kubernetes para uma distribuição com OpenSSL 3.5. O contêiner do ingress NGINX ainda roda uma imagem base antiga e continua oferecendo apenas grupos clássicos. Uma reconstrução sobre uma nova imagem base habilita o X25519MLKEM768. O serviço de faturamento, escrito em Go, só ganha suporte ao híbrido depois de uma atualização do toolchain, porque a pilha TLS do Go é compilada junto.
O caso resolvido dá três mecanismos de mudança para um único cluster: uma atualização de nós (feita), uma reconstrução de imagem (um pull request, testado em homologação) e uma atualização de toolchain (uma versão do serviço com testes de regressão). A KLS os agendou separadamente e registrou qual deles ativou a fração híbrida, para que as regressões posteriores pudessem ser rastreadas até o artefato certo.
6.5 Atividade prática
Num host de laboratório, liste a versão do OpenSSL no host e dentro de dois contêineres; liste os binários Go ou Rust e as versões dos seus toolchains.
Rode openssl version no host e depois docker run --rm IMAGE openssl version para cada contêiner, ou inspecione a lista de pacotes da imagem quando não houver shell. Para binários Go, go version -m BINARY imprime o toolchain; para Rust, verifique os metadados de compilação ou o Cargo.lock. Coloque os resultados numa tabela com host, digest da imagem, biblioteca, versão e se essa versão suporta o ML-KEM. Uma divergência entre o host e o contêiner é a constatação esperada, não uma anomalia.
6.6 Erros comuns e limites
- Supor que as atualizações do host mudam os contêineres.
- Editar as políticas criptográficas do sistema em produção sem homologação.
- Ignorar as pilhas TLS compiladas junto.
Cada erro apareceu na KLS. O anúncio da atualização dos nós dizia "TLS híbrido disponível", enquanto o contêiner do ingress continuava negociando X25519. Uma edição de teste da política criptográfica do sistema num host de produção desabilitou um grupo de que um agente de monitoramento precisava, e o agente parou de reportar até que a mudança fosse revertida. E o serviço de faturamento em Go, invisível às varreduras de pacotes, manteve a sua pilha TLS antiga até que alguém lesse os seus metadados de compilação.
6.7 Cadência de patches
O suporte pós-quântico chega por meio dos patches comuns, então a cadência de patches da equipe se torna uma alavanca da migração. Acompanhe, para cada imagem base e toolchain, quantos dias ela está atrasada em relação à versão suportada atual. Os serviços atrasados em um ano não conseguem adotar a troca de chaves híbrida sem uma grande atualização de recuperação, que é mais arriscada do que as pequenas atualizações regulares que os teriam mantido em dia.
A KLS mediu o atraso no seu registro: idade mediana das imagens base de 140 dias, pior caso de 410 dias para um serviço legado de relatórios. Esse serviço agora tem uma reconstrução agendada a cada 30 dias, e o seu atraso é uma métrica de painel sob a responsabilidade da sua equipe.
Exercícios
- EX011 — Onde mudar. Para um contêiner NGINX, um serviço Go e um daemon SSH do host, diga o que precisa mudar para habilitar a troca de chaves híbrida. Rubrica: 3 = reconstrução da imagem, toolchain/reconstrução, pacote/configuração do host.
- EX012 — Política de imagens. Proponha uma regra de CI que impeça a implantação de imagens com bibliotecas TLS desatualizadas. Rubrica: 3 = verificação concreta, limite, caminho de exceção.
Síntese
Os sistemas operacionais fornecem provedores criptográficos, mas os contêineres e os binários compilados trazem os seus próprios; o trabalho de implementação segue as bibliotecas até as imagens e os toolchains.
Continue estudando — capítulo 06 de 30
← Capítulo 05 · Índice de capítulos do curso · Capítulo 07 →
Siga para a próxima lição escrita.