お問い合わせ
4 分で読むことができます。

【Security】Sisenseで行レベルセキュリティを設定してみよう -1

執筆者 Sato-G 更新日時 2020年10月16日

【Security】Sisenseで行レベルセキュリティを設定してみよう -1

目次

シャローム!Sato-Gです。
いよいよ秋の気配...
例年は春に受けている健康診断、コロナの関係でこの時期までずれ込み、先週やっと行ってきた。
検査の間の待ち時間は例年なら雑誌を読んで過ごすのだが、今年は完全に雑誌が撤去されていて、これもコロナの影響だよね。
待ち時間がヒマすぎ。。
また受診前に「呼吸器検査はどうしますか?皆さん敬遠されるのですが...」と言われた。
この聞き方には明らかに「呼吸器検査は受けさせたくない」という意図が感じられた。
呼吸器検査は口から感染するリスクがあるので、施設の立場もわからないことはないが、健康かどうかを診断するわけでしょ?
なんだか本末転倒だよね。
ま、僕も受診しなかったんだけどさ。

さて、このところデータ接続関係のブログが続いていたので、今回はちょっと趣向を変えてセキュリティの話。

1. 行レベルセキュリティとは

企業内でダッシュボードを共有する時は、共有範囲を制限すればいい。
例えば財務会計のダッシュボードは機微なデータだから、経理部門やマネジメン層だけに限って共有する。

しかし、売上データを共有する時に、「自分のテリトリーの実績しか見れないようにする」なんていうことは日常的にある。
でもElastiCubeやダッシュボードを別々に作るのは面倒くさい。
そんな時に使えるのが、行レベルセキュリティ(RLS=Row level Security)だ。

他のBI製品の中には、コーディングが必要になるものも少なくないが、Sisenseの行レベルセキュリティはGUIで設定が完了する。
ではその方法を見ていこう。

2. 他のBI製品での行レベルセキュリティ

2.1 Power-BIの場合

Power-BIのRLSはロールにルールを設定し、そのロールにユーザを割り当てる。ロールの設定はDAX式を使う。
DAX式はMicrosoft独自の数式で[Region] = "北海道"のような数式を'北海道'みたいなロール名で登録を行った後、そのロールにユーザ(メンバー)を割り当てるという方法だ。
ここではRegionに"北海道"という値が存在することを予め知っておく必要がある。
DAX式はPower BI初心者には馴染みがないかもしれないが、この程度の数式なら問題なさそうかな。
まあ、そこそこ簡単。

2.2 Tableauの場合

Tableauの場合は、データ表の他にユーザの資格情報を定義した資格表を準備する。データ表に資格表を結合して、資格表のユーザにフィルタを掛けることでRLSを実現している。
具体的にはカスタムSQLを使用するか、計算フィールドISMEMBEROF('')のように定義しフィルターカードにドラッグして[True]と設定することになるが、資格表を準備する必要があるのが難点。
ライブ接続の場合にRLS用のテーブルを準備してもらうのかなあ?
いずれにしてもちょっと面倒くさい。

2.3 Qlikの場合

QlikのRLSはSection Accessによって行う。基本的にQlik独自のロードスクリプトという言語でデータロード時にSection Access用のテーブルを作成して行うことになる。
僕はこのコーディングは苦にはならないのだが、Qlik初心者には荷が重いかな。
いずれにしても管理者かパワーユーザの方にお願いしないと実現はできない。

一方、Sisenseの行レベルレキュリティはGUIを使用して直感的に設定が可能だ。しかも必要にして十分な内容で、上記のどのBI製品より簡単であっさり設定が完了する。
このように簡素化できるのはSisenseが一般的なインメモリBIと違い、Desktop製品がなく全てサーバサイドの技術を使用しているからだと思う。
ユーザ情報はサーバ内のMongoDBに登録されているので、Desktopで開発→サーバで共有しRLS設定のようなステップを必要としない。
では、どれだけ簡単かをこれから解説していく。

3. データ構成

今回使用するデータは以下のデータモデルで構成されている。
この中のAreaテーブルの[売上地域]でテリトリーが決められていると想定してRLSを設定していく。

検証用のウィジェットは以下のピボットテーブルとする。

以下の4つのユーザを追加し、RLSが機能しているかどうかを検証してみる。

上のピボットテーブルを配置したダッシュボードを作成した4つのユーザに共有しておく。
今回はそれぞれのユーザの閲覧可能範囲を以下のように定義したい。
北海道ユーザ(hokkaido_user):北海道のみ閲覧可能
本州ユーザ(honshu_user):北海道以外閲覧可能
本社ユーザ(honsha_user):全てのエリアの閲覧可能
海外ユーザ(kaigai_user):全てのエリアの閲覧不可

4. 行レベルセキュリティの設定

4.1 データセキュリティの対象フィールドの設定

データセキュリティの設定は「管理者」画面で行う。
データ管理」→「データソース」で設定したいデータソースの3点リーダーメニューから「データセキュリティ」を選択する。

データセキュリティ画面で、セキュリティ設定したいフィールドを[+フィールドを追加]をクリックして追加する。

データソースの中から目的とするテーブル(今回の場合はArea) から目的とするフィールド(今回の場合は売上地域)を選択する。

Scope limitationsでは影響範囲をさらに細かく設定できる。
今回の場合はデフォルトの「常にこのルールを適用する」にしておく。

4.2 ユーザー(グループ)毎の制限の設定

制限状態のデフォルトは以下の表示になっていると思う。
この状態は「全てのユーザー」が「なし」を閲覧可能、つまり全て見ることができない。

北海道ユーザ(hokkaido_user):北海道のみ閲覧可能
[+ユーザー/グループを追加]で、hokkaido_userを追加する。さらに「」にて鉛筆アイコンをクリックし、□北海道地方にチェックを入れ、[アクセスを許可]をクリックする。

本州ユーザ(honshu_user):北海道以外閲覧可能
[+ユーザー/グループを追加]で、honshu_userを追加する。さらに「」にて鉛筆アイコンをクリックし、□北海道地方にチェックを入れ、[アクセスをブロック]をクリックする。
これで「北海道」以外を閲覧できるようになる。

本社ユーザ(honsha_user):全てのエリアの閲覧可能
[+ユーザー/グループを追加]で、honsha_userを追加する。さらに「」にて鉛筆アイコンをクリックし、「全部」をクリックする。
これで本社ユーザは全ての地域の閲覧が可能になる。

海外ユーザ(kaigai_user):全てのエリアの閲覧不可
[+ユーザー/グループを追加]で、kaigai_userを追加する。さらに「」にて鉛筆アイコンをクリックし、「なし」をクリックする。
これで海外ユーザは全ての地域の閲覧ができなくなる。

おっと、自分の権限をしていなかった。「本社ユーザ」は全ての地域の閲覧が可能なので、本社ユーザの鉛筆アイコンをクリックし、自分のユーザも追加しておく。

完成形はこちら。
上記で行った設定以外の「他のすべてのユーザー/グループ」は「なし」、つまりすべて閲覧ができない

5. 行レベルセキュリティの結果確認

では各ユーザのピボットテーブルがどんな表示になっているか確認してみよう。

北海道ユーザ(hokkaido_user):北海道のみ閲覧可能

本州ユーザ(honshu_user):北海道以外閲覧可能

本社ユーザ(honsha_user):全てのエリアの閲覧可能

海外ユーザ(kaigai_user):全てのエリアの閲覧不可

全パターンで想定通り、行レベルセキュリティ制限が効いていることが確認できた。

6. まとめ

以上、Sisenseの行レベルセキュリティの設定を解説した。
上の例ではユーザ単位で設定を行ったが、複数のユーザをグループ登録しておき、グループで設定することもできる。
どう簡単でしょ?
他のBI製品のような特別な知識も必要なく、誰でも簡単に設定できそうだ。楽ちん!

普通の運用ならこれで十分だと思うけど、次回はScope limitationsを使ってもう少し詳細の設定をしてみようかな。

ではまた!

Sato-G

執筆者 Sato-G

大学卒業後、日本電気株式会社を経て、中堅商社、リゾート運営会社にて人事総務、財務会計、マーケティング等の広範な実務を経験。その実務経験を活かし、現職にてデータ活用コンサルタントとして、これまで100社以上のプロジェクトの運営、開発実績を持つ。Qlik Luminary2020に選出。

1 分で読むことができます。

【Widget】ウィジェットの背景を変更する

3 分で読むことができます。

Hello, Sisense(サイセンス) world!

8 分で読むことができます。

【Blog】Spotify音楽データの分析①