Guia

Integrar centenas de novos usuários a partir de um arquivo CSV fornecido pelo RH.

→Use o recurso de upload em massa do Admin Console. Inclua a coluna `Org Unit Path` no CSV para colocar os usuários diretamente nas OUs corretas.

Por quê: Método mais eficiente para criação em massa de usuários com atribuição correta de políticas sem scripting. Mais direto do que o GCDS para integração única.

Um funcionário está saindo. Preserve os arquivos do Drive dele e transfira-os para o controle de seu gerente.

→Antes de suspender ou excluir o usuário, use a ferramenta de Transferência de Dados do Admin Console para transferir a propriedade de todos os arquivos do Drive para o gerente.

Por quê: Preserva a integridade dos dados e garante a continuidade dos negócios. A transferência direta de propriedade é mais limpa do que o compartilhamento e mantém uma trilha de auditoria clara.

Diferentes departamentos e equipes exigem configurações de serviço e políticas de segurança exclusivas.

→Crie uma estrutura hierárquica de Unidade Organizacional (OU) (por exemplo, /Vendas/Leste, /Vendas/Oeste). Aplique políticas amplas na OU pai e substituições específicas nas OUs filhas.

Por quê: As OUs fornecem herança de políticas hierárquicas, permitindo controle escalável e granular sobre as configurações para diferentes populações de usuários.

Automatizar a associação a grupos para todos os usuários do departamento de Engenharia, incluindo novos contratados.

→Crie um Grupo Dinâmico com uma consulta de associação baseada no atributo de usuário `department==Engineering`.

Por quê: Gerencia automaticamente a associação com base em atributos de usuário, eliminando atualizações manuais e garantindo consistência à medida que as funções dos usuários mudam.

Conceder à equipe de Help Desk a capacidade de redefinir senhas apenas para usuários na OU do escritório principal.

→Crie uma função de administrador personalizada com apenas o privilégio "Usuários > Redefinir Senha". Atribua esta função à equipe de Help Desk e defina seu escopo para ser aplicada apenas à OU de destino.

Por quê: Implementa o princípio do privilégio mínimo. Funções personalizadas e com escopo evitam que administradores delegados afetem usuários ou configurações fora de sua responsabilidade.

Sincronização do Active Directory via GCDS, mas os UPNs dos usuários têm um domínio antigo. É necessário criar usuários com o novo domínio correto.

→No GCDS, configure uma regra de transformação de atributo para o atributo de endereço de e-mail para substituir a string do domínio antigo pela nova.

Por quê: Corrige dados durante o processo de sincronização sem exigir a modificação do Active Directory de origem, o que muitas vezes não é viável.

Um usuário foi excluído acidentalmente há 15 dias. O gerente dele agora precisa de um arquivo crítico do Drive.

→No Admin Console, restaure o usuário excluído recentemente. A janela de recuperação é de 20 dias. Uma vez restaurado, transfira os dados e, se necessário, exclua novamente.

Por quê: Usuários excluídos são recuperáveis por 20 dias. Esta é a única maneira de recuperar seus dados se nenhuma retenção/retenção legal do Vault estivesse em vigor.

Uma equipe de suporte precisa de um endereço de e-mail compartilhado (suporte@) onde vários membros possam gerenciar, atribuir e rastrear consultas de clientes.

→Crie um Google Group e configure-o como uma "Caixa de Entrada Colaborativa".

Por quê: Este tipo de grupo é projetado para fluxos de trabalho compartilhados, permitindo a atribuição de conversas e o rastreamento de resolução, o que é superior a uma lista de distribuição padrão ou conta de usuário compartilhada.

Impor uma isenção de responsabilidade legal padronizada e branding em todos os e-mails de saída do departamento de Vendas.

→Nas configurações do Gmail, configure uma regra de conformidade com uma ação de "Anexar rodapé", com escopo para a OU de Vendas.

Por quê: Isso anexa um rodapé não editável no nível do servidor, garantindo 100% de conformidade. Soluções no lado do usuário podem ser modificadas ou ignoradas.

Permitir que os usuários compartilhem arquivos do Drive externamente, mas apenas com domínios de parceiros específicos e aprovados.

→Nas configurações de compartilhamento do Drive, adicione domínios de parceiros à lista de "Domínios permitidos" e defina a política de compartilhamento para "Apenas domínios permitidos".

Por quê: Proporciona um equilíbrio entre segurança e colaboração, impedindo o compartilhamento de dados com partes externas não autorizadas enquanto habilita parcerias aprovadas.

Permitir convidados externos no Google Meet, mas impedir que eles entrem antes da chegada de um anfitrião interno.

→Nas configurações de segurança do Google Meet, certifique-se de que "O anfitrião deve admitir pessoas de fora da sua organização" (solicitação para entrar) esteja habilitado.

Por quê: Aprimora a segurança da reunião criando uma sala de espera virtual, dando ao anfitrião controle sobre quando e quais participantes externos podem entrar.

Migrar de um servidor Exchange local para o Gmail com tempo de inatividade zero para e-mails de entrada.

→Configure a entrega dupla. Configure uma rota de e-mail no Workspace para encaminhar e-mails para o servidor Exchange legado e, em seguida, aponte os registros MX para o Google.

Por quê: Garante que os usuários recebam e-mails em ambas as caixas de entrada durante uma migração faseada, evitando mensagens perdidas e permitindo uma transição suave.

Impedir que os usuários instalem complementos de terceiros não verificados em Docs, Sheets e Gmail.

→Nas configurações do Marketplace, configure uma lista de permissões de aplicativos aprovados e defina a política para restringir os usuários apenas a aplicativos permitidos.

Por quê: Reduz o risco de segurança de aplicativos de terceiros maliciosos ou que consomem muitos dados, criando um "jardim murado" de ferramentas aprovadas pela TI.

Para conformidade, todos os e-mails devem ser retidos por 7 anos, mesmo que os usuários os excluam de suas caixas de entrada.

→No Google Vault, crie uma regra de retenção personalizada para o Gmail com duração de 7 anos. Não defina uma expiração.

Por quê: A retenção do Vault opera independentemente das ações do usuário. Ela fornece um arquivo legalmente defensável para eDiscovery e conformidade, separado das caixas de entrada ativas dos usuários.

O departamento jurídico exige que todos os dados de funcionários específicos (custodiantes) sejam preservados indefinidamente para litígios pendentes.

→No Google Vault, crie um Caso (Matter), identifique os usuários como custodiantes e aplique uma Retenção Legal (Legal Hold) a eles.

Por quê: Uma Retenção Legal (Legal Hold) anula todas as políticas de retenção e exclusão. Os dados são preservados até que a retenção seja explicitamente liberada, garantindo que as obrigações de preservação legal sejam cumpridas.

Impedir que os usuários compartilhem acidentalmente documentos contendo números de cartão de crédito ou PII com partes externas.

→Crie uma regra de Prevenção contra Perda de Dados (DLP) em `Security > Data protection`. Use detectores predefinidos (por exemplo, Número de Cartão de Crédito) e defina a condição de acionamento para compartilhamento externo. A ação deve ser "Bloquear compartilhamento externo".

Por quê: O DLP digitaliza o conteúdo em tempo real para impor automaticamente políticas de proteção de dados, reduzindo o risco de erro humano que leva a violações de dados.

Para cumprir o GDPR, garanta que todos os dados primários de funcionários europeus sejam armazenados em repouso em data centers europeus.

→Coloque os usuários europeus em uma OU dedicada. Em `Account > Data regions`, aplique uma política de região de dados para "Europa" a essa OU.

Por quê: Este recurso aborda diretamente os requisitos de residência de dados, controlando a localização geográfica de armazenamento de dados primários para serviços específicos.

Um usuário excluiu permanentemente um arquivo crítico do Drive há 10 dias. Ele não está mais na lixeira dele.

→Se uma regra de retenção ou retenção legal do Vault estivesse cobrindo o usuário, procure o arquivo no Vault e exporte-o para recuperação.

Por quê: O Vault atua como uma rede de segurança. Dados cobertos por retenção/retenções legais são preservados mesmo após serem "permanentemente" excluídos pelo usuário.

Um funcionário sob retenção legal está saindo. É necessário preservar os dados e a retenção legal dele, mas liberar a licença completa.

→Suspenda a conta do usuário e atribua uma licença de "Usuário Arquivado" (AU). Os dados permanecem no Vault e sujeitos à retenção legal.

Por quê: As licenças AU são uma maneira econômica de preservar dados de ex-funcionários para fins de conformidade e legais, sem consumir uma licença completa e ativa.

Permitir acesso ao Workspace apenas de dispositivos gerenciados pela empresa ou quando conectado à rede do escritório.

→Configure o Acesso Consciente do Contexto (Context-Aware Access). Crie níveis de acesso para "Dispositivo compatível" (do gerenciamento de endpoint) e "Faixa de IP corporativa". Aplique uma política que exija um desses níveis para acesso.

Por quê: Este é o cerne de um modelo de confiança zero para o Workspace, mudando de um perímetro de rede para a aplicação de políticas de acesso com base no contexto do dispositivo e do usuário, independentemente do local.

Uma conta de usuário é suspeita de ter sido comprometida. O atacante pode ter sessões ativas ou acesso a aplicativos.

→Imediatamente: 1) Redefina a senha do usuário. 2) Revogue todos os tokens OAuth de terceiros. 3) Encerre todas as sessões da web.

Por quê: Este processo de três etapas garante que o atacante seja bloqueado de todos os pontos de acesso: login direto, acesso baseado em aplicativo e sessões de navegador existentes.

Impedir que os usuários concedam acesso a dados corporativos a aplicativos OAuth de terceiros arriscados ou não verificados.

→Em `Security > API controls`, configure o "App access control" para bloquear aplicativos não configurados por padrão e, em seguida, adicione aplicativos específicos e verificados à lista de "Confiáveis".

Por quê: Isso muda de uma postura de segurança de padrão-permitir para padrão-negar para aplicativos de terceiros, dando à TI controle total sobre quais aplicativos podem acessar dados da empresa.

Implementar Single Sign-On (SSO) com um IdP de terceiros, mas garantir o acesso de administrador se o IdP estiver inoperante.

→Configure o SAML SSO para toda a organização. Crie um grupo ou OU separado para Super Administradores e configure uma máscara de rede ou configuração de grupo para excluí-los do requisito de SSO.

Por quê: Fornece um procedimento crítico de "break-glass", permitindo que os administradores façam login com credenciais do Google durante uma interrupção do IdP para gerenciar o ambiente.

Impedir que atacantes falsifiquem seu domínio em ataques de phishing e melhorar a entregabilidade de e-mails.

→Configure corretamente os registros DNS SPF, DKIM e DMARC para o seu domínio. Defina a política DMARC para `p=reject` para aplicação total.

Por quê: Esses três padrões trabalham juntos para autenticar seu e-mail de saída, permitindo que os servidores receptores rejeitem com confiança mensagens fraudulentas que se passem pelo seu domínio.

Necessidade de notificação proativa de eventos de segurança, como logins suspeitos ou avisos de ataques patrocinados pelo governo.

→Monitore regularmente a Central de Alertas. Configure regras de alerta para enviar notificações por e-mail para eventos de alta prioridade para a equipe de segurança.

Por quê: A Central de Alertas é o hub centralizado para eventos relacionados à segurança. Notificações proativas permitem uma resposta rápida a incidentes.

Um usuário perdeu o telefone e não tem códigos de backup, ficando bloqueado de sua conta protegida por 2SV.

→Como administrador, selecione o usuário e gere códigos de verificação de backup de uso único para que ele recupere o acesso.

Por quê: Este é o procedimento padrão e seguro para recuperação de usuário, sem a necessidade de desativar temporariamente o 2SV, o que enfraqueceria a segurança.

Exigir a forma mais forte de autenticação para proteger usuários de alto risco contra phishing.

→Imponha uma política de Verificação em 2 Etapas que exija o uso apenas de Chaves de Segurança (FIDO).

Por quê: As chaves de segurança são resistentes a phishing porque usam criptografia de chave pública e verificam a origem da página de login, diferentemente de TOTP ou SMS que podem ser alvo de phishing.

Um telefone móvel gerenciado pela empresa contendo dados confidenciais foi perdido ou roubado.

→Usando o Admin Console em Dispositivos, localize o dispositivo e inicie imediatamente um comando remoto de "Limpar dispositivo".

Por quê: Esta é a principal resposta de segurança para um dispositivo gerenciado perdido. Ele restaura remotamente as configurações de fábrica do dispositivo ou limpa o perfil de trabalho, protegendo os dados corporativos contra acesso não autorizado.

Impor um conjunto padrão de configurações de segurança e extensões obrigatórias em todos os navegadores Chrome corporativos (Windows, Mac).

→Registre os navegadores no Chrome Browser Cloud Management (CBCM). Aplique políticas à OU do usuário/navegador para instalar extensões forçadamente, bloquear outras e configurar configurações.

Por quê: O CBCM fornece gerenciamento centralizado e baseado em nuvem de navegadores Chrome em qualquer plataforma, garantindo política e postura de segurança consistentes.

Permitir que os funcionários usem dispositivos Android pessoais para o trabalho (BYOD), mantendo os dados corporativos separados e seguros.

→Implemente o Gerenciamento Avançado de Dispositivos Móveis e imponha a criação de um Perfil de Trabalho do Android em dispositivos de propriedade dos funcionários.

Por quê: Um Perfil de Trabalho cria um contêiner no nível do SO que isola aplicativos e dados de trabalho dos dados pessoais. O contêiner inteiro pode ser limpo remotamente sem afetar os arquivos pessoais do usuário.

Uma política de Acesso Consciente do Contexto (Context-Aware Access) deve verificar se um dispositivo é de propriedade da empresa e criptografado antes de conceder acesso.

→Implante a extensão/agente de Verificação de Endpoint do Google em todos os dispositivos gerenciados. Configure o nível de acesso do CAA para exigir um status de dispositivo "Compatível" ou "De propriedade da empresa".

Por quê: A Verificação de Endpoint é o agente que coleta e relata a postura do dispositivo para o mecanismo CAA, habilitando o controle de acesso baseado na confiança do dispositivo.

Usuários relatam que e-mails para um parceiro específico estão sendo rejeitados ou gravemente atrasados.

→Use a ferramenta "Pesquisa de Registro de E-mail" no Admin Console. Procure uma mensagem de amostra para ver o caminho completo de entrega, carimbos de data/hora e quaisquer erros de rejeição do servidor receptor.

Por quê: A Pesquisa de Registro de E-mail é a ferramenta definitiva para diagnosticar problemas de entrega. Ela fornece detalhes granulares que confirmam se a mensagem saiu do Google e por que foi rejeitada.

Vários usuários em toda a organização estão subitamente incapazes de fazer login, relatando erros de verificação de credenciais.

→O problema provavelmente está no Provedor de Identidade (IdP) de terceiros. Verifique o status do serviço IdP e a validade do certificado SAML na configuração do SSO.

Por quê: Falhas de login generalizadas e repentinas em um ambiente SSO quase sempre apontam para o IdP externo, e não para contas de usuário individuais.

Um usuário relata que os códigos de 6 dígitos de seu aplicativo Google Authenticator estão sendo consistentemente rejeitados.

→Instrua o usuário a verificar e sincronizar o relógio em seu dispositivo móvel. O aplicativo Authenticator possui um recurso de correção de hora.

Por quê: Os códigos OTP baseados em tempo (TOTP) são altamente dependentes do tempo sincronizado. O desvio do relógio é a causa mais comum de rejeição de código.

Usuários em um escritório específico reclamam da má qualidade de vídeo do Google Meet, enquanto outros escritórios estão bem.

→Investigue a rede local no escritório afetado. Verifique a saturação da largura de banda, alta latência/jitter e garanta que as regras do firewall não estejam limitando ou bloqueando o tráfego do Google Meet.

Por quê: Problemas de desempenho específicos da localização são quase sempre causados por problemas de rede local, e não pelo próprio serviço do Google.

Um usuário não está recebendo e-mails de um remetente externo, mas seus colegas estão.

→Verifique as configurações pessoais do Gmail do usuário em busca de filtros ou regras de remetentes bloqueados que possam estar redirecionando ou excluindo os e-mails recebidos.

Por quê: Quando um problema afeta apenas um único usuário, a causa é na maioria das vezes uma configuração no nível do usuário, e não uma política no nível da organização.

Um usuário pode iniciar uma gravação do Meet, mas ela falha ao salvar após o término da reunião.

→Verifique a cota de armazenamento do Google Drive do usuário. As gravações falham se o usuário não tiver espaço suficiente.

Por quê: As gravações do Meet são salvas no "Meu Drive" do organizador em uma pasta "Gravações do Meet". Uma cota do Drive cheia é a razão mais comum para falhas de salvamento.