クロスアカウントアクセスとロールの引き受け ― AssumeRole・権限委譲・信頼ポリシー

導入

人だけでなく、システム同士もアカウントをまたいでアクセスする必要があります。例えば「共有サービスアカウントのLambdaが、本番アカウントのS3バケットを読みたい」といったケースです。これを安全に行う仕組みが、IAMロールの 引き受け（AssumeRole） です。

説明

クロスアカウントアクセス の基本形は、アクセスされる側（リソース側）のアカウントに IAMロール を作り、アクセスする側（信頼される側）のアカウントやユーザーを 信頼ポリシー（Trust Policy） で明示的に許可することです。アクセスする側は、そのロールを AssumeRole（引き受け） することで、一時的な認証情報を取得して操作します。

flowchart LR
    subgraph AccountA["アカウントA（アクセス元）"]
        U["ユーザー/アプリ"]
    end
    subgraph AccountB["アカウントB（リソース側）"]
        R["IAMロール<br/>信頼ポリシーでAを許可"]
        S3["S3バケット等"]
    end
    U -- "1. AssumeRole" --> R
    R -- "2. 一時的な認証情報を発行" --> U
    U -- "3. 一時credentialsで操作" --> S3

信頼ポリシー はロール自体に付ける特殊なポリシーで、「誰がこのロールを引き受けてよいか」を定義します。ロールに付けた通常の権限ポリシーは「引き受けた後に何ができるか」を定義します。この2つを混同しないことが重要です。

さらに、第三者（他社のSaaSベンダーなど）にロールを引き受けさせる場合は、外部ID（External ID） を信頼ポリシーの条件に含めるべきです。外部IDがないと、ロールARNを知っている別の第三者になりすまされる 混乱した代理人問題（confused deputy problem） のリスクがあります。

読んでみよう

「アカウントAのシステムが、アカウントBのリソースにアクセスしたい」という問題文を見たら、まず「アカウントBにロールを作り、Aを信頼する」という基本形を思い浮かべてください。相手が社外のベンダーであれば、外部IDの有無が正解を左右する重要な条件になります。