GCP - Understanding Domain-Wide Delegation
Цей пост є вступом до https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover, де можна знайти більше деталей.
Розуміння Делегування на Рівні Домену
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, будь то зовнішній додаток з Маркетплейсу Google Workspace або внутрішній Службовий обліковий запис GCP, отримувати доступ до даних по всьому Workspace від імені користувачів. Ця функція, яка є важливою для додатків, що взаємодіють з API Google або послугами, які потребують підроблення користувача, підвищує ефективність та мінімізує людські помилки шляхом автоматизації завдань. За допомогою OAuth 2.0 розробники додатків та адміністратори можуть надавати цим службовим обліковим записам доступ до даних користувачів без окремої згоди користувача. Google Workspace дозволяє створювати два основних типи глобальних делегованих об'єктів ідентичності:
Додатки GWS: Додатки з Маркетплейсу Workspace можуть бути налаштовані як делегована ідентичність. Перш ніж стати доступними на ринку, кожне додаток Workspace проходить перевірку від Google для мінімізації можливого зловживання. Хоча це не повністю усуває ризик зловживання, це значно ускладнює можливість виникнення таких випадків.
Службовий обліковий запис GCP: Дізнайтеся більше про Службові облікові записи GCP тут.
Делегування на Рівні Домену: Під Капотом
Ось як Службовий обліковий запис GCP може отримати доступ до API Google від імені інших ідентичностей в Google Workspace:
Ідентичність створює JWT: Ідентичність використовує приватний ключ службового облікового запису (частина файлу пари ключів JSON) для підпису JWT. Цей JWT містить вимоги щодо службового облікового запису, цільового користувача для підроблення та області OAuth доступу до REST API, яке запитується.
Ідентичність використовує JWT для запиту токена доступу: Додаток/користувач використовує JWT для запиту токена доступу від служби OAuth 2.0 Google. Запит також включає цільового користувача для підроблення (електронна пошта користувача Workspace) та області, для яких запитується доступ.
Служба OAuth 2.0 Google повертає токен доступу: Токен доступу представляє повноваження службового облікового запису діяти від імені користувача для вказаних областей. Цей токен зазвичай має обмежений термін дії і повинен періодично оновлюватися (згідно з потребами додатка). Важливо розуміти, що області OAuth, вказані в токені JWT, мають валідність та вплив на отриманий токен доступу. Наприклад, токени доступу з декількома областями будуть мати валідність для численних додатків REST API.
Ідентичність використовує токен доступу для виклику API Google: Тепер з відповідним токеном доступу служба може отримати доступ до необхідного REST API. Додаток використовує цей токен доступу в заголовку "Authorization" своїх HTTP-запитів, призначених для API Google. Ці API використовують токен для перевірки підробленої ідентичності та підтвердження наявності необхідного дозволу.
API Google повертають запитані дані: Якщо токен доступу є валідним, а службовий обліковий запис має відповідний дозвіл, API Google повертають запитані дані. Наприклад, на наступному зображенні ми скористалися методом users.messages.list для переліку всіх ідентифікаторів повідомлень Gmail, пов'язаних з користувачем цільового Workspace.
Last updated
