GCP - Understanding Domain-Wide Delegation
Este post é a introdução de https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover que pode ser acessado para mais detalhes.
Compreendendo a Delegação em Toda a Organização
A delegação em toda a organização do Google Workspace permite que um objeto de identidade, seja um aplicativo externo do Google Workspace Marketplace ou uma Conta de Serviço GCP interna, acessar dados em toda a Workspace em nome dos usuários. Este recurso, que é crucial para aplicativos que interagem com APIs do Google ou serviços que precisam de impersonificação de usuário, melhora a eficiência e minimiza erros humanos automatizando tarefas. Usando OAuth 2.0, desenvolvedores de aplicativos e administradores podem dar a essas contas de serviço acesso aos dados do usuário sem o consentimento individual do usuário. O Google Workspace permite a criação de dois principais tipos de identidades de objeto delegadas globais:
Aplicativos GWS: Aplicativos do Workspace Marketplace podem ser configurados como uma identidade delegada. Antes de serem disponibilizados no marketplace, cada aplicativo do Workspace passa por uma revisão do Google para minimizar possíveis abusos. Embora isso não elimine totalmente o risco de abuso, aumenta significativamente a dificuldade para tais incidentes ocorrerem.
Conta de Serviço GCP: Saiba mais sobre Contas de Serviço GCP aqui.
Delegação em Toda a Organização: Por Dentro
Assim é como uma Conta de Serviço GCP pode acessar APIs do Google em nome de outras identidades no Google Workspace:
Identidade cria um JWT: A Identidade usa a chave privada da conta de serviço (parte do arquivo de par de chaves JSON) para assinar um JWT. Este JWT contém reivindicações sobre a conta de serviço, o usuário alvo para impersonificar e os escopos OAuth de acesso à API REST que está sendo solicitada.
A Identidade usa o JWT para solicitar um token de acesso: O aplicativo/usuário usa o JWT para solicitar um token de acesso do serviço OAuth 2.0 do Google. A solicitação também inclui o usuário alvo para impersonificar (o e-mail do usuário do Workspace) e os escopos para os quais o acesso é solicitado.
O serviço OAuth 2.0 do Google retorna um token de acesso: O token de acesso representa a autoridade da conta de serviço para agir em nome do usuário para os escopos especificados. Este token é tipicamente de curta duração e deve ser atualizado periodicamente (conforme a necessidade do aplicativo). É essencial entender que os escopos OAuth especificados no token JWT têm validade e impacto no token de acesso resultante. Por exemplo, tokens de acesso possuindo vários escopos terão validade para numerosas aplicações de API REST.
A Identidade usa o token de acesso para chamar APIs do Google: Agora, com um token de acesso relevante, o serviço pode acessar a API REST necessária. O aplicativo usa este token de acesso no cabeçalho "Autorização" de suas solicitações HTTP destinadas às APIs do Google. Estas APIs utilizam o token para verificar a identidade impersonificada e confirmar que ela tem a autorização necessária.
As APIs do Google retornam os dados solicitados: Se o token de acesso for válido e a conta de serviço tiver a autorização apropriada, as APIs do Google retornam os dados solicitados. Por exemplo, na imagem a seguir, aproveitamos o método users.messages.list para listar todos os IDs de mensagens do Gmail associados a um usuário alvo do Workspace.
Última actualización
