Un col·laborador extern que ha d'arreglar una importació, afinar una consulta o migrar una taula normalment necessita un accés a la base de dades per fer-ho. El risc poques vegades és el col·laborador. És l'accés en si: creat amb presses, més ampli que la tasca, enganxat en un correu i encara actiu sis mesos després d'haver pagat la factura.
La solució és una rutina curta. Decidiu si realment cal accés directe, creeu un usuari limitat que ja tingui data de finalització, envieu la contrasenya amb un enllaç secret d'un sol ús en lloc d'un missatge que en guarda còpies, protegiu el camí de xarxa i tanqueu el compte quan s'acabi la feina. Aquesta guia repassa cada pas, amb les ordres exactes allà on són útils.
El col·laborador necessita accés directe a la base de dades?
Comenceu per la tasca, no per la petició. «Arreglar la importació» pot voler dir llegir una taula o pot voler dir escriure a mig esquema. Pregunteu quina operació, quin entorn i quines taules hi intervenen, i després busqueu una manera menys arriscada de donar-ho.
- Una base de dades de proves amb una còpia recent i anonimitzada cobreix la majoria de feines de diagnòstic i de migració sense exposar registres reals de clients.
- Una API de l'aplicació o d'administració sovint és suficient quan el col·laborador ha de canviar dades i no l'esquema.
- Una rèplica de lectura dona a les anàlisis de només lectura un lloc on executar-se sense tocar la base de dades principal.
Si no n'hi ha cap que encaixi i l'accés a producció és inevitable, escriviu en una línia per què. Aquesta nota serà la justificació quan algú auditi l'accés més endavant.
Creeu un usuari limitat i que ja tingui caducitat
No lliureu mai un accés compartit ni les credencials d'un treballador. Un usuari dedicat és el que us permet veure què ha fet el col·laborador, restringir a què pot arribar i suprimir-lo sense afectar ningú més. Definiu la caducitat de l'usuari en el moment de crear-lo, perquè l'accés s'acabi encara que us n'oblideu.
A PostgreSQL, un usuari que només pot llegir dues taules i que deixa de funcionar en una data fixa és així:
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 té CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY, i els
serveis gestionats com RDS, Cloud SQL i Supabase permeten fer el
mateix des de les seves consoles o amb testimonis de curta durada
basats en IAM. Feu servir el que admeti la vostra plataforma i genereu
la contrasenya amb un gestor de contrasenyes en lloc d'escriure'n una
a mà.
Atorgueu el conjunt mínim de permisos que permeti acabar la tasca
concreta. Per a una feina de diagnòstic, això vol dir SELECT sobre
taules concretes. Per a una migració, vol dir escriptura als objectes
que canviaran i res més. Els rols de propietari i de superusuari no
són mai la resposta adequada per a un compte temporal.
Com enviar un accés temporal a una base de dades a un col·laborador extern
La contrasenya és l'única part del lliurament que ha de continuar sent secreta. L'amfitrió, el port, el nom de la base de dades i el nom d'usuari són útils per a un atacant, però no suficients, de manera que poden viatjar en un missatge normal. Mantingueu-los separats.
- Verifiqueu el destinatari per un canal en què ja confieu, com ara el fil de correu del contracte o una trucada. Sovint una credencial acaba a la bústia equivocada per culpa d'una adreça que s'assembla a la real.
- Creeu un enllaç secret d'un sol ús que contingui només la contrasenya. Amb LinkPilot, el text es xifra al vostre navegador abans de desar-se, la còpia desada es destrueix la primera vegada que s'obre l'enllaç, i podeu triar una caducitat d'una hora, 24 hores o set dies. Els comptes Pro poden definir una caducitat personalitzada, afegir una frase de contrasenya i veure una cronologia d'auditoria de quan s'ha obert l'enllaç.
- Envieu l'enllaç pel fil habitual, amb una nota d'una línia que digui per a què serveix i quan caduca. No poseu el nom d'usuari al mateix missatge que l'enllaç.
- Envieu les dades de connexió per separat: amfitrió, port, base de dades, nom d'usuari i si cal TLS. Un segon correu o un comentari en un tiquet ja va bé, perquè cap d'aquestes dades no és secreta per si sola.
- Passeu la frase de contrasenya per un altre canal si n'heu definit una, per exemple per SMS o en una trucada.
- Demaneu al col·laborador que confirmi que l'enllaç s'ha obert. Si us diu que l'enllaç ja consta com a vist sense haver-lo obert, considereu la contrasenya exposada i roteu-la.
La funció de compartir d'un gestor de contrasenyes és una alternativa raonable quan el col·laborador ja és a la vostra caixa forta. Per a un encàrrec puntual, un enllaç d'un sol ús evita crear un compte només per lliurar un valor. La guia enllaços secrets o gestors de contrasenyes explica quan encaixa cadascun.
Protegiu la connexió
Un usuari ben limitat en un port obert continua sent un problema. Tres controls tanquen la major part de l'escletxa.
- Exigiu TLS a la connexió i digueu al col·laborador que configuri
sslmode=requireo l'equivalent al seu client. Molts clients tornen al text sense xifrar sense avisar si no ho exigiu. - Restringiu l'origen amb una llista d'IP permeses, una VPN o un servidor bastió. Permetre l'adreça del col·laborador mentre dura la feina és ràpid de configurar i ràpid de treure.
- Compartiu només el que necessita la tasca. El col·laborador no necessita el diagrama de la xarxa interna, les altres bases de dades del servidor ni l'URL de la consola d'administració.
Si la vostra plataforma ofereix testimonis IAM de curta durada en lloc de contrasenyes estàtiques, normalment és la millor opció, i elimina del tot el lliurament de la contrasenya.
Vigileu el compte i tanqueu-lo
Activeu el registre d'autenticacions i de consultes del nou usuari abans que comenci la feina, perquè pugueu comparar el que ha passat amb el que s'havia acordat. Els inicis de sessió a hores estranyes o les consultes a taules que no hi tenen res a veure mereixen una pregunta, no una acusació.
Quan s'acabi la tasca, o en canviï l'abast, feu quatre coses el mateix dia:
- Suprimiu o desactiveu l'usuari i comproveu que ja no es pot connectar.
- Traieu el permís de xarxa que hi havíeu afegit.
- Roteu qualsevol secret que hagi viatjat amb l'accés, per exemple una contrasenya de l'aplicació que era al mateix tiquet.
- Deixeu constància del lliurament: qui ha tingut accés, a què, des de quan i fins a quan, i per què. Guardeu el registre, no la contrasenya.
Un accés temporal limitat, amb caducitat, lliurat una sola vegada i tancat a temps no és cap excepció de seguretat. És, simplement, com hauria de funcionar l'accés dels col·laboradors externs.