Ukranian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - KMS Enum

Support HackTricks

KMS - Key Management Service

AWS Key Management Service (AWS KMS) представлений як керована служба, що спрощує процес для користувачів створювати та керувати основними ключами клієнтів (CMK). Ці CMK є невід'ємною частиною шифрування даних користувачів. Помітною особливістю AWS KMS є те, що CMK переважно захищені апаратними модулями безпеки (HSM), що підвищує захист шифрувальних ключів.

KMS використовує симетричну криптографію. Це використовується для шифрування інформації в спокої (наприклад, всередині S3). Якщо вам потрібно шифрувати інформацію в процесі передачі, вам потрібно використовувати щось на зразок TLS.

KMS є сервісом, специфічним для регіону.

Адміністратори Amazon не мають доступу до ваших ключів. Вони не можуть відновити ваші ключі і не допомагають вам з шифруванням ваших ключів. AWS просто адмініструє операційну систему та основний додаток, нам потрібно адмініструвати наші шифрувальні ключі та контролювати, як ці ключі використовуються.

Основні ключі клієнтів (CMK): Можуть шифрувати дані розміром до 4KB. Вони зазвичай використовуються для створення, шифрування та дешифрування DEK (ключів шифрування даних). Потім DEK використовуються для шифрування даних.

Основний ключ клієнта (CMK) є логічним представленням основного ключа в AWS KMS. На додаток до ідентифікаторів основного ключа та іншої метаданих, включаючи дату створення, опис та стан ключа, CMK містить матеріал ключа, який використовується для шифрування та дешифрування даних. Коли ви створюєте CMK, за замовчуванням AWS KMS генерує матеріал ключа для цього CMK. Однак ви можете вибрати створити CMK без матеріалу ключа, а потім імпортувати свій власний матеріал ключа в цей CMK.

Існує 2 типи основних ключів:

  • CMK, керовані AWS: Використовуються іншими службами для шифрування даних. Вони використовуються службою, яка їх створила в регіоні. Вони створюються перший раз, коли ви реалізуєте шифрування в цій службі. Обертаються кожні 3 роки, і їх неможливо змінити.

  • CMK, керовані клієнтом: Гнучкість, ротація, налаштовуваний доступ і політика ключів. Увімкнення та вимкнення ключів.

Шифрування конвертів в контексті служби управління ключами (KMS): Система з двох рівнів для шифрування даних за допомогою ключа даних, а потім шифрування ключа даних за допомогою основного ключа.

Політики ключів

Ці політики визначають хто може використовувати та отримувати доступ до ключа в KMS.

За замовчуванням:

  • Вона надає обліковому запису AWS, який володіє ключем KMS, повний доступ до ключа KMS.

На відміну від інших політик ресурсів AWS, політика ключа KMS не надає автоматично дозволу обліковому запису або будь-якому з його користувачів. Щоб надати дозвіл адміністраторам облікового запису, політика ключа повинна містити явну заяву, яка надає цей дозвіл, як ця.

  • Без дозволу облікового запису("AWS": "arn:aws:iam::111122223333:root") дозволи IAM не працюватимуть.

  • Вона дозволяє обліковому запису використовувати політики IAM для надання доступу до ключа KMS, на додаток до політики ключа.

Без цього дозволу політики IAM, які дозволяють доступ до ключа, є неефективними, хоча політики IAM, які забороняють доступ до ключа, все ще є ефективними.

  • Вона зменшує ризик того, що ключ стане некерованим, надаючи права доступу адміністраторам облікового запису, включаючи кореневого користувача облікового запису, який не може бути видалений.

Приклад політики за замовчуванням:

{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}

Якщо обліковий запис дозволено ("arn:aws:iam::111122223333:root"), суб'єкт з облікового запису все ще потребує IAM дозволів для використання KMS ключа. Однак, якщо ARN ролі, наприклад, спеціально дозволено в Політиці ключа, ця роль не потребує IAM дозволів.

Деталі політики

Властивості політики:

  • Документ на основі JSON

  • Ресурс --> Підлягаючі ресурси (може бути "*")

  • Дія --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (дозволи)

  • Ефект --> Дозволити/Відмовити

  • Суб'єкт --> arn, що підлягає

  • Умови (необов'язково) --> Умова для надання дозволів

Гранти:

  • Дозволяє делегувати ваші дозволи іншому AWS суб'єкту у вашому обліковому записі AWS. Вам потрібно створити їх за допомогою AWS KMS API. Можна вказати ідентифікатор CMK, суб'єкт гранту та необхідний рівень операції (Decrypt, Encrypt, GenerateDataKey...)

  • Після створення гранту видаються GrantToken та GrantID

Доступ:

  • Через політику ключа -- Якщо це існує, це має пріоритет над політикою IAM

  • Через політику IAM

  • Через гранти

Адміністратори ключів

Адміністратори ключів за замовчуванням:

  • Мають доступ для управління KMS, але не для шифрування або дешифрування даних

  • Тільки користувачі та ролі IAM можуть бути додані до списку адміністраторів ключів (не групи)

  • Якщо використовується зовнішній CMK, адміністратори ключів мають дозвіл на імпорт матеріалів ключа

Ротація CMK

  • Чим довше той самий ключ залишається на місці, тим більше даних шифрується цим ключем, і якщо цей ключ буде зламано, то ширша зона ризику даних. Крім того, чим довше ключ активний, тим більше ймовірність його зламу.

  • KMS ротує ключі клієнтів кожні 365 днів (або ви можете виконати процес вручну, коли захочете) і ключі, що управляються AWS, кожні 3 роки, і цього разу змінити не можна.

  • Старі ключі зберігаються для дешифрування даних, які були зашифровані до ротації

  • У разі зламу, ротація ключа не усуне загрозу, оскільки буде можливість дешифрувати всі дані, зашифровані зламаним ключем. Однак, нові дані будуть зашифровані новим ключем.

  • Якщо CMK знаходиться в стані вимкнено або в очікуванні видалення, KMS не буде виконувати ротацію ключа, поки CMK не буде повторно активовано або видалення не буде скасовано.

Ручна ротація

  • Потрібно створити новий CMK, потім створюється новий CMK-ID, тому вам потрібно буде оновити будь-яку застосунок, щоб посилатися на новий CMK-ID.

  • Щоб спростити цей процес, ви можете використовувати псевдоніми для посилання на key-id і потім просто оновити ключ, на який посилається псевдонім.

  • Вам потрібно зберігати старі ключі для дешифрування старих файлів, зашифрованих з їх допомогою.

Ви можете імпортувати ключі з вашої локальної інфраструктури ключів.

Інша релевантна інформація KMS

KMS оцінюється за кількістю запитів на шифрування/дешифрування, отриманих від усіх служб за місяць.

KMS має повну аудиторську та комплаєнс інтеграцію з CloudTrail; тут ви можете перевірити всі зміни, виконані в KMS.

З політикою KMS ви можете зробити наступне:

  • Обмежити, хто може створювати ключі даних і які служби мають доступ до використання цих ключів

  • Обмежити доступ систем до шифрування лише, дешифрування лише або обидва

  • Визначити, щоб системи могли отримувати доступ до ключів через регіони (хоча це не рекомендується, оскільки збій у регіоні, де розміщено KMS, вплине на доступність систем в інших регіонах).

Ви не можете синхронізувати або переміщати/копіювати ключі між регіонами; ви можете лише визначити правила для дозволу доступу між регіонами.

Перерахування

aws kms list-keys
aws kms list-key-policies --key-id <id>
aws kms list-grants --key-id <id>
aws kms describe-key --key-id <id>
aws kms get-key-policy --key-id <id> --policy-name <name> # Default policy name is "default"
aws kms describe-custom-key-stores

Privesc

Post Exploitation

Persistence

References

Підтримайте HackTricks
PreviousAWS - IAM, Identity Center & SSO EnumNextAWS - Lambda Enum

Last updated