Melhores práticas para controlar o acesso de login SSH

Este documento descreve as práticas recomendadas para controlar o acesso de login SSH a instâncias de máquinas virtuais (VM) Linux.

Para gerenciar com eficiência o acesso SSH às instâncias de VM, você deve permitir o acesso dos usuários quando precisarem e revogar esse acesso quando não precisarem mais dele. Se o seu processo de revogação do acesso não for confiável ou não cobrir todos os recursos, os malfeitores poderão manter o acesso mesmo depois que o acesso deveria ter sido revogado.

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

O documento centra-se em práticas que são específicas de Google Cloud ou de particular relevância ao usar SSH em Google Cloud. O documento não aborda práticas recomendadas para implementações específicas de cliente ou servidor SSH.

Use o login do sistema operacional para garantir a avaliação contínua do acesso em relação às políticas do IAM

As imagens públicas do Linux do Compute Engine são configuradas para permitir a autenticação de chave pública SSH. Para autorizar a chave pública de um usuário e conceder-lhe permissão para estabelecer uma sessão SSH, você pode usar um dos dois mecanismos a seguir:

  • Autorização de chave baseada em metadados : como administrador, você carrega a chave pública de um usuário na VM ou nos metadados do projeto ou permite que os próprios usuários realizem o upload, concedendo-lhes permissão para modificar metadados.

    Uma chave pública carregada nos metadados de uma única VM concede ao usuário privilégios root apenas para a VM; uma chave carregada nos metadados do projeto concede ao usuário acesso a todas as VMs do projeto.

  • Autorização da chave de login do sistema operacional : como usuário, você carrega uma ou mais chaves públicas no seu perfil de login do sistema operacional, que faz parte da sua conta de usuário do Google.

    Como administrador, você pode decidir se deseja conceder privilégios raiz ou privilégios de usuário regulares na VM, concedendo a função IAM de usuário administrador de login do SO ou a função IAM de usuário de login do SO .

    A CLI gcloud, o cliente SSH no navegador do console do Google Cloud e o IAP Desktop detectam automaticamente qual mecanismo você está usando e podem fazer upload da chave de um usuário adequadamente.

Uma diferença importante entre os dois mecanismos é quando o acesso é avaliado em relação às políticas do IAM:

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

    A chave do usuário está vinculada ao ciclo de vida da VM ou do projeto e permanece válida até você remover a chave ou excluir a VM ou o projeto. Suspender ou excluir a conta do usuário não afeta a validade de suas chaves.

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

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

O uso de chaves baseadas em metadados pode expô-lo a ameaças de persistência: os usuários poderão reter o acesso SSH por mais tempo do que o necessário se sua chave pública não for removida dos metadados em tempo hábil, e poderão até reter o acesso após deixar a organização. Embora você possa reduzir esse risco vasculhando metadados regularmente, fazer isso pode ser difícil em ambientes maiores e pode ser insuficiente porque as chaves baseadas em metadados concedem privilégios de root aos usuários .

Para ajudar a proteger contra tais ameaças de persistência, não permita que os utilizadores utilizem chaves baseadas em metadados. Em vez disso, configure seus projetos para impor o uso do Login do SO.

Use políticas organizacionais para impor o uso consistente do Login do SO

O Login do SO é controlado pela chave de metadados enable-oslogin : Definir enable-oslogin como TRUE nos metadados do projeto ou instância ativa o Login do SO, defini-lo como FALSE desativa o Login do SO.

Para modificar metadados no nível do projeto, você precisa da permissão compute.projects.setCommonInstanceMetadata no projeto. Essa permissão faz parte das funções Compute Instance Admin ( roles/compute.instanceAdmin.v1 ) e Compute Admin ( roles/compute.admin ). Da mesma forma, a modificação de metadados no nível da instância requer a permissão compute.instances.setMetadata na respectiva instância de VM.

Os metadados no nível da instância têm maior precedência que os metadados no nível do projeto. Definir enable-oslogin como TRUE nos metadados do projeto é, portanto, insuficiente para impor o uso do login do sistema operacional em todo o projeto: usuários com administrador de instância de computação ou acesso equivalente a instâncias de VM no projeto podem substituir sua configuração adicionando enable-oslogin=FALSE aos metadados da instância de VM.

Para impor o uso consistente do Login do SO, não confie na configuração de enable-oslogin como TRUE nos metadados do projeto. Em vez disso, aplique a política Habilitar login do sistema operacional para uma organização usando uma política de organização para que quaisquer tentativas de definir enable-oslogin como false na instância ou nos metadados do projeto sejam rejeitadas.

Conceda funções privilegiadas 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, poderá simplificar o gerenciamento de acesso implantando essas VMs em diferentesGoogle Cloud projetos e permitir que os projetos usem uma rede compartilhada. Mas usar projetos separados nem sempre é viável e alguns dos seus projetos podem conter uma combinação de instâncias de VM, onde diferentes instâncias de VM só devem ser acessíveis a usuários diferentes.

Sempre que um projeto contiver essa combinação de diferentes instâncias de VM, evite conceder permanentemente aos usuários funções como Administrador de instância do Compute no nível do projeto. Em vez disso, diferencie entre acesso somente visualização e acesso privilegiado:

  • Conceda aos usuários o Compute Viewer ou uma função equivalente somente de visualização no nível do projeto. Essa função permite que os usuários naveguem nas VMs usando o console do Google Cloud, mas não permite que publiquem chaves SSH ou acessem as VMs.
  • Conceda aos usuários login do sistema operacional de computação, administrador de instância de computação ou outras funções privilegiadas apenas para VMs individuais ou apenas just-in-time .

Suspender contas de usuário quando os usuários saírem da organização

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

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

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

Evite conceder acesso SSH a VMs que tenham 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 usar essas credenciais para atuar como conta de serviço .

Ter acesso SSH a uma VM concede privilégios semelhantes: como um aplicativo, você pode solicitar credenciais de curta duração do servidor de metadados da VM e atuar como a conta de serviço anexada.

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

Para mitigar ainda mais os riscos associados às VMs que possuem contas de serviço privilegiadas, considere as seguintes alternativas:

  • Não anexe uma conta de serviço à VM, a menos que a carga de trabalho exija acesso a Google Cloud recursos.
  • Use uma conta de serviço de finalidade única e conceda acesso apenas aos recursos necessários à carga de trabalho.
  • Exija que os usuários solicitem acesso just-in-time em vez de conceder-lhes acesso permanente à VM e à conta de serviço.

Limite o uso de privilégios de root

Ao usar o login do sistema operacional e conceder a um usuário a função de usuário de login do sistema operacional ( roles/compute.osLogin ), você está atribuindo ao usuário privilégios de usuário limitados na VM. Por outro lado, quando você concede a um usuário a função de usuário administrador de login do sistema operacional ( roles/compute.osAdminLogin ), usa a autorização de chave baseada em metadados em vez do login do sistema operacional ou permite que os usuários modifiquem os metadados da VM, você está concedendo implicitamente ao usuário privilégios raiz na VM.

Conceder privilégios de root aos usuários em uma VM pode expô-lo 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 acesso persistente à VM.

Para ajudar a reduzir esse risco de persistência, limite o uso de privilégios de root e conceda apenas a função de usuário de login do sistema operacional ( roles/compute.osLogin ) quando os privilégios de root não forem necessários.

Pré-crie perfis POSIX 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 convidado cria automaticamente uma conta de usuário Linux para você e atribui a ela um UID.

Quando você usa chaves baseadas em metadados, o ambiente 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 à qual você se conecta. Se você usar protocolos como o NFS, que assumem UIDs consistentes em um ambiente que não impõe UIDs consistentes entre máquinas, os usuários poderão – acidentalmente ou, no caso de agentes mal-intencionados, deliberadamente – conseguir realizar acesso remoto como um usuário diferente.

Ao usar chaves baseadas em metadados, o ambiente convidado também permite escolher o nome de usuário que deseja usar. Se você escolher um nome de usuário usado anteriormente por um colega de trabalho, você estará conectado com a conta que foi inicialmente criada para seu colega de trabalho.

Você pode evitar essas ambiguidades de UID e nome de usuário usando o login do sistema operacional: quando você faz login pela primeira vez em uma VM Linux usando o login do sistema operacional, o ambiente 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 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 GID únicos em todos Google Cloud projetos
  • um caminho de diretório inicial
  • configuração adicional, como um shell de login

Se sua Conta do Google não tiver um perfil POSIX quando você fizer login pela primeira vez, o Login do SO criará um automaticamente para você.

O nome de usuário e os UIDs alocados pelo Login do SO são exclusivos em seu Google Cloudambiente, mas pode se sobrepor ou ser inconsistente com nomes de usuário e UIDs que você usa fora do Google Cloud. Se você precisar que os nomes de usuário e UIDs de login do sistema operacional sejam consistentes em outros ambientes, é melhor não confiar na criação automática de perfis. Em vez disso, use a API Directory para pré-criar perfis POSIX de login do sistema operacional e atribuir nomes de usuário, UIDs e GIDs personalizados.

O que vem a seguir