Autentique utilizadores da força de trabalho num ambiente híbrido

Last reviewed 2024-06-26 UTC

Este documento é a primeira parte de uma série de várias partes que aborda como estender a sua solução de gestão de identidades para Google Cloud permitir que os seus funcionários autentiquem e consumam serviços num ambiente de computação híbrido.

A série é composta por estas partes:

Introdução

A gestão de contas de utilizador e o controlo do acesso dos funcionários a aplicações e recursos de computação são uma responsabilidade fundamental dos departamentos de TI empresariais. Para garantir a consistência e a eficiência administrativa, a maioria das empresas considera a gestão de identidades uma função central e usa um sistema unificado para gerir identidades. Normalmente, as empresas confiam nos serviços de domínio do Microsoft Active Directory (AD DS) para este fim.

Quando expande um panorama de TI para Google Cloud como parte de uma estratégia híbrida, quer manter um único ponto onde as identidades são geridas. Um sistema de gestão de identidades unificado minimiza o esforço administrativo na gestão de contas e no controlo de acesso. Este sistema também ajuda a garantir que os utilizadores e as aplicações se podem autenticar de forma segura num ambiente híbrido.

Este documento analisa as formas de integração Google Cloud com o seu sistema de gestão de identidades. O documento ajuda a escolher a abordagem que melhor se adapta aos seus requisitos.

Embora a maioria da discussão também se aplique ao Google Workspace, o documento foca-se exclusivamente no Cloud ID.

Avalie os requisitos para a gestão de identidades híbrida

A melhor forma de estender o seu sistema de gestão de identidades para Google Cloud depende de vários fatores:

  • Os conjuntos de identidades na sua organização
  • Os fornecedores de identidade usados para fornecer serviços de autenticação para as suas identidades de força de trabalho
  • Os recursos e as aplicações aos quais quer que os seus utilizadores possam aceder no Google Cloud
  • Os seus requisitos de continuidade empresarial

As secções seguintes analisam cada um destes fatores.

Identidades

O primeiro fator a ter em conta ao integrar o Google Cloud e o seu sistema de gestão de identidades é a forma como gere e distingue os tipos de identidades. A maioria das organizações usa os seguintes tipos de identidades:

  1. As identidades da força de trabalho são as identidades que gere para os funcionários da sua organização. Estas identidades são usadas para iniciar sessão em estações de trabalho, aceder a email ou usar aplicações empresariais.
  2. As identidades externas são as identidades que gere para pessoas que não são funcionários, como contratantes ou parceiros, aos quais tem de conceder acesso a recursos empresariais.
  3. As identidades de convidados são identidades geridas por uma parte diferente, como um cliente ou um parceiro que precisa de aceder a recursos corporativos.
  4. As identidades dos clientes são as identidades que gere para os utilizadores de modo a interagirem com o seu Website ou aplicações viradas para o cliente.
  5. As identidades de carga de trabalho são as identidades que gere para permitir que as aplicações interajam com outras aplicações ou com a plataforma subjacente.

Muitas vezes, as identidades da força de trabalho formam um único conjunto de identidades, em que cada funcionário tem uma única identidade e todas as identidades são geridas da mesma forma, através dos mesmos sistemas. No entanto, não tem de ser assim. Por exemplo, como resultado de uma fusão ou aquisição, pode ter vários conjuntos de identidades de força de trabalho, cada um gerido de forma diferente através de sistemas diferentes. Tecnicamente, isto significa que pode ter de integrar várias origens LDAP, florestas do Active Directory ou inquilinos do Entra ID com o Google Cloud.

A integração de vários conjuntos aumenta a complexidade da integração com o Google Cloud. Por conseguinte, deve avaliar:

  • Todos os conjuntos de identidades precisam de acesso a Google Cloudou apenas um subconjunto selecionado?
  • Todos os conjuntos de identidades devem ter acesso à mesma organização no Google Cloud ou cada um a uma diferente?
  • Existem opções para reduzir o número de conjuntos, por exemplo, através da criação de relações de confiança entre florestas do Active Directory?

As identidades externas são frequentemente tratadas de forma semelhante às identidades da força de trabalho, com as seguintes exceções:

  • A conta pode ser válida apenas durante um período limitado.
  • Podem ser-lhes concedidos menos direitos por predefinição.
  • Podem ser geridos por um diretório LDAP separado, uma floresta do Active Directory ou o Microsoft Entra ID.

Ao contrário das identidades externas, as identidades de convidados não são geridas por si, mas por uma parte diferente. Em aplicações SaaS, como o Google Workspace, as identidades de convidados podem eliminar a necessidade de manter identidades externas para clientes ou parceiros. Raramente encontra identidades de convidados em ambientes no local.

Este documento centra-se nas identidades da força de trabalho e nas identidades externas.

Se tiver usado serviços como o Google Ads, alguns dos seus funcionários podem já ter uma Conta Google que não está associada à respetiva identidade da força de trabalho, o que significa que têm duas identidades. Se assim for, considere consolidar estas identidades.

Fornecedores de identidade

O segundo fator a analisar são os seus fornecedores de identidade. Um fornecedor de identidade (IdP) é um sistema que fornece serviços de autenticação para as suas cargas de trabalho e, em última análise, decide se autentica um utilizador.

Além de fornecerem serviços de autenticação, os IdPs gerem frequentemente o ciclo de vida das identidades. No entanto, não tem de ser assim, uma vez que as identidades também podem ser aprovisionadas a partir de um sistema de recursos humanos separado.

Os fornecedores de identidade comuns incluem:

  • Active Directory (AD DS)
  • Microsoft Entra ID (anteriormente, Azure Active Directory)
  • Fornecedores de IDaaS, como ForgeRock, Okta ou Ping Identity
  • Outros diretórios LDAP, incluindo os serviços de diretório simples do Active Directory (AD LDS)

Em vez de usar apenas um sistema, pode estar a usar vários sistemas para gerir diferentes conjuntos de utilizadores, processar contas externas ou fornecer diferentes serviços de autenticação para os mesmos conjuntos de utilizadores. Exemplos em que são usados vários IdPs para gerir os mesmos conjuntos incluem:

  • Active Directory federado com o Entra ID
  • Active Directory federado com um fornecedor de IDaaS, como ForgeRock, Okta ou Ping Identity
  • Active Directory com réplicas do AD LDS

Para usar o seu IdP no Google Cloud, pode seguir duas abordagens básicas:

  • Federar o seu fornecedor de identidade com o Cloud ID: ao federar com o Cloud ID, permite que a Google se torne um IdP adicional que os utilizadores da sua força de trabalho podem usar e no qual as aplicações implementadas no Google Cloud podem confiar. Em vez de manter identidades Google para cada um dos seus utilizadores, pode depender da relação de federação para manter as identidades automaticamente. Esta relação também ajuda a garantir que o seu IdP permanece a fonte de verdade.
  • Estenda o seu fornecedor de identidade para Google Cloud: pode permitir que as aplicações implementadas no Google Cloud reutilizem o seu IdP, ligando-se diretamente a ele ou mantendo uma réplica do seu IdP noGoogle Cloud.

Consoante os outros fatores de gestão de identidades, pode ter de combinar ambas as abordagens para suportar os seus cenários de utilização híbrida.

Recursos

O terceiro fator a ter em atenção é a que Google Cloud recursos planeia conceder acesso aos utilizadores da sua força de trabalho. Este fator inclui Google Cloud o próprio projeto: tem de permitir que as equipas responsáveis o geram Google Cloud através da Google Cloud consola, da CLI gcloud> ou das APIs.

Os recursos adicionais podem incluir:

Estes recursos diferem quanto ao facto de terem, poderem ou não poderem usar a Google como fornecedor de identidade. As secções seguintes analisam estes três casos.

Recursos que têm de usar a Google como IdP

Os recursos que têm de usar o Google como IdP incluem a Google Cloud consola, a CLI gcloud, as aplicações protegidas com o IAP e outras ferramentas e serviços Google. Para conceder aos utilizadores da sua força de trabalho acesso a estes recursos, tem de aprovisionar uma identidade Google para cada utilizador.

A manutenção de identidades Google separadas vai contra a ideia de gestão de identidades unificada. Por isso, conceder aos utilizadores acesso a qualquer um destes recursos implica que tem de federar o seu IdP com Google Cloud.

Depois de federar o seu IdP com a Google, considere usar a Google como IdP para aceder a mais recursos, incluindo aplicações que podem usar outros meios para autenticar utilizadores. Google Cloud

Recursos que podem usar o Google como IdP

Os recursos que podem usar o Google como IdP, mas que atualmente não o fazem, incluem:

  • Novas aplicações, destinadas a utilizadores da força de trabalho, que planeia implementar no Google Cloud.
  • Aplicações existentes, destinadas a utilizadores da força de trabalho, que planeia transferir ou mover e melhorar para o Google Cloud.

Se estas aplicações podem usar o Google como IdP depende dos protocolos que usa para autenticação e autorização.

Protocolos de Início de sessão único na Web

A Google suporta vários protocolos padrão da indústria para o processamento de autenticação, autorização e início de sessão único. Os protocolos suportados incluem:

  • OAuth 2.0, que se aplica a clientes móveis, clientes completos e outras aplicações não baseadas em navegador.
  • OpenID Connect 1.0 (OIDC), que se aplica a aplicações baseadas no navegador.
  • SAML 2.0, que se aplica à integração de aplicações de terceiros.

Para as aplicações que planeia desenvolver, o OAuth 2.0 ou o OIDC devem ser a sua escolha preferencial. Estes protocolos são amplamente adotados e pode tirar partido de muitas bibliotecas e ferramentas bem testadas. Além disso, a utilização destes protocolos implica que pode usar opcionalmente a Google como IdP, mantendo a flexibilidade de alternar entre fornecedores de identidade conforme necessário.

Se tiver aplicações que usam SAML, OAuth 2.0 ou OIDC, a mudança para usar o Google como fornecedor de identidade deve ser possível com poucas ou nenhumas alterações ao código.

LDAP

Um dos protocolos mais versáteis e fiáveis para autenticação e autorização é o protocolo LDAP (Lightweight Directory Access Protocol). Existem várias formas de uma aplicação usar o LDAP para autenticação e autorização. Os dois cenários mais comuns são:

  1. Usar o LDAP para autenticação e consulta de informações do utilizador: neste cenário, uma aplicação não usa o Início de sessão único. Em alternativa, apresenta ao utilizador um formulário de início de sessão que pede o nome de utilizador e a palavra-passe e, em seguida, usa as credenciais fornecidas para tentar uma operação LDAP bind. Se a tentativa for bem-sucedida, as credenciais são consideradas válidas. Além disso, as informações sobre o utilizador, como o nome e a associação a grupos, podem ser consultadas no diretório e usadas para autorizar o acesso.

  2. Usar SAML para autenticação e LDAP para consultar informações do utilizador: Neste cenário, a aplicação autentica o utilizador através de um protocolo de início de sessão único. As aplicações usam frequentemente SAML para este fim. Depois de o utilizador ter sido autenticado, a aplicação usa o servidor LDAP para consultar informações adicionais sobre o utilizador, como o nome e as associações a grupos.

A diferença fundamental entre os dois cenários é que o primeiro cenário requer que a aplicação e o servidor LDAP tenham acesso à palavra-passe do utilizador para validar as credenciais. No segundo cenário, a aplicação e o servidor não precisam de acesso à palavra-passe do utilizador. A aplicação pode executar as respetivas consultas LDAP através de um utilizador de serviço dedicado.

Com o LDAP seguro, pode aceder às informações de utilizadores e grupos no Cloud ID através do protocolo LDAP. Se a Google for o seu IdP principal, o LDAP seguro permite-lhe suportar ambos os cenários. No entanto, se integrar o Cloud Identity com um IdP externo, o Cloud Identity não mantém uma cópia das palavras-passe dos utilizadores. Como resultado, apenas o segundo cenário pode ser ativado com o LDAP seguro.

Kerberos e NTLM

Se planear migrar cargas de trabalho baseadas no Windows para o Google Cloud, algumas destas aplicações podem depender da autenticação integrada do Windows (IWA) em vez de usar protocolos padrão. A IWA é uma escolha comum para aplicações baseadas em ASP.NET em execução no Microsoft IIS. A IWA é popular porque permite uma experiência de início de sessão único integrada para os utilizadores que iniciaram sessão na respetiva estação de trabalho do Windows com credenciais de domínio.

A IWA baseia-se no NTLM ou no Kerberos. Requer que a estação de trabalho do utilizador e o servidor no qual a aplicação está a ser executada estejam associados ao mesmo domínio do Active Directory ou a domínios fidedignos.

Uma consequência de depender do NTLM e do Kerberos é que uma aplicação que use a IWA não pode usar a Google como IdP. No entanto, ainda pode refatorar a aplicação para usar o OIDC. O OIDC não requer que a estação de trabalho do utilizador nem o servidor estejam associados a um domínio. Assim, a refatoração pode simplificar a implementação e ajudar a explorar opções de implementação alternativas.

Tendo em conta a experiência de Início de sessão único integrada fornecida pela IWA, a utilização do OIDC em vez da IWA pode parecer um passo atrás em termos de experiência do utilizador. No entanto, não tem de ser assim se garantir que os utilizadores podem iniciar sessão sem problemas no AD FS ou no Azure AD:

  • Se federar Google Cloud com o Active Directory e o AD FS, aplicam-se todos os métodos de autenticação configurados no AD FS. Se configurar o ADFS para permitir a IWA, os utilizadores que iniciaram sessão na respetiva estação de trabalho Windows com credenciais de domínio podem ser autenticados de forma integrada em qualquer aplicação que use o Google como IdP.
  • Se federar Google Cloud com o Entra ID, pode ativar o SSO integrado do Azure AD com o mesmo efeito.

O diagrama seguinte mostra um exemplo simplificado de como pode usar o Cloud Identity, o AD FS e a IWA para implementar o início de sessão único integrado para uma aplicação Web:

Como usar o Cloud Identity, o AD FS e a IWA para implementar o início de sessão único sem falhas para uma aplicação Web

  1. O navegador pede uma página protegida através de um navegador de Internet.
  2. A aplicação Web inicia um início de sessão através do OIDC (fluxo de autenticação do OIDC). Este fluxo redireciona o navegador para o ponto final de início de sessão da Google.
  3. O ponto final do Início de sessão da Google devolve a página de início de sessão da Google ao utilizador, pedindo o endereço de email.
  4. O utilizador introduz o respetivo endereço de email.
  5. Com base no endereço de email, o ponto final de início de sessão do Google identifica a conta do Cloud Identity e reconhece que está configurada para usar o SSO. Em seguida, o ponto final de início de sessão inicia um início de sessão SAML com o AD FS.
  6. O AD FS, configurado para usar a IWA, pede ao navegador para apresentar um pedido Kerberos, o que faz com que o navegador peça ao sistema operativo Windows subjacente para obter um pedido adequado.
  7. A menos que tenha sido colocada em cache uma autorização adequada, o Windows contacta o centro de distribuição de chaves (KDC) do Active Directory e pede que seja emitida uma autorização de serviço adequada com base na autorização de concessão de autorizações (TGT) que foi obtida quando o utilizador iniciou sessão no Windows.
  8. O navegador apresenta o pedido obtido recentemente ao AD FS.
  9. O AD FS valida o pedido verificando a respetiva assinatura criptográfica, extrai a identidade do utilizador do pedido e emite um token SAML para o ponto final de início de sessão da Google.
  10. Usando as informações de autenticação do token SAML, o ponto final de início de sessão da Google conclui o início de sessão OIDC e emite tokens OpenID Connect para a aplicação Web.
  11. Quando o utilizador é autenticado, a página protegida pode ser devolvida ao utilizador.

Autenticação de chave pública de SSH

Quando planeia executar máquinas virtuais (VMs) Linux no Google Cloud, é provável que precise de acesso SSH a estas máquinas. O método de autenticação mais comum para SSH é a autenticação de chave pública.

Ao contrário dos protocolos de início de sessão único abordados anteriormente, a autenticação de chave pública de SSH não depende de um IdP centralizado para tomar decisões de autenticação. Em alternativa, as decisões de autenticação são descentralizadas. Cada máquina processa a autenticação com base num conjunto local de chaves públicas autorizadas.

Pode colmatar a lacuna entre a autenticação de chave pública de SSH descentralizada e a gestão de identidade centralizada através do Início de sessão do SO. O Início de sessão do SO associa o ciclo de vida das chaves SSH ao ciclo de vida das contas de utilizador através do seguinte:

  • Publicar uma chave pública de SSH quando um utilizador é criado ou está a tentar usar o SSH pela primeira vez.
  • Aprovisionamento da chave pública do utilizador para máquinas às quais um utilizador tem direito de acesso.
  • Anular o aprovisionamento da chave pública do utilizador quando o acesso à conta é revogado, desativado ou eliminado.

A utilização do Início de sessão do SO torna efetivamente o Cloud Identity o IdP para as suas instâncias do Linux.

Recursos que não podem usar a Google como IdP

Alguns recursos não podem usar diretamente o Google como IdP. No entanto, ainda pode acomodar estes recursos Google Cloud combinando duas abordagens:

Se um recurso depender de protocolos que o IdP da Google não suporta, esse recurso não pode usar a Google como IdP. Estes protocolos incluem:

  • LDAP para autenticação: embora possa usar o LDAP seguro para facilitar a consulta de informações do utilizador do Cloud Identity através do LDAP, o Cloud Identity não suporta a utilização do LDAP para autenticação quando federado com um IdP externo.

    Para permitir que as aplicações usem o LDAP para autenticação, pode expôr ou replicar um diretório LDAP no local ou pode estender o seu Active Directory para Google Cloud.

  • WS-Trust, WS-Federation: especialmente se usar o AD FS, ainda pode depender do WS-Trust ou do WS-Federation para processar a autenticação baseada em tokens. A menos que possa alterar as aplicações afetadas para usar o SAML ou o OpenID Connect, é melhor expôr o seu AD FS no local a Google Cloud e fazer com que as aplicações usem o AD FS diretamente.

  • OpenID Connect com reivindicações específicas do AD FS: o AD FS e a Google suportam o OpenID Connect. Se tem usado o AD FS como fornecedor do OpenID Connect, pode depender de determinadas reivindicações específicas do AD FS que a Google não suporta. Se for o caso, considere expor o AD FS no local ao Google Cloud e fazer com que as aplicações afetadas usem diretamente o AD FS.

  • Kerberos, NTLM: se algumas das suas aplicações usarem Kerberos ou NTLM para autenticação, pode modificá-las para usar OpenID Connect ou SAML. Se isto não for possível, pode implementar estas aplicações em servidores Windows associados a um domínio e expô-las ou replicar o seu Active Directory no local para o Google Cloud.

  • Máquinas virtuais Windows: se executar cargas de trabalho do Windows no Google Cloud, tem de conseguir iniciar sessão nestas VMs através do protocolo de ambiente de trabalho remoto (RDP), através de um gateway de ambiente de trabalho remoto ou por outros meios. Se um utilizador tiver acesso de escrita ao Google Cloud projeto onde a VM foi criada, Google Cloud permite ao utilizador criar um utilizador e uma palavra-passe, o que cria uma conta na base de dados do gestor de contas de segurança (SAM) local da VM. É fundamental que a conta SAM do Windows resultante não esteja associada à Conta Google do utilizador e não esteja sujeita ao mesmo ciclo de vida da conta. Se suspender ou eliminar a Conta Google do utilizador, a conta SAM do Windows não é afetada e pode continuar a fornecer acesso à VM.

    Se tiver um número moderado de VMs do Windows e utilizadores que têm de poder iniciar sessão nestas máquinas, permitir que os utilizadores gerem palavras-passe e contas de utilizador do Windows pode ser uma abordagem viável. No entanto, quando gerir frotas maiores de servidores Windows, pode ser melhor estender um Active Directory no local para Google Cloud e associar os respetivos servidores ao domínio. A associação de servidores a um domínio também é um requisito se usar a autenticação ao nível da rede.

Disponibilidade

O fator final a ter em conta é a disponibilidade. A capacidade de autenticar utilizadores é provavelmente fundamental para muitas das suas cargas de trabalho, e uma indisponibilidade do IdP pode ter consequências de grande alcance. A abordagem certa para garantir a disponibilidade adequada depende de como pretende usar o Google Cloud e de como se enquadra na sua estratégia híbrida.

Cargas de trabalho distribuídas

Para tirar partido das capacidades únicas que cada ambiente de computação oferece, pode usar uma abordagem híbrida de várias nuvens para distribuir cargas de trabalho nesses ambientes. Estes ambientes podem ter dependências entre si que são essenciais para a disponibilidade das suas cargas de trabalho. As dependências podem incluir túneis de VPN ou interconexões, aplicações que comunicam entre si ou sistemas que acedem a dados em ambientes de computação.

Quando federar ou expandir o seu IdP externo para Google Cloud, certifique-se de que a disponibilidade do seu IdP externo e de outros sistemas necessários para a autenticação cumpre ou excede a disponibilidade de outras dependências críticas. Este requisito significa que pode ter de implementar o IdP externo e as respetivas dependências de forma redundante e garantir a conetividade de rede redundante.

Cargas de trabalho redundantes

Se usar o Google Cloud para garantir a continuidade da empresa, as suas cargas de trabalho no Google Cloud vão refletir algumas das cargas de trabalho que tem no seu ambiente de computação. O objetivo desta configuração é permitir que um ambiente de computação assuma a função do outro ambiente se ocorrer uma falha. Por isso, tem de analisar todas as dependências entre estes ambientes.

Ao Google Cloud confiar num IdP externo executado no local, cria uma dependência. Essa dependência pode prejudicar a intenção de ter uma cópia independente do seu ambiente de computação.Google Cloud

Tente replicar o seu IdP para que Google Cloud todas as cargas de trabalho no Google Cloud não sejam afetadas por uma indisponibilidade do seu ambiente de computação no local ou da conetividade entre Google Cloud e a sua rede no local.

O que se segue?