Hardening de um portátil de programador num dia

15.07.20263 min de leituraEquipa Atalaia

O portátil de um programador é uma estação de build. Guarda código, material de assinatura, credenciais de cloud e tokens que podem fazer push para pipelines de produção. Se for perdido ou comprometido, tudo o que está a montante da revisão fica exposto.

Esta é uma checklist que pode fazer num único dia, sozinho ou numa sessão de equipa. Cada item tem uma verificação, uma correção e uma forma de saber que está feito.

1. Encriptação total do disco

Este é o controlo que mais importa quando um portátil é perdido ou roubado, e normalmente já está disponível. Verifique-o em vez de o assumir.

# macOS
fdesetup status

# Linux: look for crypto_LUKS on the root device
lsblk -o NAME,FSTYPE,MOUNTPOINT

# Windows (admin prompt)
manage-bde -status C:

Concluído quando: a cifragem está ativa, a chave de recuperação está guardada num sítio que a organização controla e o ecrã bloqueia após pouco tempo de inatividade.

2. Segredos fora dos dotfiles

Os tokens acumulam-se em ~/.bashrc, ~/.zshrc, ficheiros .env, configurações de ferramentas em ~/.config e no histórico da shell. Qualquer processo a correr com o seu utilizador os consegue ler, incluindo scripts, extensões e hooks de instalação de pacotes.

# Scan home config and shell files with Gitleaks
gitleaks dir ~/.config --no-banner
gitleaks dir ~/.zshrc --no-banner
gitleaks dir ~/.zsh_history --no-banner

# Quick manual pass for exported tokens
grep -nE '^export .*(TOKEN|SECRET|KEY)=' ~/.bashrc ~/.zshrc 2>/dev/null

Mova o que encontrar para o keychain do sistema ou para o seu gestor de secrets e carregue-o quando precisar. Por exemplo, no macOS:

security add-generic-password -a "$USER" -s example-api -w
export EXAMPLE_API_TOKEN="$(security find-generic-password -s example-api -w)"

Concluído quando: uma análise dos dotfiles e do histórico não encontra nada, e qualquer token que tenha estado exposto em texto simples foi rodado, e não apenas mudado de sítio.

3. Chaves SSH com hardware ou um agente

Um id_rsa não cifrado em ~/.ssh é uma credencial portátil. Prefira uma chave que não possa sair de um token de hardware. A maioria das chaves de segurança FIDO2 suporta isto com OpenSSH 8.2 ou posterior:

# Hardware-backed key; requires touch for every use
ssh-keygen -t ed25519-sk -O resident -C "laptop-$(hostname)"

# If no hardware key: a passphrase-protected key held in an agent
ssh-keygen -t ed25519 -C "laptop-$(hostname)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519   # macOS
ssh-add ~/.ssh/id_ed25519                        # Linux

Remova as chaves antigas do seu Git host e dos servidores quando a nova funcionar. Evite agent forwarding para hosts em que não confia totalmente; use ProxyJump em vez disso.

Concluído quando: não restam chaves privadas não cifradas, e as chaves públicas antigas foram removidas de todas as contas.

4. Assinatura de commits Git

A assinatura permite que os revisores e as regras de branch protection distingam os seus commits dos de alguém a usar o seu nome em git config. O Git suporta chaves SSH para assinatura, por isso pode reutilizar a chave do passo 3.

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519_sk.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# Verify
git commit --allow-empty -m "test signed commit"
git log --show-signature -1

Carregue a chave pública no seu Git host como signing key e depois considere exigir commits assinados nas branches protegidas.

Concluído quando: os novos commits aparecem como verificados no Git host.

5. Tokens com privilégio mínimo

Os personal access tokens clássicos têm muitas vezes todos os scopes do utilizador, nunca expiram e funcionam em todos os repositórios. Substitua-os.

• Use fine-grained tokens limitados aos repositórios e permissões de que uma tarefa precisa.
• Defina uma expiração. Curta duração vale mais que conveniência.
• Prefira o fluxo de login da própria CLI, como gh auth login, que guarda as credenciais no keychain.
• Para acesso à cloud, use sessões SSO de curta duração em vez de access keys de longa duração em ~/.aws/credentials ou ficheiros semelhantes.
• Dê a cada ferramenta, script ou assistente o seu próprio token, para poder revogar um sem estragar os restantes.

Concluído quando: nenhum token em uso é mais antigo do que a sua política de expiração, e nenhum tem um scope maior do que a sua função.

Faça-o em equipa

Reserve uma manhã, partilhe esta tabela e ponha toda a gente a trabalhar nela em conjunto. A tarde é para os atrasados e para transformar as verificações em algo que a sua gestão de dispositivos consiga reportar.

Onde isto fica na linha

Na torre (em desenvolvimento):