Práticas recomendadas para controlar o acesso a redes SSH

Neste documento, você conhecerá as práticas recomendadas para controlar o acesso de rede SSH a instâncias de máquina virtual (VM) do Linux.

Para se conectar a uma instância de VM usando SSH, o usuário precisa ter acesso de rede à instância de VM e credenciais SSH válidas. Por padrã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 conecte à porta 22 das instâncias de VM. Embora seja conveniente para os desenvolvedores começarem rapidamente sem considerar controles de rede ou de segurança, permitir que os usuários se conectem de qualquer dispositivo, rede e local apresenta riscos:

  • os usuários podem se conectar de dispositivos ou redes não confiáveis.
  • Usuários de má-fé podem lançar ataques de força bruta e tentar comprometer as instâncias de VM.
  • Usuários de má-fé com acesso a credenciais SSH vazadas ou não revogadas a tempo podem usar essas credenciais para acessar e fazer login em uma VM de qualquer rede.

As seções a seguir descrevem como reduzir o risco limitando as redes, locais ou dispositivos em que os usuários podem estabelecer uma conexão SSH com suas VMs:

O documento se concentra em práticas específicas do Google Cloud ou que tenham relevância especial para o uso de SSH no Google Cloud. O documento não aborda as práticas recomendadas para implementações específicas de servidores ou clientes SSH.

Reduzir a exposição da rede

Permitir que os usuários estabeleçam conexões SSH em qualquer lugar significa que você depende totalmente dos mecanismos de autenticação e autorização SSH para proteger as VMs. É possível reduzir o risco e estabelecer uma camada adicional de proteção reduzindo a exposição de rede das VMs.

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

Redução da exposição da rede

  • Acesso externo: o primeiro fator a ser considerado é se a VM precisa ser acessível apenas na rede VPC ou se ela também precisa ser acessível externamente.

    Se o acesso interno da VPC for suficiente, não será preciso atribuir para um endereço IP externo para a VM, mas você ainda terá que decidir como gerenciar o acesso.

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

    Em redes menores, pode ser suficiente usar regras de firewall que permitam a entrada na porta 22 a partir de endereços internos para ajudar a proteger suas VMs. Em redes maiores, depender apenas de regras de firewall pode ser muito limitante. Nesses casos, use o encaminhamento de TCP do Identity-Aware Proxy. para aplicar o acesso baseado no contexto às VMs.

  • Design do perímetro do VPC Service Controls: o próximo fator a ser considerado é se a instância de VM faz parte de um perímetro do VPC Service Controls.

    Se a VM fizer parte de um perímetro de serviço, qualquer acesso à API originado dela será considerado originário de dentro do perímetro. Quando você concede acesso a um usuário fora do perímetro acesso SSH a uma VM dentro do perímetro, ele pode copiar dados do perímetro para sua estação de trabalho local ou o contrário, o que pode aumentar os riscos para a confidencialidade e a integridade dos dados do perímetro.

    Sempre que precisar conceder acesso SSH a uma instância de VM que faz parte de um Perímetro do VPC Service Controls, use o encaminhamento de TCP do IAP. O IAP detecta se a estação de trabalho do usuário faz parte do mesmo perímetro do VPC Service Controls e bloqueia tentativas de acesso de fora do perímetro de serviço por padrão. Para permitir o acesso externo, use regras de entrada e configure-as para aplicar o acesso baseado no contexto.

  • Gerenciamento de dispositivos clientes: o último fator a considerar é como seus dispositivos clientes são gerenciados, já que isso determina as maneiras pelas quais é possível controlar o acesso baseado no contexto.

    O acesso baseado no contexto é mais eficaz quando o Access Context Manager tem acesso a um conjunto rico de indicadores sobre um usuário, o dispositivo e a localização deles, funcionando em conjunto com o Chrome Enterprise Premium: se você usa o Chrome Enterprise Premium para gerenciar seus dispositivos, é possível configurar níveis de acesso que controlam o acesso com base na postura do dispositivo. É possível aplicar esse nível de acesso ao acesso SSH por meio do encaminhamento de TCP do IAP em combinação com vinculações de acesso ou condições de IAM.

    Se você não controlar a configuração de um dispositivo cliente, considere-o não gerenciado e possivelmente não confiável.

    Para permitir o acesso de dispositivos não gerenciados, também é possível usar o encaminhamento de TCP do IAP, mas só é possível gerenciar o acesso com base na identidade do usuário e no endereço IP do dispositivo. Como o Access Context Manager não tem acesso a nenhum indicador do dispositivo, não será possível restringir o acesso com base na posição do dispositivo.

Com base nos fatores e usando o fluxograma, é possível identificar qual abordagem para reduzir a exposição da rede é mais adequada para seu ambiente. As seções a seguir descrevem essas abordagens em mais detalhes.

Acesso SSH baseado em IAP

A ideia dessa abordagem é permitir apenas o acesso SSH por encaminhamento de TCP do IAP e permitir que o IAP controle o acesso com base na identidade do usuário.

Recomendamos essa abordagem para instâncias de VM em que o seguinte se aplica:

  • A instância de VM precisa ser acessível externamente ou de uma grande rede interna.
  • A VM não faz parte de um perímetro do VPC Service Controls.

Por padrão, uma instância de VM com um endereço IP externo permite acesso SSH porque os firewalls padrão permitem conexões da Internet pública para a porta 22, mas essa não é uma abordagem recomendada. Essa abordagem pode aumentar significativamente o risco de que a VM fique sujeita a ataques como os seguintes:

  • Uso de credenciais não revogadas: ex-funcionários cujo acesso não foi totalmente revogados podem continuar acessando a VM.
  • Abuso de credenciais válidas: usuários de má-fé em posse de credenciais roubadas ou vazadas podem usá-las para fazer login.
  • Negação de serviço: usuários de má-fé podem tentar esgotar os recursos da VM inundando-o de solicitações.

Uma maneira mais segura de permitir o acesso SSH externo a uma instância de VM é usar o encaminhamento TCP do IAP. Assim como um Bastion Host ou um proxy reverso, o encaminhamento de TCP do IAP atua como um intermediário entre o dispositivo cliente e a VM.

O encaminhamento TCP do IAP realiza as quatro funções a seguir quando um usuário tenta estabelecer uma conexão SSH:

  • Autenticação: o IAP verifica se o usuário tem uma credencial válida do Google.
  • Autorização: o IAP verifica as políticas do IAM para verificar se o usuário recebeu permissão para se conectar à VM pelo IAP.
  • Acesso baseado no contexto: o IAP pode verificar se o usuário, o dispositivo e o local atendem a determinados níveis de acesso.
  • Auditoria: quando os registros de acesso aos dados estão ativados, o IAP registra cada tentativa bem-sucedida ou fracasso para se conectar a uma instância de VM.

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

Acesso SSH baseado no reconhecimento de contexto no IAP

A ideia dessa abordagem é permitir apenas o acesso SSH pelo encaminhamento TCP do IAP e permitir que o IAP controle o acesso com base na identidade do usuário e em outros fatores.

Recomendamos essa abordagem para instâncias de VM em que o seguinte se aplica:

  • A instância de VM precisa ser acessível de fora da VPC e das redes que estão conectadas a ela.
  • A VM não faz parte de um perímetro do VPC Service Controls.
  • A VM só precisa estar acessível em determinados dispositivos, redes ou locais.

Ao conceder a um usuário o acesso SSH a uma instância de VM, seja diretamente ou por IAP, por padrão eles podem acessar a instância de VM de qualquer dispositivo, rede e local. Embora conveniente para os usuários, esse nível de acesso aumenta os riscos, já que os usuários podem se conectar a partir de dispositivos comprometidos ou em redes não confiáveis.

Para reduzir o risco, configure o encaminhamento de TCP do IAP para que os usuários possam acessar as instâncias de VM somente em determinados dispositivos ou locais. É possível configurar esse acesso baseado no contexto de duas maneiras:

  • Vinculações de acesso: é possível criar um nível de acesso. e o atribuir a um grupo usando uma vinculação de acesso. As vinculações de acesso são uma política baseada em formulário ou identidade e se aplicam a todos os recursos que um usuário tenta acessar, como IAP, mas também com outras APIs e o console do Google Cloud.

    O uso de vinculações de acesso funciona melhor se você quiser garantir que o acesso baseado no contexto seja aplicado de maneira uniforme em todos os recursos.

  • Condições do IAM: é possível criar um nível de acesso e atribuí-lo a vinculações de papel individuais do IAM usando condições do IAM.

    O uso de vinculações de papel do IAM é uma forma de política baseada em recursos. Essa abordagem funciona melhor se você quiser aplicar políticas diferentes a conjuntos diferentes de VMs.

Os níveis de acesso básicos permitem limitar o acesso por rede ou localização geográfica. Como assinante do Chrome Enterprise Premium, você também pode limitar o acesso com base em outros atributos, como a força da credencial, a configuração do navegador usado para autenticação ou a postura do dispositivo.

Acesso SSH baseado no VPC Service Controls

A ideia dessa abordagem é permitir o acesso SSH apenas pelo encaminhamento TCP do IAP e configurar o perímetro de serviço para permitir a entrada do IAP para determinadas identidades ou fontes.

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

Conceder aos usuários acesso SSH externo a uma VM que faz parte de um perímetro de serviço pode ser arriscado, porque permite que os usuários prejudiquem seu perímetro do VPC Service Controls exfiltrando dados pelo SSH.

Ao permitir o acesso SSH apenas pelo encaminhamento TCP do IAP, é possível reduzir esse risco e garantir que todo acesso SSH esteja sujeito à configuração do perímetro do VPC Service Controls:

  • Se um usuário tentar se conectar de fora do perímetro de serviço (como ilustrado no exemplo anterior), o encaminhamento de TCP do IAP não apenas verifica se o usuário recebeu acesso do IAM à VM, mas se a solicitação atende a alguma das regras de entrada do perímetro.

  • Se um usuário tentar se conectar dentro do perímetro de serviço, o encaminhamento de TCP do IAP também verificará se o usuário tem acesso do IAM à VM, mas irá ignorar as regras de entrada do VPC Service Controls.

    O IAP considera que uma conexão tem origem dentro de um perímetro de serviço se alguma das seguintes condições se aplicar:

    • O IP de origem é o endereço IP externo de uma VM que faz parte do perímetro de serviço.
    • A conexão é feita pelo Acesso privado do Google a partir de uma VM que faz parte do perímetro de serviço.
    • A conexão é feita por um endpoint de acesso do Private Service Connect que faz parte do perímetro de serviço.

Acesso SSH interno controlado por firewall

A ideia dessa abordagem é impedir todo o acesso externo e permitir apenas o acesso SSH interno à VPC.

Você pode usar essa abordagem para instâncias de VM em que o seguinte se aplica:

  • A instância de VM não precisa ser acessível externamente.
  • A VM está conectada a uma rede interna de tamanho pequeno a médio.
  • A VM não faz parte de um perímetro do VPC Service Controls.

Para proibir todo o acesso externo, siga um destes procedimentos:

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

Desativar o acesso ao console serial

Para resolver problemas de instâncias de VM com falha, o Compute Engine permite que você se conecte ao console serial de porta de uma instância por um gateway SSH, o ssh-serialport.googleapis.com. Esse gateway é acessível publicamente pela Internet.

O gateway SSH acessa a VM pelo hipervisor subjacente, em vez da rede VPC. O acesso ao console serial, portanto, é controlado políticas do IAM e não por regras de firewall.

Permitir que os usuários acessem um console serial de VM pode acidentalmente deixar a VM superexposta. Para evitar essa exposição excessiva, use a restrição de política da organização compute.disableSerialPortAccess para desativar o acesso ao console serial e remova a restrição temporariamente quando precisar de acesso de emergência à porta serial da VM.

Usar uma VM de bastião se precisar de registro de sessão

Ao atuar como um intermediário entre dispositivos clientes e VMs, o encaminhamento TCP do IAP executa funções que geralmente são realizadas por bastion hosts ou servidores de salto. Essas funções incluem

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

Ao contrário de alguns hosts Bastion, o encaminhamento de TCP do IAP não encerra as conexões SSH: quando você estabelece uma conexão SSH com uma VM pelo encaminhamento de TCP do IAP, a conexão SSH é criptografada de ponta a ponta entre o cliente e a VM. Como resultado dessa criptografia de ponta a ponta, o encaminhamento de TCP do IAP não pode inspecionar o conteúdo da sessão SSH nem oferece recursos de gravação de sessão. Os registros de auditoria do IAP contêm metadados de conexão, mas não revelam nenhuma informação sobre o conteúdo da sessão.

Se precisar de gravação de sessão, use uma VM de bastião:

  • Configurar a VM de bastião para que ela encerre as conexões SSH e registre o conteúdo dela. Restrinja o uso do encaminhamento de portas SSH, porque ele pode prejudicar a eficácia da gravação de sessão.
  • Configure as regras de firewall das VMs de destino para que as conexões SSH só sejam permitidas da VM do bastião.
  • Permitir o acesso à VM de bastião apenas pelo encaminhamento de TCP do IAP

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

Depois de determinar qual maneira de limitar a exposição do SSH funciona melhor para seu ambiente, verifique se todas as VMs e projetos estão configurados corretamente. Em particular, é necessário garantir que todos os projetos usem um conjunto consistente de regras de firewall para determinar como o SSH pode ser usado.

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

Por exemplo, para ajudar a garantir que todo acesso SSH seja realizado pelo encaminhamento de TCP do IAP, aplique uma política de firewall que inclua as seguintes duas regras personalizadas (em ordem de prioridade):

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

A seguir