Práticas recomendadas para controlar o acesso de login SSH

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

Para gerenciar com eficiência o acesso SSH às instâncias de VM, é necessário dar e revogar acesso aos usuários conforme necessário. Se o processo de revogação de acesso não for confiável ou não cobrir todos os recursos, usuários mal-intencionados poderão manter o acesso mesmo depois que ele tenha sido revogado.

As seções a seguir contêm práticas recomendadas que ajudam a garantir a revogação de acesso eficaz e na proteção contra ameaças persistentes:

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.

Usar o login do SO para garantir a avaliação contínua de acesso em relação às políticas do IAM

As imagens públicas do Linux do Compute Engine estão configuradas para permitir a autenticação de chave pública SSH. Para autorizar a chave pública de um usuário e lhes conceder permissão para estabelecer uma sessão SSH, use um dos seguintes mecanismos:

  • Autorização de chave baseada em metadados: como administrador, você faz o upload da chave pública do usuário para metadados da VM ou do projeto, ou permite que os próprios usuários façam o upload, concedendo a eles permissão para modificar metadados.

    Uma chave pública enviada para os metadados de uma única VM concede privilégios de raiz de usuário apenas à VM. Uma chave enviada para os metadados do projeto concede acesso a todas as VMs no projeto.

  • Autorização da chave de login do SO: como usuário, você pode fazer o upload de uma chave pública ou mais para seu perfil de login do SO, que é parte do sua conta de usuário do Google.

    Como administrador, você decide se quer conceder privilégios raiz a um usuário ou privilégios normais de usuário na VM, concedendo o papel do IAM de usuário administrador de login do SO ou o papel do IAM de usuário de login do SO.

    O gcloud CLI, o cliente SSH do console do Google Cloud no navegador e o IAP de desktop detectam automaticamente qual mecanismo está sendo usado e fazem o upload da respectiva chave do usuário.

Uma diferença importante entre os dois mecanismos está na avaliação do acesso em relação às políticas do IAM:

  • Com as chaves de metadados, o acesso é avaliado apenas uma vez, no momento de upload da chave.

    A chave do usuário está vinculada ao ciclo de vida da VM ou do projeto e permanecerá válida até ser removida ou até a VM ou o projeto serem excluídos. Suspender ou excluir a conta de usuário não afeta a validade das chaves.

  • Com o login do SO, o acesso é avaliado toda vez que um usuário tenta estabelecer uma sessão SSH.

    A chave do usuário está vinculada ao ciclo de vida da conta de usuário. Se você suspender ou excluir um usuário no Cloud Identity ou no Google Workspace; elas não poderão mais ser usadas para conceder acesso SSH.

O uso de chaves baseadas em metadados pode expor você a ameaças de persistência. Os usuários podem reter o acesso SSH por mais tempo que o necessário se a chave pública não for removida dos metadados em tempo hábil. Eles podem até mesmo manter o acesso após deixarem a organização. Embora seja possível reduzir esse risco checando regularmente os metadados, fazer isso pode ser difícil em ambientes maiores e também insuficiente porque as chaves baseadas em metadados concedem privilégios de raiz aos usuários.

Para se proteger contra essas ameaças de persistência, não permita que os usuários usem chaves baseadas em metadados. Em vez disso, configure seus projetos para aplicar o uso do login do SO.

Usar políticas da organização para impor o uso consistente do login do SO

O login do SO é controlado pela chave de metadados enable-oslogin: Configurar o enable-oslogin como TRUE em metadados do projeto ou da instância ativa o login do SO. configurá-lo como FALSE desativa o login do SO.

Para modificar metadados oara envolvidos no projeto, você precisa da permissão compute.projects.setCommonInstanceMetadata no projeto. Essa permissão faz parte dos papéis Administrador da instância do Compute (roles/compute.instanceAdmin.v1) e Administrador do Compute (roles/compute.admin). Da mesma forma, a modificação de metadados a nível de instância exige a permissão compute.instances.setMetadata na respectiva instância da VM.

Os metadados a nível de instância têm prioridade mais alta do que os metadados para envolvidos no projeto. Portanto, configurar o enable-oslogin como TRUE nos metadados do projeto não é suficiente para aplicar o uso do login do SO em todo o projeto. Usuários com acesso de Administrador da instância do Compute ou equivalente a uma instância de VM no projeto podem substituir sua configuração adicionando enable-oslogin=FALSE aos metadados da instância de VM.

Para aplicar o uso consistente do login do SO, não utilize a configuração de enable-oslogin como TRUE nos metadados do projeto. Em vez disso, aplique a ativação de login do SO em uma organização usando uma política da organização; dessa forma, todas as tentativas de configurar enable-oslogin como false nos metadados da instância ou do projeto serão rejeitadas.

Conceda papéis privilegiados de forma temporária ou por VM

Se você tiver instâncias de VM que executam cargas de trabalho diferentes e são gerenciadas por equipes diferentes, simplifique o gerenciamento de acesso implantando essas VMs em diferentes projetos do Google Cloud e permitindo que os projetos usem uma rede compartilhada. No entanto, o uso de projetos separados nem sempre é viável. Alguns deles podem conter uma combinação de instâncias de VM, com diferentes instâncias de VM só podendo ser acessadas por usuários diferentes.

Sempre que um projeto tiver essa combinação de instâncias de VM diferentes, evite conceder permanentemente papéis de usuários, como administrador da instância do Compute, a nível de projeto. Em vez disso, diferencie o acesso entre acesso de visualização e acesso privilegiado:

  • conceda aos usuários o papel Leitor do Compute ou um papel equivalente de acesso de visualização a nível de projeto. Esse papel permite que os usuários naveguem pelas VMs usando o console do Google Cloud, mas não permite que eles publiquem chaves SSH ou acessem as VMs.
  • Conceda aos usuários o login do SO do Compute, o administrador da instância do Compute ou outros papéis privilegiados apenas para VMs individuais ou somente quando necessário.

Suspender contas de usuário quando eles deixarem a organização

Suspender ou excluir uma conta de usuário no Cloud Identity ou no Google Workspace automaticamente revoga as permissões do IAM do usuário. Como o login do SO verifica as permissões de IAM de um usuário antes de permitir que ele estabeleça uma sessão SSH, a suspensão ou exclusão de uma conta de usuário também revoga seu acesso a VMs que usam o login do SO.

Se você configurou o Cloud Identity ou o Google Workspace para usar um IdP externo para logon único, os funcionários terão uma conta de usuário tanto no seu IdP externo quanto no Cloud Identity ou no Google Workspace. Desativar ou excluir a conta de usuário de um funcionário no IdP externo revoga a capacidade dele de estabelecer novas sessões de navegador para acessar os serviços do Google, mas não tem impacto imediato no login do SO: enquanto a conta de usuário do Cloud Identity ou do Google Workspace do funcionário permanecer ativa, o login do SO continuará permitindo que o ele faça a autenticação e estabeleça conexões SSH.

Para revogar o acesso SSH de forma confiável quando um usuário deixar a organização, suspenda ou exclua a conta de usuário do Cloud Identity ou do Google Workspace. Se você usa um IdP externo, configure-o para propagar eventos de suspensão de usuários para que o login do SO possa revogar o acesso.

Evitar a concessão de acesso SSH a VMs que têm uma conta de serviço privilegiada

Se uma instância de VM tiver uma conta de serviço anexada, os aplicativos em execução na VM poderão solicitar credenciais de curta duração do servidor de metadados da VM e use essas credenciais para atuar como uma conta de serviço.

Ter acesso SSH a uma VM concede privilégios semelhantes. Assim como um aplicativo, é possível solicitar credenciais de curta duração do servidor de metadados da VM e agir como uma conta de serviço anexada.

Como ter acesso SSH a uma VM com uma conta de serviço anexada permite que você atue como a conta de serviço, o login do SO exige que você tenha o iam.serviceAccounts.actAs de permissão da conta de serviço e verifica essa permissão toda vez que você se conecta à instância de VM. Dessa forma, o login do SO ajuda a manter a segurança da conta de serviço e evita o abuso do acesso SSH para escalonamento de privilégios.

Para mitigar ainda mais os riscos associados a VMs com contas de serviço privilegiadas, considere as seguintes alternativas:

Limitar o uso de privilégios de raiz

Quando você usa o login do SO e concede a um usuário o papel Usuário de login do SO (roles/compute.osLogin) você lhe atribui privilégios de usuário limitados na VM. Por outro lado, quando você concede a um usuário o papel de Usuário administrador do login do SO (roles/compute.osAdminLogin), usa a autorização de chave baseada em metadados em vez do login do SO ou permite que os usuários modifiquem os metadados da VM, você concede implicitamente os privilégios de raiz do usuário na VM.

Conceder privilégios de raiz aos usuários em uma VM pode expor você a riscos de persistência: os usuários podem abusar desses privilégios para criar novas contas de usuário ou instalar backdoors para manter o acesso persistente à VM.

Para ajudar a reduzir esse risco de persistência, limite o uso de privilégios de raiz e conceda o papel Usuário de login do SO (roles/compute.osLogin) apenas quando privilégios de raiz não são obrigatórios.

Criar perfis no formato POSIX previamente para garantir nomes de usuário e UIDs consistentes

Cada VM Linux mantém um banco de dados local de usuários (/etc/passwd) e grupos (/etc/groups). Quando você se conecta pela primeira vez a uma VM Linux usando SSH, o ambiente de convidado cria automaticamente uma conta de usuário Linux para você e atribui-lhe um UID.

Quando você usa chaves baseadas em metadados, o ambiente de convidado não vincula o usuário do Linux à sua conta de usuário do Google e pode atribuir a você um UID diferente em cada VM com que você se conectar. Se você usa protocolos como NFS que pressupõem UIDs consistentes em um ambiente que não aplique UIDs consistentes entre máquinas, os usuários podem - acidentalmente ou, no caso de usuários de má-fé, deliberadamente - realizar o acesso remoto como um usuário diferente.

Quando você usa chaves baseadas em metadados, o ambiente de convidado também permite que você escolha o nome de usuário quiser. Se você escolher um nome de usuário que um colega de trabalho usou anteriormente, você faz login com a conta que foi criada inicialmente para seu colega de trabalho.

É possível evitar essas ambiguidades de UID e nome de usuário usando o login do SO. Quando você faz login pela primeira vez em uma VM Linux usando o login do SO, o ambiente de convidado cria um usuário Linux com base no perfil POSIX da sua conta de usuário do Google. O perfil POSIX serve como modelo para usuários do Linux e define o seguinte:

  • um nome de usuário do Linux exclusivo para todos os usuários da mesma conta do Cloud Identity ou do Google Workspace
  • um UID e um GID exclusivos em todos os projetos do Google Cloud
  • um caminho de diretório principal
  • configuração extra, como um shell de login

Se sua Conta do Google não tiver um perfil no formato POSIX quando você fizer login pela primeira vez, o login do SO cria uma para você automaticamente.

O nome de usuário e os UIDs alocados pelo login do SO são exclusivos no Google Cloud, mas podem se sobrepor ou ser inconsistentes com os nomes de usuário e UIDs que você usa fora do Google Cloud. Se você precisar que os nomes de usuário e os UIDs do login do SO sejam consistentes em outros ambientes, é melhor não depender da criação automática de perfis. Em vez disso, use a API de diretório para pré-criar perfis POSIX de login do SO e atribuir nomes de usuário, UIDs e GIDs personalizados.

A seguir