Translated ['src/pentesting-cloud/workspace-security/gws-workspace-sync-

2026-07-29 07:00:29 -07:00 · 2025-05-20 06:05:08 +00:00
parent c6e9d3cbf7
commit 0d7a1ffca6
1 changed files with 6 additions and 6 deletions
@@ -4,11 +4,11 @@

 ## Основна інформація

-Головна різниця між цим способом синхронізації користувачів з GCDS полягає в тому, що GCDS виконується вручну з деякими бінарними файлами, які потрібно завантажити та запустити, тоді як **Admin Directory Sync є безсерверним** і керується Google на [https://admin.google.com/ac/sync/externaldirectories](https://admin.google.com/ac/sync/externaldirectories).
+Головна різниця між цим способом синхронізації користувачів з GCDS полягає в тому, що GCDS виконується вручну з деякими бінарними файлами, які потрібно завантажити та запустити, тоді як **Admin Directory Sync є безсерверним** і керується Google в [https://admin.google.com/ac/sync/externaldirectories](https://admin.google.com/ac/sync/externaldirectories).

 На момент написання цього матеріалу ця служба знаходиться в бета-версії і підтримує 2 типи синхронізації: з **Active Directory** та з **Azure Entra ID:**

- **Active Directory:** Щоб налаштувати це, вам потрібно надати **доступ Google до вашого середовища Active Directory**. Оскільки Google має доступ лише до мереж GCP (через **VPC connectors**), вам потрібно створити конектор, а потім зробити ваш AD доступним з цього конектора, розмістивши його на ВМ у мережі GCP або використовуючи Cloud VPN або Cloud Interconnect. Потім вам також потрібно надати **облікові дані** облікового запису з правами читання на директорію та **сертифікат** для зв'язку через **LDAPS**.
+- **Active Directory:** Щоб налаштувати це, вам потрібно надати **доступ Google до вашого середовища Active Directory**. Оскільки Google має доступ лише до мереж GCP (через **VPC connectors**), вам потрібно створити конектор, а потім зробити ваш AD доступним з цього конектора, розмістивши його на ВМ у мережі GCP або використовуючи Cloud VPN або Cloud Interconnect. Потім вам також потрібно надати **облікові дані** облікового запису з правами читання на каталог та **сертифікат** для зв'язку через **LDAPS**.
 - **Azure Entra ID:** Для налаштування цього потрібно просто **увійти в Azure з користувачем з правами читання** на підписку Entra ID у спливаючому вікні, яке відобразить Google, і Google зберігатиме токен з правами читання на Entra ID.

 Після правильного налаштування обидва варіанти дозволять **синхронізувати користувачів та групи з Workspace**, але не дозволять налаштовувати користувачів та групи з Workspace до AD або EntraID.
@@ -27,7 +27,7 @@

 #### Атака на користувачів

-Коли відбувається синхронізація, можуть синхронізуватися **всі користувачі з AD або лише ті, що з конкретного OU**, або лише **користувачі, які є членами конкретних груп в EntraID**. Це означає, що для атаки на синхронізованого користувача (або створення нового, який буде синхронізований) вам спочатку потрібно з'ясувати, які користувачі синхронізуються.
+Коли відбувається синхронізація, можуть бути синхронізовані **всі користувачі з AD або лише ті, що з конкретного OU** або лише **користувачі, які є членами конкретних груп в EntraID**. Це означає, що для атаки на синхронізованого користувача (або створення нового, який буде синхронізований) вам спочатку потрібно з'ясувати, які користувачі синхронізуються.

 - Користувачі можуть **повторно використовувати пароль або ні з AD або EntraID**, але це означає, що вам потрібно **скомпрометувати паролі користувачів для входу**.
 - Якщо у вас є доступ до **електронних листів** користувачів, ви можете **змінити пароль Workspace існуючого користувача**, або **створити нового користувача**, почекати, поки він буде синхронізований, і налаштувати обліковий запис.
@@ -43,15 +43,15 @@

 Якщо ви знаєте, які групи з Azure мають **призначені дозволи в Workspace або GCP**, ви можете просто додати скомпрометованого користувача (або новоствореного) до цієї групи та отримати ці дозволи.

-Є ще один варіант зловживання існуючими привілейованими групами в Workspace. Наприклад, група `gcp-organization-admins@<workspace.email>` зазвичай має високі привілеї над GCP.
+Існує ще один варіант зловживання існуючими привілейованими групами в Workspace. Наприклад, група `gcp-organization-admins@<workspace.email>` зазвичай має високі привілеї над GCP.

 Якщо синхронізація, наприклад, з EntraID до Workspace **налаштована на заміну домену** імпортованого об'єкта **електронною адресою Workspace**, зловмисник зможе створити групу `gcp-organization-admins@<entraid.email>` в EntraID, додати користувача до цієї групи та почекати, поки відбудеться синхронізація всіх груп.\
-**Користувач буде доданий до групи `gcp-organization-admins@<workspace.email>`, підвищуючи привілеї в GCP.**
+**Користувач буде доданий до групи `gcp-organization-admins@<workspace.email>`, що призведе до ескалації привілеїв у GCP.**

 ### З Google Workspace -> AD/EntraID

 Зверніть увагу, що Workspace вимагає облікові дані з правами лише на читання для синхронізації користувачів та груп з AD або EntraID. Тому неможливо зловживати Google Workspace для внесення будь-яких змін в AD або EntraID. Отже, **це неможливо** на даний момент.

-Я також не знаю, де Google зберігає облікові дані AD або токен EntraID, і ви **не можете відновити їх, переналаштувавши синхронізацію** (вони не з'являються у веб-формі, вам потрібно ввести їх знову). Однак з веб-інтерфейсу може бути можливим зловживати поточною функціональністю для **перегляду користувачів та груп**.
+Я також не знаю, де Google зберігає облікові дані AD або токен EntraID, і ви **не можете відновити їх, переналаштувавши синхронізацію** (вони не з'являються у веб-формі, вам потрібно ввести їх знову). Однак з вебу може бути можливим зловживати поточною функціональністю для **перегляду користувачів та груп**.

 {{#include ../../../banners/hacktricks-training.md}}