Ghid de securitate · România

Cum gestionez secretele (.env, chei API, parole) în producție fără să ajungă în git?

O cheie API ajunsă într-un commit e publică din momentul push-ului: boții scanează depozitele noi în minute. Ștergerea din repo nu o retrage, pentru că istoricul git și forkurile o păstrează. Singura reparație e rotirea.

Actualizat la

Răspuns scurt

  1. Gestionezi secretele ținându-le în afara codului: .env e în .gitignore, iar valorile reale stau în variabilele de mediu ale platformei CI și ale serverului.
  2. În Docker nu pui secrete în ARG sau ENV din Dockerfile, pentru că rămân în straturile imaginii; folosești Docker secrets sau --mount=type=secret.
  3. Scanezi fiecare commit cu gitleaks în pre-commit și în CI, ca un secret să nu ajungă în istoric.
  4. Dacă un secret a ajuns totuși în git, îl rotești imediat și abia apoi rescrii istoricul cu git filter-repo.
Prima acțiune după o scurgere
rotirea secretului, nu ștergerea din repo
Unde NU pun secretele în Dockerfile
ARG și ENV, rămân în straturile imaginii
Termen GDPR pentru notificarea unei breșe
72 de ore către ANSPDCP

De ce ștergerea din repo nu rezolvă nimic

Git păstrează fiecare versiune a fiecărui fișier. Un commit care șterge .env lasă versiunea anterioară accesibilă prin istoric, în orice clonă, fork sau oglindă. Scanerele atacatorilor extrag chei de cloud, token-uri de plăți și parole de baze de date din commit-uri noi în minute. Chiar și într-un depozit privat, oricine a avut acces vreodată are o copie. Ordinea e fixă: întâi rotești secretul, apoi cureți istoricul cu git filter-repo, apoi cauți cauza.

Unde stau secretele în fiecare mediu

Local, în .env, ignorat de git, cu un .env.example commitat care listează cheile fără valori. În CI, în variabilele secrete ale platformei, mascate în loguri. Pe server, într-un EnvironmentFile systemd cu permisiuni 600 sau într-un manager de secrete citit la pornire. În Docker, un secret scris în ENV apare în docker inspect și în orice strat al imaginii; îl montezi ca fișier prin Docker secrets sau, la build, prin --mount=type=secret.

Ce spune legislația din România

O cheie scursă care dă acces la date personale e o breșă de securitate în sensul GDPR: art. 33 cere notificarea ANSPDCP în 72 de ore de la constatare, iar art. 32 cere măsurile tehnice care ar fi prevenit-o. Un token de acces la SPV sau certificatul pentru e-Factura scurs înseamnă că un terț poate consulta sau emite facturi în numele firmei tale. Pentru entitățile înregistrate la DNSC sub OUG 155/2024, gestionarea criptografiei și a accesului e printre măsurile cerute de art. 11 din OUG 155/2024.

Unde stă un secret în fiecare mediu și ce e interzis
MediuLocul corectInterzis
Local, dezvoltare.env ignorat de git, .env.example fără valoriValori reale în .env.example sau în cod
CI/CDVariabile secrete ale platformei, mascate în loguriSecrete în fișierele de pipeline din repo
Docker build--mount=type=secretARG sau ENV cu valori secrete
Docker runtimeDocker secrets montate ca fișierENV în Dockerfile sau în docker-compose commitat
EchipăVault, SOPS + age, managerul platformeiChat, e-mail, documente partajate

Comenzi și configurări

.gitignore și scanare înainte de commit
# .gitignore
.env
.env.*
!.env.example

# pre-commit
gitleaks protect --staged --redact
Docker: secret la build, fără urmă în imagine
# Dockerfile
RUN --mount=type=secret,id=npm_token \
    NPM_TOKEN=$(cat /run/secrets/npm_token) npm ci --omit=dev --ignore-scripts

# build
docker build --secret id=npm_token,src=./npm_token.txt -t exemplu.ro/app .
systemd: fișier de mediu cu permisiuni restrictive
# /etc/exemplu/app.env (chmod 600, owner root)
DATABASE_URL=postgres://app:...@127.0.0.1/exemplu_db

# în unitatea systemd
EnvironmentFile=/etc/exemplu/app.env

Exemple practice

Agenție web din Timișoara

Un dezvoltator a commitat .env cu cheia de producție a unui procesator de plăți într-un depozit public de portofoliu. În câteva ore apăruseră încercări de tranzacții din alte țări. Cheia a fost rotită imediat; istoricul, curățat după.

Firmă de contabilitate din București cu integrare e-Factura

Token-ul de acces la SPV era scris în ENV în Dockerfile și a ajuns în registrul de imagini al firmei, accesibil tuturor angajaților. A fost mutat în Docker secrets și rotit, iar accesul la registru a fost restrâns.

Greșeli frecvente

  • Crezi că ai rezolvat problema când ștergi .env din repo, deși secretul rămâne în istoric și trebuie rotit.
  • Pui secrete în ARG sau ENV în Dockerfile și le trimiți în registrul de imagini la fiecare push.
  • Folosești aceeași cheie în toate mediile și proiectele.

Cum te ajută 4hosting

  • Serviciul Hardening & Compliance acoperă explicit accesul, secretele și cheile: mutarea lor din cod în managerul de secrete și rotire programată.
  • Serviciul CI/CD & Monitoring configurează pipeline-uri cu secrete în platformă și scanare gitleaks; Docker & Kubernetes construiește imagini fără secrete în straturi.
  • Orele de DevOps incluse lunar, 1–8 la VPS și 10 la dedicate și GPU, se cer din panoul de client, secțiunea „Servicii DevOps”; un audit al secretelor intră de obicei în cotă.

Întrebări conexe

  • Am pus o cheie API pe GitHub. Ce fac acum, în ordine?

    Rotești cheia la furnizor și verifici imediat jurnalul de utilizare pentru acțiuni străine. Apoi rescrii istoricul cu git filter-repo și forțezi push-ul, anunțând colaboratorii să recloneze. La final adaugi gitleaks în pre-commit și în CI. Dacă cheia dădea acces la date personale, evaluezi obligația de notificare.

  • Variabilele de mediu sunt sigure pe server?

    Sunt acceptabile dacă fișierul din care vin are permisiuni 600 și e deținut de root, iar procesul rulează sub un utilizator dedicat. Rămân vizibile în /proc pentru root și în crash dump-uri. Pentru secrete critice, un manager de secrete cu citire la pornire și audit e mai bun.

  • Ce e diferit între Docker secrets și ENV?

    ENV e scris în metadatele imaginii și ale containerului, vizibil prin docker inspect și în orice strat al imaginii. Docker secrets montează secretul ca fișier în memorie, în /run/secrets, doar în containerele care îl declară, fără să apară în imagine sau în loguri.

Cere o verificare de securitate

Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.