Best practice per la protezione delle 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 qualcosa che hanno, 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.

Le seguenti sezioni contengono best practice che possono aiutarti a evitare la fuga di chiavi e a ridurre il potenziale impatto delle chiavi private trapelate:

Il documento si concentra su pratiche specifiche per Google Cloud o di particolare rilevanza quando si utilizza SSH su Google Cloud. Il documento non illustra le best practice per implementazioni specifiche di client o server SSH.

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

Alcune delle tue istanze VM potrebbero avere un account di servizio associato. L'associazione di un account di servizio a una VM consente ai carichi di lavoro in esecuzione su queste VM di richiedere token di accesso di breve durata dal server di metadati in modo da poter accedere alle API e alle risorse. Google Cloud

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

Utilizzare chiavi SSH effimere per gli utenti della macchina

Le pipeline di deployment o i processi di automazione potrebbero richiedere l'accesso SSH alle istanze VM per eseguire i deployment o applicare le modifiche di configurazione. Anziché consentire a questi carichi di lavoro di utilizzare una coppia di chiavi SSH a lungo termine, consenti loro di utilizzare una nuova chiave SSH effimera ogni volta che vengono eseguiti.

Per utilizzare le chiavi SSH effimere, consenti alle pipeline di deployment o alle procedure di automazione di eseguire i seguenti passaggi:

  1. Esegui l'autenticazione come account di servizio in un modo che non implichi una chiave o un segreto, ad esempio utilizzando un account di servizio collegato o la federazione delle identità per i carichi di lavoro.
  2. Genera una coppia di chiavi SSH temporanea utilizzando uno strumento come ssh-keygen.

  3. Pubblica la chiave pubblica in Google 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 della VM.

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

  5. Se vuoi, annulla la pubblicazione della chiave pubblica ed elimina 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 una chiave privata SSH temporanea possa comunque essere divulgata, può essere utilizzata solo per poco tempo. L'utilizzo di chiavi SSH effimere può quindi ridurre il rischio di compromissione delle credenziali e ti consente di utilizzare Cloud IAM come mezzo principale di autenticazione e autorizzazione.

Utilizzare l'IAP per integrare l'autenticazione con chiave pubblica SSH

Per impostazione predefinita, le chiavi private SSH possono essere utilizzate indipendentemente dalle credenziali di 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. Non è necessario che l'autore della violazione conosca il nome utente o la password dell'utente o che possieda anche una credenziale Google.

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

Per assicurarti che le chiavi SSH non possano essere utilizzate senza credenziali Google valide, utilizza IAP per gestire l'accesso SSH e utilizza i criteri di firewall per imporre che tutto l'accesso SSH venga eseguito tramite IAP.

IAP funge da proxy inverso 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 in base al contesto.

Utilizzare l'autenticazione a più fattori

L'utilizzo di IAP per gestire l'accesso SSH rende più difficile per un malintenzionato accedere alle istanze VM utilizzando credenziali trapelate, ma non lo rende impossibile: ad esempio, un malintenzionato potrebbe compromettere una workstation e trovare sia una chiave SSH privata sia le credenziali dell'interfaccia a riga di comando gcloud memorizzate nella cache, il che è sufficiente 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 che richieda l'autenticazione a più fattori (MFA).

Se Cloud Identity o Google Workspace è il tuo provider di identità principale, obbliga l'MFA nel seguente modo:

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

Se utilizzi Single Sign-On con un IdP esterno, segui invece questa procedura:

  1. Configura Cloud Identity o Google Workspace per limitare la durata della sessione per i Google Cloud servizi in modo che le credenziali memorizzate nella cache vengano invalidate automaticamente e gli utenti debbano effettuare 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 scade. Google Cloud

Per assicurarti che la verifica in due passaggi venga applicata anche all'accesso SSH, devi eseguire almeno una delle seguenti 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 la verifica 2FA per l'accesso al sistema operativo per singole istanze VM o per interi progetti in modo che gli utenti debbano eseguire l'MFA ogni volta che stabiliscono una connessione SSH.

Gli utenti con il ruolo Amministratore di istanze Compute o un ruolo equivalente per un progetto o un'istanza VM possono disattivare l'autenticazione a due fattori di OS Login modificando i metadati dell'istanza. L'efficacia della verifica 2FA per l'accesso al sistema operativo è quindi limitata se non applichi anche la verifica 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 directory home. Il sistema operativo potrebbe proteggere i tuoi file dall'accesso 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, ad esempio:

  • Utilizzo di una chiave con supporto hardware: le versioni moderne di OpenSSH ti consentono di utilizzare i token di sicurezza FIDO2 per l'autenticazione e puoi configurare l'accesso al sistema operativo in modo che consenta solo i token di sicurezza registrati in Cloud Identity o Google Workspace. L'utilizzo di chiavi basate su hardware ti consente di evitare di memorizzare qualsiasi materiale della chiave privata 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 Windows CNG per proteggere le chiavi SSH.

Se non puoi utilizzare chiavi basate su hardware o gestite dal sistema operativo, puoi usare una passphrase per proteggere la tua chiave privata SSH: per utilizzare una chiave SSH protetta da passphrase, un malintenzionato non ha bisogno solo di una copia della chiave privata, ma deve anche conoscere la passphrase della chiave.

Utilizza le chiavi host per autenticare l'host

Quando crei una connessione SSH a un'istanza VM, la identifichi per il nome o l'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 falsificare le istanze VM e indurre 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 utilizzando le chiavi host SSH: la chiave host SSH di una VM viene generata al primo avvio e viene 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 di fiducia al primo utilizzo. L'efficacia delle chiavi host SSH può essere minata se un malintenzionato utilizza un attacco man-in-the-middle (MITM) per consentire a un client di connettersi e considerare attendibile la VM sbagliata al primo utilizzo. Un modo migliore per ottenere una chiave host è ottenerne una tramite un canale laterale attendibile prima di connettersi a una VM per la prima volta.

Puoi consentire all'interfaccia a riga di comando gcloud di ottenere le chiavi host tramite un canale secondario attivando gli attributi guest nel tuo progetto. La CLI gcloud legge quindi la chiave host di una VM prima che tu si connetta per la prima volta e la salva sul tuo computer locale.

Non lasciare credenziali personali sulle VM

Quando autorizzi l'interfaccia a riga di comando gcloud, lo strumento ottiene un token di aggiornamento OAuth e lo memorizza nella tua home directory locale. Quando esegui successivamente un comando gcloud CLI, l'interfaccia a riga di comando gcloud utilizza il token di aggiornamento 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 eseguire la riassegnazione dei privilegi o estendere il proprio accesso ad altre risorse (movimento laterale).

Quando sei connesso a un'istanza VM tramite SSH, evita di autorizzare gcloud CLI o le credenziali predefinite dell'applicazione (ADC) con le tue credenziali personali e lascia che gcloud CLI utilizzi l'account di servizio associato 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 Google Cloud servizi 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 accedere e gestire le istanze VM. Poiché questi strumenti potrebbero avere accesso a molte istanze VM (e ai relativi account di servizio 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, esiste un rischio maggiore che la chiave diventi accessibile a utenti non autorizzati e malintenzionati:

  • Gli utenti malintenzionati potrebbero cercare chiavi trapelate nel codice sorgente dei repository di origine pubblici.
  • In futuro, potresti decidere di trasformare un repository di origine privato in un repository pubblico senza prima controllare la presenza di chiavi.
  • Altri membri del team potrebbero memorizzare 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 effimere.

Passaggi successivi