クロスアカウントアクセスを理解する

別アカウントへ長期キーを共有せずアクセスを委譲し、信頼・呼出し許可・実操作の三段階を確認します。

この単元で学ぶこと

  • クロスアカウントの両側の許可を設計する
  • ExternalIdの目的と限界を説明する
  • 委譲の検証と終了手順を判断する

本文解説

1. アカウントの境界 開発Aから本番Bの資源を使う場合、同じ会社やOrganizationsにあるだけではアクセスできません。ここではBにロールを作りAから引き受ける方式を考えます。Bが信頼する相手と必要な操作を管理します。

2. 呼出し側の許可 Aの主体へBのロールARNに対するsts:AssumeRoleを許可します。Bの信頼ポリシーでもその主体やAへの委任を認めます。クロスアカウントでは片方だけを設定して終わりにせず、両側の評価と制限を調べます。

3. 引受け後の操作 AssumeRole成功後はBのロールセッションで要求します。Bのロールには必要なActionとResourceを許可します。元のAの管理者権限を無条件に加えてBで全操作できるわけではありません。

4. アカウントPrincipal 信頼ポリシーのPrincipalにアカウントのroot ARNを書く例は、そのrootユーザーだけを指すとは限りません。そのアカウントへ権限委任を認める意味を持つため、呼出し側の許可と必要な主体限定を合わせて確認します。

5. 第三者への委託 複数顧客を扱う監査会社へ委譲する場合、顧客ごとに管理されたExternalIdを信頼ポリシーで要求します。別顧客が監査会社をだまして自社の権限を使わせるConfused deputy問題を防ぐ設計です。

6. ExternalIdの位置付け ExternalIdはAWSで秘密の認証情報としては扱われません。値を知っているだけで任意の主体が引き受けられるようにはせず、信頼するPrincipalも限定します。委託先が顧客ごとの一意性を管理し、対応する値を要求へ渡します。

7. 別のアクセス方式 他アカウントのS3資源へ直接アクセスする資源ポリシー方式もあります。その場合も呼出し元側と資源側の許可を確認します。ロール引受け方式の信頼ポリシーと、直接資源を使う方式の資源ポリシーを混同しないでください。

8. 開始と終了の試験 正しい主体・ExternalIdで引受け成功、不正値や省略では失敗するかを試します。終了時は新しい引受けを止めることと既存セッションを失効させることを分けて確認します。CloudTrailで実際のセッションと操作を追い、長期キー共有を委譲の代わりにしません。

図解

AからBのロールへ
引受けの両側の許可と、引受け後の資源操作の許可は別です。

重要ポイント

  • 相手の信頼と呼出し元の許可を両方確認する。
  • ExternalIdは顧客区別の条件で秘密キーではない。
  • 引受け成功と資源操作成功を別に試す。

間違えやすい点

  • 同じOrganizationsなら自動で信頼されると思う。
  • アカウントroot ARNはroot一人だけと決め付ける。
  • ExternalIdだけでPrincipal制限を省く。

用語解説

クロスアカウント
AWSアカウントの境界をまたぐアクセス。
ExternalId
第三者による代理アクセスで顧客等の条件を識別する値。
Confused deputy
他者が代理人をだまして、その代理人の権限を意図外に使わせる問題。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。