Best practice per proteggere le credenziali SSH

Questo documento descrive le best practice per proteggere le credenziali SSH.

Per impostazione predefinita, Compute Engine utilizza l'autenticazione SSH basata su chiavi pubbliche: gli utenti vengono autenticati da un elemento in loro possesso, ovvero una chiave privata SSH. Se le chiavi private degli utenti non sono protette correttamente, potrebbero finire nelle mani di malintenzionati, che potrebbero utilizzarle per accedere alle tue istanze VM.

Nelle sezioni seguenti troverai best practice che possono aiutarti a evitare la divulgazione delle chiavi e a ridurre il potenziale impatto delle chiavi private divulgate:

Il documento si concentra su pratiche specifiche per Trusted Cloud by S3NS o di particolare pertinenza per l'utilizzo di SSH su Trusted Cloud. Nel documento non vengono trattate le best practice per implementazioni specifiche di client o server SSH.

Tratta le chiavi private SSH in modo simile alle chiavi dei service account

Alcune delle tue istanze VM potrebbero avere un service account collegato. Il collegamento di un service account a una VM consente ai workload in esecuzione su queste VM di richiedere token di accesso di breve durata al server di metadati, per poter accedere alle API e alle risorse Trusted Cloud .

Quando ti connetti a una VM tramite SSH con un service account associato, puoi anche richiedere token di accesso di breve durata al server di metadati. La concessione a un utente dell'accesso SSH a una VM è quindi simile alla concessione dell'autorizzazione per agire come service account collegato. A causa di questa somiglianza, tratta le chiavi private SSH, in particolare se non sono protette da passphrase, come le chiavi dei service account: entrambi i tipi di chiavi, se divulgati, potrebbero concedere a malintenzionati l'accesso alle risorse Trusted Cloud.

Utilizza chiavi SSH temporanee per gli utenti della macchina

Le pipeline di deployment o i processi di automazione potrebbero richiedere l'accesso SSH alle istanze VM per eseguire deployment o applicare modifiche alla configurazione. Anziché consentire a questi workload di utilizzare una coppia di chiavi SSH di lunga durata, consenti di utilizzare una nuova chiave SSH temporanea a ogni esecuzione.

Per utilizzare chiavi SSH temporanee, consenti alle pipeline di deployment o ai processi di automazione di eseguire questi passaggi:

  1. Eseguire l'autenticazione come service account senza bisogno di una chiave o di un secret, ad esempio utilizzando un service account collegato o la federazione delle identità per i workload.
  2. Generare una coppia di chiavi SSH temporanea utilizzando uno strumento come ssh-keygen.

  3. Pubblicare la chiave pubblica in Trusted Cloud, specificando una data di scadenza imminente (ad esempio 1 ora nel futuro).

    OS Login ti consente di specificare una data di scadenza della chiave quando pubblichi una chiave. Analogamente, puoi specificare una data di scadenza quando pubblichi una chiave pubblica SSH nei metadati del progetto o delle VM.

  4. Utilizzare la chiave privata per stabilire connessioni SSH alle istanze VM.

  5. Facoltativamente, annullare la pubblicazione della chiave pubblica ed eliminare la chiave privata.

Ad esempio:

# Generate RSA key pair without passphrase
ssh-keygen -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

Sebbene sia ancora possibile che una chiave privata SSH temporanea venga divulgata, può essere utilizzata solo per poco tempo. L'utilizzo di chiavi SSH temporanee può quindi ridurre il rischio di compromissione delle credenziali e ti consente di utilizzare Cloud IAM come mezzo principale di autenticazione e autorizzazione.

Utilizza IAP per integrare l'autenticazione a chiave pubblica SSH

Per impostazione predefinita, le chiavi private SSH possono essere utilizzate indipendentemente dalle credenziali Google: se la chiave SSH privata di un utente viene divulgata, un malintenzionato può utilizzarla per connettersi e autenticarsi a qualsiasi istanza VM a cui la chiave è autorizzata ad accedere. Il malintenzionato non ha bisogno di conoscere il nome utente o la password, né di possedere credenziali Google.

Controlli di sicurezza come la verifica in due passaggi e la limitazione della durata delle sessioni per i servizi Trusted Cloud possono essere modi efficaci per ridurre il rischio di furto delle credenziali, ma questi controlli si applicano solo alle risorse che richiedono le credenziali Google.

Per assicurarti che le chiavi SSH non possano essere utilizzate senza credenziali Google valide, utilizza IAP per gestire l'accesso SSH e utilizza le policy del firewall per imporre che tutti gli accessi SSH vengano eseguiti tramite IAP.

IAP funge da reverse proxy e consente agli utenti di stabilire connessioni SSH alle istanze VM solo se si sono autenticati correttamente utilizzando le proprie credenziali Google. Inoltre, IAP ti consente di limitare le VM a cui gli utenti possono connettersi e di applicare l'accesso sensibile al contesto.

Utilizza l'autenticazione a più fattori

L'utilizzo di IAP per gestire l'accesso SSH rende l'accesso di un malintenzionato alle istanze VM con le credenziali divulgate più difficile, ma non impossibile: ad esempio, un malintenzionato potrebbe compromettere una workstation e trovare sia una chiave SSH privata sia le credenziali gcloud CLI memorizzate nella cache e queste sono sufficienti per superare i controlli di autenticazione e autorizzazione di IAP e connettersi alle istanze VM dell'utente.

Puoi ridurre il possibile impatto di questi attacchi di furto delle credenziali configurando Cloud Identity o Google Workspace in modo da richiedere l'autenticazione a più fattori (MFA).

Se Cloud Identity o Google Workspace è il tuo provider di identità principale, segui questi passaggi per imporre l'autenticazione a più fattori:

  1. Configura Cloud Identity o Google Workspace per imporre la verifica in due passaggi.
  2. Limita la durata della sessione per i servizi Trusted Cloud in modo che le credenziali memorizzate nella cache vengano annullate automaticamente e gli utenti debbano ripetere periodicamente l'autenticazione e l'MFA.

Se utilizzi Single Sign-On con un IdP esterno, segui invece questi passaggi:

  1. Configura Cloud Identity o Google Workspace per limitare la durata della sessione per i servizi Trusted Cloud in modo che le credenziali memorizzate nella cache vengano invalidate automaticamente e gli utenti debbano ripetere periodicamente l'autenticazione utilizzando l'IdP esterno.
  2. Configura l'IdP esterno in modo che richieda l'MFA e limita la durata della sessione in modo che gli utenti debbano eseguire l'MFA ogni volta che la sessione Trusted Cloud scade.

Per assicurarti che la verifica in due passaggi venga applicata anche all'accesso SSH, devi eseguire almeno una di queste operazioni:

  1. Utilizza IAP per controllare l'accesso alla rete in modo che gli utenti debbano eseguire periodicamente l'MFA per aggiornare le proprie credenziali Google.
  2. Attiva l'autenticazione a due fattori (2FA) di OS Login per singole istanze VM o interi progetti in modo che gli utenti debbano eseguire l'MFA ogni volta che stabiliscono una connessione SSH.

Gli utenti con il ruolo Compute Instance Admin o un ruolo equivalente per un'istanza VM o un progetto possono disattivare l'autenticazione a due fattori di OS Login modificando i metadati dell'istanza. L'efficacia dell'autenticazione a due fattori (2FA) di OS Login è quindi limitata se non applichi anche l'MFA in Cloud Identity o nel tuo IdP esterno.

Utilizza chiavi private non esportabili o protette da passphrase

Per impostazione predefinita, molti client SSH memorizzano le chiavi private SSH come file su disco. Ad esempio, gcloud compute ssh genera una coppia di chiavi SSH al primo utilizzo e la memorizza nella home directory. Il sistema operativo potrebbe proteggere i tuoi file dall'accesso da parte di altri utenti, ma se un malintenzionato riesce a superare le autorizzazioni del file system (ad esempio copiando e montando il disco su un'altra macchina), può copiare la chiave altrove e utilizzarla a tua insaputa.

Alcuni client SSH ti consentono di evitare di utilizzare chiavi basate su file e offrono opzioni alternative per gestire le chiavi private SSH, tra cui:

  • Utilizzo di una chiave con integrazione hardware: le versioni moderne di OpenSSH ti consentono di utilizzare i token di sicurezza FIDO2 per l'autenticazione e puoi configurare OS Login in modo che consenta solo i token di sicurezza registrati in Cloud Identity o Google Workspace. L'utilizzo di chiavi con integrazione hardware ti consente di evitare di memorizzare qualsiasi materiale delle chiavi private nel file system del computer.
  • Utilizzo delle strutture di archiviazione delle chiavi del sistema operativo: ad esempio, IAP Desktop evita di utilizzare chiavi basate su file e utilizza invece Windows CNG per proteggere le chiavi SSH.

Se l'uso di chiavi con integrazione hardware o gestite dal sistema operativo non è possibile, puoi utilizzare una passphrase per proteggere la tua chiave privata SSH: per utilizzare una chiave SSH protetta da passphrase, a un malintenzionato non basta una copia della chiave privata, ma deve anche conoscere la passphrase della chiave.

Utilizza chiavi host per l'autenticazione dell'host

Quando crei una connessione SSH a un'istanza VM, la identifichi in base al nome o all'indirizzo IP. I nomi e gli indirizzi IP possono essere riassegnati e riutilizzati e il nome che ieri faceva riferimento a una determinata istanza VM potrebbe non fare riferimento alla stessa istanza VM oggi. Gli utenti malintenzionati potrebbero riassegnare o riutilizzare deliberatamente nomi o indirizzi IP per lo spoofing delle istanze VM, inducendo gli utenti a connettersi a una VM compromessa.

I client SSH possono rilevare le situazioni in cui un'istanza VM precedentemente attendibile è stata sostituita con un'altra istanza VM mediante le chiavi host SSH: la chiave host SSH di una VM viene generata al primo avvio e utilizzata per identificare l'istanza. I client SSH solitamente richiedono e memorizzano la chiave host di una VM alla prima connessione e verificano che non sia cambiata nelle connessioni successive.

Le chiavi host SSH funzionano in base allo schema "Trust On First Use" (TOFU). L'efficacia delle chiavi host SSH può essere compromessa se un malintenzionato utilizza un attacco man-in-the-middle (MITM) per far connettere un client alla VM sbagliata e considerarla attendibile al primo utilizzo. Un modo migliore per ottenere una chiave host è utilizzare un canale laterale attendibile prima di eseguire la connessione iniziale a una VM.

Puoi consentire a gcloud CLI di ottenere le chiavi host tramite un canale secondario attivando gli attributi guest nel tuo progetto. gcloud CLI legge quindi la chiave host di una VM in anticipo rispetto alla tua prima connessione e la salva sul computer locale.

Non lasciare credenziali personali sulle VM

Quando autorizzi gcloud CLI, lo strumento ottiene un token di aggiornamento OAuth e lo memorizza nella tua home directory locale. In seguito, quando esegui un comando gcloud CLI, il token di aggiornamento viene utilizzato per autenticarti automaticamente.

Il computer locale potrebbe non essere accessibile ad altri utenti, ma in un'istanza VM, la home directory può essere accessibile anche ad altri utenti che dispongono di privilegi sudo sulla VM.

Se un malintenzionato riesce a ottenere i privilegi sudo su una VM, potrebbe cercare token di aggiornamento e altre credenziali nelle home directory di altri utenti e utilizzare queste credenziali per aumentare i propri privilegi o estendere il proprio accesso ad altre risorse (movimento laterale).

Quando esegui la connessione a un'istanza VM tramite SSH, evita di autorizzare gcloud CLI o Credenziali predefinite dell'applicazione (ADC) con le tue credenziali personali e consenti invece a gcloud CLI di utilizzare il service account collegato alla VM. Analogamente, evita di eseguire altri strumenti che potrebbero memorizzare credenziali personali nella tua home directory.

Puoi ridurre ulteriormente i rischi limitando la durata della sessione per i servizi Trusted Cloud in modo che i token di aggiornamento OAuth archiviati scadano automaticamente dopo un determinato periodo di tempo.

Non inviare chiavi private SSH ai repository di codice sorgente

Alcuni strumenti di automazione come Ansible utilizzano SSH per l'accesso e la gestione delle istanze VM. Poiché questi strumenti potrebbero avere accesso a molte istanze VM (e ai relativi service account collegati), le chiavi private SSH utilizzate da questi strumenti possono essere particolarmente sensibili.

Se invii una chiave privata SSH a un repository di codice sorgente, aumenta il rischio che la chiave diventi accessibile a utenti non autorizzati e malintenzionati:

  • Gli utenti malintenzionati potrebbero cercare chiavi divulgate nel codice sorgente dei repository di codice origine pubblici.
  • In futuro, potresti decidere di trasformare un repository di codice sorgente privato in pubblico senza prima controllare la presenza di chiavi.
  • Altri membri del team potrebbero archiviare copie del codice sorgente sulla propria workstation.

Per ridurre questi rischi, archivia la chiave privata SSH in una posizione sicura separata dal codice sorgente e, se possibile, utilizza chiavi SSH temporanee.

Passaggi successivi