Este documento é a segunda parte de uma série de várias partes que discute como estender a solução de gerenciamento de identidade para o Google Cloud a fim de permitir que os usuários da força de trabalho autentiquem e consumam serviços em um ambiente de computação híbrido.
A série inclui os documentos a seguir:
- Autenticação de usuários da força de trabalho em um ambiente híbrido
- Padrões de autenticação de usuários da força de trabalho em um ambiente híbrido (este documento).
Introdução
Quando você estende seu cenário de TI para o Google Cloud como parte de uma estratégia híbrida, recomendamos adotar uma abordagem consistente para gerenciar 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 (IdP) externo com o Google Cloud. O objetivo é permitir que o Google se torne um IdP dos usuários da sua força de trabalho para que as identidades do Google sejam mantidas automaticamente e o IdP continue sendo a fonte de verdade.
- Padrões para estender um IdP para o Google Cloud. Com esses padrões, você permite que os aplicativos implantados no Google Cloud reutilizem o IdP: conectando-se a ele diretamente ou mantendo uma réplica do IdP no Google Cloud.
Padrões para federar um IdP externo com o Google Cloud
Para permitir o acesso ao console do Google Cloud, à Google Cloud CLI ou a qualquer outro recurso que use o Google como IdP, um usuário da força de trabalho precisa ter uma identidade do Google. Manter identidades do Google para cada funcionário seria complicado quando todos os funcionários já têm uma conta em um IdP. Ao federar identidades de usuário entre o IdP e o Google Cloud, é possível automatizar a manutenção das Contas do Google e vincular 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.
Federar o Active Directory com o Cloud Identity usando o Google Cloud Directory Sync e o AD FS
Se você usa o Active Directory como IdP, pode federá-lo com o Cloud Identity usando o Google Cloud Directory Sync (GCDS) e os Serviços de Federação do Active Directory (AD FS):
- O GCDS é uma ferramenta gratuita oferecida pelo Google que implementa o processo de sincronização. O GCDS se comunica com o 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 Federar o Google Cloud com o Active Directory.
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
- Ao solicitar o recurso protegido, você é redirecionado para a tela de logon do Google. Nela, você precisa fornecer seu endereço de e-mail.
- 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.
- 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).
- Depois da sua autenticação pelo AD FS, você é redirecionado de volta para o recurso protegido.
Vantagens
- A abordagem permite uma experiência de logon único em aplicativos e recursos locais no Google Cloud.
- Se você configurou o AD FS para exigir autenticação multifator, essa configuração é aplicada automaticamente ao Google Cloud.
- Não é necessário sincronizar senhas ou outras credenciais com o Google.
- Como a API Cloud Identity pode ser acessada publicamente, não é necessário configurar uma conectividade híbrida entre a rede local e o Google Cloud.
Práticas recomendadas
- O Active Directory e o Cloud Identity usam uma estrutura lógica diferente. Entenda as diferenças e avalie a maneira de mapear domínios, identidades e grupos mais adequados à sua situação. Consulte nosso guia sobre a federação do Google Cloud com o Active Directory para conferir informações mais detalhadas.
- Sincronize os grupos, além dos usuários. Com essa abordagem, é possível configurar o Cloud IAM para usar as associações a grupos no Active Directory para controlar quem tem acesso a quais recursos no Google Cloud.
- Implante e exponha o AD FS para que os usuários da força de trabalho possam acessar ele. Mas faça isso na medida certa. Embora os usuários da força de trabalho precisem acessar o AD FS, não é necessário que o AD FS possa ser acessado pelo Google ou por qualquer aplicativo implantado no Google Cloud.
- 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 Google Cloud ou qualquer outro recurso que use o Google como IdP. Portanto, verifique se o AD FS e os controladores de domínio de que o AD FS depende são implantados e dimensionados para atender aos seus objetivos de disponibilidade.
- Se você usa o Google Cloud para garantir a continuidade dos negócios, depender de um AD FS local pode prejudicar a intenção de usar o Google Cloud como uma cópia independente da implantação. Nesse caso, considere implantar réplicas de todos os sistemas relevantes no Google Cloud:
- Replique o Active Directory no Google Cloud e implante o GCDS para execução no Google Cloud.
- Execute servidores dedicados do AD FS no Google Cloud. Esses servidores usam os controladores de domínio do Active Directory em execução no Google Cloud.
- Configure o Cloud Identity para usar os servidores do AD FS implantados no Google Cloud para logon único.
Como federar o Azure AD com o Cloud Identity
Se você for um cliente do Microsoft Office 365 ou do Azure, talvez tenha conectado seu Active Directory local ao Azure AD. Se todas as contas de usuário que possivelmente precisam de acesso ao Google Cloud já estiverem sendo sincronizadas com o Azure AD, reutilize essa integração federando o Cloud Identity com o Azure AD, conforme mostrado no diagrama a seguir.
Para informações mais detalhadas sobre essa abordagem, consulte Como federar o Google Cloud com o Azure Active Directory.
Experiência do usuário
- Ao solicitar o recurso protegido, você é redirecionado para a tela de logon do Google. Nela, você precisa fornecer seu endereço de e-mail.
- 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.
- 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.
- 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 permite uma experiência de logon único no Office 365, no Azure e nos recursos do Google Cloud.
- Se você configurou o Azure AD para exigir a autenticação multifator (MFA), a MFA será aplicada automaticamente ao Google Cloud.
- 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.
- Não é necessário sincronizar senhas ou outras credenciais com o Google.
- Como a API Cloud Identity é acessível publicamente, não é necessário configurar a conectividade híbrida entre a rede local e o Google Cloud ou entre o Azure e o Google Cloud.
- É possível exibir o console do Google Cloud 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 forma de mapear domínios, identidades e grupos se adapta melhor à sua situação. Para informações mais detalhadas, consulte Como federar o Google Cloud com o Azure AD.
- Sincronize os grupos, além dos usuários. Essa abordagem permite configurar o IAM para usar assinaturas de grupo no Azure AD e controlar quem tem acesso aos recursos no Google Cloud.
- Se você usa o Google Cloud para garantir a continuidade dos negócios, depender do Azure AD para autenticação pode prejudicar a intenção de usar o Google Cloud como uma cópia independente da implantação.
Padrões para estender um IdP externo ao Google Cloud
Alguns dos apps que você planeja implantar no Google Cloud podem exigir o uso de protocolos de autenticação não oferecidos pelo Cloud Identity. Para oferecer suporte a essas cargas de trabalho, você precisa permitir que esses aplicativos usem seu IdP no Google Cloud.
As seções a seguir descrevem padrões comuns para permitir que seu IdP seja usado por cargas de trabalho implantadas no Google Cloud.
Expor um AD FS local para o Google Cloud
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.
Ao usar o AD FS, o aplicativo pode autenticar um usuário. No entanto, como a autenticação não se baseia em uma identidade do Google, o aplicativo não pode realizar chamadas de API autenticadas com credenciais de usuário. Em vez disso, todas as chamadas de APIs do Google Cloud precisam ser autenticadas usando uma conta de serviço.
Experiência do usuário
- 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.
- 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.
- 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 Google Cloud.
Práticas recomendadas
- Implante e exponha o AD FS para que os usuários da força de trabalho possam acessar ele. Mas faça isso na medida certa. Embora os usuários da força de trabalho precisem acessar o AD FS, não é necessário que o AD FS possa ser acessado pelo Google ou por qualquer aplicativo implantado no Google Cloud.
- 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 informações de grupo expostas como declarações no
IdTokensemitidas pelo AD FS, considere recuperar as informações do grupo 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 ativada para a delegação em todo o domínio do Google Workspace.
Como expor um diretório LDAP local para o Google Cloud
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 apps para usar outros meios como o SAML na autenticação, conceda a eles acesso a um diretório LDAP local.
Vantagens
- Não é necessário alterar o aplicativo.
Práticas recomendadas
- Use o Cloud VPN ou o Cloud Interconnect para estabelecer conectividade híbrida entre o Google Cloud e a rede local para que você não precise expor o diretório 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 LDAP ou a conectividade privada entre o Google Cloud e sua rede local ficarem indisponíveis, talvez os usuários não consigam mais usar um aplicativo baseado em LDAP. Portanto, garanta que os respectivos servidores sejam implantados e dimensionados para atender aos objetivos de disponibilidade. Considere o uso de túneis VPN redundantes ou de interconexões.
- Se você usa o Google Cloud para garantir a continuidade dos negócios, depender de um diretório LDAP local pode prejudicar a intenção de usar o Google Cloud como uma cópia independente da implantação atual. Nesse caso, considere replicar o diretório LDAP para o Google Cloud.
- Se você usa o Active Directory, considere executar uma réplica no Google Cloud, especialmente se você planeja ingressar em máquinas Windows executadas no Google Cloud para o Active Directory.
Como replicar um diretório LDAP local no Google Cloud
A replicação de um diretório LDAP local para o Google Cloud é semelhante ao padrão de Como expor um diretório LDAP local ao Google Cloud. Para aplicativos que usam LDAP para verificar nomes de usuário e senhas, a intenção dessa abordagem é poder executar esses aplicativos no Google Cloud. Em vez de permitir que esses aplicativos consultem seu diretório LDAP local, é possível manter uma réplica do diretório local no Google Cloud.
Vantagens
- Não é necessário alterar o aplicativo.
- A disponibilidade de aplicativos baseados em LDAP em execução no Google Cloud não depende da disponibilidade do diretório local nem 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 conectividade híbrida entre o Google Cloud e a rede local para que você não precise expor o diretório 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 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 Google Cloud com uma VPC compartilhada para implantar réplicas LDAP e conceder acesso a esse projeto com base no privilégio mínimo.
Como estender um Active Directory local para o Google Cloud
Algumas das cargas de trabalho que você planeja implantar no Google Cloud podem depender do Active Directory Domain Services, 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 oferecer suporte a essas cargas de trabalho, estenda a floresta local do Active Directory para o Google Cloud, por exemplo, implantando uma floresta de recursos no Google Cloud e conectando-a à floresta do Active Directory no local, como no diagrama a seguir.
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.
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 de aplicativos baseados no Active Directory em execução no Google Cloud não depende da disponibilidade de 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 conectividade híbrida entre o Google Cloud e a rede local.
- Para minimizar a comunicação entre o Google Cloud e sua rede local, crie um site do Active Directory separado para implantações do Google Cloud. 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 Google Cloud e adicione o domínio à floresta atual. Usar um domínio separado ajuda a reduzir a sobrecarga de replicação e os tamanhos de partição.
- 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 separado do Google Cloud com uma VPC compartilhada para implantar controladores de domínio e conceder acesso a este projeto com base no privilégio mínimo. 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.
- Considere a implantação de um farm de servidores do AD FS e do GCDS no Google Cloud. Essa abordagem permite que você faça a federação do Active Directory com o Cloud Identity sem depender da disponibilidade de recursos ou da conectividade com a rede local.
A seguir
- Saiba mais sobre como federar o Google Cloud com o Active Directory.
- Saiba mais sobre os padrões de uso do Active Directory em um ambiente híbrido.
- Veja como federar o Cloud Identity com o Azure AD.
- Projete a hierarquia de recursos da sua zona de destino do Google Cloud.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.