Cheia de la procesatorul de plăți, parola bazei de date, tokenul către API-ul SFS: toate trăiesc într-un .env pe undeva. Problema nu este fișierul, ci drumul lui: prin git, prin imaginea Docker, prin chat-ul echipei, către oameni care nu ar trebui să îl vadă.
Traseul obișnuit: un dezvoltator copiază .env în repo ca să pornească proiectul mai repede pe alt laptop. Repository-ul este privat, deci pare inofensiv. Peste un an, repo-ul devine public pentru un portofoliu, sau un fost coleg îl are clonat, sau o cheie de CI cu acces la tot codul se scurge. Al doilea traseu este imaginea Docker: o valoare pusă în ENV sau ARG rămâne în straturi și se citește cu o comandă din registry. Al treilea este chat-ul: cheia lipită într-un mesaj rămâne căutabilă ani.
Când un secret a ajuns într-un commit, primul pas nu este ștergerea lui, ci generarea unuia nou și invalidarea celui vechi la furnizor. Git păstrează fiecare versiune; un git rm nu schimbă nimic pentru cine a clonat sau pentru boții care scanează platformele de cod în minute. Abia după rotație rescrii istoricul cu git filter-repo, forțezi push-ul și anunți echipa să recloneze. Pentru clienții din UE, o cheie scursă care dă acces la date personale poate fi o breșă de raportat conform contractului.
La build, dacă ai nevoie de un token pentru un registry privat de pachete, folosește RUN --mount=type=secret: fișierul este disponibil doar în acea comandă și nu ajunge în niciun strat. La rulare, în Docker Compose sau Swarm folosește secrets, care montează valorile ca fișiere în /run/secrets, sau injectează variabilele din platforma de orchestrare. În CI, secretele stau în seiful platformei, mascate în jurnale, disponibile doar job-urilor care le cer. Pentru echipe cu mulți clienți, un manager de secrete cu audit și rotație elimină fișierele .env de pe laptopuri.
| Loc de stocare | Risc principal | Verdict |
|---|---|---|
| Fișier .env în repo | rămâne în istoric pentru totdeauna | niciodată |
| ENV sau ARG în Dockerfile | citibil din straturile imaginii | niciodată |
| .env pe server, permisiuni 600, în afara repo-ului | citibil de oricine cu acces la cont | acceptabil pentru un singur server |
| Secretele platformei de CI | job-uri cu acces prea larg | bun, cu restricție pe mediu |
| Docker secrets sau /run/secrets | montare accidentală în alt container | bun |
| Manager de secrete cu audit și rotație | un singur punct de configurat corect | recomandat pentru echipe |
printf '.env\n.env.*\n!.env.example\n*.pem\n*.key\n' >> .gitignore
gitleaks detect --source . --redact
gitleaks git --log-opts='--all' --redact# Dockerfile
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci --ignore-scripts
# build
docker build --secret id=npmrc,src=$HOME/.npmrc -t exemplu.md/app:1.4.0 .services:
app:
image: exemplu.md/app:1.4.0
secrets: [db_password]
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
file: ./secrets/db_password.txtUn proiect vechi a fost publicat ca exemplu de portofoliu. În istoricul lui, un .env cu cheia de producție a procesatorului de plăți al clientului. Boții l-au găsit în minute. Rotația a durat o oră; explicația către client, mai mult.
Tokenul către serviciul de facturare electronică era în ENV în Dockerfile. Imaginea stătea în registry-ul intern, accesibil tuturor dezvoltatorilor și unui fost contractor. A fost mutat în Docker secrets și rotit, iar accesul la registry a fost restrâns.
Pentru un singur server cu o echipă mică, da, cu permisiuni 600 și proprietar contul aplicației. Devine insuficient când ai mai multe servere, mai mulți oameni sau un client care cere audit: atunci nu mai poți răspunde cine a văzut ce și când s-a schimbat.
Prin managerul de secrete al echipei sau prin platforma de CI, unde colegul primește acces la valoarea de care are nevoie, cu jurnal. Dacă nu ai niciunul, criptează fișierul cu age sau SOPS către cheia lui publică și trimite fișierul criptat, nu valoarea.
Acest ghid adună într-un singur loc măsurile care contează pentru un server de producție al unei firme din Moldova: de la cheia SSH până la copia de backup pe care nimeni nu o poate șterge. Fiecare capitol trimite la o pagină de întrebare cu pași, comenzi și exemple. Este scris pentru echipe care livrează clienților din UE, raportează la instituții locale sau vând online și nu își permit o zi de indisponibilitate.