IAMを使った自己プロビジョニング方式で、Amazon QuickSightの権限設定する際の注意点

はじめに

西藤です。

Amazon QuickSightは、AWSが提供するBIツールで、データの可視化や分析を簡単に行うことができるサービスです。QuickSightを利用開始する際には、以下のようにさまざまな方法があります。

• AWS IAMユーザー/ロールを使用したアクセス
• Microsoft Active Directory（AD）との連携
• QuickSight専用のユーザー管理（Eメールベース）
• SAML 2.0ベースのシングルサインオン（SSO）
• IAM Identity Center（旧AWS SSO）を使用したアクセス

これらのQuickSightを使う際のアクセス方法を正しく把握していないと、組織のルールから逸脱して利用が始まったり、思わぬコストが発生するおそれがあります。

今回はその中でも、題名にある通り、IAMを使用したアクセスのうち、自己プロビジョニング方式によるQuickSight利用開始時の権限設定について、私が経験した苦労を元に注意点をまとめてみました。

Amazon QuickSightのロールの種類

まず、Amazon QuickSightには、主に以下の3つのロールが存在します：

1. Reader（閲覧者）: 共有されたダッシュボードの閲覧のみが可能
2. Author（作成者）: ダッシュボードやビジュアルの作成・編集が可能
3. Admin（管理者）: QuickSightの管理機能全般にアクセスできる

これらのロールは、QuickSightの利用目的やユーザーの役割に応じて選択されます。たとえば、データ分析のみを行うユーザーにはReaderロール、ダッシュボード作成など可視化を行うユーザーにはAuthorロールが適しています。
また、AdminロールはQuickSightの設定や管理を行うための権限を持っているため、通常は限られたユーザーに付与されます。

さらに、下記の表のように各ロールによって、QuickSightの利用にかかるコストも異なります。たとえば、Readerロールは月額料金が安価ですが、ダッシュボード作成などができるAuthorロールは料金が増えます。したがって、ユーザーの役割に応じて適切なロールを選択することが重要です。

参考：料金 - Amazon QuickSight _ AWS（2025年5月参照）

IAMを使用したアクセスとは？

では、そういったそれぞれのQuickSightのユーザーはどのようにして作成するのでしょうか？

今回、テーマとしているIAMベースのアクセスに関して、AWS規範的ガイダンス（Prescriptive Guidance）に次のような記述があります。

You can grant access to QuickSight for IAM users by using either of the following options:

Direct invitation – You invite the IAM user to access QuickSight, and the user can accept the invitation through their email.

Self-provisioned access – You create an IAM policy that permits users to provision their own access. When a user accesses QuickSight for the first time, they are granted access and define the email address that will be associated with their QuickSight user record.

Granting QuickSight access to IAM users

IAMユーザーへのQuickSightアクセスを与える方法として、直接招待（Direct Invitation）と自己プロビジョニング（Self-provisioned Access）の2つの方法があることがわかります。

直接招待は、メールアドレスを通じた招待を行い、IAMユーザーを持った利用者がその招待を受け入れることでQuickSightにアクセスできるようになる方法です。利用開始時に、管理者がどのメンバーに対してQuickSightの利用を許可するかなどを制御しやすい一方で、ユーザーの数だけ招待を行う必要があり、管理者の手間がかかります。

一方で、自己プロビジョニングの方法は、IAMポリシーを作成しておくことで、IAMユーザーが自分自身でQuickSightの利用を開始できるようにする方法です。管理者はIAMポリシーを設定するだけで、あとはIAMユーザーが自分でQuickSightの利用を開始できるため、管理者の手間が省けます。
ただし、IAMポリシーを設定する際には、IAMユーザーがQuickSightの利用を開始するために必要な権限をきちんと設定しておく必要があります。

デモ：自己プロビジョニング方式でのQuickSight利用開始

その自己プロビジョニング方式は文字だけではわかりにくいので、実際に自己プロビジョニング方式でQuickSightを利用開始するための手順を見ていきましょう。

このデモの前提として初期設定済みのQuickSightアカウントが存在しているところに、作成者ユーザーとして新たに参加する利用者の目線で手順を紹介します。

ステップ0：初期段階

最初の段階のQuickSightの画面は以下のような状態です。管理者のQuickSightのユーザーしか存在していない状態からスタートです。

ステップ1：IAMユーザーの作成

まず、次のようなquicksight:CreateUserの権限を持ったIAMユーザーを作成します。
（実際の運用時には、適切に対象となるResourceを指定してください）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "quicksight:CreateUser"
            ],
            "Resource": "*"
        }
    ]
}

ステップ2：IAMユーザーでQuickSightにアクセス

上記のIAMユーザーでAWS Management Consoleにログインし、QuickSightのページにアクセスします。

ステップ3：メールアドレスの入力

QuickSightの画面が表示されます。ここで、IAMユーザーは自分のメールアドレスを入力するように求められます。

ステップ4：QuickSightのユーザー作成完了

[続行]をクリックし、画面が遷移して、Welcome画面が表示されれば、QuickSightのユーザー作成は完了です。

ステップ5：QuickSightのユーザー確認

管理者の画面からQuickSightのユーザーを確認すると、上記までの手順を踏んだIAMユーザーの名前でQuickSightのユーザーが、"Author"ロールで作成されていることがわかります。このユーザーのロールが、実際の操作可能範囲や課金額に直接関わってきます。

ロールごとに必要なIAMポリシーとは？

さて、quicksight:CreateUserのアクションの名前からして、最低限の権限を持った"Reader"のロールを持ったQuickSightのユーザーが作成されることを期待しがちですが、実際にはそうではなく"Author"ロールのQuickSightのユーザーが作成されました。

"Reader"ロールのユーザーが作られると想定していたのに、"Author"ロールのユーザーが作られてしまうと、月額料金も高くなってしまいますね。

このロールってどこで決まるのでしょうか？

実は、"quicksight:CreateUser"権限は、「QuickSightのユーザーを作成する権限」ではなく、「QuickSightの"Author"ロールを持つユーザーを作成する権限」です。
IAMユーザーがQuickSightを利用開始する際に、そのIAMユーザーが"quicksight:CreateUser"、"quicksight:CreateReader"、"quicksight:CreateAdmin" の中のどの権限を持っているかによって、作成されるQuickSightのユーザーのロールが決まります。

しかも、Reader < Author < Adminロールのうち、上位の権限が優先されるため、不必要に権限を付与しないようにすることが重要です。

表にまとめると、以下のようになります：

ロール決定の条件を図で表すと、次のようになります。

なお、下図のようにAuthorロールで作成されたQuickSightのユーザーをAdminロールに昇格させることは可能です。

さらに、Readerロールで作成されたQuickSightのユーザーも後から、Adminロールに昇格させることができます。

ただし、Author以上のロールに昇格したり、Author以上のロールで作成されたQuickSightのユーザーは、Readerロールにダウングレードすることができません。誤ってAuthor以上のロールで作成してしまった場合は該当のQuickSightのユーザーを削除して、再度Readerロールで作成し直す必要があります。

ロールの昇格・降格に関する関係を図で表すと、次のようになります。

不必要な上位ロールの権限をつけないようにすることが大切ですね。

まとめ

以上、IAMを使った自己プロビジョニング方式で、Amazon QuickSightを利用開始する際の権限設定の注意点についてでした。
改めて、ポイントは以下のとおりです。

• IAMを使った自己プロビジョニング方式でQuickSightを利用開始する際には、そのIAMが持っている権限によって、作成されるQuickSightのユーザーのロールが決まる
• quicksight:CreateUserの権限を持っていると、"Author"ロールのQuickSightのユーザーが作成される
• "CreateUser"という名前からは、QuickSightユーザー全般の作成に使えるように思えてしまうが、実際には"Author"ロール専用の作成権限である。Readerロールを作成する際にはquicksight:CreateReaderの権限が、Adminロールを作成する際にはquicksight:CreateAdminの権限があれば良く、"CreateUser"の権限は不要である。
• 複数の権限を持っている場合は、上位の権限が優先される（Reader < Author < Adminの優先順位）
• ReaderからAuthor以上のロールに昇格することはできるが、Author以上のロールからReaderロールにダウングレードすることはできない

ユーザー管理の利便性を考えると、IAMではなく他のID基盤と連携させた形での管理が望ましい場合もありますが、組織の状況に応じて、IAMを使った自己プロビジョニング方式でのQuickSight利用開始も選択肢の1つとして考えられます。

そうした場面で、ユーザーとロールの関係を理解する手助けとして、本記事がお役に立てば幸いです。

参考リンク

• Amazon QuickSightの料金ページ
  • 料金 - Amazon QuickSight _ AWS
• AWS規範的ガイダンス（Prescriptive Guidance）におけるIAMユーザーへのQuickSightアクセスの付与方法に関する解説ページ
  • Granting QuickSight access to IAM users
• QuickSightのユーザーを作成するために必要なIAMポリシーの例
  • IAM identity-based policies for Amazon QuickSight: creating users

sho