【翻訳】Azure Databricksセキュリティベストプラクティス（バージョン2.0 - 2024年7月）

本記事は、「Security Best Practices for Azure Databricks (Version 2.0 - July 2024)」のPDFドキュメントの日本語訳をまとめたものです。Azure Databricksのセキュリティ機能や実践的なガイドラインについて知りたい方は、ぜひ参考にしてみてください。原文のPDFは、以下ドキュメント内のリンクからダウンロードできます。

https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/security-compliance-and-privacy/best-practices

（参考）他クラウドを含むセキュリティベストプラクティスの翻訳記事（本記事も含む）

https://qiita.com/nakazax/items/b9bf122e17bc71aed334

https://qiita.com/nakazax/items/d515c0da6355145b0a32

https://qiita.com/nakazax/items/48a43c746e255bc9be43

---

# 1. イントロダクション

Azure Databricksは、数千社におよぶ顧客と連携し、それぞれのセキュリティ、プライバシー、規制要件に合致した[Azure Databricks](https://azure.microsoft.com/ja-jp/products/databricks) [Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform) の安全なデプロイを支援してきました。多くの組織は独自の方法でセキュリティを実装していますが、大部分の組織で共通に利用されるパターンや機能があります。

***注意:*** セキュリティの専門家でない限り、このドキュメント全体を読む必要はありません。以下に示す **定義(Define)**、**デプロイ(Deploy)**、**モニタリング(Monitor)** の手順に従うことで、当社のセキュリティベストプラクティスを実装可能です。

* **定義(Define):** 下記の[ほとんどのデプロイ](#ほとんどのデプロイ)および[高いセキュリティを必要とするデプロイ](#高いセキュリティを必要とするデプロイ)に記載したセキュリティチェックリストを参照して検討します。  
* **デプロイ(Deploy):** [Security Reference Architecture (SRA)](https://github.com/databricks/terraform-databricks-sra/tree/main) のTerraformテンプレートを利用することで、これらのベストプラクティスに沿ったAzure Databricksワークスペースを簡単にデプロイできます！  
* **モニタリング(Monitor):** [Security Analysis Tool (SAT)](https://learn.microsoft.com/ja-jp/azure/databricks/security/#security-analysis-tool) を使用し、セキュリティベストプラクティスへの準拠を継続的に監視します。

:::note info
このドキュメントは、実行しているワークロードの種類に関係なく、データプラットフォームのセキュリティベストプラクティスに焦点を当てます。AIワークロードに関連する包括的なセキュリティベストプラクティスについては、Azure [Databricks AI Security Framework (DASF)](https://www.databricks.com/resources/whitepaper/databricks-ai-security-framework-dasf) を参照してください。
:::

# 2. Azure Databricksアーキテクチャ

[Azure Databricks](https://azure.microsoft.com/ja-jp/products/databricks) [Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform) のアーキテクチャは、権限管理を簡素化し、データの重複を回避し、リスクを低減するために、「コントロールプレーン」と「コンピュートプレーン」の2つのプレーンに分割されています。コントロールプレーンはワークスペースアプリケーションを実行し、ノートブック、設定、クラスターを管理します。コンピュートプレーンはデータ処理を担います。サーバーレスデプロイの場合、コンピュートプレーンはクラウドサービスプロバイダではなくAzure Databricksのアカウント内に存在します。

Azure Databricksプラットフォームに初めて触れる場合は、特定の推奨事項に入る前に、[Security and Trust Center](https://databricks.com/trust) にある[アーキテクチャ概要](https://databricks.com/trust/architecture)や一般的なセキュリティに関するQ&Aを先に確認することをお勧めします。

# 3. 典型的なセキュリティ構成

以下は、多くの顧客で一般的に用いられる典型的なセキュリティ構成を示します。シンプルさのため、「ほとんどのデプロイ」と「高いセキュリティを必要とするデプロイ」に分けています。

「ほとんどのデプロイ」とは、ほとんどの本番あるいはエンタープライズ環境で想定される構成（例：多要素認証(MFA)の使用）です。「高いセキュリティを必要とするデプロイ」とは、特に機密性の高いデータ、知的財産、あるいはヘルスケア・ライフサイエンス・金融サービスなどの規制業界において一般的な構成（例：Private Linkによる接続）を指します。

:::note warn
以下の推奨事項は、さまざまな顧客事例に基づいていますが、すべての環境やリスク許容度に適合するわけではありません。また、これらに従ったからといって、デプロイが必ずしも安全になることは保証できません。ご自身の企業全体のセキュリティフレームワークを考慮して、何が必要かを判断してください。
:::

## ほとんどのデプロイ

多くの本番Azure Databricksデプロイでは、以下の構成が採用されています。あまり機密性が高くないデータを扱う小規模なデータサイエンスチームであれば、すべてを導入する必要はないかもしれません。逆に、大量の機密データを分析する場合は、これらの構成をより慎重に検討することをお勧めします。

- [ ] [多要素認証(MFA)の活用](#11-多要素認証を活用する)  
- [ ] [Secure Cluster Connectivity（パブリックIPなし）の使用](#31-secure-cluster-connectivityパブリックipなしを使用する)
- [ ] [Azure Databricksを独自のAzure仮想ネットワークにデプロイ](#32-azure-databricksを独自のazure仮想ネットワークにデプロイする)してネットワーク環境を制御。現時点でこのオプションが必要でなくても、初期のワークスペースで将来的な成功の可能性を高めることができます
- [ ] [IPアクセスリスト](#33-ipアクセスリストを構成する)を用いてアカウント、ワークスペース、Delta Sharingへのアクセスを制限  
- [ ] [Unity Catalog](#21-unity-catalogでデータガバナンスを集中管理する)による集中型データガバナンス  
- [ ] [Azure Managed Identityを用いてストレージへアクセス](#22-azure-managed-identityを使用してストレージにアクセスする)  
- [ ] [ワークスペース](#42-機密性の高いワークロードを別ワークスペースに分離する)および[データ](#23-データ分離モデルを計画する)の分離モデルを計画  
- [ ] [Azure Databricksワークスペースを異なるネットワークに分離](#36-azure-databricksワークスペースを別のネットワークに分離する)するか検討  
- [ ] [匿名読み取りアクセスの防止＆その他の保護](#26-匿名読み取りアクセスを防止およびその他の保護を適用する)を実施（[Storage 用の Azure セキュリティ ベースライン](https://learn.microsoft.com/ja-jp/security/benchmark/azure/baselines/storage-security-baseline)参照）  
- [ ] [ソフトデリートなどのデータ保護機能](#27-ソフトデリートおよびその他のデータ保護機能を有効化する)の必要性を検討  
- [ ] [Azure Storageファイアウォール](#25-azure-storageファイアウォールを構成する)を構成して機密データを保存するストレージアカウントを保護  
- [ ] [Gitフォルダーによるコード管理](#54-gitフォルダーでコードバージョン管理する)や[CI/CD](#57-cicdでコードを管理する)によるコード管理  
- [ ] [管理者ユーザー数の制限](#13-管理者ユーザー数を制限する)、[職務分掌の徹底](#14-管理アカウント間での職務分掌を徹底する)および[ワークスペース管理者の制限](#15-ワークスペース管理者を制限する)  
- [ ] [サービスプリンシパル](#111-サービスプリンシパルを用いて管理タスクおよび本番ワークロードを実行する)を用いて管理タスク・本番ワークロードを実行  
- [ ] [最小権限の原則](#16-最小権限の原則に基づいてアクセスを管理する)に従ってアクセスを管理  
- [ ] [ユーザー分離をサポートするコンピュート](#112-ユーザー分離をサポートするコンピュートを使用する)を使用  
- [ ] [システムテーブルを構成しモニタリング](#51-システムテーブルを活用する)  
- [ ] [Azure Databricks担当者へのワークスペースアクセスを制御・監視](#49-azure-databricks担当者へのワークスペースアクセスを制御監視する)  
- [ ] [OAuthまたはAzure Entra IDトークン認証を使用](#17-oauthまたはazure-entra-idトークン認証を使用する)し、[トークン管理](#18-トークン管理を徹底する)でパーソナルアクセストークンの使用を無効化または制限  
- [ ] [DBFSに本番データを保存しない](#24-本番データをdbfsに保存することを避ける)  
- [ ] [秘密情報を安全に保管・使用](#113-秘密情報を安全に保管し使用する)  
- [ ] [データ流出防止のためのネットワーク制御](#35-データ流出防止を目的としたネットワーク制御を実施する)の実装検討  
- [ ] [定期的なクラスター再起動](#41-コンピュートを定期的に再起動する)により最新パッチを適用  
- [ ] [Delta Sharing](#211-delta-sharingを使用する)を利用し、[受信者トークン有効期間を設定](#212-delta-sharing受信者トークンの有効期間を構成する)  
- [ ] [予算設定](#514-予算を使用してアカウント支出をモニタリングする)や[タグ付け](#513-タグ付けをコスト監視課金戦略に活用する)によるコストモニタリングおよびチャージバック戦略を実装

## 高いセキュリティを必要とするデプロイ

上記の「ほとんどのデプロイ」で挙げた構成に加えて、以下はセキュリティ要求が高いAzure Databricksデプロイでよく利用されます。すべてを適用する必要はありませんが、以下の項目を[脅威モデル](#4-azure-databricksの脅威モデル)や自社のリスク許容度を踏まえて検討してください。

- [ ] [SCIMでユーザーとグループを同期](#12-scimを使用してユーザーとグループを同期する)  
- [ ] バックエンドでの[Private Link](#34-azure-privatelinkを使用する)使用  
- [ ] フロントエンドでの[Private Link](#34-azure-privatelinkを使用する)使用検討  
- [ ] [データ流出防止のためのネットワーク制御](#35-データ流出防止を目的としたネットワーク制御を実施する)の実装  
- [ ] [Azure Databricksワークスペースを別のネットワークに分離](#36-azure-databricksワークスペースを別のネットワークに分離する)  
- [ ] すべてのストレージアカウントに対する[Azure Storageファイアウォール設定](#25-azure-storageファイアウォールを構成する)  
- [ ] 顧客管理キー(カスタマーマネージドキー)による[マネージドサービス](#29-マネージドサービスに対して顧客管理キーを構成する)および[ストレージ](#210-ストレージに対して顧客管理キーを構成する)の暗号化検討  
- [ ] [高度な暗号化](#213-aesによる機密データの追加暗号化)や[きめ細かなアクセス制御](#44-きめ細かなアクセス制御を実装する)など、データへの追加保護検討  
- [ ] [Azure Storageデータのバックアップ](#28-azure-storageデータをバックアップする)  
- [ ] [トークン管理](#18-トークン管理を徹底する)を用いてパーソナルアクセストークンの使用禁止を検討  
- [ ] [ワークスペースバインディング](#43-unity-catalogセキュラブルを特定ワークスペースに割り当てる)による機密データセットや環境の分離  
- [ ] [クラスター作成権限制限](#19-クラスター作成権限を制限する)および[コンピュートポリシー](#110-コンピュートポリシーを使用する)でデータアクセスパターンやコストを制御  
- [ ] [ワークスペース管理者設定](#214-ワークスペース内のデータ流出防止設定を活用する)の見直しと構成  
- [ ] [ライブラリ](#58-ライブラリインストールを制御する)、[モデル](#59-信頼できるまたは評判の良いソースのみからモデルとデータを使用する)や[コード](#55-信頼できるコードリポジトリのみ使用する)使用に関する制限検討  
- [ ] [Enhanced Security MonitoringまたはCompliance Security Profile](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)の活用検討  
- [ ] [Infrastructure-as-Codeによるインフラ構築](#56-infrastructure-as-codeでインフラを構築する)  
- [ ] [Azureログを活用してシステム活動を監視](#52-azureログでシステム活動を監視する)  
- [ ] [Disaster Recovery戦略の設計・実装・テスト](#410-disaster-recoverydr戦略を実装テストする)による事業継続性要件への対応

# 4. Azure Databricksの脅威モデル

特にセキュリティに敏感な顧客は、Azure Databricksのようなプラットフォームに対して想定される脅威モデルと、そのリスク軽減策を理解したい場合があります。ベストプラクティスを確認し、特定のセキュリティ上の懸念がない場合は、この章はスキップして上記のチェックリストに集中しても問題ありません。

よく議論される脅威カテゴリは以下のとおりです。

1. [アカウントの乗っ取りまたは不正使用](#アカウントの乗っ取りまたは不正使用)  
2. [データ流出](#データ流出)  
3. [内部脅威](#内部脅威)  
4. [サプライチェーン攻撃](#サプライチェーン攻撃)  
5. [クラウドプロバイダおよび/またはAzure Databricksの潜在的な侵害](#クラウドプロバイダやazure-databricks自体の潜在的な侵害)  
6. [ランサムウェア攻撃](#ランサムウェア攻撃)  
7. [リソース悪用(クリプトマイニング等)](#リソース悪用)

この章では、これらのリスクに関する一般的な質問に回答し、確率や軽減策を示します。

## アカウントの乗っ取りまたは不正使用

**リスク説明**  
Azure Databricksは、重要なデータソースへのアクセスが可能な汎用コンピュートプラットフォームです。顧客ユーザーの資格情報がフィッシングや総当たり攻撃などで奪われた場合、攻撃者は環境内でアクセス可能なすべてのデータに不正アクセスできる可能性があります。

**確率**  
適切な対策がなければ、アカウント乗っ取りは効果的な攻撃手法となり得ます。しかし、適切な対策を講じれば、このリスクは大幅に低減可能です。

**保護策**
- [1.1 多要素認証を活用する](#11-多要素認証を活用する)  
- [1.2 SCIMでユーザーとグループを同期する](#12-scimを使用してユーザーとグループを同期する)（ユーザー離職時の自動的な削除や一時的な無効化など）  
- [1.7 OAuthまたはEntra IDトークン認証を使用する](#17-oauthまたはazure-entra-idトークン認証を使用する)（短命トークンでのアクセスを確保）  
- [1.13 秘密情報を安全に保管・使用する](#113-秘密情報を安全に保管し使用する)（ユーザー・システム資格情報の保護）  
- [1.8 トークン管理を徹底する](#18-トークン管理を徹底する)（パーソナルアクセストークンの無効化または有効期限の制限）  
- [3.3 IPアクセスリストを構成する](#33-ipアクセスリストを構成する)（アカウント、ワークスペース、Delta Sharingへのアクセスを信頼できるIPに限定）  
- [3.4 Azure Private Linkを使用する](#34-azure-privatelinkを使用する)（信頼できるプライベートネットワークへの接続制限）  
- [3.5 データ流出防止を目的としたネットワーク制御を実施する](#35-データ流出防止を目的としたネットワーク制御を実施する)  
- [3.8 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する](#38-価値のあるコードベースへのアクセスを信頼できるネットワークに限定する)

**検知**
- [5.1 システムテーブルを活用する](#51-システムテーブルを活用する)（認証失敗・不正アクセス試行の検出）  
    - 参考：[こちらのブログ](https://www.databricks.com/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する)（コード内の認証情報スキャン）

**対応**
- [1.2 SCIMでユーザーとグループを同期する](#12-scimを使用してユーザーとグループを同期する)（疑わしいユーザーの無効化・削除）  
- [1.7 OAuthまたはEntra IDトークン認証を使用する](#17-oauthまたはazure-entra-idトークン認証を使用する)（OAuthシークレット削除、SP無効化）  
- [1.8 トークン管理を徹底する](#18-トークン管理を徹底する)（トークンの取り消しまたはトークン認証の無効化）  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する)（潜在的な不正アカウント行動の調査）

## データ流出

**リスク説明**  
不正な内部ユーザーまたはアカウントが侵害された場合、攻撃者は機密データを環境外へ持ち出し、それを保存・販売・脅迫などに利用する可能性があります。

**確率**  
この種の攻撃は、内部の悪意のあるユーザーまたは侵害されたアカウントを前提としているため、一般的に発生確率は低いものの、このタイプの攻撃者がデータを流出させて悪用を試みることは珍しくありません。

**保護策**
- [1.11 サービスプリンシパルを用いて管理タスク・本番ワークロードを実行する](#111-サービスプリンシパルを用いて管理タスクおよび本番ワークロードを実行する)（ユーザーが直接データにアクセスしないようにする）  
- [2.3 データの分離モデルを計画する](#23-データ分離モデルを計画する)（機密データは適切な分離レベルで保護）  
- [2.4 本番データをDBFSに保存しない](#24-本番データをdbfsに保存することを避ける)  
- [2.5 Azure Storageファイアウォールを構成する](#25-azure-storageファイアウォールを構成する)（信頼できるネットワークからのアクセスに限定）  
- [2.6 匿名読み取りアクセスを防止＆その他の保護を適用](#26-匿名読み取りアクセスを防止およびその他の保護を適用する)  
- [2.12 Delta Sharing受信者トークンの有効期間を構成する](#212-delta-sharing受信者トークンの有効期間を構成する)  
- [2.13 AESによる機密データの追加暗号化](#213-aesによる機密データの追加暗号化)  
- [2.14 ワークスペース内でのデータ流出防止設定を活用する](#214-ワークスペース内のデータ流出防止設定を活用する)  
- [2.15 Clean Roomsを使用してプライバシーセーフな環境でコラボレーション](#215-clean-roomsを使用してプライバシーセーフな環境でコラボレーションする)  
- [3.3 IPアクセスリストを構成する](#33-ipアクセスリストを構成する)（Delta Sharing保護）  
- [3.5 データ流出防止を目的としたネットワーク制御を実施する](#35-データ流出防止を目的としたネットワーク制御を実施する)（信頼先へのアウトバウンドのみ許可）  
- [3.6 Azure Databricksワークスペースを別のネットワークに分離](#36-azure-databricksワークスペースを別のネットワークに分離する)  
- [3.7 サーバーレスコンピュートアクセス用のファイアウォール構成](#37-サーバーレスコンピュートアクセス用のファイアウォールを構成する)  
- [4.2 機密性の高いワークロードを別ワークスペースに分離](#42-機密性の高いワークロードを別ワークスペースに分離する)  
- [4.3 Unity Catalogセキュラブルを特定ワークスペースに割り当てる](#43-unity-catalogセキュラブルを特定ワークスペースに割り当てる)（機密データへのアクセスを制限）  
- [5.5 信頼できるコードリポジトリのみを使用する](#55-信頼できるコードリポジトリのみ使用する)

**検知**
- [5.1 システムテーブルを活用する](#51-システムテーブルを活用する)（多数の失敗した認可要求、多量の読み書き、アカウント・ワークスペース設定変更などを検出）  
    - 参考：[このブログ](https://www.databricks.com/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.2 Azureログを介してシステム活動を監視する](#52-azureログでシステム活動を監視する)（失敗または不審なEntra ID、データアクセス、ネットワークアクセス試行を特定）

**対応**
- [1.2 SCIMを使用してユーザーとグループを同期](#12-scimを使用してユーザーとグループを同期する)（調査対象のアカウント無効化・削除）  
- [5.3 詳細な監査ログを有効化](#53-詳細な監査ログを有効化する)（データ流出試行に関連するアクションを調査）

## 内部脅威

**リスク説明**  
優秀なエンジニアやデータの専門家は、通常、タスクを完了するための最善または最速の方法を見つけ出しますが、時にそれが組織のセキュリティに影響を及ぼす方法で行われることがあります。セキュリティ制御に対処する必要がなければ仕事がずっと楽になると考えるユーザーもいれば、データ共有を簡素化するためにデータをパブリックストレージアカウントや他のクラウドリソースにコピーするユーザーもいるかもしれません。これらのユーザーに教育を提供することはできますが、企業はガードレールの提供も検討すべきです。

**確率**  
セキュリティプロトコルを回避する方法が多数存在するため、このカテゴリーのリスクの可能性と影響には大きなばらつきがあります。とはいえ、ほとんどのセキュリティ専門家は、これを組織にとって重大な潜在的リスクとして認識しています。

**保護策**
- [1.2 SCIMを使用してユーザーとグループを同期](#12-scimを使用してユーザーとグループを同期する)（適切なアクセスレベル確保）  
- [1.3 管理者ユーザー数を制限する](#13-管理者ユーザー数を制限する)  
- [1.4 管理アカウント間で職務分掌を徹底する](#14-管理アカウント間での職務分掌を徹底する)  
- [1.5 ワークスペース管理者を制限する](#15-ワークスペース管理者を制限する)  
- [1.12 ユーザー分離をサポートするコンピュートを使用](#112-ユーザー分離をサポートするコンピュートを使用する)  
- [1.13 秘密情報を安全に保管および使用](#113-秘密情報を安全に保管し使用する)  
- [2.7 ソフトデリートおよびその他のデータ保護機能を有効化](#27-ソフトデリートおよびその他のデータ保護機能を有効化する)（誤って上書きや削除したデータの復元）  
- [2.8 Azure Storageデータをバックアップ](#28-azure-storageデータをバックアップする)（完全データセットの復元）  
- [2.13 AESによる機密データの追加暗号化](#213-aesによる機密データの追加暗号化)  
- [3.5 データ流出防止を目的としたネットワーク制御を実施](#35-データ流出防止を目的としたネットワーク制御を実施する)（内部の誤ったデータ共有を防止）  
- [3.8 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する](#38-価値のあるコードベースへのアクセスを信頼できるネットワークに限定する)  
- [5.4 Gitフォルダーを用いてコードバージョン管理](#54-gitフォルダーでコードバージョン管理する)（コードをプラットフォーム外にバックアップ）  
- [5.5 信頼できるコードリポジトリのみを使用する](#55-信頼できるコードリポジトリのみ使用する)  
- [5.6 Infrastructure-as-Codeによるインフラ構築](#56-infrastructure-as-codeでインフラを構築する)（本番環境への手動変更禁止）  
- [5.7 CI/CDによるコード管理](#57-cicdでコードを管理する)（承認済みコードのみ本番で実行）

**検知**
- [4.8 Enhanced Security MonitoringまたはCompliance Security Profileを使用する](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)（環境逸脱行為の検出・アラート）  
    - 参考：[こちらのブログ](https://www.databricks.com/blog/2022/09/01/using-enhanced-security-monitoring-detect-alert-suspicious-activity-your-databricks)
- [5.1 システムテーブルを活用](#51-システムテーブルを活用する)（破壊的活動や権限昇格試行の検出）  
- [5.2 Azureログを介してシステム活動を監視](#52-azureログでシステム活動を監視する)（失敗・不審なデータアクセス、ネットワークアクセス）

**対応**
- [1.2 SCIMでユーザーとグループを同期](#12-scimを使用してユーザーとグループを同期する)（内部脅威疑いユーザーの無効化・削除）  
- [4.10 Disaster Recovery戦略を実装しテストする](#410-disaster-recoverydr戦略を実装テストする)（必要に応じたデータ復旧）  
- [5.3 詳細な監査ログを有効化](#53-詳細な監査ログを有効化する)（疑わしい内部者行動の調査）

## サプライチェーン攻撃

**リスク説明**  
従来、サプライチェーン攻撃は、悪意のあるコードをソフトウェアライブラリに注入することに依存していました。そのコードは、標的が気付かないうちに実行されます。しかし最近では、[AIモデルとデータのサプライチェーン攻撃](https://www.databricks.com/blog/deploying-third-party-models-securely-databricks-data-intelligence-platform-and-hiddenlayer)が出現し始めており、モデル自体、その重み、またはデータそのものが悪意を持って改変されるケースが見られます。

**確率**  
適切な保護対策がない場合、サプライチェーン攻撃は攻撃者にとって効果的な戦略となる可能性があります。幸いなことに、このリスクを大幅に低減する保護戦略を容易に適用することができます。

**保護策**
- [3.5 データ流出防止を目的としたネットワーク制御を実施する](#35-データ流出防止を目的としたネットワーク制御を実施する)  
- [4.2 機密性の高いワークロードを別ワークスペースに分離](#42-機密性の高いワークロードを別ワークスペースに分離する)（ユーザーはサンドボックス環境でライブラリを自由に試すことができ、本番環境では信頼できるライブラリのみを使用する）  
- [5.5 信頼できるコードリポジトリのみを使用する](#55-信頼できるコードリポジトリのみ使用する)  
- [5.7 CI/CDによるコード管理](#57-cicdでコードを管理する)（スキャン・承認済みコードのみ本番実行）  
- [5.8 ライブラリインストールを制御する](#58-ライブラリインストールを制御する)（スキャン済み・承認済みライブラリのみ使用）  
- [5.9 信頼できるあるいは評判の良いソースのみからモデルとデータを使用する](#59-信頼できるまたは評判の良いソースのみからモデルとデータを使用する)  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する)（コード、ライブラリ、モデルの自動スキャン）  
- [5.11 Lakehouse Monitoringを使用する](#511-lakehouse-monitoringを使用する)（データ品質変化やデータ中毒攻撃を検知）

**検知**
- [4.8 Enhanced Security MonitoringまたはCompliance Security Profileを使用する](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)（環境からの脱出を試みる可能性のある不審な活動を特定し警告するため）  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する)（コード、ライブラリ、モデルの自動スキャン）

**対応**
- [5.1 システムテーブルを活用する](#51-システムテーブルを活用する)および[Search](https://learn.microsoft.com/ja-jp/azure/databricks/search/)（脆弱性が知られているライブラリ使用状況特定。例については以下ブログを参照）
    - [Databricksワークスペースにおける任意のコードのスキャン](https://www.databricks.com/blog/2022/07/19/scanning-for-arbitrary-code-in-databricks-workspace-with-improved-search-and-audit-logs.html)  
    - [静的解析ツールによるノートブックコマンドログの監視](https://www.databricks.com/blog/2022/11/02/monitoring-notebook-command-logs-static-analysis-tools.html)  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する)（ノートブックコマンド経由のライブラリインストール検出）  
- [5.8 ライブラリインストールを制御する](#58-ライブラリインストールを制御する)（脆弱なライブラリへのアクセス拒否）

## クラウドプロバイダやAzure Databricks自体の潜在的な侵害

**リスク説明**  
セキュリティを重視するお客様は、Azure Databricks自体が侵害される可能性があり、その結果として自身の環境が侵害されるのではないかという懸念を表明することがあります。

Azure DatabricksはMicrosoft製品であり、コントロールプレーンとサーバーレスコンピュートプレーンはMicrosoftが管理するサブスクリプションで実行されているため、お客様はこのリスクを評価する際にMicrosoftのセキュリティプログラムも考慮する必要があります。詳細については、[Microsoft Security and Trust Center](https://www.microsoft.com/en/trust-center/product-overview)を参照するか、必要に応じてAzureの担当者にお問い合わせください。

**確率**  
Azure Databricksは[データインテリジェンスプラットフォーム](https://www.databricks.com/product/data-intelligence-platform)のセキュリティに多大なリソースを投資しており、このようなインシデントのリスクを最小限に抑えるように設計された堅牢なセキュリティプログラムを持っています - プログラムと関連するセキュリティ制御の概要については、[Security and Trust Center](https://www.databricks.com/trust)を参照してください。ただし、どの企業にとってもリスクを完全に排除することはできません。

**保護策**
- [Microsoft](https://www.microsoft.com/en/trust-center/product-overview)および[Databricks](https://www.databricks.com/trust)のSecurity & Trust Centerを参照  
- [4.9 Azure Databricks担当者へのワークスペースアクセスを制御および監視](#49-azure-databricks担当者へのワークスペースアクセスを制御および監視)

**検知**
- [5.1 システムテーブルを活用する](#51-システムテーブルを活用する)（Databricks社員のアクセス行動を監視）  
    - 参考：[こちらのブログ](https://www.databricks.com/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.2 Azureログを介してシステム活動を監視](#52-azureログでシステム活動を監視する)（異常なプロビジョニング活動、疑わしいEntra IDアクセス、データアクセス試行を特定）

**対応**
- [Microsoft](https://www.microsoft.com/en/trust-center/product-overview)および[Databricks](https://www.databricks.com/trust) Security & Trust Centersを確認し、プロセス制御を検討  
- [5.1 システムテーブルを活用する](#51-システムテーブルを活用する)（Databricks社員アクセス監視）  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する)（Databricks社員アクセス監視）
- 万一の事態に備えた対応 
  - [2.9 マネージドサービスに対して顧客管理キーを構成する](#29-マネージドサービスに対して顧客管理キーを構成する)  
  - [2.10 ストレージに対して顧客管理キーを構成する](#210-ストレージに対して顧客管理キーを構成する)  
  - Managed Identity権限の取り消しによるデータアクセス遮断  
  など「最悪のシナリオ」対策を検討

## ランサムウェア攻撃

**リスク説明**  
ランサムウェアは、通常、個人や組織のデータへのアクセスを妨害することを目的とした、脅迫のために設計されたマルウェアの一種です。この攻撃の手段として、多くの場合、暗号化が使用されます。近年、大規模な組織を機能不全に陥れた、注目を集めるランサムウェア攻撃が複数発生しています。

**確率**  
データの大部分はお客様自身のストレージアカウント内に保存されており、これがランサムウェア攻撃のより魅力的な標的となる可能性があります。そのため、ここでは簡単な概要を説明しますが、最も重要なセキュリティ制御は、お客様が自身のストレージに対して設定するものです。

**保護策**
- [2.1 Unity Catalogでデータガバナンスを集中管理](#21-unity-catalogでデータガバナンスを集中管理する)（時間制限トークン使用でデータアクセスを制御）  
- [2.5 Azure Storageファイアウォール構成](#25-azure-storageファイアウォールを構成する)  
- [2.7 ソフトデリートやデータ保護機能の有効化](#27-ソフトデリートおよびその他のデータ保護機能を有効化する)  
- [2.8 Azure Storageデータをバックアップ](#28-azure-storageデータをバックアップする)  
- [2.10 ストレージに対して顧客管理キーを構成する](#210-ストレージに対して顧客管理キーを構成する)  
- [2.11 Delta Sharingを使用する](#211-delta-sharingを使用する)  
- [3.7 サーバーレスコンピュートアクセス用のファイアウォール構成](#37-サーバーレスコンピュートアクセス用のファイアウォールを構成する)  
- [3.8 価値のあるコードベースへのアクセスを信頼できるネットワークに限定](#38-価値のあるコードベースへのアクセスを信頼できるネットワークに限定する)  
- [5.6 Infrastructure-as-Codeでインフラ構築](#56-infrastructure-as-codeでインフラを構築する)（手動変更禁止）

**検知**
- [5.2 Azureログによるシステム活動監視](#52-azure-ログを介してシステム活動を監視する)（不審なEntra ID、データ、CMKアクセスやストレージアカウント構成変更試行）  
- [5.10 DevSecOpsプロセスを実装](#510-devsecopsプロセスを実装する)（コード内資格情報検出）

**対応**
- [2.7 ソフトデリート機能を有効化](#27-ソフトデリートおよびその他のデータ保護機能を有効化する)（誤った上書き・削除・暗号化データの復元）  
- [2.8 Azure Storageデータをバックアップ](#28-azure-storageデータをバックアップする)（必要時に完全復元）  
- [2.10 ストレージに対して顧客管理キーを構成する](#210-ストレージに対して顧客管理キーを構成する)（キーのローテーションや取り消しでアクセス制御）  
- [4.10 Disaster Recovery戦略を実装しテスト](#410-disaster-recoverydr戦略を実装テストする)（必要時のデータ回復）

## リソース悪用

**リスク説明**  
Azure Databricksは大規模なコンピュートをデプロイできます。よってアカウント侵害が起きると、クリプトマイニングなどに悪用される可能性があります。

**確率**  
顕著な事例は多くないものの、顧客から懸念が示されることがあります。

**保護策**
- [1.9 クラスター作成権限を制限する](#19-クラスター作成権限を制限する)  
- [1.10 コンピュートポリシーを使用する](#110-コンピュートポリシーを使用する)（最大サイズやインスタンスタイプ、Spark設定を制限）  
- [5.8 ライブラリインストールを制御する](#58-ライブラリインストールを制御する)（サプライチェーン攻撃防止）  
- [5.15 Azure Policyを使用してリソース上限を設定](#515-azure-policyで上限リソース制御を作成する)

**検知**
- [5.1 システムテーブルを活用](#51-システムテーブルを活用する)（課金対象利用状況の監視）  
- [5.2 Azureログによるシステム活動監視](#52-azureログでシステム活動を監視する)（異常なプロビジョニング活動）  
- [5.10 DevSecOpsプロセスを実装](#510-devsecopsプロセスを実装する)（コード内資格情報検出）  
- [5.13 タグ付けをコスト監視・課金戦略に活用](#513-タグ付けをコスト監視課金戦略に活用する)  
- [5.14 予算を使用してアカウント支出をモニタリング](#514-予算を使用してアカウント支出をモニタリングする)

**対応**
- [1.2 SCIMを使用してユーザーとグループを同期](#12-scimを使用してユーザーとグループを同期する)（調査対象アカウントの無効化・削除）  
- [5.3 詳細な監査ログを有効化](#53-詳細な監査ログを有効化する)（リソース悪用試行関連アクション調査）

# 付録A - セキュリティ構成リファレンス

本ドキュメント中で参照したセキュリティ構成について、以下でより詳細に説明します。参照しやすいよう、これらのセキュリティ構成は以下の包括的なセキュリティ、コンプライアンス、プライバシー原則に基づいて分類しています。

* [最小権限でアイデンティティとアクセスを管理する](#最小権限でアイデンティティとアクセスを管理する)  
* [データの転送中および保存時の保護](#データの転送中および保存時の保護)  
* [ネットワークを保護しエンドポイントを防御する](#ネットワークを保護しエンドポイントを防御する)  
* [コンプライアンスおよびデータプライバシー要件を満たす](#コンプライアンスおよびデータプライバシー要件を満たす)  
* [システムセキュリティを監視する](#システムセキュリティを監視する)

## 最小権限でアイデンティティとアクセスを管理する

アイデンティティ・アクセス管理(IAM)の実践により、適切な人物が適切なリソースにアクセスできるようにします。IAMは以下の側面を扱います：アカウント管理（プロビジョニングを含む）、アイデンティティガバナンス、認証、アクセス制御（認可）、およびアイデンティティフェデレーション

### 1.1 多要素認証を活用する

Azure Databricksは、[Microsoft Entra IDの条件付きアクセス](https://learn.microsoft.com/ja-jp/azure/databricks/admin/access-control/conditional-access)をサポートしており、管理者がAzureリソースへのサインイン条件（信頼できるネットワークからのみ、MFA必須など）を制御できます。

特に高セキュリティ環境では、FIDO2キーなどの物理的な認証トークンを可能な限り使用することを推奨します。これにより、物理トークンがなければ認証できず、MFAをさらに強化できます。

なお、[Microsoft Entra IDの条件付きアクセス](https://learn.microsoft.com/ja-jp/azure/databricks/admin/access-control/conditional-access)はEntra IDで認証する時点でのみ適用されます。すでに認証済みのユーザーがネットワークを変更したり、[個人用アクセストークン(PAT)](https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/pat)などの他の認証手段を使用する場合には適用されません。したがって、包括的なネットワークアクセス制御を行うには、[IPアクセスリスト](#33-ipアクセスリストを構成する)や[Azure Private Link](#34-azure-privatelinkを使用する)との併用を推奨します。

### 1.2 SCIMを使用してユーザーとグループを同期する

SCIM(System for Cross-domain Identity Management)により、[Microsoft Entra IDとAzure Databricks間でユーザーとグループを同期](https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/scim/)できます。このアプローチには3つの大きな利点があります。

1. ユーザー削除時に、自動的にAzure Databricksからも削除されます。  
2. SCIMを通じてユーザーを一時的に無効化できます。顧客はこれをアカウント侵害が疑われる場合の調査のために利用できます。  
3. グループは自動的に同期されます。

Azure Databricksは、[Microsoft Entra IDからAzure Databricksアカウントへのユーザー・グループ同期](https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/best-practices)、[アイデンティティフェデレーションの有効化](https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/best-practices#--enable-identity-federation)、およびSCIMプロビジョニングによるすべてのユーザーとグループの管理を推奨します。

### 1.3 管理者ユーザー数を制限する

ほとんどのシステムと同様に、Databricks内の管理者は拡張された権限を持つため、信頼できる少数の人に限定すべきです。可能であれば、[サービスプリンシパル](#111-サービスプリンシパルを用いて管理タスクおよび本番ワークロードを実行する)と[Infrastructure-as-Code(IaC)](#56-infrastructure-as-codeによるインフラ構築)を用いて管理タスクを自動化します。この推奨事項は、すべての[Azure Databricks管理者ロール](https://learn.microsoft.com/ja-jp/azure/databricks/security/auth-authz/#databricks-admin-roles)に適用されます。

また、[Azure RBAC](https://learn.microsoft.com/ja-jp/azure/role-based-access-control/overview)モデル上、Resource GroupにContributor以上の権限を付与されたユーザーまたはサービスプリンシパルは、Azure Databricksワークスペースにログインすると自動的に管理者になります。同じ考慮事項をAzureポータルユーザー、サービスプリンシパル、マネージドIDにも適用してください。

### 1.4 管理アカウント間での職務分掌を徹底する

セキュリティの一般的なベストプラクティスとして、管理者は特権アカウントを日常業務に使用すべきではありません。Azure Databricksは、ユーザーアカウント間での職務分掌を維持し、以下を確保することを推奨します。

* 同一ユーザーがアカウント管理者・メタストア管理者などの複数の高特権ロールを兼任しないこと  
* Databricks管理者が、通常ユーザーとしての業務用アカウントと管理用アカウントを分離すること

可能な限り、[サービスプリンシパル](#111-サービスプリンシパルを用いて管理タスクおよび本番ワークロードを実行する)と[IaC](#56-infrastructure-as-codeによるインフラ構築)を用いてすべての管理タスクを実行します。この推奨はすべての[Databricks管理者ロール](https://learn.microsoft.com/ja-jp/azure/databricks/security/auth-authz/#databricks-admin-roles)に適用されます。

なお、[Azure RBAC](https://learn.microsoft.com/ja-jp/azure/role-based-access-control/overview)上、リソースグループに共同作成者（Contributor）以上の権限があるユーザーやSPは自動的に管理者となる点にも留意してください。

### 1.5 ワークスペース管理者を制限する

デフォルトでは、ワークスペース管理者は、任意のサービスプリンシパルのジョブ所有者や「run as」設定を変更し、代理トークンを生成できます。[restrict workspace admins設定](https://learn.microsoft.com/ja-jp/azure/databricks/admin/workspace-settings/restrict-workspace-admins)を有効化してこれを防止することをお勧めします。

### 1.6 最小権限の原則に基づいてアクセスを管理する

Azure Databricksにはさまざまな[アクセス制御システム](https://learn.microsoft.com/ja-jp/azure/databricks/security/auth-authz/#--access-control-overview)が存在します。ACLは最小権限の原則に基づいて付与し、ユーザーよりもグループに付与することを推奨します。Unity Catalogのセキュラブルオブジェクトには[継承モデル](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/manage-privileges/#--inheritance-model)に従って、一番下位レベルから権限を付与します。[こちらの提案](https://www.databricks.com/discover/pages/access-control)は、ペルソナベースのアクセス制御を始めるのに役立ちます。

### 1.7 OAuthまたはAzure Entra IDトークン認証を使用する

可能な限り、OAuth（[U2M](https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/oauth-u2m)または[M2M](https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/oauth-m2m)）またはAzure Entra ID認証のみを使用してください。OAuthでは、U2M認証でUIと同様の認証が必要になり、M2Mでは短命なアクセストークンが使われるためリスクが低減します。Azure Entra ID認証も同様にリスクを低減します。

### 1.8 トークン管理を徹底する

[トークン管理](https://learn.microsoft.com/ja-jp/azure/databricks/admin/access-control/tokens)APIやUIで、PATの有効/無効化、使用可能なユーザーの限定、新規トークンの最大存続期間の設定、既存トークンの管理が可能です。可能であれば[Azure Entra IDまたはOAuthトークン認証](#17-oauthまたはazure-entra-idトークン認証を使用する)を利用し、困難な場合はトークン有効期限を短く設定します。  
[こちら](https://learn.microsoft.com/ja-jp/azure/databricks/security/auth/oauth-pat-usage)で提供されているノートブックにより、Azure Databricksアカウント内のPAT使用状況を評価できます。

### 1.9 クラスター作成権限を制限する

[コンピュートポリシー](#110-コンピュートポリシーを使用する)または[クラスター作成権限](https://learn.microsoft.com/ja-jp/azure/databricks/security/auth-authz/entitlements#entitlements-overview)を用いて、どのユーザーまたはグループがクラスターを作成できるかを定義します。また、[コンピュート権限](https://learn.microsoft.com/ja-jp/azure/databricks/compute/clusters-manage#--compute-permissions)で特定のクラスターに対するアクションを制御できます。  
[共有アクセスモードクラスター、SQLウェアハウス、サーバーレスコンピュート](#112-ユーザー分離をサポートするコンピュートを使用する)を可能な限り利用することをお勧めします。

### 1.10 コンピュートポリシーを使用する

[コンピュートポリシー](https://learn.microsoft.com/ja-jp/azure/databricks/admin/clusters/policies)を用いて、クラスターサイズ、利用可能なインスタンスタイプ、ランタイムバージョン、Spark設定などを制御できます。複数のコンピュートポリシーを設定し、特定グループには小規模クラスターのみ、別グループには大規模クラスターも許可、など柔軟に制御可能です。

### 1.11 サービスプリンシパルを用いて管理タスクおよび本番ワークロードを実行する

本番ワークロードを特定ユーザーアカウントに紐づけることはセキュリティ上推奨されません。[サービスプリンシパル](https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/service-principals)を設定して、管理者・ユーザーの操作とワークロードを分離し、ユーザーの離脱による影響を防ぎます。[ジョブ](https://learn.microsoft.com/ja-jp/azure/databricks/workflows/jobs/create-run-jobs#--run-a-job-as-a-service-principal)や[自動化ツール](https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/oauth-m2m)をサービスプリンシパルとして実行可能です。

Azure Databricksでは、Azure Databricks管理のサービスプリンシパルまたはMicrosoft Entra ID管理のサービスプリンシパルを使用できます。Azure Databricksは、DatabricksオートメーションにはAzure Databricks管理のSPを、AzureリソースとDatabricks双方に認証が必要な場合はMicrosoft Entra ID管理のSPを推奨します。

### 1.12 ユーザー分離をサポートするコンピュートを使用する

常に共有または割り当て済み[アクセスモード](https://learn.microsoft.com/ja-jp/azure/databricks/compute/configure#--access-modes)クラスター、SQLウェアハウス、サーバーレスコンピュートを使用します。特に共有アクセスモード、SQLウェアハウス、サーバーレスが望ましいです。これらのコンピュートタイプはユーザー＆ワークロード間に分離境界を設けます。

もし「No isolation shared」クラスターを使用せざるを得ない場合は、[管理者保護](https://learn.microsoft.com/ja-jp/azure/databricks/admin/account-settings/no-isolation-shared)を有効化し、管理者資格情報が他ユーザーと共有環境で保護されるようにします。

### 1.13 秘密情報を安全に保管し使用する

さまざまなシステムとの統合には多くの資格情報管理が必要です。ノートブックに直接資格情報を記述せず、[Azure Databricksの秘密管理](https://learn.microsoft.com/ja-jp/azure/databricks/security/secrets/)を使用して資格情報を安全に保存し、ノートブックやジョブで参照してください。秘密情報はAzure DatabricksまたはAzure Key Vaultに保存可能で、ACLでアクセスを制御します。

Azure Key Vaultを使用する場合でも、同一のサービスIDがすべてのユーザーに対して秘密情報取得を行うため、[Azure Databricks内でアクセス制御](https://learn.microsoft.com/ja-jp/azure/databricks/security/access-control/secret-acl)を定義する必要があります。

## データの転送中および保存時の保護

データを機密度・重要度ごとに分類し、適切な場合には暗号化、トークナイゼーション、アクセス制御などの手段を用いて保護します。

### 2.1 Unity Catalogでデータガバナンスを集中管理する

[Unity Catalog](https://www.databricks.com/product/unity-catalog)は、[Azure Databricks](https://azure.microsoft.com/ja-jp/products/databricks) [Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform)上で、構造化・非構造化データ、機械学習モデル、ノートブック、ダッシュボード、ファイルなどを単一のガバナンスレイヤーで統合管理します。これにより、データ＆AIイニシアチブが加速し、規制遵守が容易になります。

### 2.2 Azure Managed Identityを使用してストレージにアクセスする

Azure Databricksは、[Unity CatalogでのAzure Managed Identities](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/azure-managed-identities)利用を推奨しています。この設定後、ストレージファイアウォールで信頼できないネットワークからのアクセスをブロックすることも推奨します。（コンピュートプレーンは信頼できるネットワークとしてプライベートエンドポイント経由でアクセス可能）。詳細は、[(推奨) Managed Identityに基づく信頼されたAzure Storageアクセスの構成](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/azure-managed-identities#--recommended-for-vnet-injected-workspaces-configure-trusted-access-to-azure-storage-based-on-your-managed-identity)や[サーバーレスコンピュートアクセス用のファイアウォール構成](#37-サーバーレスコンピュートアクセス用のファイアウォールを構成する)を参照してください。

### 2.3 データ分離モデルを計画する

[Unity Catalog](https://www.databricks.com/product/unity-catalog)により、集中型または分散型ガバナンスモデルの選択や、データセット間で異なる分離レベルを適用可能です。[ベストプラクティス](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/best-practices)に従い、事前に[データ分離モデル](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/best-practices#plan-your-data-isolation-model)を計画することを推奨します。

### 2.4 本番データをDBFSに保存することを避ける

DBFSはワークスペース内のすべてのユーザーがアクセス可能で、API経由でもアクセスできます。IPアクセスリストやプライベートネットワークアクセスで制限可能ですが、ユーザー数が増加するとDBFS内のデータが意図せず共有される可能性があります。Azure Databricksは、本番データをDBFSに保存しないことを推奨します。

### 2.5 Azure Storageファイアウォールを構成する

Azure Databricksデプロイには主に2種類のAzureストレージアカウントがあります：ワークスペース作成時に自動生成されるマネージドストレージアカウントと、追加で作成されるストレージアカウントです。

機密データを保存するストレージアカウントには、[ストレージファイアウォール](https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?tabs=azure-portal)を構成し、[仮想ネットワーク](#32-azure-databricksを独自のazure-仮想ネットワークにデプロイ)や[サーバーレスコンピュート](#37-サーバーレスコンピュートアクセス用のファイアウォールを構成する)と[マネージドID](#22-azure-managed-identityを使用してストレージにアクセス)からのアクセスのみ許可します。

ワークスペースに関連付けられたマネージドストレージアカウントはDeny Assignmentで保護され、Azure Databricksワークスペース経由でのみアクセス可能です。高セキュリティなデプロイの場合は、[ワークスペースストレージアカウントに対するファイアウォールサポートの有効化](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/storage/firewall-support)も推奨します。

:::note warn
SQLステートメント実行APIで外部リンクを用いて大規模データセットを取得する場合は、ストレージアカウント上でネットワーク制限を構成してください。[セキュリティベストプラクティス](https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/sql-execution-tutorial#security-best-practices)を参照。
:::

### 2.6 匿名読み取りアクセスを防止およびその他の保護を適用する

管理するストレージアカウントを[Azure Storageのセキュリティベースライン](https://learn.microsoft.com/ja-jp/security/benchmark/azure/baselines/storage-security-baseline)に照らして点検します。特に、[匿名読み取りアクセス](https://learn.microsoft.com/ja-jp/azure/storage/blobs/anonymous-read-access-overview)は許可しないようにし、必要に応じて[顧客管理キー](https://learn.microsoft.com/ja-jp/azure/storage/common/customer-managed-keys-overview)の使用など追加の保護も検討します。

### 2.7 ソフトデリートおよびその他のデータ保護機能を有効化する

Azure Storageは、バックアップや復元を可能にする機能を多数提供しています。必要に応じて以下のようなオプションを検討してください：

* [リソースロック](https://learn.microsoft.com/ja-jp/azure/storage/common/lock-account-resource?tabs=portal)  
* [コンテナ用ソフトデリート](https://learn.microsoft.com/ja-jp/azure/storage/blobs/soft-delete-container-overview)  
* [Blob用ソフトデリート](https://learn.microsoft.com/ja-jp/azure/storage/blobs/soft-delete-blob-overview)  
* [データ冗長性](https://learn.microsoft.com/ja-jp/azure/storage/common/storage-redundancy)

詳しくは、[Azure Storageデータ保護、バックアップ、復旧のベストプラクティス](https://learn.microsoft.com/ja-jp/troubleshoot/azure/azure-storage/blobs/recovery/data-protection-backup-recovery)を参照してください。

### 2.8 Azure Storageデータをバックアップする

定期的なバックアップを作成し、誤削除や破損からの復旧を可能にします。ADLS Gen2ではAzure Backup、Blobバージョニング、ポイントインタイム復元がサポートされていないため、Azure StorageオブジェクトレプリケーションやAzCopyなどのツールで別アカウントにデータをコピーすることが推奨されます。[Deltaクローン](https://learn.microsoft.com/ja-jp/azure/databricks/delta/clone)によるバックアップ作成も可能です。

### 2.9 マネージドサービスに対して顧客管理キーを構成する

[顧客管理キー(CMK)](https://www.databricks.com/trust/security-features/data-protection-with-customer-managed-keys)を用いて、Azure Databricksコントロールプレーンやサーバーレスコンピュートプレーンに保存されたデータ（ノートブック、SQLクエリ、SQLクエリ履歴、秘密情報、PAT、その他の資格情報、ベクターサーチインデックスやメタデータ）を暗号化します。

Azure Databricksは継続的運用でこのキーへのアクセスを必要とします。キーアクセスを取り消すことで、コントロールプレーン（およびバックアップ）にある暗号化データへのアクセスを防ぐことができます。これは「核オプション」に相当し、ワークスペースが機能しなくなりますが、緊急時の制御手段となります。

詳細は、[顧客管理キーによる暗号化](https://learn.microsoft.com/ja-jp/azure/databricks/security/keys/customer-managed-keys)を参照してください。

### 2.10 ストレージに対して顧客管理キーを構成する

計算およびデータプレーンに保存されたデータ（[顧客管理のコンピュートプレーンでアタッチされたAzure Managed Disks](https://learn.microsoft.com/ja-jp/azure/databricks/security/keys/cmk-managed-disks-azure/)、[Databricksワークスペース関連のAzureストレージアカウント](https://learn.microsoft.com/ja-jp/azure/databricks/security/keys/customer-managed-keys-dbfs/)、Unity Catalogが管理・アクセスするAzureストレージアカウントなど）に[顧客管理キー(CMK)](https://www.databricks.com/trust/security-features/data-protection-with-customer-managed-keys)を適用します。

Azure Databricksは継続的運用でキーアクセスを必要としますが、CMKによりコンプライアンス要件を満たし、必要に応じてアクセスを取り消せます。

詳細は、[顧客管理キーによる暗号化](https://learn.microsoft.com/ja-jp/azure/databricks/security/keys/customer-managed-keys)を参照してください。

:::note info
サーバーレスコンピュートは、コンピュートノード上のマネージドディスク暗号化に顧客管理キーを使用しません。サーバーレスコンピュートのマネージドディスクは短命で、コンピュートリソースのライフサイクルに紐づいています。停止またはスケールダウン時にVMやストレージは破棄されます。
:::

### 2.11 Delta Sharingを使用する

[Delta Sharing](https://www.databricks.com/product/delta-sharing)は、データ、アナリティクス、AI間でのデータ共有に対応する初のオープンソースアプローチです。強固なセキュリティとガバナンスを確保しながら、異なるプラットフォーム、クラウド、リージョン間でライブデータを共有できます。[Delta Sharingのセキュリティベストプラクティス](https://www.databricks.com/blog/2022/08/01/security-best-practices-for-delta-sharing.html)に従って機密データを共有してください。

### 2.12 Delta Sharing受信者トークンの有効期間を構成する

[メタストアに対してDelta Sharingを有効化する](https://learn.microsoft.com/ja-jp/azure/databricks/data-sharing/set-up#--enable-delta-sharing-on-a-metastore)際、共有されるデータの機密性に比例した期間（秒、分、時間、日）で受信者トークンの有効期限を設定してください。

### 2.13 AESによる機密データの追加暗号化

Azure DatabricksはAES(Advanced Encryption Standard)による保存時の機密データ列の追加暗号化をサポートします。[aes_encrypt](https://learn.microsoft.com/ja-jp/azure/databricks/sql/language-manual/functions/aes_encrypt)や[aes_decrypt](https://learn.microsoft.com/ja-jp/azure/databricks/sql/language-manual/functions/aes_decrypt)関数を用いて、[秘密情報](#113-秘密情報を安全に保管し使用する)で管理する暗号鍵を使い平文と暗号文を相互変換します。これにより、基盤となるストレージアカウントや暗号鍵が侵害された場合でも、追加の防護層を提供します。

### 2.14 ワークスペース内のデータ流出防止設定を活用する

Azure Databricksワークスペース管理者は、[さまざまな設定](https://learn.microsoft.com/ja-jp/azure/databricks/admin/workspace-settings/)を用いて環境を保護できます。ほとんどは有効/無効を切り替えるシンプルな操作です。重要なものとしては：

- ノートブック結果のダウンロード禁止  
- ノートブックエクスポート禁止  
- SQL結果ダウンロード禁止  
- MLflow実行アーティファクトのダウンロード禁止  
- 結果テーブルのクリップボード機能無効化  
- FileStore Endpointの無効化

### 2.15 Clean Roomsを使用してプライバシーセーフな環境でコラボレーションする

Azure Databricksの[Clean Rooms](https://www.databricks.com/product/clean-room)は、安全かつプライバシーを保護した環境で顧客やパートナーとコラボレーションを可能にします。Clean Roomsにより、無許可アクセスや意図せぬデータ漏えいを防ぎつつ、データ共有が実現します。

詳細は[What is Azure Databricks Clean Rooms?](https://learn.microsoft.com/ja-jp/azure/databricks/clean-rooms/)を参照してください。

## ネットワークを保護しエンドポイントを防御する

ネットワークを保護し、内部・外部エンドポイントの健全性をセキュリティアプライアンスやクラウドファイアウォールなどのサービスで監視・保護します。

### 3.1 Secure Cluster Connectivity(パブリックIPなし)を使用する

[Secure Cluster Connectivity](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/classic/secure-cluster-connectivity)を有効化すると、顧客VNetは外部ネットワークからのインバウンドポート開放が不要になり、DatabricksクラスターのノードはパブリックIPを持ちません。この構成は攻撃面を大幅に削減し、セキュリティを強化するため、すべてのAzure Databricksワークスペースで推奨されます。

### 3.2 Azure Databricksを独自のAzure仮想ネットワークにデプロイする

サーバーレス以外のワークロードでは、Azure Databricksには顧客サブスクリプション内の仮想ネットワークが必要です。Databricksを[独自VNetにデプロイ](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/classic/vnet-inject)し、既存のネットワークアーキテクチャ（ファイアウォールなど）と統合することを推奨します。

:::note info
サーバーレスワークロードでは、コンピュートプレーンネットワークはAzure Databricksが管理・保護するため、管理すべきセキュリティ構成が1つ減ります！
:::

### 3.3 IPアクセスリストを構成する

[IPアクセスリスト](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/front-end/ip-access-list)は、Azure Databricksへのアクセス元IPアドレスを制限します（VPNやオフィスネットワークなど信頼できる範囲）。VPN切断などで信頼できないIPアドレスに接続が変わった場合、確立済みセッションも動作しません。Azure Databricksは、[アカウント](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/front-end/ip-access-list-account)、[ワークスペース](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/front-end/ip-access-list-workspace)、[Delta Sharingの受信者](https://learn.microsoft.com/ja-jp/azure/databricks/data-sharing/access-list)にIPアクセスリストを設定することを推奨します。

### 3.4 Azure PrivateLinkを使用する

[Azure Private Link](https://www.databricks.com/trust/security-features/secure-your-data-with-private-networking)は、[Azure Databricks](https://azure.microsoft.com/ja-jp/products/databricks) [Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform)に対してエンドツーエンドのプライベートネットワーキングを可能にします。Private LinkはAzure Databricksユーザーとコントロールプレーン間、コントロールプレーンとコンピュートプレーン間、コンピュートプレーンとAzureサービス間に設定可能です。

[バックエンドおよびフロントエンド接続用のAzure Private Link](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/classic/private-link)を設定すると、Databricksワークスペースは専用のプライベートチャネル経由でのみアクセス可能になります。

サーバーレスでないワークロードの場合は、[プライベートエンドポイント](https://learn.microsoft.com/ja-jp/azure/storage/common/storage-private-endpoints)を用いて[仮想ネットワーク](#32-azure-databricksを独自のazure-仮想ネットワークにデプロイ)からストレージアカウントに接続できます。

サーバーレスワークロードでは、[ネットワーク接続構成(NCC)](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/#--what-is-a-network-connectivity-configuration-ncc)を作成し、[専用プライベートエンドポイント](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/serverless-private-link)でストレージアカウントに接続します。

詳細は、[Enable Azure Private Link back-end and front-end connections](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/classic/private-link)および[Configure private connectivity from serverless compute](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/serverless-private-link)を参照してください。

:::note info
サーバーレスワークロードでは、コントロールプレーンとコンピュートプレーン間のネットワーキングはAzure Private LinkまたはAzureネットワーク（相互TLS認証と有効なIPへのアクセス限定ファイアウォールポリシー）で管理されるため、管理すべきセキュリティコントロールが1つ減ります！
:::

### 3.5 データ流出防止を目的としたネットワーク制御を実施する

デフォルトでは、Azure環境内のコンピュートプレーンホストは特定サービスやポートへのアウトバウンドアクセスに制限がありません。[独自の仮想ネットワーク](#32-azure-databricksを独自のazure-仮想ネットワークにデプロイ)にデプロイすれば、ファイアウォールでアウトバウンドトラフィックを制限可能です。[Azure Firewall](https://learn.microsoft.com/ja-jp/azure/firewall/overview)を用いた例は[こちらのブログ](https://www.databricks.com/jp/blog/data-exfiltration-protection-with-azure-databricks)参照。Azure Databricksドキュメントで記載のドメインとIPを利用して他のネットワークセキュリティツールにも応用可能です。

コントロールプレーンとコンピュートプレーン間のTLS接続は中断できず、SSL/TLSインスペクションは不可能です。また必要なカスタムTLS証明書は全顧客共通のVHDに事前ロードできません。

### 3.6 Azure Databricksワークスペースを別のネットワークに分離する

複数のワークスペースを同じ[仮想ネットワーク](#32-azure-databricksを独自のazure-仮想ネットワークにデプロイ)にデプロイすることも可能ですが、機密性の高いワークロードには推奨されません。これらのワークロードは、[独自のワークスペース](#42-機密性の高いワークロードを別ワークスペースに分離する)および[独自の仮想ネットワーク](#32-azure-databricksを独自のazure-仮想ネットワークにデプロイ)に分離してください。

共有のDNSなどのリソースが必要な場合は、Azureのハブ＆スポークモデルのベストプラクティスに従います。VNetピアリングでワークスペースVNetのプライベートIP空間をハブに拡張しつつ、スポーク同士は隔離します。

VNet内やピアリングされたネットワークに他のリソースがある場合は、同一VNetまたはピア先VNetの他ネットワーク・サブネットに接続されたNSG（ネットワークセキュリティグループ）に「Deny」ルールを追加し、インバウンドおよびアウトバウンド両方の接続を制限します。クラスターがネットワークリソースにアクセスする必要がある場合は、必要最小限の許可ルールのみ追加してください。[共有リソースとピアリング](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/classic/vnet-inject#shared-resources-and-peering)および[NSGルール](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/classic/vnet-inject#--network-security-group-rules)を参照。

サーバーレスコンピュートでは、[NCC(Network Connectivity Configurations)](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/#serverless-compute-plane-networking-overview)を使って論理的に関連するネットワークを管理します。サーバーレスデータプレーンの論理的な分離を目的にNCCを作成しますが、[ドキュメント化された制限事項](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/serverless-firewall#requirements)も考慮してください。

### 3.7 サーバーレスコンピュートアクセス用のファイアウォールを構成する

サーバーレスワークロードでは、[NCC](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/#--what-is-a-network-connectivity-configuration-ncc)を作成し、[安定した特定のサブネットIDセット](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/serverless-firewall)や[専用プライベートリンクエンドポイント](https://learn.microsoft.com/ja-jp/azure/databricks/security/network/serverless-network-security/serverless-private-link)を使用します。これにより、それらのリソースへのアクセスをこれらの接続に限定し、信頼されたネットワークからのみアクセス可能にできます。

### 3.8 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する

Azure Databricksは、価値のあるコードベースへのアクセスを信頼できるネットワークに限定することを推奨します。これらのコードリポジトリをDatabricks内で利用するには、[パブリック](https://learn.microsoft.com/ja-jp/azure/databricks/repos/repos-setup#network-connectivity-between-databricks-git-folders-and-a-git-provider)または[プライベート](https://learn.microsoft.com/ja-jp/azure/databricks/repos/git-proxy)なネットワーキング制御を適用できます。

### 3.9 仮想ネットワーク暗号化を使用する

[Azure Virtual Network暗号化](https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-encryption-overview)により、Azure VM間のトラフィックをDTLSトンネルで暗号化・復号できます。これにより、内部ネットワーク上のトラフィックは常に暗号化され、[パフォーマンス影響は最小限](https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-encryption-faq#what-is-the-performance-effect)に抑えられます。

## コンプライアンスおよびデータプライバシー要件を満たす

システム設計目標、業界規制、国法、税制、文化的要因などにより、データの保存場所や処理方法を制御する内部・外部要求が存在することがあります。PII(個人識別情報)を匿名化またはマスキングする必要があるかもしれません。可能な限りコンプライアンス対応を自動化してください。

### 4.1 コンピュートを定期的に再起動する

Azure Databricksのクラスターはエフェメラルで、起動時に常に最新のベースイメージとコンテナイメージを使用します。利用者はセキュリティ脆弱性が存在する古いイメージを選択できません（サポート終了したコンテナイメージはUIで非表示だが、手動設定または以前から構成済みの場合は例外）。  
お客様はクラスターを定期的に再起動する責任があります。Azure Databricksはライブパッチを行いません。再起動時により新しいイメージやコンテナが存在する場合、自動的に最新が適用されます。

:::note info
[Automatic cluster restart](https://learn.microsoft.com/ja-jp/azure/databricks/admin/clusters/automatic-cluster-update)は、[compliance security profile](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)有効時に自動で有効化されます。セキュリティ対策1つ減！サーバーレスコンピュートは最大7日で再利用不可となり、バックグラウンドで自動的にリサイクルされます。考慮すべきセキュリティコントロールが1つ減ります！
:::

### 4.2 機密性の高いワークロードを別ワークスペースに分離する

Azure Databricksは、ACLやUnity Catalogのセキュラブルオブジェクトなど、ワークスペース内でのワークロード分離手段を提供しますが、最も強力な分離は機密性の高いワークロードを別ワークスペースに切り出すことです。異なるチーム（例：セキュリティチームとマーケティングチーム）が異なるデータを分析する場合に有効です。

### 4.3 Unity Catalogセキュラブルを特定ワークスペースに割り当てる

ワークスペースを用いてユーザーやデータを分離している場合、Unity Catalogのセキュラブルオブジェクトへのアクセスを特定ワークスペースに限定したい場合があります。これらの割り当て（バインディング）を用いて、[カタログ](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/create-catalogs#--optional-assign-a-catalog-to-specific-workspaces)、[ストレージクレデンシャル](https://learn.microsoft.com/ja-jp/azure/databricks/connect/unity-catalog/storage-credentials#--optional-assign-a-storage-credential-to-specific-workspaces)、[外部ロケーション](https://learn.microsoft.com/ja-jp/azure/databricks/connect/unity-catalog/external-locations#--optional-assign-an-external-location-to-specific-workspaces)を特定ワークスペースに割り当て、機密データアクセスを制限できます。

バインディングは読み取り専用アクセスを付与することもでき、たとえばデータサイエンティストに本番データセットへの読み取り専用アクセスを与えて探索的データ分析を行うシナリオに有用です。

### 4.4 きめ細かなアクセス制御を実装する

機密データセットには、[行フィルターや列マスク](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/row-and-column-filters)によるきめ細かなアクセス制御を実装します。

### 4.5 タグを適用する

[タグ付け](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/tags)を用いて機密データセットを特定・識別し、適切な処理を行いやすくします。タグは[Lakehouse Monitoring](#511-lakehouse-monitoringを使用する)で自動的に適用可能で、[きめ細かなアクセス制御](#44-きめ細かなアクセス制御を実装する)（ABAC含む）にも利用できます。

### 4.6 ライネージを使用する

[Unity Catalogのライネージ](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/data-lineage)を用いて機密データの動きを追跡し、データガバナンスを改善し、規制上要求されるデータ主体要求にも正確に対応できます。

### 4.8 Enhanced Security MonitoringまたはCompliance Security Profileを使用する

[Enhanced Security Monitoring(ESM)とCompliance Security Profile(CSP)](https://www.databricks.com/trust/security-features/protect-your-data-with-enhanced-security-and-compliance)は、Azure Databricksデプロイに最も安全なベースラインを提供します。

[Enhanced Security Monitoring](https://learn.microsoft.com/ja-jp/azure/databricks/security/privacy/enhanced-security-monitoring)は以下を提供します：
1. [CIS Level 1](https://www.cisecurity.org/cis-hardened-images)で強化されたVM  
2. 行動ベースのマルウェア監視およびファイル整合性監視（[Capsule8](https://www.sophos.com/en-us/products/cloud-native-security)）  
3. マルウェア・ウイルス検出（[ClamAV](https://www.clamav.net/)）  
4. 代表的ホストOSからの[Qualys](https://www.qualys.com/)脆弱性レポート

[Compliance Security Profile](https://learn.microsoft.com/ja-jp/azure/databricks/security/privacy/security-profile)は上記に加え、コンプライアンス要件に必要な追加のセキュリティコントロールを提供します：
1. [自動クラスター更新](https://learn.microsoft.com/ja-jp/azure/databricks/admin/clusters/automatic-cluster-update)   
2. [HIPAA](https://learn.microsoft.com/ja-jp/azure/databricks/security/privacy/hipaa)および[PCI-DSS](https://learn.microsoft.com/ja-jp/azure/databricks/security/privacy/pci)準拠機能・コントロール

### 4.9 Azure Databricks担当者へのワークスペースアクセスを制御・監視する

Azure Databricks担当者は、顧客同意なしに顧客ワークスペースや本番マルチテナント環境にアクセスできません。サポート要求を出した場合、お客様は一時的にDatabricks担当者にワークスペースアクセスを付与できます（障害調査やデプロイ支援のため）。

Azure Databricksは、[Azure Databricks担当者へのワークスペースアクセス](https://learn.microsoft.com/ja-jp/azure/databricks/admin/workspace/workspace-access)をデフォルトで無効にし、必要時・時間制限付きで有効化することを推奨します。また、[システムテーブル](#51-システムテーブルを活用する)でそのようなアクセスを監視してください。

### 4.10 Disaster Recovery(DR)戦略を実装・テストする

Azure Databricks自体はDRサービスを提供しませんが、お客様はAzureに保存したデータに対して独自のDR手順（[クラウドネイティブなバックアップサービス](#28-azure-storageデータをバックアップする)や[Deltaクローン](https://learn.microsoft.com/ja-jp/azure/databricks/delta/clone)使用）を実装できます。また、[Delta Live Tablesによるクロスリージョン冗長性](https://www.databricks.com/blog/2023/03/17/production-ready-and-resilient-disaster-recovery-dlt-pipelines.html)を実現可能です。

完全に別のDRサイトへのフェイルオーバーが必要な場合は、Azure Databricks機能を活用して別リージョンにコールド（待機）ワークスペースを作成できます。[Disaster Recoveryガイド](https://learn.microsoft.com/ja-jp/azure/databricks/admin/disaster-recovery)を参照してください。

### 4.11 Azure Confidential Computeの使用を検討する

高度に機密なワークロード（個人データの非特定化など）では、[Azure Confidential Compute](https://azure.microsoft.com/ja-jp/solutions/confidential-compute/)を用いて使用中データを保護することを検討してください。

詳細は[Azure confidential computing VMs](https://learn.microsoft.com/ja-jp/azure/databricks/compute/configure#--azure-confidential-computing-vms)を参照。

## システムセキュリティを監視する

自動化ツールを使用して、アプリケーションやインフラを監視します。CI/CDパイプラインで自動スキャンを行い、脆弱性とセキュリティインシデントを検出してください。

### 5.1 システムテーブルを活用する

[システムテーブル](https://learn.microsoft.com/ja-jp/azure/databricks/admin/system-tables/)は、Delta Lakeでバックアップされ、[Unity Catalog](https://www.databricks.com/product/unity-catalog)でガバナンスされた集中型運用データストアです。コスト監視から[監査ログ](https://learn.microsoft.com/ja-jp/azure/databricks/admin/system-tables/audit-logs)まで様々な目的で利用できます。Databricksはシステムテーブルを設定し、自動モニタリングやアラートを行うことを推奨します。[こちらのブログ](https://www.databricks.com/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)が参考になります。

[Enhanced Security MonitoringまたはCompliance Security Profile](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)を使用中の顧客は、行動ベースのマルウェアおよびファイル整合性監視エージェントが検出した不審な活動に対して[モニタリングおよびアラート設定](https://www.databricks.com/blog/2022/09/01/using-enhanced-security-monitoring-detect-alert-suspicious-activity-your-databricks)が可能です。

### 5.2 Azureログでシステム活動を監視する

「システムが侵害されたことは、システム自身にはわからない。外部から観察できなければならない」というセキュリティ格言があります。[システムテーブル](#51-システムテーブルを活用する)の[監査ログ](https://learn.microsoft.com/ja-jp/azure/databricks/admin/system-tables/audit-logs)はユーザー行動監視に非常に有用ですが、Azure Databricks自体に問題がないか外部から監視するために、Azureログも役立ちます。

[リソースログ](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/resource-logs)、[アクティビティログ](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/activity-log)、[Entra IDログ](https://learn.microsoft.com/ja-jp/entra/identity/monitoring-health/howto-access-activity-logs)、[VNet/NSGフローログ](https://learn.microsoft.com/ja-jp/azure/network-watcher/vnet-flow-logs-overview)は、Azure Databricks（およびユーザー）がコンピュートプレーンとデータプレーンで行うアクションを把握するのに役立ちます。これらは以下の可視性を提供します：

* リソース作成（ビットコインマイニング検出や請求管理）  
* アウトバウンドネットワーク接続（データ流出特定）  
* サブスクリプションレベルイベント（APIコールなど、アカウント不正検出）  
* Unity Catalogを介したデータアクセス

多くの顧客はクラウドプロバイダログ分析用のお気に入りツールを持っていますが、Azure Databricksでも分析可能です。

[Azureドキュメント](https://learn.microsoft.com/ja-jp/azure/azure-monitor/data-sources)を参照してください。

:::note info
*ネットワークレベルの保護（#35-データ流出防止を目的としたネットワーク制御を実施する）を導入した場合、ファイアウォールトラフィックログを監視することが最適解となる場合があります。
:::

### 5.3 詳細な監査ログを有効化する

高度に規制されたドメインでは、ユーザーがシステム上で実行したすべてのコマンドを追跡することが必要な場合があります。Azure Databricksでは[詳細な監査ログ(verbose audit logging)](https://learn.microsoft.com/ja-jp/azure/databricks/admin/account-settings/verbose-logs)を有効化することでこれが可能になり、クエリやコマンドが実行されるたびに[システムテーブル](#51-システムテーブルを活用する)に記録されます。

### 5.4 Gitフォルダーでコードバージョン管理する

Azure Databricksは、[Gitフォルダー](https://learn.microsoft.com/ja-jp/azure/databricks/repos/)を使用してソースコードを管理し、保護することを推奨します。これは一般的なソフトウェア開発ベストプラクティスに沿います。

### 5.5 信頼できるコードリポジトリのみ使用する

ワークスペース管理者は、[ユーザーがクローン＆コミット＆プッシュできるリモートリポジトリを許可リスト化](https://learn.microsoft.com/ja-jp/azure/databricks/repos/repos-setup#--restrict-usage-to-urls-in-an-allow-list)できます。これにより、コードの流出や不正なコードの流入を防ぎます。

### 5.6 Infrastructure-as-Codeでインフラを構築する

[Infrastructure-as-Code(IaC)](https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/index-iac)を用いてインフラを構築すると、多くの利点があります。

* ヒューマンエラーによる構成ミス低減  
* セキュアなベースラインテンプレートで構成ドリフトを軽減  
* IaCツール実行時に構成ドリフトを自動的に修正  
* 手動ミスによる停止や削除のリスク軽減  
* DR/BCシナリオで環境再構築が迅速  
* 管理者ユーザー数削減  
* 日常作業権限も持つ管理者数削減

Azure DatabricksはクラウドおよびDatabricksインフラをIaCで構築し、[サービスプリンシパル](#111-サービスプリンシパルを用いて管理タスクおよび本番ワークロードを実行する)で必要時にのみ資格情報を提供することを推奨します。

:::note info
[Security Reference Architecture (SRA)](https://github.com/databricks/terraform-databricks-sra/tree/main) Terraformテンプレートは、これらのセキュリティベストプラクティスに沿ったDatabricksワークスペースを簡単にデプロイできます！
:::

### 5.7 CI/CDでコードを管理する

成熟した組織は[CI/CD](https://learn.microsoft.com/ja-jp/azure/databricks/repos/ci-cd-techniques-with-repos)を用いて本番ワークロードを構築・デプロイします。これにより、本番環境へのユーザー権限管理やコードスキャン、リンティングなどが統合できます。高度な機密データを扱う場合、CI/CDプロセスでハードコーディングされた秘密情報など特定シナリオをスキャンできます。

### 5.8 ライブラリインストールを制御する

デフォルトでAzure Databricksはpypi、CRAN、Mavenなど標準パブリックリポジトリからPython、R、Scalaライブラリをインストール可能です。

サプライチェーン攻撃を懸念する場合は、Unity Catalogで[信頼できるライブラリの許可リスト](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/manage-privileges/allowlist)を設定できます。

一部のデプロイでは独自のアーティファクトリポジトリをホストし、Databricksがそれらを使用するよう構成できます。サーバーレスワークロード（モデルサービングなど）では、[独自リポジトリからビルドした依存関係をプリパッケージ](https://learn.microsoft.com/ja-jp/azure/databricks/machine-learning/model-serving/private-libraries-model-serving)可能です。

### 5.9 信頼できるまたは評判の良いソースのみからモデルとデータを使用する

モデル・データサプライチェーン攻撃が増加しているため、可能な限り[Azure Databricks foundation models](https://learn.microsoft.com/ja-jp/azure/databricks/large-language-models/foundation-model-training/#--supported-models)や[Azure Databricks Marketplace](https://learn.microsoft.com/ja-jp/azure/databricks/marketplace/)など信頼できるソースからモデルやデータセットを利用してください。

不明な出所のモデル・重みを使用する場合は、[悪意ある・脆弱なコンテンツのスキャン](#510-devsecopsプロセスを実装する)や徹底したテストを行います。不明な出所のデータの場合は十分な探索的データ分析を実施してください。

### 5.10 DevSecOpsプロセスを実装する

データ＆AIコードは、社内でも最重要なコードベースの一つでしょう。他と同等以上の厳格な保証が必要です。顧客は[コード](https://www.databricks.com/blog/2022/11/02/monitoring-notebook-command-logs-static-analysis-tools.html)や[モデル](https://www.databricks.com/blog/deploying-third-party-models-securely-databricks-data-intelligence-platform-and-hiddenlayer)に対し静的・動的分析を実施可能です。

### 5.11 Lakehouse Monitoringを使用する

データ＆AIで成功するには、分析データ品質やモデル予測への信頼性が必要です。[Lakehouse Monitoring](https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse-monitoring/)で、データやモデルの品質、整合性、ドリフトなどを自動的に監視・アラート可能です。Lakehouse Monitoringは以下も可能：

* データ中毒やラベル反転などのデータサプライチェーン攻撃防御  
* PII検出、[タグ付け](#45-タグを適用する)自動適用で[きめ細かなアクセス制御](#44-きめ細かなアクセス制御を実装する)支援  
* 分類モデルの公正性やバイアス監視

### 5.12 Inferenceテーブルを使用する

[Inferenceテーブル](https://learn.microsoft.com/ja-jp/azure/databricks/machine-learning/model-serving/inference-tables)は、モデルサービングエンドポイントへのリクエスト・レスポンスを自動的にキャプチャし、[Unity Catalog](https://www.databricks.com/product/unity-catalog)テーブルにログします。このデータでモデルを監視、デバッグ、改善可能です。Azure Databricksはプレビュー段階でLLMモデルのInferenceテーブルをサポートしています。Inferenceテーブルはプロンプトインジェクション、モデルインバージョン、ジェイルブレイクといったモデル推論攻撃検出にも役立ちます。

### 5.13 タグ付けをコスト監視・課金戦略に活用する

[タグ](https://learn.microsoft.com/ja-jp/azure/databricks/admin/account-settings/usage-detail-tags)をコンピュートやプールに設定し、[Azure Cost Management](https://learn.microsoft.com/ja-jp/azure/cost-management-billing/costs/quick-acm-cost-analysis)までDatabricks利用状況をトレースできます。タグは[請求可能使用量(billable usage)システムテーブル](https://learn.microsoft.com/ja-jp/azure/databricks/admin/system-tables/billing)や[予算](#514-予算を使用してアカウント支出をモニタリングする)と組み合わせることで、コストを360度把握し、チャージバック戦略をサポートします。

### 5.14 予算を使用してアカウント支出をモニタリングする

予算機能でアカウント全体または特定チーム、プロジェクト、ワークスペースの支出を監視できます。

### 5.15 Azure Policyで「上限」リソース制御を作成する

[Azure Policy](https://learn.microsoft.com/ja-jp/azure/governance/policy/overview)は粗めの制御手段ですが、過剰なリソース消費を防ぐ包括的なコントロールを提供します。

# 付録B - 追加リソース

本ドキュメントでは様々な機能を紹介し、可能な限りドキュメントへのリンクを示しました。さらに理解を深めるための追加リソースを以下に示します。

1. [Security and Trust Center](https://databricks.com/trust)で、[Azure Databricks](https://azure.microsoft.com/ja-jp/products/databricks) [Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform)のあらゆるレイヤーに組み込まれたセキュリティ、[プラットフォームアーキテクチャ](https://cms.databricks.com/sites/default/files/2023-04/Databricks-Platform-Security.pdf)、利用可能な[セキュリティ機能](https://www.databricks.com/trust/security-features)、および運用している[責任共有モデル](https://www.databricks.com/sites/default/files/2023-08/databricks-shared-responsibility-model-azure_0.pdf)を理解してください。  
2. [Databricks AI Security Framework (DASF)](https://www.databricks.com/blog/introducing-databricks-ai-security-framework-dasf)を[ダウンロード](https://www.databricks.com/resources/whitepaper/databricks-ai-security-framework-dasf)して、実際の攻撃シナリオに基づくAIセキュリティ脅威への対策方法を理解してください。  
3. [デューディリジェンスパッケージ](https://www.databricks.com/trust/compliance)をダウンロードし、Azure DatabricksアカウントチームからEnterprise Security Guideや追加のコンプライアンスレポートを入手してください。  
4. Azure Databricksアカウントチームに問い合わせて、Azure Databricks Serverless Isolation技術ガイドやサーバーレスペンテスト結果を要求してください。  
5. すべてのワークスペースに対して[Security Analysis Tool](https://docs.databricks.com/en/security/index.html#security-analysis-tool)を設定し、デプロイ構成がベストプラクティスに継続的に準拠しているかレビューしてください。（[詳細](https://www.databricks.com/blog/2023/02/03/announcing-multi-cloud-support-security-analysis-tool-sat.html)）  
6. 良いセキュリティの基礎は堅牢なアーキテクチャです。[Well Architected Framework](https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse-architecture/)を確認してください。  
7. セキュリティ強化のもう1つの柱は強力なデータガバナンスです。[Unity Catalog Best Practices](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/best-practices)を参照してください。  
8. セキュリティチームによる追加コンテンツは[Platform & Security Blogs](https://www.databricks.com/blog/category/platform/security-and-trust)で確認できます。  
9. ビジュアル学習派の方は、[Security Best Practices YouTubeシリーズ](https://www.youtube.com/playlist?list=PLTPXxbhUt-YW5ryIvQo2W5qN4stKMQ5yL)をご覧ください。

以上です。