Arriba un desenvolupador nou, o comença un col·laborador extern, i el
primer que necessita és el .env que fa funcionar el projecte. Aquest
fitxer acostuma a barrejar paràmetres inofensius amb els valors més
sensibles que té l'equip, i per això acaba tan sovint en un missatge
directe o en un adjunt de correu titulat «config».
Per lliurar de manera segura un fitxer de configuració a un desenvolupador, tracteu-lo com dues coses diferents: la configuració, que pot viatjar per on sigui, i els secrets, que viatgen una sola vegada per un canal que no en guarda còpies. Aquesta guia explica com separar-los, com enviar la part secreta i què heu de dir al desenvolupador perquè el fitxer continuï segur un cop arribi.
Llegiu el fitxer com si cada línia fos pública
Obriu el fitxer i classifiqueu cada línia en un de dos grups.
- Configuració: nivells de registre, ports, indicadors de funcions, punts d'accés que no són de producció, identificadors de client públics. Tot això va al repositori com a fitxer d'exemple i es pot enviar com vulgueu.
- Secrets: contrasenyes de bases de dades, claus d'API, secrets de
signatura, claus privades, secrets de client OAuth, qualsevol cosa
que doni accés. Cerqueu
PASSWORD,SECRET,TOKEN,KEYiPRIVATE, i després llegiu la resta, perquè una cadena de connexió amb la contrasenya a dins no ho anuncia.
Després pregunteu-vos què farà el desenvolupador. Per desenvolupar en local contra l'entorn de proves necessita els valors de proves. No necessita les claus de producció, ni la clau real del proveïdor de pagaments només perquè el fitxer en contingui una.
Deixeu els secrets fora del fitxer del repositori
El .env.example que es puja al repositori documenta cada variable
amb un valor provisional. Els valors reals s'injecten en temps
d'execució des de l'entorn, un gestor de secrets o el magatzem de
secrets de la mateixa plataforma. Amb aquest patró, el fitxer que
lliureu només conté els valors secrets, i la còpia local del
desenvolupador és l'únic lloc on són tots junts.
# .env.example (committed)
DATABASE_URL=postgres://app:CHANGE_ME@staging-db.internal:5432/app
STRIPE_SECRET_KEY=sk_test_CHANGE_ME
SESSION_SECRET=CHANGE_ME
LOG_LEVEL=debug
Afegiu .env a .gitignore abans que ningú en tingui un de real, i
penseu a posar un hook de pre-commit com gitleaks perquè un commit
despistat falli de seguida.
Doneu al desenvolupador credencials pròpies sempre que pugueu
Un lliurament també és una ocasió per deixar de compartir. Si la base de dades admet usuaris individuals, creeu-ne un per al desenvolupador amb els permisos que necessita la seva feina i una data de caducitat. Si l'API ofereix claus restringides, emeteu-ne una al seu nom. La guia d'accés a bases de dades per a col·laboradors externs explica aquest patró. Les credencials fetes per a una persona es poden retirar només a aquella persona.
Com lliurar els valors secrets
Hi ha dues vies que funcionen, i totes dues eviten que el fitxer quedi en un missatge.
Enganxeu les línies secretes en un enllaç d'un sol ús. Obriu
l'eina d'enllaços
secrets, enganxeu-hi només les
línies que contenen secrets i creeu l'enllaç. 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 l'enllaç caduca al cap d'una hora,
24 hores o set dies si ningú no l'obre. Sense compte hi caben fins a
10.000 caràcters: la majoria de fitxers .env hi caben diverses
vegades.
Adjunteu el fitxer sencer a un enllaç secret. Amb la sessió iniciada en un compte de LinkPilot podeu adjuntar fins a tres fitxers de 9 MB cadascun a un secret. Cada fitxer es xifra al vostre navegador amb una clau derivada de la clau del mateix secret, de manera que el servidor no té mai el fitxer sense xifrar, i l'adjunt se suprimeix després de l'única baixada. Aquesta és la millor via quan el fitxer ha d'arribar idèntic byte a byte, per exemple un fitxer JSON d'un compte de servei o un magatzem de claus.
En tots dos casos:
- Verifiqueu el desenvolupador pel canal de contractació o del contracte, no per l'adreça que ha demanat el fitxer.
- Definiu la caducitat segons el temps que de debò farà servir. Una hora si està esperant, un dia si és en una altra zona horària.
- Limiteu les visualitzacions a una.
- Afegiu una frase de contrasenya amb un compte Pro per als valors de producció, i envieu-la per un altre canal.
- Envieu l'enllaç amb una nota d'una línia que digui què és i on va el fitxer. Envieu la configuració no secreta a part, o remeteu al fitxer d'exemple del repositori.
Una invitació a la caixa forta és la millor via quan el desenvolupador és una incorporació fixa i l'equip ja fa servir un gestor de secrets amb accés per desenvolupador. Feu servir l'enllaç d'un sol ús mentre això no estigui configurat, i per a qui no hagi d'entrar mai a la caixa forta.
Expliqueu al desenvolupador on va el fitxer
Un lliurament net pot acabar malament igualment si el fitxer va a parar a una carpeta compartida. Envieu aquestes indicacions juntament amb les dades de connexió:
- Deseu-lo com a
.enva l'arrel del projecte i enlloc més. Comproveu que.gitignoreel cobreix abans del primer commit. - No enganxeu valors en tiquets ni al xat per preguntar si són correctes. Indiqueu una variable que falta o que no és vàlida només pel nom, i qui ha enviat el fitxer en generarà un valor nou.
- Rotació en acabar. Quan s'acabi l'encàrrec, els valors d'aquell fitxer es rotaran. Digueu-ho des del principi perquè no sorprengui ningú.
Confirmeu i després feu neteja
Demaneu al desenvolupador que us confirmi el nom del fitxer, l'entorn i una marca que no sigui secreta, com ara un comentari de versió a la primera línia. Si un enllaç d'un sol ús indica que s'ha obert abans que hi arribés, considereu exposats tots els valors que contenia i roteu-los.
Quan el lliurament s'hagi completat, revoqueu els enllaços que no s'hagin obert mai, suprimiu qualsevol còpia temporal que hàgiu fet i anoteu qui ha rebut els valors de quin entorn i quan. Aquest registre és el rastre d'auditoria. El fitxer només hauria d'existir a la màquina que el necessita.