Práticas recomendadas para proteger as credenciais SSH

Este documento descreve as práticas recomendadas para proteger as credenciais SSH.

Por predefinição, o Compute Engine usa a autenticação SSH baseada em chaves públicas: os utilizadores são autenticados por algo que têm, que é uma chave privada de SSH. Se as chaves privadas dos utilizadores não estiverem devidamente protegidas, podem cair nas mãos de intervenientes prejudiciais que podem usar estas chaves para aceder às suas instâncias de VM.

As secções seguintes contêm práticas recomendadas que podem ajudar a evitar a fuga de chaves e reduzir o potencial impacto das chaves privadas roubadas:

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.

Tratar as chaves privadas SSH de forma semelhante às chaves de contas de serviço

Algumas das suas instâncias de VM podem ter uma conta de serviço anexada. Associar uma conta de serviço a uma VM permite que as cargas de trabalho executadas nestas VMs peçam tokens de acesso de curta duração ao servidor de metadados para poderem aceder a Google Cloud APIs e recursos.

Quando estabelece ligação a uma VM com uma conta de serviço anexada através do SSH, também pode pedir tokens de acesso de curta duração ao servidor de metadados. Por conseguinte, conceder a um utilizador acesso SSH a uma VM é semelhante a conceder ao utilizador autorização para agir como a conta de serviço associada. Devido a essa semelhança, trate as chaves privadas SSH, especialmente quando não estão protegidas por uma frase secreta, como chaves de contas de serviço: Ambos os tipos de chaves, se forem divulgados, podem conceder a um ator malicioso acesso a Google Cloud recursos.

Use chaves SSH efémeras para utilizadores de máquinas

Os pipelines de implementação ou os processos de automatização podem exigir acesso SSH a instâncias de VM para realizar implementações ou aplicar alterações de configuração. Em vez de permitir que estas cargas de trabalho usem um par de chaves SSH de longa duração, permita que usem uma chave SSH nova e efémera sempre que são executadas.

Para usar chaves SSH efémeras, permita que os seus pipelines de implementação ou processos de automatização realizem os seguintes passos:

  1. Autentique-se como uma conta de serviço de uma forma que não envolva uma chave nem um segredo, por exemplo, através de uma conta de serviço anexada ou da federação de identidades da carga de trabalho.
  2. Gere um par de chaves SSH temporário através de uma ferramenta como ssh-keygen.

  3. Publique a chave pública em Google Cloud, especificando uma data de validade próxima (como 1 hora no futuro).

    O Início de sessão do SO permite-lhe especificar uma data de validade da chave quando publica uma chave. Da mesma forma, pode especificar uma data de validade quando publica uma chave pública de SSH nos metadados do projeto ou da VM.

  4. Use a chave privada para estabelecer ligações SSH a instâncias de VM.

  5. Opcionalmente, anule a publicação da chave pública e elimine a chave privada.

Por exemplo:

# Generate RSA key pair without passphrase
ssh-keygen -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

Embora uma chave privada de SSH efémera possa continuar a ser roubada, só pode ser usada durante um curto período. Por conseguinte, a utilização de chaves SSH efémeras pode reduzir o risco de roubo de credenciais e permite-lhe utilizar o Cloud IAM como o principal meio de autenticação e autorização.

Use o IAP para complementar a autenticação de chave pública de SSH

Por predefinição, as chaves privadas SSH podem ser usadas independentemente das credenciais Google: se a chave SSH privada de um utilizador for divulgada, um ator malicioso pode usar a chave para se ligar e autenticar em quaisquer instâncias de VMs às quais a chave esteja autorizada a aceder. Não é necessário que o autor da ação maliciosa saiba o nome de utilizador ou a palavra-passe do utilizador, nem que tenha qualquer credencial Google.

Os controlos de segurança, como a validação em dois passos e a limitação da duração da sessão para os Google Cloud serviços podem ser formas eficazes de reduzir o risco de roubo de credenciais, mas estes controlos aplicam-se apenas a recursos que requerem credenciais Google.

Para garantir que as chaves SSH não podem ser usadas sem credenciais Google válidas, use o IAP para reger o acesso SSH e use políticas de firewall para aplicar que todo o acesso SSH é feito através do IAP.

O IAP atua como um proxy inverso e só permite que os utilizadores estabeleçam ligações SSH a instâncias de VM se a autenticação for bem-sucedida através das respetivas credenciais Google. Além disso, a IAP permite-lhe restringir as VMs às quais os utilizadores se podem ligar e aplicar o acesso sensível ao contexto.

Use a autenticação multifator

A utilização do IAP para reger o acesso SSH torna mais difícil para um ator malicioso aceder a instâncias de VM através de credenciais roubadas, mas não o torna impossível. Por exemplo, um ator malicioso pode comprometer uma estação de trabalho e encontrar uma chave SSH privada e credenciais da CLI gcloud em cache, o suficiente para passar nas verificações de autenticação e autorização do IAP e estabelecer ligação às instâncias de VM do utilizador.

Pode reduzir o possível impacto de tais ataques de roubo de credenciais configurando o Cloud Identity ou o Google Workspace para exigir a autenticação multifator (MFA).

Se o Cloud ID ou o Google Workspace for o seu fornecedor de identidade principal, faça o seguinte para aplicar a AAF:

  1. Configure o Cloud ID ou o Google Workspace para aplicar a validação em dois passos.
  2. Limite a duração da sessão para os serviços Google Cloud , para que as credenciais em cache sejam automaticamente invalidadas e os utilizadores tenham de fazer uma nova autenticação e realizar a MFA periodicamente.

Se usar o início de sessão único com um IdP externo, faça o seguinte:

  1. Configure o Cloud Identity ou o Google Workspace para limitar a duração da sessão para os Google Cloud serviços de modo que as credenciais em cache sejam automaticamente invalidadas e os utilizadores tenham de voltar a autenticar-se periodicamente através do IdP externo.
  2. Configure o IdP externo para exigir a MFA e limite a duração da sessão para que os utilizadores tenham de realizar a MFA sempre que a sessão expirar. Google Cloud

Para garantir que a MFA também se aplica ao acesso SSH, também tem de fazer, pelo menos, uma das seguintes ações:

  1. Use o IAP para controlar o acesso à rede para que os utilizadores tenham de realizar periodicamente a MFA para atualizar as respetivas credenciais Google.
  2. Ative a A2F de início de sessão no SO para instâncias de VM individuais ou projetos inteiros, para que os utilizadores tenham de realizar a MFA sempre que estabelecem uma ligação SSH.

Os utilizadores que têm a função Administrador da instância de computação ou uma função equivalente para uma instância de VM ou um projeto podem desativar a A2F do Início de sessão do SO modificando os metadados da instância. Por conseguinte, a eficácia da autenticação de 2 fatores do Início de sessão do SO é limitada se também não aplicar a autenticação multifator no Cloud ID ou no seu IdP externo.

Use chaves privadas não exportáveis ou protegidas por frase secreta

Muitos clientes SSH armazenam por predefinição as chaves privadas de SSH como ficheiros no disco. Por exemplo, o comando gcloud compute ssh gera um par de chaves SSH na primeira utilização e armazena-o no seu diretório principal. O seu sistema operativo pode proteger os seus ficheiros contra o acesso de outros utilizadores, mas se um agente malicioso conseguir ultrapassar as autorizações do sistema de ficheiros (por exemplo, copiando e montando o disco noutro computador), pode copiar a chave para outro local e usá-la sem o seu conhecimento.

Alguns clientes SSH permitem-lhe evitar a utilização de chaves baseadas em ficheiros e oferecem opções alternativas para gerir chaves privadas de SSH, como:

  • Usar uma chave suportada por hardware: as versões modernas do OpenSSH permitem-lhe usar chaves de segurança FIDO2 para autenticação, e pode configurar o Início de sessão no SO para que só permita chaves de segurança inscritas no Cloud Identity ou no Google Workspace. A utilização de chaves suportadas por hardware ajuda a evitar o armazenamento de material de chaves privadas no sistema de ficheiros do computador.
  • Usar as instalações de armazenamento de chaves do seu sistema operativo: por exemplo, o IAP Desktop evita usar chaves baseadas em ficheiros e, em vez disso, usa o Windows CNG para proteger as suas chaves SSH.

Se a utilização de chaves suportadas por hardware ou geridas pelo sistema operativo não for uma opção, pode usar uma frase secreta para proteger a sua chave privada SSH: para usar uma chave SSH protegida por frase secreta, um agente malicioso não só precisa de uma cópia da chave privada, como também precisa de saber a frase secreta da chave.

Use chaves de anfitrião para autenticar o anfitrião

Quando cria uma ligação SSH a uma instância de VM, identifica a instância de VM pelo nome ou endereço IP. Os nomes e os endereços IP podem ser reatribuídos e reutilizados, e o nome que se referia a uma determinada instância de VM ontem pode não se referir à mesma instância de VM hoje. Os autores de ameaças podem reatribuir ou reutilizar deliberadamente nomes ou endereços IP para roubar a identidade de instâncias de VM e atrair os utilizadores para estabelecerem ligação a uma VM comprometida.

Os clientes SSH podem detetar situações em que uma instância de VM anteriormente fidedigna foi substituída por uma instância de VM diferente através de chaves de anfitrião SSH: a chave de anfitrião SSH de uma VM é gerada no primeiro arranque e é usada para identificar a instância. Normalmente, os clientes SSH pedem e armazenam a chave do anfitrião de uma VM na primeira ligação e verificam se a chave do anfitrião da VM não foi alterada nas ligações subsequentes.

As chaves de anfitrião SSH funcionam com base no esquema de confiança na primeira utilização. A eficácia das chaves de anfitrião SSH pode ser comprometida se um ator malicioso usar um ataque de intrusos (MITM) para permitir que um cliente se ligue e confie na VM errada na primeira utilização. Uma forma melhor de obter uma chave de anfitrião é obtê-la através de um canal lateral fidedigno antes de estabelecer ligação a uma VM pela primeira vez.

Pode permitir que a CLI gcloud obtenha chaves de anfitrião através de um canal secundário ativando os atributos de convidado no seu projeto. Em seguida, a CLI gcloud lê a chave do anfitrião de uma VM antes de se ligar pela primeira vez à mesma e guarda-a no seu computador local.

Não deixe credenciais pessoais em VMs

Quando autoriza a CLI gcloud, a ferramenta obtém um token de atualização do OAuth e armazena-o no seu diretório base local. Quando executar posteriormente um comando da CLI gcloud, a CLI gcloud usa o token de atualização para se autenticar automaticamente.

O seu computador local pode estar inacessível a outros utilizadores, mas numa instância de VM, o seu diretório pessoal também pode ser acedido por outros utilizadores que tenham privilégios de sudo na VM.

Se um ator malicioso conseguir obter privilégios de sudo numa VM, pode procurar tokens de atualização e outras credenciais nos diretórios pessoais de outros utilizadores e usar estas credenciais para aumentar os seus privilégios ou prolongar o acesso a outros recursos (movimento lateral).

Quando tiver uma ligação a uma instância de VM através de SSH, evite autorizar a CLI gcloud ou as credenciais predefinidas da aplicação (ADC) com as suas credenciais pessoais e permita que a CLI gcloud use a conta de serviço associada à VM. Da mesma forma, evite executar outras ferramentas que possam armazenar credenciais pessoais no seu diretório principal.

Pode reduzir ainda mais os riscos limitando a duração da sessão para os Google Cloud serviços para que os tokens de atualização do OAuth armazenados expirem automaticamente após um determinado período.

Não envie chaves privadas de SSH para repositórios de código-fonte

Algumas ferramentas de automatização, como o Ansible, usam o SSH para aceder e gerir instâncias de VM. Uma vez que estas ferramentas podem ter acesso a muitas instâncias de VM (e às respetivas contas de serviço anexadas), as chaves privadas SSH usadas por estas ferramentas podem ser particularmente sensíveis.

Se enviar uma chave privada de SSH para um repositório de código fonte, existe um risco acrescido de que a chave se torne acessível a utilizadores não autorizados e autores de ataques:

  • Os autores de ameaças podem analisar o código-fonte de repositórios de origem públicos para encontrar chaves roubadas.
  • No futuro, pode decidir transformar um repositório de origem privado num repositório público sem verificar primeiro se existem chaves.
  • Outros membros da equipa podem armazenar cópias do código fonte na respetiva estação de trabalho.

Para mitigar estes riscos, armazene a chave privada de SSH numa localização segura que esteja separada do código fonte e use chaves de SSH efémeras sempre que possível.

O que se segue?