Para operadores solos o de pequeña escala que gestionan varios servidores, sitios y dominios. Cuanto más hayas postergado hacer balance porque "funciona", más te aplica esto. Aquí no hay pasos de ataque — solo riesgos que puedes listar y borrar tú mismo.
Contar y reducir lo que tienes antes de añadir controles
El estado sin seguimiento es en sí un riesgo. Haz balance y normalmente encuentras:
1. Protege los PC que guardan claves y credenciales
Por mucho que endurezcas el servidor, si el PC que guarda tu clave privada SSH queda comprometido, queda expuesto cada servidor al que esa clave da acceso. Una vez que cambias a autenticación por clave, la frontera real de tu flota se mueve a "el PC que guarda la clave". Así que la prioridad no es "servidor → PC" sino "PC → servidor".
La comprobación de mayor valor: si .ssh está FUERA de una carpeta de sincronización en la nube (OneDrive/Drive/Dropbox). Si una clave privada vive por accidente bajo la sincronización, tu clave se filtra en el momento en que alguien toma el control de la cuenta de la nube — incluso sin tocar el PC. La mentalidad de privilegio mínimo para las claves está en claves SSH y privilegio mínimo.
2. Configura el 2FA por orden de prioridad: correo, luego dominio, luego facturación
"Añade 2FA a todo" nunca termina si empiezas de forma vaga. Ordena las cuentas según cuáles permiten recuperar las demás (raíz de confianza) y la prioridad queda clara.
| Nivel | Objetivo | Por qué es máxima prioridad |
|---|---|---|
| Nivel 0 | Cuenta de correo | Casi todos los servicios se recuperan vía "enlace de restablecimiento al correo" — toma el correo y los 2FA inferiores quedan eludidos |
| Nivel 1 | Control del dominio (registrador/DNS/hosting/plataforma de código) | El propio sitio puede ser secuestrado o sustituido |
| Nivel 2 | APIs de facturación (pagos / APIs de IA / envío de correo) | Lleva a pérdida financiera directa |
En la práctica: conserva los códigos de respaldo en papel (ponerlos en la nube reduce a la mitad el sentido del 2FA), y confirma que tu correo de recuperación sigue funcionando y está bajo tu control. Los pasos están en la guía de autenticación multifactor y en la lista de comprobación de la base de seguridad.
3. Anota qué clave SSH abre qué servidor
"Es autenticación por clave, así que es segura" no es gestión. Lo que de verdad necesitas es una tabla de "qué clave en qué PC abre qué servidor". Coteja el authorized_keys de cada servidor por huella digital y aparece lo invisible — claves duplicadas (la misma clave bajo dos nombres), claves sin usar (que no se usan en ningún sitio) y registros huérfanos (que quedaron de un propósito que ya no existe). authorized_keys es fácil de ampliar y fácil de olvidar de podar. Una tabla te permite preguntar, fila a fila, "¿para qué es esto?".
4. Corta los dispositivos sin soporte con el menor número de pasos
Una clave en un dispositivo cuyo SO ha llegado al fin de vida (EOL) es común. Ir a lo grande — "rotar cada clave y reconfigurar cada servidor" — es tan pesado que nunca lo haces.
Comprueba si hay cualquier señal de fuga
El recorte de menor esfuerzo = borra la clave del dispositivo
Pon la fecha de fin de soporte en un calendario
El truco: elige el recorte que de verdad puedas terminar hoy por encima de un procedimiento perfecto que dejas sin hacer.
5. Quita las contraseñas en texto plano de la nube
Antes del debate del gestor de contraseñas, hay un daño real mayor: una lista de contraseñas en texto plano metida en un documento de la nube. Si se filtra, todas las cuentas quedan expuestas a la vez.
Lista en texto plano (un documento de la nube)
- Si alguien toma el control de una cuenta, se filtra todo
- Pegarás a mano en un sitio falso
- Sin detección de brechas, sin autocompletado
Almacenamiento cifrado en el dispositivo
- El contenido está cifrado en tu dispositivo (el proveedor no puede leerlo)
- No autocompleta en un dominio falso = resistente al phishing
- Tras migrar, borra el texto plano para siempre
"Qué gestor es mejor" importa mucho menos que "¿quitaste el texto plano de la nube?" (→ cómo elegir un gestor de contraseñas / guardar contraseñas con seguridad).
6. Corrige un cambio cada vez, de forma reversible
Cuando el inventario saca a la luz problemas, querrás arreglarlos todos de golpe. En producción, cambiar varias cosas por impulso es la jugada más peligrosa. Las operaciones difíciles de deshacer — rotación de claves, cambios de configuración, despliegues a producción — deberían hacerse una a una, tras preparar una copia de seguridad completa y un procedimiento de restauración (es decir, hazlo reversible). No crees un problema nuevo con la propia corrección (→ copia de seguridad y recuperación).
7. Diseña el registro para que no contenga secretos
El registro de tus resultados se convierte en una lista de objetivos para los atacantes si se filtra. Así que traza la línea por adelantado.
Está bien escribir (no catastrófico si se filtra)
- Claves públicas, huellas digitales
- La estructura de tu configuración, si el 2FA está activado
- Resultados aprobado/fallido
Nunca escribas (una sola línea filtrada puede usarse para atacarte)
- Contenido de claves privadas
- Contraseñas, claves de API
- Códigos de restablecimiento reales
Las huellas digitales y las claves públicas solo identifican "qué clave" y no pueden abusarse por sí solas. Expresa tu estado usando solo información que no sea catastrófica si se filtra — y entonces el registro permanece seguro en la nube o compartido con un equipo.
La visión de este sitio: haz inventario antes de añadir herramientas
En este sitio nunca guardamos secretos (claves, contraseñas, datos de conexión) en texto plano — ni en documentos compartidos, ni en código — separamos las claves por propósito (para que una fuga no se extienda a nada más), y remediamos de forma reversible, una a una. Antes de añadir una nueva herramienta, convierte primero el "estado sin seguimiento" en "un estado listado". Es poco glamuroso, y aun así borra más riesgo que cualquier otra cosa.
Sigue leyendo
- Claves: claves SSH y privilegio mínimo
- Base: lista de comprobación de la base de seguridad · guía de autenticación multifactor
- Almacenamiento: cómo elegir un gestor de contraseñas
- Dónde están las cosas: buckets públicos (el inventario no son solo tus servidores)
- Lo que olvidaste borrar: la toma de subdominios y los registros DNS colgantes (lo retirado sigue siendo un activo hasta que se borra)
- La visión general: los errores habituales son fallos de suposición (por qué funciona el inventario)