Un colaborador externo que tiene que arreglar una importación, optimizar una consulta o migrar una tabla suele necesitar un acceso a la base de datos para hacerlo. El riesgo rara vez es el colaborador. Es el propio acceso: creado con prisas, más amplio que la tarea, pegado en un correo y todavía activo seis meses después de pagar la factura.
La solución es una rutina corta. Decide si de verdad hace falta acceso directo, crea un usuario limitado que ya tenga fecha de fin, envía la contraseña con un enlace secreto de un solo uso en lugar de un mensaje que guarda copias, protege la ruta de red y cierra la cuenta cuando termine el trabajo. Esta guía recorre cada paso, con los comandos exactos donde ayudan.
¿Necesita el colaborador acceso directo a la base de datos?
Empieza por la tarea, no por la petición. «Arreglar la importación» puede significar leer una tabla o tener acceso de escritura a medio esquema. Pregunta qué operación, qué entorno y qué tablas, y luego busca una forma más barata de darle eso.
- Una base de datos de staging con una copia reciente y anonimizada cubre la mayoría de los trabajos de diagnóstico y migración sin exponer registros reales de clientes.
- Una API de la aplicación o de administración suele bastar cuando el colaborador tiene que cambiar datos y no el esquema.
- Una réplica de lectura da a los trabajos de análisis de solo lectura un sitio donde ejecutarse sin tocar la base principal.
Si nada de eso encaja y el acceso a producción es inevitable, escribe una nota de una línea con el motivo. Esa nota será la justificación cuando alguien audite el acceso más adelante.
Crea un usuario limitado que ya tenga expiración
Nunca entregues un acceso compartido ni las credenciales de un empleado. Un usuario dedicado es lo que te permite ver lo que hizo el colaborador, restringir lo que puede alcanzar y retirarlo sin afectar a nadie más. Fija la expiración del usuario al crearlo, para que el acceso termine aunque se te olvide.
En PostgreSQL, un usuario que solo puede leer dos tablas y deja de funcionar en una fecha fija se crea así:
CREATE ROLE contractor_jo LOGIN PASSWORD 'generated-elsewhere'
VALID UNTIL '2026-11-08 18:00+00';
GRANT CONNECT ON DATABASE app TO contractor_jo;
GRANT USAGE ON SCHEMA public TO contractor_jo;
GRANT SELECT ON orders, order_items TO contractor_jo;
MySQL tiene CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY, y los servicios gestionados como RDS, Cloud SQL y Supabase permiten hacer lo mismo desde sus consolas o con tokens de corta duración basados en IAM. Usa lo que admita tu plataforma, y genera la contraseña con un gestor de contraseñas en lugar de inventarla.
Concede los permisos mínimos para completar la tarea concreta. En un trabajo de diagnóstico, eso es SELECT sobre tablas específicas. En una migración, acceso de escritura a los objetos que van a cambiar y a nada más. Los roles de propietario y de superusuario nunca son la respuesta correcta para una cuenta temporal.
Cómo enviar un acceso temporal a una base de datos a un colaborador externo
La contraseña es la única parte de la entrega que tiene que mantenerse en secreto. El host, el puerto, el nombre de la base de datos y el usuario le sirven a un atacante, pero no le bastan, así que pueden ir en un mensaje normal. Mantén separadas las dos cosas.
- Verifica al destinatario por un canal en el que ya confíes, como el hilo de correo del contrato o una llamada. Las direcciones que imitan a otras son una forma habitual de que una credencial acabe en el buzón equivocado.
- Crea un enlace secreto de un solo uso que contenga solo la contraseña. Con LinkPilot, el texto se cifra en tu navegador antes de guardarse, la copia almacenada se destruye la primera vez que se abre el enlace y puedes elegir una expiración de una hora, 24 horas o siete días. Las cuentas Pro pueden fijar una expiración a medida, añadir una frase de contraseña y ver en un historial de auditoría cuándo se abrió el enlace.
- Envía el enlace en el hilo habitual, con una nota de una línea que diga para qué es y cuándo expira. No incluyas el nombre de usuario en el mismo mensaje que el enlace.
- Envía los datos de conexión por separado: host, puerto, base de datos, usuario y si se exige TLS. Vale un segundo correo o un comentario en un ticket, porque nada de eso es secreto por sí solo.
- Comunica la frase de contraseña por otro canal si has puesto una, por ejemplo por SMS o en una llamada.
- Pide al colaborador que confirme que el enlace se abrió. Si dice que ya se ha visto y él no lo abrió, da la contraseña por expuesta y cámbiala.
La función de compartir de un gestor de contraseñas es una alternativa razonable cuando el colaborador ya está en tu bóveda. Para un encargo puntual, un enlace de un solo uso evita crear una cuenta solo para entregar un valor. La guía enlaces secretos frente a gestores de contraseñas explica cuándo encaja cada uno.
Protege la conexión
Un usuario bien limitado en un puerto abierto sigue siendo un problema. Tres controles cierran la mayor parte del hueco.
- Exige TLS en la conexión y pide al colaborador que configure
sslmode=requireo su equivalente en el cliente. Muchos clientes pasan a texto sin cifrar sin avisar si no lo exiges. - Restringe el origen con una lista de IP permitidas, una VPN o un bastión. Permitir la dirección del colaborador mientras dure el trabajo se configura rápido y se quita rápido.
- Comparte solo lo que necesita la tarea. El colaborador no necesita el diagrama de la red interna, las demás bases de datos del servidor ni la URL de la consola de administración.
Si tu plataforma ofrece tokens IAM de corta duración en lugar de contraseñas fijas, suele ser la mejor opción, y elimina por completo la entrega de la contraseña.
Vigila la cuenta y ciérrala
Activa el registro de autenticación y de consultas del nuevo usuario antes de que empiece el trabajo, para poder comparar lo que pasó con lo acordado. Los inicios de sesión a horas raras o las consultas a tablas que no tienen que ver con la tarea merecen una pregunta, no una acusación.
Cuando termine la tarea, o cambie su alcance, haz cuatro cosas ese mismo día:
- Elimina o desactiva el usuario y confirma que ya no puede conectarse.
- Quita el permiso de red que añadiste para el colaborador.
- Cambia cualquier secreto que viajara junto con el acceso, por ejemplo una contraseña de la aplicación que estuviera en el mismo ticket.
- Deja constancia de la entrega: quién tuvo acceso, a qué, desde cuándo hasta cuándo y por qué. Guarda el registro, no la contraseña.
Un acceso temporal limitado, con expiración, entregado una sola vez y cerrado a tiempo no es una excepción de seguridad. Es simplemente como debería funcionar el acceso de los colaboradores externos.