Amazon QuickSight（Enterprise版）設計において、保守作業の安全性を高める対策

イノベーション推進部AIプロダクト開発グループの小松です。

ラックがAWS上でAIシステムを開発する中で、ユーザ部門がAIによる判定結果を視覚的に確認するための機能として、AWS上のBIツールであるAmazon QuickSightを利用しました。Amazon QuickSight Enterprise版の導入において、保守メンバーが顧客の個人情報にアクセスしないよう制御することが課題でした。

この記事では、Amazon QuickSightのEnterprise版を設定するにあたり、列レベルでのアクセス制限設定や自己プロビジョニングの禁止など、保守作業の安全性を高める工夫した点を紹介します。

QuickSight設定の前提

今回QuickSightを利用するのは、QuickSightを使って、自組織のあらゆるデータの運用管理をしている部門の方です。QuickSight上で確認したいデータの量は1年分と多く、その中には個人情報も含まれます。そしてQuickSight含め、AWS全般の開発・保守は、ラックが担当します。分析画面のちょっとした編集作業も、保守作業に含まれます。

つまり、ラックの保守メンバーがお客様先の個人情報を閲覧・取得できてしまう可能性があり、これを制御することが設定のポイントでした。

QuickSight設定で工夫したこと

QuickSight設定を進めるなかで、保守作業の安全性に関わる2つの課題がありました。それぞれどのような課題だったのか、またその対策方法をご紹介します。

課題① ダッシュボードで特定の列レベルのみの参照制限ができない

列レベルの制御とは、データセットの特定の列（項目）に対してアクセス制限を設ける機能です。これにより、分析画面で編集する際に、当該項目を参照不可にします。

この機能を利用することで、ラックの保守メンバーが個人情報を閲覧できないように設定しようと試みました。

列レベルの閲覧制限方法

データセットを作成したあと、対象データセットで「列レベルのセキュリティ」を選択します。

制限したい列にチェックを入れて次に進みます。

アクセスを許可するユーザやグループを選択します。

今回は自身のユーザのみ許可し、他のユーザやグループは閲覧できないようにしました。

アクセス権のないユーザが編集画面を開くと、当該項目がグレーアウトされたり閲覧禁止のマークが表示されたりします。

列レベルの閲覧制限の落とし穴

列レベルの制御によって、右側のラック保守担当向けの表示のように、顧客名だけが見えなくなることが理想でした。

しかし、実際には何も表示されなくなってしまいました......。QuickSightには特定の列を非表示にする機能がないそうです。

これだとお客様から問い合わせがあった際、状況を把握しながら対応することができません。

対策

問い合わせ対応などの保守作業ができなくなっては困るので、列レベルの閲覧制限は設定しないことにしました。

CloudTrailでダッシュボードを見たことは検知できるので、無断でダッシュボードを閲覧したことを検知するようにしました。

課題② 高権限なQuickSight自ユーザ作成ができてしまう

QuickSightユーザを作成する方法の1つとして、自己プロビジョニングという方法があります。自己プロビジョニングとは、AWS IAMユーザがマネジメントコンソールから初めてQuickSightにアクセスした際、QuickSightユーザを作成する機能のことです。

QuickSightユーザには管理者、作成者、閲覧者の3つのロールが用意されており、全てのQuickSightユーザにいずれかのロールが付与されます。さらにQuickSightユーザのロールに対し、禁止操作を定めるカスタムパーミッションの設定ができます。

ラックの保守メンバーに対し、ユーザ作成等の保守作業のために管理者ロールを付与しつつ、業務データのダウンロードを禁止するようカスタムパーミッションも設定する必要がありました。

自己プロビジョニングする際、ロールは選べますがカスタムパーミッションは選択させることができません。つまり、自己プロビジョニングを許可すると、個人情報を取り出し可能なラックの保守メンバーが誕生する可能性があります。これを阻止するため、自己プロビジョニングを禁止することが求められました。

自己プロビジョニングの操作権限管理

自己プロビジョニングの権限は、IAM Policyで制御します。このポリシーではユーザ管理、IP制限、その他閲覧関連の権限のみ許可しています。自己プロビジョニングに必要なquicksight:CreateReader、quicksight:CreateUser、quicksight:CreateAdminのいずれのポリシーも付与していません。

そのため、マネジメントコンソールからQuickSightへ初回アクセスを試みると、メールアドレスは入力できますがユーザは作成されません。

自己プロビジョニングの抜け道

CloudShellって使いますよね？自己プロビジョニングを禁止したIAMユーザで、QuickSightユーザ作成のコマンドを叩いてみました。

上記コマンドではカスタムパーミッションを設定していませんが、QuickSightユーザが作れてしまいました。QuickSightへのアクセスも問題なくできてしまいます。

自己プロビジョニングの抜け道対策

QuickSightユーザの作成は、CloudTrailで検知が可能です。

QuickSightユーザの作成を検知したら、Lambdaでカスタムパーミッションを付与することにしました。

さいごに

この記事では、特殊な要件におけるQuickSightの設計の工夫をお伝えしました。社外の保守担当者がメンテナンスする場合における不正対策について、QuickSightのアクセス制御機能が改善されたら良いなと思います。

開発の現場で、さまざまな制約や考慮事項に悩まされる方々の一助となれば幸いです。