Nesta seção, mostramos como usar o Cloud Identity para gerenciar as identidades que os funcionários usam para acessar os serviços do Google Cloud.
Provedor de identidade externo como fonte de verdade
Recomendamos federar sua conta do Cloud Identity com o provedor de identidade atual. A federação ajuda você a garantir que seus processos de gerenciamento de conta atuais se apliquem ao Google Cloud e a outros serviços do Google.
Se você não tiver um provedor de identidade, poderá criar contas de usuário diretamente no Cloud Identity.
O diagrama a seguir mostra uma visualização de alto nível da federação de identidade e do Logon único (SSO). Ele usa o Microsoft Active Directory, localizado no ambiente local, como o provedor de identidade de exemplo.
Este diagrama descreve as seguintes práticas recomendadas:
- As identidades do usuário são gerenciadas em um domínio do Active Directory localizado no ambiente local e federado ao Cloud Identity. O Active Directory usa o Google Cloud Directory Sync para provisionar identidades para o Cloud Identity.
- Os usuários que tentam fazer login nos serviços do Google são redirecionados para o provedor de identidade externo para Logon único com SAML, usando as credenciais atuais para autenticar. Nenhuma senha é sincronizada com o Cloud Identity.
A tabela a seguir contém links para as orientações de configuração para provedores de identidade.
| Provedor de identidade | Orientação |
|---|---|
| Active Directory | |
| ID do Microsoft Entra (antigo Azure AD) | |
| Outros provedores de identidade externos (por exemplo, Ping ou Okta) |
É altamente recomendável que você aplique a autenticação multifator no seu provedor de identidade com um mecanismo resistente a phishing, como uma chave de segurança Titan.
As configurações recomendadas para o Cloud Identity não são automatizadas por meio do código do Terraform neste blueprint. Consulte Controles administrativos do Cloud Identity para ver as configurações de segurança recomendadas que você precisa definir além de implantar o código do Terraform.
Grupos para controle de acesso
Um principal é uma identidade que pode receber acesso a um recurso. Os principais incluem Contas do Google para usuários, grupos do Google, contas do Google Workspace, domínios do Cloud Identity e contas de serviço. Alguns serviços também permitem conceder acesso a todos os usuários que se autenticarem com uma Conta do Google ou a todos os usuários na Internet. Para que um principal interaja com os serviços do Google Cloud, conceda papéis no Identity and Access Management (IAM).
Para gerenciar os papéis do IAM em escala, recomendamos que você atribua usuários a grupos com base nas funções do job e nos requisitos de acesso. Em seguida, conceda os papéis do IAM a esses grupos. Adicione usuários a grupos usando os processos no seu provedor de identidade atual para criação e associação de grupos.
Não recomendamos conceder papéis do IAM a usuários individuais, porque as atribuições individuais podem aumentar a complexidade do gerenciamento e da auditoria de papéis.
O blueprint configura grupos e papéis para acesso somente leitura aos recursos fundamentais. Recomendamos que você implante todos os recursos no blueprint por meio do pipeline de base e não conceda papéis a usuários a grupos para modificar recursos de fundação fora do pipeline.
A tabela a seguir mostra os grupos configurados pelo blueprint para visualizar os recursos básicos.
| Nome | Descrição | Papéis | Escopo |
|---|---|---|---|
grp-gcp-org-admin@example.com |
Administradores altamente privilegiados que podem conceder papéis do IAM no nível da organização. Eles podem acessar qualquer outro papel. Esse privilégio não é recomendado para uso diário. | Administrador da organização | organização |
grp-gcp-billing-admin@example.com |
Administradores altamente privilegiados que podem modificar a conta do Cloud Billing. Esse privilégio não é recomendado para uso diário. | Administrador de contas de faturamento | organização |
grp-gcp-billing-viewer@example.com |
A equipe responsável por visualizar e analisar os gastos em todos os projetos. | Leitor da conta de faturamento | organização |
| Usuário do BigQuery | Projeto de faturamento | ||
grp-gcp-audit-viewer@example.com |
A equipe responsável por auditar os registros relacionados à segurança. | projeto do logging | |
grp-gcp-security-reviewer@example.com |
A equipe responsável por analisar a segurança da nuvem. | Revisor de segurança | organização |
grp-gcp-network-viewer@example.com |
A equipe responsável por visualizar e manter as configurações de rede. | Leitor da rede do Compute | organização |
grp-gcp-scc-admin@example.com |
A equipe responsável pela configuração do Security Command Center. | Editor administrador da Central de segurança | organização |
grp-gcp-secrets-admin@example.com |
a equipe responsável por gerenciar, armazenar e auditar credenciais e outros secrets usados por aplicativos. | Administrador do Secret Manager | projetos de secrets |
grp-gcp-kms-admin@example.com |
A equipe responsável por aplicar o gerenciamento de chaves de criptografia para atender aos requisitos de conformidade. | Leitor do Cloud KMS | projetos de kms |
À medida que desenvolve suas próprias cargas de trabalho sobre a base, você cria outros grupos e concede papéis do IAM com base nos requisitos de acesso de cada carga de trabalho.
É altamente recomendável evitar papéis básicos (como Proprietário, Editor ou Leitor) e usar papéis predefinidos. Os papéis básicos são permissivos demais e representam um possível risco à segurança. Os papéis de Proprietário e Editor podem levar ao escalonamento de privilégios e à movimentação lateral, e o papel de Leitor inclui acesso para ler todos os dados. Para práticas recomendadas sobre papéis do IAM, consulte Usar o IAM com segurança.
Contas de superadministrador
Os usuários do Cloud Identity com a conta de superadministrador ignoram as configurações de SSO da organização e são autenticados diretamente no Cloud Identity. Essa exceção ocorre desde a concepção, para que o superadministrador ainda possa acessar o console do Cloud Identity em caso de falha ou configuração incorreta do SSO. No entanto, isso significa que você precisa considerar mais proteção para contas de superadministrador.
Para proteger suas contas de superadministrador, recomendamos que você sempre aplique a verificação em duas etapas com chaves de segurança no Cloud Identity. Veja mais detalhes em Práticas recomendadas de segurança para contas de administrador.
Problemas com contas de usuário pessoais
Se você nunca usou o Cloud Identity ou o Google Workspace antes de se integrar ao Google Cloud, é possível que os funcionários da sua organização já estejam usando contas pessoais que sejam associadas a identidades de e-mail corporativo para acessar outros serviços do Google, como Google Marketing Platform ou YouTube. As contas pessoais são contas totalmente controladas e gerenciadas pelas pessoas que as criaram. Como essas contas não estão sob o controle da sua organização e podem incluir dados pessoais e corporativos, você precisa decidir como consolidar essas contas com outras contas corporativas.
Recomendamos que você consolide as contas de usuário pessoais como parte da integração ao Google Cloud. Se você ainda não estiver usando o Google Workspace para todas as suas contas de usuário, recomendamos bloquear a criação de novas contas pessoais.
Controles administrativos do Cloud Identity
O Cloud Identity tem vários controles administrativos que não são automatizados pelo código do Terraform no blueprint. Recomendamos que você aplique cada um desses controles de segurança de práticas recomendadas no início do processo de criação da base.
| Controle | Descrição |
|---|---|
| Implantar a verificação em duas etapas | As contas de usuário podem ser comprometidas por phishing, engenharia social, senha ou várias outras ameaças. A verificação em duas etapas ajuda a reduzir essas ameaças. Recomendamos que você aplique a verificação em duas etapas a todas as contas de usuário da sua organização com um mecanismo resistente a phishing, como as chaves de segurança Titan ou outras chaves baseadas em os padrões FIDO U2F (CTAP1) resistente a phishing. |
| Definir a duração da sessão para os serviços do Google Cloud | Tokens OAuth persistentes em estações de trabalho do desenvolvedor podem ser um risco de segurança se expostos. Recomendamos definir uma política de reautenticação que exija autenticação a cada 16 horas usando uma chave de segurança. |
| Definir a duração da sessão para Serviços do Google | (Apenas para clientes do Google Workspace)
Sessões da Web persistentes em outros serviços do Google podem ser um risco de segurança se expostas. Recomendamos que você aplique uma duração máxima da sessão da Web e alinhe isso aos controles de duração da sessão no seu provedor de SSO. |
| Compartilhar dados do Cloud Identity com os serviços do Google Cloud | Os registros de auditoria de atividade de amin do Google Workspace ou do Cloud Identity geralmente são gerenciados e visualizados no Admin Console, separadamente dos registros no ambiente do Google Cloud. Esses registros contêm informações relevantes para seu ambiente do Google Cloud, como eventos de login do usuário. Recomendamos que você compartilhe os registros de auditoria do Cloud Identity com o ambiente do Google Cloud para gerenciar de maneira centralizada registros de todas as origens. |
| Configurar a "Verificação pós-SSO" | O blueprint presume que você configure o SSO com seu provedor de identidade externo. Recomendamos que você ative uma camada adicional de controle com base na análise de risco de login do Google. Depois que você aplicar essa configuração, os usuários poderão ver outros desafios de login com base em riscos no login se o Google considerar que um login de usuário é suspeito. |
| Corrigir problemas com contas de usuário pessoais | usuários com um endereço de e-mail válido no seu domínio, mas nenhuma Conta do Google, podem se inscrever em contas pessoais não gerenciadas. Essas contas podem conter dados corporativos, mas não são controladas pelos processos de gerenciamento do ciclo de vida. Recomendamos que você tome medidas para garantir que todas as contas de usuário sejam gerenciadas. |
| Desativar a recuperação de contas de superadministrador | A recuperação automática da conta de superadministrador fica desativada por padrão para todos os novos clientes (é possível que os clientes atuais tenham essa configuração ativada). Desativar essa configuração ajuda a reduzir o risco de que um telefone comprometido, um e-mail comprometido ou um ataque de engenharia social possa permitir que um invasor receba privilégios de superadministrador sobre seu ambiente. Planeje um processo interno para que um superadministrador entre em contato com outro superadministrador da organização se perder o acesso à conta e garanta que todos os superadministradores conheçam o processo de recuperação assistida por suporte. |
| Aplicar e monitorar requisitos de senha para os usuários | Na maioria dos casos, as senhas de usuário são gerenciadas por meio do provedor de identidade externo, mas as contas de superadministrador ignoram o SSO e precisam usar uma senha para fazer login no Cloud Identity. Desative a reutilização e monitore a força da senha de todos os usuários que usam uma senha para fazer login no Cloud Identity, especialmente as contas de superadministrador. |
| Definir políticas de uso de grupos para toda a organização | Por padrão, as contas de usuário externas podem ser adicionadas a grupos no Cloud Identity. Recomendamos que você defina configurações de compartilhamento para que os proprietários dos grupos não possam adicionar membros externos. Essa restrição não se aplica à conta de superadministrador ou a outros administradores delegados com permissões de administrador do Grupos. Como a federação do seu provedor de identidade é executada com privilégios de administrador, as configurações de compartilhamento de grupo não se aplicam a essa sincronização de grupo. Recomendamos que você revise os controles no provedor de identidade e no mecanismo de sincronização para garantir que participantes que não sejam do domínio não sejam adicionados a grupos ou que você aplique restrições de grupo. |
A seguir
- Leia sobre a estrutura organizacional (próximo documento desta série).