В чем разница между IAM-ролью и IAM-политикой в AWS?

Разница между IAM-ролью и IAM-политикой в AWS

В AWS Identity and Access Management (IAM) роли и политики являются фундаментальными компонентами системы контроля доступа, но выполняют разные функции и используются в различных контекстах. Понимание их различий критически важно для построения безопасной и эффективной архитектуры в облаке.

IAM-политика: определение прав

IAM-политика (Policy) — это документ на языке JSON, который определяет разрешения (permissions). Политика описывает, какие действия (например, s3:GetObject, ec2:RunInstances) разрешены или запрещены для каких ресурсов (например, конкретного S3-бакета или EC2-инстанса) и при каких условиях.

Политика НЕ привязана напрямую к пользователю или роли. Она является декларативным набором правил. Существует два основных типа политик:

• Identity-based policies (Политики на основе удостоверения): Прикрепляются к пользователям, группам или ролям IAM.
• Resource-based policies (Политики на основе ресурса): Прикрепляются непосредственно к ресурсам AWS (например, к политике S3-бакета или KMS-ключа).

Пример политики, разрешающей чтение из конкретного S3-бакета:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-example-bucket/*"
        }
    ]
}

IAM-роль: временное удостоверение с полномочиями

IAM-роль (Role) — это удостоверение IAM с определенным набором разрешений, которое не имеет постоянных долгосрочных учетных данных (логина и пароля или access key). Роль предназначена для временного делегирования доступа.

Ключевые характеристики роли:

• Не связана с конкретным пользователем. Её может "принять" (assume) доверенный субъект (trusted entity).
• Создает временные безопасные учетные данные (временные ключи доступа, токен безопасности и ID сессии) при каждом принятии роли.
• Содержит две ключевые части:

    1.  **Доверительная политика (Trust Policy):** Определяет, *кому* разрешено принять эту роль (например, другому аккаунту AWS, конкретному сервису AWS, федеративным пользователям). Это политика на основе ресурса, прикрепленная непосредственно к роли.
    2.  **Политика разрешений (Permission Policy):** Определяет, *что* можно делать с помощью этой роли. Это identity-based политика, прикрепленная к роли.

Пример доверительной политики, разрешающей принятие роли службой EC2:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Основные различия в сравнительной таблице

Взаимодействие на практике

Связь между сущностями можно представить так:

**Доверенный субъект** (например, EC2-инстанс)
        ↓ (вызывает sts:AssumeRole)
**IAM-роль** (с Trust Policy, разрешающей EC2)
        ├── **Permission Policy 1** (политика разрешений)
        └── **Permission Policy 2** (политика разрешений)
                ↓ (определяют права)
**Ресурсы AWS** (S3, DynamoDB и т.д.)

Пример архитектуры: Вы создаете роль EC2-To-S3-Role. К ней прикрепляете доверительную политику, где Principal — это ec2.amazonaws.com, и политику разрешений на доступ к S3. Затем вы запускаете EC2-инстанс и присваиваете ему эту IAM-роль. После запуска приложения на инстансе через Metadata Service автоматически получают временные ключи доступа от этой роли и могут выполнять разрешенные действия с S3.

Итог: Политика — это "что" (правила доступа), а Роль — это "кто + что + как" (временное удостоверение с правилами и механизмом делегирования). Политики — это строительные блоки разрешений, а Роли — это безопасный контейнер для этих блоков, предназначенный для динамического назначения полномочий между сервисами, аккаунтами и пользователями.