Розуміння ролей IAM в AWS: AssumeRole та призначення ролей

AWS Identity and Access Management (IAM) є основою безпеки в AWS, дозволяючи вам контролювати доступ до ресурсів безпечно. Серед багатьох своїх компонентів, ролі IAM відіграють важливу роль у наданні дозволів для конкретних дій без необхідності використання довготривалих облікових даних. У цьому блозі ми розглянемо, що таке AssumeRole, які типи ролей є в AWS, і чи можна призначати ролі безпосередньо користувачам або сервісам без використання AssumeRole.

Що таке роль IAM?

Роль IAM — це набір дозволів, який надає тимчасовий доступ до ресурсів AWS. На відміну від користувачів IAM, ролі не мають постійних облікових даних. Замість цього вони надають тимчасові облікові дані безпеки, які можуть бути прийняті такими сутностями, як:

Користувачі IAM
Сервіси AWS, такі як Lambda та EC2
Застосунки або зовнішні ідентичності (наприклад, провайдери SAML або OpenID Connect)

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

Розуміння AssumeRole

AssumeRole — це ключовий механізм в AWS, що дозволяє одній сутності (такій як користувач IAM, сервіс AWS або зовнішня ідентичність) тимчасово отримати дозволи іншої ролі IAM. Це здійснюється через API sts:AssumeRole, надане AWS Security Token Service (STS). Коли роль приймається, AWS видає тимчасові облікові дані безпеки, які складаються з:

Access Key
Secret Key
Session Token

Ці облікові дані дійсні протягом обмеженого часу (від 15 хвилин до 12 годин), після чого вони стають недійсними.

Варіанти використання AssumeRole

Перехресний доступ між обліковими записами: Дозволяє сутностям одного облікового запису AWS отримати доступ до ресурсів іншого облікового запису.
Делегування ролей сервісу: Сервіси, такі як Lambda або ECS, приймають ролі для виконання дій від вашого імені.
Федеративний доступ: Надання доступу до ресурсів AWS для зовнішніх користувачів через провайдерів ідентичностей, таких як Okta або Google.
Найкращі практики безпеки: Зменшення ризику витоку облікових даних шляхом використання тимчасових токенів.

Приклад політики AssumeRole

Ось простий приклад політики, яка дозволяє користувачу або застосунку в Обліковому записі A прийняти роль в Обліковому записі B:

{  
 "Version": "2012-10-17",  
 "Statement": [  
 {  
 "Effect": "Allow",  
 "Principal": {  
 "AWS": "arn:aws:iam::123456789012:user/ExampleUser"  
 },  
 "Action": "sts:AssumeRole",  
 "Condition": {}  
 }  
 ]  
}

Типи ролей IAM в AWS

AWS пропонує кілька типів ролей, адаптованих до різних варіантів використання:

Роль сервісу

Використовується сервісами AWS (наприклад, EC2, Lambda або RDS) для виконання дій від вашого імені.
Приклад: Роль EC2 для дозволу читання/запису в S3.

Роль для перехресного доступу між обліковими записами

Дозволяє сутностям одного облікового запису AWS отримати доступ до ресурсів іншого облікового запису.
Приклад: Обмін доступом між двома обліковими записами AWS для спільного проєкту.

Роль для постачальника ідентичності

Використовується для надання тимчасового доступу зовнішнім користувачам (федеративний доступ) через провайдерів ідентичностей, таких як Google або Active Directory Federation Services (ADFS).

Роль завдання

Призначена для завдань у таких сервісах, як ECS, дозволяючи їм отримати доступ до ресурсів AWS.
Приклад: Завдання ECS, яке отримує доступ до таблиці DynamoDB.

Роль профілю екземпляра

Роль, прикріплена до EC2 екземпляра через профіль екземпляра, дозволяючи екземпляру отримати доступ до ресурсів AWS.
Приклад: Роль профілю EC2 для взаємодії з S3.

Роль, пов'язана з сервісом

Попередньо визначені ролі, створені та керовані AWS для конкретних сервісів.
Приклад: Роль для груп масштабування автоматичного управління (Auto Scaling).

Роль обмеження дозволів

Обмежує максимальні дозволи, які може мати сутність або роль.
Приклад: Обмеження доступу розробника до лише певних ресурсів в обліковому записі.

Чи можна призначати ролі без AssumeRole?

Коротка відповідь: ні, ви не можете призначити роль IAM безпосередньо користувачу IAM, групі або сервісу без використання механізму AssumeRole.
Ось чому:

Чому AssumeRole є обов'язковим

Ролі призначені для тимчасового доступу
Ролі призначені для тимчасових дозволів і не прив'язані до конкретної сутності. Вимагаючи використання AssumeRole, AWS гарантує, що дозволи надаються лише коли це явно необхідно.
Розмежування облікових даних
На відміну від користувачів IAM, які залежать від довготривалих облікових даних, ролі IAM надають короткострокові облікові дані, які мають термін дії, що зменшує ризик зловживання.
Найкращі практики безпеки
Вимога використання AssumeRole забезпечує надання дозволів лише за суворих умов і на обмежений час, що відповідає принципу найменших привілеїв (least privilege).
Аудит та моніторинг
API sts:AssumeRole генерує логи CloudTrail, що дозволяє краще відслідковувати, хто і коли використовував роль.

Коли ролі не потребують явних викликів AssumeRole

Хоча AssumeRole є стандартним механізмом, існують ситуації, коли AWS абстрагує цей процес, і здається, що ролі призначаються безпосередньо:

1. Ролі, прикріплені до сервісів AWS

AWS дозволяє безпосередньо прикріплювати ролі до сервісів, таких як EC2, Lambda або ECS.
У цих випадках AWS автоматично обробляє процес AssumeRole за кулісами.
Приклад: Роль екземпляра EC2 може отримати доступ до S3 без явних викликів AssumeRole, використовуючи метадані екземпляра.

2. Ролі, пов'язані із сервісом

Деякі сервіси AWS, такі як Auto Scaling або Elastic Beanstalk, автоматично створюють та керують ролями, пов'язаними із сервісом.
Ці ролі приймаються сервісом без необхідності втручання користувача.

3. Федеративні ідентичності

Коли використовуються постачальники ідентичностей (наприклад, Google, Okta), федеративний користувач автоматично приймає роль після автентифікації.

Основні висновки

Ролі IAM є важливими для надання тимчасового доступу до ресурсів AWS без довготривалих облікових даних.
AssumeRole — це основний механізм для отримання тимчасових дозволів сутностями.
Хоча ролі не можна безпосередньо призначити користувачам або сервісам, AWS надає безшовну інтеграцію для конкретних варіантів використання, таких як ролі екземплярів EC2 або ролі, пов'язані із сервісами.
Такий підхід забезпечує безпеку, гнучкість і можливості аудиту, відповідаючи принципу найменших привілеїв.

Розуміючи, як працюють ролі IAM та важливість AssumeRole, ви можете створити безпечні та масштабовані механізми управління доступом у вашому середовищі AWS.

Перекладено з: Understanding IAM Roles in AWS: AssumeRole and Assigning Roles