Gestionarea cheilor SSH: 7 bune practici pentru 2026

Problema cheilor SSH

Cheile SSH sunt coloana vertebrală a accesului la servere. Sunt mai sigure decât parolele, simplu de pus în funcțiune și suportate peste tot. Dar pe măsură ce echipa voastră crește, complexitatea gestionării lor crește și ea.

Majoritatea echipelor încep cu o mână de chei, copiind manual cheile publice pe servere. Într-un an, aveți zeci de chei dispersate între laptopuri, pipeline-uri CI/CD și foldere partajate. Nimeni nu știe ce chei dau acces la ce servere. Când cineva pleacă, revocarea accesului înseamnă conectarea la fiecare server în parte.

7 bune practici

1. Centralizați gestionarea cheilor

Încetați să gestionați cheile pe fiecare server. Folosiți un sistem centralizat care servește drept sursă unică de adevăr pentru cine are acces la ce. Aceasta este ceea ce face auditul posibil și revocarea instantanee.

2. Implementați rotația cheilor

Cheile SSH trebuie să aibă o dată de expirare. Definiți o politică de rotație - 90 de zile este un bun punct de plecare. Rotația automatizată elimină sindromul „o vom face mai târziu" care duce la chei vechi de mai mulți ani încă valide în producție.

3. Folosiți autentificarea prin certificate

Certificatele SSH sunt superioare cheilor brute în mediul de echipă. Includ metadate (cine, ce, când, unde) și pot fi limitate în timp. Un certificat care expiră în 8 ore este intrinsec mai sigur decât o cheie care trăiește veșnic.

4. Impuneți autentificarea multi-factor

Cheile SSH singure sunt o autentificare cu un singur factor. Combinați-le cu TOTP, WebAuthn sau chei de securitate hardware. Dacă o cheie este compromisă, al doilea factor împiedică accesul neautorizat.

5. Auditați fiecare conexiune

Înregistrați cine s-a conectat, când, de unde și ce a făcut. Fără jurnale de audit complete, nu puteți investiga incidente, dovedi conformitatea sau răspunde la întrebarea de bază: „Cine a accesat producția în noaptea aceasta?"

6. Aplicați principiul celui mai mic privilegiu

Dezvoltatorii nu au nevoie de acces root pe toate serverele. Definiți politici de acces per rol. Un dezvoltator frontend are nevoie de acces la serverul de staging, nu la baza de date de producție.

7. Automatizați offboardingul

Când cineva pleacă, revocarea accesului trebuie să fie automatizată și instantanee. Procesele de offboarding manuale sunt lente, predispuse la erori și constituie un risc de securitate.

Cum ajută SecurSSH

SecurSSH implementează aceste bune practici nativ: gestionarea centralizată a credențialelor SSH într-un seif criptat, jurnal de audit de doi ani, RBAC pe trei niveluri și revocare instantanee prin retragerea membrului. Semnarea de certificate SSH, 2FA TOTP pe cont și MFA de echipă obligatorie sunt în foaia de parcurs 2026. Punere în funcțiune în 15 minute.