O eterno problema do GCP: usuários não gerenciados

Agora vamos imaginar o primeiro cenário desde o começo. A sua empresa tem os e-mails hospedados em um servidor Exchange on-premise, no Microsoft 365 ou até mesmo em um serviço de e-mail da GoDaddy. Mas surge a necessidade de gerenciar todas as contas Google em um só lugar para ter mais controle e visibilidade.

Talvez até para usar contas corporativas no Google Analytics ou no YouTube e habilitar SSO, de modo que, ao desativar ou excluir o usuário do seu sistema, ele também seja removido do Google. Aí você registra o seu domínio em uma assinatura corporativa ou gerenciada de serviços Google — como o Google Workspace (antigo G-Suite) ou o CloudIdentity.

Você confirma que o domínio é seu e começa a usar a assinatura. Aí decide criar [email protected]. Mas, ao criar, o sistema avisa que esse e-mail já está em uso. Lembre-se da primeira regra: só pode haver um endereço de e-mail.

Pronto: você agora tem um problema de contas de usuário não gerenciadas duplicadas\ conflitantes!

Agora imagine que você é o super admin de uma conta totalmente gerenciada do Google Workspace na empresa. Suponha que um admin crie uma regra de roteamento padrão ou um mapa de endereços de destinatário pelo console de admin do Google da sua assinatura do Google Workspace para encaminhar qualquer e-mail enviado para [email protected] (endereço de e-mail privado).

Esse mesmo admin acessa o link de cadastro de contas de usuário não gerenciadas e registra o endereço de e-mail. Um e-mail de verificação será enviado para a caixa de entrada da empresa, onde precisará ser confirmado.

Pronto: você agora tem uma conta de usuário Google não gerenciada que pode, em tese, se inscrever no Google Analytics, criar canais no YouTube com o domínio da sua empresa e até ter acesso não autorizado ao GCP. Para piorar, você não sabe nada sobre esse usuário como admin, nem consegue redefinir a senha etc.

Hoje, o Google não impede a criação de contas pessoais ou de consumidor com o sufixo de um domínio registrado. Você também não tem nenhum recurso no console de admin para evitar que isso aconteça. Se você acionar o suporte do Google pedindo explicitamente para bloquear essa opção na sua conta corporativa do G-Suite ou Google Workspace, eles não conseguem fazer isso e nem vão tentar.

A solução

Se você tem uma conta do Google Workspace (G-Suite), pode criar um endereço catch-all pelo link a seguir.

Um endereço catch-all garante que mensagens enviadas para um endereço incorreto ainda sejam recebidas por alguém da organização, que pode então analisá-las e decidir o que fazer. Isso ajuda a identificar usuários que tentam ativar uma conta Google não gerenciada. Mas, se for um admin que define uma regra de roteamento, digamos com um "mapa de endereços de destinatário", o catch-all não resolve.

Então a melhor solução, que funciona como contorno para qualquer sistema de e-mail, é simplesmente cortar a comunicação entre o processo de verificação e o usuário. Crie uma regra de conformidade de conteúdo com as seguintes condições (todas precisam ser atendidas — AND, não OR):

Direção de entrada AND Corpo corresponde ao regex `^[0–9]{6}$` AND Corpo contém o texto "Verify this email is yours" AND Assunto contém o texto "Verify your email address" AND Cabeçalho do remetente contém o texto "[email protected]".

Enquanto o Google não alterar esses metadados, você está protegido. Também recomendo não rejeitar os e-mails de verificação. Mude o destinatário para um admin, igual ao endereço catch-all, para que você consiga monitorar — em vez de rejeitar e-mails que talvez atendam aos critérios, mas não se encaixam nesse cenário.

Você também pode reforçar a proteção, se necessário. No GCP, dá para definir uma política de restrição de compartilhamento por domínio — clique aqui para ver como.

Isso impedirá que usuários fora do domínio sejam adicionados ao IAM dos projetos da organização. Tenha em mente que isso não funciona retroativamente, e você não conseguirá adicionar usuários gmail.com aos seus projetos. Apenas usuários gerenciados dentro da sua conta do Google Workspace ou CloudIdentity poderão receber permissões IAM.

Lidando com as contas não gerenciadas

Primeiro, você precisará ter o papel de "Super Admin" na sua assinatura do Google Workspace ou CloudIdentity para realizar as ações a seguir. Ao fazer login no Console de Admin, você poderá abrir a " Ferramenta de transferência para usuários não gerenciados".

Ou pela seção "Usuários", clicando em "Mais":

Ao abrir a ferramenta de transferência, você verá uma lista de todos os usuários não gerenciados com contas duplicadas e conflitantes. Para cada um, você tem a opção de enviar um convite para transferir a conta não gerenciada para a sua empresa. Quando você envia o convite, cabe à pessoa (supondo que o convite tenha mesmo sido recebido) aceitar ou recusar a solicitação de transferência.

Uma vez aceito, o nome de usuário é atribuído à sua conta corporativa e passa a aparecer na sua lista de usuários. O usuário continua se autenticando como antes, com a diferença de que a conta passa a estar sujeita à política da empresa (2FA, serviços permitidos ou não, tempo limite de sessão etc.). Se esse usuário tinha acesso a projetos no GCP, ele continuará tendo.

Em caso de não resposta ou recusa, você pode tomar providências (criar regras de roteamento para encaminhar mensagens enviadas a essas contas para a caixa de entrada de um admin), reenviar o convite e aceitá-lo em nome do usuário (afinal, você é o proprietário do domínio e os registros MX apontam para a conta da sua empresa).

Sugiro fazer isso com cautela e tentar localizar o funcionário. Pode ser um ex-colaborador que simplesmente esqueceu de encerrar a conta ou nem sabia dessa pendência. Você também pode simplesmente seguir em frente e criar o usuário.

Ao criar o usuário pelo console de admin, aparece uma tela perguntando se você quer enviar um "convite de transferência" ao usuário ou criá-lo mesmo assim — isso vai criar uma nova identidade gerenciada dentro da sua assinatura corporativa — e renomear o usuário original para algo como "username%[email protected]".

Quando o usuário quiser usar a conta dele para acessar um serviço Google, terá a opção de escolher "Conta de trabalho" — a que você criou — ou "Conta pessoal" — a "username%[email protected]".

Os dados do usuário permanecem na conta original, enquanto todos os dados relacionados, como Google Analytics ou canais do YouTube, ficam na conta pessoal dele. Esses dados não estarão acessíveis pelo novo nome de usuário que você criou.

Atenção: a API é usada quando você utiliza o GCDS (Google Cloud Directory Sync) do MS-AD on-premise para o Google, no provisionamento automático de usuários do MS-AAD (Microsoft Azure Active Directory) ou em soluções de terceiros, como o Okta. A API não tem como saber se uma conta é pessoal, de consumidor ou não gerenciada. Ela simplesmente cria os usuários automaticamente, e o usuário pessoal não gerenciado será renomeado, sem pedir ao admin que faça a transferência primeiro.