Ghid de securitate pentru serverul de producție în România (2026)

Toate întrebările

• De ce nu trebuie lăsate fișierele npm (node_modules) pe serverul de producție?
• Cum protejez un site WordPress de atacuri?
• Ce este un atac DDoS și cum îmi protejez serverul de el?
• Cum securizez accesul SSH la un server Linux?
• Cum configurez firewall-ul pe un VPS și ce porturi trebuie să las deschise?
• Cum fac backup corect la un server și cum testez restaurarea (regula 3-2-1)?
• Cum instalez HTTPS gratuit cu Let's Encrypt și cum activez HSTS pe server?
• Ce este un WAF (Web Application Firewall) și când am nevoie de el?
• Cum gestionez secretele (.env, chei API, parole) în producție fără să ajungă în git?
• Cum securizez containerele Docker în producție?
• Cum actualizez serverul Linux cu patch-uri de securitate fără să opresc producția?
• Cum securizez baza de date PostgreSQL sau MySQL în producție?
• Cum monitorizez serverul de producție: ce loguri și ce alerte am nevoie?
• Ce fac dacă serverul a fost compromis?
• Cum securizez serverul de e-mail cu SPF, DKIM și DMARC?
• Ce headere de securitate HTTP configurez în nginx?
• Cum configurez un VPN WireGuard pentru accesul administrativ la server?
• Cum gestionez utilizatorii și sudo pe server după principiul privilegiului minim?
• Ce obligații legale de securitate cibernetică are firma mea în România?
• Cum securizez contul cPanel pe un hosting partajat?

Cum securizezi un server, pas cu pas

1. Închizi accesul administrativ

   Treci SSH pe chei ed25519, interzici root și parolele, restrângi conturile cu AllowUsers și pui fail2ban. Consola furnizorului rămâne calea de rezervă, nu parola.

2. Reduci suprafața expusă

   Firewall cu refuz implicit, doar 22, 80 și 443 spre internet, HTTPS cu Let's Encrypt și HSTS. Baza de date și panourile interne ascultă pe localhost sau pe rețeaua privată, prin VPN.

3. Livrezi aplicația din CI, nu de pe server

   Build reproductibil din lockfile, scanare de dependențe în pipeline, imagini Docker multi-stage fără npm sau compilatoare în runtime, secrete în afara codului și a imaginii.

4. Întărești aplicația și containerele

   Actualizări la zi, WAF cu reguli OWASP în fața aplicației, containere non-root cu capabilități eliminate și sistem de fișiere read-only, verificate cu CIS Docker Benchmark.

5. Faci backup pe care l-ai restaurat

   Regula 3-2-1 plus o copie imutabilă, criptare la sursă, cheia păstrată separat și o restaurare de test lunară pe o mașină curată, cu RPO și RTO măsurate.

6. Monitorizezi și știi ce faci la incident

   Loguri centralizate, alerte pe autentificări, trafic și expirări de certificat, plan de răspuns scris, cu responsabili și termenele de notificare către DNSC și ANSPDCP.

Identitate și acces

Aproape orice compromitere de server începe cu un acces legitim folosit greșit: o parolă ghicită, o cheie partajată, un cont uitat. Controlul accesului e primul strat.

• SSH doar cu chei ed25519; PasswordAuthentication no și PermitRootLogin no în sshd_config
• Un cont per om, escaladare prin sudo, ștergerea cheii în ziua în care cineva pleacă
• Acces la servicii interne doar prin VPN WireGuard, nu prin porturi publice

Rețea și expunere

Tot ce ascultă pe o interfață publică va fi găsit de scanere în minute. Regula e simplă: refuzi implicit, permiți explicit și verifici cu ss -tulpn ce ascultă efectiv.

• ufw default deny incoming; allow doar 22 cu rate limiting, 80 și 443
• Baza de date pe 127.0.0.1 sau rețea privată; acces remote prin tunel SSH
• Porturile Docker publicate pe 127.0.0.1, pentru că -p fără adresă ocolește firewall-ul
• Protecție DDoS L3/L4 la furnizor, pentru că firewall-ul local nu poate absorbi trafic volumetric

Aplicație și lanț de aprovizionare

Codul tău e o fracțiune din ce rulează pe server; restul sunt dependențe, plugin-uri și imagini de bază scrise de alții. Controlezi ce intră și când.

• Actualizări de securitate aplicate în ziua publicării, după backup
• Build în CI din package-lock.json; pe server doar artefacte, fără npm și devDependencies
• npm ci --omit=dev --ignore-scripts dacă totuși instalezi pe server; scripturi de instalare permise individual
• Imagini Docker minimale, fixate pe digest, scanate cu Trivy înainte de push

Date, backup și criptare

Un backup e o măsură de securitate doar după ce l-ai restaurat cu succes pe o mașină curată. Ransomware-ul caută întâi serverul de backup, deci o copie trebuie să fie în afara rețelei.

• Regula 3-2-1-1-0: trei copii, două suporturi, una offsite, una imutabilă, zero erori la test
• Criptare la sursă cu restic sau borg; cheia în alt loc decât copiile
• Secrete în afara codului și a imaginilor: .gitignore, variabile în CI, Docker secrets

Monitorizare și răspuns la incident

Nu poți răspunde la ce nu vezi. Logurile centralizate și câteva alerte bine alese îți spun despre un incident înaintea clienților.

• Loguri de autentificare, server web și aplicație într-un sistem central, în afara serverului
• Alerte pe login din locații neobișnuite, cheie nouă în authorized_keys, salt de trafic, job de backup eșuat, certificat aproape de expirare
• Plan de răspuns scris: cine izolează, cine anunță furnizorul, cine comunică clienților
• Restaurare de test lunară, ca planul să fie exersat, nu doar scris

Conformitate în România: DNSC, NIS2 și GDPR

Măsurile de mai sus nu sunt doar bune practici: pentru multe firme din România sunt obligații legale, verificate de DNSC și ANSPDCP.

• OUG 155/2024 transpune NIS2, e în vigoare din 31 decembrie 2024 și e aprobată prin Legea 124/2025; autoritatea competentă e DNSC
• Ordinele DNSC 1/2025 și 2/2025 stabilesc înregistrarea entităților și metodologia de evaluare a riscului; infrastructura digitală, inclusiv hosting, DNS și cloud, e în anexe
• Incidente semnificative: alertă timpurie în 24 de ore, notificare în 72 de ore, raport final într-o lună
• Art. 32 GDPR cere măsuri tehnice adecvate și capacitatea de a restabili datele; art. 33 cere notificarea ANSPDCP în 72 de ore la o breșă
• e-Factura: facturile transmise la ANAF trebuie păstrate pe durata legală de arhivare, deci backup-ul arhivei XML e obligație fiscală

Greșeli frecvente

• Crezi că portul SSH schimbat, un certificat SSL sau un firewall local înseamnă securitate; fiecare acoperă un singur strat.
• Ai backup, dar nu l-ai restaurat niciodată și stă în aceeași rețea cu producția.
• Instalezi dependențe direct pe server, cu npm install, și lași scripturile de instalare să ruleze pe producție.
• Rulezi containere ca root, cu --privileged sau cu socket-ul Docker montat, și le consideri izolate.
• Nu ai loguri în afara serverului și afli despre incident de la clienți sau de la furnizorul de plăți.

Cum te ajută 4hosting

Întrebări conexe

• Cu ce încep dacă am un singur VPS și puțin timp?

  În ordinea asta: SSH pe chei fără root și parole, firewall cu refuz implicit, actualizări automate de securitate, backup criptat offsite cu o restaurare de test, HTTPS cu reînnoire automată. Sunt câteva ore de lucru o singură dată și acoperă majoritatea atacurilor automate.

• Intru sub NIS2 dacă am o firmă mică?

  Depinde de sector și de dimensiune. OUG 155/2024 vizează entitățile esențiale și importante din anexele sale, inclusiv infrastructura digitală și serviciile IT gestionate, cu praguri de dimensiune. Un IMM dintr-un sector nelistat nu e vizat direct, dar clienții lui pot fi și îi pot cere dovezi contractual. Criteriile de dimensiune și pragurile de perturbare sunt în anexele OUG 155/2024 și în Ordinul DNSC 2/2025.

• Cine răspunde de securitate: furnizorul de hosting sau eu?

  Furnizorul răspunde de infrastructura fizică, de rețea și de protecția DDoS la nivel de rețea; pe cPanel și de sistemul de operare. Pe VPS și pe serverele dedicate, sistemul de operare, aplicația, datele și backup-ul sunt responsabilitatea ta. Orele incluse în abonament există exact ca să nu rămâi singur cu partea ta.