WebアプリケーションにQuickSightダッシュボードを埋め込むことについて考える

mon
12 時間前
読了時間: 5分

Amazon QuickSight では、ダッシュボードを外部のWebページやアプリケーションに埋め込む機能が提供されています。

本記事では、埋め込み方式の比較と、実際に「認証付き埋め込み」を用いた検証手順を紹介します。（実装は次の記事）

QuickSightの埋め込み方式とは？

QuickSight には、以下の2つの埋め込み方式があります：

方式	特徴	適用例
匿名埋め込み	誰でもアクセス可能（認証不要）	公開ダッシュボード、社外KPI表示
認証付き埋め込み	QuickSight登録ユーザーのみアクセス可能	社内BI、顧客ごとのデータ表示

本記事では認証付き埋め込みに絞って、具体的な設定と表示方法を検証します。

認証付き埋め込みの仕組み

認証付き埋め込みは、QuickSight に登録されているユーザーごとに埋め込み表示を制御できる仕組みです。埋め込みURLは API を通じて発行され、iframe に埋め込むことでWebアプリに統合可能です。

必須条件：QuickSight Enterprise Edition
利用API：GenerateEmbedUrlForRegisteredUser
ライセンス：Reader または Author ライセンスのユーザー

実装の概要

1. QuickSight ユーザーとダッシュボードを準備

QuickSight にログインし、対象のダッシュボードを作成または共有します。
表示対象のユーザー（Readerライセンス）を QuickSight に追加します。

2. IAMロールとポリシーの設定

埋め込みURLを生成するアプリケーションには、以下のようなIAMポリシーを付与します：

{
  "Effect": "Allow",
  "Action": [
    "quicksight:GenerateEmbedUrlForRegisteredUser"
  ],
  "Resource": "*"
}

IAMロールの信頼ポリシーでは、APIを実行するLambdaやアプリケーションが AssumeRole できるように設定します。

埋め込みURLの生成（Pythonスクリプト）

boto3 を使って埋め込みURLを生成するPythonコード例：

import boto3

client = boto3.client('quicksight')
response = client.generate_embed_url_for_registered_user(
    AwsAccountId='123456789012',
    SessionLifetimeInMinutes=60,
    UserArn='arn:aws:quicksight:ap-northeast-1:123456789012:user/default/alice',
    ExperienceConfiguration={
        'Dashboard': {
            'InitialDashboardId': 'your-dashboard-id'
        }
    }
)
print(response['EmbedUrl'])

HTMLページへの埋め込み

取得したURLをiframeに差し込むだけで表示が可能です。

<iframe
  width="100%"
  height="600"
  src="https://quicksight.aws.amazon.com/sn/embed/..."
  frameborder="0"
  allowfullscreen>
</iframe>

ブラウザで表示すると、QuickSight にログイン済みのユーザーとしてダッシュボードが表示されます。

埋め込みURLを生成するIAMとQuickSightユーザーの関係

ここで一つ重要な疑問が生じます：

「GenerateEmbedUrlForRegisteredUser を呼び出す IAM ユーザーの権限で QuickSight のアクセスも制御されるのか？」

答え：いいえ。QuickSight のアクセス制御は、埋め込み対象の QuickSight ユーザーの権限によって行われます。

API を実行する IAM ユーザー／ロールは、あくまで「埋め込みURLを発行する役割」です。

実際にダッシュボードを表示するユーザーのアクセス制御（共有設定やRLSなど）は、UserArn で指定した QuickSight ユーザーの権限に基づいて評価されます。

例

UserArn = arn:aws:quicksight:ap-northeast-1:123456789012:user/default/alice

この場合：

IAM は「alice のためのURL」を生成するだけ
表示時に適用されるアクセス制御やフィルタは、QuickSight 内の alice さんのロール・設定によって決定されます

QuickSight の埋め込みURLと S3 の Pre-signed URL の類似性

QuickSight の GenerateEmbedUrlForRegisteredUser は、アクセス対象の QuickSight ユーザーのセッションを代理で生成する仕組みです。この構造は、S3 の Pre-signed URL（署名付きURL） によく似ています。

比較項目	QuickSight Embed URL	S3 Pre-signed URL
発行者	IAMユーザー／IAMロール	IAMユーザー／IAMロール
対象	QuickSight ユーザー（UserArn）	S3 オブジェクト（バケット＋キー）
有効期限	最大 600 分（SessionLifetimeInMinutes）	最大 7 日（Expires）
アクセス権の適用先	QuickSight ユーザーの共有設定やRLS	URLに署名が含まれている
アクセスの実行者	ブラウザ埋め込み先で動作するQuickSightセッション	URLにアクセスするクライアント
主な用途	ダッシュボード埋め込み	ファイルの一時公開や一時アップロード

類似のポイント

IAM がアクセス主体の代わりに「限定されたセッション」を発行
URL 自体にアクセス資格情報が埋め込まれている
有効期限つきで安全にアクセス制御できる

相違点（補足）

QuickSight はビューアーを含んだUI付きの表示が主目的
S3 は純粋なリソース（バイナリやJSONなど）の一時公開

Webアプリケーションのユーザーと QuickSight ユーザーの突き合わせはどうする？

ここで重要なセキュリティ上の観点として、次の疑問が生まれます：

「Webアプリにログインしているユーザーが、埋め込み対象の QuickSight ユーザーと一致しているかどうかは、どう検証するのか？」

結論：

GenerateEmbedUrlForRegisteredUser は、指定された UserArn に対してセッションを発行するだけで、

「そのセッションを発行してよいユーザーなのか」の検証はアプリケーション側の責任です。

Webアプリ側で実装すべきこと

Webアプリでユーザー認証を行い、「これは QuickSight ユーザー alice である」と確定する
- 例：Cognito / IAM Identity Center / JWT トークンなど
確定したユーザーに対応する UserArn を特定する
その UserArn を使って GenerateEmbedUrlForRegisteredUser を呼び出す

このステップを飛ばして、ユーザーの入力値などをそのまま使うと、他人の QuickSight セッションを取得できる脆弱な実装になってしまいます。

QuickSight埋め込みにおける「ユーザーと権限の結びつけ」の課題と、S3 Pre-signed URLとの比較

前セクションの課題を踏まえて、再びS3 の Pre-signed URLと比較してみます。

観点	S3 Pre-signed URL	QuickSight 認証付き埋め込み
認証ユーザーと権限の結合	IAM Role を Assume した認証済ユーザーが署名URLを使う	Webアプリ側で QuickSight ユーザーへのマッピングが必要
アクセス主体	実行中の IAM ロール（例：Cognito 連携ロール）	UserArn で指定された QuickSight ユーザー
URL発行に必要なもの	IAM Role + 対象オブジェクト情報	IAM Role + QuickSight UserArn + DashboardId 等
信頼性の担保	IAM Policy / TrustPolicy により制御	アプリケーション側のマッピングロジックに依存
Webアプリとアクセス権の一体性	高い（認証がそのまま権限に）	低い（マッピングが必要）

結論

QuickSight 埋め込みでは、CognitoユーザーにIAM RoleをAssumeさせてQuickSightアクセスを自動的に制御することはできません。

アプリケーションが「ログインユーザー ↔ QuickSightユーザー」の関係を正しく持ち、責任を持って UserArn を決定する必要があります。

この設計の違いを理解したうえで、安全かつ柔軟な埋め込みアーキテクチャを構築することが重要です。

まとめ

GenerateEmbedUrlForRegisteredUser 自体にはユーザー認証機能はありません
誰が誰のセッションを使うかを判定・制御するのは、アプリケーションの責任
安全に運用するには、アプリ側でログインユーザー情報と QuickSight ユーザーのマッピングを厳格に管理する必要があります

以上を踏まえて、次の記事では簡単なアプリケーションを作って確認してみたいと思います。