Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - KMS Enum

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

KMS - Служба управління ключами

Служба управління ключами Amazon Web Services (AWS KMS) представлена як керована служба, спрощуючи процес для користувачів у створенні та управлінні ключами основних клієнтів (CMK). Ці CMK є невід'ємними в шифруванні даних користувача. Важливою особливістю AWS KMS є те, що CMK в основному захищені апаратними модулями безпеки (HSM), підвищуючи захист ключів шифрування.

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

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

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

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

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

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

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

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

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

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

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

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

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

На відміну від інших політик ресурсів AWS, політика ключа 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. Вам потрібно створити їх за допомогою API AWS KMS. Можна вказати ідентифікатор CMK, принципал отримувача та необхідний рівень операції (Decrypt, Encrypt, GenerateDataKey...)

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

Доступ:

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

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

  • Через дозволи

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

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

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

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

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

Ротація CMKs

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

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

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

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

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

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

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

  • Для спрощення цього процесу ви можете використовувати псевдоніми для посилання на ідентифікатор ключа і потім просто оновити ключ, на який посилається псевдонім.

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

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

Інша важлива інформація про 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

Підвищення привілеїв

pageAWS - KMS Privesc

Післяексплуатаційна діяльність

pageAWS - KMS Post Exploitation

Наполегливість

pageAWS - KMS Persistence

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousAWS - IAM EnumNextAWS - Lambda Enum

Last updated