GCP - Understanding Domain-Wide Delegation
Ten post jest wprowadzeniem do https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover, które można znaleźć w celu uzyskania dalszych szczegółów.
Zrozumienie delegacji na poziomie domeny
Delegacja na poziomie domeny Google Workspace pozwala obiektowi tożsamości, czy to zewnętrznej aplikacji z Google Workspace Marketplace, czy wewnętrznemu Konto usługi GCP, na uzyskiwanie dostępu do danych w całym Workspace w imieniu użytkowników. Ta funkcja, która jest kluczowa dla aplikacji współdziałających z interfejsami API Google lub usługami wymagającymi podszywania się pod użytkowników, zwiększa efektywność i minimalizuje błędy ludzkie poprzez automatyzację zadań. Używając OAuth 2.0, deweloperzy aplikacji i administratorzy mogą dać tym kontom usługowym dostęp do danych użytkowników bez indywidualnej zgody użytkowników. Google Workspace pozwala na tworzenie dwóch głównych typów globalnych tożsamości obiektów delegowanych:
Aplikacje GWS: Aplikacje z Marketplace Workspace mogą być skonfigurowane jako delegowana tożsamość. Zanim zostaną udostępnione w marketplace, każda aplikacja Workspace przechodzi przegląd przez Google, aby zminimalizować potencjalne nadużycia. Chociaż nie eliminuje to całkowicie ryzyka nadużyć, znacznie zwiększa trudność wystąpienia takich incydentów.
Konto usługi GCP: Dowiedz się więcej o Konta usługi GCP tutaj.
Delegacja na poziomie domeny: Jak to działa
Oto jak Konto usługi GCP może uzyskać dostęp do interfejsów API Google w imieniu innych tożsamości w Google Workspace:
Tożsamość tworzy JWT: Tożsamość używa prywatnego klucza konta usługi (część pliku pary kluczy JSON) do podpisania JWT. Ten JWT zawiera roszczenia dotyczące konta usługi, docelowego użytkownika, którego należy podszyć się, oraz zakresy OAuth dostępu do żądanego interfejsu API REST.
Tożsamość używa JWT do żądania tokena dostępu: Aplikacja/użytkownik używa JWT do żądania tokena dostępu z usługi OAuth 2.0 Google. Żądanie zawiera również docelowego użytkownika, którego należy podszyć się (adres e-mail użytkownika Workspace), oraz zakresy, dla których żądany jest dostęp.
Usługa OAuth 2.0 Google zwraca token dostępu: Token dostępu reprezentuje uprawnienia konta usługi do działania w imieniu użytkownika dla określonych zakresów. Ten token jest zazwyczaj krótkoterminowy i musi być okresowo odnawiany (zgodnie z potrzebami aplikacji). Ważne jest, aby zrozumieć, że zakresy OAuth określone w tokenie JWT mają ważność i wpływ na wynikowy token dostępu. Na przykład, tokeny dostępu posiadające wiele zakresów będą miały ważność dla wielu aplikacji interfejsu API REST.
Tożsamość używa tokena dostępu do wywołania interfejsów API Google: Teraz z odpowiednim tokenem dostępu, usługa może uzyskać dostęp do wymaganego interfejsu API REST. Aplikacja używa tego tokena dostępu w nagłówku "Authorization" swoich żądań HTTP kierowanych do interfejsów API Google. Te interfejsy API wykorzystują token do weryfikacji podszywanej tożsamości i potwierdzenia, że ma ona odpowiednie uprawnienia.
Interfejsy API Google zwracają żądane dane: Jeśli token dostępu jest ważny, a konto usługi ma odpowiednie uprawnienia, interfejsy API Google zwracają żądane dane. Na przykład, na poniższym obrazku wykorzystaliśmy metodę users.messages.list do wylistowania wszystkich identyfikatorów wiadomości Gmail związanych z docelowym użytkownikiem Workspace.
Last updated
