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 chiave pubblica: Utenti vengono autenticati da un elemento in loro possesso, ovvero una chiave privata SSH. Se l'account le chiavi private non sono adeguatamente protette perché potrebbero cadere nelle mani di utenti malintenzionati che potrebbero utilizzare queste chiavi 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.

Gestisci le chiavi private SSH in modo simile alle chiavi degli account di servizio

Alcune delle tue istanze VM potrebbero essere collegate l'account di servizio. Il collegamento di un account di servizio a una VM consente ai carichi di lavoro in esecuzione Queste VM richiedere token di accesso di breve durata al server dei metadati per poter accedere alle API e alle risorse di 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 dai metadati o server web. 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 quando non sono protetti da passphrase, come le chiavi degli account di servizio: Entrambi i tipi di chiavi, se divulgati, potrebbero concedere l'accesso a Google Cloud a utenti malintenzionati Google Cloud.

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. Invece di lasciare che usano una coppia di chiavi SSH di lunga durata, per cui possono usare una nuova chiave SSH temporanea ogni volta che vengono eseguite.

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

  1. Autenticare come account di servizio in un modo che non richieda una chiave o un secret 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 su 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 in metadati di progetto o VM.

  4. Utilizza la chiave privata per stabilire le 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'uso di chiavi SSH temporanee può quindi ridurre il rischio di la perdita di credenziali e consente di utilizzare Cloud IAM come metodi di autenticazione e autorizzazione.

Usa 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 utente malintenzionato può utilizzarla per connettersi e autenticarsi alle istanze 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 della sessione per i servizi Google Cloud possono essere modi efficaci per ridurre il rischio di furto di 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 utilizzare i criteri firewall per assicurare che tutti gli accessi SSH vengano eseguiti tramite IAP.

IAP funge da proxy inverso e consente agli utenti di stabilire soltanto connessioni SSH Istanze VM se l'autenticazione è riuscita utilizzando le proprie credenziali Google. Inoltre, IAP ti consente limitare le VM a cui gli utenti possono connettersi, e imporre l'accesso sensibile al contesto.

Usare 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.

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 servizi Google Cloud in modo che le credenziali memorizzate nella cache vengano invalidate automaticamente e gli utenti debbano effettuare periodicamente l'autenticazione e l'MFA.

Se utilizzi il Single Sign-On con un IdP esterno, procedi nel seguente modo:

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

Per assicurarti che l'autenticazione MFA si applichi anche all'accesso SSH, devi inoltre 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 OS Login 2FA per individuale Istanze VM o interi progetti in modo che gli utenti debbano eseguire ogni volta l'autenticazione MFA stabiliscono una connessione SSH.

Utenti con il ruolo Amministratore istanza Compute o un ruolo equivalente per un'istanza VM o il progetto può disabilitare l'autenticazione a due fattori (2FA) di OS Login modificando i metadati dell'istanza. La l'efficacia di OS Login 2FA è pertanto limitata se non applichi anche 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 archivia nel della tua home directory. Il tuo sistema operativo potrebbe proteggere i tuoi file dall'accesso da altri utenti, ma se un utente malintenzionato riesce a superare le autorizzazioni del file system (ad ad esempio copiando e montando il disco su un'altra macchina, possono copiare 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 basata su hardware: le versioni moderne di OpenSSH consentono di utilizzare FIDO2 token di sicurezza 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 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, identifichi quest'ultima in base al nome o all'indirizzo IP. Nomi e indirizzi IP possono essere riassegnati e riutilizzati, mentre il nome che ieri faceva riferimento a una determinata istanza VM potrebbe non fare riferimento la stessa istanza VM. I malintenzionati potrebbero riassegnare o riutilizzare deliberatamente nomi o indirizzi IP per lo spoofing delle istanze VM e indurre gli utenti a connettersi una VM compromessa.

I client SSH possono rilevare le situazioni in cui un'istanza VM precedentemente attendibile era sostituito con un'istanza VM diversa utilizzando le chiavi host SSH: l'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 alla attendibilità al primo utilizzo . L'efficacia delle chiavi host SSH può essere compromessa se un utente malintenzionato utilizza un attacco man in the middle (MITM) per consentire al cliente di connettersi e fidarsi di quello sbagliato VM 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 a gcloud CLI di ottenere le chiavi host su un canale posteriore abilitando 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 gcloud CLI, lo strumento ottiene un token di aggiornamento OAuth e lo archivia nella 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 tuo computer locale potrebbe non essere accessibile ad altri utenti, ma su un'istanza VM alla tua home directory sono accessibili anche ad altri utenti che hanno sudo i privilegi sulla VM.

Se un utente malintenzionato riesce a ottenere i privilegi di sudo su una VM, potrebbe cercare i token di aggiornamento e altre credenziali di altri utenti le home directory Usare queste credenziali per aumentare i privilegi o estendere l'accesso ad altre risorse (Movimento laterale).

Quando hai una connessione a un'istanza VM su SSH, evita di autorizzare gcloud CLI o ADC con le tue credenziali personali e consenti gcloud CLI utilizza invece l'account di servizio collegato alla VM. Analogamente, evita di eseguire altri strumenti che potrebbero archiviare le credenziali personali della tua home directory.

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

Non inviare chiavi private SSH ai repository di codice sorgente

Alcuni strumenti di automazione come Ansible utilizzano SSH per accedere alle istanze VM e gestirle. Poiché questi strumenti potrebbero avere accesso a molte istanze VM (e alle relative account di servizio), le chiavi private SSH utilizzate da questi strumenti possono essere 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:

  • I malintenzionati potrebbero scansionare il codice sorgente dei repository di codice sorgente pubblici alla ricerca di chiavi trapelate.
  • In futuro, potrai decidere di trasformare un repository di codice sorgente privato in un senza prima verificare le chiavi.
  • Gli 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 dal codice sorgente e utilizzano chiavi SSH temporanee, se possibile.

Passaggi successivi