Best practice per il controllo dell'accesso tramite accesso 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 l'accesso degli utenti quando ne hanno bisogno e revocarlo quando non è più necessario. Se il processo per la revoca dell'accesso non è affidabile o non copre tutte le risorse, i malintenzionati potrebbero riuscire a mantenere l'accesso anche dopo il loro accesso avrebbero dovuto essere revocati.

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 concedere per 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 di OS Login: come 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 norme 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. In fase di sospensione o l'eliminazione dell'account utente non influisce sulla validità delle chiavi.

  • Con OS Login, l'accesso viene valutato ogni volta che un utente tenta di stabilire una sessione SSH.

    La chiave dell'utente è legata al ciclo di vita dell'account utente. Se sospendere o eliminare un utente in Cloud Identity o Google Workspace; le loro chiavi non possono più essere utilizzate per concedere l'accesso SSH.

L'uso di chiavi basate su metadati può esporti a minacce di persistenza: gli utenti potrebbero conservano l'accesso SSH per più tempo del necessario se la chiave pubblica non viene rimossa dai metadati in modo tempestivo e potrebbero anche mantenere l'accesso dopo aver lasciato all'interno dell'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'OS Login è controllato dalla chiave di metadati enable-oslogin: L'impostazione di enable-oslogin su TRUE nei metadati di progetto o istanza abilita OS Login, Se lo imposti su FALSE, l'OS Login viene disabilitato.

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

I metadati a livello di istanza hanno la precedenza su quelli a livello di progetto. Impostare enable-oslogin su TRUE nei metadati di progetto non è quindi sufficiente per applicare in modo forzato l'uso di OS Login in tutto il progetto: Utenti con Amministratore istanze Compute o un accesso equivalente a un'istanza VM nel progetto può sostituire la tua 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 Attivare OS Login per un'organizzazione utilizzando un criterio dell'organizzazione in modo che qualsiasi tentativo di impostare enable-oslogin su false nell'istanza o nel progetto vengono 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 vari puoi semplificare la gestione degli accessi eseguendo il deployment di queste VM in diversi ai progetti Google Cloud e utilizzo di una rete condivisa. Tuttavia, non è sempre possibile utilizzare progetti separati e alcuni dei tuoi progetti potrebbero contengono una combinazione di istanze VM, dove diverse istanze VM devono accessibile a diversi utenti.

Ogni volta che un progetto contiene una combinazione di istanze VM diverse, evita concedendo in modo permanente ruoli agli utenti come Amministratore 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 equivalente di sola visualizzazione nel progetto. livello. Questo ruolo consente agli utenti di sfogliare le VM utilizzando la console Google Cloud, ma non permette di pubblicare chiavi SSH o di accedere alle VM.
  • Concedi agli utenti Compute OS Login, Amministratore istanze Compute o altri privilegi ruoli solo per singole VM solo nel momento giusto.

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 l'utilizzo un IdP esterno per il Single Sign-On, i dipendenti avranno un account utente dell'IdP esterno e 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 che hanno un account di servizio con privilegi

Se un'istanza VM è collegata l'account di servizio, le applicazioni in esecuzione sulla VM possono richiedere e credenziali dal server metadati della VM e utilizzare queste credenziali 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.

Perché avere accesso SSH a una VM con un account di servizio collegato ti consente di agire come account di servizio, OS Login richiede l'autorizzazione iam.serviceAccounts.actAs autorizzazione per l'account di servizio e ne verifica la presenza ogni volta connettersi all'istanza VM. In questo modo, OS Login aiuta a mantenere la sicurezza l'account di servizio e impedire l'uso illecito dell'accesso SSH 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 carico di lavoro non richieda alle risorse Google Cloud.
  • Utilizzare un account di servizio monouso e concedere l'accesso solo alle risorse necessarie al carico di lavoro.
  • Richiedi agli utenti di richiedere un accesso just-in-time anziché concedere l'accesso permanente alla VM e all'account di servizio.

Limitare l'uso dei privilegi root

Quando utilizzi OS Login e concedi a un utente l'utente OS Login (roles/compute.osLogin) , stai assegnando all'utente i privilegi utente con limitazioni 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.

Crea in anticipo 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 usi chiavi basate su metadati, l'ambiente guest non collega l'utente Linux al tuo account utente Google e potrebbe assegnarti un UID diverso su ogni VM connettersi. Se utilizzi protocolli come NFS che presuppongono UID coerenti in un ambiente che non applica UID coerenti su più macchine, gli utenti potrebbero, per errore, o nel caso malintenzionati, deliberatamente, essere in grado di eseguire l'accesso da remoto come un utente diverso.

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 ambiguità di UID e nome utente utilizzando OS Login: la prima volta se accedi a una VM Linux utilizzando OS Login, l'ambiente guest crea un utente 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 della stessa Cloud Identity o un account Google Workspace
  • Un UID e un GID univoci per tutti i progetti Google Cloud
  • 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 Accesso sistema operativo sono univoci all'interno del tuo ambiente Google Cloud, 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