Best practice per il controllo dell'accesso al login SSH

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

Per gestire in modo efficace l'accesso tramite 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, dei malintenzionati potrebbero riuscire a mantenere l'accesso anche dopo che avrebbe dovuto essere revocato.

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

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.

Utilizza OS Login per garantire una valutazione continua dell'accesso in base alle policy IAM

Le immagini Linux pubbliche di Compute Engine sono configurate per consentire l'autenticazione a chiave pubblica SSH. Per autorizzare la chiave pubblica di un utente e concedere 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 personalmente il caricamento 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 in questione; una chiave caricata nei metadati del progetto concede all'utente l'accesso a tutte le VM nel 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 OS Login Admin User o il ruolo IAM OS Login User.

    gcloud CLI, il client SSH nel browser della console Trusted 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 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 del suo account utente. Se sospendi 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 tramite SSH per più tempo del necessario se la loro chiave pubblica non viene rimossa tempestivamente dai metadati e potrebbero persino mantenere l'accesso dopo aver lasciato l'organizzazione. Per quanto 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 imporre l'utilizzo di OS Login.

Utilizza le policy dell'organizzazione per imporre l'utilizzo coerente di OS Login

OS Login è controllato dalla chiave dei metadati enable-oslogin: l'impostazione di enable-oslogin su TRUE nei metadati del progetto o dell'istanza attiva OS Login, mentre l'impostazione su FALSE lo disattiva.

Per modificare i metadati a livello di progetto, devi disporre dell'autorizzazione compute.projects.setCommonInstanceMetadata sul progetto. Questa autorizzazione fa parte dei ruoli Compute Instance Admin (roles/compute.instanceAdmin.v1) e Compute Admin (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 Compute Instance Admin o con accesso equivalente a un'istanza VM nel progetto possono sostituire l'impostazione aggiungendo enable-oslogin=FALSE ai metadati dell'istanza VM.

Per imporre l'utilizzo coerente di OS Login, non fare affidamento sull'impostazione di enable-oslogin su TRUE nei metadati del progetto. Invece, attiva OS Login per un'organizzazione utilizzando una policy dell'organizzazione in modo che tutti i tentativi di impostare enable-oslogin su false nei metadati dell'istanza o del progetto vengano rifiutati.

Concedi ruoli con privilegi temporaneamente o solo sulle singole VM

Se hai istanze VM che eseguono workload diversi e sono gestite da team diversi, puoi semplificare la gestione degli accessi eseguendo il deployment di queste VM in progettiTrusted Cloud diversi e consentendo ai progetti di utilizzare una rete condivisa. Tuttavia, l'utilizzo di progetti distinti non è sempre fattibile e alcuni dei tuoi progetti potrebbero contenere una combinazione di istanze VM diverse, che devono essere accessibili solo a utenti diversi.

Se un progetto contiene una combinazione di istanze VM diverse, evita di concedere agli utenti in modo permanente ruoli come Compute Instance Admin a livello di progetto. Distingui invece tra accesso di sola visualizzazione e accesso con privilegi:

  • Concedi agli utenti il ruolo Compute Viewer o un ruolo di sola visualizzazione equivalente a livello di progetto. Questo ruolo consente agli utenti di sfogliare le VM utilizzando la console Trusted Cloud , ma non consente loro di pubblicare chiavi SSH o di accedere alle VM.
  • Concedi agli utenti i ruoli Compute OS Login, Compute Instance Admin o altri ruoli con privilegi solo su singole VM o solo una tantum.

Sospendi 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é OS Login controlla le autorizzazioni IAM di un utente prima di consentire di stabilire una sessione SSH, la sospensione o l'eliminazione di un account utente comporta anche la revoca dell'accesso alle VM che utilizzano OS Login.

Se hai configurato Cloud Identity o Google Workspace per utilizzare un IdP esterno per 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 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 tramite 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 OS Login possa revocare l'accesso.

Evita di concedere l'accesso tramite SSH alle VM che hanno un service account con privilegi

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

L'accesso tramite SSH a una VM concede privilegi simili: come un'applicazione, puoi richiedere credenziali di breve durata al server di metadati della VM e agire come il service account associato.

Poiché l'accesso tramite SSH a una VM con un service account collegato ti consente di agire come il service account, OS Login richiede di avere l'autorizzazione iam.serviceAccounts.actAs sul service account e la controlla ogni volta che ti connetti all'istanza VM. In questo modo, OS Login contribuisce a mantenere la sicurezza del service account e a impedire che l'accesso tramite SSH venga utilizzato in modo improprio per l'escalation dei privilegi.

Per mitigare ulteriormente i rischi associati alle VM che hanno service account con privilegi, prendi in considerazione le seguenti alternative:

  • Non collegare un service account alla VM, a meno che il workload non richieda l'accesso alle risorse Trusted Cloud .
  • Utilizza un service account a scopo specifico e concedi l'accesso solo alle risorse richieste dal workload.
  • Rendi obbligatorio che gli utenti richiedano un accesso just-in-time anziché concedere loro l'accesso permanente alla VM e al service account.

Limita l'utilizzo dei privilegi di root

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

La concessione agli utenti dei 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 solo il ruolo OS Login User (roles/compute.osLogin) 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, a cui assegna un UID.

Quando utilizzi 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 a cui ti connetti. Se utilizzi protocolli, come NFS, che presuppongono UID coerenti in un ambiente che non impone UID coerenti sulle macchine, gli utenti potrebbero involontariamente (o deliberatamente, nel caso di malintenzionati) riuscire a 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, accederai con l'account creato inizialmente per il collega.

Puoi evitare queste ambiguità di UID e nome utente utilizzando OS Login: al primo accesso 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 template 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 progetti Trusted 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, OS Login ne crea automaticamente uno per te.

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

Passaggi successivi