Guías de seguridad
Inventario de seguridad — 7 comprobaciones que pasan por alto quienes operan varios servidores
Inventario de seguridad en 7 puntos para operadores solos y pequeños: audita el PC que guarda tus claves, escalona el 2FA, haz una matriz de tus claves SSH y elimina las contraseñas en texto plano. Riesgos que borras con solo listarlos.
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 recortar" antes de "añadir"
El estado sin seguimiento es en sí un riesgo. Haz balance y normalmente encuentras:
1. Defiende el "PC con las claves", no el "servidor"
Por mucho que endurezcas el servidor, si el PC que guarda tu clave privada SSH queda comprometido, todo se abre. 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 cae 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. Escalona el 2FA por la "raíz de confianza"
"Añade 2FA a todo" nunca termina si empiezas de forma vaga. Escalónalo por la cadena de control (raíz de confianza) y la prioridad se decide sola.
| 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 |
Las claves prácticas: 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 está vivo y 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. Las claves SSH no están "gestionadas" hasta que las pones en una matriz
"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 matriz te permite preguntar, fila a fila, "¿para qué es esto?".
4. Dispositivos EOL: el recorte de menor esfuerzo, sopesado por esfuerzo vs riesgo
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 el precipicio 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. Fíltrala y es pérdida total instantánea.
Lista en texto plano (un documento de la nube)
- Una cuenta que cae 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. Remedia "de forma reversible, una a una"
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 abras un nuevo agujero con la propia remediació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 un mapa de ataque 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 línea lo convierte en arma)
- 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: inventario antes que suma
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 (una fuga no se encadena = radio de la explosión mínimo), 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
FAQ
Q¿Qué es un inventario de seguridad?
Antes de 'añadir' nuevos controles, listas las claves, cuentas, dispositivos y registros que ya tienes, encuentras los innecesarios o peligrosos, y los reduces. Para operadores solos/pequeños, los incidentes vienen menos de un cortafuegos o WAF ausente que de estado sin seguimiento — '¿qué clave en qué PC abre qué servidor?', '¿está el 2FA activado o no?'. Un inventario borra eso.
Q¿Por dónde empiezo?
El orden es PC → servidor. Una vez que usas SSH basado en claves, la frontera real se mueve del servidor al PC que guarda la clave. Primero audita la salud del PC que guarda las claves (especialmente si .ssh está FUERA de una carpeta de sincronización en la nube), luego el 2FA y los códigos de respaldo de tu cuenta de correo, y luego el inventario de claves SSH.
Q¿Es seguro conservar un registro de los resultados?
Lo es si trazas la línea en el contenido. Las claves públicas, las huellas digitales, la estructura de tu configuración, si el 2FA está activado y los resultados aprobado/fallido se pueden escribir (ninguno es secreto). Pero nunca escribas el contenido de una clave privada, una contraseña, una clave de API ni un código de restablecimiento real — ni una sola línea. Expresa tu estado usando solo información que no sea catastrófica si se filtra, y el registro nunca se convertirá en un mapa de ataque.