Dar acceso SFTP a un equipo sin compartir una sola contraseña

La agencia comparte deploy@client.com / Summer2024! con cinco personas. Un profesional independiente se va: nadie cambia la contraseña "para no bloquear la producción". Seis meses después, la auditoría revela accesos fantasmas y archivos modificados sin autor identificable. Una contraseña compartida no es acceso de equipo, es una bomba de tiempo.

SFTP (Protocolo de transferencia de archivos SSH) cifra las transferencias y se basa en cuentas virtuales o del sistema. Buenas prácticas: un identificador por persona, permisos mínimos, revocación individual — alineado con la responsabilidad entre cliente y proveedor de servicios.

Modelo recomendado según hosting

Deshabilitar FTP de texto sin formato; forzar SFTP en el puerto SSH (22 o puerto personalizado documentado). Si el proveedor de alojamiento solo ofrece FTP heredado, cambie su oferta o cambie a VPS.

Permisos, chroot y privilegios mínimos

Un usuario SFTP solo debería ver lo que necesita modificar:

• Chroot o jailkit: el usuario sólo accede a /var/www/client.
• Solo lectura para un proveedor de servicios de auditoría; escribiendo para el integrador activo.
• Raíz nunca compartida: no proporciones el panel maestro del anfitrión al profesional independiente.
• Registros: verifique auth.log SSH y correlacione con los tickets de soporte.

En caso de sospecha de compromiso, siga el procedimiento de denuncia de abuso y rote las claves y secretos afectados.

Revocación e incorporación

Lista de verificación al salir de un proveedor de servicios:

1. Deshabilite la cuenta SFTP o elimine su clave pública.
2. Cambie los secretos que pudo ver (API, base de datos si accedió).
3. Revisar los archivos modificados recientemente (git log o fechas de modificación).
4. Actualizar la documentación interna de acceso autorizado.

A su llegada: cuenta individual, clave registrada, rutas autorizadas documentadas, no “lo mismo que todos los demás”.

La cumbre: la contraseña compartida es una deuda invisible

Esto es lo que no dicen las ofertas de “acceso FTP incluido” el día que un autónomo se marcha.

Compare las ofertas multicuenta y VPS en el directorio y en la comparación.

Decide y avanza sin puntos ciegos

En un día, puedes restablecer el acceso del equipo a una base saludable:

1. Inventario quién tiene acceso hoy y revocar inmediatamente cualquier cuenta genérica compartida.
2. Cree cuentas y claves individuales con permisos limitados a la carpeta del proyecto.
3. Cambie la implementación actual a Git y CI si el equipo lo permite; SFTP se convierte en la excepción.
4. Redactar un procedimiento de incorporación y baja de proveedores de servicios, con plazos y responsables.
5. Pruebe la revocación: desactive una cuenta de prueba y verifique que otros accesos sigan funcionando.

Para elegir un host que permita múltiples cuentas o un VPS adecuado, explore el directorio.

Preguntas frecuentes

¿SFTP o FTP para un equipo?

Sólo SFTP. Clear FTP está obsoleto y expone las credenciales en la red. FTPS rara vez sigue siendo necesario si la implementación de SFTP o Git está disponible.

¿Cómo despedir a un autónomo sin romperlo todo?

Con una cuenta dedicada, desactivas al usuario o eliminas su clave en claves_autorizadas. Los demás miembros del equipo continúan trabajando con normalidad.

¿El host compartido permite múltiples cuentas SFTP?

Depende de la oferta: verifique la cantidad de cuentas FTP/SFTP adicionales antes de firmar. De lo contrario, un VPS con usuarios separados ofrece más control.

¿Clave SSH o contraseña?

Prefiere una clave SSH por persona protegida por frase de contraseña. Se acepta una contraseña segura por cuenta como último recurso, nunca un único identificador para todo el equipo.

Si su equipo comparte una contraseña SFTP, la pregunta no es "si" tendrá un incidente, sino "cuándo" no sabrá quién es el responsable.