În multe firme din Moldova serverul a fost instalat o dată și „nu se mai atinge, ca să nu se strice”. Pentru clientul din UE care cere dovada că vulnerabilitățile publicate se închid în câteva zile, tocmai prudența asta e riscul auditat.
Când o vulnerabilitate primește un identificator CVE și un patch, atacatorii compară versiunile și scriu exploit-ul în ore sau zile. Scanerele automate caută banner-ul de versiune, la Frankfurt ca și la Chișinău. Serverul actualizat trimestrial rămâne vulnerabil luni de zile; cel care instalează singur actualizările de securitate în aceeași noapte reduce fereastra la câteva ore.
Separă cele două fluxuri. Actualizările de securitate ale distribuției sunt mici, testate și rar schimbă comportamentul, deci pot rula fără intervenție. Versiunile majore de PostgreSQL, PHP sau Node și upgrade-ul distribuției rămân manuale, prin staging, cu plan de revenire. Fixează prin pinning versiunile majore ale bazei și ale runtime-ului, ca o actualizare de sistem să nu-ți schimbe PHP 8.2 în 8.4 într-o marți dimineață.
Kernelul nou rulează doar după repornire; până atunci ai patch-ul pe disc și vulnerabilitatea în memorie. Alege o fereastră fixă, de exemplu marți la 03:00 ora Chișinăului, anunț-o în contractele de suport și lasă unattended-upgrades să repornească în ea. Pe un singur nod pierzi câteva zeci de secunde; pe două noduri în spatele unui load balancer repornești pe rând. Live patching-ul acoperă doar kernelul, nu și glibc sau systemd.
Hotărârea Guvernului nr. 562/2025, cu privire la modul de realizare a obligațiilor de asigurare a securității cibernetice de către furnizorii de servicii în sectoarele critice, cere o politică de gestionare a riscurilor și a vulnerabilităților, cu evaluări documentate. Clienții din UE cer același lucru în anexa de securitate: termen maxim pentru vulnerabilitățile critice și dovada aplicării. Jurnalul apt sau dnf, exportat lunar, este acea dovadă.
| Componentă | Mod de actualizare | Cere repornire | Termen orientativ |
|---|---|---|---|
| Kernel | automat, din -security | da, completă | în prima fereastră după publicare |
| glibc, OpenSSL, systemd | automat, din -security | restart de servicii sau completă | în aceeași zi |
| nginx, PHP, Node.js | automat pentru securitate, versiune majoră fixată | restart de serviciu | câteva zile |
| PostgreSQL, MySQL | minor automat, major manual din staging | restart de serviciu | planificat, cu backup verificat |
| Imagini de containere | rebuild în CI pe bază actualizată | redeploy | săptămânal sau la CVE critic |
apt install unattended-upgrades needrestart
cat > /etc/apt/apt.conf.d/52-security-only <<'EOF'
// golim listele implicite din 50unattended-upgrades înainte să punem ale noastre
Unattended-Upgrade::Allowed-Origins { };
#clear Unattended-Upgrade::Allowed-Origins;
#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename}-security";
"origin=Ubuntu,archive=${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
EOF
# în ieșirea de mai jos trebuie să apară DOAR originile -security
unattended-upgrade --dry-run --debugdnf install dnf-automatic
sed -i 's/^upgrade_type.*/upgrade_type = security/; s/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
systemctl enable --now dnf-automatic.timerneedrestart -r l # listează serviciile care rulează biblioteci înlocuite
needrestart -k # verifică separat dacă kernelul încărcat e cel instalatAuditorul clientului a cerut timpul mediu între publicarea unui patch și aplicarea lui; nimeni nu știa. Echipa a activat unattended-upgrades pe toate mașinile, cu repornire marți la 03:00, și exportă lunar jurnalul apt. La al doilea audit cifra era sub 24 de ore.
Serverul nu fusese actualizat de la instalare, de teamă că magazinul nu mai pornește. O clonă din snapshot a arătat că actualizarea trece curat; singurul incident, un modul PHP dezactivat, s-a reparat pe staging în zece minute.
Actualizările rulau, dar serverul nu fusese repornit de opt luni, deci kernelul vulnerabil era în memorie. needrestart a listat 14 servicii cu biblioteci vechi. Repornirea e acum planificată lunar, într-o fereastră anunțată.
Pentru actualizările de securitate ale distribuției, da: sunt mici și testate. Riscul vine din versiunile majore, pe care le excluzi din fluxul automat. Păstrează un snapshot înainte de fereastră și verifică jurnalul dimineața; incidentele sunt rare și mai ieftine decât o breșă.
Pe Debian și Ubuntu apare /var/run/reboot-required după un kernel nou, iar needrestart arată serviciile cu biblioteci înlocuite pe disc. Pe RHEL, dnf needs-restarting -r. Dacă uptime-ul e de luni de zile, răspunsul e aproape sigur da.
Pentru servere care nu pot avea niciun minut de pauză, da, dar acoperă doar kernelul: glibc, systemd și OpenSSL tot cer restart. Pentru majoritatea serverelor din Moldova, repornirea planificată noaptea e mai simplă și mai ieftină.
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.