Como autenticar usuários corporativos em um ambiente híbrido

Este artigo é a primeira parte de uma série de várias partes que discute como estender sua solução de gerenciamento de identidade para o Google Cloud para permitir que os usuários corporativos autentiquem e consumam serviços em um ambiente de computação híbrido.

A série contém estas partes:

Introdução

Gerenciar contas de usuários e controlar o acesso de funcionários a aplicativos e recursos de computação é uma responsabilidade fundamental dos departamentos de TI. Para garantir consistência e a eficiência administrativa, a maioria das empresas considera o gerenciamento de identidades uma função central e usa um sistema unificado para gerenciar identidades. Geralmente, as empresas usam o Microsoft Active Directory Domain Services (AD DS) para isso.

Ao estender um cenário de TI para o Google Cloud como parte de uma estratégia híbrida, é recomendável manter um único ponto em que as identidades são gerenciadas. Um sistema unificado de gerenciamento de identidades minimiza o esforço administrativo no gerenciamento de contas e no controle de acesso. Esse sistema também garante que usuários e aplicativos sejam autenticados com segurança em um ambiente híbrido.

Este artigo analisa as maneiras de integrar o Google Cloud ao seu sistema de gerenciamento de identidades. O artigo ajuda você a escolher a abordagem que melhor se adapta às suas necessidades.

Mesmo que a maior parte das discussões também se aplique ao Google Workspace, o foco deste artigo é o Cloud Identity.

Avaliar os requisitos do gerenciamento de identidade híbrido

A melhor maneira de estender seu sistema de gerenciamento de identidade para o Google Cloud depende de vários fatores:

  • Os pools de identidades na sua organização
  • Os provedores de identidade usados para fornecer serviços de autenticação para suas identidades corporativas
  • Os recursos e aplicativos que você quer que os usuários corporativos acessem no Google Cloud
  • Seus requisitos de continuidade de negócios

As seções a seguir analisam cada um desses pontos.

Identidades

O primeiro fator a ser considerado ao integrar o Google Cloud e seu sistema de gerenciamento de identidade é como você gerencia e distingue os tipos de identidade. A maioria das organizações usa os seguintes tipos de identidades:

  1. Identidades corporativas são as identidades que você gerencia para os funcionários da sua organização. Essas identidades são usadas para fazer login em estações de trabalho, acessar e-mails ou usar aplicativos corporativos.
  2. Identidades externas são as identidades que você gerencia para pessoas que não são funcionárias, como contratados ou parceiros, que precisam ter acesso a recursos corporativos.
  3. Identidades de convidado são identidades gerenciadas por uma parte diferente, como um cliente ou um parceiro que precisa acessar recursos corporativos.
  4. Identidades de cliente são as identidades que você gerencia para os usuários, a fim de interagir com seu site ou aplicativos voltados para o cliente.
  5. Identidades de aplicativos são as identidades que você gerencia para permitir que os aplicativos interajam com outros aplicativos ou com a plataforma subjacente.

Frequentemente, as identidades corporativas formam um único conjunto de identidades, onde cada funcionário tem uma única identidade e todas as identidades são gerenciadas da mesma maneira, usando os mesmos sistemas. No entanto, isso não é obrigatório. Como resultado de uma fusão ou aquisição, por exemplo, você pode ter vários pools de identidades corporativas, cada um gerenciado de maneira diferente, usando sistemas diversos. Em termos técnicos, isso significa que talvez seja necessário integrar várias fontes LDAP, florestas do Active Directory ou locatários do Azure AD ao Google Cloud.

A integração de vários pools aumenta a complexidade da integração com o Google Cloud. Portanto, você precisa considerar o seguinte:

  • Todos os pools de identidade precisam de acesso ao Google Cloud ou apenas um subconjunto selecionado?
  • Todos os pools de identidade precisam ter acesso à mesma organização no Google Cloud ou cada um deles precisa ter acesso a uma organização diferente?
  • Há opções para reduzir o número de pools, por exemplo, com a criação de relações de confiança entre florestas do Active Directory?

As identidades externas são geralmente tratadas de maneira semelhante às identidades corporativas, com estas exceções:

  • Sua conta pode ser válida por tempo limitado.
  • Elas podem receber menos direitos por padrão.
  • Elas podem ser gerenciadas por um diretório LDAP separado, pela floresta do Active Directory ou pelo locatário do Azure AD.

Ao contrário das identidades externas, as identidades de convidado não são gerenciadas por você, mas por outra parte. Em aplicativos de SaaS, como o Google Workspace, identidades de convidado podem eliminar a necessidade de manter identidades externas para clientes ou parceiros. Você raramente encontra identidades de convidado em ambientes locais.

O foco deste artigo são as identidades corporativas e as identidades externas.

Se você usou serviços como o Google Ads, alguns dos seus funcionários podem já ter uma Conta do Google que não está conectada à identidade corporativa deles, o que significa que eles têm duas identidades. Nesse caso, considere consolidar essas identidades.

Provedores de identidade

O segundo fator a ser considerado são seus provedores de identidade. Um provedor de identidade (IdP, na sigla em inglês) é um sistema que fornece serviços de autenticação para suas cargas de trabalho e, em última análise, decide se um usuário será autenticado.

Além de fornecer serviços de autenticação, os IdPs geralmente gerenciam as próprias identidades. No entanto, isso não é obrigatório, porque as identidades também podem ser provisionadas a partir de um sistema de recursos humanos separado.

Provedores de identidade comuns incluem:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • Provedores de IDaaS, como Okta ou Ping Identity
  • Outros diretórios de LDAP, incluindo o Active Directory Lightweight Directory Services (AD LDS)

Em vez de usar apenas um sistema, você pode ter vários implementados: para gerenciar diferentes pools de usuários, para lidar com contas externas ou para fornecer diferentes serviços de autenticação para os mesmos pools de usuários. Exemplos em que vários IdPs são usados para gerenciar os mesmos pools incluem:

  • Active Directory federado com o Azure AD
  • Active Directory federado com um provedor de IDaaS, como Okta ou Ping Identity
  • Active Directory com réplicas do AD LDS

Para usar seu IdP no Google Cloud, é possível seguir duas abordagens básicas:

  • Faça federação do seu provedor de identidade com o Cloud Identity: ao federar com o Cloud Identity, você permite que o Google se torne um novo IdP que seus usuários corporativos podem usar e com quem esses aplicativos implantados no Google Cloud podem contar. Em vez de manter as identidades do Google para cada um dos seus usuários, você pode usar o relacionamento de federação para manter as identidades automaticamente. Esse relacionamento também ajuda a garantir que seu IdP continue sendo a fonte da verdade.
  • Estenda seu provedor de identidade para o Google Cloud: permita que os aplicativos implantados no Google Cloud reutilizem seu IdP, conectando-se diretamente a ele ou mantendo uma réplica do IdP no Google Cloud.

Dependendo dos outros fatores de gerenciamento de identidade, talvez seja necessário combinar as duas abordagens para oferecer suporte aos seus cenários de uso híbrido.

Recursos

O terceiro fator a ser considerado é a quais recursos do Google Cloud você planeja conceder acesso aos usuários corporativos. Esse fator inclui o próprio Google Cloud. Você precisa permitir que equipes responsáveis gerenciem o Google Cloud usando o Console do Cloud, a ferramenta de linha de comando gcloud ou APIs.

Outros recursos podem incluir:

Dependendo do recurso, ele precisa, pode ou não pode usar o Google como provedor de identidade. As seções a seguir analisam esses três casos.

Recursos que precisam usar o Google como IdP

Os recursos que precisam usar o Google como IdP incluem o Console do Cloud, a ferramenta gcloud, aplicativos protegidos com IAP e outras ferramentas e serviços do Google. Para conceder aos seus usuários corporativos acesso a esses recursos, forneça uma identidade do Google para cada usuário.

A manutenção de identidades separadas do Google é contrária à ideia de gerenciamento unificado de identidades. Portanto, conceder aos usuários acesso a qualquer um desses recursos significa que você precisa federar seu IdP com o Google Cloud.

Depois de federar seu IdP com o Google Cloud, use o Google como IdP para ter mais recursos, incluindo aplicativos que podem usar outros meios para autenticar usuários.

Recursos que podem usar o Google como IdP

Recursos que podem usar o Google como IdP, mas atualmente não usam, incluem:

  • Novos aplicativos, destinados a usuários corporativos, que você planeja implantar no Google Cloud.
  • Aplicativos existentes, destinados a usuários corporativos, para os quais você planeja fazer a migração lift-and-shift ou fazer a migração improve-and-move para o Google Cloud.

Se esses aplicativos podem usar o Google como IdP, isso depende dos protocolos usados para autenticação e autorização.

Protocolos de logon único da Web

O Google aceita vários protocolos padrão do setor para lidar com autenticação, autorização e logon único. Os protocolos compatíveis incluem:

  • OAuth 2.0, que se aplica a clientes em dispositivos móveis, clientes de grande porte e outros aplicativos que não são de navegador.
  • OpenID Connect 1.0 (OIDC), que se aplica a aplicativos baseados em navegador.
  • SAML 2.0, que se aplica à integração de aplicativos de terceiros

Para aplicativos que você planeja desenvolver, prefira OAuth 2.0 ou OIDC. Esses protocolos são amplamente adotados, e você pode aproveitar muitas bibliotecas e ferramentas já testadas. Além disso, usar esses protocolos implica que você pode, opcionalmente, usar o Google como IdP enquanto mantém a flexibilidade de alternar provedores de identidade conforme necessário.

Se você tiver aplicativos que usam SAML, OAuth 2.0 ou OIDC, é possível alterá-los para usar o Google como provedor de identidade com poucas ou nenhuma alteração no código.

LDAP

Um dos protocolos mais versáteis e confiáveis para autenticação e autorização é o Lightweight Directory Access Protocol (LDAP). Existem várias maneiras de um aplicativo 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 usuário: nesse cenário, um aplicativo não usa o logon único. Em vez disso, ele mostra ao usuário um formulário de logon que solicita o nome de usuário e a senha e, em seguida, usa as credenciais fornecidas para tentar uma operação bind de LDAP. Se a tentativa tiver êxito, as credenciais serão consideradas válidas. Além disso, informações adicionais sobre o usuário, como nome e associação a grupos, podem ser consultadas no diretório e usadas para autorizar o acesso.

  2. Usar o SAML para autenticação e o LDAP para consultar informações do usuário: nesse cenário, o aplicativo autentica o usuário usando um protocolo de logon único. Os aplicativos geralmente usam o SAML para essa finalidade. Depois que o usuário tiver sido autenticado, o aplicativo usará o servidor LDAP para consultar informações adicionais sobre o usuário, como associações de nome e de grupo.

A diferença crítica entre os dois cenários é que o primeiro exige que o aplicativo e o servidor LDAP tenham acesso à senha do usuário para verificar as credenciais. No segundo cenário, o aplicativo e o servidor não exigem acesso à senha do usuário, e o aplicativo pode executar consultas LDAP usando um usuário de serviço dedicado.

Com o LDAP seguro, você pode acessar informações de usuários e grupos no Cloud Identity usando o protocolo LDAP. Se o Google for seu IdP principal, o LDAP seguro permitirá que você use ambos os cenários. No entanto, se você integrar o Cloud Identity a um IdP externo, o Cloud Identity não manterá uma cópia das senhas dos usuários. Como resultado, apenas o segundo cenário pode ser ativado com o LDAP seguro.

Kerberos e NTLM

Se você planeja migrar cargas de trabalho baseadas no Windows para o Google Cloud, alguns desses aplicativos podem depender da Autenticação Integrada do Windows (IWA, na sigla em inglês) em vez de usar protocolos padrão. A IWA é uma opção comum para aplicativos baseados em ASP.NET em execução no Microsoft IIS. A IWA é bastante usada porque permite uma experiência de logon único sem interrupções para usuários que efetuaram login na estação de trabalho do Windows usando credenciais de domínio.

A IWA conta com NTLM ou Kerberos. Ela exige que a estação de trabalho do usuário e o servidor em que o aplicativo é executado ingressem no mesmo domínio do Active Directory ou em domínios confiáveis.

Uma consequência de usar o NTLM e o Kerberos é que um aplicativo que usa IWA não pode usar o Google como IdP. No entanto, ainda será possível refatorar o aplicativo para usar o OIDC. O OIDC não requer que a estação de trabalho do usuário ou o servidor sejam conectados ao domínio. Assim, a refatoração pode simplificar a implantação e ajudar você a buscar opções de implantação alternativas.

Considerando a experiência logon único fornecida pela IWA, usar o OIDC em vez da IWA pode parecer um passo para trás em termos de experiência do usuário. No entanto, não precisa ser assim, se você garantir que os usuários possam fazer login facilmente no AD FS ou no Azure AD:

  • Se você federar o Google Cloud com o Active Directory e o FS, todos os métodos de autenticação configurados no AD FS serão aplicados. Se você configurar o AD FS para permitir IWA, os usuários que tiverem feito login em estações de trabalho do Windows usando credenciais de domínio poderão ser autenticados em qualquer aplicativo que use o Google como IdP.
  • Se você federar o Google Cloud com o Azure AD, poderá ativar o SSO Contínuo do Azure AD para alcançar o mesmo efeito.

O diagrama a seguir mostra um exemplo simplificado de como você pode usar o Cloud Identity, o AD FS e a IWA para implementar o logon único em um aplicativo da Web:

Como usar o Cloud Identity, o AD FS e a IWA para implementar logon único integrado em um aplicativo da Web

  1. O navegador solicita uma página protegida usando um navegador da Web.
  2. O aplicativo da Web inicia um login usando o OIDC (fluxo de autenticação do OIDC, em inglês). Esse fluxo redireciona o navegador para o endpoint de login do Google.
  3. O endpoint de login do Google retorna a página de login do Google ao usuário solicitando o endereço de e-mail.
  4. O usuário digita o endereço de e-mail corporativo.
  5. Com base no endereço de e-mail, o endpoint de login do Google identifica a conta do Cloud Identity e reconhece que ela está configurada para usar o SSO. O endpoint de login inicia um login via SAML com o AD FS.
  6. O AD FS, configurado para usar IWA, solicita que o navegador apresente um tíquete do Kerberos, que aciona o navegador para solicitar que o sistema operacional Windows subjacente consiga um tíquete adequado.
  7. A menos que um tíquete adequado tenha sido armazenado em cache, o Windows entra em contato com o centro de distribuição de chaves (KDC, na sigla em inglês) do Active Directory e solicita que um tíquete de serviço adequado seja emitido com base no tíquete de concessão de tíquete (TGT, na sigla em inglês) recebido quando o usuário entrou no Windows.
  8. O navegador apresenta o tíquete recém-conseguido para o AD FS.
  9. O AD FS valida o tíquete verificando sua assinatura criptográfica, extrai a identidade do usuário do tíquete e emite um token SAML para o endpoint de login do Google.
  10. Usando as informações de autenticação do token SAML, o endpoint de login do Google conclui o logon do OIDC e emite os tokens do OpenID Connect para o aplicativo da Web.
  11. Quando o usuário é autenticado, a página protegida pode ser retornada ao usuário.

Autenticação de chave pública SSH

Quando você planeja executar máquinas virtuais (VMs) do Linux no Google Cloud, provavelmente precisará de acesso SSH a essas máquinas. O método de autenticação mais comum para o SSH é a autenticação de chave pública.

Ao contrário dos protocolos de logon único discutidos anteriormente, a autenticação de chave pública SSH não depende de um IdP centralizado para tomar decisões de autenticação. Em vez disso, as decisões de autenticação são descentralizadas: cada máquina lida com a autenticação com base em um conjunto local de chaves públicas autorizadas.

Você pode preencher a lacuna entre a autenticação de chave pública SSH descentralizada e o gerenciamento centralizado de identidades. Para isso, vincule três atividades de provisionamento ao ciclo de vida de contas de usuários gerenciadas pelo IdP central:

  • Crie um par de chaves quando um usuário é criado ou tenta usar o SSH pela primeira vez.
  • Provisione a chave pública do usuário para máquinas que um usuário tem o direito de acessar.
  • Desprovisione a chave pública do usuário quando a conta é revogada, desativada ou excluída.

Em vez de usar ferramentas personalizadas para preencher a lacuna, você pode instalar o ambiente de convidado do Linux em VMs do Linux. Esse ambiente inclui um conjunto de scripts e daemons que automatizam o gerenciamento de contas de usuário e chaves SSH com base no IAM. Usar esse ambiente torna o Cloud Identity o IdP para suas instâncias do Linux.

Recursos que não podem usar o Google como IdP

Alguns recursos não podem usar o Google diretamente como IdP. Mas você ainda pode acomodar esses recursos no Google Cloud combinando duas abordagens:

Se um recurso usa protocolos que não são compatíveis com o IdP do Google, esse recurso não pode usar o Google como IdP. Esses protocolos incluem:

  • LDAP para autenticação: embora você possa usar o LDAP seguro para facilitar a consulta de informações do usuário do Cloud Identity por meio do LDAP, o Cloud Identity não aceita o uso do LDAP para autenticação quando federado com um IdP externo.

    Para permitir que os aplicativos usem o LDAP para autenticação, é possível expor ou replicar um diretório LDAP local ou ainda estender o Active Directory para o Google Cloud.

  • WS-Trust, WS-Federation: especialmente se você usar o AD FS, talvez ainda use o WS-Trust ou WS-Federation para lidar com a autenticação baseada em token. A menos que você consiga alterar os aplicativos afetados para usar SAML ou OpenID Connect, é melhor expor seu AD FS local ao Google Cloud e fazer com que os aplicativos usem o AD FS diretamente.

  • OpenID Connect com declarações específicas do AD FS: o AD FS e o Google são compatíveis com o OpenID Connect. Se você estiver usando o AD FS como um provedor OpenID Connect, poderá usar declarações específicas do AD FS que o Google não aceita. Em caso afirmativo, considere expor seu AD FS local ao Google Cloud e fazer com que os aplicativos usem diretamente o AD FS.

  • Kerberos, NTLM: se alguns dos seus aplicativos usarem o Kerberos ou o NTLM para autenticação, você poderá modificá-los para usar o OpenID Connect ou o SAML. Se isso não for possível, implante esses aplicativos em servidores do Windows conectados ao domínio e exponha ou replique seu Active Directory local para o Google Cloud.

  • Máquinas virtuais do Windows: se você executar cargas de trabalho do Windows no Google Cloud, poderá fazer login nessas VMs por meio do RDP, por meio de um gateway de área de trabalho remota ou por outros meios. Se um usuário tiver acesso de gravação ao projeto do Google Cloud em que a VM foi criada, o Google Cloud permitirá que ele crie um usuário e uma senha, que criam uma conta no banco de dados local do Gerenciador de contas de segurança (SAM, na sigla em inglês) da VM. É de extrema importância que a conta do SAM do Windows resultante não esteja conectada à Conta do Google do usuário e não esteja sujeita ao mesmo ciclo de vida da conta. Se você suspender ou excluir a Conta do Google do usuário, a conta do SAM do Windows não será afetada e poderá continuar a fornecer acesso à VM.

    Se você tiver um número moderado de VMs e usuários do Windows que precisam fazer login nessas máquinas, permitir que os usuários gerem contas de usuário e senhas do Windows talvez seja uma abordagem viável. No entanto, ao gerenciar frotas maiores de servidores do Windows, talvez seja melhor estender um Active Directory local para o Google Cloud e ingressar no domínio dos respectivos servidores. Servidores de conexão de domínio também são um requisito se você usar a Autenticação no nível da rede.

Disponibilidade

O último fator a considerar é a disponibilidade. A capacidade de autenticar usuários provavelmente é essencial para muitas das suas cargas de trabalho, e uma interrupção do IdP pode ter consequências sérias. A abordagem correta para garantir a disponibilidade adequada depende de como você pretende usar o Google Cloud e como ele se encaixa na sua estratégia híbrida.

Cargas de trabalho distribuídas

Para aproveitar os recursos exclusivos que cada ambiente de computação oferece, você pode usar uma abordagem híbrida com várias nuvens para distribuir cargas de trabalho nesses ambientes. Esses ambientes podem ter dependências uns com os outros que são essenciais para a disponibilidade das suas cargas de trabalho. As dependências podem incluir túneis túneis VPN ou interconexões, comunicação de aplicativos uns com os outros, ou sistemas que acessam dados em ambientes de computação.

Ao federar ou estender seu IdP externo para o Google Cloud, verifique se a disponibilidade do IdP externo e de outros sistemas necessários para autenticação atende ou excede a disponibilidade de outras dependências críticas. Esse requisito significa que pode ser necessário implantar de maneira redundante o IdP externo e as dependências dele além de garantir uma conectividade de rede redundante.

Cargas de trabalho redundantes

Se você usar o Google Cloud para garantir a continuidade dos negócios, suas cargas de trabalho no Google Cloud espelharão algumas das cargas de trabalho que você tem no ambiente de computação. O propósito dessa configuração é permitir que um ambiente de computação assuma o papel do outro ambiente se ocorrer uma falha. Então, é preciso analisar todas as dependências entre esses ambientes.

Ao fazer com que o Google Cloud dependa de um IdP externo em execução no local, você cria uma dependência. Essa dependência pode minar a intenção de que o Google Cloud seja uma cópia independente do seu ambiente de computação.

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

A seguir