Este documento é a segunda 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 utilizadores da sua força de trabalho autentiquem e consumam serviços num ambiente de computação híbrida.
A série é composta pelos seguintes documentos:
- Autenticar utilizadores da força de trabalho num ambiente híbrido
- Padrões para autenticar utilizadores da força de trabalho num ambiente híbrido (este documento)
Introdução
Quando expande o seu panorama de TI Google Cloud como parte de uma estratégia híbrida, recomendamos que adote uma abordagem consistente à gestão de identidades em todos os ambientes. À medida que cria e personaliza a sua arquitetura para cumprir estas restrições e requisitos, pode basear-se em alguns padrões comuns. Estes padrões dividem-se em duas categorias:
- Padrões para federar um fornecedor de identidade (IdP) externo com Google Cloud. O objetivo destes padrões é permitir que a Google se torne um IdP para os utilizadores da sua força de trabalho, de modo que as identidades Google sejam mantidas automaticamente e o seu IdP permaneça a fonte de informações fidedignas.
- Padrões para estender um IdP a Google Cloud. Nestes padrões, permite que as aplicações implementadas no Google Cloud reutilizem o seu IdP, quer estabelecendo ligação diretamente ao mesmo, quer mantendo uma réplica do seu IdP no Google Cloud.
Padrões para federar um IdP externo com o Google Cloud
Para ativar o acesso à Google Cloud consola, à CLI do Google Cloud ou a qualquer outro recurso que use a Google como IdP, um utilizador da força de trabalho tem de ter uma identidade Google. A manutenção das identidades Google para cada funcionário seria complicada quando todos os funcionários já têm uma conta num IdP. Ao federar as identidades dos utilizadores entre o seu IdP e o Google Cloud, pode automatizar a manutenção das Contas Google e associar o respetivo ciclo de vida às contas existentes. A federação ajuda a garantir o seguinte:
- O seu IdP continua a ser a única fonte de verdade para a gestão de identidades.
- Para todas as contas de utilizador que o IdP gere ou um subconjunto selecionado dessas contas, é criada automaticamente uma Conta Google.
- Se uma conta for desativada ou eliminada no seu IdP, a Conta Google correspondente é suspensa ou eliminada.
- Para impedir a cópia de palavras-passe ou outras credenciais, a ação de autenticação de um utilizador é delegada no seu IdP.
Federe o Active Directory com o Cloud ID através da Sincronização de diretórios do Google Cloud e do AD FS
Se usar o Active Directory como IdP, pode federar o Active Directory com o Cloud Identity através da Sincronização de diretórios do Google Cloud (GCDS) e dos Active Directory Federation Services (AD FS):
- O GCDS é uma ferramenta gratuita fornecida pela Google que implementa o processo de sincronização. O GCDS comunica com a Identity Platform através da camada de ligação segura (SSL) e, normalmente, é executado no ambiente de computação existente.
- O AD FS é fornecido pela Microsoft como parte do Windows Server. Com o AD FS, pode usar o Active Directory para a autenticação federada. Normalmente, o AD FS é executado no ambiente de computação existente.
Para informações mais detalhadas sobre esta abordagem, consulte o artigo Federar Google Cloud com o Active Directory.
Para uma variação deste padrão, também pode usar os serviços de diretório simples do Active Directory (AD LDS) ou um diretório LDAP diferente com o AD FS ou outro IdP compatível com SAML.
Experiência do utilizador
- Quando pede o recurso protegido, é redirecionado para o ecrã de início de sessão da Google, que lhe pede o seu endereço de email.
- Se o endereço de email estiver associado a uma conta sincronizada a partir do Active Directory, é feito o redirecionamento para o AD FS.
- Consoante a configuração do AD FS, pode ver um ecrã de início de sessão a pedir o nome de utilizador e a palavra-passe do Active Directory. Em alternativa, o AD FS pode tentar iniciar sessão automaticamente com base no seu início de sessão no Windows (IWA).
- Quando o AD FS autentica a sua identidade, é redirecionado novamente para o recurso protegido.
Vantagens
- Esta abordagem permite uma experiência de início de sessão único em aplicações no local e recursos no Google Cloud.
- Se configurou o AD FS para exigir a autenticação multifator, essa configuração aplica-se automaticamente ao Google Cloud.
- Não precisa de sincronizar palavras-passe nem outras credenciais com a Google.
- Uma vez que a API Cloud Identity está acessível publicamente, não é necessário configurar conetividade híbrida entre a sua rede no local e Google Cloud.
Práticas recomendadas
- O Active Directory e o Cloud Identity usam uma estrutura lógica diferente. Certifique-se de que compreende as diferenças e avalie qual a forma de mapear domínios, identidades e grupos que melhor se adequa à sua situação. Consulte o nosso guia sobre a federação Google Cloud com o Active Directory para obter informações mais detalhadas.
- Sincronizar grupos além de utilizadores. Com esta abordagem, pode configurar o IAM para poder usar as subscrições de grupos no Active Directory para controlar quem tem acesso aos recursos no Google Cloud.
- Implemente e exponha o AD FS para que os utilizadores da força de trabalho possam aceder ao mesmo, mas não o exponha mais do que o necessário. Embora os utilizadores do pessoal tenham de poder aceder ao AD FS, não existe nenhum requisito para que o AD FS esteja acessível a partir do Google ou de qualquer aplicação implementada no Google Cloud.
- Pondere ativar a autenticação integrada do Windows (IWA) no AD FS para permitir que os utilizadores iniciem sessão automaticamente com base no respetivo início de sessão no Windows.
- Se o AD FS ficar indisponível, os utilizadores podem não conseguir usar a Google Cloud consola nem qualquer outro recurso que use o Google como IdP. Por isso, certifique-se de que o AD FS e os controladores de domínio dos quais o AD FS depende estão implementados e dimensionados para cumprir os seus objetivos de disponibilidade.
- Se usar o Google Cloud para ajudar a garantir a continuidade da empresa, confiar
num AD FS no local pode prejudicar a intenção de usar o
Google Cloud como uma cópia independente da sua implementação. Neste caso, considere implementar réplicas de todos os sistemas relevantes em Google Cloud:
- Replique o Active Directory para Google Cloud e implemente o GCDS para ser executado em Google Cloud.
- Execute servidores AD FS dedicados em Google Cloud. Estes servidores usam os controladores de domínio do Active Directory em execução no Google Cloud.
- Configure o Cloud ID para usar os servidores do AD FS implementados no Google Cloud para o Início de sessão único.
Federe o Entra ID com o Cloud ID
Se for cliente do Microsoft Office 365 ou do Azure, pode ter associado o seu Active Directory no local ao Microsoft Entra ID (anteriormente Azure AD). Se todas as contas de utilizador que potencialmente precisam de acesso a Google Cloud já estiverem a ser sincronizadas com o Entra ID, pode reutilizar esta integração federando o Cloud Identity com o Entra ID, conforme mostra o diagrama seguinte.
Para obter informações mais detalhadas sobre esta abordagem, consulte o artigo Federar Google Cloud com o Microsoft Entra ID.
Experiência do utilizador
- Quando pede o recurso protegido, é redirecionado para o ecrã de início de sessão da Google, que lhe pede o seu endereço de email.
- Se o endereço de email estiver associado a uma conta que foi sincronizada a partir do Entra ID, é feito o redirecionamento para o Entra ID.
- Consoante a forma como o Active Directory no local está ligado ao Entra ID, o Entra ID pode pedir-lhe um nome de utilizador e uma palavra-passe. Em alternativa, pode ser redirecionado para um AD FS no local.
- Após a autenticação bem-sucedida com o Entra ID, é feito o redirecionamento de volta para o recurso protegido.
Vantagens
- Não precisa de instalar software adicional no local.
- Esta abordagem permite uma experiência de início de sessão único no Office 365, no Azure e nos recursos no Google Cloud.
- Se configurou o Entra ID para exigir a autenticação multifator (MFA), a MFA aplica-se automaticamente ao Google Cloud.
- Se o seu Active Directory no local usar vários domínios ou florestas e tiver configurado uma configuração personalizada do Entra ID Connect para mapear esta estrutura para um inquilino do Entra ID, pode tirar partido deste trabalho de integração.
- Não precisa de sincronizar palavras-passe nem outras credenciais com a Google.
- Uma vez que a API Cloud Identity é acessível publicamente, não é necessário configurar a conetividade híbrida entre a sua rede no local e Google Cloud ou entre o Azure eGoogle Cloud.
- Pode apresentar a Google Cloud consola como um mosaico no portal do Office 365.
Práticas recomendadas
- Uma vez que o Entra ID e o Cloud Identity usam uma estrutura lógica diferente, certifique-se de que compreende as diferenças. Avalie qual a forma de mapear domínios, identidades e grupos que melhor se adequa à sua situação. Para mais informações, consulte o artigo sobre a federação Google Cloud com o Entra ID.
- Sincronizar grupos além de utilizadores. Com esta abordagem, pode configurar o IAM para poder usar as associações a grupos no Entra ID para controlar quem tem acesso aos recursos no Google Cloud.
- Se usar o Google Cloud para ajudar a garantir a continuidade da empresa, confiar no Entra ID para autenticação pode prejudicar a intenção de usar o Google Cloud como uma cópia independente da sua implementação.
Padrões para estender um IdP externo a Google Cloud
Algumas das aplicações que planeia implementar em Google Cloud podem exigir a utilização de protocolos de autenticação não oferecidos pelo Cloud Identity. Para suportar estas cargas de trabalho, tem de permitir que estas aplicações usem o seu IdP a partir de Google Cloud.
As secções seguintes descrevem padrões comuns para permitir que o seu IdP seja usado por cargas de trabalho implementadas no Google Cloud.
Exponha um AD FS no local a Google Cloud
Se uma aplicação exigir a utilização de WS-Trust ou WS-Federation, ou depender de funcionalidades ou reivindicações específicas do AD FS quando utilizar o OpenID Connect, pode permitir que a aplicação utilize diretamente o AD FS para autenticação.
Ao usar o AD FS, uma aplicação pode autenticar um utilizador. No entanto, uma vez que a autenticação não se baseia numa identidade Google, a aplicação não vai poder fazer chamadas API autenticadas com credenciais do utilizador. Em alternativa, todas as chamadas às Google Cloud APIs têm de ser autenticadas através de uma conta de serviço.
Experiência do utilizador
- Quando pede o recurso protegido, é redirecionado para o ecrã de início de sessão do ADFS, que lhe pede o seu endereço de email. Se o AD FS não estiver exposto publicamente na Internet, o acesso ao AD FS pode exigir que tenha ligação à rede da sua empresa ou à VPN corporativa.
- Consoante a configuração do AD FS, pode ver um ecrã de início de sessão a pedir o nome de utilizador e a palavra-passe do Active Directory. Em alternativa, o AD FS pode tentar iniciar sessão automaticamente com base no seu início de sessão no Windows.
- Quando o AD FS autentica a sua identidade, é redirecionado novamente para o recurso protegido.
Vantagens
- Pode usar protocolos de autenticação que não são suportados pelo Cloud Identity, incluindo WS-Trust e WS-Federation.
- Se a aplicação tiver sido desenvolvida e testada em relação ao AD FS, pode evitar riscos que possam surgir ao mudar a aplicação para usar o Cloud Identity.
- Não tem de configurar a conetividade híbrida entre a sua rede no local e o Google Cloud.
Práticas recomendadas
- Implemente e exponha o AD FS para que os utilizadores da força de trabalho possam aceder ao mesmo, mas não o exponha mais do que o necessário. Embora os utilizadores do pessoal tenham de poder aceder ao AD FS, não existe nenhum requisito para que o AD FS esteja acessível a partir do Google ou de qualquer aplicação implementada no Google Cloud.
- Se o AD FS ficar indisponível, os utilizadores podem não conseguir usar a aplicação. Certifique-se de que o AD FS e os controladores de domínio dos quais depende estão implementados e dimensionados para cumprir os seus objetivos de disponibilidade.
- Considere refatorar as aplicações que dependem do WS-Trust e do WS-Federation para usar o SAML ou o OpenID Connect.
- Se a aplicação depender de informações de grupos expostas como reivindicações
em
IdTokensemitidas pelo AD FS, considere obter informações de grupos de uma origem diferente, como a API Directory. A consulta da API Directory é uma operação privilegiada que requer a utilização de uma conta de serviço ativada para a delegação ao nível do domínio do Google Workspace.
Exponha um diretório LDAP no local para Google Cloud
Algumas das suas aplicações podem exigir que os utilizadores indiquem o respetivo nome de utilizador e palavra-passe e usem estas credenciais para tentar uma operação de associação LDAP. Se não conseguir modificar estas aplicações para usar outros meios, como o SAML, para realizar a autenticação, pode conceder-lhes acesso a um diretório LDAP no local.
Vantagens
- Não precisa de alterar a sua aplicação.
Práticas recomendadas
- Use o Cloud VPN ou o Cloud Interconnect para estabelecer uma ligação híbrida entre o Google Cloud e a sua rede nas instalações, para que não precise de expor o diretório LDAP através da Internet. Google Cloud
- Verifique se a latência introduzida pela consulta de um diretório LDAP no local não afeta negativamente a experiência do utilizador.
- Certifique-se de que a comunicação entre a aplicação e o diretório LDAP está encriptada. Pode conseguir esta encriptação através da Cloud VPN ou da Cloud Interconnect com LDAP/S.
- Se o diretório LDAP ou a conetividade privada entre o Google Cloud e a sua rede no local ficar indisponível, os utilizadores podem deixar de conseguir usar uma aplicação baseada em LDAP.Google Cloud Por conseguinte, certifique-se de que os respetivos servidores são implementados e dimensionados para cumprir os seus objetivos de disponibilidade e considere usar túneis de VPN redundantes ou interligações.
- Se usar o Google Cloud para garantir a continuidade da empresa, confiar num diretório LDAP no local pode comprometer a intenção de usar oGoogle Cloud como uma cópia independente da sua implementação existente. Neste caso, considere replicar o diretório LDAP em vez disso. Google Cloud
- Se usar o Active Directory, considere executar uma réplica no Google Cloud em vez disso, especialmente se planear juntar ao domínio máquinas Windows em execução noGoogle Cloud ao Active Directory.
Replique um diretório LDAP no local para Google Cloud
A replicação de um diretório LDAP no local para Google Cloud é semelhante ao padrão de exposição de um diretório LDAP no local para Google Cloud. Para aplicações que usam LDAP para validar nomes de utilizador e palavras-passe, o objetivo desta abordagem é poder executar essas aplicações no Google Cloud. Em vez de permitir que essas aplicações consultem o seu diretório LDAP no local, pode manter uma réplica do diretório no local no Google Cloud.
Vantagens
- Não precisa de alterar a sua aplicação.
- A disponibilidade das aplicações baseadas em LDAP em execução no Google Cloud não depende da disponibilidade do diretório no local nem da conetividade à rede no local. Este padrão é adequado para cenários híbridos de continuidade do negócio.
Práticas recomendadas
- Use o Cloud VPN ou o Cloud Interconnect para estabelecer uma ligação híbrida entre o Google Cloud e a sua rede nas instalações, para que não precise de expor o diretório LDAP através da Internet. Google Cloud
- Certifique-se de que a replicação entre o diretório LDAP no local é realizada através de um canal seguro.
- Implemente várias réplicas do diretório LDAP em várias zonas ou regiões para cumprir os seus objetivos de disponibilidade. Pode usar um equilibrador de carga interno para distribuir ligações LDAP entre várias réplicas implementadas na mesma região.
- Use um projeto Google Cloud separado com uma VPC partilhada para implementar réplicas do LDAP e conceder acesso a este projeto com base no princípio do menor privilégio.
Estenda um Active Directory no local para Google Cloud
Algumas das cargas de trabalho que planeia implementar no Google Cloud podem depender dos serviços de domínio do Active Directory, por exemplo:
- Máquinas Windows que têm de ser associadas a um domínio
- Aplicações que usam Kerberos ou NTLM para autenticação
- Aplicações que usam o Active Directory como um diretório LDAP para validar nomes de utilizador e palavras-passe
Para suportar estas cargas de trabalho, pode expandir a floresta do Active Directory no local Google Cloud, por exemplo, implementando uma floresta de recursosGoogle Cloud e associando-a à floresta do Active Directory no local, como no diagrama seguinte.
Para mais detalhes sobre esta abordagem e outras formas de implementar o Active Directory num ambiente híbrido, consulte os padrões de utilização do Active Directory num ambiente híbrido.
Vantagens
- As suas cargas de trabalho podem tirar total partido do Active Directory, incluindo a capacidade de associar máquinas Windows ao domínio do Active Directory.
- A disponibilidade de aplicações baseadas no Active Directory em execução no Google Cloud não depende da disponibilidade de recursos no local nem da conetividade à rede no local. O padrão é adequado para cenários híbridos de continuidade do negócio.
Práticas recomendadas
- Use o Cloud VPN ou o Cloud Interconnect para estabelecer uma conetividade híbrida entre o Google Cloud e a sua rede no local.
- Para minimizar a comunicação entre o Google Cloud e a sua rede no local, crie um site do Active Directory separado para implementações do Google Cloud. Pode usar um único site por VPC partilhada ou, para minimizar a comunicação entre regiões, um site por VPC partilhada e região.
- Crie um domínio do Active Directory separado dedicado aos recursos implementados no Google Cloud e adicione o domínio à floresta existente. A utilização de um domínio separado ajuda a reduzir a sobrecarga de replicação e os tamanhos das partições.
- Para aumentar a disponibilidade, implemente, pelo menos, dois controladores de domínio, distribuídos por várias zonas1. Se usar várias regiões, considere implementar controladores de domínio em cada região.
- Use um Google Cloud projeto separado com uma VPC partilhada para implementar controladores de domínio e conceder acesso a este projeto com base no princípio do menor privilégio. Ao gerar uma palavra-passe ou aceder à consola série de instâncias do controlador de domínio, os membros do projeto não autorizados podem, de outra forma, comprometer o domínio.
- Considere implementar uma farm de servidores do AD FS e o GCDS no Google Cloud. Esta abordagem permite-lhe federar o Active Directory com o Cloud ID sem depender da disponibilidade de recursos ou da conetividade à rede no local.
O que se segue?
- Saiba mais sobre a federação Google Cloud com o Active Directory.
- Saiba mais sobre os padrões de utilização do Active Directory num ambiente híbrido.
- Saiba como pode federar o Cloud ID com o Entra ID.
- Crie a hierarquia de recursos para a sua Google Cloud zona de destino.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.
-
Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões. ↩