こんにちは。今回は、Amazon QuickSight の Row-Level Security (RLS) 機能を活用して、データアクセスをユーザーごとに制限する方法について解説します。
この記事では以下の内容を説明します。
- RLS とは？
- RLS のセットアップ方法
- 実際のユースケースと運用
1. Row-Level Security とは？
RLS は、QuickSight 内で特定のユーザーやグループに対して、行レベルでアクセス制御を行うための機能です。これにより、ユーザーは自分に関連するデータだけを閲覧できるようになります。
例えば、開発チームはすべてのデータを閲覧できる。特定の顧客にはその顧客のデータのみが閲覧できるといった制御を行うことができます。 RLS は ダイレクトクエリ と SPICE の両方で利用でき、データのプライバシーやセキュリティを向上させます。
2. Row-Level Security のセットアップ方法
RLS を設定するには、まず「RLS ポリシー」を定義するためのデータセット（ユーザー ID テーブル）を準備します。このテーブルには、以下のような列を含める必要があります：
| UserName | ClientId |
|---|---|
| alice@example.com | Client_111 |
| bob@example.com | Client_222 |
上記はユーザー名で RLS ポリシーを設定する例ですが、実際には権限管理は QuickSight の Group 機能を使うことが多いと思います。 GroupName を用いて権限制御する際は以下のようなポリシーテーブルを用意します。
| GroupName | ClientId |
|---|---|
| developer | Client_111 |
| developer | Client_222 |
| client_111 | Client_111 |
| client_222 | Client_222 |
上記はdeveloper グループ (開発者) であればすべての ClientId のデータが閲覧でき、client_111 グループに所属するユーザーは ClientId が Client_111 というデータにのみアクセスできるような制御がおこなえます。
実際に動作を確認してみます。以下のようなデータを GroupName に応じて出し分けをしたいケースを考えます。
データセットの画面から行レベルセキュリティの設定を押下し、ユーザーベースのルールを用い、先ほど用意した GroupName による権限制御の RLS 用ポリシーテーブルをデータセットとして適用します。
| GroupName | ClientId |
|---|---|
| developer | Client_111 |
| client_111 | Client_111 |
| client_222 | Client_222 |
(テスト用に developer グループのユーザーで、Client_111 の ClientId のみが閲覧できるような RLS ポリシーテーブルにしています)
実際に適用すると以下のようにフィルタされた状態の表示になりアクセス制御を行えます。
3. 実際のユースケースと運用
実際のユースケースとして特定クライアントには、そのクライアントに関するデータのみ見せるといった制御が実現できます。 RLS を使わない場合は、QuickSight のダッシュボードをクライアントごとに作成しデータを適切に分離する実装を行う必要がありますが、RLS を使うことで 1つのダッシュボードで複数のユーザーごとに異なるデータを出し分けられ、効率的なダッシュボードの運用を実現することができます。
ただし、実際に運用する際にはポリシーテーブルの確実かつ安全な運用をどのように行うかという点が重要なため、RLS 機能を使用する際のユースケースはデータの特性に応じて慎重に検討する必要があります。
まとめ
QuickSight の Row-Level Security を使うことで 1つのダッシュボードで、ユーザー（グループ）ごとにデータアクセスを制御できることを紹介しました。 安全なデータアクセス制御と効率的なダッシュボード運用に役立つ機能だと思いますので、ユースケースに応じて導入を検討してみるのが良さそうだと思います。
