Baza de date e locul unde stau datele clienților, facturile și parolele, deci ținta finală a oricărui atac. Cele mai multe scurgeri nu vin din exploit-uri sofisticate, ci dintr-un port deschis pe internet, un cont de aplicație superuser și o parolă veche.
Un server de baze de date nu are nevoie să fie accesibil de pe internet, nici cu parolă bună. Îl legi de adresa privată, iar administrarea de la distanță o faci prin tunel SSH sau VPN. Al doilea strat e autentificarea: pg_hba.conf spune cine se poate conecta, de unde, la ce bază și cum. Metodele trust și md5 pe rețea trebuie să dispară; scram-sha-256 e implicit din PostgreSQL 14, iar hostssl refuză conexiunile necriptate. În MySQL, echivalentul e bind-address, conturi pe host precis, nu pe %, și require_secure_transport = ON.
Cea mai frecventă greșeală e aplicația conectată ca postgres sau root, „ca să meargă migrările”. Când aplicația are un SQL injection, atacatorul are tot ce are contul: toate bazele, extensii, citire de fișiere de pe disc. Corect, creezi un rol pentru aplicație cu SELECT, INSERT, UPDATE, DELETE pe tabelele ei și un rol separat pentru migrări, folosit doar la deploy. Rolurile de raportare primesc doar SELECT. Fiecare rol are parola lui, rotită când cineva pleacă, ținută în managerul de secrete, nu în cod.
Baza de date e, aproape întotdeauna, locul unde stau datele personale, deci art. 32 GDPR se aplică direct: criptare, control al accesului, capacitate de restaurare. La o scurgere, ANSPDCP trebuie notificată în 72 de ore, iar prima întrebare e cine avea acces la date și cum. Pentru entitățile de sub OUG 155/2024, gestionarea accesului și backup-ul sunt măsuri minime explicite. Facturile emise prin e-Factura au termene legale de păstrare, deci backup-ul testat al bazei e obligație, nu opțiune.
| Control | PostgreSQL | MySQL / MariaDB |
|---|---|---|
| Adresa de ascultare | listen_addresses în postgresql.conf | bind-address în my.cnf |
| Cine se conectează, de unde | pg_hba.conf, o linie per rol și rețea | utilizator@host, fără % |
| Autentificare | scram-sha-256 | caching_sha2_password (implicit din 8.0) |
| Criptare în tranzit | ssl = on, hostssl în pg_hba.conf | require_secure_transport = ON |
| Backup logic + punct în timp | pg_dump + arhivare WAL (PITR) | mysqldump / mariabackup + binlog |
# postgresql.conf (fragment)
listen_addresses = '10.0.0.10'
password_encryption = scram-sha-256
ssl = on
log_connections = on
# pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer
hostssl app_db app_user 10.0.0.5/32 scram-sha-256
host all all 0.0.0.0/0 rejectCREATE ROLE app_user LOGIN PASSWORD 'parola-din-managerul-de-secrete';
GRANT CONNECT ON DATABASE app_db TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;# /etc/mysql/mysql.conf.d/mysqld.cnf (fragment)
[mysqld]
bind-address = 10.0.0.10
require_secure_transport = ON
local_infile = 0
-- în clientul mysql
DROP USER IF EXISTS 'root'@'%';
CREATE USER 'app'@'10.0.0.5' IDENTIFIED BY 'parola-din-managerul-de-secrete';
GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'app'@'10.0.0.5';
FLUSH PRIVILEGES;Aplicația rula ca postgres, iar un formular vulnerabil a permis un SQL injection care a citit toate schemele, inclusiv ale altor clienți. Fiecare tenant a primit apoi un rol propriu, aplicația a pierdut superuser, iar pg_hba.conf a trecut pe scram-sha-256 și hostssl.
Pentru un client desktop, cineva crease root@% și deschisese 3306 în firewall. Un scaner l-a găsit în câteva ore și a început brute force-ul. Contul a fost șters, bind-address setat pe adresa privată, iar accesul de la distanță s-a mutat pe tunel SSH.
Pe același server, prin socket Unix sau 127.0.0.1, traficul nu părăsește mașina, deci TLS e opțional. Când baza de date e pe alt server, chiar în aceeași rețea privată, TLS devine obligatoriu: rețeaua furnizorului e partajată și o greșeală de configurare o expune.
pg_dump îți dă starea de la ora la care a rulat; tot ce s-a întâmplat după se pierde. PITR, recuperarea la un punct în timp, folosește arhiva WAL, sau binlog-ul în MySQL, ca să reconstruiești baza la minutul dinaintea unui DELETE greșit. Le folosești împreună.
Criptarea discului te protejează de furtul fizic sau de un disc scos din rotație, nu de un atacator conectat la baza care rulează. Pentru coloane sensibile, CNP sau date de plată, criptarea la nivel de aplicație, cu chei în afara bazei, e stratul care contează.
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.