◇ OpenCyber Academy
Técnico · Capítulo 3 · Português

Capítulo 3 — Sistemas operacionais e identidades

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 3 — Sistemas operacionais e identidades

Mapa da aula

Aula 03 publicada. Mapa, exemplo, EX009.

flowchart TD
  N0["3.1 Onde as chaves ficam"]
  N1["3.2 Privilégio mínimo para arquivos de chave"]
  N2["3.3 Contas de serviço e identidade"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX009"]

Desenho lógico

flowchart LR
  N0["3.1 Onde as chaves ficam"]
  N1["3.2 Privilégio mínimo para arquivos de chave"]
  N2["3.3 Contas de serviço e identidade"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX009"]
[3.1 Onde as chaves ficam]
    |
    v
[3.2 Privilégio mínimo para arquivos de chave]
    |
    v
[3.3 Contas de serviço e identidade]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX009]

Objetivos de aprendizagem

Você vai (1) localizar os repositórios de chaves e certificados em hosts Linux e Windows; (2) aplicar o privilégio mínimo aos arquivos de chave privada; (3) explicar como as contas de serviço usam identidades criptográficas.

3.1 Onde as chaves ficam

No host Linux de transferência de arquivos, Tomás encontra o certificado do servidor em /etc/ssl/certs e a chave privada num diretório que só o root e a conta de serviço podem ler. Nos notebooks Windows, os certificados ficam no repositório de certificados, que o sistema operacional protege com as credenciais do usuário ou da máquina. Os coletores guardam o certificado de cliente do Wi-Fi num repositório de chaves do fornecedor apoiado em hardware. Priya explica que a localização importa tanto quanto o algoritmo: uma chave RSA ou ECDSA forte num arquivo legível por todos não dá nenhuma proteção, porque qualquer um que copie o arquivo pode se passar pelo servidor.

3.2 Privilégio mínimo para arquivos de chave

Tomás confere as permissões no host de transferência de arquivos com ls -l e descobre que um script de backup tinha copiado a chave privada para /tmp com o modo 644, legível por todas as contas. Ele relata o problema, remove a cópia, e a equipe rotaciona a chave porque não consegue provar que ninguém a leu. A regra que ele escreve no caderno é que uma chave privada deve poder ser lida apenas pelo processo que precisa dela, pertencer a uma conta dedicada e nunca ser copiada para pastas compartilhadas, chamados ou chats. Uma exposição sem evidência de uso indevido ainda exige rotação.

3.3 Contas de serviço e identidade

Muitos serviços da Lumen rodam como contas não humanas. O portal de rastreamento roda como svc-portal, que precisa ler sua chave TLS e mais nada; o job noturno de transferência roda como svc-sftp e se autentica junto aos parceiros com uma chave SSH. Essas identidades são tão importantes quanto as senhas da equipe, mas costumam ser esquecidas quando as pessoas saem. Tomás acrescenta cada conta de serviço ao inventário, com sua chave, seu dono e a data em que a chave foi criada, para que os capítulos seguintes possam planejar a rotação. Ele também confirma que nenhuma das contas consegue fazer login interativo.

Exemplo resolvido

Tomás audita as permissões dos arquivos de chave em dois hosts sintéticos, encontra a cópia 644 em /tmp e registra o chamado de rotação e a conta de serviço afetada.

Caso sintético. Os nomes de host, os caminhos e as contas são exemplos inventados de organizações comuns.

Erros e limites

As permissões de arquivo não impedem o root nem um serviço comprometido. Os repositórios apoiados em hardware reduzem as cópias, mas não o uso indevido por meio do dispositivo.

Exercícios

Síntese

A identidade criptográfica é tão forte quanto as permissões de arquivo e os limites de conta que protegem cada chave privada.

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

← Capítulo 02 · Índice das aulas · Capítulo 04 →

Continue para a próxima aula já escrita.