Padrões de autenticação de usuários corporativos em um ambiente híbrido

Este artigo é a segunda parte de uma série. Nele, você verá como estender a solução de gerenciamento de identidade para o Google Cloud Platform (GCP) para que seus usuários corporativos se autentiquem e consumam serviços em um ambiente de computação híbrido.

A série inclui os artigos a seguir:

Introdução

Quando você estende o cenário de TI para o GCP como parte de uma estratégia híbrida, é recomendada a adoção de uma abordagem consistente no gerenciamento de identidades entre ambientes. Ao projetar e adaptar sua arquitetura para atender a essas restrições e requisitos, é possível seguir alguns padrões comuns. Esses padrões se dividem em duas categorias:

  • Padrões para federar um provedor de identidade externo (IdP, na sigla em inglês) com o GCP. O objetivo é permitir que o Google se torne um IdP dos seus usuários corporativos para que as identidades do Google sejam mantidas automaticamente, e o IdP continue sendo a fonte.
  • Padrões para estender um IdP para o GCP. Com eles, os aplicativos implantados no GCP reutilizam o IdP, seja por meio da conexão direta a ele ou pela manutenção de uma réplica do IdP no GCP.

Padrões para federar um IdP externo com o GCP

Para permitir o acesso ao Console do GCP, à ferramenta de linha de comando gcloud ou a qualquer outro recurso que use o Google como IdP, o usuário corporativo precisa ter uma identidade do Google. A manutenção das identidades do Google de cada funcionário pode ser complicada se todos os funcionários já tiverem uma conta em um IdP. Ao federar identidades de usuários entre o IdP e o GCP, você automatiza a manutenção das contas do Google e vincula o ciclo de vida delas às contas atuais. A federação ajuda a garantir que:

  • o IdP seja a única fonte para o gerenciamento de identidades;
  • uma Conta do Google seja criada automaticamente para todas as contas de usuário gerenciadas pelo IdP ou um subconjunto selecionado dessas contas;
  • a Conta do Google correspondente seja suspensa ou excluída se uma conta for desativada ou removida no IdP;
  • a autenticação de um usuário seja delegada ao IdP para impedir que senhas ou outras credenciais sejam copiadas.

Como federar o Active Directory com o Cloud Identity usando o GCDS e o AD FS

Se você usa o Active Directory como IdP, é possível federá-lo com o Cloud Identity usando o Google Cloud Directory Sync (GCDS) [página em inglês] e os serviços de federação do Active Directory (AD FS, na sigla em inglês):

  • O Cloud Directory Sync é uma ferramenta gratuita fornecida pelo Google que implementa o processo de sincronização. Ele se comunica com o Google Identity Platform por meio do Secure Sockets Layer (SSL) e geralmente é executado no ambiente de computação atual.
  • O AD FS é fornecido pela Microsoft como parte do Windows Server. Com ele, é possível usar o Active Directory para realizar autenticação federada. O AD FS geralmente é executado no ambiente de computação atual.

Para informações mais detalhadas sobre essa abordagem, consulte Como federar o GCP com o Active Directory.

Padrão: como federar o Active Directory com o Cloud Identity usando o GCDS e o AD FS

Se quiser uma variação desse padrão, também é possível usar o Active Directory Lightweight Directory Services (AD LDS) ou um diretório do LDAP diferente com o AD FS ou outro IdP compatível com SAML.

Experiência do usuário

  1. Ao solicitar o recurso protegido, você é redirecionado para a tela de logon do Google. Nela, você precisa fornecer seu endereço de e-mail.
  2. Se o endereço de e-mail estiver associado a uma conta que foi sincronizada no Active Directory, você será redirecionado para o AD FS.
  3. Dependendo da configuração do AD FS, você verá uma tela de logon que solicitará seu nome de usuário e senha do Active Directory. Ou talvez o AD FS tente fazer seu login automaticamente com base no login do Windows (IWA).
  4. Depois da sua autenticação pelo AD FS, você é redirecionado de volta para o recurso protegido.

Vantagens

  • A abordagem possibilita uma experiência de logon único em recursos e aplicativos locais no GCP.
  • Se você definiu o AD FS para exigir a autenticação multifator, essa configuração será aplicada automaticamente ao GCP.
  • Você não precisa sincronizar senhas ou outras credenciais com o Google.
  • Como a API do Cloud Identity é acessível ao público, não é necessário configurar a conectividade híbrida entre a rede local e o GCP.

Práticas recomendadas

  • O Active Directory e o Cloud Identity usam uma estrutura lógica diferente. Você precisa entender as diferenças e avaliar qual a melhor maneira de mapear domínios, identidades e grupos. Consulte o guia sobre como federar o GCP com o Active Directory para informações mais detalhadas.
  • Sincronize os grupos, além dos usuários. Com essa abordagem, você configura o Cloud IAM para usar assinaturas de grupo no Active Directory e controlar quem tem acesso aos recursos no GCP.
  • Implante e exponha o AD FS para que os usuários corporativos possam acessá-lo. No entanto, faça isso na medida certa. É necessário que os usuários corporativos possam acessar o AD FS, mas ele não precisa ser acessado pelo Google ou por qualquer aplicativo implantado no GCP.
  • Pense em ativar a Autenticação Integrada do Windows (IWA, na sigla em inglês) no AD FS para que os usuários façam login automaticamente com base no login do Windows.
  • Se o AD FS ficar indisponível, talvez os usuários não consigam usar o Console do GCP ou qualquer outro recurso que utilize o Google como IdP. Por isso, garanta que o AD FS e os controladores de domínio em que ele se baseia sejam implantados e dimensionados para atender aos objetivos de disponibilidade.
  • Se você utiliza o GCP para garantir a continuidade dos negócios, depender de um AD FS local pode prejudicar o uso do GCP como uma cópia independente da implantação. Nesse caso, implante réplicas de todos os sistemas relevantes no GCP:
    • Faça uma réplica do Active Directory no GCP e implante o GCDS para ser executado no GCP.
    • Execute servidores dedicados do AD FS no GCP. Eles usam os controladores de domínio do Active Directory executados no GCP.
    • Configure o Cloud Identity para usar os servidores do AD FS implantados no GCP no logon único.

Como federar o Azure AD com o Cloud Identity

Se você é um cliente do Microsoft Office 365 ou do Azure, talvez tenha conectado o Active Directory local ao Azure AD. Se todas as contas de usuário que podem precisar de acesso ao GCP já estiverem sendo sincronizadas com o Azure AD, será possível reutilizar essa integração ao federar o Cloud Identity com o Azure AD, como mostrado no diagrama a seguir.

Como federar o Cloud Identity com o Azure AD

Para informações mais detalhadas sobre esta abordagem, consulte Como federar o GCP com o Azure Active Directory.

Experiência do usuário

  1. Ao solicitar o recurso protegido, você é redirecionado para a tela de logon do Google. Nela, você precisa fornecer seu endereço de e-mail.
  2. Se o endereço de e-mail estiver associado a uma conta que foi sincronizada no Azure AD, você será redirecionado para o Azure AD.
  3. Dependendo de como o Active Directory local está conectado ao Azure AD, o Azure AD pode solicitar um nome de usuário e senha. Ou talvez ele redirecione você para um AD FS local.
  4. Depois da autenticação com o Azure AD, você é redirecionado de volta para o recurso protegido.

Vantagens

  • Você não precisa instalar mais nenhum software no local.
  • A abordagem possibilita uma experiência de logon único no Office 365, no Azure e nos recursos do GCP.
  • Se você definiu o Azure AD para exigir a autenticação multifator (MFA, na sigla em inglês), essa configuração será aplicada automaticamente ao GCP.
  • Esse trabalho de integração pode ser vantajoso se o Active Directory local usa vários domínios ou florestas, e você definiu uma configuração personalizada do Azure AD Connect para mapear essa estrutura para um locatário do Azure AD.
  • Você não precisa sincronizar senhas ou outras credenciais com o Google.
  • Como a API do Cloud Identity é acessível ao público, não é necessário configurar a conectividade híbrida entre a rede local ou o Azure e o GCP.
  • É possível visualizar o Console do GCP como um bloco no portal do Office 365.

Práticas recomendadas

  • Como o Azure AD e o Cloud Identity usam uma estrutura lógica diferente, você precisa entender as diferenças. Avalie qual a melhor maneira de mapear domínios, identidades e grupos. Para informações mais detalhadas, consulte Como federar o GCP com o Azure AD.
  • Sincronize os grupos, além dos usuários. Com essa abordagem, você configura o Cloud IAM para usar assinaturas de grupo no Azure AD e controlar quem tem acesso aos recursos no GCP.
  • Se você utiliza o GCP para garantir a continuidade dos negócios, depender do Azure AD na autenticação pode prejudicar o uso do GCP como uma cópia independente da implantação.

Padrões para estender um IdP externo para o GCP

Alguns dos aplicativos que você planeja implantar no GCP podem exigir o uso de protocolos de autenticação não oferecidos pelo Cloud Identity. Para aceitar essas cargas de trabalho, é necessário permitir que os aplicativos usem o IdP no GCP.

Nas seções a seguir, você vê descrições dos padrões comuns para permitir que o IdP seja usado por cargas de trabalho implantadas no GCP.

Como expor um AD FS local para o GCP

Se um aplicativo exige o uso do WS-Trust ou WS-Federation ou depende de declarações ou recursos específicos do AD FS ao executar o OpenID Connect, é possível permitir que o aplicativo utilize diretamente o AD FS na autenticação.

Aplicativo que usa diretamente o AD FS na autenticação

Ao usar o AD FS, o aplicativo pode autenticar um usuário. No entanto, como a autenticação não é baseada em uma identidade do Google, o aplicativo não poderá realizar chamadas de API em nome do usuário. Na verdade, todas as chamadas para a API do GCP precisam ser autenticadas por meio de uma conta de serviço.

Experiência do usuário

  1. Ao solicitar o recurso protegido, você é redirecionado para a tela de logon do AD FS. Nela, você precisa fornecer seu endereço de e-mail. Se o AD FS não estiver exposto ao público pela Internet, você precisará estar conectado à rede da empresa ou à VPN corporativa para acessar o AD FS.
  2. Dependendo da configuração do AD FS, você verá uma tela de logon que solicitará seu nome de usuário e senha do Active Directory. Ou talvez o AD FS tente fazer seu login automaticamente com base no login do Windows.
  3. Depois da sua autenticação pelo AD FS, você é redirecionado de volta para o recurso protegido.

Vantagens

  • É possível usar protocolos de autenticação que não sejam compatíveis com o Cloud Identity, incluindo o WS-Trust e o WS-Federation.
  • Se o aplicativo tiver sido desenvolvido e testado no AD FS, será possível evitar os riscos que podem surgir ao alternar o aplicativo para usar o Cloud Identity.
  • Não é necessário configurar a conectividade híbrida entre a rede local e o GCP.

Práticas recomendadas

  • Implante e exponha o AD FS para que os usuários corporativos possam acessá-lo. No entanto, faça isso na medida certa. É necessário que os usuários corporativos possam acessar o AD FS, mas ele não precisa ser acessado pelo Google ou por qualquer aplicativo implantado no GCP.
  • Se o AD FS ficar indisponível, talvez os usuários não consigam mais usar o aplicativo. Garanta que o AD FS e os controladores de domínio em que ele se baseia sejam implantados e dimensionados para atender aos objetivos de disponibilidade.
  • Pense na refatoração de aplicativos que dependem do WS-Trust e WS-Federation para usar o SAML ou o OpenID Connect.
  • Se o aplicativo depende de que as informações do grupo sejam expostas como declarações nos IdTokens emitidos pelo AD FS, pense em recuperá-las de uma fonte diferente, como a API Directory. Consultar a API Directory é uma operação com privilégios que exige o uso de uma conta de serviço com a delegação em todo o domínio do G Suite ativada.

Como expor um diretório de LDAP local para o GCP

Alguns dos aplicativos podem exigir que os usuários forneçam nome de usuário e senha e usem essas credenciais para realizar uma operação de vinculação do LDAP. Se não for possível modificar esses aplicativos para usar outros meios como o SAML na autenticação, conceda a eles acesso a um diretório de LDAP local.

Como conceder aos usuários acesso a um diretório de LDAP local

Vantagens

  • Não é necessário alterar o aplicativo.

Práticas recomendadas

  • Use o Cloud VPN ou o Cloud Interconnect para estabelecer a conectividade híbrida entre o GCP e a rede local. Assim, você não precisa expor o diretório de LDAP pela Internet.
  • Verifique se a latência gerada pela consulta de um diretório de LDAP local não afeta negativamente a experiência do usuário.
  • Garanta que a comunicação entre o aplicativo e o diretório de LDAP esteja criptografada. Para conseguir essa criptografia, use o Cloud VPN ou o Cloud Interconnect com o LDAP/S.
  • Se o diretório de LDAP ou a conectividade privada entre o GCP e a rede local ficarem indisponíveis, talvez os usuários não consigam mais usar o aplicativo baseado no LDAP. Portanto, garanta que os respectivos servidores sejam implantados e dimensionados para atender aos objetivos de disponibilidade. Pense no uso de túneis VPN redundantes ou interconexões.
  • Se você utiliza o GCP para garantir a continuidade dos negócios, depender de um diretório de LDAP local pode prejudicar o uso do GCP como uma cópia independente da implantação atual. Nesse caso, faça a replicação do diretório de LDAP no GCP.
  • Se você usa o Active Directory, execute uma réplica no GCP. Faça isso principalmente se você planeja associar o domínio das máquinas Windows executadas no GCP ao Active Directory.

Como replicar um diretório de LDAP local para o GCP

Replicar um diretório de LDAP local no GCP tem um padrão semelhante ao da seção Como expor um diretório de LDAP local para o GCP. Com relação aos aplicativos que usam o LDAP para verificar nomes de usuário e senhas, a intenção dessa abordagem é poder executar os aplicativos no GCP. Em vez de permitir que esses aplicativos consultem o diretório de LDAP local, é possível manter uma réplica do diretório local no GCP.

Como manter uma réplica do diretório local no GCP

Vantagens

  • Não é necessário alterar o aplicativo.
  • A disponibilidade dos aplicativos baseados em LDAP executados no GCP não depende da disponibilidade do diretório local ou da conectividade com a rede local. Esse padrão é adequado para cenários híbridos de continuidade dos negócios.

Práticas recomendadas

  • Use o Cloud VPN ou o Cloud Interconnect para estabelecer a conectividade híbrida entre o GCP e a rede local. Assim, você não precisa expor o diretório de LDAP pela Internet.
  • Garanta que a replicação entre o diretório de LDAP local seja realizada por meio de um canal seguro.
  • Implante várias réplicas do diretório de LDAP em muitas zonas ou regiões para atender aos objetivos de disponibilidade. Use um balanceador de carga interno para distribuir conexões de LDAP entre várias réplicas implantadas na mesma região.
  • Use um projeto separado do GCP com uma VPC compartilhada para implantar réplicas do LDAP e conceder acesso a esse projeto com base na abordagem de menor privilégio.

Como estender um Active Directory local para o GCP

Algumas das cargas de trabalho que você planeja implantar no GCP podem depender dos serviços de domínio do Active Directory. Por exemplo:

  • Máquinas Windows que precisam ter o domínio associado.
  • Aplicativos que usam o Kerberos ou o NTLM na autenticação.
  • Aplicativos que usam o Active Directory como um diretório de LDAP para verificar nomes de usuário e senhas.

Para aceitar essas cargas de trabalho, é possível estender a floresta do Active Directory local para o GCP. Por exemplo, ao implantar uma floresta de recursos no GCP e conectá-la à floresta do Active Directory local, como mostrado no diagrama a seguir.

Como conectar uma floresta de recursos à floresta do Active Directory local

Para mais detalhes sobre essa abordagem e outras maneiras de implantar o Active Directory em um ambiente híbrido, consulte Padrões para usar o Active Directory em um ambiente híbrido.

Como estender a floresta do Active Directory local para o GCP ao implantar controladores de domínio extras no GCP

Vantagens

  • É possível aproveitar ao máximo o Active Directory nas suas cargas de trabalho, incluindo a capacidade de associar máquinas Windows ao domínio do Active Directory.
  • A disponibilidade dos aplicativos baseados no Active Directory executados no GCP não depende da disponibilidade dos recursos locais ou da conectividade com a rede local. O padrão é adequado para cenários híbridos de continuidade dos negócios.

Práticas recomendadas

  • Use o Cloud VPN ou o Cloud Interconnect para estabelecer a conectividade híbrida entre o GCP e a rede local.
  • Para diminuir a comunicação entre o GCP e a rede local, crie um site do Active Directory separado para usar nas implantações do GCP. Utilize um único site por VPC compartilhada ou, para diminuir a comunicação entre regiões, um por VPC compartilhada e região.
  • Crie um domínio do Active Directory separado dedicado aos recursos implantados no GCP e o adicione à floresta atual. O uso de um domínio separado reduz a sobrecarga da replicação e os tamanhos das partições.
  • Para aumentar a disponibilidade, implante pelo menos dois controladores de domínio distribuídos por várias zonas. Se você usa várias regiões, implante os controladores em cada uma delas.
  • Use um projeto do GCP separado com uma VPC compartilhada para implantar controladores de domínio e conceder acesso a esse projeto com base na abordagem de menor privilégio. Ao gerar uma senha ou acessar o console serial das instâncias do controlador de domínio, você evita que membros não autorizados do projeto corrompam o domínio.
  • Pense na implantação de um farm de servidores do AD FS e do GCDS no GCP. Com essa abordagem, é possível federar o Active Directory com o Cloud Identity sem depender da disponibilidade de recursos ou da conectividade com a rede local.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…