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

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

1. イントロダクション

Databricksは、数千社に及ぶ顧客が、適切な機能を備えたDatabricks Data Intelligence Platform をセキュアに導入し、セキュリティ、プライバシー、および規制要件を満たせるよう支援してきました。多くの組織は独自にセキュリティを展開しますが、ほとんどの組織が共通して使用するパターンと機能があります。

注意: あなたがセキュリティの専門家でない場合、このドキュメントをすべて読む必要はありません。以下に示す 定義(Define)、デプロイ(Deploy)、モニタリング(Monitor) のアプローチに従えば、セキュリティベストプラクティスを実装できます。

定義(Define): 下記のほとんどのデプロイと高いセキュリティを必要とするデプロイのセキュリティチェックリストを確認します。
デプロイ(Deploy): Security Reference Architecture (SRA) のTerraformテンプレートを用いることで、これらのベストプラクティスに従ったDatabricksワークスペースを簡単にデプロイできます。詳細なセキュリティ構成リファレンスセクションでは、SRAで展開可能な制御には以下のチェックを記しています：

SRAでデプロイ

モニタ(Monitor): Security Analysis Tool (SAT) を使用して、セキュリティベストプラクティス遵守状況を継続的に監視します。詳細なセキュリティ構成リファレンスセクションでは、SATで監視可能な制御には以下のチェックを記しています：

SATでモニタ

このドキュメントはデータプラットフォームのセキュリティベストプラクティスにフォーカスしています。実行しているワークロードの種類に関わらず、当てはまります。AIワークロードのセキュリティベストプラクティスについては、Databricks AI Security Framework (DASF) をご参照ください。

2. Databricksアーキテクチャ

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

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

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

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

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

ほとんどのデプロイ

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

アカウントレベルでのシングルサインオン(SSO)による認証
マルチファクタ認証(MFA)の活用
IPアクセスリストを用いてアカウント、ワークスペース、Delta Sharingへのアクセスを制限
Unity Catalogを使用してデータガバナンスを集中管理
データ隔離モデルおよびワークスペース隔離モデルを計画
顧客管理VPCを使用してネットワーク環境を強化 (今すぐ必要なくても、将来の成功確率向上につながる)
S3バケットを暗号化し、パブリックアクセスを防ぐ
S3データのバックアップ
Gitフォルダおよび CI/CD でコード管理
管理者ユーザー数を制限、管理アカウント間での職務分離、ワークスペース管理者を制限
サービスプリンシパルで管理タスクや本番ワークロードを実行
最小権限の原則に従ってアクセスを管理
ユーザー分離をサポートするコンピュートを使用
システムテーブルを用いて構成・監視
Databricksスタッフによるワークスペースアクセスを制御・監視
OAuthトークン認証を使用し、トークン管理を強制してパーソナルアクセストークンの使用を無効または制限
本番データをDBFSに保管しない
シークレットを安全に保存・使用
データ流出防止のためのネットワーク制御を実装を検討
定期的にコンピュートを再起動して最新パッチを適用
Delta Sharingを使用 & 受信者トークン有効期間を構成
タグと予算を使用してコストモニタリングとチャージバック戦略を実装

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

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

制限付きクロスアカウントIAMロールを使用
SCIMを使用してユーザーとグループを同期
フロントエンド PrivateLink の検討
バックエンド PrivateLink の検討
ネットワーク隔離モデルの計画
ネットワーク流出防止策の実装
顧客管理鍵を使用およびストレージに顧客管理鍵を構成して保存データ暗号化を強化
AESを用いた機密データ追加暗号化やきめ細やかなアクセス制御を検討
バケットポリシー適用
S3バージョニングの活用の検討
トークン管理を強制してパーソナルアクセストークン使用防止を検討
Unity Catalogセキュア対象物を特定のワークスペースに割り当ててワークスペース間でのデータ隔離
クラスター作成権限を制限やコンピュートポリシー適用
ワークスペース内のデータ流出防止設定のレビュー・構成
ライブラリ、モデル、コードの使用制限を検討
Enhanced Security MonitoringまたはCompliance Security Profile の活用
インフラストラクチャをコードとしてプロビジョニング
AWS CloudTrailおよびその他ログによるシステム活動監視
災害復旧(DR)戦略の設計・実装・テスト

4. Databricksの脅威モデル

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

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

アカウント乗っ取りまたは侵害
データ流出
内部脅威
サプライチェーン攻撃
Databricks自体の潜在的な侵害
ランサムウェア攻撃
リソース悪用

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

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

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

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

保護策

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

検知策

5.1 システムテーブルの活用により、認証失敗やアクセス試行を確認
- 参考: ブログ記事
5.10 DevSecOpsプロセスを実装することでコード中の資格情報を発見可能

対応策

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

データ流出

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

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

保護策

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

検知策

5.1 システムテーブルの活用により失敗した認可要求や大量の読み書き操作、アカウント・ワークスペース設定変更を特定
- 参考: ブログ記事
5.2 AWS CloudTrailおよびその他ログでシステム活動を監視するで失敗・不審なロール引受やデータアクセス、ネットワークアクセス試行を検知

対応策

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

内部脅威

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

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

保護策

1.4 SCIMを使用してユーザーとグループを同期することで適切な権限を維持
1.5 管理者ユーザー数を制限する
1.6 管理アカウント間での職務分離を徹底する
1.7 ワークスペース管理者を制限する
1.14 ユーザー分離をサポートするコンピュートを使用するでユーザー・ワークロードを分離
1.15 シークレットを安全に保存・使用する
2.6 S3バージョニングを使用するで誤って上書き・削除したデータを復元可能にする
2.7 S3データのバックアップで必要な場合にデータセットを完全復元
2.12 AESを用いて機密データを追加入力で暗号化する
3.4 ネットワーク流出防止策を実装するは、悪意ある攻撃者だけでなく誤った内部者による露出にも有効
3.7 価値のあるコードベースへのアクセスを信頼できるネットワークに限定する
5.4 Gitフォルダでコードバージョンを管理することでコードをプラットフォーム外部でバックアップ
5.5 信頼できるコードリポジトリのみを使用するよう制限する
5.6 インフラストラクチャをコードとしてプロビジョニングすることで本番環境への手動変更を防止
5.7 CI/CDでコードを管理することで承認済みコードのみ本番環境で実行可能

検知策

4.8 Enhanced Security MonitoringまたはCompliance Security Profileを使用するで環境からの逸脱行動を検知
- 参考: ブログ記事
5.1 システムテーブルの活用で破壊的活動(セッション内で大量削除)や権限昇格試行(セッション内で大量のパーミッション変更)を特定
- 参考: ブログ記事
5.2 AWS CloudTrailおよびその他ログでシステム活動を監視するで失敗・不審なデータアクセスやネットワークアクセス試行を検知

対応策

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

サプライチェーン攻撃

リスク説明
従来、サプライチェーン攻撃はソフトウェアライブラリへの悪意あるコード注入に依存していました。しかし、近年ではAIモデルやデータのサプライチェーン攻撃が発生しており、モデルやその重み、データ自体が悪意ある形で改変される可能性があります。

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

保護策

3.4 ネットワーク流出防止策を実装するは、サプライチェーン攻撃に対しても有効
4.2 機密性の高いワークロードを別のワークスペースに分離することで、サンドボックス環境でライブラリ実験を行い、本番環境では信頼できるライブラリのみ使用
5.5 信頼できるコードリポジトリのみを使用するよう制限する
5.7 CI/CDでコードを管理するでスキャン・承認済みのコードのみ本番で実行
5.8 ライブラリインストールを制御するでスキャン・承認済みライブラリのみ機密ワークロードで使用
5.9 信頼できる・評判の良いソースからのみモデルやデータを使用する
5.10 DevSecOpsプロセスを実装するでコード、ライブラリ、依存関係、モデル、モデルウェイトを自動スキャン
5.11 Lakehouse Monitoringを使用するでデータセット品質・一貫性の変化(データ毒性やラベル改ざん)を検知

検知策

4.8 Enhanced Security MonitoringまたはCompliance Security Profileを使用するで環境逸脱行動を検知
- 参考: ブログ記事
5.10 DevSecOpsプロセスを実装するによりコード、ライブラリ、モデルを自動スキャン

対応策

5.1 システムテーブルの活用および検索機能で既知脆弱性ライブラリを特定
- 参考: 脆弱なコードスキャン例
- 参考: Notebookコマンドログ監視例
5.3 詳細な監査ログを有効化するでNotebookコマンドによるライブラリインストールを特定
5.8 ライブラリインストールを制御するで脆弱性のあるライブラリを使用禁止

Databricks自体の潜在的な侵害

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

発生確率
Databricksは、Data Intelligence Platformのセキュリティに多大なリソースを投資しており、Security and Trust Center で概要と関連セキュリティ対策を確認できます。しかし、いかなる企業においてもリスクを完全に排除することは不可能です。

保護策

Databricks Security & Trust Center をレビューして必要なプロセス管理
1.16 制限付きクロスアカウントIAMロールを使用するでIAMロール侵害リスクを軽減
4.9 Databricksスタッフによるワークスペースアクセスを制御・監視する

検知策

5.1 システムテーブルの活用でDatabricks社員のアクティビティを監視
- 参考: ブログ記事
5.2 AWS CloudTrailおよびその他ログでシステム活動を監視するで
- 不審なプロビジョニング活動
- 不審または失敗したロール引受試行
- 不審または失敗したデータアクセス試行
  を特定

対応策

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

ランサムウェア攻撃

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

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

保護策

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

検知策

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

対応策

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

リソース悪用

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

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

保護策

1.11 クラスター作成権限を制限する
1.12 コンピュートポリシーを使用するで最大サイズやコンピュートタイプを制限
1.16 制限付きクロスアカウントIAMロールを使用する
5.8 ライブラリインストールを制御するでサプライチェーン攻撃によるリソース悪用を軽減
5.15 AWSサービスクォータを使用するで利用可能リソースを制限

検知策

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

対応策

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

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

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

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

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

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

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

DatabricksはSAML 2.0またはOpenID Connect (OIDC)を介したIdPとの間でのシングルサインオン(SSO)をサポートしています。

SSOはアカウントおよびワークスペースレベルの両方で構成できますが、Databricksはすべてのワークスペースに対して統合ログインを有効にし、単一のアカウントレベルSSO構成を使用することを推奨します。

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

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

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

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

統合ログインが有効な場合、アカウントおよびワークスペース管理者を含むすべてのユーザーはSSOでDatabricksにサインインする必要があります。

ロックアウトを防ぐために、アカウント管理者は緊急アクセスを最大10人まで構成し、これらのユーザーがセキュリティキーを用いたMFAでDatabricksにログインできるようにします。Databricksは、緊急アクセスでサインインするユーザーが強力なパスワードと少なくとも1つのFIDO2ハードウェアセキュリティキーを設定することを推奨します。

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

SCIM（System for Cross-domain Identity Management）を使用すると、IdPとDatabricks間でユーザーおよびグループを同期できます。このアプローチには以下の3つの主要な利点があります。

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

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

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

ほとんどのシステムと同様に、Databricks内の管理者には昇格された特権があります。これらは組織内の信頼できる少数の人にのみ拡張すべきです。可能な場合は、サービスプリンシパルを介した自動化によって、IaC(Infrastructure as Code)で管理作業を行うことを推奨します。この推奨事項は、すべてのDatabricks管理者ロールに適用されます。

SATによるモニタリング

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

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

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

可能な限り、サービスプリンシパルを使用した自動化により、IaCで管理タスクを実行することを推奨します。これらの推奨事項はすべてのDatabricks管理者ロールに適用されます。

SATによるモニタリング

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

デフォルトでは、ワークスペース管理者はジョブオーナーまたは代行実行設定を変更し、ワークスペース内の任意のサービスプリンシパルの代理トークンを生成できます。Databricksは、ワークスペース管理者を制限する設定を有効にし、これを防ぐことを推奨します。

SATによるモニタリング

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

Databricks内には、さまざまなセキュア対象物に対する異なるアクセス制御システムがあります。Databricksは、アクセス制御リスト(ACL)を最小権限の原則に従って割り当て、ユーザー個人ではなくグループにACLを付与することを推奨します。Unity Catalogのセキュア対象物に対しては、継承モデルの最下位レベルでアクセス権を管理します。この提案は、ペルソナベースのアクセス制御を導入するのに役立ちます。

SATによるモニタリング

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

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

SRAによるデプロイ

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

顧客はトークン管理APIまたはUIを使用して、REST API認証に使用されるパーソナルアクセストークン(PAT)を有効または無効にし、PATを使用できるユーザーを制限し、新しいトークンの最大有効期間を設定し、既存のトークンを管理できます。可能であれば、高度にセキュアな顧客にはOAuthトークン認証を推奨します。それが不可能な場合は、新しいトークンの最大有効期間を短くすることを推奨します。こちらのノートブックを使用して、Databricksアカウント内でのPAT使用状況を評価できます。

SRAによるデプロイ
SATによるモニタリング

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

コンピュートポリシーまたはクラスター作成エンタイトルメントを使用すると、組織内でクラスターを作成できるユーザーやグループを制御できます。

コンピュートパーミッションにより、特定のクラスターに対してどのユーザーがどのアクションを行えるかを指定できます。また、ユーザー分離をサポートするコンピュートも考慮に入れてください。可能な限り共有アクセスモードクラスタ、SQLウェアハウス、サーバーレスコンピュートを優先することを推奨します。

SATによるモニタリング

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

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

SRAによるデプロイ
SATによるモニタリング

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

本番ワークロードを個々のユーザーアカウントに紐付けるのはセキュリティベストプラクティスに反します。そのため、サービスプリンシパルをDatabricks内で構成することを推奨します。サービスプリンシパルは管理者とユーザーのアクションをワークロードから分離し、ユーザーが組織を離れてもワークロードへの影響を防ぎます。Databricksでは、ジョブや自動化ツールをサービスプリンシパルとして実行するよう構成できます。

SRAによるデプロイ
SATによるモニタリング

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

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

もしNo isolation sharedクラスタを使用せざるを得ない場合は、admin protectionを有効化して、他のユーザーと共有される環境で管理者認証情報を保護してください。

SRAによるデプロイ
SATによるモニタリング

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

異種システムとの統合には大量の資格情報管理が必要です。ノートブックに直接資格情報を入力する代わりに、Databricksシークレットを使用して資格情報を格納し、ノートブックやジョブで参照してください。Databricksシークレット管理は資格情報を安全に使用・共有可能です。

SRAによるデプロイ
SATによるモニタリング

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

非サーバーレスワークロードでは、DatabricksはクロスアカウントIAMロールを使用してDatabricksアカウントがAWSアカウント内でアクションを実行します。顧客はデフォルトロールの権限を制限できるかをよく尋ねます。

権限を制限する際は、適切な開始点があるか確認してください。デフォルトではドキュメントは簡略化した権限セットを示しています。しかし、セキュリティ重視の顧客は顧客管理VPCを使用することで、必要な権限数を減らせます。必要な権限とその目的についてはこのガイドを参照してください。

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

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

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

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

SRAによるデプロイ
SATによるモニタリング

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

Unity Catalogでは、集中および分散ガバナンスモデルを選択でき、データセット間にさまざまな隔離レベルを適用できます。Databricksは、ベストプラクティスに従い、データ隔離モデルを事前に計画することを推奨します。

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

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

SATによるモニタリング

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

S3バケットは、Databricksデプロイで2つの役割を果たします：Databricks初期設定時に提供するルートS3バケットとデータ格納用の追加バケットです。これらバケットについては、デフォルトでの暗号化または個別バケットごとの暗号化を行い、パブリックアクセスをブロックする必要があります。

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

SRAによるデプロイ
SATによるモニタリング

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

S3バケットポリシーを使用して、ネットワークアクセス制限やサーバーレスコンピュートアクセス用ファイアウォールなどの保護を適用します。

大量のデータセットをSQL Statement Execution API経由で取得する場合は、ストレージアカウントにネットワーク制限を構成することをDatabricksは推奨します。詳細はSecurity best practicesを参照してください。

SRAによるデプロイ

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

S3オブジェクトバージョニングを使用して古いバージョンのデータを保持し、誤削除や上書きから復旧可能にします。

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

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

S3データの定期的なバックアップを行い、誤削除や破損からの復旧を可能にします。

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

Databricksコントロールプレーンおよびサーバーレスコンピュートプレーン内に格納される以下のデータに対して顧客管理鍵(CMK)を構成してください：

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

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

詳細はCustomer-managed keys for encryptionを参照してください。

SRAによるデプロイ
SATによるモニタリング

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

以下に格納されるデータに対して顧客管理鍵(CMK)を構成してください：

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

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

詳細はCustomer-managed keys for encryptionを参照してください。

SRAによるデプロイ
SATによるモニタリング

サーバーレスコンピュートリソースはEBSストレージ暗号化に顧客管理鍵を使用しません。サーバーレスコンピュートのディスクは短命で、コンピュート停止やスケールダウン時に破棄されます。

2.10 Delta Sharingを使用する

Delta Sharingはデータ、アナリティクス、AI間でのオープンソースなデータ共有方式です。顧客はライブデータをプラットフォーム、クラウド、リージョン間で安全に共有できます。機密データを共有する際は、Security Best Practices for Delta Sharingに従ってください。

SATによるモニタリング

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

メタストアでDelta Sharingを有効化する場合、受信者トークンを有効期限付きに設定し、共有されるデータの機密性に応じて適切な時間スケール（秒・分・時間・日）で失効するようにしてください。

SATによるモニタリング

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

DatabricksはAES暗号化をサポートしており、保管時の機密データ列をさらに暗号化できます。aes_encryptおよびaes_decryptを使用して平文と暗号文を変換し、シークレットで暗号鍵を安全に管理できます。追加暗号化により、基盤となるストレージや暗号鍵が侵害された場合でもさらなる保護を提供します。

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

Databricksワークスペース管理者は、様々な設定を活用してデータ流出防止策を強化できます。特に重要なもの：

Notebook結果のダウンロード
Notebookエクスポート
SQL結果のダウンロード
MLflowランアーティファクトのダウンロード
結果テーブルのクリップボード機能
FileStoreエンドポイント
SRAによるデプロイ
SATによるモニタリング

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

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

詳細はWhat is Databricks Clean Rooms?を参照してください。

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

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

3.1 顧客管理VPCを使用する

非サーバーレスワークロードでは、Databricksは顧客AWSアカウント内にVPCを必要とします。Databricksは顧客管理VPCを使用することを推奨し、クロスアカウント権限が減少し、Databricks VPCを既存のネットワークアーキテクチャに統合できます。これにより独自のネットワーク強制ポイント（ファイアウォールなど）を通すことや、VPCエンドポイントでデータアクセスを制御可能です。

SRAによるデプロイ
SATによるモニタリング

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

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

IPアクセスリストは、Databricksへのアクセスに使用可能なIPアドレスを制限します。Databricksは、Databricksアカウント、ワークスペース、Delta Sharing受信者に対してIPアクセスリストを構成することを推奨します。

SRAによるデプロイ
SATによるモニタリング

3.3 AWS PrivateLinkを使用する

AWS PrivateLinkは、DatabricksData Intelligence Platformへのエンドツーエンドのプライベートネットワーキングを実現します。PrivateLinkはユーザーとコントロールプレーン間、コントロールプレーンとコンピュートプレーン間、コンピュートプレーンとAWSサービス間で構成可能です。

フロントエンドPrivateLink接続では、アクセス制限を構成して、特定ワークスペースへのアクセスをDatabricksアカウントに登録されたVPCエンドポイントや特定のエンドポイントに限定できます。

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

顧客管理VPCの場合、Databricksは同一リージョン内でのS3アクセスにゲートウェイエンドポイントを使用することを推奨します。リージョナルエンドポイント構成を参照してください。

サーバーレスワークロードでは、ネットワーク接続構成(NCC)を使用して、AWS VPCエンドポイントサービス経由で顧客リソースへのPrivateLink接続が可能です（現在プレビュー中）。

詳細はEnable AWS PrivateLinkおよびServerless compute plane networkingを参照してください。

SRAによるデプロイ
SATによるモニタリング

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

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

デフォルトでは、AWS環境内のコンピュートプレーンホストは特定ポートでのアウトバウンドアクセスが制限されていません。顧客管理VPCを使用する場合、ファイアウォールなどを用いてアウトバウンドトラフィックを制限できます。このブログ記事ではAWS Network Firewallの使用例を、ドキュメントではその他一般化手法を示しています。

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

顧客はVPCエンドポイントポリシーを使用してアクセス可能なリソースを制限できます。Databricksは「Data Exfiltration Protections for Databricks on AWS」技術ガイドで例を提示できます。

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

アカウント管理者が管理する信頼されたAWS PrivateLinkエンドポイント
データ隔離モデルに従ってメタストア管理者が管理する信頼されたUnity Catalogロケーション

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

SRAによるデプロイ

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

顧客は1つの顧客管理VPCを複数のワークスペースで共有できますが、機密性の高いワークロードには推奨されません。機密性の高いワークロードは別のワークスペースと独自の顧客管理VPCに分離すべきです。

サーバーレスコンピュートでは、ネットワーク接続構成(NCC)を用いて論理的に関連するネットワークを管理できます。論理的な分離に基づいてNCCを作成しますが、制限事項を考慮してください。

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

サーバーレスワークロードでは、ネットワーク接続構成を用いて特定の安定したIPアドレスセットからリソースへアクセスできます。顧客はこれらのIPのみ許可してリソースを保護できます。

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

Databricksは、価値あるコードベースへのアクセスを信頼できるネットワークに限定することを推奨します。Databricks内でこれらのコードリポジトリを使用するには、パブリックまたはプライベートなネットワークコントロールを適用できます。

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

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

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

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

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

SATによるモニタリング

Compliance Security Profileが有効な場合、Automatic cluster restartは自動的に有効化されます。サーバーレスコンピュートも最大7日間の稼働時間で自動的に再サイクルされ、セキュリティ管理が容易になります！

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

Databricksにはアクセス制御リストやUnity Catalog特権など多くの分離手段がありますが、最も強力な隔離は機密性の高いワークロードを別のワークスペースに移すことです。

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

ワークスペースを用いてユーザーとデータを隔離する場合、カタログ、ストレージクレデンシャル、外部ロケーションを特定ワークスペースに割り当てることでアクセスを制限できます。

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

SRAによるデプロイ
SATによるモニタリング

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

機密性の高いデータセットには、行フィルターやカラムマスクによるきめ細やかなアクセス制御を適用してください。

4.5 タグを適用する

タグを適用することで機密データセットを特定・発見しやすくし、適切な処理を可能にします。タグはLakehouse Monitoringで自動的に適用可能で、微粒度アクセス制御やABAC(プレビュー中)にも利用できます。

SRAによるデプロイ

4.6 リネージを使用する

リネージを使用して機密データの流れを追跡し、ガバナンスを強化し、規制上のデータ主体要求に的確に対応できます。

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

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

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

SRAによるデプロイ

Compliance Security Profileが有効な場合、AWS Nitroインスタンス使用が自動で適用されます。

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

Enhanced Security Monitoring(ESM)およびCompliance Security Profile(CSP)は最もセキュアなベースラインを提供します。

Enhanced Security Monitoringは：

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

Compliance Security Profileは上記に加え：

FIPS 140-2 Level 1暗号モジュール
AWS Nitro VM強制
自動クラスター更新
HIPAA, PCI-DSS, FedRAMP Moderate, IRAP準拠機能

SATによるモニタリング

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

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

DatabricksはDatabricksスタッフアクセスをデフォルトで無効とし、必要に応じて時間限定で有効にすること、またシステムテーブルでアクセスを監視することを推奨します。

SRAによるデプロイ

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

DatabricksはDRサービスを提供しませんが、顧客はS3データのバックアップやDeltaクローンでDR手順を実装できます。また、Delta Live Tablesを用いたクロスリージョン冗長性でミッションクリティカルなワークロードのレジリエンスを高められます。

別リージョンにコールドスタンバイワークスペースを作成することで、完全なDRサイトへのフェイルオーバーも可能です。disaster recoveryガイドを参照してください。

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

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

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

システムテーブルはDelta Lake上の統合運用データストアで、Unity Catalogでガバナンスされます。システムテーブルはコストモニタリングや監査ログなどに活用可能です。Databricksは顧客にシステムテーブルの設定と自動モニタリング・アラートを推奨します。Improve Lakehouse Security Monitoring using System Tables in Databricks Unity Catalogを参照してください。

Enhanced Security MonitoringまたはCompliance Security Profileを使用する顧客は、振る舞いベースのマルウェア・ファイル整合性監視エージェントによる不審活動検出を監視・アラート可能です。

SRAによるデプロイ
SATによるモニタリング

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

システム侵害時にシステム自身に頼らず、外部から監視する必要があります。システムテーブルの監査ログは有用ですが、Databricks自体の挙動を外部から観察するにはCloudTrail、S3アクセスログ、VPCフローログなどが有効です。

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

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

顧客はお好みのツールでクラウドログ分析可能ですが、Databricksでも可能です。ブログ記事でCloudTrailやネットワーク・セキュリティログを処理・監視するパイプラインが紹介されています。

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

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

一部規制領域では、ユーザーがシステムで実行したすべてのコマンドを追跡する必要があります。詳細監査ログ(Verbose Audit Logging)を有効化すると、クエリやコマンド実行時にシステムテーブルにログが記録されます。

SRAによるデプロイ
SATによるモニタリング

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

DatabricksはGitフォルダでソースコードを管理・保護することを推奨します。これは一般的なソフトウェア開発ベストプラクティスです。

SATによるモニタリング

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

ワークスペース管理者は、許可リストでクローンやプッシュ先リポジトリを制限し、コード流出や不正コード流入を防げます。

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

Infrastructure as Code(IaC)でインフラを構築することで、ミス構成やドリフト防止、迅速な復旧、管理者ユーザー削減など多くの利点があります。

DatabricksはクラウドおよびDatabricksインフラをIaCで構築し、サービスプリンシパルを使用して必要時のみ資格情報を信頼できる人に渡すことを推奨します。

SRAによるデプロイ

Security Reference Architecture (SRA)のTerraformテンプレートで、これらのセキュリティベストプラクティスに従ったDatabricksワークスペースを簡単にデプロイできます！

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

成熟した組織はCI/CDで本番ワークロードをデプロイし、権限管理、コードスキャン、リンティングなどを統合します。機密データがある場合、CI/CDでハードコーディングシークレットなどを検出可能です。

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

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

サプライチェーン攻撃を懸念する場合、Unity Catalogの許可リストで信頼できるライブラリのみを許可できます。

サーバーレスワークロード（モデルサービングなど）では、独自リポジトリからビルドした依存関係を事前パッケージ化できます。

SATによるモニタリング

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

モデル・データのサプライチェーン攻撃が増えています。可能な限りDatabricks foundation modelsやDatabricks Marketplaceなど、信頼できるソースから取得してください。

未知ソースからモデルや重みを取得する場合、レビュー、脆弱性・悪意チェック、テストを行うべきです。未知データ使用時も十分な探索的データ分析を行ってください。

5.10 DevSecOpsプロセスを実装する

データ＆AIコードは重要な資産です。他の開発領域同様、静的・動的解析で脆弱性検出を行い、コードやモデルをスキャンしてください。

5.11 Lakehouse Monitoringを使用する

データ＆AIで成功するにはデータ品質とモデル予測への信頼が必要です。Lakehouse Monitoringでデータ品質、整合性、ドリフトなどを自動監視・アラートします。これにより：

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

5.12 Inferenceテーブルを使用する

Inferenceテーブルはモデルサービングエンドポイントへのリクエスト・レスポンスをログ化します。これにより、モデルのモニタリング、デバッグ、改善が可能です。InferenceテーブルはLLMモデルに対してプレビュー対応しており、プロンプトインジェクションやモデル反転攻撃検出にも役立ちます。

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

AWSリソース課金まで追跡するには、コンピュートやプールにタグ付けを行います。タグは課金用システムテーブルや予算と組み合わせてコスト分析やチャージバックに役立ちます。

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

Budgetsを設定してアカウント支出を監視します。全体支出や特定チーム、プロジェクト、ワークスペースごとの支出トラッキングが可能です。

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

AWSサービスクォータは非常に大雑把な制御ですが、過剰なリソース消費を防ぐ包括的コントロールとして機能します。

付録B - 追加リソース

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

Security and Trust CenterでDatabricksData Intelligence Platformにおけるセキュリティ、プラットフォームアーキテクチャ、利用可能なセキュリティ機能、および責任共有モデルを確認
Databricks AI Security Framework (DASF)をダウンロードして、実際の攻撃シナリオに基づくAIセキュリティ脅威緩和方法を理解
デューデリジェンスパッケージをダウンロードし、DatabricksアカウントチームからEnterprise Security Guideや追加コンプライアンスレポートを入手
AWSサーバーレス分離技術ガイドとサーバーレスペンテスト結果をDatabricksアカウントチームへリクエスト
Security Analysis Tool(SAT)を全ワークスペースで実行し、継続的にベストプラクティスとの整合性を確認(詳細)
強固なアーキテクチャがセキュリティの基盤です。Well Architected Frameworkを確認
強力なデータガバナンスも重要です。Unity Catalog Best Practicesを参照
さらなる情報はPlatform & Security Blogsを参照
ビジュアル学習にはSecurity Best Practices YouTubeシリーズを視聴してください。

以上です。