こちらの記事はDatabricks Advent Calendar 2022の23日目の記事です。

カケハシのデータ基盤チームの松田です。カケハシでは今年の7月からDatabricksを利用しており、そろそろ半年ぐらい経とうとしています。Databricksを採用した背景については、以下の記事に詳細をまとめていますので、まだ拝見されていない方は見ていただければ幸いです。色々な人から「とても参考になった！」と反響を呼んでいるオススメの記事です！

今回はDatabricks導入のタイミングで、データの閲覧権限とその管理者について見直したので、その検討過程と現時点での方針についての投稿になっています。

カケハシで利用しているデータの特性と現状の課題について

カケハシでは薬歴システムであるMusubiのデータを管理しており、毎日たくさんのデータが格納されています。それらのデータの中には、利用者の薬剤師の個人情報であったり、さらには患者さんの個人情報のような非常に秘匿性の高い情報があります。そのようなデータを扱っているため、現在は限定的な人しか扱えない状況です。本来でしたら適切に匿名加工処理を施せば利用できるにもかかわらず、現状は必要以上にかなり利用制限をかけており、データ利活用のハードルが高いです。

また、Musubiだけではなく複数のプロダクトがカケハシには存在しており、データ基盤チームだけでは各プロダクト毎のドメイン知識を有していないため匿名加工項目がわかなかったり、管理するリソースが限られています。

上記のような2つの課題があり、Databricks導入のちょうどいい機会だったので、データの閲覧権限とその管理者について検討しました。

データの閲覧権限を「プロダクト✕情報の機微な度合い」でロールを作成

データの閲覧権限に関して、「実践的データ基盤への処方箋」の「3-7章適切な権限設定とリスク管理方法を定める」を参考にし、各プロダクトと情報の機微な度合いの組み合わせでロールを作成し、そのロールにチームや個人を紐付けるロールベースアクセス制御（RBAC）で権限設定しました。

具体的には、プロダクトにはMusubiやMusubi InsightやPocket Musubiなどが該当し、情報の機微な度合いは以下の4つに区分してロールを作成しました。

そして、それらのロールに個人を所属させたロールグループとデータオブジェクトを以下の画像のように紐付けてTerraformでコード管理しました。たとえば、プロダクトがMusubiのデータで情報の機敏な度合いが最高機密情報であれば、「Musubi_最高機密情報」といったロールが作成され、そこにMusubiチームのエンジニアのロールグループやMusubiの生データが格納されているデータオブジェクトが割り当てられます。

ただ現時点での設計だと新入社員や部署異動が発生した際には、都度権限の見直しが必要となり運用コストがかかります。カケハシではよりお客様に価値を提供するためには、戦略に合わせて組織拡大や柔軟に体制変更があり、そのコストを最小限にできるような運用方針を定めなければいけなく、今後の課題になります。

データの管理者をプロダクトチームに移譲

データの管理者は、データメッシュの原則に則り、プロダクト毎にエンジニア代表者を選出して上記のロールを各プロダクト毎で管理する方針をたてました。まだ構想段階で一部分でしか実現できていない状況ですが、管理者を各プロダクトに移譲することにより、データ基盤チームのリソース不足による遅延が解消されつつあります。よりデータメッシュ組織化を進めるにあたっては、データ管理のガイドライン制定やデータ管理者の採用・教育などの課題がたくさんあります。