Práticas recomendadas para controlar o acesso ao início de sessão SSH

Este documento descreve as práticas recomendadas para controlar o acesso de início de sessão SSH a instâncias de máquinas virtuais (VMs) do Linux.

Para gerir eficazmente o acesso SSH a instâncias de VM, tem de permitir o acesso aos utilizadores quando precisarem e revogar esse acesso quando já não precisarem. Se o seu processo de revogação do acesso não for fiável ou não abranger todos os recursos, os autores de má conduta podem conseguir manter o acesso mesmo depois de este ter sido revogado.

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

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.

Use o Início de sessão do SO para garantir a avaliação contínua do acesso em relação às políticas IAM

As imagens Linux públicas do Compute Engine estão configuradas para permitir a autenticação de chaves públicas de SSH. Para autorizar a chave pública de um utilizador e conceder-lhe autorização para estabelecer uma sessão SSH, pode usar um dos seguintes dois mecanismos:

  • Autorização de chaves baseada em metadados: enquanto administrador, carrega a chave pública de um utilizador para os metadados da VM ou do projeto ou permite que os utilizadores façam o carregamento concedendo-lhes autorização para modificar os metadados.

    Uma chave pública carregada para os metadados de uma única VM concede ao utilizador privilégios de raiz apenas para a VM. Uma chave carregada para os metadados do projeto concede a um utilizador acesso a todas as VMs no projeto.

  • Autorização de chave de início de sessão no SO: como utilizador, carrega uma ou mais chaves públicas para o seu perfil de início de sessão no SO, que faz parte da sua conta de utilizador Google.

    Enquanto administrador, pode decidir se concede privilégios de raiz a um utilizador ou privilégios de utilizador normal na VM, concedendo a função do IAM Utilizador administrador de início de sessão no SO ou a função do IAM Utilizador de início de sessão no SO.

    A CLI gcloud, o cliente SSH Google Cloud no navegador da consola e o IAP Desktop detetam automaticamente o mecanismo que está a usar e podem carregar a chave de um utilizador em conformidade.

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

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

    A chave do utilizador está associada ao ciclo de vida da VM ou do projeto e permanece válida até remover a chave ou eliminar a VM ou o projeto. A suspensão ou a eliminação da conta de utilizador não afeta a validade das respetivas chaves.

  • Com o Início de sessão do SO, o acesso é avaliado sempre que um utilizador tenta estabelecer uma sessão SSH.

    A chave do utilizador está associada ao ciclo de vida da respetiva conta de utilizador. Se suspender ou eliminar um utilizador no Cloud ID ou no Google Workspace, as respetivas chaves deixam de poder ser usadas para conceder acesso SSH.

A utilização de chaves baseadas em metadados pode expô-lo a ameaças de persistência: os utilizadores podem manter o acesso SSH durante mais tempo do que o necessário se a respetiva chave pública não for removida dos metadados atempadamente, e podem até manter o acesso depois de sair da organização. Embora possa reduzir este risco analisando regularmente os metadados, tal pode ser difícil em ambientes maiores e pode ser insuficiente porque as chaves baseadas em metadados concedem privilégios de raiz aos utilizadores.

Para ajudar a proteger contra estas ameaças persistentes, não permita que os utilizadores usem chaves baseadas em metadados. Em alternativa, configure os seus projetos para impor a utilização do Início de sessão do SO.

Use políticas organizacionais para aplicar a utilização consistente do Início de sessão do SO

O Início de sessão do SO é controlado pela enable-osloginchave de metadados: Definir enable-oslogin como TRUE nos metadados do projeto ou da instância ativa o Início de sessão do SO, definir como FALSE desativa o Início de sessão do SO.

Para modificar os metadados ao nível do projeto, precisa da compute.projects.setCommonInstanceMetadata autorização no projeto. Esta autorização faz parte das funções Administrador de instâncias do Compute (roles/compute.instanceAdmin.v1) e Administrador do Compute (roles/compute.admin). Da mesma forma, a modificação dos metadados ao nível da instância requer a autorização compute.instances.setMetadata na instância de VM respetiva.

Os metadados ao nível da instância têm uma precedência mais elevada do que os metadados ao nível do projeto. Por conseguinte, definir enable-oslogin como TRUE nos metadados do projeto não é suficiente para aplicar a utilização do Início de sessão do SO em todo o projeto: os utilizadores com administrador da instância de computação ou acesso equivalente a instâncias de VM no projeto podem substituir a sua definição adicionando enable-oslogin=FALSE aos metadados da instância de VM.

Para aplicar a utilização consistente do início de sessão no SO, não confie na definição de enable-oslogin para TRUE nos metadados do projeto. Em alternativa, aplique a opção Ativar o Início de sessão do SO para uma organização através de uma política da organização para que todas as tentativas de definir enable-oslogin como false nos metadados da instância ou do projeto sejam rejeitadas.

Conceda funções privilegiadas temporariamente ou por VM

Se tiver instâncias de VM que executam diferentes cargas de trabalho e são geridas por diferentes equipas, pode simplificar a gestão de acesso implementando estas VMs em diferentesGoogle Cloud projetos e permitindo que os projetos usem uma rede partilhada. No entanto, a utilização de projetos separados nem sempre é viável e alguns dos seus projetos podem conter uma combinação de instâncias de VM, em que diferentes instâncias de VM só devem ser acessíveis a diferentes utilizadores.

Sempre que um projeto contiver essa combinação de diferentes instâncias de VM, evite conceder permanentemente aos utilizadores funções como Administrador de instâncias de computação ao nível do projeto. Em alternativa, distinga entre o acesso apenas para visualização e o acesso privilegiado:

  • Conceda aos utilizadores a função Leitor de computação ou uma função equivalente apenas de visualização ao nível do projeto. Esta função permite que os utilizadores procurem VMs através da Google Cloud consola, mas não lhes permite publicar chaves SSH nem aceder às VMs.
  • Conceda aos utilizadores o Início de sessão do SO do Compute, o Administrador de instâncias do Compute ou outras funções privilegiadas apenas para VMs individuais ou apenas numa base just-in-time.

Suspenda as contas de utilizador quando os utilizadores saírem da organização

A suspensão ou a eliminação de uma conta de utilizador no Cloud ID ou no Google Workspace revoga automaticamente as autorizações da IAM do utilizador. Uma vez que o Início de sessão do SO verifica as autorizações do IAM de um utilizador antes de lhe permitir estabelecer uma sessão SSH, a suspensão ou a eliminação de uma conta de utilizador também revoga o acesso do utilizador a VMs que usam o Início de sessão do SO.

Se configurou o Cloud ID ou o Google Workspace para usar um IdP externo para o início de sessão único, os funcionários têm uma conta de utilizador no IdP externo e no Cloud ID ou Google Workspace. A desativação ou a eliminação da conta de utilizador de um funcionário no seu IdP externo revoga a respetiva capacidade de estabelecer novas sessões do navegador para aceder aos serviços Google, mas não tem impacto imediato no Início de sessão no SO: desde que a conta de utilizador do Cloud Identity ou do Google Workspace do funcionário permaneça ativa, o Início de sessão no SO continua a permitir que o utilizador se autentique e estabeleça ligações SSH.

Para revogar de forma fiável o acesso SSH quando um utilizador sai da organização, certifique-se de que suspende ou elimina a respetiva conta de utilizador do Cloud ID ou Google Workspace. Se usar um IdP externo, configure-o para propagar eventos de suspensão de utilizadores para que o Início de sessão 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, as aplicações em execução na VM podem pedir credenciais de curta duração ao servidor de metadados da VM e usar estas credenciais para agir como a conta de serviço.

Ter acesso SSH a uma VM concede-lhe privilégios semelhantes: tal como uma aplicação, pode pedir credenciais de curta duração ao servidor de metadados da VM e agir como a conta de serviço anexada.

Uma vez que ter acesso SSH a uma VM com uma conta de serviço anexada permite-lhe agir em nome da conta de serviço, o Início de sessão do SO requer que tenha a autorização iam.serviceAccounts.actAs na conta de serviço e verifica esta autorização sempre que se liga à instância da VM. Desta forma, o início de sessão no SO ajuda a manter a segurança da conta de serviço e a impedir que o acesso SSH seja usado indevidamente para a escalada de privilégios.

Para mitigar ainda mais os riscos associados às VMs que têm 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 recursos do Google Cloud .
  • Use uma conta de serviço de finalidade única e conceda-lhe apenas acesso aos recursos de que a carga de trabalho precisa.
  • Exija que os utilizadores peçam acesso imediato em vez de lhes conceder acesso à VM e à conta de serviço de forma permanente.

Limite a utilização de privilégios de raiz

Quando usa o Início de sessão do SO e concede a um utilizador a função Utilizador do Início de sessão do SO (roles/compute.osLogin), está a atribuir ao utilizador privilégios de utilizador limitados na VM. Por outro lado, quando concede a um utilizador a função OS Login Admin User (roles/compute.osAdminLogin), usa a autorização de chaves baseada em metadados em vez do Início de sessão do SO ou permite que os utilizadores modifiquem os metadados da VM, está a conceder implicitamente privilégios de raiz ao utilizador na VM.

Conceder privilégios de raiz aos utilizadores numa VM pode expô-lo a riscos de persistência: Os utilizadores podem abusar destes privilégios para criar novas contas de utilizador ou instalar backdoors para manter o acesso persistente à VM.

Para ajudar a reduzir este risco de persistência, limite a utilização de privilégios de raiz e conceda apenas a função Utilizador de início de sessão do SO (roles/compute.osLogin) quando não forem necessários privilégios de raiz.

Pré-crie perfis POSIX para garantir nomes de utilizador e UIDs consistentes

Cada VM do Linux mantém uma base de dados local de utilizadores (/etc/passwd) e grupos (/etc/groups). Quando se liga pela primeira vez a uma VM do Linux através do SSH, o ambiente convidado cria automaticamente uma conta de utilizador do Linux para si e atribui-lhe um UID.

Quando usa chaves baseadas em metadados, o ambiente convidado não associa o utilizador do Linux à sua conta de utilizador da Google e pode atribuir-lhe um UID diferente em cada VM à qual se liga. Se usar protocolos como o NFS que pressupõem UIDs consistentes num ambiente que não impõe UIDs consistentes em todas as máquinas, os utilizadores podem, acidentalmente ou, no caso de autores de ameaças, deliberadamente, conseguir realizar acesso remoto como um utilizador diferente.

Quando usa chaves baseadas em metadados, o ambiente convidado também lhe permite escolher o nome de utilizador que quer usar. Se escolher um nome de utilizador que um colega usou anteriormente, inicia sessão com a conta que foi criada inicialmente para o seu colega.

Pode evitar estas ambiguidades de UID e nome de utilizador através do Início de sessão do SO: quando inicia sessão numa VM Linux pela primeira vez através do Início de sessão do SO, o ambiente convidado cria um utilizador Linux com base no perfil POSIX da sua conta de utilizador Google. O perfil POSIX serve como modelo para utilizadores do Linux e define o seguinte:

  • Um nome de utilizador do Linux exclusivo para todos os utilizadores da mesma conta do Cloud Identity ou do Google Workspace
  • Um UID e um GID exclusivos em todos os Google Cloud projetos
  • Um caminho do diretório inicial
  • Configuração adicional, como um shell de início de sessão

Se a sua Conta Google não tiver um perfil POSIX quando iniciar sessão pela primeira vez, o Início de sessão no SO cria automaticamente um para si.

O nome de utilizador e os UIDs atribuídos pelo Início de sessão no SO são únicos no seu Google Cloud ambiente, mas podem sobrepor-se ou ser inconsistentes com os nomes de utilizador e os UIDs que usa fora do Google Cloud. Se precisar que os nomes de utilizador e os UIDs do início de sessão do SO sejam consistentes noutros ambientes, é melhor não depender da criação automática de perfis. Em alternativa, use a API Directory para pré-criar perfis POSIX de Início de sessão do SO e atribuir nomes de utilizadores, UIDs e GIDs personalizados.

O que se segue?