Într-o firmă din Moldova cu opt dezvoltatori, doi administratori și un contabil extern, la întrebarea „cine poate face ce pe server” răspunsul e de obicei „toți, totul, ca root”. Privilegiul minim înseamnă că fiecare cont poate face exact ce are nevoie, iar jurnalul spune cine a făcut.
Când toți intră pe același cont, jurnalul arată că „deploy” a șters o bază de date și auditul se termină acolo. Când un coleg pleacă, parola comună ar trebui schimbată, ceea ce în practică nu se întâmplă. Cu conturi individuale și sudo, fiecare comandă privilegiată are un nume lângă ea, iar plecarea cuiva înseamnă dezactivarea unui singur cont. Clienții din UE cer exact asta: acces nominal, jurnal al acțiunilor administrative, revocare promptă.
Un dezvoltator trebuie să repornească serviciul aplicației și să-i citească logurile, nu să editeze sshd_config; un operator de backup rulează scriptul de backup, nu instalează pachete. Scrii câte un fișier în /etc/sudoers.d/ per rol, cu comenzile exacte, și pui oamenii în grupuri care corespund rolurilor. NOPASSWD se dă doar unui cont de automatizare, pentru o singură comandă, niciodată ALL. Validezi fiecare fișier cu visudo -c înainte să închizi sesiunea: o eroare de sintaxă blochează sudo pentru toți.
Aplicația web, baza de date și job-urile programate rulează fiecare sub contul lor, creat cu -r și shell nologin, fără parolă și fără cheie SSH. Un atacator care compromite aplicația obține un cont fără shell și fără sudo. Pentru oameni, offboarding-ul are o listă: dezactivare cu usermod -L și expirare, ștergerea cheilor din authorized_keys pe toate serverele, revocarea peer-ului VPN, rotirea parolelor și cheilor API văzute. Lista se rulează în ziua plecării.
Trimestrial generezi lista conturilor cu UID peste 1000, grupurile lor și regulile sudo efective și o compari cu lista de angajați: conturile fără proprietar se dezactivează, cele cu drepturi peste rol se restrâng. HG nr. 562/2025 cere furnizorilor sub Legea nr. 48/2023 o politică de control al accesului cu revizuiri periodice, iar Legea nr. 195/2024 cere măsuri organizatorice adecvate pentru accesul la date personale. Raportul trimestrial e dovada pentru amândouă.
| Rol | Cont | Drepturi sudo | Ce nu poate face |
|---|---|---|---|
| Administrator de sistem | nominal, în grupul ops | ALL, cu parolă, cu log_output | conectare directă ca root |
| Dezvoltator | nominal, în grupul dev | systemctl restart app, journalctl -u app | editare configurație de sistem, instalare pachete |
| Operator backup | nominal sau de automatizare | NOPASSWD doar pentru /usr/local/bin/backup.sh | orice altă comandă |
| Contabil extern | nominal, limitat | NOPASSWD doar pentru scriptul de export | shell interactiv privilegiat |
| Aplicație web | de serviciu, nologin | niciunul | shell, sudo, SSH |
groupadd dev && groupadd ops
useradd -m -G dev -s /bin/bash ion.popescu
# cheia lui Ion ajunge în /home/ion.popescu/.ssh/authorized_keys, nu parolă
# aplicația rulează sub cont de serviciu fără shell
useradd -r -s /usr/sbin/nologin -d /srv/app app# journalctl și systemctl status deschid un pager care, rulat ca root, permite !sh —
# de aceea comenzile sunt fixate cu --no-pager și fără wildcard.
Cmnd_Alias APP_OPS = /usr/bin/systemctl --no-pager restart app.service, /usr/bin/systemctl --no-pager --full status app.service, /usr/bin/journalctl --no-pager -n 200 -u app.service
Defaults!APP_OPS env_reset, env_delete += "PAGER SYSTEMD_PAGER LESS LESSOPEN"
%dev ALL=(root) APP_OPS
# /etc/sudoers.d/20-backup
backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh
# /etc/sudoers.d/00-defaults
Defaults log_output, logfile=/var/log/sudo.log
# validare înainte de a închide sesiunea:
visudo -c# offboarding
usermod -L -e 1 vasile.rusu && pkill -u vasile.rusu
grep -rl 'vasile.rusu@' /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys
# audit: conturi umane, grupuri, reguli sudo efective
awk -F: '$3>=1000 && $7!~/nologin|false/ {print $1}' /etc/passwd
for u in $(awk -F: '$3>=1000 && $7!~/nologin|false/ {print $1}' /etc/passwd); do echo "== $u"; id -nG "$u"; sudo -l -U "$u" | tail -n +2; doneNouă oameni știau parola contului deploy, care avea sudo ALL, iar un tabel șters în producție nu a putut fi atribuit nimănui. După conturi nominale și un fișier sudoers.d pe rol, incidentul următor a fost atribuit în două minute.
Contabilul avea sudo ALL ca să copieze exporturile pentru SFS. Acum are un cont limitat la o comandă, cu NOPASSWD pentru scriptul de export, iar jurnalul arată când a rulat.
Un audit intern a găsit șapte conturi active ale unor persoane plecate de peste un an, două cu chei SSH valide. Offboarding-ul a fost formalizat, iar auditul trimestrial a intrat în calendarul responsabilului IT.
Da, pentru rolul de administrator, cu cont nominal, parolă cerută și log_output activat: administratorul chiar are nevoie de tot. Problema apare când toți primesc ALL fiindcă e mai simplu. Celelalte roluri primesc liste de comenzi.
Cu un instrument precum Ansible, care aplică aceeași listă de utilizatori, grupuri, chei și fișiere sudoers.d pe toate mașinile, dintr-un inventar versionat în Git. Offboarding-ul devine o ștergere și o rulare, iar auditul e diff-ul acelui fișier.
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.