[アップデート] Amazon QuickSight が Athena データソースで IAM Identity Center の Trusted Identity Propagation (TIP) がサポートされました

[アップデート] Amazon QuickSight が Athena データソースで IAM Identity Center の Trusted Identity Propagation (TIP) がサポートされました

Clock Icon2025.07.14

いわさです。

2 週間前くらいのアップデートになるのですが、Amazon QuickSight で TIP (Trusted Identity Propagation) を有効化した Athena ワークグループもデータソースとして構成できるようになりました。

https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-quicksight-trusted-identity-propagation/

TIP (Trusted Identity Propagation) が馴染みの無い方もまだ多いと思うのですが、公式ドキュメントだと「信頼できる ID の伝播」などと訳されている機能で、IAM Identity Center の認証情報をコンテキストとして統合されたサービスへ伝播させることで、認可制御を行う際に利用できるサービスです。

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/trustedidentitypropagation-overview.html

ユースケースとして想定されているのは主にデータ分析周りのサービスで、Redshift、EMR Studio、Athena、S3 Access Grants、Lake Formation あたりがサポートされています。
特に、Auth0 や Microsoft Entra ID などの外部 ID 基盤を IAM Identity Center と統合した時に、そのユーザー情報を使って Lake Formation を中心にデータアクセス許可をコントロールできます。

EMR Studio → Athena の経路はこれまでもサポートされていたのですが、先日の冒頭のアップデートで QuickSight → Athena の経路もサポートされたみたいです。
今回こちらを設定して試してみたのでその様子を紹介します。

IAM Identity Center 統合した Athena ワークグループを用意する

流れとしてはまず IAM Identity Center を認証モードに設定した Athena ワークグループを用意し、QuickSight のデータソース指定時にそのワークグループを指定する形です。
ということでまずは Athena のワークグループを用意しましょう。
注意点として QuickSight の前提条件として IAM Identity Center インスタンス、Athena ワークグループ、Lake Formation、S3 Access Grants で同じ AWS リージョンを使う必要があります。私は東京リージョンを使いました。

ワークグループの認証情報は作成後に変更は出来ないので、IAM Identity Center 用に新しいワークグループを新規作成する必要があります。
認証情報に IAM か、IAM Identity Center を選択できるので後者を選択します。

6A7C3B68-E5D2-4FEE-BC74-B7EBFE805603_1_105_c.jpeg

IAM Identity Center を使う場合は S3 Access Grants も自動で有効化されます。
Athena を使う IAM Identity Center ユーザーが S3 Access Grants でのロケーションやオブジェクトへのアクセス許可を得ている必要があります。

9E63FAFE-9248-4C2B-B2E6-52A1587642EC_1_105_c.jpeg

ここでの注意点としては、本日時点では日本語コンソールだとワークグループの作成に失敗するので日本語から英語に一度切り替えてから試しましょう。

https://dev.classmethod.jp/articles/athena-idc-create-workgroup/

そしてワークグループにユーザーを割り当てしておきます。

96871C6D-513C-48E2-8C71-1D094299E102_1_105_c.jpeg

ちなみに IAM Identity Center 認証のワークグループは通常の Athena コンソールのクエリエディタから選択は出来ません。
EMR Studio あるいは QuicKSight などのクライアントサービスと併用して使う感じになります。

ED6D5678-B6D3-43F3-8449-F7ABB1BF45A5.png

Athena ワークグループとあわせて S3 Access Granjts にも IAM Identity Center インスタンスの割り当てやロケーションの作成などを済ませておきましょう。

C772F0E9-D90F-40B8-88D8-1192D7DFD8CB_1_105_c.jpeg

1FE9FF03-1768-45E2-BF5F-6A4E84AD041D.png

IAM Identity Center 統合した QuickSight を用意する

続いて QuickSight を設定していきます。
この機能を使う前提条件なのですが QuickSight の認証モードは IAM Identity Center で作成しておく必要があります。

https://dev.classmethod.jp/articles/iam-identity-center-integration-quicksight/

事前に QuickSight 用のサービスロールを作成しておきます。ポイントとしてはsts:SetContextを信頼ポリシーに追加する必要があります。
このロールは Athena に対してのアクセスポリシーも必要です。

{ 
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "QuickSightandAthenaTrust",
            "Effect": "Allow",
            "Principal": {
                "Service": "quicksight.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetContext"
            ]
        }
    ]
}

作成後、QuickSight の管理機能からサービスロールとして指定します。

2D11C67F-E6CB-49C0-B04F-4439D7AF54E4.png

続いて QuickSight の API を使って ID 伝播設定を有効にする必要があります。(QuickSight アカウント上の共通設定)
指定する情報としては先ほどの Athena ワークグループのアプリケーション ARN です。

B576D6F9-FF45-4843-BE0C-F453C0D74A77_1_105_c.jpeg

% cat hoge.json
{
    "AwsAccountId": "123456789012",
    "Service": "ATHENA",
    "AuthorizedTargets": [
        "arn:aws:sso::123456789012:application/ssoins-7758571eb0e448d1/apl-42d3fe9e68e7c940"
    ]
}
% aws quicksight update-identity-propagation-config --cli-input-json file://hoge.json --profile hogeadmin
{
    "Status": 200,
    "RequestId": "5a28612e-1a8e-42c3-8de1-f994f6aea862"
}

その後 Athena データソースを新規作成します。
作成の際に IAM Identity Center 認証のワークグループを選択できるはずです。

824A6157-D251-41C3-BB4C-1DA2C3F560E9.png

ここからがちょっと苦労するのですが、少しの設定不備で様々な検証エラー、クエリプレビュー画面でのエラーが発生します。
データアクセスのベースに Lake Formation が使われているのでかなりこのあたりは厳格で、エラーメッセージごとの解決策などはまた別途紹介したいと思います。
ひととおり権限周りの問題が解決していれば次のように接続テストに成功するはずです。

C0CB1C72-9611-4DC2-AB42-98368F07BFE2.png

その後は通常のデータセットと扱いは同じなのですが重要な注意事項がありまして、この方法を使うデータセットはダイレクトクエリのみで SPICE モードが使えません。
また、カスタムクエリや閾値アラート、電子メールレポート、Q in QuickSight 機能、各種エクスポート機能など様々な機能が無効になります。
ここは結構大きな制限事項なので注意しましょう。詳細は以下に記載されています。

https://docs.aws.amazon.com/quicksight/latest/user/athena-trusted-identity-propagation.html

データセットのモードでは次のように表示されていました。

685573CA-F50F-46A6-99D3-9576CDD18003.png

ダッシュボードを表示

ではデータセットが用意できたので分析・ダッシュボードでどのように表示されるのかを確認してみましょう。
ダッシュボードを閲覧する IAM Identity Center ユーザーに特にデータ行・列の表示制限をしていない場合は次のような感じです。

image.png

基本的にこの機能を使う場合は Lake Formation で権限制御をするのですが、ここで Lake Formation のデータフィルター機能を使った Row-Level Security を実装してみましょう。

B5ADE5DF-7956-4BC9-B4CA-3D858B2DAD9A_4_5005_c.jpeg

0A0A0AA6-F685-4C69-8A81-2A44B25C698A_4_5005_c.jpeg

設定後、次のようにアクセス可能な行のみが表示されることを確認しました。QuickSight 側にも RLS 機能はありますが、Lake Formation 側で実装できる感じですね。なるほど。

F4FC1005-BF8E-4122-9CE0-667F2B2C0E81_4_5005_c.jpeg

さいごに

本日は Amazon QuickSight が Athena データソースで IAM Identity Center の Trusted Identity Propagation (TIP) がサポートされたので使ってみました。

IAM Identity Center の認証情報と Lake Formation でかなり細かく権限制御が出来るので、そういったユースケースでは採用出来そうです。
ただし、様々な機能が制限されるので採用は慎重に行う必要がありそうです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.