Best practice per il controllo dell'accesso alla rete SSH


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

Per connettersi a un'istanza VM tramite SSH, un utente deve accedere alla VM e credenziali SSH valide. Per impostazione predefinita, Compute Engine utilizza una regola firewall che non limita l'accesso alla rete SSH, ma consente a chiunque su internet di connettersi alla porta 22 delle istanze VM. Sebbene sia comodo per gli sviluppatori iniziare rapidamente senza considerare i controlli di rete o di sicurezza, consentire agli utenti di connettersi da qualsiasi dispositivo, rete e posizione comporta dei rischi:

  • Gli utenti potrebbero connettersi da dispositivi o reti non attendibili.
  • I malintenzionati potrebbero lanciare attacchi di forza bruta e tentare di compromettere delle tue istanze VM.
  • Gli utenti malintenzionati con accesso alle credenziali SSH che sono state divulgate o non revocate in tempo possono utilizzare le credenziali per accedere a una VM da qualsiasi rete.

Le seguenti sezioni descrivono come ridurre il rischio limitando le reti, le località o i dispositivi da cui gli utenti possono stabilire una connessione SSH alle tue VM:

Il documento è incentrato sulle pratiche specifiche di 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.

Ridurre l'esposizione della rete

Se consenti agli utenti di stabilire connessioni SSH da qualsiasi luogo, devi fare affidamento completamente sui meccanismi di autenticazione e autorizzazione SSH per proteggere le tue VM. Puoi ridurre i rischi e stabilire un ulteriore livello di protezione per ridurre l'esposizione della rete delle VM.

Esistono diversi approcci per ridurre l'esposizione alla rete delle VM. Per identificare l'approccio più adatto al tuo ambiente, devi considerare una serie di fattori, come illustrato dal seguente diagramma di flusso:

Riduzione dell'esposizione della rete

  • Accesso esterno: il primo fattore da considerare è se la VM necessita solo sia accessibile all'interno della rete VPC o se è necessaria accessibile anche dall'esterno.

    Se l'accesso interno al VPC è sufficiente, non è necessario assegnare un indirizzo IP alla VM, ma devi comunque decidere come gestire l'accesso.

  • Dimensioni della rete interna: se l'accesso interno alla VPC è sufficiente, il secondo fattore da considerare è la dimensione della rete interna.

    Nelle reti più piccole, potrebbe essere sufficiente usare regole firewall che consentano in entrata nella porta 22 dagli indirizzi interni per proteggere le tue VM. Nella reti più grandi, basarsi solo sulle regole firewall potrebbe essere troppo limitante: In questi casi, puoi trarre vantaggio dall'utilizzo dell'inoltro TCP di Identity-Aware Proxy per imporre l'accesso sensibile al contesto alle VM.

  • Design del perimetro dei Controlli di servizio VPC: il prossimo fattore da considerare è se l'istanza VM fa parte di un perimetro dei Controlli di servizio VPC.

    Se la VM fa parte di un perimetro di servizio, qualsiasi accesso API dalla VM è considerata origine dall'interno del perimetro. Quando concedere a un utente che si trova all'esterno del perimetro di SSH l'accesso a una VM all'interno il perimetro, può potenzialmente copiare i dati da quest'ultimo workstation locale o viceversa, questo può compromettere la riservatezza l'integrità dei dati del tuo perimetro.

    Ogni volta che devi concedere l'accesso SSH a un'istanza VM che fa parte di un perimetro di Controlli di servizio VPC, utilizza l'inoltro TCP IAP. Per impostazione predefinita, IAP rileva se la workstation dell'utente fa parte dello stesso perimetro di Controlli di servizio VPC e blocca i tentativi di accesso dall'esterno del perimetro di servizio. Per consentire l'accesso esterno, utilizza le regole di ingresso e configurale in modo da applicare l'accesso sensibile al contesto.

  • Gestione dei dispositivi client: l'ultimo fattore da considerare è il modo in cui i dispositivi client sono gestiti, perché questo determina i modi in cui e controllare l'accesso sensibile al contesto.

    L'accesso sensibile al contesto è più efficace quando Gestore contesto accesso ha accesso a un'ampia gamma di indicatori su un utente, il suo dispositivo e i suoi posizione geografica, pertanto funziona in combinazione con Chrome Enterprise Premium: se utilizzi Chrome Enterprise Premium per gestire i tuoi dispositivi, poi puoi configurare livelli di accesso che controllare l'accesso in base alla postura del dispositivo. Puoi quindi applicare questo livello di accesso all'accesso SSH utilizzando l'inoltro TCP di IAP in combinazione con le associazioni di accesso o le condizioni IAM.

    Se non hai il controllo della configurazione di un dispositivo client, devi considerare non gestito e potenzialmente non attendibile.

    Per consentire l'accesso dai dispositivi non gestiti, puoi anche utilizzare IAP è possibile gestire l'accesso solo in base all'identità dell'utente e all'indirizzo IP del dispositivo. Poiché Gestore contesto accesso non ha accesso a nessun indicatore del dispositivo, non potrai limitare l'accesso in base alla posizione del dispositivo.

In base ai fattori e utilizzando il diagramma di flusso, puoi identificare l'approccio per ridurre l'esposizione alla rete più adatto al tuo ambiente. Le seguenti sezioni a descrivere questi approcci in modo più dettagliato.

Accesso SSH basato su IAP

L'idea di questo approccio è consentire l'accesso SSH solo attraverso Inoltro TCP IAP e consentire a IAP di controllare l'accesso in base all'identità dell'utente.

Consigliamo questo approccio per le istanze VM per le quali si applica quanto segue:

  • L'istanza VM deve essere accessibile dall'esterno o da una rete interna di grandi dimensioni.
  • La VM non fa parte di un perimetro dei Controlli di servizio VPC.

Per impostazione predefinita, un'istanza VM con un indirizzo IP esterno consente l'accesso SSH firewall predefiniti consentono le connessioni dalla rete internet pubblica alla porta 22, ma non è un approccio consigliato. Questo approccio può aumentare significativamente il rischio che la VM sia soggetta ad attacchi come i seguenti:

  • Utilizzo di credenziali non revocate: gli ex dipendenti di cui l'accesso non è stato completamente revocato potrebbero continuare ad accedere alla VM.
  • Abuso di credenziali valide: malintenzionati in possesso di credenziali rubate o divulgate potrebbero utilizzarle per accedere.
  • Denial of service: i malintenzionati potrebbero tentare di esaurire le risorse della VM inondandola di richieste.

Un modo più sicuro per attivare l'accesso SSH esterno a un'istanza VM è utilizzare il forwarding TCP IAP. Come un bastion host o un proxy inverso, il forwarding TCP dell'IAP agisce da intermediario tra il dispositivo client e la VM.

Quando l'inoltro TCP IAP esegue le seguenti quattro funzioni, un utente tenta di stabilire una connessione SSH:

  • Autenticazione:IAP verifica che l'utente possieda una credenziale Google valida.
  • Autorizzazione: IAP controlla i criteri IAM per verificare che all'utente sia stata concessa l'autorizzazione per connettersi alla VM tramite IAP.
  • Accesso sensibile al contesto: facoltativamente, IAP può verificare l'utente, il dispositivo e la posizione soddisfino determinati livelli di accesso.
  • Controllo: quando gli audit log di accesso ai dati sono abilitati, IAP registra ogni tentativo riuscito e non riuscito di connessione a un'istanza VM.

Agendo da intermediario ed eseguendo queste funzioni, l'IAP consente di eliminare la necessità di assegnare un indirizzo IP esterno alla VM e fornisce un ulteriore livello di sicurezza.

Accesso SSH sensibile al contesto basato su IAP

L'idea di questo approccio è consentire l'accesso SSH solo tramite l'inoltro TCP IAP e consentire a IAP di controllare l'accesso in base all'identità dell'utente e ad altri fattori.

Consigliamo questo approccio per le istanze VM per le quali si applica quanto segue:

  • L'istanza VM deve essere accessibile dall'esterno della VPC e delle reti collegate alla VPC.
  • La VM non fa parte di un perimetro dei Controlli di servizio VPC.
  • La VM deve essere accessibile solo da determinati dispositivi, reti o località.

Quando concedi a un utente l'accesso SSH a un'istanza VM, direttamente o tramite IAP. Per impostazione predefinita, possono accedere all'istanza VM da qualsiasi dispositivo, rete e posizione. Sebbene sia pratico per gli utenti, questo livello di accesso aumenta i rischi in quanto gli utenti potrebbero connettersi da dispositivi compromessi o da reti non attendibili.

Per ridurre il rischio, configura l'inoltro TCP IAP in modo che gli utenti possano accedere alle istanze VM solo da determinati dispositivi o località. Puoi configurare questo tipo di accesso sensibile al contesto in due modi:

  • Associazioni di accesso: puoi creare un livello di accesso e assegnarlo a un gruppo tramite un'associazione di accesso. Le associazioni di accesso sono criteri basati su moduli o identità e si applicano a tutte le risorse a cui un utente tenta di accedere, tra cui IAP, ma anche altre API e la console Google Cloud.

    L'uso delle associazioni di accessi funziona meglio se vuoi garantire che l'accesso sensibile al contesto in modo uniforme su tutte le risorse.

  • Condizioni IAM: puoi creare un livello di accesso e assegnarlo alle singole associazioni di ruoli IAM utilizzando Condizioni IAM.

    L'uso delle associazioni di ruoli IAM è un tipo di criterio basato sulle risorse e l'approccio funziona meglio se vuoi applicare criteri diversi diversi set di VM.

I livelli di accesso di base ti consentono di limitare l'accesso in base alla rete o alla geolocalizzazione. Come se sei abbonato a Chrome Enterprise Premium, puoi limitare l'accesso anche in base ad altre come forza delle credenziali, la configurazione del browser utilizzato per l'autenticazione posizione del dispositivo.

Accesso SSH basato su Controlli di servizio VPC

L'idea di questo approccio è consentire l'accesso SSH solo tramite IAP l'inoltro TCP e configurare il perimetro di servizio per consentire IAP in entrata per certe identità e le nostre fonti.

Consigliamo questo approccio per le istanze VM che fanno parte di un Perimetro Controlli di servizio VPC.

Concedere agli utenti l'accesso SSH esterno a una VM che fa parte di un perimetro di servizio può essere rischioso perché potrebbe consentire agli utenti di minare il perimetro di Controlli di servizio VPC esfiltrando i dati tramite SSH.

Se consenti l'accesso SSH solo tramite l'inoltro TCP IAP, puoi ridurre questo rischio e assicurarsi che tutti gli accessi SSH siano soggetti alla configurazione del tuo perimetro Controlli di servizio VPC:

  • Se un utente tenta di connettersi dall'esterno del perimetro di servizio (come illustrato nell'esempio precedente), l'inoltro TCP IAP non solo verifica se all'utente è concesso l'accesso IAM alla VM, ma verifica anche se la richiesta soddisfa una delle regole in entrata del perimetro.
  • Se un utente tenta di connettersi dall'interno del perimetro di servizio, IAP Il protocollo TCP-forwarding controlla anche se all'utente viene concesso l'accesso IAM. alla VM, ma ignorano le regole in entrata dei Controlli di servizio VPC.

    IAP considera una connessione come origine dall'interno di una perimetro di servizio se si applica una delle seguenti condizioni:

    • L'IP di origine è l'indirizzo IP esterno di una VM che fa parte di il perimetro di servizio.
    • La connessione viene effettuata tramite l'accesso privato Google da una VM che fa parte del perimetro del servizio.
    • La connessione viene effettuata tramite un endpoint di accesso Private Service Connect che fa parte del perimetro di servizio.

Accesso SSH interno controllato dal firewall

L'idea di questo approccio è di non consentire tutto l'accesso esterno e di consentire solo l'accesso SSH interno alla VPC.

Puoi utilizzare questo approccio per le istanze VM per le quali si applica quanto segue:

  • L'istanza VM non deve essere accessibile esternamente.
  • La VM è connessa a una rete interna di piccole o medie dimensioni.
  • La VM non fa parte di un perimetro dei Controlli di servizio VPC.

Per non consentire del tutto l'accesso esterno, puoi procedere in uno dei seguenti modi:

  • Esegui il deployment delle istanze VM senza un indirizzo IP esterno.
  • Configura le regole del firewall in modo che il traffico SSH in entrata da intervalli IP esterni al VPC non è consentito.

Disattivare l'accesso alla console seriale

Per risolvere i problemi relativi al malfunzionamento delle istanze VM, Compute Engine ti consente di connetterti alla console della porta seriale di un'istanza tramite un gateway SSH, ssh-serialport.googleapis.com. Questo gateway è accessibile pubblicamente su internet.

Il gateway SSH accede alla VM tramite l'hypervisor sottostante anziché alla rete VPC. L'accesso alla console seriale è quindi controllato dai criteri IAM e non dalle regole del firewall.

Se consenti agli utenti di accedere alla console seriale di una VM, la VM potrebbe rimanere involontariamente esposta. Per evitare questa sovraesposizione, utilizza il compute.disableSerialPortAccess vincolo dei criteri dell'organizzazione per disattivare l'accesso alla console seriale, e rimuovi temporaneamente il vincolo quando hai bisogno di accedere di emergenza alla porta seriale della VM.

Utilizza una VM bastion se hai bisogno della registrazione delle sessioni

Agendo da intermediario tra i dispositivi client e le VM, il forwarding TCP IAP esegue funzioni che vengono comunemente eseguite da bastion host o jump server. Queste funzioni includono:

  • Applicazione dei criteri di accesso in modo centralizzato
  • Controllo dell'accesso

A differenza di alcuni bastion host, l'inoltro TCP IAP Connessioni SSH: quando stabilisci una connessione SSH a una VM tramite IAP TCP forwarding, la connessione SSH è protetta con crittografia end-to-end tra il client e la VM. A causa di questa crittografia end-to-end, il forwarding TCP IAP non può ispezionare i contenuti della sessione SSH e non fornisce funzionalità di registrazione della sessione. Gli audit log IAP contengono metadati di connessione, ma non rivelano informazioni sui contenuti della sessione.

Se hai bisogno di registrare le sessioni, utilizza una VM bastion:

  • Configura la VM bastione in modo che interrompa le connessioni SSH e registri i relativi contenuti. Assicurati di limitare l'utilizzo del reindirizzamento delle porte SSH, in quanto potrebbe compromettere l'efficacia della registrazione della sessione.
  • Configura le regole firewall delle VM di destinazione in modo che le connessioni SSH siano consentite solo dalla VM bastion.
  • Consenti l'accesso alla VM bastion solo tramite l'inoltro TCP IAP

Utilizza i criteri firewall per limitare l'esposizione SSH

Dopo aver stabilito quale modo per limitare l'esposizione SSH che funzioni al meglio per il tuo ambiente, devi assicurarti che tutte le VM e tutti i progetti configurate di conseguenza. In particolare, devi assicurarti che tutti i progetti utilizzino un insieme coerente di regole firewall che determinano come può essere utilizzato SSH.

Per applicare un insieme di regole firewall a più progetti, usa criteri firewall gerarchici e si applicano alle cartelle nella tua gerarchia delle risorse.

Ad esempio, per contribuire a garantire che tutto l'accesso SSH venga eseguito tramite il forwarding TCP di IAP, applica un criterio firewall che includa le seguenti due regole personalizzate (in ordine di priorità):

  1. Consenti il traffico in entrata da 35.235.240.0/20 alla porta 22 delle VM selezionate. 35.235.240.0/20 è l'intervallo IP utilizzato dall'inoltro TCP IAP.
  2. Nega il traffico in entrata da 0.0.0.0/0 alla porta 22 di tutte le VM.

Passaggi successivi