Práticas recomendadas para controlar o acesso à rede SSH

Este documento descreve as práticas recomendadas para controlar o acesso à rede SSH a instâncias de máquinas virtuais (VMs) Linux.

Para estabelecer ligação a uma instância de VM através do SSH, um utilizador precisa de acesso à rede da instância de VM e de credenciais SSH válidas. Por predefinição, o Compute Engine usa uma regra de firewall que não restringe o acesso à rede SSH, mas permite que qualquer pessoa na Internet se ligue à porta 22 de instâncias de VM. Embora seja conveniente para os programadores começarem rapidamente sem considerar os controlos de rede ou de segurança, permitir que os utilizadores se liguem a partir de qualquer dispositivo, rede e localização acarreta riscos:

  • Os utilizadores podem estabelecer ligação a partir de dispositivos ou redes não fidedignos.
  • Os intervenientes prejudiciais podem lançar ataques de força bruta e tentar comprometer as suas instâncias de VM.
  • Os autores de ameaças com acesso a credenciais de SSH que foram divulgadas ou não foram revogadas a tempo podem usar as credenciais para aceder e iniciar sessão numa VM a partir de qualquer rede.

As secções seguintes descrevem como pode reduzir o risco limitando as redes, as localizações ou os dispositivos a partir dos quais os utilizadores podem estabelecer uma ligação SSH às suas VMs:

O documento centra-se em práticas específicas Google Cloud ou de particular relevância quando usa o SSH no Google Cloud. O documento não aborda as práticas recomendadas para implementações específicas de clientes ou servidores SSH.

Reduza a exposição da rede

Permitir que os utilizadores estabeleçam ligações SSH a partir de qualquer lugar significa que depende completamente dos mecanismos de autenticação e autorização SSH para proteger as suas VMs. Pode reduzir o risco e estabelecer uma camada adicional de proteção reduzindo a exposição de rede das VMs.

Existem várias abordagens para reduzir a exposição de rede das suas VMs. Para identificar a abordagem mais adequada ao seu ambiente, tem de considerar vários fatores, conforme ilustrado no seguinte fluxograma:

Reduzir a exposição da rede

  • Acesso externo: o primeiro fator a considerar é se a VM só precisa de ser acessível na rede VPC ou se também precisa de ser acessível externamente.

    Se o acesso interno da VPC for suficiente, não precisa de atribuir um endereço IP externo à VM, mas tem de decidir como gerir o acesso.

  • Tamanho da rede interna: se o acesso interno da VPC for suficiente, o segundo fator a considerar é o tamanho da sua rede interna.

    Em redes mais pequenas, pode ser suficiente usar regras de firewall que permitam a entrada na porta 22 a partir de endereços internos para ajudar a proteger as suas VMs. Em redes maiores, confiar apenas nas regras de firewall pode ser demasiado limitativo: nestes casos, pode beneficiar da utilização do encaminhamento TCP do Identity-Aware Proxy para aplicar o acesso sensível ao contexto às VMs.

  • Estrutura do perímetro dos VPC Service Controls: o fator seguinte a considerar é se a instância de VM faz parte de um perímetro dos VPC Service Controls.

    Se a VM fizer parte de um perímetro de serviço, qualquer acesso à API originário da VM é considerado originário de dentro do perímetro. Quando concede a um utilizador situado fora do perímetro acesso SSH a uma VM dentro do perímetro, este pode potencialmente copiar dados do perímetro para a sua estação de trabalho local ou vice-versa. Isto pode colocar em risco a confidencialidade e a integridade dos dados do seu perímetro.

    Sempre que precisar de conceder acesso SSH a uma instância de VM que faça parte de um perímetro dos VPC Service Controls, use o encaminhamento TCP do IAP. O IAP deteta se a estação de trabalho do utilizador faz parte do mesmo perímetro dos VPC Service Controls e bloqueia as tentativas de acesso provenientes de fora do perímetro de serviço por predefinição. Para permitir o acesso externo, use regras de entrada e configure-as para aplicar o acesso sensível ao contexto.

  • Gestão de dispositivos cliente: o fator final a considerar é a forma como os seus dispositivos cliente são geridos, uma vez que isso determina as formas como pode controlar o acesso sensível ao contexto.

    O acesso sensível ao contexto é mais eficaz quando o Access Context Manager tem acesso a um conjunto abrangente de sinais sobre um utilizador, o respetivo dispositivo e a respetiva localização e, por conseguinte, funciona em conjunto com o Chrome Enterprise Premium: se usar o Chrome Enterprise Premium para gerir os seus dispositivos, pode configurar níveis de acesso que controlam o acesso com base na postura do dispositivo. Em seguida, pode aplicar este nível de acesso ao acesso SSH através do encaminhamento TCP do IAP em combinação com associações de acesso ou condições do IAM.

    Se não controlar a configuração de um dispositivo cliente, tem de o considerar não gerido e potencialmente não fidedigno.

    Para permitir o acesso a partir de dispositivos não geridos, também pode usar o encaminhamento TCP do IAP, mas só pode gerir o acesso com base na identidade do utilizador e no endereço IP do dispositivo. Uma vez que o Access Context Manager não tem acesso a sinais de dispositivos, não pode restringir o acesso com base na postura do dispositivo.

Com base nos fatores e usando o fluxograma, pode identificar a abordagem para reduzir a exposição da rede mais adequada ao seu ambiente. As secções seguintes descrevem estas abordagens mais detalhadamente.

Acesso SSH baseado no IAP

A ideia desta abordagem é permitir apenas o acesso SSH através do encaminhamento TCP do IAP e deixar que o IAP controle o acesso com base na identidade do utilizador.

Recomendamos esta abordagem para instâncias de VMs às quais se aplica o seguinte:

  • A instância de VM tem de estar acessível externamente ou a partir de uma grande rede interna.
  • A VM não faz parte de um perímetro dos VPC Service Controls.

Por predefinição, uma instância de VM com um endereço IP externo permite o acesso SSH porque as firewalls predefinidas permitem ligações da Internet pública à porta 22, mas esta não é uma abordagem recomendada. Esta abordagem pode aumentar significativamente o risco de a VM ficar sujeita a ataques, como os seguintes:

  • Utilização de credenciais não revogadas: os antigos funcionários cujo acesso não tenha sido totalmente revogado podem continuar a aceder à VM.
  • Abuso de credenciais válidas: os intervenientes prejudiciais na posse de credenciais roubadas ou divulgadas podem usá-las para iniciar sessão.
  • Negação de serviço: os intervenientes mal intencionados podem tentar esgotar os recursos da VM inundando-a com pedidos.

Uma forma mais segura de ativar o acesso SSH externo a uma instância de VM é usar o encaminhamento TCP do IAP. Semelhante a um anfitrião de baluarte ou um proxy inverso, o encaminhamento TCP do IAP funciona como um intermediário entre o dispositivo cliente e a VM.

O encaminhamento TCP do IAP executa as seguintes quatro funções quando um utilizador tenta estabelecer uma ligação SSH:

  • Autenticação: a IAP verifica se o utilizador tem uma credencial Google válida.
  • Autorização: o IAP verifica as políticas de IAM para confirmar que foi concedida autorização ao utilizador para se ligar à VM através do IAP.
  • Acesso sensível ao contexto: opcionalmente, o IAP pode verificar se o utilizador, o respetivo dispositivo e a localização satisfazem determinados níveis de acesso.
  • Auditoria: quando os registos de acesso aos dados estão ativados, o IAP regista cada tentativa bem-sucedida e falhada de ligação a uma instância de VM.

Ao atuar como intermediário e realizar estas funções, o IAP remove a necessidade de atribuir um endereço IP externo à VM e fornece uma camada de segurança adicional.

Acesso SSH sensível ao contexto baseado no IAP

A ideia desta abordagem é permitir apenas o acesso SSH através do encaminhamento TCP do IAP e deixar que o IAP controle o acesso com base na identidade do utilizador e em fatores adicionais.

Recomendamos esta abordagem para instâncias de VMs às quais se aplica o seguinte:

  • A instância de VM tem de estar acessível a partir do exterior da VPC e das redes que estão ligadas à VPC.
  • A VM não faz parte de um perímetro dos VPC Service Controls.
  • A VM só precisa de estar acessível a partir de determinados dispositivos, redes ou localizações.

Quando concede a um utilizador acesso SSH a uma instância de VM, seja diretamente ou através do IAP, por predefinição, este pode aceder à instância de VM a partir de qualquer dispositivo, rede e localização. Embora seja conveniente para os utilizadores, este nível de acesso aumenta os riscos, uma vez que os utilizadores podem estar a estabelecer ligação a partir de dispositivos comprometidos ou redes não fidedignas.

Para reduzir o risco, configure o encaminhamento TCP do IAP para que os utilizadores só possam aceder a instâncias de VMs a partir de determinados dispositivos ou localizações. Pode configurar este acesso sensível ao contexto de duas formas:

  • Associações de acesso: pode criar um nível de acesso e atribuí-lo a um grupo através de uma associação de acesso. As associações de acesso são uma forma de política baseada na identidade e aplicam-se a todos os recursos aos quais um utilizador tenta aceder, incluindo as CNA, mas também outras APIs e a Google Cloud consola.

    A utilização de associações de acesso funciona melhor se quiser garantir que o acesso sensível ao contexto é aplicado de forma uniforme nos recursos.

  • Condições da IAM: pode criar um nível de acesso e atribuí-lo a associações de funções da IAM individuais através das condições da IAM.

    A utilização de associações de funções do IAM é uma forma de política baseada em recursos e a abordagem funciona melhor se quiser aplicar políticas diferentes a diferentes conjuntos de VMs.

Os níveis de acesso básicos permitem-lhe limitar o acesso por rede ou geolocalização. Como subscritor do Chrome Enterprise Premium, também pode limitar o acesso com base noutros atributos, como a força das credenciais, a configuração do navegador usado para autenticação ou a postura do dispositivo.

Acesso SSH baseado nos VPC Service Controls

A ideia desta abordagem é permitir apenas o acesso SSH através do encaminhamento TCP do IAP e configurar o perímetro de serviço para permitir a entrada do IAP para determinadas identidades das nossas origens.

Recomendamos esta abordagem para instâncias de VM que fazem parte de um perímetro do VPC Service Controls.

Conceder aos utilizadores acesso SSH externo a uma VM que faça parte de um perímetro de serviço pode ser arriscado, uma vez que pode permitir que os utilizadores prejudiquem o perímetro dos VPC Service Controls através da exfiltração de dados por SSH.

Ao permitir apenas o acesso SSH através do encaminhamento TCP do IAP, pode reduzir este risco e garantir que todo o acesso SSH está sujeito à configuração do perímetro dos VPC Service Controls:

  • Se um utilizador tentar estabelecer ligação a partir do exterior do perímetro de serviço (conforme ilustrado no exemplo anterior), o encaminhamento TCP do IAP não só verifica se o utilizador tem acesso do IAM à VM, como também verifica se o pedido cumpre alguma das regras de entrada do perímetro.

  • Se um utilizador tentar estabelecer ligação a partir do interior do perímetro de serviço, o encaminhamento de TCP do IAP também verifica se o utilizador tem acesso de IAM concedido à VM, mas ignora as regras de entrada dos VPC Service Controls.

    O IAP considera que uma ligação tem origem no interior de um perímetro de serviço se se aplicar alguma das seguintes situações:

    • O IP de origem é o endereço IP externo de uma VM que faz parte do perímetro de serviço.
    • A ligação é feita através do acesso privado à Google a partir de uma VM que faz parte do perímetro de serviço.
    • A ligação é feita através de um ponto final de acesso do Private Service Connect que faz parte do perímetro de serviço.

Acesso SSH interno controlado por firewall

A ideia desta abordagem é não permitir qualquer acesso externo e permitir apenas o acesso SSH interno da VPC.

Pode usar esta abordagem para instâncias de VM para as quais se aplica o seguinte:

  • A instância de VM não tem de ser acessível externamente.
  • A VM está ligada a uma rede interna de pequena a média dimensão.
  • A VM não faz parte de um perímetro dos VPC Service Controls.

Para não permitir qualquer acesso externo, pode fazer uma das seguintes ações:

  • Implemente as instâncias de VM sem um endereço IP externo.
  • Configure regras de firewall para que o tráfego SSH de entrada de intervalos de IP fora da VPC não seja permitido.

Desative o acesso à consola de série

Para resolver problemas de instâncias de VM com mau funcionamento, o Compute Engine permite-lhe ligar-se à consola da porta de série de uma instância através de um gateway SSH, ssh-serialport.googleapis.com. Este gateway está acessível publicamente através da Internet.

O gateway SSH acede à VM através do hipervisor subjacente em vez da rede VPC. Por conseguinte, o acesso à consola de série é controlado por políticas do IAM e não por regras de firewall.

Permitir que os utilizadores acedam a uma consola de série de VM pode deixar a VM inadvertidamente demasiado exposta. Para evitar esta exposição excessiva, use a compute.disableSerialPortAccess restrição da política organizacional para desativar o acesso à consola de série, e revogue a restrição temporariamente quando precisar de acesso de emergência à porta de série da VM.

Use uma VM bastion se precisar de gravação de sessões

Ao atuar como intermediário entre os dispositivos cliente e as VMs, o encaminhamento TCP do IAP executa funções que são normalmente executadas por anfitriões de bastião ou servidores de salto. Estas funções incluem:

  • Aplicar políticas de acesso de forma centralizada
  • Auditoria de acesso

Ao contrário de alguns anfitriões bastion, o encaminhamento TCP do IAP não termina as ligações SSH: quando estabelece uma ligação SSH a uma VM através do encaminhamento TCP do IAP, a ligação SSH é encriptada ponto a ponto entre o cliente e a VM. Como resultado desta encriptação ponto a ponto, o encaminhamento de TCP do IAP não pode inspecionar o conteúdo da sessão SSH e não oferece capacidades de gravação de sessões. Os registos de auditoria da IAP contêm metadados de ligação, mas não revelam informações sobre o conteúdo da sessão.

Se precisar de gravação de sessões, use uma VM bastion:

  • Configure a VM bastion para que termine as ligações SSH e registe o respetivo conteúdo. Certifique-se de que restringe a utilização do encaminhamento de portas SSH, uma vez que pode prejudicar a eficácia da gravação de sessões.
  • Configure regras de firewall das VMs de destino para que as ligações SSH só sejam permitidas a partir da VM bastion.
  • Permita o acesso à VM bastion apenas através do encaminhamento TCP do IAP

Use políticas de firewall para restringir a exposição de SSH

Depois de determinar como limitar a exposição ao SSH que funciona melhor para o seu ambiente, tem de garantir que todas as VMs e projetos estão configurados em conformidade. Em particular, tem de garantir que todos os projetos usam um conjunto consistente de regras de firewall que determinam como o SSH pode ser usado.

Para aplicar um conjunto de regras de firewall em vários projetos, use políticas de firewall hierárquicas e aplique-as a pastas na sua hierarquia de recursos.

Por exemplo, para ajudar a aplicar que todo o acesso SSH é realizado através do encaminhamento TCP do IAP, aplique uma política de firewall que inclua as duas regras personalizadas seguintes (por ordem de prioridade):

  1. Permitir entrada de 35.235.240.0/20 para a porta 22 das VMs selecionadas. 35.235.240.0/20 é o intervalo de IPs usado pelo encaminhamento TCP do IAP.
  2. Negue a entrada de 0.0.0.0/0 na porta 22 de todas as VMs.

O que se segue?