「別のアカウントにあるS3バケットを、こっちのアカウントのEC2から触りたい」——クロスアカウントで最初に手が止まるのがここです。私もSAP（Solutions Architect Professional）の学習で、IAMロールの「信頼ポリシー」と「許可ポリシー」が何度読んでも頭の中で入れ替わり、「どっちが誰がで、どっちが何をだっけ？」で止まりました。本記事は、その2枚を二度と取り違えないよう、時限の「来客バッジ」の例えで整理します。ついでにクロスアカウントの「両側の握手」とExternal ID（社外向けの合言葉）まで一気に片づけます。
1. 結論：恒久キーを配らず「時限の来客バッジ（ロール）」を借りる
細部に入る前に、クロスアカウントの正解の形を先に置きます。他アカウントのリソースを触るときは、アクセスキーを渡し合うのではなく、時限のバッジを"借りる"のが定石です。
- IAMユーザー＝恒久の身分証。ずっと有効なので、配って回すと管理が破綻する。
- IAMロール＝受付で借りる来客バッジ（時限ゲストパス）。数十分〜数時間で自動失効する。
- AssumeRole＝そのバッジを"借りる"行為。借りている間だけ一時的な権限を得る。
そしてこのロール（バッジ）は、2枚の紙でできています。ここが本記事の核です。
- 信頼ポリシー＝「誰が」このバッジを借りられるか（受付の入館名簿）
- 許可ポリシー＝借りたバッジで「何ができるか」（そのバッジが開けるドアの範囲）
2. なぜ恒久のアクセスキーを配ってはいけないのか
「他アカウントに恒久のアクセスキーを発行して渡せば早いのでは？」——最初はそう思いがちです。でもこれは事故のもとで、理由は2つあります。
- 自動失効しない。一度配った恒久キーは、明示的に消さない限り永遠に有効。漏れても無期限のリスクとして残ります。
- 棚卸しが地獄になる。「誰にどのキーを配ったか」が増えるほど追えなくなり、いざ剥奪しようとしても回収漏れが出ます。
一方、ロールを借りて得る一時キーは時間が来れば勝手に切れます。だから「渡しっぱなしにならない」。恒久キーを配らず、その都度バッジを借りさせる——これがクロスアカウントの安全設計の背骨です。
3. ロールは「2枚の紙」でできている ― 信頼ポリシー（誰が）と許可ポリシー（何を）
混同の元凶はこの2枚です。役割の向きが違うので、そこで固定します。
| 2枚の紙 | 問い | 書いてある中身 |
|---|---|---|
| 信頼ポリシー | 誰が借りられるか | このロールをAssumeRoleしてよい相手（＝Principal） |
| 許可ポリシー | 借りて何ができるか | 許可されるアクションとリソース（S3読み取り等） |
「信頼＝誰が（相手）」「許可＝何を（操作）」。この対応さえ握れば、設問で2枚が並んでも迷いません。
そしてクロスアカウントは、両側の握手で初めて成立します。片方だけでは通りません。
- 借りる側（Aアカウント）：利用者のIAMポリシーに「BのロールをAssumeRoleしてよい」という許可が要る。
- 貸す側（Bアカウント）：ロールの信頼ポリシーで「Aを信頼する」と宣言しておく。
「借りにいく許可（A側）」と「貸す相手として認める宣言（B側）」の両方が揃った瞬間にだけバッジが渡る。これがクロスアカウントの握手です。
4. External ID ― 社外に貸すときだけ要る「合言葉」
もう一つ、混乱しやすいのがExternal IDです。これは社外の第三者（外部のSaaSやベンダー）に自分のロールを貸すときに、信頼ポリシーへ仕込む合言葉です。
狙いは「混乱した代理（confused deputy）」の防止。外部サービスがあなたのロールを引き受ける構成では、その外部サービスが別の顧客の依頼であなたのロールを誤って使ってしまう危険があります。そこで「この合言葉付きのリクエストしか受け付けない」と縛ることで、取り違えを防ぎます。
ポイントは適用範囲です。External IDが要るのは"社外に貸す"ときだけ。自社内のアカウントAからBへ借りる構成では不要です。「クロスアカウント＝常にExternal ID」ではありません。
5. 早見表：何が問われたら、どれを思い浮かべるか
設問や要件のキーワードから逆引きできるよう、判断軸を一覧にします。
| 状況・要件のキーワード | 答え | 決め手 |
|---|---|---|
| 「誰がこのロールを借りられるか」 | 信頼ポリシー | 信頼＝相手（Principal）を書く紙 |
| 「借りたあと何ができるか」 | 許可ポリシー | 許可＝アクション／リソースを書く紙 |
| 他アカウントを恒久キーで連携したい | ロールを使う（キー配布はNG） | 恒久キーは自動失効せず棚卸し地獄 |
| 社外のSaaSに自分のロールを貸す | External IDを付ける | confused deputy（取り違え）対策の合言葉 |
| 社内のアカウントA→Bで借りる | External IDは不要 | 合言葉は社外third-party限定 |
6. 私がつまずいたポイント（実体験）
整理して書いていますが、私はこの周辺を最初から綺麗に区別できたわけではありません。つまずきは2つでした。
- 信頼ポリシーと許可ポリシーの向きが入れ替わる：「信頼」という言葉から"何を許すか"を連想してしまい、逆に取っていました。信頼＝誰が（相手）、許可＝何を（操作）と、言葉と向きをセットで固定したら止まりました。
- External IDを社内でも要ると思い込んだ：「クロスアカウント＝合言葉が必要」と早合点していました。正しくは社外の第三者に貸すときだけで、社内アカウント間では不要。confused deputy が"社外の取り違え"対策だと分かって腑に落ちました。
まとめ
クロスアカウントは「恒久キーを配らず、時限の来客バッジ（ロール）を借りる」。ロールは2枚の紙＝信頼ポリシー（誰が借りられるか）と許可ポリシー（借りて何ができるか）でできていて、借りる側の許可と貸す側の信頼が揃う両側の握手で成立する。External IDは社外に貸すときだけの合言葉。「信頼＝誰が／許可＝何を」の1問を当てれば、もう取り違えません。
このAssumeRole／ポリシーの整理は、私がオンプレ環境の出身からクラウド（AWS）インフラエンジニアへ転職し、いまAWS SAP合格を目指して続けている学習記録の一部です。「AWSの権限まわりに苦労している」という方は、そもそも私がどうやってオンプレからクラウドの世界へ移ってきたのか——転職のリアルも参考になるかもしれません。