QuickSight の権限と IAM の関係を整理する

QuickSight の権限は、ロールと共有（記事2）でだいたいの「見える／見えない」が説明できます。
ところが、ロールも共有も問題ないのに、VPC 内のデータベースへの接続作成だけが失敗するケースがあります。
このとき原因は QuickSight の中ではなく、その外側にある IAM の権限です。

IAM まわりは奥が深い領域ですが、ここでは入口として「どちらの権限の問題かを切り分ける」ところまでに絞って整理します。網羅的なポリシー設計には踏み込みません。

この記事では、以下の3つをまとめています。

• QuickSight の権限が「IAM の権限」と「QuickSight 内部の権限（ロール×共有）」の2種類に分かれること
• IAM の権限が何を決めているか（quicksight:* の権限と、VPC 接続で必要になる PassRole・Trust Policy）
• 「Admin ロールなのに操作できない」症状を、どちらの権限の問題か切り分ける見方

このシリーズは QuickSight の権限を「認証 → 認可 → RLS → IAM 境界」の順にたどる入口記事の4本目です。IAM の話は、前3本で見てきた QuickSight 内部の権限の「外側」に当たります。

• 1本目 QuickSight のログイン方式を整理する（認証）
• 2本目 QuickSight のアクセスはロールとリソース共有で決まる（認可）
• 3本目 QuickSight の行レベルセキュリティ(RLS)とは

QuickSight の権限は2種類ある

権限を切り分けるとき、まず押さえたいのが、種類の違う2つの権限が関わっていることです。この2つはたがいに独立していて、取り違えると原因でない側を調べ続けてしまいます。

権限の種類	どこで決まるか	何を決めるか	制御するもの
IAM の権限	AWS アカウントの IAM	誰が QuickSight の API・管理操作を実行できるか	IAM ポリシー
QuickSight 内部の権限	QuickSight アプリの中	何を見る／編集できるか（記事2の「ロール × 共有」の掛け算）	ロールとアセット共有

片方がそろっていても、もう片方が欠ければ通りません。

• IAM で API を叩ける権限があっても、共有されていないダッシュボードは見えない
• 逆に、ロールも共有もそろっているのに VPC 接続の作成だけ失敗する → このときは IAM の権限を見る

IAM の権限が決めていること

IAM の権限は、AWS アカウントの IAM で「誰が QuickSight を操作できるか」を決めます。QuickSight 内部のロールや共有とは別に、IAM ポリシーで制御される部分です。

quicksight:* のアイデンティティベースポリシー

QuickSight の API や管理操作は、quicksight: から始まるアクションとして IAM に定義されています。
これらを実行できるかは、操作する人（IAM ユーザーやロール）に紐づいたアイデンティティベースポリシーで決まります¹。
API 経由でアセットを操作したりアカウント設定を変えたりする権限は、IAM の話です。

VPC 接続に必要な PassRole と Trust Policy

IAM の権限が関わる代表例が、VPC 内のデータソースへ接続するときです。VPC 接続では QuickSight に IAM ロール（実行ロール）を渡し、QuickSight がそのロールを引き受けて VPC 内のリソースへアクセスします。ここで、性質の違う2つの設定が両方そろっている必要があります。

• iam:PassRole: 操作する人（呼び出し元）が「このロールを QuickSight に渡してよい」権限を持つこと
• Trust Policy: 渡されるロール側が「quicksight.amazonaws.com に引き受けを許可する」と宣言していること²

前者は呼び出し元プリンシパルの権限、後者は渡されるロール側の設定で、別物です³。どちらか一方だけでは接続は通りません。

エラーメッセージで、どちらが欠けているか切り分けられます。

エラーメッセージ	欠けているもの	どちら側の問題か
not authorized to perform iam:PassRole	呼び出し元の PassRole 権限	呼び出し元
Failed to assume your role. Verify the trust relationships...	渡されるロールの Trust Policy	ロール側

リソースベースポリシーには対応していない

QuickSight は、IAM 側でよくある次の制御方式に対応していません¹。

• リソースベースポリシー（S3 のバケットポリシーのように、リソース側に IAM ポリシーを貼る方式）
• タグベースの認可
• サービスロール／サービスリンクロール

そのため QuickSight を IAM で制御するときは、アイデンティティベースポリシーと、上の PassRole／Trust の組み合わせで考えます。

「Admin ロール＝全権」ではない

記事2では「Admin ロールでも、共有されていないダッシュボードは見えない」と書きました。Admin が万能でないのは、QuickSight 内部の権限だけでなく IAM の権限にも当てはまります。

IAM Identity Center と連携した構成では、管理操作の一部が QuickSight の Admin ロールではなく、IAM の権限に分離されます⁴。次のような操作が該当します。

• VPC 接続
• KMS による暗号化まわり
• アカウントレベルの設定

QuickSight 上で Admin ロールを持っていても、IAM でこれらの権限がなければ操作できません。「Admin なのに VPC 接続でつまずく」のは、この分離が理由です。

症状からどちらの権限か切り分ける

「操作できない／見えない」に直面したとき、どちらの権限を見るかの早見表です。

症状	どちらの権限か	見るべき場所
API・管理操作が AccessDenied	IAM の権限	quicksight:* のアイデンティティベースポリシー
ダッシュボードが一覧に出ない	QuickSight 内部の権限	アセットの共有（記事2）
VPC 接続の作成・インポートに失敗	IAM の権限	iam:PassRole（呼び出し元）＋ Trust Policy（渡されるロール）
KMS・アカウント設定が変更できない（IAM Identity Center 連携時）	IAM の権限	IAM に該当の権限があるか（Admin ロールでは足りない）

まとめ

• 目的: 権限で「操作できない／見えない」に直面したとき、原因調査を最短化する。
• 手段: 症状が IAM の権限（API・VPC・KMS の操作）か QuickSight 内部の権限（ロール×共有）かを判定し、上の対応表で原因の側を特定する。
• 効果: 調査範囲が片側に絞られ、原因でない側を調べる手戻りを防げる。

関連記事

QuickSight の権限を「認証 → 認可 → RLS → IAM 境界」の順にたどる入口記事です。

• 1本目 QuickSight のログイン方式を整理する（認証）
• 2本目 QuickSight のアクセスはロールとリソース共有で決まる（認可）
• 3本目 QuickSight の行レベルセキュリティ(RLS)とは
• 4本目 QuickSight の権限と IAM の関係を整理する（IAM 境界・本記事）

1. Amazon QuickSight で IAM を使用する（アイデンティティベースポリシー対応・リソースベースポリシー／タグベース認可／サービスリンクロール非対応） ↩ ↩² ↩³

2. CLI で VPC 接続を構成する（quicksight.amazonaws.com を信頼するロールと --role-arn） ↩

3. ユーザーにロールを AWS サービスへ渡す権限を付与する（iam:PassRole は呼び出し元の権限・Trust Policy はロール側の別要素） ↩

4. Amazon Quick のユーザー種別とロール（IAM Identity Center 連携時の IAM／Admin ロール権限の二分表を含む） ↩ ↩²