| Exemplo concreto | |
|---|---|
.
(onde antes ficava a "tela de consentimento do OAuth ", reorganizada nas abas Branding, Público, Acesso a dados e Clientes). O passo a passo é mantido atualizado pelo Google em sua documentação oficial para desenvolvedores, e não faz sentido duplicá-lo aqui: ele muda a cada reformulação do design do console.
O que não muda são as quatro decisões a seguir.
Decisão 1: em nome de quem a integração atua?
Esta é a decisão da qual dependem todas as outras, e aquela que é tomada de forma errada com mais frequência. Há três modelos e não são intercambiáveis.
Conta de serviço direta
A integração atua por conta própria, como uma identidade que não pertence a nenhuma pessoa. Ela funciona quando alguém lhe concede acesso explícito aos recursos de que necessita: adicioná-la como membro de um drive compartilhado, dar-lhe permissão para uma planilha específica ou autorizá-la em um espaço do Chat. Esse é o modelo. mais simples e o mais seguro, e por isso deveria ser o ponto de partida.
Consentimento OAuth por usuário
Cada pessoa autoriza a integração explicitamente e vê exatamente quais permissões concede. O acesso é dela, e ela pode revogá-lo quando quiser. É o modelo correto para complementos e aplicativos que os funcionários usam de forma consciente.
Delegação de domínio (domain-wide delegation)
Uma conta de serviço recebe autorização para agir em nome de qualquer usuário do domínio, sem solicitar permissão. É isso que viabiliza o arquivamento de e-mails, as auditorias de conformidade, as migrações e as sincronizações em massa.
E é também o modelo que exige mais cuidado, por um motivo que o Google explica de forma direta em sua própria documentação: a delegação não permite restringir qual usuário específico será impersonado. Ela autoriza a impersonação de qualquer pessoa na organização, inclusive superadministradores, o que torna essa conta de serviço um alvo prioritário para a escalada de privilégios. A recomendação oficial é evitá-la sempre que o caso de uso puder ser resolvido com uma conta de serviço direta ou com consentimento OAuth .
Três detalhes operacionais que é importante saber antes de assumir um cronograma:
- A ativação é feita por um superadministrador no console de administração do Workspace, não na equipe de desenvolvimento.
- Se a organização tem a aprovação multipartes uma vez ativada, a autorização de uma nova integração exige a confirmação de um segundo superadministrador. Isso significa dias, e não minutos, quando entram em jogo férias ou agendas.
- Não funciona em contas pessoais do Gmail , apenas em domínios do Google Workspace.
| Modelo | Quando é a opção correta | O que vai te bloquear |
|---|---|---|
| Conta de serviço direta | A integração precisa apenas de recursos que podem ser compartilhados explicitamente com ela. | Não acessa caixas de correio nem o Drive pessoal dos usuários. |
| Consentimento OAuth | O usuário final interage com a integração e deve poder revogá-la. | É necessária uma pessoa para autorizar. |
| Delegação de domínio | Processos autônomos que abrangem toda a organização. | Superadministrador, possível dupla aprovação e uma superfície de risco que precisa ser governada. |
Esta integração precisa acessar dados de pessoas que não vão autorizá-la uma a uma? Se a resposta for não, não use delegação de domínio. Se for
Uma
Uma integração com delegação de domínio pode ler os e-mails de toda a empresa. Se não houver registro do que foi feito, quando e sobre quais dados, não há como responder a uma auditoria, a uma consulta de um funcionário ou a um incidente de segurança. O registro de operações não é uma melhoria acrescentada posteriormente: é parte do projeto.
Estes três erros são, no fundo, erros de governança de dados, e não de programação. Se você está revisando a postura de segurança de todo o seu ambiente, o ponto de partida é o nosso guia sobre Segurança na nuvem e conformidade com o RGPD com Google Cloud.
Quanto tempo leva de verdade
Não existe uma resposta única, mas sim faixas realistas:
| Tipo de projeto | Prazo razoável |
|---|---|
| Automação interna no Apps Script | Dias |
| Integração de um fluxo com um sistema externo | De duas a seis semanas |
| Plataforma que conecta vários sistemas com lógica de negócio própria | Meses |
O que altera o prazo Quase nunca é o código.Trata-se da qualidade da API do sistema do outro lado, da necessidade de delegação de domínio e das aprovações que isso envolve, do processo de verificação caso a integração seja externa e da velocidade com que sua organização toma decisões sobre permissões e segurança.
Qualquer fornecedor que lhe dê um prazo firme sem ter perguntado sobre esses quatro fatores não entendeu o projeto.
Como abordamos isso na The Cloud Collective
Como Google Cloud Premier Partner em Barcelona, trabalhamos nessas integrações começando pelo final: qual processo de negócio precisa funcionar e quais dados são necessários para isso. A partir daí, definimos o modelo de identidade com a permissão mínima necessária, Evitamos a delegação de domínio quando o caso de uso permite uma alternativa mais segura., e deixamos documentado o modelo de permissões para que sua equipe possa auditar sem depender de nós.
Em seguida, acompanhamos a entrada em produção no Google Cloud , com as integrações com Gmail , Drive, Calendar e Admin SDK que o projeto exigir, e o registro de operações necessário para conformidade. Se você ainda está avaliando a plataforma antes da integração, comece pela nossa página de Google Workspace para empresas.
Perguntas frequentes
O uso das APIs é gratuito dentro das cotas padrão. Ultrapassá-las pode resultar em limitações temporárias nas solicitações, mas não gera cobrança direta. Dois pontos importantes: algumas APIs estão disponíveis apenas em determinadas edições do Workspace, e o custo real de uma integração reside na infraestrutura onde ela é executada e no desenvolvimento, não nas chamadas à API .
Para uma automação simples com Apps Script, não: um perfil técnico com conhecimentos de Workspace é suficiente. Para uma integração em produção, no entanto, são necessários conhecimentos de Google Cloud , pois as decisões sobre identidade, permissões e implantação são tomadas nessa plataforma e determinam se a integração será segura e sustentável.
Quase sempre. A restrição raramente está do lado do Google — que disponibiliza APIs REST padrão que podem ser consumidas a partir de qualquer linguagem —, mas sim nas capacidades de integração do outro sistema. Esse é o primeiro ponto a ser avaliado em qualquer projeto desse tipo.
Depende do modelo de identidade escolhido, e essa é uma das razões pelas quais essa decisão é tão importante. Com o consentimento OAuth individual, o acesso é perdido quando a conta é encerrada. Com uma conta de serviço, a integração continua funcionando independentemente da equipe. Vale a pena definir isso durante a fase de projeto, e não no momento em que o problema ocorre.
Escolha um único processo — o mais incômodo e repetitivo que você tiver — e integre-o do início ao fim. Um caso real em produção ensina mais sobre suas próprias restrições internas do que três meses de análise, além de deixar uma base para escalar.
Conclusão
As APIs do Google Workspace são robustas e bem documentadas: A tecnologia raramente é o gargalo.O que determina o sucesso de um projeto de integração é ter respondido rapidamente a quatro perguntas: em nome de quem a integração atua, se ela precisa de infraestrutura própria, se vai sair da sua organização e qual o grau de atualidade necessário para os dados.
Responda a elas antes de escrever código e o projeto se torna um problema de execução. Responda a elas com atraso e isso se torna um problema de arquitetura.
Você está avaliando uma integração com Google Workspace ?
Na The Cloud Collective podemos ajudar você a definir o modelo de permissões e a arquitetura antes de sua equipe começar a desenvolver. Diagnóstico inicial sem compromisso, com foco no processo de negócio e não na tecnologia.
Falar com um partner certificado
