この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
お疲れさまです。とーち（@tttkkk215） です。
Amazon QuickSight（以下 QuickSight）で一つのデータセット上のデータの参照範囲をユーザごとに制限するにはどうしたらいいかを考えてみました。
この記事の対象者
- QuickSight の権限周りがいまいち分からないという方
- QuickSight で一つのデータセット上のデータの参照範囲をユーザごとに制限する方法について知りたい方
QuickSight 構成要素
権限コントロールをする際に前提となる知識をまず説明・・・と思いましたが、以下の記事にわかりやすくまとまっておりましたので、ご参照ください。
ここでは簡単に説明したいと思います。
ユーザ
QuickSight 上のユーザで Admin,Author,Reader の種別があります。
またユーザをまとめる単位としてグループという概念があります。
アセット
アセットとはデータソース、データセット、分析、ダッシュボードのことを指します。 アセットをまとめる概念として、共有フォルダ（ただしフォルダにデータソースを入れることは出来ない）があります。
基本的な考え方
まず前提として各アセットは作ったユーザ個人の所有物になるため、”明示的に他ユーザへの共有設定をしない限り”、他のユーザは参照・更新することはできません。
各アセット・共有フォルダを他ユーザに共有する際にはユーザ名の指定と、所有者か表示者（アセットにより名称は異なります）どちらの権限をつけるかを選択します。
この際つけられる権限は付与対象のユーザの種別により変わってきます。
所有者権限は Admin,Author にのみ付与できます。表示者権限は全てのユーザ種別に付与できます。
この権限によりアセットに対して行える操作が変わってきます。一例としてデータセットの場合に行える操作は以下の通りです。
- 表示者：そのデータセットから分析や他のデータセットを作成することを許可
- 所有者：表示者の権限に加えてデータセットの更新、編集、削除、再共有が可能
参考：データセットの共有 - Amazon QuickSight
また、後々の管理を考えるとユーザ個人やアセット単体に共有設定をするよりも、グループや共有フォルダを使って管理をしていったほうがいいと思います。
QuickSight の権限周りとしては、まずは上記を抑えておけばいいかと思います。
行レベルセキュリティについて
上記の他に行レベルセキュリティ・列レベルセキュリティという機能を使ってアクセス範囲を制限することができます。ここでは行レベルセキュリティについて説明します。
行レベルセキュリティでは、一つのデータセット内のデータに対してある範囲だけ A ユーザに見せ、別のある範囲については C ユーザに見せるといったことを実現できます。
また行レベルセキュリティにはユーザベースのルールとタグベースのルールがあります。
- ユーザベースのルール：QuickSight ユーザまたはグループに対して制限した行だけを見せる方法
- タグベースのルール：埋め込みダッシュボードを使用している状況で、QuickSight 未登録ユーザに対して見せるデータを制限したい場合に使用
行レベルセキュリティは便利なのですが、いくつか注意点があるのでご注意ください。
- 行レベルセキュリティはテキストデータ (文字列、char、varchar など) のみサポート、数値フィールド等では使えない
- データセットの所有者権限を持つユーザは行レベルセキュリティの設定に関係なくデータセット編集画面から全データを見ることができる。データの閲覧を完全に禁止したい場合には注意が必要。なお、データセットを使った”分析”に関してはデータセット所有者であっても行レベルセキュリティの設定が有効になる
- ユーザベースのルールでは表形式でルールを表現するが、この際、ルール表に存在しないユーザやグループに関してはデータが一切表示されなくなる
その他にも注意点がありますので、使用する場合はマニュアルをよくご確認ください。
Amazon QuickSight での行レベルのセキュリティ (RLS) の使用 - Amazon QuickSight
実際の使い方例
上記を踏まえて以下のような要件のときに具体的にどのような設定を入れればよいかを考えてみます。
- 分析対象 DB（RDBMS 等）の一つのテーブルに複数企業のデータが入っている
- ある QuickSight ユーザは特定の複数企業のデータを使って分析ができる
- 担当 A は A 株式会社と B 株式会社のデータを使える、担当 B は C 株式会社のデータを使えるといったイメージ
絵にするとこんなイメージになります。
役割分担の定義
まず QuickSight を使用する関係者の役割分担を明確にします。
役割分担については以下の資料が参考になったので、ご参照ください。
Amazon QuickSightの運用設計
画像引用：【開催報告＆資料公開】Amazon QuickSight のノウハウ総まとめ！ 〜BI 設計から運用まで〜 | Amazon Web Services ブログにてダウンロード出来る資料より
今回は以下のような想定とします。
- QuickSight アカウント全体の管理者（管理者：Admin ロール）
- QuickSight 上でデータソース及び、データセットを登録する（データ登録担当：Author ロール）
- 担当範囲においてデータセットを使用して分析、ダッシュボードを作成する、複数存在（データ分析担当：Author ロール）
- 担当範囲においてダッシュボードを閲覧する、複数存在（データ閲覧者：Reader ロール）
この役割分担に基づき設定していきます。
カスタム SQL を使ったアクセス制限方法
こちらはカスタム SQL を使ってユーザが見える範囲を制限する方法になります。
共有フォルダの構成としては以下のようなイメージになります。
１．データソースの作成
データソースはデータ登録担当ユーザで作成します。他ユーザへの共有はしません。
２．データセットの作成
データ登録担当ユーザがデータ分析担当ユーザごとにデータセットをカスタム SQL（ユーザごとに必要な範囲を where 句などで絞る）で作成します
３．データセットの共有
データセットを共有フォルダに入れます
共有フォルダにデータ分析担当ユーザを所有者権限で追加します
４．データの分析
データ分析担当ユーザはデータセットを使って分析・ダッシュボードを作成します
データ分析担当ユーザはデータソースを共有されていないので、カスタム SQL を発行することはできませんし、既存のデータソースからデータを追加することも出来ない状態となっており、アクセス範囲が制限されていることを確認できます。
メリット
- データ分析担当ユーザがデータセットを編集できる権限をもつ。例えばデータセットのフィールド名の変更やデータ型の変更が可能となる
デメリット
- データ分析担当ユーザがデータセットを削除することができてしまう
- データ分析担当ユーザがデータセットを他ユーザに共有できてしまう※
※ 共有についてはユーザのカスタムアクセス許可を使うことで制限することが可能です
参考：Amazon QuickSight コンソールへのアクセスのカスタマイズ - Amazon QuickSight
行レベルセキュリテイを使ったアクセス制限方法
こちらは行レベルセキュリテイを使ってユーザが見える範囲を制限する方法になります。
共有フォルダの構成としては以下のようなイメージになります。
１．データソースの作成
データソースはデータ登録担当ユーザで作成します。他ユーザへの共有はしません。
２．データセットの作成
データ登録担当ユーザがデータセットを作成し行レベルセキュリティでユーザごとに見える範囲を設定します
以下のような CSV データを用意します
UserName 列が QuickSight 上のユーザ名です。companyName はデータセットのフィールド名になっており、指定した値を持つ行のみが対象のユーザに表示されるようになります。
UserName,companyName
quicksight-user-a,A-Company
quicksight-user-b,B-Company用意した CSV ファイルをデータセットとして QuickSight にアップロードします
行レベルセキュリテイを実施したいデータセットのメニューを開き「行レベルのセキュリテイ」を選択します
ユーザベースのルールを開き、先程アップロードしたデータセットを選択してデータセットの適用を押すことで行レベルセキュリテイが有効になります
３．データセットの共有
データセットを共有フォルダに入れます 共有フォルダにデータ分析担当ユーザを表示者権限で追加します
４．データの分析
データ分析担当ユーザはデータセットを使って分析・ダッシュボードを作成します
分析画面で行レベルセキュリテイにより使用できるデータが制限されていることが確認できます
メリット
- データ分析担当ユーザがデータセットの所有権を持たないので他ユーザへの共有や削除することなどを防げる
- 行レベルセキュリティにより一つのデータセットを複数ユーザ間で共用するので、ユーザごとにデータセットを作るという手間が省ける
デメリット
- データ分析担当ユーザはデータセットの変更権限を持っていないので、フィールド名の変更やデータ型の変更が不可
- データセットのデータ型の変更等を行う場合、複数ユーザ間で共有で使っていることから、各ユーザへの影響を考慮する必要が出てくる
名前空間の使用について
上記の１、２に対して更に名前空間を使うということも可能です。 名前空間を使う場合の手順を簡単に記載しておきます。
- アクセス範囲を分けたいユーザごとに名前空間を作成
- データ登録担当ユーザがデータセットを作成（カスタム SQL または行レベルセキュリティを使用してユーザ毎に適切な参照範囲とする）
- 適切な権限を持つ IAM を使って、AWS CLI でデータセットを各名前空間のユーザに共有する設定を行う（共有フォルダ単位で共有することも可能です）
以降の流れは上記の方法と同じです。
名前空間を使う場合のメリットデメリットは以下のようになるかと思います。
メリット
- 各名前空間に所属するユーザは同じ名前空間内のユーザとしかアセットを共有できなくなる※
※別の名前空間のアセットの共有を完全に防ぐものではありません。上述のように、QuickSight が存在する AWS アカウント上で適切な権限を持つ IAM ユーザ・ロールを使用すれば、別の名前空間に対してもアセットの共有をすることは可能です。
デメリット
- 名前空間の管理が必要になります。ユーザが増えた際に名前空間を追加するなどの作業が発生します
- 名前空間のユーザはフェデレーテッドシングルサインオンでのみアクセスできます。パスワードベースのアクセス等はできません
まとめ
QuickSight で一つのデータセット上のデータの参照範囲をユーザごとに制限する方法を調べてみました。調べたことで QuickSight の権限周りに対する理解が一層深まったと感じます。 今回ご紹介した設定はあくまでも一例に過ぎません。もっといいやり方を知ってるよという方がいらしたら、ぜひご指摘お願いします。
以上、とーちでした。
0
