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

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

https://docs.databricks.com/ja/lakehouse-architecture/security-compliance-and-privacy/best-practices.html

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

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

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

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

# 1. イントロダクション
Databricksは、数千社に及ぶ顧客が、適切な機能を備えた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テンプレートを用いることで、これらのベストプラクティスに従ったDatabricksワークスペースを簡単にデプロイできます。詳細な [セキュリティ構成リファレンス](#付録a-セキュリティ構成リファレンス) セクションでは、SRAで展開可能な制御には以下のチェックを記しています：  
- [x] ***SRAでデプロイ***  
* **モニタ(Monitor):** [Security Analysis Tool (SAT)](https://docs.databricks.com/en/security/index.html#security-analysis-tool) を使用して、セキュリティベストプラクティス遵守状況を継続的に監視します。詳細な [セキュリティ構成リファレンス](#付録a---セキュリティ構成リファレンス) セクションでは、SATで監視可能な制御には以下のチェックを記しています：  
- [x] ***SATでモニタ***

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

# 2. Databricksアーキテクチャ

Databricks [Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform) のアーキテクチャは、権限管理を簡略化し、データ重複を避け、リスク軽減を可能にするために、2つのプレーン(コントロールプレーンとコンピュートプレーン)に分割されています。コントロールプレーンはワークスペースアプリケーションが稼働し、ノートブック、構成、およびクラスターを管理する管理プレーンです。コンピュートプレーンはデータ処理を担うプレーンです。サーバーレス導入の場合、コンピュートプレーンはクラウドサービスプロバイダーアカウントではなくDatabricksアカウント内に存在します。

Databricksプラットフォームが初めての場合は、特定の推奨事項に入る前に、まずアーキテクチャの概要と一般的なセキュリティに関する質問を参照することをお勧めします。詳しくは[Security and Trust Center](https://databricks.com/trust)、特に[アーキテクチャ概要](https://databricks.com/trust/architecture)をご覧ください。

# 3. 一般的なセキュリティ構成

以下に、ほとんどの顧客が使用している代表的なセキュリティ構成例を示します。簡略化のため、「ほとんどのデプロイ」と「高いセキュリティを必要とするデプロイ」に分けています。「ほとんどのデプロイ」は、たとえばMFAで保護されたシングルサインオン(SSO)など、大半の本番またはエンタープライズ展開で見られることが多い構成を指します。「高いセキュリティを必要とするデプロイ」は、特に機密性の高いデータ、知的財産、あるいは医療、ライフサイエンス、金融サービスなどの規制対象業界に見られる構成を表し、Private Link接続や顧客管理鍵の使用などが含まれます。

:::note info
重要: 以下で示す推奨事項は、顧客が実際に構成しているタイプに基づいており、各企業ごとにリスク許容度が異なります。また、あらゆる導入は独自性があるため、以下の推奨事項は網羅的なものではなく、これらに従ってもセキュアであることが保証されるわけではありません。全体的な企業セキュリティフレームワークの文脈で確認し、導入環境およびデータを保護するために必要な対策を決定してください。
:::

## ほとんどのデプロイ

以下の構成は多くの本番Databricks導入環境で見られるものです。もしあまり機密性の高くないデータを扱う小規模なデータサイエンスチームであれば、すべてを必須と感じないかもしれません。逆に、大量の機密データを分析している場合には、これらの構成をより詳細に検討することをお勧めします。

- [ ] [アカウントレベルでのシングルサインオン(SSO)による認証](#11-アカウントレベルでのシングルサインオンssoによる認証)  
- [ ] [マルチファクタ認証(MFA)の活用](#12-マルチファクタ認証mfaの活用)  
- [ ] [IPアクセスリスト](#32-ipアクセスリストを構成する) を用いてアカウント、ワークスペース、Delta Sharingへのアクセスを制限  
- [ ] [Unity Catalogを使用してデータガバナンスを集中管理](#21-unity-catalogを使用してデータガバナンスを集中管理する)  
- [ ] [データ隔離モデル](#22-データ隔離モデルを計画する) および [ワークスペース隔離モデル](#42-機密性の高いワークロードを別のワークスペースに分離する) を計画  
- [ ] [顧客管理VPCを使用](#31-顧客管理vpcを使用する) してネットワーク環境を強化 (今すぐ必要なくても、将来の成功確率向上につながる)  
- [ ] [S3バケットを暗号化し、パブリックアクセスを防ぐ](#24-s3バケットを暗号化しパブリックアクセスを防ぐ)  
- [ ] [S3データのバックアップ](#27-s3データのバックアップ)  
- [ ] [Gitフォルダ](#54-gitフォルダでコードバージョンを管理する) および [CI/CD](#57-cicdでコードを管理する) でコード管理  
- [ ] [管理者ユーザー数を制限](#15-管理者ユーザー数を制限する)、[管理アカウント間での職務分離](#16-管理アカウント間での職務分離を徹底する)、[ワークスペース管理者を制限](#17-ワークスペース管理者を制限する)  
- [ ] [サービスプリンシパル](#113-サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する) で管理タスクや本番ワークロードを実行  
- [ ] [最小権限の原則に従ってアクセスを管理](#18-最小権限の原則に従ってアクセスを管理する)  
- [ ] [ユーザー分離をサポートするコンピュートを使用](#114-ユーザー分離をサポートするコンピュートを使用する)  
- [ ] [システムテーブル](#51-システムテーブルの活用) を用いて構成・監視  
- [ ] [Databricksスタッフによるワークスペースアクセスを制御・監視](#49-databricksスタッフによるワークスペースアクセスを制御監視する)  
- [ ] [OAuthトークン認証](#19-oauthトークン認証を使用する) を使用し、[トークン管理を強制](#110-トークン管理を強制する) してパーソナルアクセストークンの使用を無効または制限  
- [ ] [本番データをDBFSに保管しない](#23-本番データをdbfsに保管しない)  
- [ ] [シークレットを安全に保存・使用](#115-シークレットを安全に保存使用する)  
- [ ] [データ流出防止のためのネットワーク制御を実装](#34-ネットワーク流出防止策を実装する) を検討  
- [ ] [定期的にコンピュートを再起動](#41-定期的にコンピュートを再起動する) して最新パッチを適用  
- [ ] [Delta Sharingを使用](#210-delta-sharingを使用する) & [受信者トークン有効期間を構成](#211-delta-sharingの受信者トークン有効期間を構成する)  
- [ ] [タグ](#513-コストモニタリングとチャージバック戦略のためにタグを使用する) と [予算](#514-予算を使用してアカウント支出を監視する) を使用してコストモニタリングとチャージバック戦略を実装

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

以下は高セキュリティなDatabricks導入環境でよく使用される構成例です。これらはあくまで一般的な例であり、すべての高セキュリティ環境がこれらすべてを使うわけではありません。以下の例を参考に、[脅威モデル](#4-databricksの脅威モデル)や自社のリスク許容度に応じて、既存のセキュリティ対策に適切な項目を組み込みます。

- [ ] [制限付きクロスアカウントIAMロール](#116-制限付きクロスアカウントiamロールを使用する) を使用  
- [ ] [SCIMを使用してユーザーとグループを同期](#14-scimを使用してユーザーとグループを同期する)  
- [ ] フロントエンド [PrivateLink](#33-aws-privatelinkを使用する) の検討  
- [ ] バックエンド [PrivateLink](#33-aws-privatelinkを使用する) の検討  
- [ ] [ネットワーク隔離モデル](#35-機密性の高いワークロードを別のネットワークに分離する) の計画  
- [ ] [ネットワーク流出防止策](#34-ネットワーク流出防止策を実装する) の実装  
- [ ] [顧客管理鍵を使用](#28-マネージドサービスに顧客管理鍵を構成する) および [ストレージに顧客管理鍵を構成](#29-ストレージに顧客管理鍵を構成する) して保存データ暗号化を強化  
- [ ] [AESを用いた機密データ追加暗号化](#212-aesを用いて機密データを追加入力で暗号化する) や [きめ細やかなアクセス制御](#44-きめ細やかなアクセス制御を適用する) を検討  
- [ ] [バケットポリシー適用](#25-バケットポリシーを適用する)  
- [ ] [S3バージョニングの活用](#26-s3バージョニングを使用する) の検討  
- [ ] [トークン管理を強制](#110-トークン管理を強制する) してパーソナルアクセストークン使用防止を検討  
- [ ] [Unity Catalogセキュア対象物を特定のワークスペースに割り当て](#43-unity-catalogセキュア対象物を特定のワークスペースに割り当てる) てワークスペース間でのデータ隔離  
- [ ] [クラスター作成権限を制限](#111-クラスター作成権限を制限する) や [コンピュートポリシー適用](#112-コンピュートポリシーを使用する)  
- [ ] [ワークスペース内のデータ流出防止設定](#213-ワークスペース内のデータ流出防止設定を活用する) のレビュー・構成  
- [ ] [ライブラリ](#58-ライブラリインストールを制御する)、[モデル](#59-信頼できる評判の良いソースからのみモデルやデータを使用する)、[コード](#55-信頼できるコードリポジトリのみを使用するよう制限する) の使用制限を検討  
- [ ] [Enhanced Security MonitoringまたはCompliance Security Profile](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する) の活用  
- [ ] [インフラストラクチャをコードとしてプロビジョニング](#56-インフラストラクチャをコードとしてプロビジョニングする)  
- [ ] [AWS CloudTrailおよびその他ログによるシステム活動監視](#52-aws-cloudtrailおよびその他ログでシステム活動を監視する)  
- [ ] [災害復旧(DR)戦略](#410-災害復旧dr戦略を実装テストする) の設計・実装・テスト

# 4. Databricksの脅威モデル

特にセキュリティ意識の高い顧客は、Databricksのようなプラットフォームに関連する脅威モデルを理解し、特定のリスクに対抗するために活用できるコントロールを把握したいと考えることがあります。もしベストプラクティスに従うことが目的で、特定のセキュリティ懸念がなければ、このセクションは飛ばし、上記のチェックリストに注力してください。

顧客からよく挙がる代表的な脅威カテゴリーは以下の通りです。

1. [アカウント乗っ取りまたは侵害](#アカウント乗っ取りまたは侵害)  
2. [データ流出](#データ流出)  
3. [内部脅威](#内部脅威)  
4. [サプライチェーン攻撃](#サプライチェーン攻撃)  
5. [Databricks自体の潜在的な侵害](#databricks自体の潜在的な侵害)  
6. [ランサムウェア攻撃](#ランサムウェア攻撃)  
7. [リソース悪用](#リソース悪用)

以下では、これらのリスクに関する一般的な質問、発生確率、軽減策を示します。

---

## アカウント乗っ取りまたは侵害

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

**発生確率**  
適切な対策なしでは、アカウント乗っ取りは有効な戦略となり得ます。しかし、適切な戦略を適用することで、このリスクを劇的に低減できます。

**保護策**  
- [1.1 アカウントレベルでのシングルサインオン（SSO）による認証](#11-アカウントレベルでのシングルサインオンssoによる認証)  
- [1.2 マルチファクタ認証(MFA)の活用](#12-マルチファクタ認証mfaの活用)  
- [1.3 統合ログインの有効化 & 緊急アクセスの構成](#13-統合ログインの有効化--緊急アクセスの構成)  
- [1.4 SCIMを使用してユーザーとグループを同期する](#14-scimを使用してユーザーとグループを同期する) により、組織を離れたユーザーを正しくデプロビジョニング  
- [1.9 OAuthトークン認証を使用する](#19-oauthトークン認証を使用する) ことで短命トークンを利用  
- [1.10 トークン管理を強制する](#110-トークン管理を強制する) ことでパーソナルアクセストークンを無効化または寿命を制限  
- [1.15 シークレットを安全に保存・使用する](#115-シークレットを安全に保存使用する) ことでユーザーやシステムの資格情報を保護  
- [3.2 IPアクセスリストを構成する](#32-ipアクセスリストを構成する) で信頼できるパブリックネットワークからのみアクセス許可  
- [3.3 AWS PrivateLinkを使用する](#33-aws-privatelinkを使用する) で信頼できるプライベートネットワークからのみアクセス許可  
- [3.4 ネットワーク流出防止策を実装する](#34-ネットワーク流出防止策を実装する) により、アカウント乗っ取り後のデータ流出を防止  
- [3.7 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する](#37-価値のあるコードベースへのアクセスを信頼できるネットワークに限定する)

**検知策**  
- [5.1 システムテーブルの活用](#51-システムテーブルの活用) により、認証失敗やアクセス試行を確認  
    - 参考: [ブログ記事](https://www.databricks.com/jp/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する) ことでコード中の資格情報を発見可能

**対応策**  
- [1.4 SCIMを使用してユーザーとグループを同期する](#14-scimを使用してユーザーとグループを同期する) ことで疑わしいユーザーを無効化・削除  
- [1.9 OAuthトークン認証を使用する](#19-oauthトークン認証を使用する) ことでOAuthシークレット削除、サービスプリンシパル無効化・削除  
- [1.10 トークン管理を強制する](#110-トークン管理を強制する) でトークンの取り消し・無効化  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する) により、疑わしいアカウント活動を調査可能

---

## データ流出

**リスク説明**  
悪意あるユーザーまたは攻撃者が顧客環境にログインできれば、機密データを外部へ持ち出し、それを保存、販売、または身代金要求に利用する可能性があります。

**発生確率**  
この種の攻撃は、悪意ある内部者またはアカウント侵害を前提としているため、確率は低いと考えられますが、実際に流出したデータを悪用するケースは珍しくありません。

**保護策**  
- [1.13 サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する](#113-サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する) により、可能な限りユーザーが直接機密データにアクセスする必要を減らす  
- [2.2 データ隔離モデルを計画する](#22-データ隔離モデルを計画する) ことで適切な隔離レベルで機密データを保護  
- [2.3 本番データをDBFSに保管しない](#23-本番データをdbfsに保管しない)  
- [2.4 S3バケットを暗号化し、パブリックアクセスを防ぐ](#24-s3バケットを暗号化しパブリックアクセスを防ぐ)  
- [2.5 バケットポリシーを適用する](#25-バケットポリシーを適用する) ことで信頼できるネットワークからのみアクセス可能  
- [2.11 Delta Sharingの受信者トークン有効期間を構成する](#211-delta-sharingの受信者トークン有効期間を構成する)  
- [2.12 AESを用いて機密データを追加入力で暗号化する](#212-aesを用いて機密データを追加入力で暗号化する)  
- [2.13 ワークスペース内のデータ流出防止設定を活用する](#213-ワークスペース内のデータ流出防止設定を活用する)  
- [2.14 Clean Roomsを使用してプライバシー重視の環境でコラボレーションする](#214-clean-roomsを使用してプライバシー重視の環境でコラボレーションする)  
- [3.2 IPアクセスリストを構成する](#32-ipアクセスリストを構成する) でDeltaシェアへのアクセスを制限  
- [3.4 ネットワーク流出防止策を実装する](#34-ネットワーク流出防止策を実装する) でアウトバウンドアクセスを信頼できる宛先のみに制限  
- [3.5 機密性の高いワークロードを別のネットワークに分離する](#35-機密性の高いワークロードを別のネットワークに分離する)  
- [3.6 サーバーレスコンピュートアクセス用のファイアウォールを構成する](#36-サーバーレスコンピュートアクセス用のファイアウォールを構成する)  
- [4.2 機密性の高いワークロードを別のワークスペースに分離する](#42-機密性の高いワークロードを別のワークスペースに分離する)  
- [4.3 Unity Catalogセキュア対象物を特定のワークスペースに割り当てる](#43-unity-catalogセキュア対象物を特定のワークスペースに割り当てる)  
- [5.5 信頼できるコードリポジトリのみを使用するよう制限する](#55-信頼できるコードリポジトリのみを使用するよう制限する)

**検知策**  
- [5.1 システムテーブルの活用](#51-システムテーブルの活用) により失敗した認可要求や大量の読み書き操作、アカウント・ワークスペース設定変更を特定  
    - 参考: [ブログ記事](https://www.databricks.com/jp/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.2 AWS CloudTrailおよびその他ログでシステム活動を監視する](#52-aws-cloudtrailおよびその他ログでシステム活動を監視する) で失敗・不審なロール引受やデータアクセス、ネットワークアクセス試行を検知

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

---

## 内部脅威

**リスク説明**  
優秀なエンジニアやデータプロフェッショナルは仕事を効率化するために最適な方法を選びがちですが、それがセキュリティリスクを生むこともあります。たとえば、あるユーザーがセキュリティ対策を回避しようとしたり、パブリックなS3バケットや他のクラウドリソースにデータをコピーしてしまうことが考えられます。教育による対策は可能ですが、企業としてガードレールを設けるべきです。

**発生確率**  
セキュリティ対策を回避する方法は多岐にわたるため、リスクの発生確率と影響度は大きく変動しますが、ほとんどのセキュリティ専門家はこのリスクを重要視します。

**保護策**  
- [1.4 SCIMを使用してユーザーとグループを同期する](#14-scimを使用してユーザーとグループを同期する) ことで適切な権限を維持  
- [1.5 管理者ユーザー数を制限する](#15-管理者ユーザー数を制限する)  
- [1.6 管理アカウント間での職務分離を徹底する](#16-管理アカウント間での職務分離を徹底する)  
- [1.7 ワークスペース管理者を制限する](#17-ワークスペース管理者を制限する)  
- [1.14 ユーザー分離をサポートするコンピュートを使用する](#114-ユーザー分離をサポートするコンピュートを使用する) でユーザー・ワークロードを分離  
- [1.15 シークレットを安全に保存・使用する](#115-シークレットを安全に保存使用する)  
- [2.6 S3バージョニングを使用する](#26-s3バージョニングを使用する) で誤って上書き・削除したデータを復元可能にする
- [2.7 S3データのバックアップ](#27-s3データのバックアップ) で必要な場合にデータセットを完全復元  
- [2.12 AESを用いて機密データを追加入力で暗号化する](#212-aesを用いて機密データを追加入力で暗号化する)  
- [3.4 ネットワーク流出防止策を実装する](#34-ネットワーク流出防止策を実装する) は、悪意ある攻撃者だけでなく誤った内部者による露出にも有効  
- [3.7 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する](#37-価値のあるコードベースへのアクセスを信頼できるネットワークに限定する)  
- [5.4 Gitフォルダでコードバージョンを管理する](#54-gitフォルダでコードバージョンを管理する) ことでコードをプラットフォーム外部でバックアップ  
- [5.5 信頼できるコードリポジトリのみを使用するよう制限する](#55-信頼できるコードリポジトリのみを使用するよう制限する)  
- [5.6 インフラストラクチャをコードとしてプロビジョニングする](#56-インフラストラクチャをコードとしてプロビジョニングする) ことで本番環境への手動変更を防止  
- [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-システムテーブルの活用) で破壊的活動(セッション内で大量削除)や権限昇格試行(セッション内で大量のパーミッション変更)を特定  
    - 参考: [ブログ記事](https://www.databricks.com/jp/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.2 AWS CloudTrailおよびその他ログでシステム活動を監視する](#52-aws-cloudtrailおよびその他ログでシステム活動を監視する) で失敗・不審なデータアクセスやネットワークアクセス試行を検知

**対応策**  
- [1.4 SCIMを使用してユーザーとグループを同期する](#14-scimを使用してユーザーとグループを同期する) ことで疑わしい内部者を無効化・削除  
- [2.6 S3バージョニングを使用する](#26-s3バージョニングを使用する) で誤って上書き・削除・破壊されたデータを復元  
- [2.7 S3データのバックアップ](#27-s3データのバックアップ) で必要な場合にデータセットを完全復元  
- [4.10 災害復旧(DR)戦略を実装・テストする](#410-災害復旧dr戦略を実装テストする) でデータを復旧  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する) で内部者による事故的または悪意ある行為を調査可能

---

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

**リスク説明**  
従来、サプライチェーン攻撃はソフトウェアライブラリへの悪意あるコード注入に依存していました。しかし、近年では[AIモデルやデータのサプライチェーン攻撃](https://www.databricks.com/blog/deploying-third-party-models-securely-databricks-data-intelligence-platform-and-hiddenlayer)が発生しており、モデルやその重み、データ自体が悪意ある形で改変される可能性があります。

**発生確率**  
適切な対策なしでは、サプライチェーン攻撃は有効な戦略になり得ますが、適切な防御策を講じればリスクは劇的に低減します。

**保護策**  
- [3.4 ネットワーク流出防止策を実装する](#34-ネットワーク流出防止策を実装する) は、サプライチェーン攻撃に対しても有効  
- [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を使用する) で環境逸脱行動を検知  
    - 参考: [ブログ記事](https://www.databricks.com/blog/2022/09/01/using-enhanced-security-monitoring-detect-alert-suspicious-activity-your-databricks)  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する) によりコード、ライブラリ、モデルを自動スキャン

**対応策**  
- [5.1 システムテーブルの活用](#51-システムテーブルの活用) および [検索機能](https://docs.databricks.com/en/search/index.html) で既知脆弱性ライブラリを特定  
    - 参考: [脆弱なコードスキャン例](https://www.databricks.com/blog/2022/07/19/scanning-for-arbitrary-code-in-databricks-workspace-with-improved-search-and-audit-logs.html)  
    - 参考: [Notebookコマンドログ監視例](https://www.databricks.com/blog/2022/11/02/monitoring-notebook-command-logs-static-analysis-tools.html)  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する) でNotebookコマンドによるライブラリインストールを特定  
- [5.8 ライブラリインストールを制御する](#58-ライブラリインストールを制御する) で脆弱性のあるライブラリを使用禁止

---

## Databricks自体の潜在的な侵害

**リスク説明**  
セキュリティ意識の高い顧客は、Databricks自体が侵害され、その結果自社環境が侵害される可能性を懸念することがあります。

**発生確率**  
Databricksは、[Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform)のセキュリティに多大なリソースを投資しており、[Security and Trust Center](https://www.databricks.com/trust) で概要と関連セキュリティ対策を確認できます。しかし、いかなる企業においてもリスクを完全に排除することは不可能です。

**保護策**  
- Databricks [Security & Trust Center](https://www.databricks.com/trust) をレビューして必要なプロセス管理  
- [1.16 制限付きクロスアカウントIAMロールを使用する](#116-制限付きクロスアカウントiamロールを使用する) でIAMロール侵害リスクを軽減  
- [4.9 Databricksスタッフによるワークスペースアクセスを制御・監視する](#49-databricksスタッフによるワークスペースアクセスを制御監視する)

**検知策**  
- [5.1 システムテーブルの活用](#51-システムテーブルの活用) でDatabricks社員のアクティビティを監視  
    - 参考: [ブログ記事](https://www.databricks.com/jp/blog/improve-lakehouse-security-monitoring-using-system-tables-databricks-unity-catalog)  
- [5.2 AWS CloudTrailおよびその他ログでシステム活動を監視する](#52-aws-cloudtrailおよびその他ログでシステム活動を監視する) で  
  - 不審なプロビジョニング活動  
  - 不審または失敗したロール引受試行  
  - 不審または失敗したデータアクセス試行  
  を特定

**対応策**  
- Databricks [Security & Trust Center](https://www.databricks.com/trust) をレビューし、必要なプロセス対策を検討  
- [5.1 システムテーブルの活用](#51-システムテーブルの活用) および  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する) によりDatabricks社員のアクティビティを監視・調査  
- 万が一の事態に備えた対策を準備：  
  - [1.16 制限付きクロスアカウントIAMロールを使用する](#116-制限付きクロスアカウントiamロールを使用する) を無効化してDatabricksによるリソースデプロイを阻止  
  - [2.8 マネージドサービスに顧客管理鍵を構成する](#28-マネージドサービスに顧客管理鍵を構成する) や [2.9 ストレージに顧客管理鍵を構成する](#29-ストレージに顧客管理鍵を構成する) で顧客管理鍵を取り消しアクセス拒否（元に戻せない可能性あり）

---

## ランサムウェア攻撃

**リスク説明**  
ランサムウェアは、データへのアクセスを拒否するマルウェアの一種で、身代金目的で暗号化が利用されます。近年、大規模組織を麻痺させたランサムウェア攻撃がいくつも報告されています。

**発生確率**  
大半のデータは顧客のS3バケットに保管されており、そこが主要な攻撃対象となる可能性があります。ここでは簡単に対策を示しますが、最も重要な対策は顧客自身のストレージにおけるセキュリティコントロールです。

**保護策**  
- [2.1 Unity Catalogを使用してデータガバナンスを集中管理する](#21-unity-catalogを使用してデータガバナンスを集中管理する) で時間制限・スコープ縮小トークンのみでデータアクセス  
- [2.4 S3バケットを暗号化し、パブリックアクセスを防ぐ](#24-s3バケットを暗号化しパブリックアクセスを防ぐ)  
- [2.5 バケットポリシーを適用する](#25-バケットポリシーを適用する)  
- [2.6 S3バージョニングを使用する](#26-s3バージョニングを使用する) で上書き・削除・破損データを復旧可能  
- [2.7 S3データのバックアップ](#27-s3データのバックアップ) で必要な場合に完全復元  
- [2.9 ストレージに顧客管理鍵を構成する](#29-ストレージに顧客管理鍵を構成する) で暗号化鍵に対する制御と可視性を強化  
- [2.10 Delta Sharingを使用する](#210-delta-sharingを使用する) で読み取り専用・時間制限・スコープ縮小トークンによるデータアクセス  
- [3.6 サーバーレスコンピュートアクセス用のファイアウォールを構成する](#36-サーバーレスコンピュートアクセス用のファイアウォールを構成する)  
- [3.7 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する](#37-価値のあるコードベースへのアクセスを信頼できるネットワークに限定する)  
- [5.6 インフラストラクチャをコードとしてプロビジョニングする](#56-インフラストラクチャをコードとしてプロビジョニングする) で本番環境への手動変更を防止

**検知策**  
- [5.2 AWS CloudTrailおよびその他ログでシステム活動を監視する](#52-aws-cloudtrailおよびその他ログでシステム活動を監視する) で疑わしいIAM、データ、CMKアクセス試行やS3バケット設定変更試行を特定  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する) でコード中の資格情報を発見

**対応策**  
- [2.6 S3バージョニングを使用する](#26-s3バージョニングを使用する) で誤って上書き・削除・破壊されたデータを復元  
- [2.7 S3データのバックアップ](#27-s3データのバックアップ) で必要に応じて完全復元  
- [2.9 ストレージに顧客管理鍵を構成する](#29-ストレージに顧客管理鍵を構成する) で鍵のローテーションや取り消しを実施  
- [4.10 災害復旧(DR)戦略を実装・テストする](#410-災害復旧dr戦略を実装テストする) でデータ復旧

---

## リソース悪用

**リスク説明**  
Databricksは大量のコンピュートリソースを提供可能なため、ユーザーアカウントが侵害されれば、攻撃者は仮想通貨マイニングなどに悪用する可能性があります。

**発生確率**  
実例は多くありませんが、顧客が懸念を持つことはあります。

**保護策**  
- [1.11 クラスター作成権限を制限する](#111-クラスター作成権限を制限する)  
- [1.12 コンピュートポリシーを使用する](#112-コンピュートポリシーを使用する) で最大サイズやコンピュートタイプを制限  
- [1.16 制限付きクロスアカウントIAMロールを使用する](#116-制限付きクロスアカウントiamロールを使用する)  
- [5.8 ライブラリインストールを制御する](#58-ライブラリインストールを制御する) でサプライチェーン攻撃によるリソース悪用を軽減  
- [5.15 AWSサービスクォータを使用する](#515-awsサービスクォータを使用する) で利用可能リソースを制限

**検知策**  
- [5.1 システムテーブルの活用](#51-システムテーブルの活用) により請求対象利用を監視  
- [5.2 AWS CloudTrailおよびその他ログでシステム活動を監視する](#52-aws-cloudtrailおよびその他ログでシステム活動を監視する) で異常なプロビジョニング活動を特定  
- [5.10 DevSecOpsプロセスを実装する](#510-devsecopsプロセスを実装する) でコード中の資格情報を発見  
- [5.13 コストモニタリングとチャージバック戦略のためにタグを使用する](#513-コストモニタリングとチャージバック戦略のためにタグを使用する)  
- [5.14 予算を使用してアカウント支出を監視する](#514-予算を使用してアカウント支出を監視する)

**対応策**  
- [1.4 SCIMを使用してユーザーとグループを同期する](#14-scimを使用してユーザーとグループを同期する) で疑わしいユーザーを無効化・削除  
- [5.3 詳細な監査ログを有効化する](#53-詳細な監査ログを有効化する) でリソース悪用試行に関連するアクションを調査可能

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

本書で参照されるセキュリティ構成について、以下で詳細に説明します。参照しやすいように、これらのセキュリティ構成は以下の包括的なセキュリティ、コンプライアンス、プライバシー原則にグループ化しています。

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

## IDとアクセスを最小権限で管理する

IDおよびアクセス管理（IAM）のプラクティスは、適切な人物が適切なリソースにアクセスできるようにすることを支援します。IAMは以下の側面に対応します：アカウント管理（プロビジョニングを含む）、IDガバナンス、認証、アクセス制御（認可）、およびIDフェデレーション。

### 1.1 アカウントレベルでのシングルサインオン（SSO）による認証

Databricksは[SAML 2.0またはOpenID Connect (OIDC)](https://docs.databricks.com/en/admin/account-settings-e2/single-sign-on/index.html)を介したIdPとの間での[シングルサインオン(SSO)](https://docs.databricks.com/en/admin/account-settings-e2/single-sign-on/index.html)をサポートしています。

SSOはアカウントおよびワークスペースレベルの両方で構成できますが、Databricksはすべてのワークスペースに対して[統合ログインを有効](https://docs.databricks.com/en/admin/account-settings-e2/single-sign-on/index.html#enable-unified-login)にし、単一のアカウントレベルSSO構成を使用することを推奨します。

### 1.2 マルチファクタ認証(MFA)の活用

ほとんどのIdPはMFAソリューションを直接提供するか、またはMFAソリューションと統合できます。多くのDatabricks顧客はDatabricksへのログイン時、またはVPN要件によってユーザーログイン時にMFAプロンプトを要求しています。

セキュリティが非常に厳しい環境では、Databricksは可能な限りFIDO2キーなどの物理的認証トークンの使用を推奨します。これらのキーは、物理的トークンとの対話を必要とすることで、従来のMFAを強化します。

### 1.3 統合ログインの有効化 & 緊急アクセスの構成

[統合ログインが有効](https://docs.databricks.com/en/admin/account-settings-e2/single-sign-on/index.html#enable-unified-login)な場合、アカウントおよびワークスペース管理者を含むすべてのユーザーはSSOでDatabricksにサインインする必要があります。

ロックアウトを防ぐために、アカウント管理者は[緊急アクセス](https://docs.databricks.com/en/admin/account-settings-e2/single-sign-on/index.html#configure-emergency-access)を最大10人まで構成し、これらのユーザーがセキュリティキーを用いたMFAでDatabricksにログインできるようにします。Databricksは、緊急アクセスでサインインするユーザーが強力なパスワードと少なくとも1つのFIDO2ハードウェアセキュリティキーを設定することを推奨します。

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

SCIM（System for Cross-domain Identity Management）を使用すると、[IdPとDatabricks間でユーザーおよびグループを同期](https://docs.databricks.com/en/admin/users-groups/scim/index.html)できます。このアプローチには以下の3つの主要な利点があります。

1. ユーザーを削除すると、そのユーザーは自動的にDatabricksからも削除されます。  
2. ユーザーを一時的に無効化することもできます。アカウントが危険にさらされている可能性がある場合に有用です。  
3. グループが自動的に同期されます。

Databricksは、アカウントレベルのSCIMプロビジョニングを使用してアカウント内のすべてのユーザーを管理することを推奨します。

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

ほとんどのシステムと同様に、Databricks内の管理者には昇格された特権があります。これらは組織内の信頼できる少数の人にのみ拡張すべきです。可能な場合は、[サービスプリンシパル](#113-サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する)を介した自動化によって、[IaC(Infrastructure as Code)](#56-インフラストラクチャをコードとしてプロビジョニングする)で管理作業を行うことを推奨します。この推奨事項は、すべてのDatabricks管理者ロールに適用されます。

- [x] ***SATによるモニタリング***

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

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

* 同一ユーザーが複数の高度に特権的なロール（アカウント管理者およびメタストア管理者など）を共有しないこと  
* Databricks管理者が日常的な作業を行う通常のユーザーアカウントとは別に、管理タスク用のユーザーアカウントを使用すること

可能な限り、[サービスプリンシパル](#113-サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する)を使用した自動化により、[IaC](#56-インフラストラクチャをコードとしてプロビジョニングする)で管理タスクを実行することを推奨します。これらの推奨事項はすべてのDatabricks管理者ロールに適用されます。

- [x] ***SATによるモニタリング***

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

デフォルトでは、ワークスペース管理者はジョブオーナーまたは代行実行設定を変更し、ワークスペース内の任意のサービスプリンシパルの代理トークンを生成できます。Databricksは、[ワークスペース管理者を制限する](https://docs.databricks.com/en/admin/workspace-settings/restrict-workspace-admins.html)設定を有効にし、これを防ぐことを推奨します。

- [x] ***SATによるモニタリング***

### 1.8 最小権限の原則に従ってアクセスを管理する

Databricks内には、さまざまなセキュア対象物に対する異なる[アクセス制御システム](https://docs.databricks.com/en/security/auth-authz/index.html#access-control-overview)があります。Databricksは、アクセス制御リスト(ACL)を最小権限の原則に従って割り当て、ユーザー個人ではなくグループにACLを付与することを推奨します。Unity Catalogのセキュア対象物に対しては、[継承モデル](https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/index.html#inheritance-model)の最下位レベルでアクセス権を管理します。[この提案](https://www.databricks.com/discover/pages/access-control)は、ペルソナベースのアクセス制御を導入するのに役立ちます。

- [x] ***SATによるモニタリング***

### 1.9 OAuthトークン認証を使用する

可能な限り、顧客はOAuthによる[ユーザー・マシン間(U2M)](https://docs.databricks.com/en/dev-tools/auth/oauth-u2m.html)および[マシン間(M2M)](https://docs.databricks.com/en/dev-tools/auth/oauth-m2m.html)認証を使用すべきです。OAuthはリスクを低減します。U2MではユーザーはUIでのログインと同様に認証が必要になり、M2Mではメモリ上の資格情報は短命なアクセストークンとなります。コードは新しいアクセストークンを要求するためにシークレットを参照する必要がありますが、そのシークレットは安全な場所（例：AWS Secrets Manager）に格納し、新しいアクセストークン要求時のみ取得できます。

- [x] ***SRAによるデプロイ***

### 1.10 トークン管理を強制する

顧客は[トークン管理](https://docs.databricks.com/administration-guide/access-control/tokens.html)APIまたはUIを使用して、REST API認証に使用されるパーソナルアクセストークン(PAT)を有効または無効にし、PATを使用できるユーザーを制限し、新しいトークンの最大有効期間を設定し、既存のトークンを管理できます。可能であれば、高度にセキュアな顧客には[OAuthトークン認証](#19-oauthトークン認証を使用する)を推奨します。それが不可能な場合は、新しいトークンの最大有効期間を短くすることを推奨します。[こちら](https://docs.databricks.com/en/security/auth/oauth-pat-usage.html)のノートブックを使用して、Databricksアカウント内でのPAT使用状況を評価できます。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

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

[コンピュートポリシー](#112-コンピュートポリシーを使用する)または[クラスター作成エンタイトルメント](https://docs.databricks.com/en/security/auth-authz/entitlements.html#entitlements-overview)を使用すると、組織内でクラスターを作成できるユーザーやグループを制御できます。

[コンピュートパーミッション](https://docs.databricks.com/en/compute/clusters-manage.html#cluster-level-permissions)により、特定のクラスターに対してどのユーザーがどのアクションを行えるかを指定できます。また、[ユーザー分離をサポートするコンピュート](#114-ユーザー分離をサポートするコンピュートを使用する)も考慮に入れてください。可能な限り共有アクセスモードクラスタ、SQLウェアハウス、サーバーレスコンピュートを優先することを推奨します。

- [x] ***SATによるモニタリング***

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

Databricks管理者は、[コンピュートポリシー](https://docs.databricks.com/en/admin/clusters/policies.html)を使用してクラスターのサイズ、使用可能なインスタンスタイプ、ランタイムバージョン、Spark構成設定などを制御できます。管理者は複数のコンピュートポリシーを構成でき、特定のグループには小規模なクラスター作成を許可し、別のグループには大規模クラスターの作成を許可、他のグループには既存クラスターのみ利用可能などの制御が可能です。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

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

本番ワークロードを個々のユーザーアカウントに紐付けるのはセキュリティベストプラクティスに反します。そのため、[サービスプリンシパル](https://docs.databricks.com/en/admin/users-groups/service-principals.html)をDatabricks内で構成することを推奨します。サービスプリンシパルは管理者とユーザーのアクションをワークロードから分離し、ユーザーが組織を離れてもワークロードへの影響を防ぎます。Databricksでは、[ジョブ](https://docs.databricks.com/en/workflows/jobs/create-run-jobs.html#run-as-sp)や[自動化ツール](https://docs.databricks.com/en/dev-tools/auth/oauth-m2m.html#language-Terraform)をサービスプリンシパルとして実行するよう構成できます。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

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

顧客は、常に共有または割り当て済みアクセスモードクラスタ、SQLウェアハウス、またはサーバーレスコンピュートを使用すべきで、共有アクセスモード、SQLウェアハウス、サーバーレスを優先すべきです。これらのコンピュートタイプはユーザーやワークロード間に分離境界を提供します。

もしNo isolation sharedクラスタを使用せざるを得ない場合は、[admin protectionを有効化](https://docs.databricks.com/en/admin/account-settings/no-isolation-shared.html)して、他のユーザーと共有される環境で管理者認証情報を保護してください。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 1.15 シークレットを安全に保存・使用する

異種システムとの統合には大量の資格情報管理が必要です。ノートブックに直接資格情報を入力する代わりに、Databricksシークレットを使用して資格情報を格納し、ノートブックやジョブで参照してください。[Databricksシークレット管理](https://docs.databricks.com/security/secrets/index.html#secrets-user-guide)は資格情報を安全に使用・共有可能です。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 1.16 制限付きクロスアカウントIAMロールを使用する

非サーバーレスワークロードでは、Databricksは[クロスアカウントIAMロール](https://docs.databricks.com/administration-guide/account-api/iam-role.html)を使用してDatabricksアカウントがAWSアカウント内でアクションを実行します。顧客はデフォルトロールの権限を制限できるかをよく尋ねます。

権限を制限する際は、適切な開始点があるか確認してください。デフォルトでは[ドキュメント](https://docs.databricks.com/administration-guide/account-api/iam-role.html)は簡略化した権限セットを示しています。しかし、セキュリティ重視の顧客は[顧客管理VPC](#31-顧客管理vpcを使用する)を使用することで、必要な権限数を減らせます。必要な権限とその目的については[このガイド](https://docs.databricks.com/en/admin/cloud-configurations/aws/permissions.html)を参照してください。

## データを転送中および保管時に保護する

データを機密性および重要度に応じて分類し、適切な場合に暗号化、トークン化、アクセス制御などのメカニズムを使用してください。

### 2.1 Unity Catalogを使用してデータガバナンスを集中管理する

[Unity Catalog](https://www.databricks.com/product/unity-catalog)は、Databricksの[Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform)内でデータおよびAIの統一的なガバナンス層を提供します。これにより、構造化・非構造化データ、機械学習モデル、ノートブック、ダッシュボード、ファイルをあらゆるクラウド・プラットフォームで統一的にガバナンスできます。このアプローチにより、データとAIの取り組みが加速し、規制遵守が容易になります。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 2.2 データ隔離モデルを計画する

[Unity Catalog](https://www.databricks.com/product/unity-catalog)では、集中および分散ガバナンスモデルを選択でき、データセット間にさまざまな隔離レベルを適用できます。Databricksは、[ベストプラクティス](https://docs.databricks.com/en/data-governance/unity-catalog/best-practices.html)に従い、[データ隔離モデル](https://docs.databricks.com/en/data-governance/unity-catalog/best-practices.html#plan-your-data-isolation-model)を事前に計画することを推奨します。

### 2.3 本番データをDBFSに保管しない

デフォルトでDBFSはワークスペースのすべてのユーザーがアクセス可能で、API経由でアクセス可能です。これ自体は大きなデータ流出リスクではないかもしれませんが、ワークスペース内ユーザーが増えるとすべてのユーザーがDBFS上のデータにアクセス可能となり、望まれない情報共有が発生します。Databricksは、本番データをDBFSに保管しないことを推奨します。また、DatabricksはAWS用のバケットポリシーを提供可能で、DBFSへの本番データ保管を防止できます。

- [x] ***SATによるモニタリング***

### 2.4 S3バケットを暗号化し、パブリックアクセスを防ぐ

S3バケットは、Databricksデプロイで2つの役割を果たします：Databricks初期設定時に提供するルートS3バケットとデータ格納用の追加バケットです。これらバケットについては、[デフォルトでの暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html)または[個別バケットごとの暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html)を行い、[パブリックアクセスをブロック](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)する必要があります。

これらのS3バケットは顧客責任で構成を確認する必要があります。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 2.5 バケットポリシーを適用する

[S3バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)を使用して、[ネットワークアクセス制限](https://docs.databricks.com/en/security/network/classic/customer-managed-vpc.html#optional-restrict-access-to-s3-buckets)や[サーバーレスコンピュートアクセス用ファイアウォール](#36-サーバーレスコンピュートアクセス用のファイアウォールを構成する)などの保護を適用します。

:::note info
大量のデータセットをSQL Statement Execution API経由で取得する場合は、ストレージアカウントにネットワーク制限を構成することをDatabricksは推奨します。詳細は[Security best practices](https://docs.databricks.com/en/dev-tools/sql-execution-tutorial.html#security-best-practices)を参照してください。
:::

- [x] ***SRAによるデプロイ*** 

### 2.6 S3バージョニングを使用する

[S3オブジェクトバージョニング](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)を使用して古いバージョンのデータを保持し、誤削除や上書きから復旧可能にします。

DatabricksがDBFSにデータを格納する方法のため、DBFS用バケットにはS3バージョニングは推奨されません。

### 2.7 S3データのバックアップ

[S3データの定期的なバックアップ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/backup-for-s3.html)を行い、誤削除や破損からの復旧を可能にします。

### 2.8 マネージドサービスに顧客管理鍵を構成する

Databricksコントロールプレーンおよびサーバーレスコンピュートプレーン内に格納される以下のデータに対して[顧客管理鍵(CMK)](https://www.databricks.com/trust/security-features/data-protection-with-customer-managed-keys)を構成してください：

* ノートブック  
* SQLクエリ  
* SQLクエリ履歴  
* シークレット  
* パーソナルアクセストークン(PAT)またはその他の資格情報  
* ベクター検索インデックスおよびメタデータ

Databricksは継続的な運用のためにAWS IAMロールを介した鍵へのアクセスを必要としますが、鍵へのアクセスを取り消すことでコントロールまたはコンピュートプレーン内のデータアクセスを防げます（ワークスペースは機能しなくなりますが、非常措置として可能）。

詳細は[Customer-managed keys for encryption](https://docs.databricks.com/en/security/keys/customer-managed-keys.html)を参照してください。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 2.9 ストレージに顧客管理鍵を構成する

以下に格納されるデータに対して[顧客管理鍵(CMK)](https://www.databricks.com/trust/security-features/data-protection-with-customer-managed-keys)を構成してください：

* 顧客管理のコンピュートプレーンでアタッチされるEBSボリューム  
* Databricksワークスペースに関連付けられたルートS3バケット  
* Unity Catalogが管理またはアクセスするS3バケット

Databricksは継続的運用のためIAMロールを介したキーアクセスを必要としますが、顧客管理鍵はコンプライアンス要件を満たし、必要に応じてアクセスを取り消すことも可能です。

詳細は[Customer-managed keys for encryption](https://docs.databricks.com/en/security/keys/customer-managed-keys.html)を参照してください。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***  
      
:::note info
サーバーレスコンピュートリソースはEBSストレージ暗号化に顧客管理鍵を使用しません。サーバーレスコンピュートのディスクは短命で、コンピュート停止やスケールダウン時に破棄されます。
:::

### 2.10 Delta Sharingを使用する

[Delta Sharing](https://www.databricks.com/product/delta-sharing)はデータ、アナリティクス、AI間でのオープンソースなデータ共有方式です。顧客はライブデータをプラットフォーム、クラウド、リージョン間で安全に共有できます。機密データを共有する際は、[Security Best Practices for Delta Sharing](https://www.databricks.com/blog/2022/08/01/security-best-practices-for-delta-sharing.html)に従ってください。

- [x] ***SATによるモニタリング***

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

[メタストアでDelta Sharingを有効化](https://docs.databricks.com/en/data-sharing/set-up.html#enable-delta-sharing-on-a-metastore)する場合、受信者トークンを有効期限付きに設定し、共有されるデータの機密性に応じて適切な時間スケール（秒・分・時間・日）で失効するようにしてください。

- [x] ***SATによるモニタリング***

### 2.12 AESを用いて機密データを追加入力で暗号化する

DatabricksはAES暗号化をサポートしており、保管時の機密データ列をさらに暗号化できます。[aes_encrypt](https://docs.databricks.com/en/sql/language-manual/functions/aes_encrypt.html)および[aes_decrypt](https://docs.databricks.com/en/sql/language-manual/functions/aes_decrypt.html)を使用して平文と暗号文を変換し、[シークレット](#115-シークレットを安全に保存使用する)で暗号鍵を安全に管理できます。追加暗号化により、基盤となるストレージや暗号鍵が侵害された場合でもさらなる保護を提供します。

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

Databricksワークスペース管理者は、[様々な設定](https://docs.databricks.com/en/admin/workspace-settings/index.html)を活用してデータ流出防止策を強化できます。特に重要なもの：

- Notebook結果のダウンロード  
- Notebookエクスポート  
- SQL結果のダウンロード  
- MLflowランアーティファクトのダウンロード  
- 結果テーブルのクリップボード機能  
- FileStoreエンドポイント

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 2.14 Clean Roomsを使用してプライバシー重視の環境でコラボレーションする

[Databricks Clean Rooms](https://www.databricks.com/product/clean-room)を使用すると、顧客やパートナーとプライバシー重視のセキュアな環境で容易にコラボレーションできます。Clean Roomsは無許可アクセスやデータ漏えいを防ぎながらコラボレーションを可能にします。

詳細は[What is Databricks Clean Rooms?](https://docs.databricks.com/en/clean-rooms/index.html)を参照してください。

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

ネットワークをセキュアにし、内部および外部エンドポイントの完全性を維持するために、ファイアウォールなどのセキュリティアプライアンスやクラウドサービスを使用してください。

### 3.1 顧客管理VPCを使用する

非サーバーレスワークロードでは、Databricksは顧客AWSアカウント内にVPCを必要とします。Databricksは[顧客管理VPC](https://docs.databricks.com/administration-guide/cloud-configurations/aws/customer-managed-vpc.html)を使用することを推奨し、[クロスアカウント権限](#116-制限付きクロスアカウントiamロールを使用する)が減少し、Databricks VPCを既存のネットワークアーキテクチャに統合できます。これにより独自のネットワーク強制ポイント（[ファイアウォールなど](#34-ネットワーク流出防止策を実装する)）を通すことや、[VPCエンドポイント](#34-ネットワーク流出防止策を実装する)でデータアクセスを制御可能です。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

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

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

[IPアクセスリスト](https://docs.databricks.com/en/security/network/front-end/ip-access-list.html)は、Databricksへのアクセスに使用可能なIPアドレスを制限します。Databricksは、Databricks[アカウント](https://docs.databricks.com/en/security/network/front-end/ip-access-list-account.html)、[ワークスペース](https://docs.databricks.com/en/security/network/front-end/ip-access-list.html)、[Delta Sharing受信者](https://docs.databricks.com/en/data-sharing/access-list.html)に対してIPアクセスリストを構成することを推奨します。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

### 3.3 AWS PrivateLinkを使用する

AWS [PrivateLink](https://www.databricks.com/trust/security-features/secure-your-data-with-private-networking)は、Databricks[Data Intelligence Platform](https://www.databricks.com/product/data-intelligence-platform)へのエンドツーエンドのプライベートネットワーキングを実現します。PrivateLinkはユーザーとコントロールプレーン間、コントロールプレーンとコンピュートプレーン間、コンピュートプレーンとAWSサービス間で構成可能です。

フロントエンドPrivateLink接続では、[アクセス制限](https://docs.databricks.com/en/security/network/classic/private-access-settings.html)を構成して、特定ワークスペースへのアクセスをDatabricksアカウントに登録されたVPCエンドポイントや特定のエンドポイントに限定できます。

バックエンドPrivateLinkを構成すると、コンピュートは専用でプライベートなチャネル上でのみ認証可能になります。

[顧客管理VPC](#31-顧客管理vpcを使用する)の場合、Databricksは同一リージョン内でのS3アクセスに[ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)を使用することを推奨します。[リージョナルエンドポイント構成](https://docs.databricks.com/en/security/network/classic/customer-managed-vpc.html#recommended-configure-regional-endpoints)を参照してください。

サーバーレスワークロードでは、[ネットワーク接続構成(NCC)](https://docs.databricks.com/en/security/network/serverless-network-security/index.html#what-is-a-network-connectivity-configuration-ncc)を使用して、AWS VPCエンドポイントサービス経由で顧客リソースへのPrivateLink接続が可能です（現在プレビュー中）。

詳細は[Enable AWS PrivateLink](https://docs.databricks.com/en/security/network/classic/privatelink.html)および[Serverless compute plane networking](https://docs.databricks.com/en/security/network/serverless-network-security/index.html)を参照してください。

- [x] ***SRAによるデプロイ***   
- [x] ***SATによるモニタリング***

:::note info
サーバーレスワークロードでは、コントロールプレーンとコンピュートプレーン間のネットワーキングはDatabricksがAWS PrivateLinkまたは相互TLS認証とファイアウォールポリシーで管理します。これでセキュリティ制御を1つ減らせます！
:::

### 3.4 ネットワーク流出防止策を実装する

デフォルトでは、AWS環境内のコンピュートプレーンホストは特定ポートでのアウトバウンドアクセスが制限されていません。[顧客管理VPC](#31-顧客管理vpcを使用する)を使用する場合、ファイアウォールなどを用いてアウトバウンドトラフィックを制限できます。[このブログ記事](https://www.databricks.com/blog/2021/02/02/data-exfiltration-protection-with-databricks-on-aws.html)ではAWS Network Firewallの使用例を、[ドキュメント](https://docs.databricks.com/en/resources/supported-regions.html#databricks-control-plane-addresses)ではその他一般化手法を示しています。

TLS接続は中断できず、SSL/TLS検査はできません。

顧客は[VPCエンドポイントポリシー](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)を使用してアクセス可能なリソースを制限できます。Databricksは「Data Exfiltration Protections for Databricks on AWS」技術ガイドで例を提示できます。

サーバーレスワークロードでは、ネットワークポリシーを作成して以下へのアクセスを制限できます：

* アカウント管理者が管理する信頼されたAWS PrivateLinkエンドポイント  
* [データ隔離モデル](#22-データ隔離モデルを計画する)に従ってメタストア管理者が管理する信頼されたUnity Catalogロケーション

この構成を有効にすると、信頼できないコードから他の場所へのアウトバウンドアクセスはブロックされます（現在プレビュー中）。

- [x] ***SRAによるデプロイ***

### 3.5 機密性の高いワークロードを別のネットワークに分離する

顧客は1つの[顧客管理VPC](#31-顧客管理vpcを使用する)を複数のワークスペースで共有できますが、機密性の高いワークロードには推奨されません。機密性の高いワークロードは[別のワークスペース](#42-機密性の高いワークロードを別のワークスペースに分離する)と独自の[顧客管理VPC](#31-顧客管理vpcを使用する)に分離すべきです。

サーバーレスコンピュートでは、[ネットワーク接続構成(NCC)](https://docs.databricks.com/en/security/network/serverless-network-security/index.html#what-is-a-network-connectivity-configuration-ncc)を用いて論理的に関連するネットワークを管理できます。論理的な分離に基づいてNCCを作成しますが、[制限事項](https://docs.databricks.com/en/security/network/serverless-network-security/serverless-firewall.html#requirements)を考慮してください。

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

サーバーレスワークロードでは、[ネットワーク接続構成](https://docs.databricks.com/en/security/network/serverless-network-security/index.html#what-is-a-network-connectivity-configuration-ncc)を用いて[特定の安定したIPアドレスセット](https://docs.databricks.com/en/security/network/serverless-network-security/serverless-firewall.html)からリソースへアクセスできます。顧客はこれらのIPのみ許可してリソースを保護できます。

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

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

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

内部・外部要件により、データ保存場所や処理への制御が必要な場合があります。法的要件や産業規制、国家法、税務上の問題、文化的要因に左右されることがあります。個人情報(PII)マスキングや削除が必要な場合もあります。可能な限りコンプライアンス努力を自動化してください。

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

Databricksクラスターは短命で、起動時に常に最新のベースイメージやコンテナイメージを使用します。ユーザーは特定の古いバージョンを選択できません（サポート終了したコンテナイメージを除く）。

顧客はクラスターを定期的に再起動する責任があります。Databricksはライブパッチを行わず、クラスターを再起動すると最新イメージ・コンテナが適用されます。

- [x] ***SATによるモニタリング***

:::note info
[Compliance Security Profile](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)が有効な場合、[Automatic cluster restart](https://docs.databricks.com/en/admin/clusters/automatic-cluster-update.html)は自動的に有効化されます。サーバーレスコンピュートも最大7日間の稼働時間で自動的に再サイクルされ、セキュリティ管理が容易になります！
:::

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

Databricksには[アクセス制御リスト](https://docs.databricks.com/en/security/auth-authz/index.html#access-control-lists)や[Unity Catalog特権](https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html)など多くの分離手段がありますが、最も強力な隔離は機密性の高いワークロードを別のワークスペースに移すことです。

### 4.3 Unity Catalogセキュア対象物を特定のワークスペースに割り当てる

ワークスペースを用いてユーザーとデータを隔離する場合、[カタログ](https://docs.databricks.com/en/data-governance/unity-catalog/create-catalogs.html#optional-assign-a-catalog-to-specific-workspaces)、[ストレージクレデンシャル](https://docs.databricks.com/en/connect/unity-catalog/storage-credentials.html#workspace-binding)、[外部ロケーション](https://docs.databricks.com/en/connect/unity-catalog/external-locations.html#workspace-binding)を特定ワークスペースに割り当てることでアクセスを制限できます。

バインディングは読み取り専用アクセスにも利用でき、(本番データセットへの読み取り専用アクセスをデータサイエンティストに与えるなど)有用です。

- [x] ***SRAによるデプロイ***  
- [x] ***SATによるモニタリング***

### 4.4 きめ細やかなアクセス制御を適用する

機密性の高いデータセットには、[行フィルターやカラムマスク](https://docs.databricks.com/en/data-governance/unity-catalog/row-and-column-filters.html)によるきめ細やかなアクセス制御を適用してください。

### 4.5 タグを適用する

[タグを適用](https://docs.databricks.com/en/data-governance/unity-catalog/tags.html)することで機密データセットを特定・発見しやすくし、適切な処理を可能にします。タグは[Lakehouse Monitoring](#511-lakehouse-monitoringを使用する)で自動的に適用可能で、[微粒度アクセス制御](#44-微粒度のアクセス制御を適用する)やABAC(プレビュー中)にも利用できます。

- [x] ***SRAによるデプロイ***

### 4.6 リネージを使用する

[リネージ](https://docs.databricks.com/en/data-governance/unity-catalog/data-lineage.html)を使用して機密データの流れを追跡し、ガバナンスを強化し、規制上のデータ主体要求に的確に対応できます。

### 4.7 AWS Nitroインスタンスを使用する

AWS Nitroインスタンスのメリット：

1. NVMeディスクを用いてデータを自動暗号化  
2. 多くのNitroインスタンスタイプはホスト間通信を自動暗号化

- [x] ***SRAによるデプロイ***

:::note info
[Compliance Security Profile](#48-enhanced-security-monitoringまたはcompliance-security-profileを使用する)が有効な場合、AWS Nitroインスタンス使用が自動で適用されます。
:::

### 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)は最もセキュアなベースラインを提供します。

[Enhanced Security Monitoring](https://docs.databricks.com/security/enhanced-security-monitoring.html)は：

1. CIS Level 1ハードニングAMI  
2. 振る舞いベースのマルウェア監視・ファイル整合性監視(Capsule8)  
3. マルウェア・ウイルス検出(ClamAV)  
4. Qualys脆弱性レポート

[Compliance Security Profile](https://docs.databricks.com/security/security-profile.html)は上記に加え：

1. FIPS 140-2 Level 1暗号モジュール  
2. [AWS Nitro VM](#47-aws-nitroインスタンスを使用する)強制  
3. 自動クラスター更新  
4. HIPAA, PCI-DSS, FedRAMP Moderate, IRAP準拠機能

- [x] ***SATによるモニタリング***

### 4.9 Databricksスタッフによるワークスペースアクセスを制御・監視する

Databricksスタッフは顧客同意なしにワークスペースや本番環境にアクセスできません。サポート要求時、顧客は一時的アクセスを付与できます。

Databricksは[Databricksスタッフアクセス](https://docs.databricks.com/en/admin/workspace/workspace-access.html)をデフォルトで無効とし、必要に応じて時間限定で有効にすること、また[システムテーブル](#51-システムテーブルの活用)でアクセスを監視することを推奨します。

- [x] ***SRAによるデプロイ***

### 4.10 災害復旧（DR）戦略を実装・テストする

DatabricksはDRサービスを提供しませんが、顧客は[S3データのバックアップ](#27-s3データのバックアップ)や[Deltaクローン](https://docs.databricks.com/en/delta/clone.html)でDR手順を実装できます。また、[Delta Live Tables](https://www.databricks.com/blog/2023/03/17/production-ready-and-resilient-disaster-recovery-dlt-pipelines.html)を用いたクロスリージョン冗長性でミッションクリティカルなワークロードのレジリエンスを高められます。

別リージョンにコールドスタンバイワークスペースを作成することで、完全なDRサイトへのフェイルオーバーも可能です。[disaster recoveryガイド](https://docs.databricks.com/administration-guide/disaster-recovery.html)を参照してください。

## システムセキュリティをモニタリングする

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

### 5.1 システムテーブルの活用

[システムテーブル](https://docs.databricks.com/en/admin/system-tables/index.html)はDelta Lake上の統合運用データストアで、[Unity Catalog](https://www.databricks.com/product/unity-catalog)でガバナンスされます。システムテーブルはコストモニタリングや[監査ログ](https://docs.databricks.com/en/admin/system-tables/audit-logs.html)などに活用可能です。Databricksは顧客にシステムテーブルの設定と自動モニタリング・アラートを推奨します。[Improve Lakehouse Security Monitoring using System Tables in Databricks Unity Catalog](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)可能です。

- [x] ***SRAによるデプロイ***  
- [x] ***SATによるモニタリング***

### 5.2 AWS CloudTrailおよびその他ログでシステム活動を監視する

システム侵害時にシステム自身に頼らず、外部から監視する必要があります。[システムテーブル](#51-システムテーブルの活用)の[監査ログ](https://docs.databricks.com/en/admin/system-tables/audit-logs.html)は有用ですが、Databricks自体の挙動を外部から観察するにはCloudTrail、S3アクセスログ、VPCフローログなどが有効です。

これらクラウドプロバイダログで：

* インスタンス作成（ビットコインマイニングや請求管理に有用）  
* アウトバウンド接続（データ流出検知）  
* APIコール（アカウント/キー侵害検知）  
* クロスアカウントロールアサンプション（アカウント/キー侵害検知）  
* Unity Catalogを介したデータアクセス可視化

顧客はお好みのツールでクラウドログ分析可能ですが、Databricksでも可能です。[ブログ記事](https://databricks.com/blog/2022/06/03/building-etl-pipelines-for-the-cybersecurity-lakehouse-with-delta-live-tables.html)でCloudTrailやネットワーク・セキュリティログを処理・監視するパイプラインが紹介されています。

:::note info
ネットワークレベルの保護(ファイアウォールなど)を使用している場合、ファイアウォールトラフィックログ監視が最適です。
:::

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

一部規制領域では、ユーザーがシステムで実行したすべてのコマンドを追跡する必要があります。[詳細監査ログ(Verbose Audit Logging)](https://docs.databricks.com/en/admin/account-settings/verbose-logs.html)を有効化すると、クエリやコマンド実行時に[システムテーブル](#51-システムテーブルの活用)にログが記録されます。

- [x] ***SRAによるデプロイ***  
- [x] ***SATによるモニタリング***

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

Databricksは[Gitフォルダ](https://docs.databricks.com/en/repos/index.html)でソースコードを管理・保護することを推奨します。これは一般的なソフトウェア開発ベストプラクティスです。

- [x] ***SATによるモニタリング***

### 5.5 信頼できるコードリポジトリのみを使用するよう制限する

ワークスペース管理者は、[許可リスト](https://docs.databricks.com/en/repos/repos-setup.html#restrict-usage-to-urls-in-an-allow-list)でクローンやプッシュ先リポジトリを制限し、コード流出や不正コード流入を防げます。

### 5.6 インフラストラクチャをコードとしてプロビジョニングする

[Infrastructure as Code(IaC)](https://docs.databricks.com/en/dev-tools/index-iac.html)でインフラを構築することで、ミス構成やドリフト防止、迅速な復旧、管理者ユーザー削減など多くの利点があります。

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

- [x] ***SRAによるデプロイ***

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

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

成熟した組織は[CI/CD](https://docs.databricks.com/en/dev-tools/index-ci-cd.html)で本番ワークロードをデプロイし、権限管理、コードスキャン、リンティングなどを統合します。機密データがある場合、CI/CDでハードコーディングシークレットなどを検出可能です。

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

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

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

サーバーレスワークロード（モデルサービングなど）では、[独自リポジトリからビルドした依存関係を事前パッケージ化](https://docs.databricks.com/en/machine-learning/model-serving/private-libraries-model-serving.html)できます。

- [x] ***SATによるモニタリング***

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

モデル・データのサプライチェーン攻撃が増えています。可能な限り[Databricks foundation models](https://docs.databricks.com/en/large-language-models/foundation-model-training/index.html#supported-models)や[Databricks Marketplace](https://docs.databricks.com/en/marketplace/index.html)など、信頼できるソースから取得してください。

未知ソースからモデルや重みを取得する場合、レビュー、[脆弱性・悪意チェック](#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://docs.databricks.com/en/lakehouse-monitoring/index.html)でデータ品質、整合性、ドリフトなどを自動監視・アラートします。これにより：

* データ毒化やラベル反転などのサプライチェーン攻撃防止  
* PII検出と自動[タグ付与](#45-タグを適用する)による[微粒度アクセス制御](#44-微粒度のアクセス制御を適用する)  
* 分類モデルの公平性やバイアスを監視

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

[Inferenceテーブル](https://docs.databricks.com/en/machine-learning/model-serving/inference-tables.html)はモデルサービングエンドポイントへのリクエスト・レスポンスをログ化します。これにより、モデルのモニタリング、デバッグ、改善が可能です。InferenceテーブルはLLMモデルに対してプレビュー対応しており、プロンプトインジェクションやモデル反転攻撃検出にも役立ちます。

### 5.13 コストモニタリングとチャージバック戦略のためにタグを使用する

AWSリソース課金まで追跡するには、コンピュートやプールに[タグ付け](https://docs.databricks.com/administration-guide/account-settings/usage-detail-tags-aws.html)を行います。タグは[課金用システムテーブル](https://docs.databricks.com/en/admin/system-tables/billing.html)や[予算](#514-予算を使用してアカウント支出を監視する)と組み合わせてコスト分析やチャージバックに役立ちます。

### 5.14 予算を使用してアカウント支出を監視する

[Budgets](https://docs.databricks.com/en/admin/account-settings/budgets.html)を設定してアカウント支出を監視します。全体支出や特定チーム、プロジェクト、ワークスペースごとの支出トラッキングが可能です。

### 5.15 AWSサービスクォータを使用する

[AWSサービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)は非常に大雑把な制御ですが、過剰なリソース消費を防ぐ包括的コントロールとして機能します。

---

# 付録B - 追加リソース

本書で多くの機能に言及し、可能な限りドキュメントリンクを示しました。以下はさらなる学習のための追加リソースです：

1. [Security and Trust Center](https://databricks.com/trust)で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://databricks.com/sites/default/files/2023-08/databricks-shared-responsibility-model-aws.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)をダウンロードし、DatabricksアカウントチームからEnterprise Security Guideや追加コンプライアンスレポートを入手  
4. AWSサーバーレス分離技術ガイドとサーバーレスペンテスト結果をDatabricksアカウントチームへリクエスト  
5. [Security Analysis Tool(SAT)](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://docs.databricks.com/en/lakehouse-architecture/index.html)を確認  
7. 強力なデータガバナンスも重要です。[Unity Catalog Best Practices](https://docs.databricks.com/en/data-governance/unity-catalog/best-practices.html)を参照  
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)を視聴してください。

以上です。