Come applicare il principio del "privilegio minimo" per l'accesso SSH all'interno del proprio team

Il principio del privilegio minimo è semplice: ogni persona e ogni sistema dovrebbero avere accesso esattamente a ciò di cui hanno bisogno, e nient’altro. Applicato all’accesso SSH, significa nessun accesso permanente ai server che una persona non utilizza attivamente, nessuna chiave condivisa, nessuna autorizzazione “per ogni evenienza” che permanga dopo la conclusione di un progetto.

In pratica, la maggior parte dei team di ingegneri è ben lontana da questo obiettivo. Non per negligenza, ma perché l’accesso SSH è facile da concedere e facile da dimenticare. Il divario tra il modello di accesso che si intende adottare e quello che esiste effettivamente nei file authorized_keys cresce silenziosamente, un’eccezione alla volta.

L’accesso dovrebbe essere limitato al ruolo, non all’anzianità di servizio

L’errore più comune che i team commettono è quello di trattare l’accesso SSH come un privilegio che varia in base all’anzianità di servizio: i junior hanno accesso allo staging, i senior alla produzione. Questo confonde la fiducia con la necessità.

Un modello migliore limita l’accesso a ciò che il lavoro attuale di ciascuna persona richiede effettivamente. Un ingegnere senior che lavora esclusivamente sul servizio API non ha alcuna necessità operativa di accedere direttamente ai server del database. Un collaboratore esterno assunto per lavorare sul frontend non ha alcuna necessità di toccare l’infrastruttura. L’anzianità di servizio può influenzare il processo di approvazione, ma non dovrebbe determinare l’ambito predefinito.

Definire i livelli di accesso in base alla funzione, non al titolo. Rivedere tali livelli quando cambiano i ruoli, non solo quando le persone entrano o escono dall’organizzazione.

Le chiavi devono essere individuali e attribuibili

Le chiavi SSH condivise sono un anti-pattern di sicurezza senza alcuna giustificazione legittima in un ambiente di squadra. Quando una chiave viene condivisa, si perde la capacità di attribuire l’accesso: non è possibile rispondere alla domanda «chi ha effettuato l’accesso a quel server alle 2 del mattino» con qualcosa di più specifico di «qualcuno in possesso della chiave condivisa».

Ogni persona dovrebbe disporre di una propria coppia di chiavi, registrata a nome della propria identità. Questo è il fondamento di qualsiasi tracciato di audit significativo ed è un requisito imprescindibile per la maggior parte dei quadri normativi di conformità. DataraSSH garantisce questo aspetto per sua stessa natura: ogni chiave nel sistema è attribuita a una persona specifica, il che rende le revisioni degli accessi e la procedura di offboarding semplici e immediate, anziché un'operazione forense manuale.

L’offboarding deve essere immediato e completo

La causa più comune di accessi SSH non autorizzati non sono gli aggressori esterni, bensì ex dipendenti e collaboratori le cui chiavi non sono mai state rimosse. Le checklist standard per la cessazione del rapporto di lavoro coprono SSO, e-mail e Slack. Le chiavi SSH vengono sistematicamente trascurate perché non esiste un registro centrale dei server a cui una persona aveva accesso.

La best practice consiste nel considerare la revoca delle chiavi SSH come una fase fondamentale in qualsiasi processo di uscita, con una verifica accertata del completamento. Ciò significa sapere, nel momento in cui una persona lascia l’azienda, esattamente su quali server si trova la sua chiave, senza doverlo ricostruire in seguito setacciando i server uno per uno.

L'accesso temporaneo dovrebbe scadere automaticamente

Per gli appaltatori, gli addetti alla gestione degli incidenti o chiunque abbia bisogno di un accesso a breve termine a un sistema con cui non interagisce abitualmente, l'accesso a tempo determinato è significativamente più sicuro rispetto a quello che richiede una revoca manuale. Concedete l'accesso con una scadenza esplicita e considerate qualsiasi proroga come una nuova approvazione piuttosto che come una continuazione predefinita.

Questo è uno degli ambiti in cui gli strumenti fanno davvero la differenza nella pratica. La scadenza manuale si basa sul fatto che qualcuno si ricordi di occuparsene — e tale attività viene inevitabilmente messa in secondo piano quando ci sono altri compiti da svolgere.

Le verifiche periodiche individuano ciò che sfugge al processo

Anche un modello di accesso ben progettato subisce derive nel tempo. I cambiamenti di ruolo, i passaggi di consegne tra progetti e le eccezioni concesse sotto pressione creano tutti dei divari tra il modello previsto e lo stato effettivo della vostra infrastruttura.

Una revisione trimestrale degli accessi — che metta a confronto l’attribuzione attuale delle chiavi con i ruoli attuali — è la pratica minima necessaria. Non deve essere necessariamente complessa. L’obiettivo è semplicemente rispondere a queste domande: ogni chiave attiva appartiene a un membro attuale del team e il suo accesso corrisponde ancora a quanto richiesto dal suo ruolo? Qualsiasi chiave che non superi uno dei due controlli viene esaminata e, a seconda dei casi, giustificata o revocata.

Con DataraSSH, questa revisione è un esercizio di visibilità piuttosto che un audit manuale: lo stato attuale è già mappato, quindi la revisione consiste nel confrontarlo con il modello dei ruoli piuttosto che ricostruirlo da zero.

L’obiettivo è un sistema, non una pulizia una tantum

La maggior parte dei team affronta l’accesso SSH basato sul principio del privilegio minimo come un progetto di rimedio: si esegue l’audit, si ripuliscono le chiavi e si va avanti. Sei mesi dopo, gli stessi problemi si sono accumulati di nuovo.

La differenza tra i team che mantengono una buona igiene degli accessi e quelli che non lo fanno non sta nella qualità della loro pulizia iniziale, ma nel fatto che dispongano o meno di un sistema in grado di mantenere correttamente circoscritti gli accessi man mano che il team e l’infrastruttura si evolvono. Ruoli definiti, chiavi individuali, procedure strutturate di inserimento e uscita dal personale, revisioni periodiche. Non si tratta di pratiche complesse. Devono solo essere costanti.

DataraSSH è stato progettato per rendere pratico questo processo: non una pulizia una tantum, ma un sistema continuo. Try DataraSSH ed esegui la tua prima verifica degli accessi in meno di dieci minuti.