Amazon Quick でのユーザーロールのダウングレード

Amazon Quick においてアクセス権限を効果的に管理することは、安全で協力的な環境を維持するための重要な要素です。Quick は、多様な ID タイプや組織のニーズに対応できるように設計された、柔軟なユーザー管理オプションをサポートしています。Quick Identity を通じてユーザーをネイティブにプロビジョニングすることも、AWS IAM Identity Center や Active Directory などのエンタープライズ ID プロバイダーを通じて管理することもできます。これらのシステムにより、Admin、Author、Reader などのユーザーロールを、職務やセキュリティ要件に応じて割り当て、グループ化することが可能です。チームメンバーが組織に加わったり、役割を変更したり、組織を離れたりする際には、管理者は業務ワークフローを中断させたりセキュリティ上の隙間を作ったりすることなく、これらの移行が円滑に行われるよう確認しなければなりません。

Quick環境のセキュリティを維持するためには、定期的なアクセスレビューが重要です。毎月または四半期ごとにユーザーロールの監査を計画し、全員が適切な権限を持っていることを確認しましょう。チームメンバーの担当業務が変更された際は、放置されたリソース(孤立したリソース)が発生しないよう、ダッシュボードや分析の所有権を積極的に移譲してください。このプラクティスは、以下で推奨されています。 AWS Well-Architected Framework, ビジネスに不可欠な可視化の継続性を維持するのに役立ちます。

本記事では、ユーザーのライフサイクルにおける特定の、しかし重要なタスクである、ユーザーロールのダウングレードに焦点を当てます。

なぜダウングレードするのか?

最小権限の原則は、Quickの管理において非常に重要です。ユーザーには、それぞれの職務に必要な範囲のみアクセスを許可すべきです。ユーザーロールの格下げは、最小権限を強制するための重要な要素です。ユーザーの職責において作成者権限や管理権限が不要になった場合は、セキュリティの攻撃対象領域を最小化するために、それに応じてロールを引き下げてください。

クイックプライシングもロールベースです。AuthorsとAdminsはユーザーあたりの固定月額料金を支払いますが、Readersはセッションベースの料金体系を利用します。ダッシュボードの閲覧のみを行うAuthorsとしてプロビジョニングされたユーザーがいる組織は、Readerロールへの適正化によってコストを大幅に削減できます。最新の料金詳細については、以下をご参照ください。 Amazon Quick 料金ページ.

Amazon Quick の組み込みロール以上のきめ細かな制御が必要な場合は、ロールの割り当てを以下と組み合わせて補完することを検討してください カスタム権限ロール階層内の特定の機能を制限するものです。Amazon Quick との統合により、 AWS Identity and Access Management (IAM) 基本的なロールシステムを補完する追加の権限境界を提供します。

この記事の範囲

正確な手順はユーザーアイデンティティの種類によって異なりますが、この記事では主に Amazon Quick Identity ユーザー(Quick-managed ユーザーとも呼ばれます)を取り上げます。IAM Identity Center や Active Directory を通じて認証されたユーザーは、通常、ロールの変更が外部アイデンティティプロバイダーのグループマッピングを通じて管理されます。お使いの環境で IAM Identity Center を使用している場合、ロールのダウングレードは、ユーザーをある IdC グループから別のグループに移動することで処理されます(例えば、Quick-Admins グループから Quick-Readers グループへ)。段階的な降格手順は必要ありません。

Amazon Quick コンソールでは、すべてのロール変更に対して直接的なダウングレード手順が提供されていません（具体的には、コンソール画面から Admin から Reader へ、または Author から Reader へ直接ダウングレードすることはできません）が、信頼できる解決策が2つあります。手動で削除して再作成する方法と、AWS Command Line Interface（AWS CLI）を使用する方法です。ここでは両方の手法を順を追って説明し、チームの変化に応じて適切なアクセス管理を維持できるようサポートします。

前提条件

始める前に、Amazon Quick への管理者アクセス権を持つ有効な AWS アカウントを用意してください。CLI 方式を使用する予定の場合は、次のものが必要です。 AWS CLIがインストールおよび設定済みであること お使いのマシン上で。また、ロールを変更する必要があるユーザーのリストを事前に準しておくと便利です。

Amazon Quick のロールを理解する

Amazon Quick は、異なるロールセットを持つ 2 つのサブスクリプションプランを提供しています:

コンソールには、任意のAuthorティアから任意のReaderティアへダウングレードする直接的な方法は提供されていません。 update-user APIも同じ制約を適用しており、直接のダウングレードは「You cannot downgrade a user role」というエラーで拒否されます。

次のスクリーンショットはAmazon Quick Suiteのユーザー管理ページを示したもので、コンソールではユーザーをAuthorティアからReaderティアへ降格させる直接的な操作は提供されていません。これが、この投稿で紹介する方法が必要とされる理由です。

図1: Amazon Quick Suiteのユーザー管理ページ

CLIによる段階的な降格の方法は、 レガシーなBIのみのロール (Admin、Author、Reader)に対して、次の順序で確実に機能します:

Admin > Author > Restricted Reader > Reader

この同じ順序は、中間のステップでレガシーロールを使用する限り、Proユーザーにも機能します。たとえば、Author Pro > Author > Restricted Reader > Reader Proという手順は正常に完了します。

変更を加える前に知っておくべき重要な考慮事項

いずれかの方法でロール変更を実装する際には、留意すべき重要な要素がいくつかあります。まず、変更を加える前に、リスト内のすべてのユーザーが現在 Admin または Author のユーザーであることを確認してください。すでに低い権限を持つユーザーをダウングレードしようとすると、エラーが発生する可能性があります。CLI 方式を使用する場合でも、リソースの所有権の問題は引き続き適用されます。ダウングレードされるユーザーは、以前所有していたリソースを編集できなくなります。CLI 方式を使用する大規模な組織では、メールアドレスをハードコーディングするのではなく、CSV ファイルからユーザーのメールアドレスを読み込むことを検討してください。ローカルにインストールした CLI の代わりに AWS CloudShell を使用する場合、AWS CloudShell は現在のコンソールのリージョンコンテキストを自動的に使用するため、AWS リージョンの指定を省略できます。

アセットの所有権の移行（最初に行います）

ユーザーを削除する前に、ダッシュボード、データセット、分析など、そのユーザーが所有するアセットが適切に再割り当てされていることを確認することが不可欠です。これにより、業務の混乱を防ぎ、リソースが孤立したままになるのを回避できます。ユーザーが Author である場合は、データセットやダッシュボードを所有しているかどうかを確認し、ここで説明するのと同じアセット再割り当ての手順に従ってください。Amazon Quick でアセットの所有権を移行するには、主に 3 つの方法があります。

オプション 1: 別の管理者に事前に所有権を移行する

最も制御しやすい方法は、ユーザーを削除する前に手動で所有権を再割り当てすることです。これを行うには、Quick の各アセットに移動し、 Shareを選択して、別の管理者を共同所有者として割り当てます。この方法では、各リソースを誰が引き継ぐかを正確に決定できるため、影響の大きいダッシュボードやデータセットに特に有用です。大規模な環境では時間がかかる可能性がありますが、チームの構造と責任に応じてアセットを分配する柔軟性が得られます。

次のスクリーンショットは、アセットの Share ダイアログを示しています。ここで別の管理者を共同所有者として追加することで、元のユーザーを削除する前に所有権が移行されます。

図 2: アセットの所有権を別のユーザーに移行する

オプション 2: 管理ページで Amazon Quick の一括アセット転送を使用する

ユーザーが多くのアセットを所有している場合、手動の方法は非効率になる可能性があります。その場合は、Quick の管理セクションにある Manage assets 機能を使用できます。このツールを使用すると、管理者は複数のアセットの一括所有権移行や共有権限の更新を一度に行うことができます。これにより、特にユーザーのオフボーディングや組織変更の管理の際に、再割り当てプロセスが大幅に合理化されます。この機能の使用方法の詳細については、公式の Managing assets in Amazon Quick ドキュメントを参照してください。

オプション 3: Quick のユーザーグループとアセットを共有する

もう 1 つの効果的な戦略は、ユーザーグループとアセットを共有することです。Quick Identity ユーザーの場合は、Quick グループを作成し、関連するチームメンバーを追加して、個々のユーザーではなくグループとダッシュボードやデータセットを共有できます。アカウントが IAM Identity Center または Active Directory と統合されている場合、同等のグループはそれらのシステムで作成および管理され、Quick では Quick 管理のグループの代わりにそれらの外部グループがアクセス制御に使用されます。このようにすることで、特定のユーザーが削除されても、共有リソースへのアクセスは維持されます。これは、将来の所有権の再割り当ての必要性を減らし、変化の激しいチーム間で一貫したアクセスを維持するのに役立つ、回復力のあるアプローチです。

手動の方法: ユーザーの削除と再作成

最も効率的な方法ではありませんが、手動での削除と再作成の方法は、CLI の使用が不可能な環境向けの選択肢の 1 つです。この方法では、管理者ユーザーを完全に削除してから、リーダー権限で再作成します。この同じ手動方法は、Author を Reader にダウングレードする場合にも適用されますが、通常はアセットの所有権に関する複雑さは少なくなります。

この方法では、より低いロールで再作成する前にユーザーアカウントを削除する必要があるため、貴重なリソースを失ったりワークフローを混乱させたりしないように、慎重な準備が不可欠です。続行する前に、前のセクションで説明したアセットの所有権の移行が完了していることを確認してください。

ステップ 1: 管理者ユーザーを削除する

すべてのリソースの所有権を移行したら、AWS Management Console にサインインし、Amazon Quick サービスに移動します。そこから、プロファイルアイコンを選択し、 Manage Quickを選択し、続いて Manage usersを選択します。ダウングレードする管理者ユーザーを見つけたら、名前の横にある削除アイコンを選択し、プロンプトが表示されたら削除を確認します。これにより、システムへの現在のアクセスが完全に削除されます。

事前にすべてのリソースを移行していない場合、Quick は所有権移行ダイアログを表示します。このダイアログでは、ユーザーのすべてのリソースの所有権を受け取る別の管理者を選択するよう求められます。リストから適切な管理者を選択し、選択して移行を確認します 削除と転送. この組み込みの転送メカニズムは孤立したリソースの発生を防ぐのに役立ちますが、すべてを単一の管理者に転送してしまいます。より細かい制御を行うには、前述の事前アプローチを使用して、リソースを異なるチームメンバーに戦略的に配分してください。

事前の転送を行わなかった場合、次の図に示す削除ダイアログで、アカウントを削除する前にユーザーのすべてのリソースを単一の管理者に再割り当てできます。

図 3: ユーザー削除時の組み込みリソース転送

ステップ 2: Reader ロールでユーザーを再作成する

ユーザーの削除が正常に完了したら、Usersページにとどまり、選択します ユーザーを招待「。ユーザーのメールアドレスを入力し、以下を選択してください:」 読者 利用可能なオプションから役割を選択します。招待状を送信して、ユーザーがより制限の強い新しい権限でQuickに再参加できるようにします。

ステップ 3: ロールの変更を確認する

ユーザーが招待を承諾した後:

• アクセス権限が以下に更新されたことを確認します: 読者.
• ダッシュボードとレポートの閲覧のみが可能であることを確認してください。
• コンテンツを変更または作成できないことを確認します。

CLI方式：役割の段階的移行（推奨）

AWS CLI または AWS CloudShell を使用する場合は、プログラムでユーザーのロールを変更できます。Quick ではロールの変更を特定の順序で行う必要があるため、任意の Admin から任意の Reader へ直接移行することはできません。代わりに、中間のロールを順に経由する必要があります。

重要なお知らせ

• 置き換え <your-account-id> お使いのAWSアカウントIDを指定してください。
• 置換 <user-name> ユーザーのユーザー名。
• 置換 <user-email> ユーザーのメールアドレスと共に。
• CloudShell の外部で AWS CLI を使用している場合は、以下を指定してください。 --region パラメータ.
• ザ --role 値はAPIのロール名と正確に一致する必要があります(前の表を参照してください)。

例: レガシートラック(AdminからReaderへ)

ステップ1: 役割をAdminからAuthorに変更します:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role AUTHOR

ステップ2: 役割を Author から Restricted Reader に変更します:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role RESTRICTED_READER

ステップ3: ロールを「Restricted Reader」から「Reader」に変更します:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role READER

格下げ後:レビュー制限プロファイルとカスタム権限

ロールを変更しても、Limit Profile や Custom Permissions プロファイルは自動的に調整されません。これらはどちらもユーザーのロールとは独立して保持されるため、ダウングレード後には必ず見直してください。

• Limit Profiles は、インデックスストレージやエージェント時間などのリソースに対するユーザーごとの上限を制御します。ダウングレードされたユーザーに、以前の Admin または Author ロールに適したプロファイルが割り当てられていた場合は、リソースの過剰割り当てを避けるため、Reader に適した Limit Profile を再割り当てしてください。詳細については、 Limit Profiles のドキュメント を参照してください。
• Custom Permissions は、ロール階層内の特定の機能を制限します。Author に割り当てられたプロファイルは、Reader では期待どおりに動作しない場合があります。最後の CLI ステップで解除するか( --unapply-custom-permissions)、Reader 階層向けに設計されたプロファイルを割り当ててください。

複数ユーザーを更新するスクリプト

次のスクリプトを使用して、複数のユーザーを更新します。

#!/bin/bash

# Define AWS account details
AWS_ACCOUNT_ID="<your-account-id>"
REGION="<your-region>"

# Load users from file (format: username,email per line)
# Lines starting with # are treated as comments
INPUT_FILE="users_to_downgrade.txt"

while IFS=',' read -r username email; do
  # Skip comments and empty lines
  [[ "$username" =~ ^#.*$ || -z "$username" ]] && continue

  echo "Processing user: $username"

  # Role transition stages
  for ROLE in AUTHOR RESTRICTED_READER READER; do
    RESULT=$(aws quicksight update-user \
      --aws-account-id "$AWS_ACCOUNT_ID" \
      --user-name "$username" \
      --namespace default \
      --email "$email" \
      --role "$ROLE" \
      --region "$REGION" 2>&1)

    if [ $? -ne 0 ]; then
      echo " ERROR at $ROLE: $RESULT"
      break
    fi

    echo " Transitioned to $ROLE"
    sleep 3
  done

  echo "Role update completed for $username."
done < "$INPUT_FILE"

echo "All user role updates processed!"

スクリプトの機能

このスクリプトは以下を実行します:

• 外部ファイルからユーザー名とメールアドレスを読み取ります(# によるコメントに対応)。
• ロールを 3 段階で更新します: Admin > Author > Restricted Reader > Reader。
• エラーハンドリングにより、いずれかのステップが失敗した場合、そのユーザーの移行を停止します。
• sleep コマンドにより、変更が反映されるまでの時間を確保します。

スクリプトを実行する際に注意すべき点:

• 実行前に、対象ユーザーが現在 Admin または Author ユーザーであることを確認してください。
• フェデレーテッド環境ではメールのプレフィックスが異なる場合があるため、実際の Quick のユーザー名を使用してください。
• AWS CloudShell ではリージョンの指定は不要です。
• スクリプトを修正して、次の CSV エクスポートからユーザーを読み込むことができます: list-users.

ユーザーアクセス管理のベストプラクティス

Quick 環境を安全かつ整理された状態に保つために、以下のベストプラクティスに従ってください:

• ユーザーロールを定期的に見直す(月次または四半期ごとの監査)。
• ロールを変更する前にリソースの所有権を移譲する。
• 最小権限の原則に従う。
• ロール階層内のきめ細かな制御にはカスタムアクセス許可プロファイルを使用する。
• 耐障害性のため、個人ではなくグループとリソースを共有する。
• 追加のアクセス許可境界として AWS Identity and Access Management を使用する。

クリーンアップ

ユーザーロールの変更が完了したら:

• テストユーザーを削除する。
• 意図しないリソースが残っていないことを確認する。
• 一時的な CLI スクリプトやユーザーリストファイルを削除する。
• 最終的なユーザーのアクセス許可を再確認する。

まとめ

この記事では、Amazon Quick でユーザーロールをダウングレードする 2 つの方法、手動での削除と再作成、および柔軟な AWS CLI を使ったアプローチを紹介しました。これらの戦略は、チームのアクセスを効率的かつ安全に管理するのに役立ちます。

IAM Identity Center を使用している環境では、ロールの変更は IdC グループの再割り当てを通じて管理され、ここで説明した段階的な降格の手順は不要です。追加のガバナンス管理については、機能レベルの制限には Custom Permissions を、コンテンツレベルの分離には Restricted Folders をそれぞれご覧ください。

関連リソース

• Managing User Access in Amazon Quick
• Managing Assets in Amazon Quick
• Custom Permissions Profiles
• AWS IAM Best Practices
• AWS Business Intelligence Blog

皆さんのユーザー管理の経験についてぜひお聞かせください。あなたの組織では Quick Suite のロール移行をどのように処理していますか?これらの変更を効率化するためのカスタムスクリプトやプロセスを開発しましたか?コメントであなたの考えや課題を共有してください。

著者について