◇ OpenCyber Academy
Tecnólogo · Capítulo 7 · Português

Capítulo 7 — Fundamentos de identidade e acesso

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 7 — Fundamentos de identidade e acesso

Mapa da aula

Aula 07 publicada. Mapa, exemplo, EX013.

flowchart TD
  N0["7.1 Onde as assinaturas autenticam"]
  N1["7.2 Cadeias e repositórios de confiança"]
  N2["7.3 Ordem das mudanças"]
  N3["7.4 Caso resolvido"]
  N4["7.5 Atividade prática"]
  N5["7.7 Chaves SSH de host e de usuário"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX013"]

Desenho lógico

flowchart LR
  N0["7.1 Onde as assinaturas autenticam"]
  N1["7.2 Cadeias e repositórios de confiança"]
  N2["7.3 Ordem das mudanças"]
  N3["7.4 Caso resolvido"]
  N4["7.5 Atividade prática"]
  N5["7.7 Chaves SSH de host e de usuário"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX013"]

[7.1 Onde as assinaturas autenticam]
    |
    v
[7.2 Cadeias e repositórios de confiança]
    |
    v
[7.3 Ordem das mudanças]
    |
    v
[7.4 Caso resolvido]
    |
    v
[7.5 Atividade prática]
    |
    v
[7.7 Chaves SSH de host e de usuário]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX013]

Objetivos de aprendizagem

Você vai (1) distinguir autenticação de autorização nos serviços; (2) explicar certificados, cadeias e repositórios de confiança; (3) identificar as assinaturas relevantes para o quântico em SSO, mTLS, SSH e assinatura de código; e (4) planejar a ordem das mudanças de identidade pós-quânticas.

7.1 Onde as assinaturas autenticam

Os usuários entram por um SSO cujos tokens são assinados (RSA ou ECDSA); os serviços se autenticam entre si com certificados de TLS mútuo; os administradores usam chaves SSH; os pipelines de CI assinam artefatos; os dispositivos guardam certificados para o registro. A autorização (papéis, políticas) não é ameaçada pelos computadores quânticos; as assinaturas por trás da autenticação, sim.

Na KLS, essa lista corresponde a chaves concretas: a chave de token RS256 do provedor de SSO, a chave emissora ECDSA P-256 da AC interna, as chaves SSH Ed25519 dos administradores, a chave de assinatura de versões RSA-3072 e os certificados de registro de dispositivos nos leitores. Cada uma ganha uma linha com algoritmo, tempo de vida e o sistema que a verifica, porque é o verificador, mais do que o signatário, que costuma limitar a migração.

7.2 Cadeias e repositórios de confiança

Um certificado é confiável se encadeia até uma raiz no repositório de confiança do verificador. Introduzir uma raiz pós-quântica significa atualizar primeiro todos os repositórios de confiança — sistemas operacionais, runtimes de linguagens, appliances, sistemas de parceiros. A PKI interna é o melhor lugar para começar com certificados pós-quânticos, porque a KLS controla tanto os emissores quanto os verificadores.

Os sistemas dos parceiros são os repositórios mais lentos de mudar, porque a KLS não pode enviar atualizações para eles; qualquer ligação mTLS com um parceiro precisa que a nova raiz seja entregue e confirmada com meses de antecedência. Dentro da KLS, o pacote de ACs da imagem base dos contêineres e os truststores Java dos serviços são os repositórios mais esquecidos, já que são embutidos nos artefatos em vez de gerenciados nos hosts.

7.3 Ordem das mudanças

Comece pelos itens em que o risco de forjar depois é alto e o controle também: a raiz e as intermediárias internas, a assinatura de código de artefatos de vida longa. Deixe os tokens de vida curta para depois; as suas chaves podem ser rotacionadas rapidamente quando as bibliotecas suportarem o ML-DSA (FIPS 204). Os certificados web públicos seguem o suporte das ACs públicas e dos navegadores.

A ordem também tem uma vantagem prática. As raízes internas e as chaves de assinatura são poucas, pertencem a uma única equipe e mudam em cerimônias planejadas, então são bons primeiros projetos. Os milhares de certificados finais e de tokens seguem automaticamente quando os emissores e os verificadores suportarem o ML-DSA, então o esforço gasto neles cedo é, na maior parte, desperdiçado esperando pelas bibliotecas.

7.4 Caso resolvido

O inventário de identidade da KLS: tokens de SSO RS256 (tempo de vida de 1 hora); mTLS dos serviços pela AC interna (ECDSA P-256, certificados finais de 90 dias, raiz de 15 anos); chaves SSH de usuário Ed25519; assinatura de versões RSA-3072. Prioridade: a raiz interna (vida longa, controlada), a assinatura de versões (artefatos verificados por anos), depois os certificados finais de mTLS, o SSH e os tokens.

A lista também mostra onde a KLS pode se preparar sem algoritmos novos. A assinatura de versões pode acrescentar desde já um segundo campo de assinatura ao formato dos artefatos, de modo que acrescentar o ML-DSA depois seja uma mudança de pipeline. O SSH pode passar a usar certificados de uma autoridade central, para que as chaves de usuário sejam rotacionadas de forma central. Nenhum dos dois passos exige suporte pós-quântico, e ambos encurtam o tempo de migração mais tarde.

7.5 Atividade prática

Desenhe a PKI interna da KLS com a raiz, as intermediárias e os tipos de certificados finais, e liste todos os repositórios de confiança que precisam aceitar uma nova raiz.

O desenho deve mostrar a raiz de 15 anos offline, pelo menos uma intermediária emissora e os tipos de certificados finais para os serviços da malha, o ingress, os agentes de monitoramento e os dispositivos. Depois, liste os repositórios de confiança por parte confiante: pacotes do sistema operacional do host, pacotes das imagens de contêiner, truststores Java, pacotes de confiança dos sidecars da malha, agentes de monitoramento, runners de CI e qualquer parceiro que verifique certificados da KLS em mTLS. Marque quais repositórios a KLS atualiza por configuração e quais só por reconstrução ou pedindo ao parceiro. O mais longo desses caminhos define a data segura mais cedo para emitir certificados finais pós-quânticos.

7.6 Erros comuns e limites

No laboratório da KLS, o primeiro erro produziu exatamente o resultado esperado: um certificado final de teste assinado por uma intermediária ML-DSA falhou na validação em todos os serviços Java, porque os seus truststores não tinham recebido a nova raiz. Gastar esforço com mapeamentos de papéis ou políticas de autorização é o segundo erro, já que eles não são criptográficos. O terceiro é o mais lento de corrigir: um parceiro que fixa a raiz atual da KLS vai rejeitar uma nova cadeia até que os seus próprios operadores a atualizem.

7.7 Chaves SSH de host e de usuário

O SSH ilustra a separação entre a troca de chaves e a identidade. A troca de chaves híbrida no OpenSSH protege desde já a confidencialidade da sessão, enquanto as chaves de host e de usuário continuam sendo assinaturas clássicas. Rotacionar as chaves de host é barato do ponto de vista operacional se os clientes usam certificados ou arquivos known-hosts gerenciados, e caro se cada usuário fixou chaves individuais. Por isso, passar os administradores para certificados SSH emitidos por uma autoridade central é um passo útil de agilidade, mesmo antes de implantar qualquer algoritmo de chave de host pós-quântico.

Os administradores da KLS hoje confiam nas chaves de host por meio de entradas individuais em known_hosts, então uma mudança de chave de host produz avisos em toda a equipe. Passar para certificados de host significa uma única chave de AC na configuração de cada cliente, e uma futura mudança para um algoritmo de chave de host pós-quântico se torna uma mudança de AC.

Exercícios

Síntese

As assinaturas sustentam a autenticação no SSO, no mTLS, no SSH e na assinatura de código. A identidade pós-quântica começa pelas raízes internas e pela assinatura de longa duração, depois que os repositórios de confiança estiverem preparados.

Continue estudando — capítulo 07 de 30

← Capítulo 06 · Índice de capítulos do curso · Capítulo 08 →

Siga para a próxima lição escrita.