株式会社GENDAでデータマネジメント部の部長をしております、さっくです。
データ基盤の民主化が進み、ダッシュボードを作る人が増えました。困ったのは、顧客データのような取り扱いに気を使うデータを含むダッシュボードを、作った人の裁量で好きな範囲に公開できる状態になっていたことです。
そして「誰が・何を・どこまで広く公開しているか」を横断で見る手段がありませんでした。1つずつ開いて目視すればいい話ではあるのですが、うちはDatabricksをグループ企業ごとにワークスペースを分けて運用していて、10個以上あります。ダッシュボードは、使われていないものも含めると500以上。目視で回りきれる規模ではありません。
この記事は、全ワークスペースのダッシュボードを毎朝収集して、リスク判定つきの一覧にまとめるまでの作業ログです。
ダッシュボードの一覧を返すシステムテーブルは無かった
最初に探したのはDatabricksのシステムテーブルです。SQL一発で全ワークスペース分を舐められるなら話が早い。
結論から言うと、2026年8月時点では見つけられませんでした。惜しいものはあります。テーブルの依存関係を記録しているシステムテーブル（system.access.table_lineage）にはダッシュボードの行も現れるので、IDだけなら拾えます。ただしテーブルを参照しているものに限られますし、こちらが欲しい情報、つまり公開しているのか、誰に共有されているのかは1つも入っていません。
監査ログ（system.access.audit）のほうには公開操作のイベントが流れてきますが、これは記録であって現在の状態ではなく、保持期間より前に公開されて以後放置されているダッシュボードは現れません。
現在の状態を知りたければ、ワークスペースごとにAPIを叩いて自分で組み立てるしかない。そういう結論になりました。
一番見たかったのは、誰の権限でデータを見せているか
集めた情報の中で、セキュリティ上いちばん効くシグナルは、公開APIの embed_credentials というフィールドでした。
Databricksのダッシュボード（AI/BI）は、公開するときに「発行者の認証情報を埋め込む」か「閲覧者の権限で実行する」かを選べます。しかも、既定は埋め込む側です。前者だと、閲覧者は元テーブルへの権限を持っていなくても中身が見えます。発行者の権限で動くからです。
機能自体は便利で、権限設計を簡略化したい場面では普通に使います。危ないのは組み合わせでした。公開していて、発行者の認証情報を埋め込んでいて、共有先がワークスペース全員またはアカウント全員。この3つが揃うと、閲覧者が本来アクセスできないデータを、発行者の権限で全社に見せている状態が完成します。作った本人に悪意がまったく無いのが厄介なところです。
なのでリスク判定は、この3条件の重なり方で決めることにしました。
| リスク | 条件 |
|---|---|
| HIGH | 公開 かつ 発行者の認証情報を埋め込み かつ 全員に共有 |
| MID | 公開 かつ 発行者の認証情報を埋め込み（共有は個別のみ） |
| LOW | 上記以外 |
埋め込みの有無を第一軸にしているのは、閲覧者の権限で実行される限り、最後は元データ側の権限が守ってくれるからです。
発行者は監査ログから拾って、テーブルに書き出しておく
APIからは「誰が公開したか」が取れません。ダッシュボード情報のAPIレスポンスにはオーナーを示す項目が無く、置かれているパスに個人のフォルダ名が含まれていれば持ち主を推測できる、という程度です。共有フォルダに置かれているものは、監査ログの作成イベントから作成者を拾って補っています。後で出てくる一覧表のオーナー列は、この推測値です。
発行者のほうは監査ログの公開イベントから、ダッシュボードごとの最新の1件を拾うことにしました。最終実行日時はクエリ履歴（system.query.history）から取れます。
ここで工夫したのは、この結果をビューではなくテーブルに実体化したことです。ビューのままだと、棚卸しダッシュボードを開くたびに監査ログとクエリ履歴をスキャンし直すことになります。日次で1回テーブルに書き出してしまえば、スキャンは1日1回で済みます。秒単位に棚卸しするわけでもないので、日次で十分でした。
全体としてはこういう流れになっています。
ジョブもダッシュボードもSQLも、Databricks Asset Bundles（DABs）で宣言的に管理しています。
収集できていないワークスペースも一覧に出す
収集対象のワークスペースは設定に手動で記載しています。収集には各ワークスペースへの認証情報が必要で、その発行と登録がどうしても人の作業になるためです。ということは、グループ企業が増えてワークスペースが増えたとき、誰かが追加しない限りその分は対象外のままです。ジョブは毎朝成功し続けるので、漏れていることには誰も気づきません。ワークスペースが増えるたびに把握できていない範囲が静かに広がっていく、つまり放っておくと負債になる構造です。
なので、監査ログには収集対象になっていないワークスペースを、そのまま一覧に出すパネルを作りました。新しいワークスペースができると、翌朝にはこのパネルに表示されます（システムテーブルがカバーするのは同一リージョンのワークスペースまでなので、この検出もその範囲で効きます）。
実際、このパネルを作った直後には、収集対象に入れていなかったワークスペースがいくつか表示されました。負債はもう始まっていたわけです。ここに出てきたものを順に収集対象へ追加していく、という運用にしています。
出来上がったダッシュボードに載せているもの
最終的には1枚のダッシュボードに集約しました。上段は全体感を掴むためのカウンタで、ダッシュボードの総数、公開中の数、発行者の認証情報を埋め込んで公開している数、リスクHIGHの数の4枚です。
中心は一覧のテーブルです。1行が1つのダッシュボードに対応していて、次のような見た目になっています（値はサンプルで、列も一部を抜粋しています）。
| リスク | ワークスペース | ダッシュボード名 | オーナー | 共有データの権限の種類 | 発行者 | 共有状態 | 最新の実行日時 |
|---|---|---|---|---|---|---|---|
| HIGH | ws-a | 会員売上モニタリング | sato@… | 発行者の権限（埋め込み） | sato@… | 公開 / ワークスペース全員 | 2026-08-18 09:12 |
| MID | ws-b | キャンペーン効果測定 | suzuki@… | 発行者の権限（埋め込み） | tanaka@… | 公開 / 個別4件 | 2026-08-17 18:03 |
| LOW | ws-c | 在庫分析（作業中） | ito@… | 未公開 | — | 下書き / 個別2件 | 2026-08-01 13:22 |
このほかに作成日時や最終更新日時、置かれているパスなどの列があります。作成日時・最終更新日時と最新の実行日時を組み合わせると、そのダッシュボードがいまも使われているのか、作られたきり放置されているのかがある程度わかります。ダッシュボード名はリンクにしてあり、クリックするとそのダッシュボード本体が別タブで開きます。棚卸しで引っかかったものを、その場で開いて中身を確かめるためです。ワークスペース・リスク・公開状態で絞り込めるので、「この会社のHIGHだけ」という見方ができます。
もちろん、一覧にして眺められるようになっただけでは、何も安全になっていません。なお、ここで言う「公開」や「全員に共有」は社内のワークスペース・アカウント内のメンバーに対するもので、社外やインターネットに公開されているわけではありません。ここからリスクの高いものを順に、作った人と一緒に見直していくことになります。本当に全員に共有する必要があるのか、発行者の権限で見せる必要があるのか。それを判断する材料が毎朝勝手に揃う状態を作れたのが、この取り組みの成果だと思っています。
まとめ
Databricksのダッシュボード棚卸しは、システムテーブルが用意されていない領域なので、APIを叩いて自分で組み立てるしかありませんでした。実際に集めてみると、公開・埋め込み・全員共有が揃った状態は思っていたより身近にあって、作った価値はありました。
ただ、本音を言えば、この仕組みの大半は自作したかったものではありません。Databricksのシステムテーブルはこの数年でずいぶん充実してきて、テーブルのリネージも、クエリの履歴も、課金の使用量も、SQLで引けるようになりました。それなのにダッシュボードだけは、何が公開されていて誰に共有されているかを一覧できるシステムテーブルがまだありません。民主化を進めるほど、この情報はガバナンスをする側の生命線になります。いつかDatabricksが提供してくれることを期待しています。
Discussion