⚡Databricksガバナンス入門⚡ガバナンス設計の6つの基本原則と実務での適用例

📚 参考書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。

『ゼロから考えてわかった！Databricks ガバナンス 完全ガイド ― 導入後に困らない設計・権限・運用のベストプラクティス』

サイバー攻撃やAI活用が進む今こそ、ガバナンスが重要。🔐
設計・権限管理・セキュリティ・運用を体系的に解説！
https://link.amazon/B0izqqRtA

📚 その他参考書籍一覧

※全書籍・全ブログ・週刊Databricksリリース情報
https://modern-tech-hub.mellow-launc-5442.chatgpt.site/books

⚡Databricksガバナンス入門⚡ ガバナンス設計の6つの基本原則と実務での適用例 ガバナンス設計の基本原則

Databricksのガバナンスを設計するとき、個々の機能をどのように設定するかを考える前に、組織として共通の設計原則を決めておくことが重要です。

原則がないままWorkspace、Catalog、Group、Computeなどを増やしていくと、担当者ごとに異なる設計が行われ、環境が複雑になります。

本書では、Databricksガバナンスの基本原則を次の6つとして考えます。

• 最小権限
• 職務分離
• 標準化
• 自動化
• 監査可能性
• 責任分界

これらはDatabricks固有の考え方ではありませんが、Unity CatalogやWorkspace、Compute、CI/CDなどを設計するときの共通した判断基準になります。

最小権限を基本とする

最も基本となる考え方が**Least Privilege（最小権限）**です。

ユーザーやService Principalには、業務に必要な範囲だけ権限を付与します。

たとえば、データを参照するだけのAnalystにCatalogの管理権限を付与する必要はありません。また、開発担当者がDEV環境を変更できるとしても、同じ権限をPROD環境まで与える必要はありません。

Databricksでは特に、

• 個人ユーザーへ直接権限を付与しすぎない
• Groupを利用して権限を管理する
• 管理者権限を必要最小限のユーザーに限定する
• DEV/STG/PRODで権限を分離する

といった設計が重要になります。

「必要になったら権限を追加する」ことを基本とし、最初から広い権限を付与しないことがポイントです。

実務例：分析担当者の権限設計

営業部門のAnalystが売上データを参照する場合です。

• sales_analyst Groupを作成
• 対象CatalogとSchemaにUSE権限を付与
• 売上TableにSELECT権限を付与
• MODIFYやMANAGEなどの権限は付与しない
• PRODの管理者権限は付与しない

個人へ直接権限を付与するのではなく、Groupを通じて必要な範囲だけ許可します。

職務を分離する

大規模なDatabricks環境では、すべてを一人の管理者が操作できる状態は避けるべきです。

たとえば、

• Platform Team：Databricks基盤全体を管理
• Security Team：セキュリティポリシーを管理
• Data Owner：データ利用を承認
• Application Team：JobやPipelineを開発
• 利用者：許可されたデータを利用

といったように役割を分けます。

これを**Separation of Duties（職務分離）**と呼びます。

環境を構築する人、データアクセスを承認する人、本番へ変更を反映する人などを適切に分離することで、誤操作や不正操作のリスクを減らすことができます。

実務例：本番データへのアクセス申請

開発担当者が本番顧客データへのアクセスを希望した場合です。

• Application Team：アクセスを申請
• Data Owner：業務上の必要性を確認・承認
• Security Team：セキュリティ要件を確認
• Platform Team：Unity Catalogの権限を設定
• 監査担当：申請・承認・変更履歴を確認

申請者が自分自身のアクセスを承認できない設計にします。

標準化して例外を減らす

ガバナンスを安定して運用するためには、利用者ごと、Workspaceごとに異なるルールを作らないことも重要です。

たとえば、

• Workspaceの構成
• Catalog / Schemaの構成
• GroupとPrivilege
• Compute Policy
• Tag
• 命名規則
• Network構成

などについて、組織の標準を定義します。

新しいシステムを追加するたびにゼロから設計するのではなく、基本となる標準パターンを用意し、特別な要件がある場合のみ例外として扱います。

**「標準を基本とし、例外を管理する」**ことがガバナンスを複雑化させないための重要な考え方です。

実務例：WorkspaceとCatalogの標準構成

新しい業務システムをDatabricksへ追加する場合です。

• Workspace：DEV/STG/PRODで分離
• Catalog：sales_dev、sales_stg、sales_prod
• Group：管理者・開発者・参照者を標準化
• Compute Policy：利用可能なCompute構成を制限
• Tag：部門・システム・コストセンターを統一

新規案件でも同じ設計パターンを再利用し、例外だけを個別審査します。

手作業ではなく自動化する

標準を定義しても、設定をすべて人が手作業で行えば、設定漏れや環境ごとの差異が発生します。

そこで重要になるのが自動化です。

WorkspaceやUnity Catalogの設定はTerraformなどでコード化し、JobやPipelineはDeclarative Automation Bundlesなどを利用してデプロイします。

また、本番環境への変更についても、人が直接設定を変更するのではなく、Git、Review、CI/CDを経由する仕組みにすることで変更を統制できます。

ガバナンスでは、人にルールを守らせるだけではなく、仕組みにルールを守らせることが重要です。

実務例：本番環境への変更管理

新しいLakeflow Jobを本番へ追加する場合です。

• 開発担当者がDEV環境でJobを実装
• Job定義をDeclarative Automation Bundlesでコード化
• GitでPull Requestを作成
• レビューと承認を実施
• CI/CDからPRODへデプロイ
• デプロイ履歴をGitと実行ログに保存

手作業による設定ミスや環境差異を減らします。

すべての変更を追跡できるようにする

企業システムでは、「現在どうなっているか」だけでなく、「誰が、いつ、何を変更したのか」を確認できる必要があります。

そのため、権限変更、管理者操作、Compute利用、Job実行、データアクセスなどを記録し、必要に応じて確認できる状態にします。

これが**Auditability（監査可能性）**です。

さらにTerraformやGitを利用すれば、設定やコードについても変更履歴を残せます。

実務例：本番データへの権限変更を監査する

あるユーザーに本番Catalogの権限が追加された場合です。

• Unity Catalogの権限変更をAudit Logで確認
• system.access.auditから操作主体と変更時刻を調査
• 申請・承認履歴と照合
• 想定外の権限変更を検知
• 必要に応じて権限を是正

監査ログと変更申請を関連付けることで、操作の正当性を確認できる状態にします。

誰が責任を持つのかを明確にする

最後に重要なのが責任分界です。

Workspace、Catalog、データ、Security、Network、Costなどについて、誰がOwnerであり、誰が変更・承認・監視するのかを明確にします。

ガバナンスでは、技術的な設定だけを整えても十分ではありません。

「誰が決め、誰が実施し、誰が確認するのか」まで定義することで、初めて継続的に運用できるガバナンスになります。

実務例：障害発生時の責任分界

本番Lakeflow Pipelineが異常終了した場合です。

• Application Team：処理ロジックとエラー原因を調査
• Platform Team：Compute・基盤・権限を確認
• Data Owner：データ品質と業務影響を判断
• Security Team：セキュリティ問題の有無を確認
• 運用担当：障害通知・エスカレーションを実施

RACIなどの責任分担表を用意し、障害時に対応担当者が曖昧にならないようにします。

まとめると

Databricksガバナンスの6つの基本原則は、次のように実務へ適用できます。

基本原則	実務での適用例
最小権限	Group単位の権限付与
職務分離	申請・承認・設定の分離
標準化	Workspace・Catalog設計の共通化
自動化	Terraform・CI/CDによる環境管理
監査可能性	System Tables・Audit Logによる追跡
責任分界	RACIによるOwnerと対応責任の明確化

重要なのは、6つの原則を個別に適用するだけでなく、相互に組み合わせることです。

以降の章では、この6つの基本原則を判断基準として、Databricksの各管理領域を具体的に設計していきます。