Esta secção apresenta como usar o Cloud ID para gerir as identidades que os seus funcionários usam para aceder aos Google Cloud serviços.
Fornecedor de identidade externo como fonte de informação fidedigna
Recomendamos que federar a sua conta do Cloud Identity com o seu fornecedor de identidade existente. A federação ajuda a garantir que os seus processos de gestão de contas existentes se aplicam ao Google Cloud e a outros serviços Google.
Se não tiver um fornecedor de identidade existente, pode criar contas de utilizador diretamente no Cloud Identity.
O diagrama seguinte mostra uma vista de alto nível da federação de identidades e do início de sessão único (SSO). Usa o Microsoft Active Directory, localizado no ambiente no local, como o fornecedor de identidade de exemplo.
Este diagrama descreve as seguintes práticas recomendadas:
- As identidades dos utilizadores são geridas num domínio do Active Directory que está localizado no ambiente no local e federado com o Cloud Identity. O Active Directory usa a Sincronização de diretórios do Google Cloud para aprovisionar identidades no Cloud ID.
- Os utilizadores que tentam iniciar sessão nos serviços Google são redirecionados para o fornecedor de identidade externo para o Início de sessão único com SAML, usando as respetivas credenciais existentes para autenticação. Não são sincronizadas palavras-passe com o Cloud Identity.
A tabela seguinte fornece links para orientações de configuração para fornecedores de identidade.
| Fornecedor de identidade | Orientação |
|---|---|
| Active Directory | |
| Microsoft Entra ID (anteriormente, Azure AD) | |
| Outros fornecedores de identidade externos (por exemplo, Ping ou Okta) |
Recomendamos vivamente que aplique a autenticação multifator no seu fornecedor de identidade com um mecanismo resistente a phishing, como uma chave de segurança Titan.
As definições recomendadas para o Cloud ID não são automatizadas através do código Terraform neste projeto. Consulte os controlos administrativos do Cloud ID para ver as definições de segurança recomendadas que tem de configurar, além de implementar o código do Terraform.
Grupos para controlo de acesso
Um principal é uma identidade à qual pode ser concedido acesso a um recurso. Os membros incluem contas Google para utilizadores, grupos Google, contas do Google Workspace, domínios do Cloud ID e contas de serviço. Alguns serviços também lhe permitem conceder acesso a todos os utilizadores que se autenticam com uma Conta Google ou a todos os utilizadores na Internet. Para que um principal interaja com os Google Cloud serviços, tem de lhe conceder funções na gestão de identidade e de acesso (IAM).
Para gerir funções de IAM em grande escala, recomendamos que atribua utilizadores a grupos com base nas respetivas funções profissionais e requisitos de acesso e, em seguida, conceda funções de IAM a esses grupos. Deve adicionar utilizadores a grupos através dos processos no seu fornecedor de identidade existente para a criação de grupos e a adesão.
Não recomendamos a concessão de funções da IAM a utilizadores individuais, uma vez que as atribuições individuais podem aumentar a complexidade da gestão e auditoria de funções.
O projeto configura grupos e funções para acesso apenas de visualização aos recursos fundamentais. Recomendamos que implemente todos os recursos no projeto através do pipeline de base e que não conceda funções a utilizadores nem grupos para modificar recursos de base fora do pipeline.
A tabela seguinte mostra os grupos que são configurados pela planta para ver recursos básicos.
| Nome | Descrição | Funções | Âmbito |
|---|---|---|---|
grp-gcp-org-admin@example.com | Administradores com privilégios elevados que podem conceder funções de IAM ao nível da organização. Pode aceder a qualquer outra função. Este privilégio não é recomendado para utilização diária. | Administrador da organização | organização |
grp-gcp-billing-admin@example.com |
Administradores com privilégios elevados que podem modificar a conta de faturação do Google Cloud. Este privilégio não é recomendado para utilização diária. | Administrador da conta de faturação | organização |
grp-gcp-billing-viewer@example.com | A equipa responsável por ver e analisar os gastos em todos os projetos. | Leitor da conta de faturação | organização |
| Utilizador do BigQuery | projeto de faturação | ||
grp-gcp-audit-viewer@example.com |
A equipa responsável pela auditoria dos registos relacionados com a segurança. | projeto de registo | |
grp-gcp-security-reviewer@example.com |
A equipa responsável pela revisão da segurança na nuvem. | Revisor de segurança | organização |
grp-gcp-network-viewer@example.com |
A equipa responsável pela visualização e manutenção das configurações de rede. | Visualizador da rede de computação | organização |
grp-gcp-scc-admin@example.com |
A equipa responsável pela configuração do Security Command Center. | Editor de administração do centro de segurança | organização |
grp-gcp-secrets-admin@example.com |
A equipa responsável pela gestão, armazenamento e auditoria das credenciais e outros segredos usados pelas aplicações. | Administrador do Secret Manager | projetos de segredos |
grp-gcp-kms-admin@example.com |
A equipa responsável pela aplicação da gestão de chaves de encriptação para cumprir os requisitos de conformidade. | Visualizador do Cloud KMS | Projetos de kms |
À medida que cria as suas próprias cargas de trabalho com base na fundação, cria grupos adicionais e concede funções do IAM com base nos requisitos de acesso de cada carga de trabalho.
Recomendamos vivamente que evite as funções básicas (como Proprietário, Editor ou Leitor) e use funções predefinidas em alternativa. As funções básicas são excessivamente permissivas e representam um potencial risco de segurança. As funções de proprietário e editor podem levar à escalada de privilégios e ao movimento lateral, e a função de leitor inclui acesso à leitura de todos os dados. Para ver as práticas recomendadas sobre funções do IAM, consulte o artigo Use o IAM em segurança.
Contas de superadministrador
Os utilizadores do Cloud ID com a conta de superadministrador contornam as definições de SSO da organização e autenticam-se diretamente no Cloud ID. Esta exceção é intencional, para que o superadministrador possa continuar a aceder à consola do Cloud ID em caso de erro de configuração ou indisponibilidade do SSO. No entanto, isto significa que tem de considerar proteção adicional para as contas de superadministrador.
Para proteger as suas contas de superadministrador, recomendamos que aplique sempre a validação em dois passos com chaves de segurança no Cloud Identity. Para mais informações, consulte as práticas recomendadas de segurança para contas de administrador.
Problemas com contas de utilizador de consumidor
Se não usou o Cloud Identity nem o Google Workspace antes de integrar o Google Cloud, é possível que os funcionários da sua organização já estejam a usar contas de consumidor associadas às respetivas identidades de email corporativas para aceder a outros serviços Google, como a Google Marketing Platform ou o YouTube. As contas de consumidor são contas que pertencem e são totalmente geridas pelos indivíduos que as criaram. Uma vez que essas contas não estão sob o controlo da sua organização e podem incluir dados pessoais e empresariais, tem de decidir como consolidar estas contas com outras contas empresariais.
Recomendamos que consolide as contas de utilizador de consumidor existentes como parte da integração no Google Cloud. Se ainda não estiver a usar o Google Workspace para todas as suas contas de utilizador, recomendamos que bloqueie o acesso a contas de consumidor.
Controlos administrativos do Cloud ID
O Cloud Identity tem vários controlos administrativos que não são automatizados pelo código do Terraform no projeto. Recomendamos que aplique cada um destes controlos de segurança de práticas recomendadas no início do processo de criação da sua base.
| Controlo | Descrição |
|---|---|
| Implemente a validação em dois passos | As contas de utilizador podem ser comprometidas através de phishing, engenharia social, pulverização de palavras-passe ou várias outras ameaças. A validação em dois passos ajuda a mitigar estas ameaças. Recomendamos que aplique a validação em dois passos a todas as contas de utilizador na sua organização com um mecanismo resistente ao phishing, como chaves de segurança Titan ou outras chaves baseadas nas normas FIDO U2F (CTAP1) resistentes ao phishing. |
| Defina a duração da sessão para os Google Cloud serviços | Os tokens OAuth persistentes nas estações de trabalho dos programadores podem constituir um risco de segurança se forem expostos. Recomendamos que defina uma política de reautenticação para exigir autenticação a cada 16 horas através de uma chave de segurança. |
| Defina a duração da sessão para os Serviços Google | (Apenas para clientes do Google Workspace)
As sessões Web persistentes noutros serviços Google podem constituir um risco de segurança se forem expostas. Recomendamos que aplique uma duração máxima da sessão Web e a alinhe com os controlos de duração da sessão no seu fornecedor de SSO. |
| Partilhe dados do Cloud Identity com os serviços Google Cloud | Os registos de auditoria da atividade do administrador do Google Workspace ou do Cloud ID são normalmente geridos e visualizados na consola do administrador, separadamente dos seus registos no seu Google Cloud ambiente. Estes registos contêm informações relevantes para o seu ambiente, como eventos de início de sessão do utilizador. Google Cloud Recomendamos que partilhe os registos de auditoria do Cloud Identity com o seu ambiente para gerir centralmente os registos de todas as origens.Google Cloud |
| Configure a validação após o SSO | O plano pressupõe que configurou o SSO com o seu fornecedor de identidade externo. Recomendamos que ative uma camada de controlo adicional com base na análise de risco de início de sessão da Google. Depois de aplicar esta definição, os utilizadores podem ver desafios de início de sessão adicionais baseados em risco no início de sessão se a Google considerar que um início de sessão de utilizador é suspeito. |
| Corrija problemas com contas de utilizadores consumidores | Os utilizadores com um endereço de email válido no seu domínio, mas sem uma Conta Google, podem inscrever-se em contas de consumidor não geridas. Estas contas podem conter dados empresariais, mas não são controladas pelos seus processos de gestão do ciclo de vida da conta. Recomendamos que tome medidas para garantir que todas as contas de utilizador são contas geridas. |
| Desative a recuperação de conta para contas de superadministrador | A recuperação automática da conta de superadministrador está desativada por predefinição para todos os novos clientes (os clientes existentes podem ter esta definição ativada). Desativar esta definição ajuda a mitigar o risco de um telemóvel comprometido, um email comprometido ou um ataque de engenharia social permitir que um atacante obtenha privilégios de superadministrador sobre o seu ambiente. Planeie um processo interno para um superadministrador contactar outro superadministrador na sua organização se tiver perdido o acesso à respetiva conta e certifique-se de que todos os superadministradores estão familiarizados com o processo de recuperação assistida pelo apoio técnico. |
| Aplique e monitorize os requisitos de palavras-passe para os utilizadores | Na maioria dos casos, as palavras-passe dos utilizadores são geridas através do seu fornecedor de identidade externo, mas as contas de superadministrador ignoram o SSO e têm de usar uma palavra-passe para iniciar sessão no Cloud Identity. Desative a reutilização de palavras-passe e monitorize a força das palavras-passe de todos os utilizadores que utilizam uma palavra-passe para iniciar sessão no Cloud Identity, especialmente contas de superadministrador. |
| Defina políticas ao nível da organização para a utilização de grupos | Por predefinição, as contas de utilizadores externos podem ser adicionadas a grupos no Cloud Identity. Recomendamos que configure as definições de partilha para que os proprietários dos grupos não possam adicionar membros externos. Tenha em atenção que esta restrição não se aplica à conta de superadministrador nem a outros administradores delegados com autorizações de administrador do Google Groups. Uma vez que a federação do seu fornecedor de identidade é executada com privilégios de administrador, as definições de partilha de grupos não se aplicam a esta sincronização de grupos. Recomendamos que reveja os controlos no fornecedor de identidade e no mecanismo de sincronização para garantir que os membros que não pertencem ao domínio não são adicionados a grupos ou que aplica restrições de grupos. |
O que se segue?
- Leia sobre a estrutura organizacional (próximo documento desta série).