AWS IAM詳解：ポリシー、ロール、フェデレーション

AWS Identity and Access Management（IAM）は、AWSリソースへのアクセスを制御する基盤です。IAMは2つの基本的なセキュリティの問いに答えます：あなたは誰ですか？（認証）何ができますか？（認可）IAMを深く理解することは、認定試験のためだけでなく、安全なAWSアーキテクチャを構築するために不可欠です。

なぜIAMが重要なのか

次のような課題を考えてみてください：数百のAWSリソース（顧客データを含むS3バケット、アプリケーションを実行するEC2インスタンス、機密情報を持つデータベース）があります。そして、これらのリソースにさまざまなレベルでアクセスする必要がある数十人、数百人の人とアプリケーションがあります。

IAMがなければ、不可能な選択に直面することになります：全員にフルアクセスを与えるか（壊滅的なセキュリティリスク）、または各個人とリソースに対して個別の認証情報を手動で管理するか（スケールせず、エラーが発生しやすい）。

IAMは以下のための統一フレームワークを提供することでこれを解決します：

アイデンティティ管理：ユーザー、グループ、ロールの作成と管理
アクセス制御：誰がどのリソースにどのような条件でアクセスできるかの定義
フェデレーション：外部IDプロバイダーとの統合
監査証跡：誰が何をいつ行ったかの記録

根本的な課題：最小権限の原則

最小権限の原則は、すべてのアイデンティティがその機能を実行するために必要な権限のみを持つべきであると述べています。それ以上は不要です。これは単純に聞こえますが、実際には驚くほど難しいです。

最小権限が難しい理由

発見の問題：アプリケーションが実際に必要とする権限をどうやって知るのでしょうか？開発者は、特に内部で呼び出しを行うSDKやフレームワークを使用している場合、アプリケーションが行うAWS API呼び出しの完全なリストを知らないことがよくあります。

進化の問題：アプリケーションの要件は時間とともに変化します。起動時に必要なかった権限が後で必要になったり、その逆もあります。ポリシーを実際の要件と同期させるには継続的な努力が必要です。

利便性とのトレードオフ：過度に制限的な権限はアプリケーションの障害を引き起こします。締め切りが迫ると、チームは「一時的に」広い権限を付与し、二度と見直さないことがよくあります。最も簡単な道は通常、最も許可的な道です。

被害範囲の現実：権限が広すぎると、認証情報が侵害された場合に広範な損害を引き起こす可能性があります。s3:*権限を持つEC2インスタンスが侵害された場合、アカウント内のすべてのS3バケットがリスクにさらされます。

最小権限のための戦略

広く始めて、狭める：より広い権限で開発を開始し、IAM Access Analyzerを使用して実際に使用されているものを特定し、実際の使用パターンに基づいてポリシーを作成します。

AWS管理ポリシーを出発点として使用：AWSは一般的なユースケース向けの管理ポリシーを提供しています。それらをレビューし、何を付与するかを理解し、特定のニーズに対してより制限的なカスタムポリシーを作成します。

サービスリンクロールを活用：AWSサービスがあなたの代わりにリソースにアクセスする必要がある場合、カスタムロールを作成する代わりにサービスリンクロールを使用します。AWSはこれらを最小限の必要な権限で維持します。

アイデンティティタイプの理解

IAMはいくつかのアイデンティティタイプを提供し、それぞれ異なるユースケースに対応します。適切なアイデンティティタイプを選択することは、重要なセキュリティ上の決定です。

flowchart TB
    subgraph Principals["IAMプリンシパル"]
        U["IAMユーザー<br/>(長期認証情報)"]
        R["IAMロール<br/>(一時認証情報)"]
        G["IAMグループ<br/>(ユーザーコンテナ)"]
    end

    subgraph Policies["権限アタッチメント"]
        IP["アイデンティティ<br/>ベースポリシー"]
        PB["アクセス許可<br/>境界"]
    end

    U --> G
    G --> IP
    U --> IP
    R --> IP
    U --> PB
    R --> PB

    style U fill:#ef4444,color:#fff
    style R fill:#22c55e,color:#fff
    style G fill:#3b82f6,color:#fff
    style IP fill:#f59e0b,color:#000
    style PB fill:#8b5cf6,color:#fff

IAMユーザー：長期アクセスが必要な人間向け

IAMユーザーは永続的な認証情報（パスワードやアクセスキー）を持っています。以下の場合に適しています：

AWSマネジメントコンソールへのアクセスが必要な場合
外部IDプロバイダーとのフェデレーションを実装できない場合
特定のコンプライアンス要件がIAMユーザー管理を義務付けている場合

ただし、IAMユーザーにはセキュリティ上の課題があります：

認証情報管理の負担：パスワードにはローテーションが必要、アクセスキーにはライフサイクル管理が必要
認証情報漏洩リスク：長寿命の認証情報は盗まれて悪用される可能性がある
スケールの制限：数百のIAMユーザーの管理は管理上複雑になる

ベストプラクティス：IAMユーザーの作成を最小限にします。人間のアクセスには、IDプロバイダー（Okta、Azure AD、IAM Identity Centerなど）とのフェデレーションを優先します。

IAMロール：一時的な引き受けベースのアクセス向け

ロールには永続的な認証情報がありません。代わりに、プリンシパル（ユーザー、アプリケーション、またはサービス）がロールを「引き受ける」と、AWSは自動的に期限切れになる一時的な認証情報を提供します。

ロールは以下に適しています：

AWSサービス：AWSリソースにアクセスする必要があるEC2インスタンス、Lambda関数、その他のサービス
クロスアカウントアクセス：他のAWSアカウントのユーザーまたはサービスへのアクセス付与
フェデレーション：外部システムのアイデンティティにAWSアクセスを提供
特権操作：機密性の高いアクションに対して明示的なロール引き受けを要求

ロールのセキュリティ上の利点は重要です：

長期シークレットがない：一時的な認証情報は自動的に期限切れ（デフォルト：1時間、最大12時間まで設定可能）
監査可能な引き受け：すべてのロール引き受けはCloudTrailに記録される
取り消し可能なアクセス：ロールを取り消すと即座にアクセスが切断される
アイデンティティと権限の分離：同じアイデンティティが異なる目的で異なるロールを引き受けることができる

サービスリンクロール：サービス用のAWS管理権限

一部のAWSサービスは機能するために特定の権限を必要とします。サービスリンクロールはAWSによって作成・管理され、サービスが必要とするものに正確にスコープされた権限を持ちます。

サービスリンクロールの権限は変更できませんが、これは実際にはセキュリティ上の利点です。AWSサービスアクセスの偶発的な過剰権限付与を防ぎます。

グループ：人間ユーザーを大規模に管理

グループには認証情報がありません。権限管理を簡素化するIAMユーザーのコンテナです。個々のユーザーにポリシーをアタッチする代わりに、グループにアタッチします。

このアプローチは以下を提供します：

一貫性：グループ内のすべてのユーザーが同じ権限を持つ
管理の容易さ：ユーザーをグループに追加すると、グループのすべての権限が付与される
明確な組織化：グループはチーム、職務、アクセスレベルを表すことができる

ポリシーの仕組み

ポリシーは権限を定義するJSONドキュメントです。その構造と評価を理解することはセキュリティに不可欠です。

ポリシー構造

すべてのポリシーには1つ以上のステートメントが含まれ、各ステートメントが権限を定義します：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "IpAddress": {"aws:SourceIp": "192.168.1.0/24"}
      }
    }
  ]
}

Effect：AllowまたはDeny。明示的な拒否は常に許可をオーバーライドします。

Action：ステートメントが適用されるAWS APIアクション。ワイルドカード（s3:Get*）を使用できますが、注意が必要です。ワイルドカードは意図したよりも多くを付与することがよくあります。

Resource：ステートメントが適用される特定のAWSリソース。常にできるだけ具体的にしてください。"*"は「すべてのリソース」を意味し、本番ポリシーでは避けるべきです。

Condition：オプションのコンテキスト要件。条件はIP制限、MFA要件、時間ベースのアクセスなどの洗練されたアクセス制御を可能にします。

アイデンティティベースポリシーとリソースベースポリシー

アイデンティティベースポリシーはプリンシパル（ユーザー、グループ、ロール）にアタッチされ、そのプリンシパルが何ができるかを定義します：

「このロールはS3バケットXからオブジェクトを読み取れる」
「このユーザーはタグEnvironment=Developmentを持つEC2インスタンスを起動できる」

リソースベースポリシーはリソースにアタッチされ、誰がそれにアクセスできるかを定義します：

「このS3バケットはアカウント123456789012からの読み取りアクセスを許可する」
「このKMSキーはアカウントYのロールXによって使用できる」

リソースベースポリシーはクロスアカウントアクセスに不可欠です。アクセスするアカウントが事前の信頼関係を持っていなくてもアクセスを可能にします。

アクセス許可境界：委任管理のためのガードレール

アクセス許可境界は、IAMエンティティが持つことができる最大権限を定義します。それ自体は権限を付与せず、アイデンティティベースポリシーが付与できるものを制限します。

アクセス許可境界は以下の場合に使用します：

任意の権限を自分に付与すべきでないチームにIAM管理を委任する場合
特定の権限を超えるべきでないサービスアカウントを作成する場合
ガードレール内でのセルフサービスIAMを実装する場合

たとえば、開発者にアプリケーション用のIAMロールを作成させることができますが、それらのロールがIAMやOrganizationsの権限を持つことを防ぐアクセス許可境界を適用できます。

サービスコントロールポリシー：組織全体のガードレール

サービスコントロールポリシー（SCP）は、組織内のAWSアカウント全体に適用されます。アカウント内のすべてのアイデンティティの最大権限を設定します。

SCPは以下に強力です：

本番アカウントがCloudTrailログを削除できないようにする
使用できるリージョンを制限する
すべてのサービスに暗号化要件を強制する

重要：SCPは権限を付与しません。SCPがアクションを許可しても、アイデンティティベースポリシーがそれを明示的に許可する必要があります。

ポリシー評価：AWSが許可または拒否を決定する方法

プリンシパルがアクションを要求すると、AWSは適用可能なすべてのポリシーを評価します：

flowchart TD
    Start["リクエスト"] --> D1{"明示的拒否<br/>いずれかのポリシーで?"}
    D1 -->|Yes| Deny["拒否"]
    D1 -->|No| D2{"SCPが許可?"}
    D2 -->|No| Deny
    D2 -->|Yes| D3{"リソースベース<br/>ポリシーが許可?"}
    D3 -->|Yes| Allow["許可"]
    D3 -->|No| D4{"アイデンティティベース<br/>ポリシーが許可?"}
    D4 -->|No| Deny
    D4 -->|Yes| D5{"アクセス許可<br/>境界が許可?"}
    D5 -->|No| Deny
    D5 -->|Yes| D6{"セッション<br/>ポリシーが許可?"}
    D6 -->|No| Deny
    D6 -->|Yes| Allow

    style Deny fill:#ef4444,color:#fff
    style Allow fill:#22c55e,color:#fff
    style Start fill:#3b82f6,color:#fff

明示的拒否チェック：いずれかのポリシーがアクションを明示的に拒否している場合、要求は拒否されます。明示的拒否は絶対的です。
組織SCP：アカウントがOrganizationに属している場合、SCPがアクションを許可する必要があります。SCP権限なし=暗黙の拒否。
リソースベースポリシー：リソースベースポリシーがアクションを明示的に許可している場合（プリンシパルが同じアカウント内にいるか、リソースポリシーがクロスアカウントアクセスを許可している場合）、要求は許可される可能性があります。
アイデンティティベースポリシー：プリンシパルにアタッチされたポリシーがアクションを許可する必要があります。
アクセス許可境界：プリンシパルにアクセス許可境界がある場合、それがアクションを許可する必要があります。
セッションポリシー：認証情報がセッションポリシー付きのロール引き受けから来た場合、セッションポリシーがアクションを許可する必要があります。

有効な権限はこれらすべてのポリシーの交差点です。つまり、すべてのレイヤーで権限が必要であり、どのレイヤーも拒否できると考えてください。

セキュリティにとってなぜこれが重要か

この評価モデルは多層防御を可能にします：

SCPは組織全体で危険なアクションのカテゴリ全体を防止
アクセス許可境界は委任されたIAM権限を制限
アイデンティティベースポリシーは特定の権限を付与
リソースベースポリシーはアクセスに追加条件を要求できる

いずれかのレイヤーがアクションを許可しない場合、アクセスは拒否されます。これにより、単一の設定ミスがセキュリティ脆弱性を作成することが難しくなります。

一時的な認証情報とAWS STS

AWS Security Token Service（STS）は、自動的に期限切れになる一時的な認証情報を提供します。これは長寿命の認証情報の問題を排除するため、AWSセキュリティの基本です。

STSが関与するとき

ロール引き受け：プリンシパルがロールを引き受けると、STSは一時的な認証情報を提供します。これは以下の場合に舞台裏で発生します：

EC2インスタンスプロファイル（インスタンスがロールを引き受ける）
Lambda実行ロール（関数がロールを引き受ける）
クロスアカウントアクセス（ユーザーが他のアカウントのロールを引き受ける）

フェデレーション：外部アイデンティティがSAML、OIDC、CognitoでAWSにアクセスすると、STSは一時的な認証情報を提供します。

セッションポリシー：ロールを引き受けるとき、その特定のセッションに対してロールの権限をさらに制限するセッションポリシーをアタッチできます。

セキュリティモデル

一時的な認証情報には3つのコンポーネントがあります：

アクセスキーID（認証情報を識別）
シークレットアクセスキー（リクエストの署名に使用）
セッショントークン（認証情報が一時的で有効であることを証明）

セッショントークンには認証情報の有効期限と引き受けたロールが含まれています。有効期限後、認証情報は自動的に機能を停止します。取り消しは不要です。

アイデンティティフェデレーション：外部IDプロバイダーの信頼

フェデレーションにより、AWS外部で管理されているアイデンティティがAWSリソースにアクセスできます。これは、IAMでアイデンティティ管理を重複させたくない企業にとって重要です。

SAML 2.0フェデレーション

SAMLフェデレーションは、Active Directoryフェデレーションサービス（AD FS）、Okta、Azure ADなどのエンタープライズIDプロバイダーと連携します。

sequenceDiagram
    participant User as ユーザー
    participant IdP as IDプロバイダー<br/>(Okta, AD FS等)
    participant STS as AWS STS
    participant AWS as AWSサービス

    User->>IdP: 1. 認証
    IdP->>User: 2. SAMLアサーション
    User->>STS: 3. AssumeRoleWithSAML
    STS->>User: 4. 一時認証情報
    User->>AWS: 5. AWSリソースにアクセス

SAMLフェデレーションは、人間のアクセスのためのIAMユーザー管理を排除します。エンタープライズIDプロバイダーが認証、パスワードポリシー、MFAを処理します。

OIDCフェデレーション（Webアイデンティティ）

OpenID Connect（OIDC）フェデレーションは、Google、Facebook、AmazonなどのOAuth 2.0プロバイダーと連携します。一般的に以下に使用されます：

ソーシャルアイデンティティでサインインするモバイルアプリケーション
ユーザーの代わりにAWSリソースにアクセスする必要があるWebアプリケーション

AWS CognitoはOIDCフェデレーションを簡素化し、トークン交換を処理し、複数のプロバイダーにわたる統一されたアイデンティティプールを提供します。

IAM Identity Center（AWS SSO）

IAM Identity Centerは、複数のAWSアカウントに対する一元化されたアクセス管理を提供します。独自のアイデンティティストアを使用するか、外部プロバイダーとフェデレーションできます。

利点：

シングルサインオン：すべてのAWSアカウントとアプリケーションに1回のログイン
アクセス許可セット：権限を一度定義し、複数のアカウントに適用
一元化された監査：すべてのアクセスイベントが1か所に

複数のAWSアカウントを持つ組織には、人間のアクセス管理にIAM Identity Centerが推奨されるアプローチです。

よくあるセキュリティミス

IAMユーザーへの過度の依存

すべての従業員にIAMユーザーを作成することはスケールせず、認証情報管理のオーバーヘッドを生み出します。人間のアクセスにはフェデレーションまたはIAM Identity Centerを優先してください。

ロールで十分な場合にアクセスキーを使用

AWSコンピューティングサービス（EC2、Lambda、ECS）で実行されるアプリケーションは、アクセスキーではなくIAMロールを使用すべきです。インスタンスプロファイルと実行ロールは自動的な認証情報ローテーションを提供します。

ワイルドカードアクションとリソース

"Action": "*"または"Resource": "*"を持つポリシーは、通常必要とされるよりもはるかに多くのアクセスを付与します。開発でのこれらのショートカットは、本番ではセキュリティ脆弱性になります。

クロスアカウント信頼の無視

他のアカウントから引き受けられるロールを作成するとき、以下を検討してください：

そのアカウントの全員を信頼しますか？
混乱した代理攻撃を防ぐために外部IDを要求すべきですか？
MFAを要求すべきですか？

条件を使用しない

条件は強力な制限を可能にします：

機密アクションにMFAを要求
特定のIP範囲にアクセスを制限
特定のVPCにアクセスを制限
データストレージに暗号化を要求

条件のないポリシーは通常、必要以上に許可的です。

セキュリティモニタリングと分析

IAM Access Analyzer

Access Analyzerは、アカウントまたは組織外部と共有されているリソースを特定します。継続的に監視し、以下の場合に検出結果を生成します：

S3バケットがパブリックアクセスを許可
IAMロールが外部エンティティによって引き受け可能
KMSキーが外部プリンシパルによって使用可能

意図しない外部アクセスをキャッチするために、すべてのアカウントでAccess Analyzerを有効にしてください。

IAMイベント用CloudTrail

CloudTrailはすべてのIAM API呼び出しを記録します：

誰がユーザー、ロール、ポリシーを作成または変更したか
認証情報がいつどのIPから使用されたか
どのロールが誰によって引き受けられたか

これらのイベントを監視することは、認証情報の侵害とポリシー変更を検出するために不可欠です。

認証情報レポートとAccess Advisor

IAMは未使用および潜在的に過剰権限のエンティティを特定するツールを提供します：

認証情報レポート：すべてのユーザーと認証情報ステータスを含むCSV
Access Advisor：エンティティがどのサービスにいつアクセスしたかを表示

これらを使用して、ローテーションすべき認証情報や削除できる権限を特定します。

まとめ

IAMはAWSのセキュリティ基盤です。主要な概念：

概念	目的
ユーザー	人間のための永続的なアイデンティティ（代わりにフェデレーションを優先）
ロール	サービスおよびクロスアカウントアクセス用の一時的な引き受けベースのアイデンティティ
ポリシー	権限を定義するJSONドキュメント
アクセス許可境界	エンティティが持てる最大権限
SCP	アカウント全体の最大権限
フェデレーション	外部IDプロバイダー統合
STS	一時認証情報の生成

セキュリティ原則：

最小権限：必要な権限のみを付与
一時認証情報：アクセスキーではなくロールを使用
多層防御：SCP、境界、ポリシーを階層化
条件：ポリシーにコンテキスト要件を追加
モニタリング：Access Analyzerを有効にしCloudTrailをレビュー

IAMをマスターするには、ポリシーの書き方だけでなく、セキュリティモデルがなぜそのように機能するかを理解する必要があります。すべてのIAMの決定は「必要な最小権限は何か？この認証情報が侵害された場合何が起こるか？」と問うべきです。

参考資料

IAM ユーザーガイド
IAM ベストプラクティス
ポリシー評価ロジック
Crane, Dylan. AWS Security. Manning Publications, 2022.
Muñoz, Mauricio, et al. Mastering AWS Security, 2nd Edition. Packt, 2024.