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, gdzie można uzyskać więcej szczegółów.
Zrozumienie Delegacji na Poziomie Domeny
Delegacja na poziomie domeny w Google Workspace pozwala obiektowi tożsamości, czy to zewnętrznej aplikacji z Google Workspace Marketplace, czy wewnętrznemu Kontu Usługi GCP, na dostęp do danych w całym Workspace w imieniu użytkowników. Ta funkcja, kluczowa dla aplikacji współpracujących z interfejsami API Google lub usług potrzebujących podrobienia użytkownika, zwiększa efektywność i minimalizuje błędy ludzkie poprzez automatyzację zadań. Korzystając z OAuth 2.0, deweloperzy aplikacji i administratorzy mogą nadać tym kontom usług dostęp do danych użytkownika bez indywidualnej zgody użytkownika. Google Workspace pozwala na utworzenie dwóch głównych typów globalnych zdelegowanych obiektów tożsamości:
Aplikacje GWS: Aplikacje z Workspace Marketplace mogą być skonfigurowane jako zdelegowana tożsamość. Przed udostępnieniem ich na rynku, każda aplikacja Workspace przechodzi recenzję przez Google w celu zminimalizowania potencjalnego nadużycia. Choć nie eliminuje to całkowicie ryzyka nadużycia, znacznie zwiększa trudność wystąpienia takich incydentów.
Konto Usługi GCP: Dowiedz się więcej o Kontach Usług GCP tutaj.
Delegacja na Poziomie Domeny: Pod Maską
Tak Konta Usługi GCP mogą 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 twierdzenia dotyczące konta usługi, docelowego użytkownika do podrobienia oraz zakresów OAuth dostępu do interfejsu API REST, który jest żądany.
Tożsamość używa JWT do żądania tokena dostępu: Aplikacja/użytkownik używa JWT do żądania tokenu dostępu od usługi OAuth 2.0 Google. Żądanie zawiera również docelowego użytkownika do podrobienia (adres e-mail użytkownika Workspace) oraz zakresy, dla których jest żądany 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. Token ten jest zazwyczaj krótkotrwały i musi być odświeżany okresowo (zgodnie z potrzebą aplikacji). Istotne jest zrozumienie, ż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ą ważne dla licznych aplikacji interfejsu API REST.
Tożsamość używa tokenu dostępu do wywołania interfejsów API Google: Teraz, posiadając odpowiedni token dostępu, usługa może uzyskać dostęp do wymaganego interfejsu API REST. Aplikacja używa tego tokenu dostępu w nagłówku "Autoryzacja" swoich żądań HTTP kierowanych do interfejsów API Google. Te interfejsy wykorzystują token do weryfikacji podrobionej tożsamości i potwierdzenia, że ma ona niezbędną autoryzację.
Interfejsy API Google zwracają żądane dane: Jeśli token dostępu jest ważny, a konto usługi ma odpowiednią autoryzację, 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 powiązanych z docelowym użytkownikiem Workspace.
Last updated
