Best practice per il controllo dell'accesso tramite SSH

Questo documento descrive le best practice per controllare l'accesso tramite l'autenticazione SSH alle istanze di macchine virtuali (VM) Linux.

Per gestire in modo efficace l'accesso SSH alle istanze VM, devi consentire agli utenti di accedere quando ne hanno bisogno e revocare l'accesso quando non ne hanno più bisogno. Se la procedura di revoca dell'accesso non è affidabile o non copre tutte le risorse, gli utenti malintenzionati potrebbero riuscire a mantenere l'accesso anche dopo che l'accesso avrebbe dovuto essere revocato.

Le seguenti sezioni contengono best practice che ti aiutano a garantire un'efficace revoca dell'accesso e a proteggerti dalle minacce persistenti:

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.

Utilizza OS Login per garantire una valutazione continua dell'accesso in base ai criteri IAM

Le immagini Linux pubbliche di Compute Engine sono configurate per consentire l'autenticazione con chiave pubblica SSH. Per autorizzare la chiave pubblica di un utente e concedergli l'autorizzazione a stabilire una sessione SSH, puoi utilizzare uno dei seguenti due meccanismi:

  • Autorizzazione delle chiavi basata sui metadati: in qualità di amministratore, carichi la chiave pubblica di un utente nei metadati della VM o del progetto oppure consenti agli utenti di eseguire il caricamento autonomamente concedendo loro l'autorizzazione a modificare i metadati.

    Una chiave pubblica caricata nei metadati di una singola VM concede all'utente i privilegi di root solo per la VM; una chiave caricata nei metadati del progetto concede all'utente l'accesso a tutte le VM del progetto.

  • Autorizzazione delle chiavi OS Login: in qualità di utente, carichi una o più chiavi pubbliche nel tuo profilo OS Login, che fa parte del tuo account utente Google.

    In qualità di amministratore, puoi decidere se concedere a un utente i privilegi di amministratore o di utente normale sulla VM concedendo il ruolo IAM Utente amministratore OS Login o il ruolo IAM Utente OS Login.

    L'interfaccia a riga di comando gcloud, il client SSH in-browser della console Google Cloud e IAP Desktop rilevano automaticamente il meccanismo in uso e possono caricare la chiave di un utente di conseguenza.

Una differenza fondamentale tra i due meccanismi è il momento in cui l'accesso viene valutato in base alle policy IAM:

  • Con le chiavi dei metadati, l'accesso viene valutato una sola volta, al momento del caricamento della chiave.

    La chiave dell'utente è legata al ciclo di vita della VM o del progetto e rimane valida fino a quando non rimuovi la chiave o elimini la VM o il progetto. La sospensione o l'eliminazione dell'account utente non influisce sulla validità delle relative chiavi.

  • Con Accesso al sistema operativo, l'accesso viene valutato ogni volta che un utente tenta di stabilire una sessione SSH.

    La chiave dell'utente è legata al ciclo di vita del suo account utente. Se ospendi o elimini un utente in Cloud Identity o Google Workspace, le relative chiavi non possono più essere utilizzate per concedere l'accesso SSH.

L'utilizzo di chiavi basate su metadati può esporre a minacce di persistenza: gli utenti potrebbero mantenere l'accesso SSH per più tempo del necessario se la loro chiave pubblica non viene rimossa dai metadati in modo tempestivo e potrebbero persino mantenere l'accesso dopo aver lasciato l'organizzazione. Sebbene tu possa ridurre questo rischio esaminando regolarmente i metadati, questa operazione può essere difficile in ambienti più grandi e potrebbe non essere sufficiente perché le chiavi basate su metadati concedono agli utenti i privilegi di root.

Per proteggerti da queste minacce di persistenza, non consentire agli utenti di utilizzare chiavi basate su metadati. Configura invece i progetti per applicare l'utilizzo di OS Login.

Utilizzare i criteri dell'organizzazione per applicare l'utilizzo coerente di Accesso al sistema operativo

L'accesso al sistema operativo è controllato dalla chiave dei metadati enable-oslogin: l'impostazione di enable-oslogin su TRUE nei metadati del progetto o dell'istanza abilita l'accesso al sistema operativo, mentre impostandolo su FALSE lo disabilita.

Per modificare i metadati a livello di progetto, devi disporre dell'autorizzazione compute.projects.setCommonInstanceMetadata per il progetto. Questa autorizzazione fa parte dei ruoli Amministratore istanze Compute (roles/compute.instanceAdmin.v1) e Amministratore Compute (roles/compute.admin). Analogamente, la modifica dei metadati a livello di istanza richiede l'autorizzazione compute.instances.setMetadata sulla rispettiva istanza VM.

I metadati a livello di istanza hanno la precedenza su quelli a livello di progetto. L'impostazione di enable-oslogin su TRUE nei metadati del progetto non è quindi sufficiente per imporre l'utilizzo di OS Login in tutto il progetto: gli utenti con il ruolo Amministratore istanza Compute o con un accesso equivalente a un'istanza VM nel progetto possono ignorare l'impostazione aggiungendo enable-oslogin=FALSE ai metadati dell'istanza VM.

Per applicare un utilizzo coerente di OS Login, non fare affidamento sull'impostazione di enable-oslogin su TRUE nei metadati del progetto. Applica invece il valore Attiva l'accesso al sistema operativo per un'organizzazione utilizzando un criterio dell'organizzazione in modo che tutti i tentativi di impostare enable-oslogin su false nei metadati di istanza o progetto siano rifiutati.

Concedi ruoli con privilegi su base temporanea o per VM

Se hai istanze VM che eseguono carichi di lavoro diversi e sono gestite da team diversi, puoi semplificare la gestione dell'accesso implementando queste VM in progettiGoogle Cloud diversi e consentendo ai progetti di utilizzare una rete condivisa. Tuttavia, l'utilizzo di progetti separati non è sempre fattibile e alcuni dei tuoi progetti potrebbero contenere una combinazione di istanze VM, dove istanze VM diverse devono essere accessibili solo a utenti diversi.

Ogni volta che un progetto contiene una combinazione di istanze VM diverse, evita di concedere permanentemente agli utenti ruoli come Amministratore di istanze Compute a livello di progetto. Distingui invece tra accesso di sola visualizzazione e accesso privilegiato:

  • Concedi agli utenti il ruolo Visualizzatore Compute o un ruolo di visualizzazione equivalente a livello di progetto. Questo ruolo consente agli utenti di sfogliare le VM utilizzando la console Google Cloud, ma non consente loro di pubblicare chiavi SSH o di accedere alle VM.
  • Concedi agli utenti i ruoli OS Login Compute, Amministratore istanze Compute o altri ruoli privilegiati solo per singole VM o solo su base just-in-time.

Sospendere gli account utente quando gli utenti lasciano l'organizzazione

La sospensione o l'eliminazione di un account utente in Cloud Identity o Google Workspace comporta automaticamente la revoca delle autorizzazioni IAM dell'utente. Poiché Accesso sistema operativo controlla le autorizzazioni IAM di un utente prima di consentirgli di stabilire una sessione SSH, la sospensione o l'eliminazione di un account utente comporta anche la revoca dell'accesso alle VM che utilizzano Accesso sistema operativo.

Se hai configurato Cloud Identity o Google Workspace per utilizzare un IdP esterno per il Single Sign-On, i dipendenti hanno un account utente sia nel tuo IdP esterno sia in Cloud Identity o Google Workspace. La disattivazione o l'eliminazione dell'account utente di un dipendente nell'IDP esterno revoca la sua capacità di stabilire nuove sessioni del browser per accedere ai servizi Google, ma non ha alcun impatto immediato su OS Login: finché l'account utente Cloud Identity o Google Workspace del dipendente rimane attivo, OS Login continuerà a consentire all'utente di autenticarsi e stabilire connessioni SSH.

Per revocare in modo affidabile l'accesso SSH quando un utente lascia l'organizzazione, assicurati di sospendere o eliminare il suo account utente Cloud Identity o Google Workspace. Se utilizzi un IdP esterno, configuralo in modo da propagare gli eventi di sospensione dell'utente in modo che l'accesso al sistema operativo possa revocare l'accesso.

Evita di concedere l'accesso SSH alle VM con un account di servizio privilegiato

Se un'istanza VM ha un account di servizio associato, le applicazioni in esecuzione sulla VM possono richiedere credenziali di breve durata al server di metadati della VM e utilizzarle per agire come account di servizio.

L'accesso SSH a una VM ti concede privilegi simili: come un'applicazione, puoi richiedere credenziali di breve durata dal server dei metadati della VM e agire come account di servizio associato.

Poiché l'accesso SSH a una VM con un account di servizio associato ti consente di agire come account di servizio, Accesso sistema operativo richiede l'autorizzazione iam.serviceAccounts.actAs per l'account di servizio e la controlla ogni volta che ti colleghi all'istanza VM. In questo modo, l'accesso all'OS contribuisce a mantenere la sicurezza dell'account di servizio e a impedire che l'accesso SSH venga utilizzato in modo improprio per l'escalation dei privilegi.

Per ridurre ulteriormente i rischi associati alle VM con account di servizio privilegiati, valuta le seguenti alternative:

  • Non collegare un account di servizio alla VM, a meno che il workload non richieda l'accesso alle risorse Google Cloud .
  • Utilizza un account di servizio a scopo specifico e concedigli l'accesso solo alle risorse di cui ha bisogno il carico di lavoro.
  • Richiedi agli utenti di richiedere un accesso just-in-time instead of granting them access to the VM and service account on a permanent basis.

Limita l'utilizzo dei privilegi di root

Quando utilizzi OS Login e concedi a un utente il ruolo Utente OS Login (roles/compute.osLogin), assegni all'utente privilegi utente limitati sulla VM. Al contrario, quando concedi a un utente il ruolo Utente amministratore OS Login (roles/compute.osAdminLogin), utilizzi l'autorizzazione delle chiavi basata sui metadati anziché OS Login o consenti agli utenti di modificare i metadati della VM, concedi implicitamente all'utente i privilegi di amministratore della VM.

La concessione agli utenti di privilegi di root su una VM può esporre a rischi di persistenza: gli utenti potrebbero abusare di questi privilegi per creare nuovi account utente o installare backdoor per mantenere l'accesso permanente alla VM.

Per contribuire a ridurre questo rischio di persistenza, limita l'uso dei privilegi di root e concedi il ruolo Utente di accesso al sistema operativo (roles/compute.osLogin) solo quando i privilegi di root non sono richiesti.

Pre-crea i profili POSIX per garantire nomi utente e UID coerenti

Ogni VM Linux gestisce un database locale di utenti (/etc/passwd) e gruppi (/etc/groups). La prima volta che ti connetti a una VM Linux utilizzando SSH, l'ambiente guest crea automaticamente un account utente Linux e gli assegna un UID.

Quando utilizzi chiavi basate sui metadati, l'ambiente guest non collega l'utente Linux al tuo account utente Google e potrebbe assegnarti un UID diverso a ogni VM a cui ti colleghi. Se utilizzi protocolli come NFS che presuppongono UID coerenti in un ambiente che non impone UID coerenti sulle macchine, gli utenti potrebbero, accidentalmente o, nel caso di agenti malintenzionati, deliberatamente, essere in grado di eseguire l'accesso remoto come un altro utente.

Quando utilizzi chiavi basate su metadati, l'ambiente guest ti consente anche di scegliere il nome utente che vuoi utilizzare. Se scegli un nome utente utilizzato in precedenza da un collega, accedi con l'account creato inizialmente per il tuo collega.

Puoi evitare queste ambiguità di UID e nome utente utilizzando OS Login: la prima volta che accedo a una VM Linux utilizzando OS Login, l'ambiente guest crea un utente Linux in base al profilo POSIX del tuo account utente Google. Il profilo POSIX funge da modello per gli utenti Linux e definisce quanto segue:

  • un nome utente Linux univoco per tutti gli utenti dello stesso account Cloud Identity o Google Workspace
  • un UID e un GID univoci per tutti i Google Cloud progetti
  • un percorso della home directory
  • Configurazione aggiuntiva, ad esempio una shell di accesso

Se il tuo Account Google non ha un profilo POSIX al primo accesso, Accesso sistema operativo ne crea automaticamente uno.

Il nome utente e gli UID allocati da OS Login sono univoci all'interno del tuo Google Cloud ambiente, ma potrebbero sovrapporsi o essere incoerenti con i nomi utente e gli UID che utilizzi al di fuori di Google Cloud. Se hai bisogno che i nomi utente e gli UID di accesso al sistema operativo siano coerenti in altri ambienti, è meglio non fare affidamento sulla creazione automatica dei profili. Utilizza invece l'API Directory per pre-creare profili POSIX di OS Login e assegnare nomi utente, ID utente e ID gruppo personalizzati.

Passaggi successivi