IAMロールとポリシーの仕組みを理解する

前回の記事では、IAMユーザーとグループによるアクセス管理の基礎を解説しました。本記事では、より柔軟なアクセス制御を実現するIAMロールと、権限を定義するIAMポリシーの仕組みについて詳しく解説します。ロールとポリシーを理解することで、セキュアで管理しやすい権限設計ができるようになります。

IAMロールとは

IAMロールは、AWSリソースやサービス、外部ユーザーに一時的な認証情報を付与するためのエンティティです。IAMユーザーが「誰であるか」を表すのに対し、IAMロールは「何ができるか」を表します。

IAMユーザーとIAMロールの違い

IAMユーザーとIAMロールは似ているようで、その性質は大きく異なります。

graph LR
    subgraph "IAMユーザー"
        U[ユーザー] --> LTC[長期的な認証情報]
        LTC --> AK[アクセスキー]
        LTC --> PW[パスワード]
    end
    
    subgraph "IAMロール"
        R[ロール] --> TTC[一時的な認証情報]
        TTC --> ST[セッショントークン]
        TTC --> TAK[一時アクセスキー]
        TTC --> EXP[有効期限]
    end

IAMロールの主な使用シナリオ

IAMロールは以下のようなシナリオで使用されます。

AWSサービスへの権限付与

EC2インスタンスやLambda関数などのAWSサービスが他のAWSリソースにアクセスする際に使用します。例えば、EC2インスタンスからS3バケットにアクセスする場合、インスタンスにIAMロールをアタッチすることで、アクセスキーをインスタンスに保存することなく安全にアクセスできます。

クロスアカウントアクセス

別のAWSアカウントのユーザーやサービスが、自分のアカウントのリソースにアクセスする際に使用します。本番環境と開発環境を別アカウントで管理している場合などに活用されます。

IDフェデレーション

企業の既存のIDプロバイダー（Active Directory、Okta、Google Workspaceなど）で認証されたユーザーがAWSリソースにアクセスする際に使用します。

Webアプリケーションからのアクセス

Amazon CognitoやOIDCプロバイダーを使用して、Webアプリケーションやモバイルアプリケーションのユーザーに一時的なAWS認証情報を付与する際に使用します。

IAMロールの構成要素

IAMロールは、信頼ポリシー（Trust Policy）と許可ポリシー（Permission Policy）の2つのポリシーで構成されています。

graph TB
    subgraph "IAMロールの構成"
        Role[IAMロール]
        TP[信頼ポリシー<br/>Trust Policy]
        PP[許可ポリシー<br/>Permission Policy]
        
        Role --> TP
        Role --> PP
        
        TP -->|誰がロールを<br/>引き受けられるか| Principal[プリンシパル]
        PP -->|何ができるか| Actions[アクション]
    end

信頼ポリシー（Trust Policy）

信頼ポリシーは、誰がそのロールを引き受けられるかを定義します。AssumeRoleアクションを許可するプリンシパル（エンティティ）を指定します。

EC2インスタンスがロールを引き受けることを許可する信頼ポリシーの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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

別のAWSアカウントがロールを引き受けることを許可する信頼ポリシーの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

許可ポリシー（Permission Policy）

許可ポリシーは、ロールを引き受けたエンティティが実行できるアクションを定義します。IAMユーザーやグループにアタッチするポリシーと同じ形式です。

AssumeRoleの仕組み

AssumeRoleは、IAMロールを引き受けて一時的な認証情報を取得するSTSアクションです。この仕組みを理解することで、ロールベースのアクセス制御を適切に設計できます。

AssumeRoleの流れ

AssumeRoleの処理フローを以下に示します。

sequenceDiagram
    participant Caller as 呼び出し元<br/>(ユーザー/サービス)
    participant STS as AWS STS
    participant Role as IAMロール
    participant Resource as AWSリソース
    
    Caller->>STS: AssumeRole リクエスト
    STS->>Role: 信頼ポリシーを確認
    Role-->>STS: 許可/拒否
    STS-->>Caller: 一時的な認証情報を返却<br/>(AccessKeyId, SecretAccessKey, SessionToken)
    Caller->>Resource: 一時的な認証情報でアクセス
    Resource-->>Caller: レスポンス

AssumeRoleを実行すると、以下の一時的な認証情報が返されます。

• AccessKeyId: 一時的なアクセスキーID
• SecretAccessKey: 一時的なシークレットアクセスキー
• SessionToken: セッショントークン（APIリクエストに必須）
• Expiration: 認証情報の有効期限（デフォルト1時間、最大12時間）

AWS CLIでのAssumeRole実行例

AWS CLIを使用してロールを引き受ける例を示します。

1
2
3
4

# ロールを引き受けて一時的な認証情報を取得
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session

レスポンスとして以下のような一時的な認証情報が返されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "Credentials": {
    "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "SessionToken": "FwoGZXIvYXdzEBYaDkV4YW1wbGVTZXNzaW9u...",
    "Expiration": "2026-01-25T19:00:00+00:00"
  },
  "AssumedRoleUser": {
    "AssumedRoleId": "AROA3XFRBF535EXAMPLE:my-session",
    "Arn": "arn:aws:sts::123456789012:assumed-role/MyRole/my-session"
  }
}

取得した一時的な認証情報を環境変数に設定することで、そのロールの権限でAWSリソースにアクセスできます。

1
2
3
4
5
6

export AWS_ACCESS_KEY_ID="ASIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="FwoGZXIvYXdzEBYaDkV4YW1wbGVTZXNzaW9u..."

# ロールの権限でS3バケット一覧を取得
aws s3 ls

EC2インスタンスプロファイル

EC2インスタンスにIAMロールをアタッチするには、インスタンスプロファイルを使用します。インスタンスプロファイルは、IAMロールのコンテナであり、起動時にEC2インスタンスに関連付けられます。

graph TB
    subgraph "EC2とIAMロールの関係"
        EC2[EC2インスタンス]
        IP[インスタンスプロファイル]
        Role[IAMロール]
        IMDS[インスタンスメタデータ<br/>サービス IMDS]
        
        EC2 --> IP
        IP --> Role
        EC2 <--> IMDS
        IMDS -->|一時的な認証情報| EC2
    end

EC2インスタンス上で動作するアプリケーションは、インスタンスメタデータサービス（IMDS）から自動的に一時的な認証情報を取得します。AWS SDKは自動的にこの認証情報を使用するため、アプリケーションコード内にアクセスキーを記述する必要がありません。

IAMポリシーの基本構造

IAMポリシーは、アクセス許可を定義するJSON形式のドキュメントです。ポリシーの構造を理解することで、適切な権限設計が可能になります。

ポリシードキュメントの構成要素

IAMポリシーは以下の要素で構成されています。

ポリシーのJSON構造例

S3バケットへの読み取り専用アクセスを許可するポリシーの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

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

Effect（効果）

Effectは、ステートメントの結果を指定します。

• Allow: 指定されたアクションを許可
• Deny: 指定されたアクションを拒否

Denyは常にAllowよりも優先されます。複数のポリシーが適用される場合、1つでもDenyがあればそのアクションは拒否されます。

graph TB
    subgraph "ポリシー評価ロジック"
        Start[リクエスト] --> Check1{明示的なDenyあり?}
        Check1 -->|はい| Deny[拒否]
        Check1 -->|いいえ| Check2{明示的なAllowあり?}
        Check2 -->|はい| Allow[許可]
        Check2 -->|いいえ| DefaultDeny[暗黙的な拒否]
    end

Action（アクション）

Actionは、許可または拒否する操作を指定します。アクションはサービス名:アクション名の形式で記述します。

1
2
3
4
5
6
7

{
  "Action": [
    "ec2:StartInstances",
    "ec2:StopInstances",
    "ec2:DescribeInstances"
  ]
}

ワイルドカード（*）を使用して、複数のアクションを一括指定することもできます。

1
2
3

{
  "Action": "s3:*"
}

1
2
3

{
  "Action": "ec2:Describe*"
}

Resource（リソース）

Resourceは、アクションの対象となるAWSリソースをARN（Amazon Resource Name）で指定します。

ARNの基本形式は以下のとおりです。

arn:partition:service:region:account-id:resource-type/resource-id

リソースの指定例を示します。

1
2
3
4
5
6
7

{
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*",
    "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-1234567890abcdef0"
  ]
}

Condition（条件）

Conditionは、ポリシーが適用される条件を指定します。IPアドレス、時間、MFAの有無などに基づいてアクセスを制御できます。

特定のIPアドレス範囲からのアクセスのみを許可する例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.168.1.0/24",
            "10.0.0.0/8"
          ]
        }
      }
    }
  ]
}

MFAが有効な場合のみアクセスを許可する例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

主な条件演算子は以下のとおりです。

IAMポリシーの種類

IAMポリシーには、管理方法や用途によっていくつかの種類があります。

AWS管理ポリシー

AWS管理ポリシーは、AWSが作成・管理する再利用可能なポリシーです。一般的なユースケースに対応しており、AWSがセキュリティベストプラクティスに基づいて更新を行います。

主なAWS管理ポリシーの例を示します。

AWS管理ポリシーのメリットは以下のとおりです。

• メンテナンス不要: AWSが自動的に更新
• すぐに使える: 一般的なユースケースに対応済み
• ベストプラクティス準拠: AWSのセキュリティ基準に従っている

一方、デメリットとしては以下があります。

• 柔軟性が低い: 細かい権限制御ができない
• 過剰な権限: 必要以上の権限が付与されることがある

カスタマー管理ポリシー

カスタマー管理ポリシーは、ユーザーが作成・管理するポリシーです。組織固有の要件に合わせて細かく権限を設定できます。

カスタマー管理ポリシーを作成する際のベストプラクティスを示します。

最小権限の原則に従う

必要最小限の権限のみを付与します。以下は、特定のS3バケットに対して特定のプレフィックスのみアクセスを許可する例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::company-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": "department-a/*"
        }
      }
    },
    {
      "Sid": "AllowObjectAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::company-data/department-a/*"
    }
  ]
}

タグベースのアクセス制御を活用する

リソースタグに基づいてアクセスを制御することで、管理を効率化できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "development"
        }
      }
    }
  ]
}

インラインポリシー

インラインポリシーは、特定のIAMエンティティ（ユーザー、グループ、ロール）に直接埋め込まれるポリシーです。

インラインポリシーは、特定のユーザーやロールに固有の権限を付与する場合にのみ使用することが推奨されています。一般的には、管理ポリシー（AWS管理またはカスタマー管理）を使用する方が管理しやすくなります。

リソースベースポリシー

リソースベースポリシーは、AWSリソース（S3バケット、SNSトピック、SQSキューなど）に直接アタッチするポリシーです。アイデンティティベースポリシーとの違いは、Principal要素を使用して「誰に」アクセスを許可するかを指定する点です。

S3バケットポリシーの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::shared-bucket",
        "arn:aws:s3:::shared-bucket/*"
      ]
    }
  ]
}

IAMポリシーの評価ロジック

複数のポリシーが適用される場合、AWSは以下のロジックでアクセスを評価します。

flowchart TB
    Start[リクエスト開始] --> SCP{SCPで許可?}
    SCP -->|いいえ| Deny1[拒否]
    SCP -->|はい| ExplicitDeny{明示的なDenyあり?}
    ExplicitDeny -->|はい| Deny2[拒否]
    ExplicitDeny -->|いいえ| ExplicitAllow{明示的なAllowあり?}
    ExplicitAllow -->|いいえ| Deny3[暗黙的な拒否]
    ExplicitAllow -->|はい| ResourcePolicy{リソースベースポリシーで許可?}
    ResourcePolicy -->|該当なし| IdentityPolicy{アイデンティティベースポリシーで許可?}
    ResourcePolicy -->|はい| Allow1[許可]
    IdentityPolicy -->|いいえ| Deny4[拒否]
    IdentityPolicy -->|はい| PermBoundary{アクセス許可境界で許可?}
    PermBoundary -->|いいえ| Deny5[拒否]
    PermBoundary -->|はい| SessionPolicy{セッションポリシーで許可?}
    SessionPolicy -->|いいえ| Deny6[拒否]
    SessionPolicy -->|はい| Allow2[許可]

評価の優先順位は以下のとおりです。

1. 明示的なDeny: 最優先で拒否
2. Organizations SCP: 組織レベルの制御
3. リソースベースポリシー: リソースに直接アタッチされたポリシー
4. アイデンティティベースポリシー: ユーザー/グループ/ロールにアタッチされたポリシー
5. アクセス許可境界: IAMエンティティの最大権限を制限
6. セッションポリシー: AssumeRole時に指定される追加制限
7. 暗黙的なDeny: 明示的なAllowがなければ拒否

実践的なポリシー設計パターン

実際の運用で役立つポリシー設計パターンを紹介します。

開発者向けポリシー

開発者がEC2、S3、RDS、Lambda等の開発に必要なリソースを操作できるが、IAMやネットワーク設定は変更できないポリシーの例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDevelopmentServices",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:*",
        "lambda:*",
        "dynamodb:*",
        "logs:*",
        "cloudwatch:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    },
    {
      "Sid": "DenyIAMAndNetworkChanges",
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "ec2:CreateVpc",
        "ec2:DeleteVpc",
        "ec2:CreateSubnet",
        "ec2:DeleteSubnet",
        "ec2:CreateInternetGateway",
        "ec2:DeleteInternetGateway"
      ],
      "Resource": "*"
    }
  ]
}

本番環境の保護ポリシー

本番環境のリソースに対して読み取りは許可するが、変更は拒否するポリシーの例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyAccessToProduction",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:Get*",
        "s3:List*",
        "rds:Describe*",
        "logs:Get*",
        "logs:Describe*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "production"
        }
      }
    },
    {
      "Sid": "DenyModifyProduction",
      "Effect": "Deny",
      "Action": [
        "ec2:TerminateInstances",
        "ec2:StopInstances",
        "rds:DeleteDBInstance",
        "rds:StopDBInstance",
        "s3:DeleteObject",
        "s3:DeleteBucket"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}

IAM Access Analyzerの活用

IAM Access Analyzerは、外部エンティティと共有されているリソースを特定し、権限を分析するサービスです。ポリシーの検証や未使用のアクセス権の特定に活用できます。

主な機能

外部アクセスの検出

S3バケット、IAMロール、KMSキーなどが外部アカウントや公開アクセスで共有されていないかを検出します。

ポリシーの検証

カスタムポリシーの文法エラーやセキュリティ上の問題を検出します。ポリシーを作成する前にチェックすることで、誤った設定を防げます。

未使用アクセスの分析

一定期間使用されていないアクセス権を特定し、最小権限への見直しを支援します。

IAM Access Analyzerによるポリシー検証

AWS CLIを使用してポリシーを検証する例を示します。

1
2
3

aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://my-policy.json

検証結果には、エラー、警告、提案が含まれます。これらを確認し、ポリシーを改善することでセキュリティを強化できます。

まとめ

本記事では、IAMロールとポリシーの仕組みについて詳しく解説しました。

IAMロールは、一時的な認証情報を使用した安全なアクセス制御を実現します。EC2インスタンスへの権限付与、クロスアカウントアクセス、IDフェデレーションなど、さまざまなシナリオで活用できます。

IAMポリシーのJSON構造（Effect/Action/Resource/Condition）を理解し、AWS管理ポリシーとカスタマー管理ポリシーを適切に使い分けることで、セキュアで管理しやすい権限設計が可能になります。

権限設計においては、以下のポイントを意識することが重要です。

• 最小権限の原則に従い、必要最小限の権限のみを付与する
• IAMロールを活用し、長期的なアクセスキーの使用を避ける
• タグベースのアクセス制御で管理を効率化する
• IAM Access Analyzerを活用してポリシーを検証する
• 定期的に権限を見直し、未使用のアクセス権を削除する

次回の記事では、VPCとサブネットでネットワークを構築する方法について解説します。

参考リンク

• AWS IAM ロール
• IAM ポリシーと許可
• IAM JSON ポリシーリファレンス
• IAM Access Analyzer
• AWS STS AssumeRole