Baza de date ține datele clienților, comenzile și facturile pe care le raportezi la SFS. O bază expusă pe internet, cu parola de la instalare, e cel mai scurt drum către o notificare la CNPDCP și o discuție neplăcută cu clientul din UE.
Cele mai multe baze de date compromise nu au fost sparte, ci găsite. Un PostgreSQL pe 5432 sau un MySQL pe 3306 deschis către lume primește încercări de autentificare la câteva minute după pornire. Baza ascultă pe localhost dacă aplicația e pe același server, altfel pe adresa din rețeaua privată. Firewall-ul blochează portul dinspre exterior, ca a doua plasă, iar administratorul intră prin SSH sau VPN.
Aplicația nu are nevoie de superuser. Creează un rol de rulare cu SELECT, INSERT, UPDATE și DELETE pe schema ei și unul separat pentru migrări, folosit doar din pipeline. Un SQL injection dintr-un formular rămâne atunci limitat la tabelele aplicației, nu la toată instanța. Parolele lungi, generate, stau într-un manager de secrete. TLS între aplicație și bază pare exagerat în rețeaua privată, dar acoperă un vecin compromis pe același switch.
Un dump zilnic pierde până la 24 de ore de date: pentru un magazin din Chișinău, comenzi pierdute și facturi de refăcut. Arhivarea continuă a WAL în PostgreSQL, cu pgBackRest sau WAL-G, permite restaurarea la orice minut, de pildă dinaintea unui DELETE greșit; în MySQL, jurnalul binar face același lucru. Backupul pleacă criptat de pe server, iar restaurarea se repetă lunar pe o mașină curată.
Baza unui magazin, a unei clinici sau a unei firme de outsourcing conține date cu caracter personal. Legea nr. 195/2024, în vigoare din 23 august 2026, cere măsuri tehnice și organizatorice adecvate riscului și notificarea CNPDCP la o încălcare a securității, fără întârziere nejustificată și, unde e posibil, în cel mult 72 de ore. Clienții din UE cer prin contractul de prelucrare criptare, control al accesului și jurnalizare; rolurile și jurnalul de conexiuni sunt dovada.
| Aspect | PostgreSQL | MySQL / MariaDB | Ce previne |
|---|---|---|---|
| Unde ascultă | listen_addresses = 'localhost' sau IP privat | bind-address = 127.0.0.1 sau IP privat | descoperirea bazei din internet |
| Autentificare | scram-sha-256 în pg_hba.conf | MySQL 8: caching_sha2_password (implicit); MariaDB: ed25519 sau mysql_native_password | atacuri pe hash-uri slabe |
| Conturi privilegiate | postgres doar local, prin peer | fără 'root'@'%' | acces administrativ de la distanță |
| Criptare în tranzit | hostssl + ssl = on | require_secure_transport = ON | interceptare în rețea |
| Restaurare la moment | arhivare WAL cu pgBackRest / WAL-G | binlog + mysqlbinlog | pierderea unei zile de date |
CREATE ROLE magazin_app LOGIN PASSWORD 'parola-lunga-generata';
GRANT CONNECT ON DATABASE magazin TO magazin_app;
GRANT USAGE ON SCHEMA public TO magazin_app;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO magazin_app;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO magazin_app;# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer
hostssl magazin magazin_app 10.10.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
# în postgresql.conf: password_encryption = scram-sha-256, ssl = on# /etc/mysql/mysql.conf.d/mysqld.cnf
# aplicația pe ACELAȘI server: bind-address = 127.0.0.1
# aplicația pe ALT nod: bind-address = IP-ul din rețeaua privată (exemplul de mai jos)
bind-address = 10.10.0.10
require_secure_transport = ON
-- în consolă
DROP USER IF EXISTS 'root'@'%';
-- MySQL 8:
CREATE USER 'magazin_app'@'10.10.0.%' IDENTIFIED WITH caching_sha2_password BY 'parola-lunga-generata' REQUIRE SSL;
-- MariaDB nu are caching_sha2_password:
-- INSTALL SONAME 'auth_ed25519';
-- CREATE USER 'magazin_app'@'10.10.0.%' IDENTIFIED VIA ed25519 USING PASSWORD('parola-lunga-generata') REQUIRE SSL;
GRANT SELECT, INSERT, UPDATE, DELETE ON magazin.* TO 'magazin_app'@'10.10.0.%';MySQL asculta pe toate interfețele, cu root accesibil de oriunde, fiindcă dezvoltatorul se conecta de acasă. După legarea pe localhost, tunel SSH și un cont dedicat aplicației, încercările de autentificare din jurnal au dispărut.
Contractul de prelucrare cerea criptare în tranzit și restaurare la un moment dat. Echipa a trecut pe hostssl cu scram-sha-256 și pgBackRest cu arhivare WAL într-un bucket separat. Testul lunar de restaurare e acum o linie în raportul către client.
Aplicația folosea contul postgres, superuser, pentru tot, iar un plugin de raportare defect a putut citi tabelele de salarii. Acum fiecare modul are rolul lui, iar rapoartele rulează pe o replică de citire, doar pe schema de vânzări.
Criptarea la repaus acoperă furtul fizic al discului sau un snapshot copiat. Pe un VPS sau server dedicat în datacenter, riscul principal rămâne accesul logic, deci prioritatea sunt rețeaua, rolurile și backupul. Criptarea discului se adaugă după, mai ales dacă o cere contractul.
Doar în spatele VPN-ului sau al unui tunel SSH, niciodată pe un URL public. Panourile web de administrare sunt printre primele ținte scanate, iar un phpMyAdmin vechi a cauzat multe compromiteri. Alternativa e clientul local, prin tunel.
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.