Hardening de un portátil de desarrollo en un día

15.07.20263 min de lecturaEquipo Atalaia

Un portátil de desarrollo es una estación de build. Contiene código fuente, material de firma, credenciales cloud y tokens que pueden hacer push a pipelines de producción. Si se pierde o se compromete, todo lo que está antes de la revisión queda expuesto.

Es un checklist que puedes completar en un solo día, solo o en una sesión de equipo. Cada punto tiene una comprobación, una corrección y una forma de saber que has terminado.

1. Cifrado de disco completo

Este es el control que más importa cuando se pierde o te roban un portátil, y normalmente ya está disponible. Compruébalo en lugar de darlo por hecho.

# macOS
fdesetup status

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

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

Hecho cuando: el cifrado está activado, la clave de recuperación está en custodia donde la organización la controla y la pantalla se bloquea tras poco tiempo de inactividad.

2. Secretos fuera de los dotfiles

Los tokens se acumulan en ~/.bashrc, ~/.zshrc, ficheros .env, configuraciones de herramientas bajo ~/.config y el historial del shell. Cualquier proceso que se ejecute como tú puede leerlos, incluidos scripts, extensiones y hooks de instalación de paquetes.

# 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

Mueve lo que encuentres al llavero del sistema o a tu gestor de secretos y cárgalo bajo demanda. Por ejemplo, en macOS:

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

Hecho cuando: un escaneo de dotfiles e historial sale limpio y cualquier token que estuviera expuesto en texto plano se ha rotado, no solo movido.

3. Claves SSH con hardware o un agente

Un id_rsa sin cifrar en ~/.ssh es una credencial portátil. Es preferible una clave que no pueda salir de un token hardware. La mayoría de las llaves de seguridad FIDO2 lo permiten con OpenSSH 8.2 o 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

Quita las claves antiguas de tu host de Git y de los servidores cuando la nueva funcione. Evita el agent forwarding hacia hosts de los que no te fíes del todo; usa ProxyJump en su lugar.

Hecho cuando: no queda ninguna clave privada sin cifrar y las claves públicas antiguas han desaparecido de todas las cuentas.

4. Firma de commits en Git

La firma permite que revisores y reglas de protección de ramas distingan tus commits de los de alguien que usa tu nombre en git config. Git admite claves SSH para firmar, así que puedes reutilizar la del paso 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

Sube la clave pública a tu host de Git como clave de firma y plantéate exigir commits firmados en las ramas protegidas.

Hecho cuando: los commits nuevos aparecen como verificados en el host de Git.

5. Tokens con mínimo privilegio

Los personal access tokens clásicos suelen tener todos los scopes del usuario, no caducan y funcionan en todos los repositorios. Sustitúyelos.

• Usa tokens de granularidad fina limitados a los repositorios y permisos que necesita una tarea.
• Fija una caducidad. Mejor corta que cómoda.
• Prefiere el flujo de login propio de la CLI, como gh auth login, que guarda las credenciales en el llavero.
• Para el acceso a la nube, usa sesiones SSO de corta duración en lugar de claves de acceso de larga duración en ~/.aws/credentials o ficheros similares.
• Dale a cada herramienta, script o asistente su propio token para poder revocar uno sin romper el resto.

Hecho cuando: ningún token en uso supera su política de caducidad y ninguno tiene más scope del que necesita su tarea.

Hazlo en equipo

Reserva una mañana, comparte esta tabla y que todo el mundo la trabaje junto. La tarde es para los rezagados y para convertir las comprobaciones en algo que tu gestión de dispositivos pueda reportar.

Dónde encaja en la línea

En la torre (en desarrollo):