Práticas recomendadas para proteger credenciais SSH

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

Por padrão, o Compute Engine usa autenticação SSH baseada em chave pública: usuários são autenticados por algo que eles têm, que é uma chave privada SSH. Se as chaves privadas dos usuários não estiverem protegidas adequadamente, elas poderão cair nas mãos de usuários mal-intencionados, que podem usar essas chaves para acessar as instâncias de VM.

As seções a seguir contêm práticas recomendadas que podem ajudar a evitar o vazamento de chaves e reduzir o possível impacto do vazamento de chaves privadas:

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

Tratar chaves privadas do SSH de forma semelhante às chaves de conta de serviço

Algumas das suas instâncias de VM podem ter uma conta de serviço anexada. A anexação de uma conta de serviço a uma VM permite que as cargas de trabalho executadas nessas VMs solicitem tokens de acesso de curta duração do servidor de metadados para acessar as APIs e os recursos do Google Cloud.

Ao usar SSH para se conectar a uma VM com uma conta de serviço vinculada, é possível também solicitam tokens de acesso de curta duração do servidor de metadados. Portanto, conceder a um usuário acesso SSH a uma VM é semelhante a conceder a ele permissão para atuar como a conta de serviço anexada. Devido a essa semelhança, trate as chaves privadas do SSH, especialmente quando elas não estiverem protegidas por senha, como chaves de conta de serviço. Ambos os tipos de chaves, se vazados, podem conceder a um usuário mal-intencionado acesso aos recursos do Google Cloud.

Usar chaves SSH temporárias para usuários de máquinas

Pipelines de implantação ou processos de automação podem exigir acesso SSH às instâncias de VM para executar implantações ou aplicar alterações de configuração. Em vez de deixar essas cargas de trabalho usarem um par de chaves SSH de longa duração, permita que elas usem uma nova chave SSH temporária sempre que forem executadas.

Para usar chaves SSH temporárias, permita que seus pipelines de implantação ou processos de automação executem as seguintes etapas:

  1. autenticar como uma conta de serviço que não envolva uma chave ou um secret. Por exemplo, usando uma conta de serviço anexada ou a federação de identidade da carga de trabalho.
  2. gerar um par de chaves SSH temporário usando uma ferramenta como ssh-keygen.

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

    O Login do SO permite especificar uma data de validade de chave quando você publica uma chave. Da mesma forma, é possível especificar uma data de validade ao publicar uma chave SSH pública nos metadados do projeto ou da VM.

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

  5. Opcionalmente, desative a chave pública e exclua 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

É possível que uma chave privada SSH temporária ainda tenha vazamento, mas ela só pode ser usada por pouco tempo. O uso de chaves SSH temporárias pode reduzir o risco de vazamento de credenciais e permite que você use o Cloud IAM como o principal meio de autenticação e autorização.

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

Por padrão, as chaves privadas SSH podem ser usadas independentemente das credenciais do Google: se a chave SSH privada de um usuário vazar, uma pessoa mal-intencionada poderá usá-la para se conectar e se autenticar nas instâncias de VM que a chave tem autorização para acessar. Não é necessário que o invasor saiba o nome de usuário ou a senha do usuário ou mesmo que tenha qualquer credencial do Google.

Controles de segurança, como a verificação em duas etapas e a limitação da duração da sessão para serviços do Google Cloud podem ser maneiras eficazes de reduzir o risco de roubo de credenciais, mas esses controles se aplicam apenas a recursos que exigem credenciais do Google.

Para garantir que as chaves SSH não possam ser usadas sem credenciais válidas do Google, use o IAP para governar o acesso SSH e use políticas de firewall para garantir que todo acesso SSH seja realizado pelo IAP.

O IAP atua como um proxy reverso e só permite que os usuários estabeleçam conexões SSH com instâncias de VM se eles forem autenticados usando as credenciais do Google. Além disso, o IAP permite restringir as VMs que os usuários podem acessar e aplicar o acesso com base no contexto.

Usar autenticação multifator

Usar o IAP para controlar o acesso SSH torna mais difícil para um usuário mal-intencionado acessar instâncias de VM usando credenciais vazadas, mas isso não é impossível. Por exemplo, um usuário mal-intencionado pode comprometer uma estação de trabalho e descobrir uma chave SSH privada e credenciais da gcloud CLI armazenadas em cache, o suficiente para passar nas verificações de autenticação e autorização do IAP e se conectar às instâncias de VM do usuário.

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

Se o Cloud Identity ou o Google Workspace for seu provedor de identidade principal, faça o seguinte para aplicar a MFA:

  1. Configure o Cloud Identity ou o Google Workspace para aplicar a verificação em duas etapas.
  2. Limite a duração da sessão para os serviços do Google Cloud para que as credenciais em cache sejam invalidadas automaticamente e os usuários precisem refazer a autenticação e realizar a MFA periodicamente.

Se você usar o logon ú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 nos serviços do Google Cloud para que as credenciais em cache sejam invalidadas automaticamente e os usuários precisem fazer a autenticação novamente periodicamente usando o IdP externo.
  2. Configure seu IdP externo para exigir a MFA e limite a duração da sessão para que os usuários precisem realizar a autenticação multifator (MFA) sempre que a sessão do Google Cloud expirar.

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

  1. Usar o IAP para controlar o acesso à rede para que os usuários precisem realizar a autenticação multifator (MFA) periodicamente para atualizar as credenciais do Google.
  2. Ativar a 2FA do Login do SO para instâncias de VM individuais ou projetos inteiros para que os usuários precisem realizar a MFA sempre que estabelecerem uma conexão SSH.

Os usuários com a função Administrador de instância do Compute ou uma função equivalente para uma instância de VM ou projeto podem desativar a 2FA do Login do SO modificando os metadados da instância. Portanto, a eficácia da autenticação de dois fatores do Login do SO é limitada se você não aplicar também a autenticação de dois fatores no Cloud Identity ou no IdP externo.

Usar chaves privadas não exportáveis ou protegidas por senha

Muitos clientes SSH usam como padrão o armazenamento de chaves privadas SSH como arquivos em disco. Por exemplo, gcloud compute ssh gera um par de chaves SSH no primeiro uso e o armazena no diretório principal. Seu sistema operacional pode impedir que seus arquivos sejam acessados por outros usuários, mas se um usuário mal-intencionado puder contornar as permissões do sistema de arquivos (por por exemplo, copiando e montando o disco em outra máquina), ele poderá copiar a chave em outro lugar e usá-la sem seu conhecimento.

Alguns clientes SSH permitem que você evite o uso de chaves baseadas em arquivos e oferecem opções alternativas para gerenciar chaves privadas SSH, como:

  • Usar uma chave protegida por hardware: as versões modernas do OpenSSH permitem o uso de chaves de segurança FIDO2 para autenticação, e é possível configurar o Login do SO para que ele permita apenas chaves de segurança registradas no Cloud Identity ou no Google Workspace. O uso de chaves protegidas por hardware ajuda a evitar o armazenamento de qualquer material de chave privada no sistema de arquivos do computador.
  • Usar os principais recursos de armazenamento do seu sistema operacional. Por exemplo, o IAP Desktop evita o uso de chaves baseadas em arquivo, e usa o Windows CNG para proteger as chaves SSH.

Se o uso de chaves gerenciadas pelo sistema operacional ou protegidas por hardware não for uma opção, você poderá usar uma senha longa para proteger sua chave privada SSH: para usar uma chave SSH protegida por senha longa, um invasor não precisa apenas de uma cópia da chave privada, mas também precisa saber a senha da chave.

Usar chaves do host para autenticar o host

Ao criar uma conexão SSH com uma instância de VM, você identifica essa instância 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. Usuários mal-intencionados podem reatribuir ou reutilizar nomes deliberadamente ou endereços IP para falsificar instâncias de VM e induzir os usuários a se conectarem a uma VM comprometida.

Os clientes SSH podem detectar situações em que uma instância de VM confiável foi substituída por outra usando chaves de host SSH: a chave de host SSH de uma VM é gerada na primeira inicialização e usada para identificar a instância. Os clientes SSH normalmente solicitam e armazenam a chave de host de uma VM na primeira conexão e verificam se a chave de host da VM não mudou nas conexões subsequentes.

As chaves de host SSH funcionam com base no esquema de confiança no primeiro uso. A eficácia das chaves de host SSH pode ser prejudicada se alguém de má-fé usar um ataque man-in-the-middle (MITM) para permitir que um cliente se conecte e confie na VM errada no primeiro uso. Uma maneira melhor de conseguir uma chave de host é por um canal lateral confiável antes de se conectar a uma VM pela primeira vez.

É possível permitir que a CLI gcloud receba chaves de host por um backchannel ativando os atributos de convidado no seu projeto. A CLI gcloud lê a chave do host de uma VM antes de você se conectar a ela e as salva no seu computador local.

Não deixe credenciais pessoais em VMs

Quando você autoriza a CLI gcloud, a ferramenta recebe um token de atualização OAuth e o armazena no diretório principal local. Depois, quando você executar um comando da CLI gcloud, a CLI gcloud usa o token de atualização para autenticar você automaticamente.

Seu computador local pode estar inacessível a outros usuários, mas em uma instância de VM, seu diretório principal também pode ser acessado por outros usuários com privilégios sudo na VM.

Se um invasor conseguir privilégios sudo em uma VM, ele poderá procurar tokens de atualização e outras credenciais nos diretórios principais de outros usuários e usar essas credenciais para aumentar os privilégios ou estender o acesso a outros recursos (movimento lateral).

Quando você estiver conectado a uma instância de VM por SSH, evite autorizar a CLI gcloud ou as credenciais padrão do aplicativo (ADC) com suas credenciais pessoais e deixe a CLI gcloud usar a conta de serviço anexada à VM. Da mesma forma, evite executar outras ferramentas que possam armazenar credenciais pessoais no diretório principal.

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

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

Algumas ferramentas de automação, como o Ansible, usam o SSH para acessar e gerenciar instâncias de VM. Como essas ferramentas podem ter acesso a muitas instâncias de VM (e às contas de serviço anexadas), as chaves privadas do SSH usadas por essas ferramentas podem ser particularmente sensíveis.

Quando você envia uma chave privada SSH para um repositório de código-fonte, há um risco maior de a chave ficar acessível a usuários não autorizados e usuários mal-intencionados:

  • Usuários mal-intencionados podem verificar o código-fonte dos repositórios de origem pública em busca de chaves vazadas.
  • No futuro, você pode optar por transformar um repositório de origem particular em um repositório público, sem antes verificar se há chaves nele.
  • Outros membros da equipe podem armazenar cópias do código-fonte nas estações de trabalho deles.

Para reduzir esses riscos, armazene a chave privada SSH em um local seguro separado do código-fonte e use chaves SSH temporárias quando possível.

A seguir