[アップデート] QuickSight で IAM 権限を持たないユーザーでもカスタムアクセス許可(制限)が設定できるようになっていました
コーヒーが好きな emi です。
QuickSight で IAM 権限を持たないユーザーでもカスタムアクセス許可(制限)が設定できるようになっていましたので、試してみました。
- 経緯
2024/11/20 に、以下のように IAM Identity Center(以降 IdC と省略)による認証を行っている QuickSight アカウントで、カスタムアクセス許可設定を行う API が提供されたというアップデートがありました。
これに付随して API アップデートを見ると、どうやら IAM 権限を持たない QuickSight ユーザーに対してもカスタムアクセス許可ができるようになったようです。
以前までは制御される QuickSight ユーザーに IAM 権限が必要だったのですが、それが無くなったというアップデートです。
update-user-custom-permission コマンドを使うと IAM 権限のない QuickSight ユーザーでもカスタムアクセス許可(制限)できそうです。
カスタムアクセス許可(制限)とは
QuickSight では以下のようなロールが 6 種類用意されており、アセットに対して実行できるアクションを制限できます。
1 | Admin | 管理者 | QuickSight ユーザーとアカウントレベルの設定を管理し、アカウントの SPICE キャパシティーと年間サブスクリプションを購入できるユーザー。QuickSight のすべての作成機能を利用でき、必要に応じてアカウントを Standard Edition から Enterprise Edition にアップグレードできる。 請求上、QuickSight の作成者と管理者はどちらも「作成者」として認識される。 |
2 | Author | 作成者 | データソースへの接続、分析の作成、ダッシュボードの作成ができるユーザー。パラメータや計算フィールドといった QuickSight の高度な機能を利用してインタラクティブなダッシュボードを作成し、ダッシュボードをアカウント内の別のユーザーに公開できる。 |
3 | Reader | 閲覧者 | インタラクティブなダッシュボードを利用するユーザー。ウェブブラウザやモバイルアプリケーションから共有されたダッシュボードの閲覧、データのフィルタリング、詳細情報へのドリルダウン、CSV ファイルでのデータエクスポートを行う。閲覧者には SPICE 容量は割り当てられない。 |
4 | Admin Pro | 管理者プロ | 管理者のすべての機能が含まれているほか、自然言語によるダッシュボードの構築、Q トピックの作成、エグゼクティブダッシュボードの概要、生成データストーリーの構築と共有の機能を含む Amazon Q の生成 BI が追加されている。 |
5 | Author Pro | 著者プロ | 作成者のすべての機能が含まれているほか、自然言語によるダッシュボードの構築、Q トピックの作成、エグゼクティブダッシュボードの概要、生成データストーリーの構築と共有の機能を含む Amazon Q の生成 BI が追加されている。 |
6 | Reader Pro | リーダープロ | 閲覧者のすべての機能に加え、エグゼクティブダッシュボードの概要や生成データストーリーを構築および共有する機能など、Amazon Q の生成 BI 機能が含まれる。 |
上記の 6 種類の権限セット以外に、もっと詳細に権限をカスタマイズしたカスタム許可プロファイルを作成することができます。これは、あらかじめ提供されている 6 種類の権限セットから、「この操作はさせない」という「拒否」を設定する仕様になっています。
以前までは制御される QuickSight ユーザーに IAM 権限が必要だったのですが、それが無くなりました。
検証イメージ
検証が終わると以下のような構成になります。
1. IAM 権限を持たない QuickSight ユーザー向けのカスタムアクセス許可(制限)設定
では検証していきます。操作自体は IAM 権限と管理者(Admin)権限を持つユーザーを使用します。
まずは IAM 権限を持たない QuickSght ユーザー「test」を作成します。
ユーザーの作成方法は以下ブログも参考にしてください。
[QuickSight の管理] - [ユーザーを管理] - [アクセス許可を管理] と進みます。
カスタム許可プロファイル(custom permissions profile)を作成します。
名前を付け、ユーザーに実施させたくない(制限したい)アクションにチェック します。
今回は「restrict-datasets」という名前を付け、以下のチェックを付けてみました。チェックしたアクションができなくなる想定です。
- Datasets
- Creating or updating all datasets(すべてのデータセットの作成または更新)
- Data sources
- Creating or updating all data sources(すべてのデータソースの作成または更新)
- Viewing account SPICE capacity(アカウントの SPICE キャパシティの表示)
カスタム許可プロファイル(custom permissions profile)を作成できたら、update-user-custom-permission コマンドでユーザーのカスタム権限を更新します。この操作は現在 API でしかできないので、IAM 権限を持つ管理者(Admin)ユーザーで CloudShell から AWS CLI を実行します。
実行コマンド
aws quicksight update-user-custom-permission \
--user-name test \
--aws-account-id 123456789012 \
--namespace default \
--custom-permissions-name restrict-datasets
▼実行結果
[cloudshell-user@ip-10-134-6-193 ~]$ aws quicksight update-user-custom-permission \
> --user-name test \
> --aws-account-id 123456789012 \
> --namespace default \
> --custom-permissions-name restrict-datasets
{
"Status": 200,
"RequestId": "db8a1adc-374d-4196-9e5e-b6f8b708cbef"
}
[cloudshell-user@ip-10-134-6-193 ~]$
実行すると、以下のように「アクセス許可」欄に作成したカスタム許可プロファイル「restrict-datasets」が表示されるようになりました。
カスタム許可プロファイルを付与した「test」ユーザーでデータセット画面を見ると、「新しいデータセット」ボタンがありません。ユーザー情報を表示していると隠れて見えにくいのですが、ないです。
ちゃんと制御できています。
2. カスタムアクセス許可(制限)をロールごとに一括設定する際も IAM 権限は不要なのか
以下はおまけの検証です。
冒頭で示した通り、QuickSight には 6 種類のロールがあらかじめ用意されています。この あらかじめ用意されているロール自体の権限をカスタマイズできる機能 がちょうど 1 年ほど前にリリースされています。
この、あらかじめ用意されているロールの権限をカスタマイズする際も IAM 権限が必要なのか?と気になったので、試してみます。
まずは IAM 権限のない QuickSight ユーザー「test2」を作成します。作成者(Author)ロールを付与しました。
作成した「test2」ユーザーでログインすると、こんな感じで、「新しいデータセット」ボタンが見えています。
では、カスタム許可プロファイル(custom permissions profile)を作成します。
「restrict-datasets2」という名前を付け、以下のチェックを付けてみました。
- Datasets
- Creating or updating all datasets(すべてのデータセットの作成または更新)
- Data sources
- Creating or updating all data sources(すべてのデータソースの作成または更新)
作成できました。
カスタム許可プロファイル(custom permissions profile)を作成できたら、update-role-custom-permission コマンドで作成者(Author)ロールにカスタムアクセス許可(制限)を付与します。
実行コマンド
aws quicksight update-role-custom-permission \
--custom-permissions-name restrict-datasets2 \
--role AUTHOR \
--aws-account-id 123456789012 \
--namespace default
▼実行結果
[cloudshell-user@ip-10-134-6-193 ~]$ aws quicksight update-role-custom-permission \
> --custom-permissions-name restrict-datasets2 \
> --role AUTHOR \
> --aws-account-id 123456789012 \
> --namespace default
{
"RequestId": "f3abf087-e4f2-4582-b5f0-b0ac402a6e74",
"Status": 200
}
[cloudshell-user@ip-10-134-6-193 ~]$
作成者(Autor)ロールにカスタムアクセス許可(制限)を付与できました。確認コマンドで確認します。
aws quicksight describe-role-custom-permission \
--role AUTHOR \
--aws-account-id 123456789012 \
--namespace default
▼実行結果
[cloudshell-user@ip-10-134-6-193 ~]$ aws quicksight describe-role-custom-permission \
> --role AUTHOR \
> --aws-account-id 123456789012 \
> --namespace default
{
"CustomPermissionsName": "restrict-datasets2",
"RequestId": "2ac7546e-ba85-4866-9823-2bb8e3b1beda",
"Status": 200
}
[cloudshell-user@ip-10-134-6-193 ~]$
AUTHOR
ロールにカスタム許可プロファイル restrict-datasets2
が付与されていることが確認できました。
QuickSight 画面から見ると、「アクセス許可」欄には特に反映されないようです。
「test2」ユーザーでデータセット画面を見ると、「新しいデータセット」ボタンがありません。ちゃんと制御できています。
2-2. もう 1 つ作成者(Author)ユーザーを作成してみる
もう 1 つ作成者(Author)ユーザーを作成し、作成者(Author)ロール全体がカスタマイズされた権限になっているのか確認してみます。
「test3」ユーザーを作成者(Author)ロールで IAM 権限なしで作成します。
「test3」ユーザーでデータセット画面を見ると、「新しいデータセット」ボタンがありません。ちゃんと制御されています。
ユーザーレベルのカスタムアクセス許可(制限)は、ロールのデフォルト権限またはロールレベルのカスタムアクセス許可(制限)をオーバーライドする
ユーザーレベルのカスタムアクセス許可(制限)は、ロールのデフォルト権限またはロールレベルのカスタムアクセス許可(制限)をオーバーライドします。ユーザー個別に割り当てた権限が一番強いというわけです。
ユーザーレベルのカスタム許可は、指定されたユーザーについてのロールの既存のデフォルト、またはカスタムロールレベルの許可をオ
ーバーライドします。
Amazon QuickSight コンソールへのアクセスのカスタマイズ - Amazon QuickSight
参考