Un singur cont „deploy” cu parola știută de toată echipa și sudo fără restricții e cea mai comună configurație pe serverele mici din România. Funcționează până când cineva pleacă, un laptop e furat sau trebuie să afli cine a rulat o comandă.
Un cont partajat face imposibile două lucruri: să afli cine a făcut o schimbare și să retragi accesul unei singure persoane. Cu un cont per persoană, logul de sudo spune cine a rulat ce, iar plecarea cuiva înseamnă un singur cont dezactivat. Regula implicită de pe multe VPS-uri, grupul sudo poate rula orice fără parolă, transformă orice cheie SSH compromisă în root. Corect, definești roluri: cine face deploy repornește serviciul și îi citește logurile, cine administrează baza de date rulează comenzile ei, iar root complet rămân doi oameni.
Aplicația, serverul web și baza de date rulează fiecare sub un cont de sistem propriu, cu shell nologin și fără parolă: chiar dacă cineva află parola bazei de date, nu poate deschide o sesiune cu contul acela. Offboarding-ul e o procedură scrisă, executată în ziua plecării: blochezi contul, îi pui expirarea în trecut, ștergi cheia din authorized_keys de pe toate serverele, îl scoți din grupuri și rotești parolele și cheile API pe care le-a văzut. Audit lunar: conturile cu shell valid, grupul sudo, ultima autentificare. Un cont nefolosit de 90 de zile se dezactivează.
Art. 32 GDPR cere măsuri care să asigure că doar persoanele autorizate au acces la datele personale, iar la o breșă ANSPDCP verifică exact acest control: cine avea acces, pe ce bază, când a fost retras. Un cont partajat nu poate răspunde la niciuna dintre întrebări. Pentru entitățile de sub OUG 155/2024, transpunerea NIS2 aprobată prin Legea 124/2025, politicile de control al accesului și securitatea resurselor umane sunt măsuri minime explicite (art. 13 lit. f). Retragerea accesului în ziua plecării e și protecția firmei față de un fost angajat nemulțumit.
| Tip de cont | Shell | Autentificare | sudo |
|---|---|---|---|
| Administrator (doi oameni) | bash | cheie SSH personală, prin VPN | ALL, cu parolă la fiecare comandă |
| Deploy / dezvoltator | bash | cheie SSH personală | doar comenzile de deploy, în sudoers.d |
| Cont de serviciu (app, www-data, postgres) | /usr/sbin/nologin | niciuna | niciuna |
| CI / automatizare | bash sau nologin cu ForceCommand | cheie dedicată, restricționată | o singură comandă de deploy |
| root | bash | doar local sau prin consolă | — |
sudo adduser --disabled-password --gecos "Ana Popescu" ana
sudo install -d -m 700 -o ana -g ana /home/ana/.ssh
echo "ssh-ed25519 AAAA...cheia Anei... ana@laptop" | sudo tee /home/ana/.ssh/authorized_keys
sudo chmod 600 /home/ana/.ssh/authorized_keys && sudo chown ana:ana /home/ana/.ssh/authorized_keys
sudo useradd --system --shell /usr/sbin/nologin --home /var/lib/app --create-home app# grupul deploy poate reporni aplicația și îi poate citi logurile, nimic altceva.
# ATENȚIE: journalctl și systemctl status deschid un pager, iar pager-ul rulat ca root
# permite evadarea în shell cu !sh. De aceea forțăm --no-pager și interzicem argumentele libere.
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 LESSSECURE"
%deploy ALL=(root) NOPASSWD: APP_OPS# offboarding
sudo usermod -L -e 1 ana
sudo gpasswd -d ana sudo; sudo gpasswd -d ana deploy
sudo rm -f /home/ana/.ssh/authorized_keys
# apoi rotești parolele și cheile API pe care le-a văzut
# audit
getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}'
getent group sudo deploy
sudo lastlog -b 90 | grep -v "Never"Zece oameni, un cont, o parolă din 2021 și NOPASSWD: ALL. Când un fost angajat a șters un director de client, nimeni nu a putut spune cine. Agenția a creat conturi personale cu chei, a limitat sudo la comenzile de deploy și a scris procedura de offboarding.
Aplicația Java rula ca root „pentru că avea nevoie de portul 443”. O vulnerabilitate de deserializare a dat atacatorului root pe server. Acum aplicația rulează sub un cont nologin, pe un port înalt, iar nginx stă în față pe 443.
Pentru că cheia SSH e singurul lucru dintre atacator și root. Un laptop furat deblocat, un agent SSH redirecționat pe un server compromis sau o cheie copiată dintr-un backup devin imediat root. Parola la sudo e un al doilea factor local; regulile pe comenzi limitează pagubele.
Printr-un grup deploy cu reguli sudo pe comenzile exacte de care are nevoie: repornirea serviciului, citirea logurilor lui, eventual un script de deploy cu cale fixă și fără argumente libere. În CI, aceleași comenzi le rulează un cont dedicat, cu cheie proprie.
Lunar pe serverele cu date personale sau cu obligații NIS2, trimestrial pe restul, plus după fiecare plecare din echipă. Verificarea durează cinci minute cu comenzile de audit și prinde conturile uitate, cheile în plus și membrii nejustificați ai grupului sudo.
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.