[第4回] 権限制御はどこに実装する？　～Tableauとデータベースの機能分担について

miyabiiです。
Tableauサイト管理者 兼 DATA Saber挑戦中のApprenticeとして、考えたことや学んだことをシェアしていきます。
第4回は、Tableauとデータベース（DB）の権限制御の機能分担について、Tableauを中心にして考えます。

DBレイヤとBIレイヤの機能分担

Tableau単体だけで権限を考えるとうまくいかない

前回までTableauのパーミッション設計についての経験をお話しましたが、実際には組織のデータ管理とセキュリティはプラットフォーム全体で実現するため、DBとの機能分担の上でTableauのパーミッションをどうするか設計する必要があります。BIツールであるTableau単体だけで考えてしまうと、アーキテクチャ全体で見たら似たような機能が二重で実装されてしまったり、メンテナンスや管理上の問題が発生する恐れもあります。

Tableauでの権限制御を最小限にした背景・理由

データ利活用のプラットフォームを構築するにあたり、今回はTableau（BIレイヤ）ではなくBigQuery（DBレイヤ）に権限制御を寄せることを選択しました。

それには以下のような背景があります。

・権限制御の要求が非常に複雑。動的に行レベルセキュリティと列レベルセキュリティを必要とする。
　　→できるだけ1カ所にまとめて、全体の見通しを良くしたい！

・Tableauが唯一のユーザインターフェースではない。ユーザがデータ参照する際に使うのはTableauだけでなく、BigQueryにも直接アクセスしてデータ参照するユースケースがある。
　　→まとめる場所は、データのプライマリとしてのDB（BigQuery）で！

という訳で、権限制御はDBに一元化することにしました。

権限制御をDB一元化することで得られるガバナンス上のメリット

データセキュリティポリシーは変わります。ポリシー変更のたびに、権限制御を漏れなく修正する必要があるため、権限制御が複数の場所に実装されていると全てに反映されなかったり、ずれが生じてしまう恐れがあります。更に、Tableau側での権限管理の実装内容は機械的に洗い出すことが不可能なので、メンテナンスが困難であり、正しくポリシーを適用できないガバナンスリスクを抱えることになります。

共通ポリシーの実装を一元化することで、正確さのチェックが容易になり、修正時のコストが下がります。また、DBに実装をまとめることで、検索性や可読性が良くなります。これは、ガバナンス上の大きなメリットです。

個別ポリシーはTableauで実装してもOK

上記は、データ利活用プラットフォーム全体の共通ポリシーについて、DB一元化するという話でしたが、すべてDBに寄せることを強制するのではありません。個別ポリシーについてはTableau側に実装することもOKとしています。

例えば、とあるワークブックだけ、Aさんに見せるビューとBさんに見せるビューを変えるというような個別要件がある場合は、Tableauに実装するのが合理的です。

ただし、Tableauコンテンツで実装するのは上述したように実装したCreatorにしか分からない状態になりがちで、見通しがよいものではないので、まずはできる限りパーミッションで対処できるように検討します。それが難しい場合、Tableauの機能でどう実現するかを要件に合わせて選ぶ、という流れで検討するのがよいと思います。

Tableauでは、行レベル/列レベルセキュリティをフィルターを使って実現する方法がいくつかあります。具体的な選択肢は、次回、もう少し詳しく紹介しようと思います。

【backnumber】
[第1回]TableauのExplorerライセンスは、どういう時に使うのか？
[第2回] Tableauのパーミッションはベストプラクティスを死守すべし！
[第3回] 新しい運用ルールの決め方　～パーミッション続編
[第4回] 権限制御はどこに実装する？　～Tableauとデータベースの機能分担について
[第5回] Tableauでの行レベル/列レベルセキュリティの実現方法あれこれ
[第6回] Tableauからデータベースへのアクセス時の認証について
[第7回] 失敗例から学んでほしいダメなTableauの使い方
[第8回] クリーニングから始まるTableau Cloud移行
[第9回] Vizが遅い？！　～TableauCloud移行で性能に悩んだ話