GCP - Розуміння делегування на рівні домену

Reading time: 4 minutes

Ця публікація є вступом до 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, отримувати доступ до даних у Workspace від імені користувачів. Ця функція, яка є критично важливою для додатків, що взаємодіють з Google API або службами, які потребують імперсонації користувача, підвищує ефективність і мінімізує людські помилки шляхом автоматизації завдань. Використовуючи OAuth 2.0, розробники додатків і адміністратори можуть надати цим обліковим записам служби доступ до даних користувачів без індивідуальної згоди користувачів.

Google Workspace дозволяє створення двох основних типів глобальних делегованих об'єктів ідентичності:

• GWS Додатки: Додатки з Marketplace Workspace можуть бути налаштовані як делегована ідентичність. Перед тим, як стати доступними в маркетплейсі, кожен додаток Workspace проходить перевірку Google для мінімізації потенційного зловживання. Хоча це не усуває ризик зловживання, це значно ускладнює можливість таких інцидентів.
• Обліковий запис служби GCP: Дізнайтеся більше про облікові записи служби GCP тут.

Делегування на рівні домену: Під капотом

Ось як обліковий запис служби GCP може отримати доступ до Google API від імені інших ідентичностей у Google Workspace:

1. Ідентичність створює JWT: Ідентичність використовує приватний ключ облікового запису служби (частина файлу пари ключів JSON) для підписання JWT. Цей JWT містить заяви про обліковий запис служби, цільового користувача для імперсонації та OAuth області доступу до REST API, до якого запитується доступ.
2. Ідентичність використовує JWT для запиту токена доступу: Додаток/користувач використовує JWT для запиту токена доступу з сервісу OAuth 2.0 Google. Запит також включає цільового користувача для імперсонації (електронна пошта користувача Workspace) та області, для яких запитується доступ.
3. Сервіс OAuth 2.0 Google повертає токен доступу: Токен доступу представляє авторитет облікового запису служби діяти від імені користувача для зазначених областей. Цей токен зазвичай має короткий термін дії і повинен періодично оновлюватися (згідно з потребами додатка). Важливо розуміти, що області OAuth, зазначені в токені JWT, мають дійсність і впливають на результуючий токен доступу. Наприклад, токени доступу, що мають кілька областей, будуть дійсними для численних REST API додатків.
4. Ідентичність використовує токен доступу для виклику Google API: Тепер з відповідним токеном доступу служба може отримати доступ до необхідного REST API. Додаток використовує цей токен доступу в заголовку "Authorization" своїх HTTP запитів, призначених для Google API. Ці API використовують токен для перевірки імперсованої ідентичності та підтвердження, що вона має необхідну авторизацію.
5. Google API повертають запитувані дані: Якщо токен доступу дійсний і обліковий запис служби має відповідну авторизацію, Google API повертають запитувані дані. Наприклад, на наступному зображенні ми використали метод users.messages.list для переліку всіх ідентифікаторів повідомлень Gmail, пов'язаних з цільовим користувачем Workspace.