Estabelecer ligação segura a instâncias de VM

Este documento descreve as práticas recomendadas para estabelecer ligação em segurança a instâncias de máquinas virtuais (VMs) do Compute Engine, incluindo o armazenamento de chaves de anfitrião através da ativação de atributos de convidado e a prevenção do acesso às VMs a partir da Internet pública.

Antes de começar

  • Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-se no Compute Engine selecionando uma das seguintes opções:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

    2. Set a default region and zone.

Armazenar chaves de anfitrião ativando atributos de convidado

Uma chave de anfitrião é um par de chaves que identifica um anfitrião ou uma máquina específica. Quando se liga a um anfitrião remoto, a chave do anfitrião é usada para verificar se está a estabelecer ligação à máquina pretendida.

Se usar o gcloud compute ssh para estabelecer ligação às suas VMs do Linux, pode adicionar uma camada de segurança armazenando as chaves do anfitrião como atributos de convidado.

O armazenamento de chaves de anfitrião SSH como atributos de convidado melhora a segurança das suas ligações, ajudando a proteger contra vulnerabilidades, como ataques de man-in-the-middle (MITM). Na inicialização inicial de uma VM, se os atributos de convidado estiverem ativados, o Compute Engine armazena as chaves de anfitrião geradas como atributos de convidado. Depois disso, o Compute Engine usa estas chaves de anfitrião armazenadas para validar todas as ligações subsequentes à VM.

As chaves de anfitrião podem ser armazenadas como atributos de convidado nas seguintes imagens de sistemas operativos públicos:

  • Debian
  • Ubuntu
  • Red Hat Enterprise Linux (RHEL)
  • CentOS
  • SUSE Linux Enterprise Server (SLES)

Para escrever chaves do anfitrião nos atributos do convidado, tem de ativar os atributos do convidado antes de arrancar a VM pela primeira vez. Pode ativar os atributos de convidado em VMs selecionadas durante a criação de VMs ou em todo o projeto.

Depois de ativar os atributos do SO convidado para um projeto ou uma VM, o agente do SO convidado publica automaticamente a chave do anfitrião como um atributo do convidado. Se usar gcloud compute ssh em vez de um cliente SSH simples, a CLI gcloud lê automaticamente os atributos e atualiza o ficheiro known_hosts na próxima vez que estabelecer ligação.

Para armazenar chaves de anfitrião como atributos de hóspedes, conclua os seguintes passos:

  1. Antes de arrancar a VM pela primeira vez, ative os atributos do SO convidado em VMs selecionadas durante a criação da VM ou em todo o projeto.

  2. Estabeleça ligação à sua VM através de gcloud compute ssh.

    1. Certifique-se de que tem a versão mais recente da CLI Google Cloud:

      gcloud components update

    2. Estabeleça ligação à VM:

      gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME

      Substitua o seguinte:

      • PROJECT_ID: o ID do projeto que contém a VM
      • ZONE: o nome da zona em que a VM está localizada
      • VM_NAME: o nome da VM

      Se tiver definido propriedades predefinidas para a CLI gcloud, pode omitir as flags --project e --zone deste comando. Por exemplo:

      gcloud compute ssh VM_NAME

    3. Reveja a mensagem de arranque. Por exemplo, um sistema operativo Debian pode apresentar a seguinte mensagem:

      Writing 3 keys to YOUR_HOME_DIRECTORY/.ssh/google_compute_known_hosts
Linux host-key-2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64

Para confirmar que as chaves do anfitrião estão armazenadas como atributos do convidado para esta VM, reveja os valores das chaves do anfitrião para verificar se as chaves SSH estão escritas nos atributos do convidado para a VM (opção 1) ou reveja a porta série para verificar a presença de chaves do anfitrião (opção 2):

Opção 1: reveja os valores-chave do anfitrião

Pode usar a CLI gcloud para verificar se as chaves SSH são escritas nos atributos do convidado:

gcloud compute instances get-guest-attributes VM_NAME \
  --query-path="hostkeys/" \
  --zone=ZONE

Substitua o seguinte:

  • VM_NAME: o nome da VM
  • ZONE: o nome da zona em que a VM está localizada

O resultado é semelhante ao seguinte:

NAMESPACE  KEY                  VALUE
hostkeys   ecdsa-sha2-nistp256  AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBJAGpTm
                                V3mFxBTHK1NIu9a7kVQWaHsZVaFUsqF8cLxQRQ+N96/Djiiuz1tucHQ8vBTJI=
hostkeys   ssh-ed25519          AAAAC3NzaC1lZDI1NTE5AAAAIM/WYBn3jIEW5t3BZumx0X/Htm61J6S9FcU8L
hostkeys   ssh-rsa              AAAAB3NzaC1yc2EAAAADAQABAAABAQDU3jReR/MoSttlWYfauW6qEqS2dhe5
                                Zdd3guYk2H7ZyxblNuP56nOl/IMuniVmsFa9v8W6MExViu6G5Cy4iIesot09
                                1hsgkG0U7sbWrXM10PQ8pnpI3B5arplCiEMhRtXy64rlW3Nx156bLdcxv5l+
                                7Unu4IviKlY43uqqwSyTv+V8q4ThpQ9dNbk1Gg838+KzazljzHahtbIaE1rm
                                I0L1lUqKiKLSLKuBgrI2Y/WSuqvqGEz+bMH7Ri4ht+7sAwykph6FbOgKqoBI
                                hVWBo38/Na/gEuvtmgULUwK+xy9zWg9k8k/Qtihc6El9GD9y

Opção 2: reveja a porta de série

  1. Veja a saída da porta de série.
  2. Selecione porta de série 1.

  3. Pesquise a seguinte mensagem:

    INFO Wrote ssh-rsa host key to guest attributes

    Se a sua imagem usar um sistema operativo suportado, mas a definição de atributos do convidado não tiver sido ativada antes do primeiro arranque da VM, pode ver a seguinte mensagem:

    Unable to write ssh-rsa host key to guest attributes

    Isto significa que as chaves do anfitrião não são armazenadas como atributos do convidado para esta MV. Se quiser armazenar chaves de anfitrião para VMs adicionais que planeia criar, ative os atributos de convidado antes do primeiro arranque da VM.

Impedir o acesso às VMs a partir da Internet pública

Quando desenvolve projetos no Compute Engine, existem vários cenários em que quer impedir que as VMs sejam alcançadas a partir da Internet pública:

  • Os serviços Web ainda estão em desenvolvimento e não estão prontos para serem expostos a utilizadores externos porque estão incompletos ou ainda não foram configurados com HTTPS.
  • A VM pode estar a fornecer serviços concebidos para serem consumidos apenas por outras VMs no projeto.
  • As VMs só devem ser acedidas através de opções de interconexão dedicadas a partir de escritórios ou centros de dados da empresa.

Mesmo quando um serviço está intencionalmente virado para a Internet, é importante que a comunicação com o serviço seja restrita aos grupos de utilizadores de destino e ocorra através de canais seguros, como SSH ou HTTPS, para proteger informações confidenciais.

Este artigo demonstra vários métodos para proteger as comunicações com VMs com endereços IP externos e VMs sem endereços IP externos. Independentemente de proteger ou não as comunicações com estes métodos, Google Cloud permite sempre a comunicação entre uma instância de VM e o respetivo servidor de metadados. Para mais informações, consulte o artigo sobre o tráfego sempre permitido.

Proteger serviços em máquinas com endereços IP externos

Quando as VMs têm um endereço IP público, é importante que apenas os serviços e o tráfego que pretende expor sejam acessíveis e, para os que estão expostos, todas as informações confidenciais sejam protegidas em trânsito. Existem vários métodos para proteger serviços em VMs com endereços IP externos explicados neste documento, incluindo firewalls, HTTPS e SSL, encaminhamento de portas através de SSH e proxy SOCKS através de SSH.

Firewalls

A sua primeira linha de defesa é restringir quem pode aceder à VM através de firewalls. Ao criar regras de firewall, pode restringir todo o tráfego para uma rede ou máquinas de destino num determinado conjunto de portas para endereços IP de origem específicos.

As firewalls não são uma solução autónoma. Restringir o tráfego a IPs de origem específicos não protege informações confidenciais, como credenciais de início de sessão, comandos que criam ou destroem recursos ou ficheiros, ou registos. Quando executa um serviço Web numa máquina acessível publicamente, como uma VM do Compute Engine com um IP externo, tem de encriptar todas as comunicações entre o anfitrião e a VM implementada para garantir a segurança adequada.

Além disso, as firewalls nem sempre são a solução adequada. Por exemplo, as firewalls não são ideais para ambientes de desenvolvimento que não tenham endereços IP estáticos, como portáteis em roaming.

HTTPS e SSL

Para sistemas Web de produção, deve configurar o HTTPS/SSL. Pode configurar o HTTPS/SSL configurando uma VM para terminar o HTTPS ou configurando o balanceamento de carga HTTPS. O HTTPS/SSL envolve alguma complexidade inicial, o que requer que execute as seguintes tarefas:

Encaminhamento de portas através de SSH

Pode usar a CLI do Google Cloud para iniciar um servidor numa determinada porta local que encaminha todo o tráfego para um anfitrião remoto através de uma ligação SSH.

Primeiro, tome nota da VM e da porta que estão a fornecer o serviço ao qual quer estabelecer uma ligação segura. Em seguida, execute o seguinte comando:

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT

Substitua o seguinte:

  • VM_NAME é o nome da VM à qual quer ligar-se.
  • PROJECT_ID é o seu Google Cloud ID do projeto.
  • ZONE: a zona na qual a sua VM está a ser executada, por exemplo, us-central1-a.
  • LOCAL_PORT: a porta local na qual está a ouvir, por exemplo, 2222.
  • REMOTE_PORT: A porta remota à qual se está a ligar, por exemplo, 8888.

Por exemplo, se especificar uma porta local de "2222" e uma porta remota de "8888", e abrir http://localhost:2222/ no navegador, a ligação HTTP usa o túnel SSH que criou para o anfitrião remoto para estabelecer ligação à VM especificada através de SSH. A ligação HTTP vai usar o túnel SSH para se ligar à porta 8888 na mesma máquina, mas através de uma ligação SSH encriptada e segura.

O comando gcloud cria e mantém uma ligação SSH enquanto a sessão SSH estiver ativa. Assim que sair da sessão SSH, o encaminhamento de portas através de http://VM_NAME:LOCAL_PORT deixa de funcionar.

Para criar mais do que uma regra de encaminhamento de portas, pode especificar várias regras numa única linha de comandos repetindo as flags:

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT

Em alternativa, pode executar um novo comando gcloud de cada vez para criar um túnel separado. Tenha em atenção que não pode adicionar nem remover o encaminhamento de portas de uma ligação existente sem sair e restabelecer a ligação de raiz.

Proxy SOCKS através de SSH

Se quiser estabelecer ligação a vários anfitriões diferentes na sua implementação na nuvem, a forma mais fácil de o fazer é alterar o navegador para fazer as pesquisas diretamente a partir da sua rede. Esta abordagem permite-lhe usar o nome abreviado dos anfitriões em vez de procurar o endereço IP de cada anfitrião, abrir portas para cada serviço ou criar um túnel SSH para cada par anfitrião/porta.

A abordagem que usa aqui é a seguinte:

  1. Configure um único túnel SSH para um dos anfitriões na rede e crie um proxy SOCKS nesse anfitrião.
  2. Altere a configuração do navegador para fazer todas as pesquisas através desse anfitrião do proxy SOCKS.

Tenha em atenção que, uma vez que está a encaminhar todo o tráfego através desse anfitrião, deve evitar usar esse navegador ou esse perfil específico para navegar na Web, uma vez que tem de dedicar essa largura de banda ao seu serviço na nuvem. Em geral, é recomendável usar um perfil do navegador separado e mudar para ele quando necessário.

Inicie o proxy SOCKS

Para iniciar o proxy SOCKS, execute o seguinte comando:

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE
    --ssh-flag="-D" \
    --ssh-flag="LOCAL_PORT" \
    --ssh-flag="-N"

Substitua o seguinte:

  • VM_NAME: o nome da VM à qual quer estabelecer ligação.
  • PROJECT_ID: o seu Google Cloud ID do projeto.
  • ZONE: a zona na qual a sua VM está a ser executada, por exemplo, us-central1-a.
  • LOCAL_PORT: a porta local na qual está a ouvir, por exemplo, 1080.

Tenha em atenção que, neste caso, não precisa de especificar uma porta remota. Uma vez que um proxy SOCKS não se associa a nenhuma porta remota específica, qualquer ligação que fizer através do proxy SOCKS será resolvida relativamente ao anfitrião ao qual se liga.

Ao usar um proxy SOCKS, pode estabelecer ligação a qualquer VM que partilhe uma rede do Compute Engine com a sua VM de proxy através do nome abreviado da VM. Além disso, pode estabelecer ligação a qualquer porta numa determinada VM.

Esta abordagem é muito mais flexível do que o método simples de encaminhamento de portas, mas também requer que altere as definições no seu navegador de Internet para usar o proxy.

Em seguida, configure o Chrome ou o Firefox para usar o proxy.

Chrome

Por predefinição, o Chrome usa definições de proxy ao nível do sistema, pelo que tem de especificar um proxy diferente através de sinalizadores da linha de comandos. O lançamento do Chrome por predefinição cria uma MV de um perfil já em execução. Por isso, para lhe permitir executar várias cópias do Chrome em simultâneo, uma que esteja a usar o proxy e outras que não estejam, precisa de um novo perfil.

Inicie o Chrome com um novo perfil. É criado automaticamente se não existir.

Linux:

/usr/bin/google-chrome \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

macOS:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

Windows:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" ^
    --user-data-dir="%USERPROFILE%\chrome-proxy-profile" ^
    --proxy-server="socks5://localhost:1080"

Defina a porta de anfitrião local para o mesmo valor que usou no comando gcloud anteriormente (1080 no nosso exemplo).

Firefox

Antes de alterar estas definições, recomendamos que crie um novo perfil do Firefox. Caso contrário, todas as VMs do Firefox vão usar esse anfitrião como um proxy, o que provavelmente não é o que quer.

Depois de ter o Firefox em execução com um perfil separado, pode configurar o proxy SOCKS:

  1. Abra as Preferências.
  2. Clique em Avançadas > Redes > Definições para abrir a caixa de diálogo Definições de ligação.
  3. Escolha a opção Configuração manual do proxy.
    1. Na secção Anfitrião SOCKS, preencha localhost como anfitrião e a porta que selecionou quando executou o comando gcloud anteriormente.
    2. Escolha SOCKS v5.
    3. Selecione a caixa DNS remoto.
    4. Deixe todas as outras entradas em branco.
  4. Clique em OK e feche a caixa de diálogo Preferências.

Estabelecer ligação a VMs sem endereços IP externos

Quando as VMs não têm endereços IP externos (incluindo VMs que são back-ends para balanceadores de carga de proxy SSL e HTTPS), só podem ser alcançadas através do seguinte:

Pode aprovisionar VMs na sua rede para atuarem como retransmissões fidedignas para ligações de entrada, também conhecidas como hosts de bastião. Além disso, pode configurar um Cloud NAT para tráfego de rede de saída ou configurar a consola série interativa para manter ou resolver problemas de VMs sem endereços IP externos.

Bastion hosts

Os bastion hosts oferecem um ponto de entrada virado para o exterior numa rede que contém instâncias de rede privadas, conforme ilustrado no diagrama seguinte.

Arquitetura de bastion hosts que atuam como o ponto de entrada virado para o exterior de uma rede de instâncias privadas.

Este anfitrião pode fornecer um único ponto de fortificação ou auditoria e pode ser iniciado e parado para ativar ou desativar o SSH de entrada. Ao usar um host bastion, pode estabelecer ligação a uma VM que não tenha um endereço IP externo. Esta abordagem permite-lhe estabelecer ligação a um ambiente de desenvolvimento ou gerir a instância da base de dados para a sua aplicação externa, por exemplo, sem configurar regras de firewall adicionais.

A proteção completa de um host bastion está fora do âmbito deste artigo, mas alguns passos iniciais podem incluir:

  • Limite o intervalo CIDR de IPs de origem que podem comunicar com o bastion.
  • Configure regras de firewall para permitir o tráfego SSH para VMs privadas apenas a partir do anfitrião bastion.

Por predefinição, o SSH nas VMs está configurado para usar chaves privadas para autenticação. Quando usa um bastion host, inicia sessão primeiro no bastion host e, em seguida, na VM privada de destino. Devido a este início de sessão em dois passos, os anfitriões bastion são, por vezes, denominados "servidores de salto". Deve usar o encaminhamento ssh em vez de armazenar a chave privada da máquina de destino no anfitrião bastion como forma de alcançar a máquina de destino. Tem de o fazer, mesmo que use o mesmo par de chaves para as VMs bastion e de destino, porque o bastion só tem acesso direto à metade pública do par de chaves.

Para saber como usar uma instância de anfitrião de bastion para estabelecer ligação a outras VMs na sua rede, consulte o artigo Estabeleça ligação a VMs do Linux através de um anfitrião de bastion. Google Cloud

Para saber como usar o sshencaminhamento e outros métodos para estabelecer ligação a VMs que não têm um endereço IP externo, consulte o artigo Estabelecer ligação a VMs que não têm endereços IP externos.

IAP para encaminhamento TCP

A utilização do SSH com a funcionalidade de encaminhamento TCP do IAP envolve uma ligação SSH dentro do HTTPS. Em seguida, a funcionalidade de encaminhamento TCP do IAP envia-o para a VM remota.

Para saber como estabelecer ligação a uma VM remota com o IAP, consulte o artigo Estabeleça ligação a VMs do Linux através do Identity-Aware Proxy.

VPN

A Cloud VPN permite-lhe ligar a sua rede existente à sua rede do Google Cloud Platform através de uma ligação IPsec a um dispositivo de gateway de VPN.Google Cloud Isto permite o encaminhamento direto do tráfego das suas instalações para as interfaces de IP privado das VMs do Compute Engine. O tráfego é encriptado à medida que transita através de links públicos para a Google.

Para obter detalhes sobre a configuração, a configuração e a utilização da VPN com o Compute Engine, consulte a documentação da Cloud VPN.

Para saber como estabelecer ligação a VMs na sua Google Cloud rede através de uma VPN existente em vez de através de endereços IP externos de VMs, leia o artigo Estabeleça ligação a VMs Linux através do Cloud VPN ou do Cloud Interconnect.

Tráfego de saída através do Cloud NAT

Quando uma VM não tem um endereço IP externo atribuído, não pode estabelecer ligações diretas a serviços externos, incluindo outros serviços Google Cloud. Para permitir que estas VMs alcancem serviços na Internet pública, pode configurar o Cloud NAT, que pode encaminhar o tráfego em nome de qualquer VM na rede. Não considere que uma única VM tem elevada disponibilidade ou é capaz de suportar um elevado débito de tráfego para várias VMs.

Acesso interativo à consola de série

Quando uma VM não tem um endereço IP externo, ainda pode ter de interagir com a VM para fins de resolução de problemas ou manutenção. A configuração de um host bastion, conforme abordado anteriormente, é uma opção, mas pode exigir uma configuração mais complexa do que o que é adequado às suas necessidades. Se quiser resolver problemas de uma VM sem um endereço IP externo, considere ativar o acesso interativo na consola série, o que lhe permite interagir com a consola série de uma VM através de SSH e executar comandos na consola série.

Para saber mais, leia o artigo Interagir com a consola série.

Balanceadores de carga de proxy HTTPS e SSL

As VMs que são back-ends para balanceadores de carga de proxy HTTPS e SSL não têm de ter endereços IP externos para serem acedidas através do balanceador de carga. Para aceder diretamente a estes recursos, tem de usar os métodos indicados na secção Estabelecer ligação a VMs sem endereços IP externos.

Para saber mais, leia a documentação sobre o equilíbrio de carga para esses equilibradores de carga.