Amazon Quick、ユーザー別カスタム権限の自動化機能を発表

Amazon Quick の環境が拡大し、AI 機能を備えた新機能がユーザーの活用範囲を広げる中で、「最小権限の原則」を維持するためには、ユーザーレベルのカスタム権限を自動化することが不可欠です。これに対応すべく、Quick では カスタム権限 を提供しています。これを使えば、特定の機能をオン・オフに切り替えることで、個々のユーザーに対してきめ細かいアクセス制御を適用できます。

例えば、財務アナリストにはレポート作成は許可しつつ、生データの出力は禁止したり、外部パートナーにはダッシュボードの閲覧は許可するが、共有設定へのアクセスは制限したりといった制御が可能です。

Quick ではアカウントレベル、ロールレベル、ユーザーレベルでカスタム権限を適用する複数のオプションがありますが、組織固有の権限を動的に適用したいケースも存在します。本記事では、ユーザーライフサイクルの主要な段階においてカスタム権限の割り当てを自動化するための 4 つのアーキテクチャパターンを紹介します。アプローチは、単一の API パラメータからイベント駆動型の自動化まで多岐にわたり、新規ユーザー、将来のユーザー、グループベースのロジック、遡及的な一括更新といったシナリオをカバーします。

本記事で取り上げる内容

ここでは、ユーザーライフサイクルの主要な段階に対応する 4 つのシナリオを紹介します。

• 未登録ユーザー: カスタムポータルやスクリプトを構築している場合、RegisterUser API を使用して、ユーザー作成の瞬間にプロアクティブにカスタム権限を適用する方法をご紹介します。

アカウントまたはロールレベルでのデフォルトのカスタム権限を設定するには、UpdateAccountCustomPermission および UpdateRoleCustomPermission API を使用して、既存および将来のすべてのユーザーに対してデフォルトのプロファイルを適用する方法を解説します。これにより、追加の自動化は不要です。

ネイティブのデフォルトを超える条件付きロジック（例：グループ所属に基づいて異なるプロファイルを適用する）が必要な場合は、Amazon EventBridge と AWS Lambda を使用して、新しいグループ所属を自動的に検出し、権限を動的に適用する方法を紹介します。これは、Quick 固有のグループと AWS IAM Identity Center (IDC) グループの両方をサポートしています。

自動化が導入される前にプロビジョニングされた既存ユーザーに対しては、指定した Quick グループ内のすべてのユーザーにカスタム権限を遡及的に適用するための堅牢な Python スクリプトを提供します。

シナリオ 1: 事前登録済みユーザー（API および CLI）

RegisterUser API を使用してユーザーをプロビジョニングするカスタムオンボーディングポータルをお持ちの場合、複雑な自動化は不要です。Quick ユーザー作成時に --custom-permissions-name パラメータを含めることで、カスタム権限を適用できます。

このアプローチが適しているケース：組織がカスタムポータルやスクリプトを通じて、ユーザー作成プロセスをエンドツーエンドで管理している場合です。イベント駆動型のインフラは不要で、最も直接的な方法となります。特に、顧客アカウント全体に Amazon QuickSight を組み込む SaaS 企業において一般的な手法です。例えば、各ユーザーがプロビジョニングされる瞬間に、顧客の価格プランに基づいてページネーション付きレポートや GenBI のようなプレミアム機能へのアクセスを自動的に制限するケースなどが該当します。

以下の例では、「Restricted-Author-Profile」という名前のカスタム権限プロファイルをアカウント内の「Author」ロールに適用していますが、同様の API を使用すれば、「Author Pro」「Admin」「Admin Pro」「Reader」「Reader Pro」など、あらゆるロールに対して権限プロファイルを適用することが可能です。

aws quicksight register-user \
    --aws-account-id 123456789012 \
    --namespace default \
    --identity-type QUICKSIGHT \
    --user-role AUTHOR \
    --email user@example.com \
    --user-name user_name \
    --custom-permissions-name "Restricted-Author-Profile"

シナリオ 2：デフォルトのアカウントまたはロールの権限（API および CLI）

ネイティブな API を 2 つ利用すれば、ユーザーごとの自動化を行わずに、デフォルトのカスタム権限プロファイルを設定できます。なお、QuickSight のカスタム権限は「アカウント」「ロール」「ユーザー」の 3 レベル階層構造に従っており、ユーザーレベルの設定がロールレベルを優先し、さらにそれがアカウントレベルを優先します。これにより、管理者は柔軟で多層的なセキュリティポリシーを実装することが可能になります。

allowing administrators to implement flexible, layered security policies

このアプローチを採用すべきタイミング

本 API は、現在のユースケースだけでなく将来の要件にも対応し、運用オーバーヘッドを最小限に抑えることができます。カスタム自動化を構築する前に、まずはここから始めることを推奨します。アカウントレベルやロールレベルのデフォルトでは対応できない条件付きロジックが必要な場合に限り、シナリオ 3 へ移行してください。

例えば、50,000 ユーザー規模のエンタープライズ環境では、セキュリティチームによる 60〜90 日間のレビューが完了するまで、新しく立ち上がった GenBI の機能やコネクタをデフォルトでブロックしておく必要がある場合があります。アカウントレベルでのデフォルト設定を適用すれば、個々のユーザーごとの自動化が必要なく、プロビジョニングの隙間も生じさせることなく、この制限を即座に強制できます。

オプション A: アカウントレベルのデフォルト

UpdateAccountCustomPermission API を使用すると、明示的なプロファイルが割り当てられていないユーザー（Just-In-Time プロビジョニングで新規作成されたユーザーを含む）に対して、QuickSight が適用するフォールバック用のカスタム権限プロファイルを設定できます。

aws quicksight update-account-custom-permission \
    --aws-account-id 123456789012 \
    --custom-permissions-name "Restricted-User-Profile"

オプション B: ロールレベルのデフォルト

UpdateRoleCustomPermission API を利用すれば、QuickSight の各ロール（READER, AUTHOR, ADMIN, PRO）ごとにデフォルトのカスタム権限プロファイルを設定することが可能です。

aws quicksight update-role-custom-permission \
    --aws-account-id 123456789012 \
    --role AUTHOR \
    --namespace default \
    --custom-permissions-name "Restricted-Author-Profile"

シナリオ 3: イベント駆動型のカスタムロジック (Amazon EventBridge と Lambda)

このシナリオは、より細粒度な要件に対応するものです。具体的には、Quick や IAM Identity Center のどのグループに所属するかによって、ユーザーごとに異なるカスタム権限プロファイルを適用するというケースです。

例えば、12 万 5000 人の従業員を抱えるテクノロジーサービス企業では、各事業部の作成者がグループ割当の瞬間に固有の権限プロファイルを受け取る必要があります。これにより、すべての作成者が同じ Quick ロールを共有しているにもかかわらず、承認された個人に対してのみパワーユーザーへのアクセス権を付与しつつ、事業部間の資産共有を防ぐことが可能になります。

ただし、グループに対してカスタム権限を割り当てるネイティブ API が存在しないため、特定の権限を持つべきグループにユーザーが追加されたことを検知するアーキテクチャが必要です。

注記：完全な階層化された権限戦略を実現するには、このアプローチをシナリオ 2 と組み合わせることを推奨します。 シナリオ 2 と 3 は互いに排他的なものではなく、補完関係にあります。ユーザーが即時フェデレーション（Just-In-Time federation）を通じてプロビジョニングされる場合、アカウント作成から管理者が適切なグループに追加するまでの間に、避けられない時間的ギャップが生じます。シナリオ 3 はあくまでグループメンバーシップイベントが発生した際にトリガーされる仕組みです。

ユーザーが制限のない状態に置かれることを防ぐためには、まずシナリオ 2 を適用してベースラインを確立してください。具体的には、アカウントレベルまたはロールレベルで最も厳格な許容プロファイルを強制するデフォルト設定を行います。その後、ユーザーがグループに割り当てられたら、シナリオ 3 を用いて権限を微調整します。シナリオ 3 で定義されるユーザーレベルのオーバーライドは、シナリオ 2 のデフォルト設定よりも優先されます。したがって、競合は発生せず、制御層が補完的に機能することになります。

20万人以上のユーザーをシングルサインオン（SSO）経由で管理するグローバル銀行を想定してください。同社では、従業員が入社した瞬間にデータのエクスポートをブロックする必要があります。シナリオ 2 では制限的なアカウントレベルのデフォルト設定によりこのギャップを即座に解消し、シナリオ 3 ではユーザーがコンプライアンスグループに割り当てられた後に権限を細かく調整します。これにより、プロビジョニング完了からグループ割当までの間に従業員が機密性の高い顧客データをダウンロードするリスクを防ぐことができます。

Amazon Quick と IAM Identity Center は、グループメンバーシップの変更に対してそれぞれ異なる AWS CloudTrail イベントを出力します。Quick では、ユーザーが追加されると「CreateGroupMembership」が、削除されると「DeleteGroupMembership」が生成されます。

IAM Identity Center では、ユーザーがグループに追加された際に「AddMemberToGroup」イベントが発生し、削除された際には「RemoveMemberFromGroup」イベントが発生します。以下のアーキテクチャではこれらのイベントを検知して、権限の更新を自動的にトリガーする仕組みとなっています。

この仕組みは、イベントの検出に Amazon EventBridge を、修正処理の実行に AWS Lambda を使用して構築します。

図 1: ユーザーが Quick や IAM Identity Center のグループに追加された際に、カスタム権限プロファイル適用を行うイベント駆動型アーキテクチャ

• ユーザーが Quick または Identity Center のグループに追加される。
• Amazon CloudTrail: CreateGroupMembership イベントまたは AddMemberToGroup イベントをキャプチャする。
• Amazon EventBridge: これらのログをフィルタリングし、ユーザーがグループに正常に追加されたタイミングを検出する。
• AWS Lambda: ユーザーの詳細情報を抽出し、UpdateUserCustomPermission API を使用して適切な権限プロファイルを適用する。

事前準備

本ソリューションを実装する前に、以下の条件を満たしていることを確認してください。

• 管理者権限を持つ AWS アカウント。
• AWS CloudFormation を使用して AWS リソースの作成および管理を行うための AWS Identity and Access Management (IAM) 権限。
• 以下の AWS サービスへのアクセス権:
• AWS CloudFormation: インフラストラクチャスタックをコードとしてデプロイおよび管理する。
• Amazon Quick: カスタム権限が適用される対象サービス。
• Amazon CloudTrail: ターゲットの AWS リージョンで有効化されていること。Amazon EventBridge が消費する Quick および IDC の API イベントをキャプチャする。
• Amazon EventBridge: CloudTrail イベントをフィルタリングし、グループメンバーシップの変更を検出する。

• AWS Lambda：UpdateUserCustomPermission API を呼び出して自動化ロジックを実行します。

• AWS IAM Identity Center：IDC グループベースのトリガーを使用する場合のみ必要です。

• シナリオ 4 でバッチ更新スクリプトを実行するには、Python 3.9 以上と AWS Command Line Interface (AWS CLI) v2 が必要です。

CloudFormation でデプロイする

提供された CloudFormation テンプレートを使用すれば、IAM ロール、Lambda 関数、Amazon EventBridge ルールを含むパイプライン全体をデプロイできます。Amazon EventBridge ルールは自身のリージョン内のイベントのみを取得するため、CloudFormation スタックは Amazon Quick のサブスクリプションと同じ AWS リージョンにデプロイする必要があります。

テンプレートでは以下のパラメータを受け付けます：

手動でデプロイする場合は、以下の手順に従ってください。

ステップ 1: Lambda 用の IAM ロールを作成する

Lambda 関数が Quick と通信するには、適切な権限が必要です。

• IAM コンソールにアクセスし、ポリシー → ポリシーの作成を選択します。
• JSONタブに切り替え、以下のポリシーを貼り付けます。注: IdentityStore への権限は、Quick アカウントが IAM Identity Center と連携している場合にのみ必要です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:YOUR_ACCOUNT_ID:log-group:/aws/lambda/Auto-Assign-QS-Permissions:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "quicksight:UpdateUserCustomPermission",
                "quicksight:DeleteUserCustomPermission",
                "quicksight:UpdateUser",
                "quicksight:DescribeUser"
            ],
            "Resource": "arn:aws:quicksight:*:*:user/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "identitystore:DescribeUser",
                "identitystore:DescribeGroup"
            ],
            "Resource": "*"
        }
    ]
}

• ポリシー名を Quick-Lambda-Policy に設定し、ポリシーの作成をクリックします。
• ロール → ロールの作成へ移動します。
• AWS サービスを選択し、Lambdaを選びます。
• 次へをクリックします。
• 検索ボックスで Quick-Lambda-Policy を入力して選択します。
• 次へをクリックします。

ロール名を Quick-Auto-Permissions-Role に設定し、Create role を選択します。

ステップ 2: Lambda 関数のデプロイ

Lambda コンソール にアクセスして Create function をクリックしてください。

• Function name: Auto-Assign-QS-Permissions
• Runtime: Python 3.14（または利用可能な最新バージョン）
• Execution role: 他のロールを使用 → Quick-Auto-Permissions-Role を選択
• Create function をクリックして作成します。

Configuration の General configuration で、タイムアウトを 30 秒に延長してください。単一イベントの処理であればこの設定で十分です。もし Amazon CloudWatch Logs でタイムアウトが発生する場合は、その値に応じて増やしてください。

次に、Configuration → Environment Variables で以下の環境変数を設定します。

Code Source エディタに戻り、以下のコードを貼り付けてください。

import logging
import os
import time
import boto3

logger = logging.getLogger()
logger.setLevel(logging.INFO)

quicksight = boto3.client("quicksight")
identity_store = boto3.client("identitystore")

def lambda_handler(event, context):
    detail = event.get("detail", {})
    event_source = detail.get("eventSource", "")
    event_name = detail.get("eventName", "")
    permission_profile = os.environ["PERMISSION_PROFILE"]
    target_group = os.environ["TARGET_GROUP_NAME"]
    namespace = os.environ["NAMESPACE"]

account_id = (
        detail.get("userIdentity", {}).get("accountId")
        or detail.get("recipientAccountId")
    )

logger.info(
        "Event received: source=%s, name=%s", event_source, event_name
    )

try:
        if event_source == "sso-directory.amazonaws.com":
            return handle_idc_event(detail, account_id, namespace, permission_profile, target_group)
        elif event_source == "quicksight.amazonaws.com":
            return handle_quicksight_event(detail, account_id, namespace, permission_profile, target_group)
        else:
            logger.warning("Unknown event source: %s", event_source)
            return {"statusCode": 200, "body": "Unknown event source"}
    except Exception as e:
        logger.error("Error processing event: %s", str(e))
        return {"statusCode": 500, "body": str(e)}

def handle_idc_event(detail, account_id, namespace, permission_profile, target_group):
    """Handle AddM