はじめに
本記事は Databricksセキュリティ&トラストセンター で公開されている Azure Databricks Security Best Practices (Version 2.1 - December 2024) の
各 Appendix を “いつ、どの強度レベルで適用すべきか” に再構成・和訳したものです。
元文書は体系的である一方、実装順序・影響度・優先度の判断が難しいため、
セキュリティ強度（Lv0〜Lv3）ごとに実装タイミングを分類しました。
この記事では、セキュリティ強度別にセキュリティベストプラクティスにおけるコントロールの実装タイミングを定義し、紹介します。
デプロイモデル（各項目と関連appendixを和訳）
Azure Databricks セキュリティベストプラクティスのドキュメントでは、二つのデプロイモデルが紹介され、それぞれに適用すべきセキュリティコントロールが Appendix として記載されています。
Most deployments (多くの企業に適合)
| 項目番号 | Most Deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 1 | すべてのユーザーアクセスに多要素認証（MFA）を適用する | 1.1 | Leverage multi-factor authentication |
| 2 | Secure Cluster Connectivity（パブリックIPなし）を使用する | 3.1 | Use Secure Cluster Connectivity |
| 3 | Azure Databricks を自社の Azure 仮想ネットワーク（VNet）内にデプロイする | 3.2 | Deploy into your own VNet |
| 4 | アカウント、ワークスペース、Delta共有へのアクセスを IP アクセス リストで制限する | 3.3 | Configure IP access lists |
| 5 | Unity Catalog を使用してデータガバナンスを集約管理する | 2.1 | Centralise data governance with Unity Catalog |
| 6 | ストレージアクセスに Azure Managed Identities を使用する | 2.2 | Use Azure Managed Identities |
| 7 | データおよびワークスペースの分離モデルを計画する | 2.3 / 4.2 | Plan your data isolation model / Isolate sensitive workloads into different workspaces |
| 8 | ワークスペースを異なるネットワークに分離すべきか検討する | 3.6 | Isolate Azure Databricks workspaces into different networks |
| 9 | 匿名読み取りアクセスを防止し、ストレージの Azure セキュリティ基準に準拠した保護を適用する | 2.6 | Prevent anonymous read access |
| 10 | データセットにソフトデリートやその他のデータ保護機能が必要か検討する | 2.7 | Enable soft deletes & data protection features |
| 11 | 機密データを扱うストレージアカウントに Azure Storage Firewall を構成する | 2.5 | Configure Azure Storage firewalls |
| 12 | Git フォルダー と CI/CD を使ってコードを管理する | 5.4 / 5.7 | Manage code versions with Git folders / Manage code via CI/CD |
| 13 | 管理者ユーザー数を最小化し、通常アカウントと管理アカウントの職務分掌を徹底し、ワークスペース管理者を制限する | 1.3 / 1.4 / 1.5 | Limit admin users / Segregation of duties / Restrict workspace admins |
| 14 | 管理タスクや本番ワークロードの実行にサービスプリンシパルを使用する | 1.11 | Run tasks with service principals |
| 15 | 最小権限の原則に基づいてアクセスを管理する | 1.6 | Manage access according to least privilege |
| 16 | ユーザー分離をサポートするコンピュートを使用する | 1.12 | Use compute that supports user isolation |
| 17 | システムテーブルを構成し監視する | 5.1 | Configure and monitor system tables |
| 18 | Databricks の担当者によるワークスペースアクセスを制御・監視する | 4.9 | Control & monitor access for Databricks personnel |
| 19 | OAuth または Entra ID トークンを使用し、Personal Access Token（PAT）の使用を制限・無効化する | 1.7 / 1.8 | Use OAuth or Entra ID tokens / Enforce token management |
| 20 | 本番データセットを DBFS に保存しない | 2.4 | Avoid storing production data in DBFS |
| 21 | シークレットを安全に保存・使用する | 1.13 | Store and use secrets securely |
| 22 | データ流出対策としてネットワーク制御を実装することを検討する | 3.5 | Network exfiltration controls |
| 23 | クラスターを定期的に再起動する | 4.1 | Restart compute resources regularly |
| 24 | Delta Sharing を使用し、各メタストアでレシピエントトークンの有効期限を設定する | 2.11 / 2.12 | Use Delta Sharing / Configure recipient token lifetime |
| 25 | 予算やタグ付けを用いてコスト監視・チャージバック戦略を実装する | 5.13 / 5.14 | Use tagging for cost monitoring / Use budgets to monitor spending |
Highly secure deployments（より高度な構成）
| 項目番号 | Highly secure deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 1 | SCIM を使用してユーザーとグループを常に最新状態に保つ | 1.2 | Use SCIM to synchronize users and groups |
| 2 | バックエンド PrivateLink を利用する | 3.4 | Use Azure PrivateLink |
| 3 | フロントエンド PrivateLink を使用するか検討する | 3.4 | Use Azure PrivateLink |
| 4 | データ流出対策としてネットワーク制御を実装する | 3.5 | Implement network exfiltration protections |
| 5 | Azure Databricks ワークスペースを異なるネットワークに分離する | 3.6 | Isolate Azure Databricks workspaces into different networks |
| 6 | すべてのストレージアカウントに Azure Storage Firewall を構成する | 2.5 | Configure Azure Storage firewalls |
| 7 | データ保護強化のため、マネージドサービス・ストレージ両方に顧客管理キー（CMK）が必要か評価する | 2.9 / 2.10 | Configure customer-managed keys for managed services / Configure customer-managed keys for storage |
| 8 | データに追加の保護（暗号化や細粒度アクセス制御）が必要か検討する | 2.13 / 4.4 | Additionally encrypt sensitive data at rest using AES / Implement fine-grained access controls |
| 9 | Azure Storage のデータをバックアップする | 2.8 | Backup your Azure Storage data |
| 10 | PAT の使用を防止するためトークン管理の利用を検討する | 1.8 | Enforce token management |
| 11 | ワークスペース バインディングを使用して機密データセットと環境を分離する | 4.3 | Assign Unity Catalog securables to specific workspaces |
| 12 | クラスター作成権限を制限し、データアクセスパターンやコストを制御するため Compute Policy を使用する | 1.9 / 1.10 | Restrict cluster creation rights / Use compute policies |
| 13 | ワークスペース管理者設定を見直し構成する | 2.14 | Leverage data exfiltration prevention settings within the workspace |
| 14 | ライブラリ・モデル・コードの使用に制限を設けることを検討する | 5.5 / 5.8 / 5.9 | Restrict trusted code repos / Control library installation / Use trusted models and data sources |
| 15 | Enhanced Security Monitoring または Compliance Security Profile の利用を検討する | 4.8 | Use Enhanced Security Monitoring or Compliance Security Profile |
| 16 | インフラを IaC（Infrastructure-as-Code）でプロビジョニングする | 5.6 | Provision infrastructure via IaC |
| 17 | Azure ログでシステムアクティビティを監視する | 5.2 | Monitor system activities via Azure logs |
| 18 | 事業継続要件が強い場合、DR（Disaster Recovery）戦略を設計・実装・テストする | 4.10 | Implement and test a Disaster Recovery strategy |
本記事におけるデプロイモデル＝セキュリティ強度
- Lv0 (既定)：Azure Databricks 既定の状態または、セキュリティコントロールが未適用な状態を示します。
- Lv1 (Most Deployment)：多くの企業で標準となるコントロールを適用した場合のセキュリティ強度です。
- Lv2 (Highly)：エンタープライズ向けに高度なセキュリティ設定を導入する場合の強度です。比較的一般的に設定されている内容を中心に選別しています。
- Lv3 (最高強度)：最高強度のセキュリティを適用する場合のコントロールとして、Most にも Highly にも記載がない、または、Highly でも難易度が高いものを記載しています。
セキュリティの柱
Azure Databricks のセキュリティの柱に基づいて整理します。Appendixもこの構造にならっています
- 最小の特権を使って ID とアクセスを管理する
- 転送中と保存時のデータを保護する
- ネットワークをセキュリティで保護し、エンドポイントを保護する
- コンプライアンスとデータプライバシーの要件を満たす
- システムのセキュリティを監視する
1. 最小の特権を使って ID とアクセスを管理する
Most 1.x:
| 項目番号 | Most Deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 1 | すべてのユーザーアクセスに多要素認証（MFA）を適用する | 1.1 | Leverage multi-factor authentication |
| 13 | 管理者ユーザー数を最小化し、通常アカウントと管理アカウントの職務分掌を徹底し、ワークスペース管理者を制限する | 1.3 / 1.4 / 1.5 | Limit admin users / Segregation of duties / Restrict workspace admins |
| 14 | 管理タスクや本番ワークロードの実行にサービスプリンシパルを使用する | 1.11 | Run tasks with service principals |
| 15 | 最小権限の原則に基づいてアクセスを管理する | 1.6 | Manage access according to least privilege |
| 16 | ユーザー分離をサポートするコンピュートを使用する | 1.12 | Use compute that supports user isolation |
| 19 | OAuth または Entra ID トークンを使用し、Personal Access Token（PAT）の使用を制限・無効化する | 1.7 / 1.8 | Use OAuth or Entra ID tokens / Enforce token management |
| 21 | シークレットを安全に保存・使用する | 1.13 | Store and use secrets securely |
Highly 1.x:
| 項目番号 | Highly secure deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 1 | SCIM を使用してユーザーとグループを常に最新状態に保つ | 1.2 | Use SCIM to synchronize users and groups |
| 10 | PAT の使用を防止するためトークン管理の利用を検討する | 1.8 | Enforce token management |
| 12 | クラスター作成権限を制限し、データアクセスパターンやコストを制御するため Compute Policy を使用する | 1.9 / 1.10 | Restrict cluster creation rights / Use compute policies |
1.1 認証（Identity & Authentication）
ユーザー認証（MFA / Entra ID / Token）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| ユーザー認証 | アカウント侵害 / データ流出 / 内部脅威 / リソース悪用 | Entra ID SSOのみ、MFAなし | Conditional Access による MFA 必須（A-1.1） | – | FIDO2 / Phishing-resistant MFA 強制（A-1.1） |
デジタル ID 管理（SCIM / 自動プロビジョニング）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| デジタルID管理 | アカウント侵害 / データ流出 / 内部脅威 / リソース悪用 | Azure RBACでの権限を持つユーザーがアクセス時に自動的にDatabricks ユーザーが作成されるが、グループ管理などは Databricks 内で独立 | - | 自動ID連携による Entra ID との同期（A-1.2） | - |
API認証（OAuth / PAT）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| API認証 | アカウント侵害 | PAT無制限 | PAT期限短縮（7〜30日）（A-1.8） | ・可能な限り Entra ID または OAuthによる認証を使用する（A-1.7） ・PAT発行許可ユーザーの制限（A-1.8） |
・PAT発行の禁止（A-1.8） |
Secret / Credential 管理
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| Secret / Credential 管理 | アカウント侵害 / 内部脅威 | ノートブックに直書き | secret scope または KeyVault-backed scope で管理（A-1.13） | – | – |
管理タスク・ジョブ運用
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 本番環境の管理タスク・ジョブ運用 | データ流出 | 管理者アカウント・個人アカウントでジョブ／管理タスクを実行 | 本番ジョブおよび構成変更はサービスプリンシパルでの実行を基本とする（A-1.11） | - | - |
1.2 最小特権とアクセス管理（Least Privilege & Privileged Access Management）
管理者最小化と職務分掌
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 管理者最小化と職務分掌 | 内部脅威 | Account Admin・Workspace Admin・開発者が兼任し権限が集中している | ・アカウントとワークスペースにおける管理者ロール対象ユーザーを最小に保つ（A-1.3) ・管理者アカウントと日常で使用するユーザーアカウントを分離する（A-1.4) ・ワークスペース管理者の実行可能範囲を制限する(A-1.5） ・環境ごとに最小権限を保ち、グループに権限を割り当てる（A-1.6) |
- | - |
エンタイトルメントと Workspace オブジェクトアクセス
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| エンタイトルメントと Workspace オブジェクトアクセス | 内部脅威 / リソース悪用 | エンタイトルメント、Workspace object（Folder / Notebook / Job / Cluster など）の ACL が利用可能。ユーザーはシングルユーザーアクセスモードのコンピュートを作成可能 | ・分離無し共有クラスターを禁止する（標準（Shared / Lakeguard）と専用（Single User）のみ許可）（A-1.12) | ・クラスター作成権限を必要最小限に制限（A-1.9） ・Compute Policy の適用（A-1.10） |
- |
2. データ保護（Data Protection）
Most 2.x:
| 項目番号 | Most Deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 5 | Unity Catalog を使用してデータガバナンスを集約管理する | 2.1 | Centralise data governance with Unity Catalog |
| 6 | ストレージアクセスに Azure Managed Identities を使用する | 2.2 | Use Azure Managed Identities |
| 7 | データおよびワークスペースの分離モデルを計画する | 2.3 / 4.2 | Plan your data isolation model / Isolate sensitive workloads into different workspaces |
| 9 | 匿名読み取りアクセスを防止し、ストレージの Azure セキュリティ基準に準拠した保護を適用する | 2.6 | Prevent anonymous read access |
| 10 | データセットにソフトデリートやその他のデータ保護機能が必要か検討する | 2.7 | Enable soft deletes & data protection features |
| 11 | 機密データを扱うストレージアカウントに Azure Storage Firewall を構成する | 2.5 | Configure Azure Storage firewalls |
| 20 | 本番データセットを DBFS に保存しない | 2.4 | Avoid storing production data in DBFS |
| 22 | データ流出対策としてネットワーク制御を実装することを検討する | 3.5 | Network exfiltration controls / Workspace exfiltration settings |
| 24 | Delta Sharing を使用し、各メタストアでレシピエントトークンの有効期限を設定する | 2.11 / 2.12 | Use Delta Sharing / Configure recipient token lifetime |
Highly: 2.x
| 項目番号 | Highly secure deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 6 | すべてのストレージアカウントに Azure Storage Firewall を構成する | 2.5 | Configure Azure Storage firewalls |
| 7 | データ保護強化のため、マネージドサービス・ストレージ両方に顧客管理キー（CMK）が必要か評価する | 2.9 / 2.10 | Configure customer-managed keys for managed services / Configure customer-managed keys for storage |
| 8 | データに追加の保護（暗号化や細粒度アクセス制御）が必要か検討する | 2.13 / 4.4 | Additionally encrypt sensitive data at rest using AES / Implement fine-grained access controls |
| 9 | Azure Storage のデータをバックアップする | 2.8 | Backup your Azure Storage data |
| 13 | ワークスペース管理者設定を見直し構成する | 2.14 | Leverage data exfiltration prevention settings within the workspace |
2.1 データ境界（Data Boundary / Isolation）
Unity Catalog によるデータアクセスの一元化
| 制御観点 | 脅威モデル | Lv0（既定） | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| Unity Catalog によるデータアクセスの一元化 | ランサムウェア | Hive Metastore を使用しデータが DBFS / 外部ストレージに散在 | ・Unity Catalog を有効化し、データガバナンスを一元化（A-2.1) ・運用データを DBFS に置かない （A-2.4） |
– | – |
データ分離モデル（Logical / Physical Separation）
| 制御観点 | 脅威モデル | Lv0 | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| データ分離モデル | データ流出 | 単一メタストア / 単一ストレージに全データが混在 | Catalogレベルでのストレージを基本としてデータ分離モデルを設計する（A-2.3） | - | – |
2.2 データ保護（暗号化・Storage 機能・Storage アクセス制御）
暗号化（At-rest / In-transit / CMK）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 暗号化（保存時・転送時 / CMK） | データ流出 / 内部脅威 / ランサムウェア | Azure Storage 既定暗号化 + TLS（クラウドとユーザー間通信） | - | - | ・Workspace / Storage に Customer Managed Key（CMK）適用（A-2-9 / A-2.10） ・AES によるレコード値暗号化保存（A-2.13） |
Storage 保護（論理削除 / バージョニング / バックアップ）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| Storage 保護機能 | データ流出 / ランサムウェア / 内部脅威 | 保護機能と冗長化なし | リソースロック、論理削除の有効化、冗長ストレージの選択（A-2.7 ） | ストレージのバックアップを構成（A-2.8） | – |
Storage アクセス制御（Firewall / 匿名アクセス防止 / Managed Identity）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| Storage アクセス制御 | ランサムウェア / データ流出 | Firewall 無効・Public Access 許可・キー認証 | ・Azure Managed Identity による安全な Storage アクセス（A-2.2） ・機密データ用ストレージにファイアウォールを構成する（A-2.5) ・匿名Blobアクセス禁止などのAzureセキュリティベースラインに準拠したストレージ構成 (A-2.6） |
Workspace Storage を含む 全てのストレージにファイアウォールを構成する（A-2.5) | – |
2.3 データ流出防止（Exfiltration Prevention / Sharing / Clean Room）
Workspace Exfiltration Prevention
| 制御観点 | 脅威モデル | Lv0 | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| データ流出防止 | データ流出 | SQL結果のダウンロードなどの制御なし | - | Workspace のデータ流出防止設定を有効化（A-2.14） | – |
外部共有境界（Delta Sharing / Token Lifetime / Clean Room）
| 制御観点 | 脅威モデル | Lv0 | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| 外部共有境界 | データ流出 / 内部脅威 / 誤共有リスク | Delta Sharing を使用しない。ETL などによる物理共有 | Delta Sharing を有効化する場合、 recipient token lifetime を最小化（A-2.11 / A-2.12） | Clean Room によるプライバシーセーフな共同分析（A-2.15） | - |
3. ネットワークをセキュリティで保護し、エンドポイントを保護する
Most 3.x:
| 項目番号 | Most Deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 2 | Secure Cluster Connectivity（パブリックIPなし）を使用する | 3.1 | Use Secure Cluster Connectivity |
| 3 | Azure Databricks を自社の Azure 仮想ネットワーク（VNet）内にデプロイする | 3.2 | Deploy into your own VNet |
| 4 | アカウント、ワークスペース、Delta共有へのアクセスを IP アクセス リストで制限する | 3.3 | Configure IP access lists |
| 8 | ワークスペースを異なるネットワークに分離すべきか検討する | 3.6 | Isolate Azure Databricks workspaces into different networks |
| 22 | データ流出対策としてネットワーク制御を実装することを検討する | 3.5 | Network exfiltration controls |
Highly 3.x:
| 項目番号 | Highly secure deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 2 | バックエンド PrivateLink を利用する | 3.4 | Use Azure PrivateLink |
| 3 | フロントエンド PrivateLink を使用するか検討する | 3.4 | Use Azure PrivateLink |
| 4 | データ流出対策としてネットワーク制御を実装する | 3.5 | Implement network exfiltration protections |
| 5 | Azure Databricks ワークスペースを異なるネットワークに分離する | 3.6 | Isolate Azure Databricks workspaces into different networks |
3.1 プライベートネットワークでの利用（Private Network Access）
経路と露出の抑制
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 経路と露出の抑制 | アカウント侵害 / データ流出 /ランサムウェア / サプライチェーン攻撃 | Public IP + Public経路のまま | ・Secure Cluster Connectivity により Public IP を廃止（A-3.1） ・VNet Injection により compute を顧客VNetに隔離（A-3.2） ・IP Access Lists を適用（A-3.3） |
PrivateLink による全経路の閉域化（A-3.4） ・サーバーレスコンピューティングからデータに対してプライベート接続(NCC)する（A-3.7） |
Git Proxy によるコードリポジトリ取得経路の閉域化（A-3.8） |
3.2 通信データ保護（Communication & Data Protection）
外部通信の制限（Outbound Restriction）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 外部通信の制限 | アカウント侵害 / データ流出 / 内部脅威 / サプライチェーン攻撃 | アウトバウンド通信が無制限 | – | ・Azure Firewall / NSG により outbound allowlist を構成（A-3.5） ・ Serverless egress policy により serverless もあて先を制御する（A-3.7） |
- |
ネットワーク保護（分離・暗号化）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| ネットワーク保護 | データ流出 | 複数のworkspaceが互いに通信可能、VM間通信(L2/L3 encryption)は暗号化されない | – | Workspaceを専用VNetに分離し、Cross-Workspace / Cross-VNet通信をNSGで明示的に遮断する（A-3.6） | Virtual Network Encryption によりVNet内のVM間通信をDTLSで暗号化する（A-3.9） |
4. コンプライアンスとデータプライバシー要件を満たす
Most:
| 項目番号 | Most Deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 7 | データおよびワークスペースの分離モデルを計画する | 2.3 / 4.2 | Plan your data isolation model / Isolate sensitive workloads into different workspaces |
| 18 | Databricks の担当者によるワークスペースアクセスを制御・監視する | 4.9 | Control & monitor access for Databricks personnel |
| 23 | クラスターを定期的に再起動する | 4.1 | Restart compute resources regularly |
Highly:
| 項目番号 | Highly secure deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 8 | データに追加の保護（暗号化や細粒度アクセス制御）が必要か検討する | 2.13 / 4.4 | Additionally encrypt sensitive data at rest using AES / Implement fine-grained access controls |
| 11 | ワークスペース バインディングを使用して機密データセットと環境を分離する | 2.3 / 4.2 / 4.3 | Plan your data isolation model / Isolate sensitive workloads / Assign UC securables to workspaces |
| 15 | Enhanced Security Monitoring または Compliance Security Profile の利用を検討する | 4.8 | Use Enhanced Security Monitoring or Compliance Security Profile |
| 18 | 事業継続要件が強い場合、DR（Disaster Recovery）戦略を設計・実装・テストする | 4.10 | Implement and test a Disaster Recovery strategy |
4.1 コンプライアンスへの準拠（Compliance Alignment）
コンピューティング環境の脅威保護
| 制御観点 | 脅威モデル | Lv0 | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| コンピューティング環境の脆弱性対応 | 内部脅威 / サプライチェーン攻撃 / ランサムウェア | 任意再起動による最新化 | 定期的な再起動運用による最新化（A-4.1） | ESM：強化されたセキュリティ監視 / CSP:コンプライアンスセキュリティプロファイル の適用（A-4.8） | – |
災害対策
| 制御観点 | 脅威モデル | Lv0 | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| 災害対策 | 内部脅威 / ランサムウェア | DRなし | - | - | DR 戦略を策定し、クロスリージョン DR を含めた復旧手順を構成する（A-4.10） |
4.2 データプライバシー（Data Privacy & Governance）
データガバナンスの強化
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| データガバナンスの強化 | 対応無し | Unity Catalog 内のリネージが取得される（A-4.6） | – | ・Row/Column Mask制御を適用する（A-4.4） ・データタグ付与と運用を開始する（A-4.5） ・外部 Lineage を追加する追跡 |
– |
アクセス範囲の分離
| 制御観点 | 脅威モデル | Lv0 | Lv1（Most） | Lv2（Highly） | Lv3 |
|---|---|---|---|---|---|
| アクセス範囲の分離 | データ流出 / サプライチェーン攻撃 | ・ACLを用いたワークロード間のWS共有 ・同一メタストアに対して全WSアクセス可能 |
- | ・機密データワークロードのWSを隔離する（A-4.2） ・特定のカタログ・スキーマ・外部ロケーション・資格情報を特定のWSのみに割当てる（A-4.3） |
– |
環境のプライバシー保護
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 環境のプライバシー保護 | Databricks 自体の潜在侵害 | Databricks 従業員がアクセス可能（ログ対象） | 従業員アクセスについてデフォルト拒否 + 必要時のみ許可（A-4.9） | – | Azure Confidential Computeを使用して使用中データの暗号化を構成（A-4.11） |
5. システムのセキュリティを監視する
Most 5.x :
| 項目番号 | Most Deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 12 | Git フォルダー と CI/CD を使ってコードを管理する | 5.4 / 5.7 | Manage code versions with Git folders / Manage code via CI/CD |
| 17 | システムテーブルを構成し監視する | 5.1 | Configure and monitor system tables |
| 25 | 予算やタグ付けを用いてコスト監視・チャージバック戦略を実装する | 5.13 / 5.14 | Use tagging for cost monitoring / Use budgets to monitor spending |
Highly 5.x :
| 項目番号 | Highly secure deployments の項目（和訳） | Appendix 番号 | Appendix 項目名 |
|---|---|---|---|
| 14 | ライブラリ・モデル・コードの使用に制限を設けることを検討する | 5.5 / 5.8 / 5.9 | Restrict trusted code repos / Control library installation / Use trusted models and data sources |
| 16 | インフラを IaC（Infrastructure-as-Code）でプロビジョニングする | 5.6 | Provision infrastructure via IaC |
| 17 | Azure ログでシステムアクティビティを監視する | 5.2 | Monitor system activities via Azure logs |
5.1 監査・監視
ログの収集と監視 （システムテーブル / 外部ログ / コマンドログ / データ品質）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| ログの収集と監視 | アカウント侵害 / データ流出 / 内部脅威 / サプライチェーン攻撃 / Databricks 自体の潜在侵害 / リソース悪用 / ランサムウェア | ログ未収集・監視なし | システムテーブル有効化(A-5.1) | Databricks 外部のログ（Activity Log/ Resource Logs/ VNet Logs / Entra ID）の収集（A-5.2） | ・Verbose Audit Logging を有効化し全クエリコマンドを取得（A-5.3） ・Lakehouse Monitoring で品質・ドリフト監視（A-5.11） |
コストの監視と保護（タグ / Budgets / Azure Policy）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| コストの監視と保護 | リソース悪用 | Azure Cost Management による費用監視のみ。Databricks 内の費用詳細追跡なし、無制限利用 | ・Databricks 内のタグ付けによる利用者別の計算リソース消費の可視化（A-5.13） ・基本的な Budget ポリシー設定（A-5.14） |
- | ・Azure Policy によるSKU強制（ A-5.15） |
5.2 構成管理・供給チェーン保護
構成・コードの保護（Git / Trusted Repo / IaC / CI/CD / Library Control / DevSecOps）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 構成・コードの保護 | アカウント侵害 / サプライチェーン攻撃 / 内部脅威 / リソース悪用 | コードは Databricks 内で手動管理されるか、リポジトリ制限なし。CI/CD、IaCなし。 | ・Git フォルダでのコード管理運用（A-5.4 ) ・基本CI/CD導入（A-5.7）。 |
・Trusted Repo 制限（A-5.5） ・IaC により環境構築を自動化（A-5.6） ・Library Allow-list（A-5.8） |
・DevSecOps スキャン統合（A-5.10）。 |
信頼されたリソースの利用（Trusted Models / Inference Tables & AI Guardrails）
| 制御観点 | 脅威モデル | Lv0 | Lv1 | Lv2 | Lv3 |
|---|---|---|---|---|---|
| 信頼されたリソースの利用 | サプライチェーン攻撃 | モデルの出所は未管理。監視なし。マーケットプレイスは既定でアクセス不可 | - | 信頼済みソースのモデル/データのみ利用（A-5.9） | Inference Tablesによるログ収集と AI ガードレール （A-5.12） |