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 Marketplace, або внутрішньому GCP Service Account, отримувати доступ до даних у Workspace від імені користувачів. Ця функція, яка є критично важливою для додатків, що взаємодіють з Google APIs або сервісами, які потребують імперсонації користувача, підвищує ефективність і мінімізує людські помилки шляхом автоматизації завдань. Використовуючи OAuth 2.0, розробники додатків і адміністратори можуть надати цим обліковим записам сервісу доступ до даних користувачів без індивідуальної згоди користувачів. Google Workspace дозволяє створення двох основних типів глобальних делегованих об'єктів ідентичності:
GWS Applications: Додатки з Marketplace Workspace можуть бути налаштовані як делегована ідентичність. Перед тим, як стати доступними в маркетплейсі, кожен додаток Workspace проходить перевірку Google, щоб мінімізувати потенційне зловживання. Хоча це не усуває ризик зловживання повністю, це значно ускладнює можливість таких інцидентів.
GCP Service Account: Дізнайтеся більше про GCP Service Accounts тут.
Делегування на рівні домену: Під капотом
Ось як GCP Service Account може отримати доступ до Google APIs від імені інших ідентичностей у Google Workspace:
Ідентичність створює JWT: Ідентичність використовує приватний ключ облікового запису сервісу (частина файлу пари ключів JSON) для підписання JWT. Цей JWT містить заяви про обліковий запис сервісу, цільового користувача для імперсонації та OAuth області доступу до REST API, до якого запитується доступ.
Ідентичність використовує JWT для запиту токена доступу: Додаток/користувач використовує JWT для запиту токена доступу від сервісу OAuth 2.0 Google. Запит також включає цільового користувача для імперсонації (електронну пошту користувача Workspace) та області, для яких запитується доступ.
Сервіс OAuth 2.0 Google повертає токен доступу: Токен доступу представляє авторитет облікового запису сервісу діяти від імені користувача для зазначених областей. Цей токен зазвичай має короткий термін дії і повинен періодично оновлюватися (згідно з потребами додатка). Важливо розуміти, що області OAuth, зазначені в токені JWT, мають дійсність і впливають на результуючий токен доступу. Наприклад, токени доступу, що мають кілька областей, будуть дійсні для численних REST API додатків.
Ідентичність використовує токен доступу для виклику Google APIs: Тепер з відповідним токеном доступу сервіс може отримати доступ до необхідного REST API. Додаток використовує цей токен доступу в заголовку "Authorization" своїх HTTP запитів, призначених для Google APIs. Ці API використовують токен для перевірки імперсованої ідентичності та підтвердження, що вона має необхідну авторизацію.
Google APIs повертають запитувані дані: Якщо токен доступу дійсний і обліковий запис сервісу має відповідну авторизацію, Google APIs повертають запитувані дані. Наприклад, на наступному зображенні ми використали метод users.messages.list для переліку всіх ідентифікаторів повідомлень Gmail, пов'язаних з цільовим користувачем Workspace.
Last updated
