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

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

1. イントロダクション

Databricksは、多くの顧客がDatabricks Data Intelligence Platformをセキュアに導入し、プライバシーや規制要件を満たすための経験に基づいています。組織ごとにセキュリティ導入方法は異なりますが、多くの企業が共通して採用するパターンや機能があります。

注意: あなたがセキュリティの専門家でない限り、このドキュメント全体を読む必要はありません。以下で説明する Define（定義）、Deploy（展開）、Monitor（監視） アプローチに従うことで、当社のセキュリティベストプラクティスを実装できます。

Define（定義）: ほとんどのデプロイおよび高いセキュリティを必要とするデプロイ向けのセキュリティチェックリストを確認する
Deploy（展開）: Security Reference Architecture (SRA) のTerraformテンプレートを使用して、これらのベストプラクティスに沿ったワークスペースを簡単に展開する
Monitor（監視）: Security Analysis Tool (SAT) を用いてセキュリティベストプラクティスへの準拠を継続的に監視する

このドキュメントは、実行中のワークロード種類に関係なく、データプラットフォームセキュリティのベストプラクティスに焦点を当てます。
AIワークロードに関連するセキュリティベストプラクティスの包括的な概要については、Databricks AI Security Framework (DASF)を参照してください。

2. Databricksアーキテクチャ

Databricks Data Intelligence Platform のアーキテクチャは、権限管理を簡素化し、データ重複を回避し、リスク低減するため、コントロールプレーンとコンピュートプレーンの2つに分かれています。コントロールプレーンはワークスペースアプリケーションやノートブック、設定、クラスターなどを管理する管理プレーンであり、コンピュートプレーンはデータ処理を行います。サーバーレスデプロイメントでは、コンピュートプレーンはクラウドサービスプロバイダではなく、Databricksアカウント内に存在します。

Databricksプラットフォームが初めての場合は、特定の推奨事項に入る前に、Security and Trust Center と security and trust overview guide を参照し、アーキテクチャ概要や一般的なセキュリティ質問を確認してください。

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

以下は、多くの顧客が使用する典型的なセキュリティ構成例です。「ほとんどのデプロイ」と「高いセキュリティを必要とするデプロイ」に分けています。ほとんどのデプロイに該当する設定は、例えば多要素認証(MFA)など、ほとんどの本番またはエンタープライズ導入で見られるものです。一方、高いセキュリティを必要とするデプロイでみられる構成は、医療、ライフサイエンス、金融サービスなどの規制対象業界や、特に機密性が高いデータや知的財産を扱う環境で一般的なものです。(例: Private Service Connectやカスタマーマネージドキー)

重要な点として、以下の推奨事項は、お客様のリスク許容度やユースケースにより異なるため、網羅的ではありません。また、これらを遵守しても絶対的な安全性が保証されるわけではありません。自社のエンタープライズセキュリティフレームワークの文脈で検討し、貴社のデプロイとデータを保護するために必要な対策を判断してください。

ほとんどのデプロイ

以下の構成は多くの本番Databricks導入環境で一般的なものです。機密性の低いデータを扱う小規模なデータサイエンスチームの場合、これらすべてを必ずしも必要としないかもしれません。一方、大量の機密データを解析する場合は、これらの構成を慎重に検討することをお勧めします。

全ユーザアクセスに対して多要素認証を活用する
アカウント、ワークスペース、Delta共有へのアクセスを IPアクセスリストで制限
Unity Catalogによるデータガバナンスの集中管理を行う
データおよびワークスペースの分離モデルを計画する
カスタマーマネージドVPC へDatabricksをデプロイしてネットワーク環境を制御(今すぐ必要がなくても、将来的な拡張性が向上)
GCSバケットを保護し、パブリックアクセスを防ぐ
GCSデータをバックアップする(デュアルリージョン)
Gitフォルダでコードバージョン管理および CI/CDでコード管理を実施
管理者ユーザ数を制限し、管理アカウント間で職務分離を強制、ワークスペース管理者を制限
サービスプリンシパルを用いて管理タスクや本番ワークロードを実行
最小権限の原則に従ってアクセスを管理
ユーザ分離をサポートするコンピュートを使用
システムテーブルを活用して設定を監視
Databricks担当者によるワークスペースアクセス制御と監視
OAuthトークン認証を使用し、トークン管理によってパーソナルアクセストークンの使用を無効または制限
本番データをDBFSに保存しない
シークレットを安全に保存および使用
ネットワーク流出防止策の検討
定期的なコンピュートの再起動による最新パッチ適用
Delta Sharingを使用し、Delta Sharing受信者トークン有効期間を設定
タグ付けや予算を活用してコスト監視・課金戦略を実施

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

以下は「ほとんどの導入」の構成に加え、高度なセキュリティが必要な環境でよく用いられる構成です。すべてを必要とするわけではありませんが、以下の項目を脅威モデル(Databricksの脅威モデル)や貴社のリスク許容度を踏まえ、適宜組み込むことをお勧めします。

デプロイ後のハードニングステップを検討する
SCIMを活用してユーザとグループを同期する
フロントエンドとバックエンド両方で GCP Private Service Connect を検討
ネットワーク分離モデルの計画
ネットワーク流出防止策の実装
カスタマーマネージドキーやストレージ用カスタマーマネージドキーにより保存時データ暗号化を強化
AESによる追加暗号化やきめ細やかなアクセス制御の検討
VPC Service Controls でGCPリソースをインターネットや未承認ネットワークから隔離
GCSデータに対するソフトデリートを用いて、誤削除データを復元可能に
トークン管理を使用して、パーソナルアクセストークンを無効化
Unity Catalogのセキュアラブルを特定ワークスペースに割り当てる
クラスター作成権限を制限し、Computeポリシーでデータアクセスパターンやコストを制御
ワークスペース内のデータ流出防止設定を活用
ライブラリ、モデル、コードの利用制限
Infrastructure as Codeによるインフラプロビジョニング
GCP Cloud Audit Logsでシステムアクティビティを監視
災害復旧DR戦略の実装およびテスト

4. Databricksの脅威モデル

特にセキュリティ意識が高い顧客は、Databricksのようなプラットフォームに関わる脅威モデルや、特定のリスクを軽減するためのコントロールを理解したい場合があります。ベストプラクティスに従うことが目的で、特定のセキュリティ懸念がない場合は、このセクションをスキップして上記チェックリストに集中しても構いません。
顧客との会話でよく話題になる主な脅威カテゴリは以下です。

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

以下では、これらのリスクに関する一般的な質問に回答し、確率について議論し、具体的な対策を示します。

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

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

確率
適切な対策がない場合、アカウント乗っ取りは効果的な戦略になり得ます。しかし、適切な対策によりリスクは大幅に低減できます。

保護策

1.1 多要素認証を活用する
1.2 SCIMを活用してユーザとグループを同期するし、退職者のアカウントを適切に削除
1.7 OAuthトークン認証を使用することで短命トークンによるアクセス
1.8 トークン管理を強制することでパーソナルアクセストークンを無効化または有効期限を設定
1.13 シークレットを安全に保存および使用する
3.2 IPアクセスリストを設定することでアカウント、ワークスペース、Delta共有へのアクセスを信頼できるパブリックネットワークに制限
3.3 GCP Private Service Connectを使用するしてプライベートネットワーク経由に制限
3.4 ネットワーク流出防止策を実装することで、アカウント乗っ取り後のデータ流出を防止
3.7 価値あるコードベースへのアクセスを信頼できるネットワークに限定する

検知策

5.1 システムテーブルを活用することで、認証・認可失敗やアクセス試行を特定(参考: ブログ記事)
5.10 DevSecOpsプロセスを実装するしてコード内の資格情報を検出

対応策

1.2 SCIMを活用してユーザとグループを同期することで疑わしいユーザを無効化/削除
1.7 OAuthトークン認証を使用するし、OAuthシークレット削除、サービスプリンシパル無効化
1.8 トークン管理を強制するでトークン無効化・削除
5.3 詳細監査ログを有効化するで、侵害の可能性があるアカウントの行動を調査

データ流出

リスク説明
悪意あるユーザまたは攻撃者が顧客環境に侵入した場合、機密データを外部へ持ち出し、保管・販売・恐喝する可能性があります。

確率
この攻撃には内部犯行やアカウント侵害が前提となるため確率は低いですが、一度侵入を許すとデータ流出は深刻な被害をもたらし得ます。

保護策

1.11 サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する
2.2 データ分離モデルの計画
2.3 本番データをDBFSに保存しない
2.4 GCSバケットを保護しパブリックアクセスを防ぐ
2.5 VPC Service Controlsを使用する
2.11 Delta Sharing受信者トークン有効期間を設定する
2.12 AESによる追加暗号化
2.13 ワークスペース内のデータ流出防止設定を活用する
3.2 IPアクセスリストを設定する
3.4 ネットワーク流出防止策を実装する
3.5 機密性の高いワークロードを別のネットワークに分離する
3.6 サーバーレスコンピュートアクセス用のファイアウォール設定
4.2 機密性の高いワークロードを別のワークスペースに分離する
4.3 Unity Catalogのセキュアラブルを特定ワークスペースに割り当てる
5.5 信頼できるコードリポジトリへ利用を制限する

検知策

5.1 システムテーブルを活用するし、不審なアクセスや大量リード/ライト、アカウント設定変更を検知(参考: ブログ記事)
5.2 GCP Cloud Audit Logsでシステムアクティビティを監視する

対応策

1.2 SCIMを活用してユーザとグループを同期するし、調査中のアカウントを無効化/削除
5.3 詳細監査ログを有効化するしてデータ流出疑惑に関するアクティビティを調査

内部脅威

リスク説明
内部者(ユーザ)が業務を楽にするためにセキュリティ対策を回避しようとする場合があります。また、データ共有を簡素化するために公開GCSバケットにデータを移すなど、意図せずセキュリティリスクを生むこともあります。

確率
回避方法は多数あり、組織ごとにリスクは異なりますが、多くのセキュリティ専門家は内部脅威を重大な潜在的リスクと考えています。

保護策

1.2 SCIMを活用してユーザとグループを同期する
1.3 管理者ユーザ数を制限する
1.4 管理アカウント間で職務分離を強制する
1.5 ワークスペース管理者を制限する
1.12 ユーザ分離をサポートするコンピュートを使用する
1.13 シークレットを安全に保存および使用する
2.6 ソフトデリートによるGCSデータ保護
2.7 デュアルリージョンでGCSデータをバックアップする
2.12 AESによる追加暗号化
3.4 ネットワーク流出防止策を実装する
3.7 価値あるコードベースへのアクセスを信頼できるネットワークに限定する
5.4 Gitフォルダでコードバージョン管理を行う
5.5 信頼できるコードリポジトリへ利用を制限する
5.6 Infrastructure as Codeによるインフラプロビジョニング
5.7 CICDでコードを管理する

検知策

5.1 システムテーブルを活用するし、過剰な削除や権限変更の試行を検知(参考: ブログ記事)
5.2 GCP Cloud Audit Logsでシステムアクティビティを監視する

対応策

1.2 SCIMを活用してユーザとグループを同期するし、内部脅威とみなされるアカウントを無効化/削除
2.6 ソフトデリートによるGCSデータ保護で誤削除・上書きデータを復元
2.7 デュアルリージョンでGCSデータをバックアップするで完全なデータセットを復元
4.8 災害復旧DR戦略の実装およびテスト
5.3 詳細監査ログを有効化するで内部犯行や事故を調査

サプライチェーン攻撃

リスク説明
従来のサプライチェーン攻撃はソフトウェアライブラリへの悪意あるコード注入が多かったですが、近年ではAIモデルやデータのサプライチェーン攻撃も出現しています。
モデルや重み、データが悪意を持って改ざんされる可能性があります。

確率
適切な対策がなければ効果的な戦略となり得ますが、防御戦略を適用すればリスクは大幅に減少します。

保護策

3.4 ネットワーク流出防止策を実装する
4.2 機密性の高いワークロードを別のワークスペースに分離する
5.5 信頼できるコードリポジトリへ利用を制限する
5.7 CICDでコードを管理する
5.8 ライブラリインストールの制御
5.9 信頼ある有名なソースからのみモデルやデータを使用する
5.10 DevSecOpsプロセスを実装する

検知策

5.10 DevSecOpsプロセスを実装するし、コード・ライブラリ・依存関係・モデル・モデルウェイトを自動スキャン

対応策

5.1 システムテーブルを活用するや検索で脆弱性を含むライブラリの利用を特定(参考: ブログ1, ブログ2)
5.3 詳細監査ログを有効化するしてノートブックコマンド経由のライブラリインストールを確認
5.8 ライブラリインストールの制御で既知の脆弱性を含むライブラリを禁止

Databricks自体の潜在的な侵害

リスク説明
セキュリティ重視の顧客は、Databricks自体が侵害された場合に自分たちの環境への波及を懸念することがあります。

確率
DatabricksはSecurity and Trust Centerで紹介する堅牢なセキュリティプログラムを有し、リスク最小化に多大な投資を行っています。それでも、いかなる企業でもリスクを完全には排除できません。

保護策

Databricks Security & Trust Center を確認し、必要なプロセスコントロールを検討
1.14 デプロイ後のハードニングステップを検討する
4.7 Databricks担当者によるワークスペースアクセス制御と監視

検知策

5.1 システムテーブルを活用するし、アクセス許可したDatabricks従業員の活動を監視(参考: ブログ記事)
5.2 GCP Cloud Audit Logsでシステムアクティビティを監視する

対応策

Databricks Security & Trust Center の確認と必要なプロセスコントロール
5.1 システムテーブルを活用する
5.3 詳細監査ログを有効化する
サービスアカウントやカスタマーマネージドキーを取り消してデータアクセスを遮断(可逆性がない場合もあり要注意)

ランサムウェア攻撃

リスク説明
ランサムウェアはデータへのアクセスを妨害し、身代金要求を目的とするマルウェアの一種です。暗号化が主な手段として用いられます。

確率
多くのデータは顧客のGCSバケットに保存され、こちらが主要な標的になります。Databricks側でできる対策も簡潔に示しますが、主な防御は顧客側ストレージのセキュリティ対策です。

保護策

2.1 Unity Catalogによるデータガバナンスの集中管理
2.4 GCSバケットを保護しパブリックアクセスを防ぐ
2.5 VPC Service Controlsを使用する
2.6 ソフトデリートによるGCSデータ保護
2.7 デュアルリージョンでGCSデータをバックアップする
2.9 ストレージに対してカスタマーマネージドキーを設定する
2.10 Delta Sharingを使用する
3.6 サーバーレスコンピュートアクセス用のファイアウォール設定
3.7 価値あるコードベースへのアクセスを信頼できるネットワークに限定する
5.6 Infrastructure as Codeによるインフラプロビジョニング

検知策

5.2 GCP Cloud Audit Logsでシステムアクティビティを監視するし、IAMやデータアクセス、CMKアクセス、不正なGCSバケット設定変更を検知
5.10 DevSecOpsプロセスを実装するしてコード内の資格情報を検出

対応策

2.6 ソフトデリートによるGCSデータ保護でデータ復元
2.7 デュアルリージョンでGCSデータをバックアップする
2.9 ストレージに対してカスタマーマネージドキーを設定するし、必要時にキー回転・失効
4.8 災害復旧DR戦略の実装およびテスト

リソース悪用(クリプトマイニングなど)

リスク説明
Databricksは大量のコンピュートリソースを展開できるため、アカウントが侵害された場合、攻撃者はクリプトマイニング等に利用する可能性があります。

確率
このシナリオは現実ではあまり顕著ではありませんが、一部顧客は懸念を示します。

保護策

1.9 クラスター作成権限を制限する
1.10 Computeポリシーを使用する
1.14 デプロイ後のハードニングステップを検討する
5.8 ライブラリインストールの制御
5.13 Organization Policiesを使用する

検知策

5.1 システムテーブルを活用するし、請求使用量を監視
5.2 GCP Cloud Audit Logsでシステムアクティビティを監視する
5.10 DevSecOpsプロセスを実装するし、コード内の資格情報検出
5.11 コスト監視や課金戦略にタグを活用する
5.12 予算を用いてアカウント支出を監視する

対応策

1.2 SCIMを活用してユーザとグループを同期するし、疑わしいアカウントを無効化/削除
5.3 詳細監査ログを有効化するでリソース悪用関連アクティビティを調査

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

本ドキュメントで参照するセキュリティ構成について、以下に詳細を示します。
参照しやすいよう、これらのセキュリティ構成は以下の包括的なセキュリティ、コンプライアンス、およびプライバシーに関する原則に基づいてグルーピングされています。

特権の最小化に基づくアイデンティティとアクセスの管理
転送中および保存中のデータを保護する
ネットワークをセキュアにし、エンドポイントを保護する
コンプライアンスおよびデータプライバシー要件を満たす
システムセキュリティを監視する

特権の最小化に基づくアイデンティティとアクセスの管理

アイデンティティおよびアクセス管理（IAM）は、適切なユーザが適切なリソースへアクセスできるようにする仕組みです。IAMは、アカウント管理（プロビジョニングを含む）、アイデンティティガバナンス、認証、アクセス制御（認可）、およびアイデンティティフェデレーションといった要素を扱います。

1.1 多要素認証を活用する

DatabricksはGoogle Cloud Identityとネイティブに統合され、SSO（シングルサインオン）をサポートしていますが、顧客はMFA（多要素認証）の設定も行うべきです。多くのDatabricks顧客は、Databricksへのログイン時あるいはVPN接続を要件とすることでユーザログイン時にMFAプロンプトを求めています。

最もセキュリティが厳しい環境では、Databricksは可能な限りFIDO2キーなどの物理的な認証トークンを用いることを推奨します。これらのキーは、物理的なトークンとのインタラクションを要することで、多要素認証を強化し、容易に侵害されない高いセキュリティレベルを提供します。

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

SCIM (System for Cross-domain Identity Management)を用いることで、IdP(アイデンティティプロバイダ)とDatabricks間でユーザとグループを同期できます。このアプローチには以下の3つの大きな利点があります。

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

Databricksは、顧客がIdPからDatabricksアカウントへユーザとグループを同期し、アイデンティティフェデレーションを有効化し、SCIMプロビジョニングを用いてアカウント内のすべてのユーザとグループを管理することを推奨します。

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

ほとんどのシステムと同様に、Databricks内の管理者は高い権限を持ち、その権限は組織内のごく一部の信頼できるメンバーにのみ与えるべきです。可能な場合は、[サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する](#1.11 サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する)を介した自動化（望ましくは[Infrastructure-as-Codeによるインフラプロビジョニング](#5.6 Infrastructure-as-Codeによるインフラプロビジョニング)）を用いて管理タスクを実行してください。この推奨は、すべてのDatabricks管理者ロールに適用されます。

1.4 管理アカウント間で職務分離を強制する

セキュリティ全般のベストプラクティスとして、管理者は特権アカウントを日常業務に用いるべきではありません。Databricksは、顧客がユーザアカウント間で職務分離を行うことを推奨します。具体的には以下が必要です。

同一ユーザが複数の高度な特権ロール（たとえばアカウント管理者とメタストア管理者）を兼任しない
Databricks管理者が通常ユーザとしてもDatabricksを使う場合、管理タスク用アカウントと日常業務用アカウントを分離する

可能な場合は、[サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する](#1.11 サービスプリンシパルを用いて管理タスクや本番ワークロードを実行する)を用いた自動化（望ましくは[Infrastructure-as-Codeによるインフラプロビジョニング](#5.6 Infrastructure-as-Codeによるインフラプロビジョニング)）で管理タスクを実行してください。この推奨はすべてのDatabricks管理者ロールに適用されます。

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

デフォルトでは、ワークスペース管理者はジョブオーナーや「run as」設定を変更したり、ワークスペース内の任意のサービスプリンシパルに対して代理トークンを生成できます。Databricksは、restrict workspace admins設定を有効化して、これを防ぐことを推奨します。

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

Databricksには、さまざまなオブジェクトに対するアクセス制御システムがあります。Databricksは、ACLを最小権限の原則に従って割り当て、ユーザではなくグループに対して権限を付与することを推奨します。Unity Catalogセキュアラブルに対しては、継承モデル内で可能な限り低レベルでアクセス権を管理してください。こちらの提案は、ペルソナベースのアクセス制御の導入に役立ちます。

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

可能な場合、顧客はユーザ-to-マシン(U2M) OAuth、マシン-to-マシン(M2M) OAuthまたはGoogle Cloud認証を用いるべきです。OAuthはリスク低減に有効です。U2MではUIと同様の認証が必要となり、M2Mの場合はメモリ内の資格情報が短期有効なアクセストークンになるためです。

Databricksは、Databricksおよび他のGoogle Cloudリソースへの同時認証が必要なシナリオにおいては、M2M OAuthではなくGoogle Cloud認証を用いることを推奨します。これはGoogle Cloud OAuthアクセストークンを必要とするからです。

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

顧客はToken Management APIやUIコントロールを用いて、REST API認証用のパーソナルアクセストークン(PAT)を有効・無効化したり、PAT使用が許可されるユーザを制限したり、新規トークンの最大存続期間を設定したり、既存トークンを管理できます。可能であれば[OAuthトークン認証](#1.7 OAuthトークン認証を使用する)を推奨します。難しい場合、ワークスペース内で新規トークンの有効期限を短く設定します。PAT使用状況はこちらで提供されるノートブックを使用して評価できます。

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

[Computeポリシー](#1.10 Computeポリシーを使用する)やクラスター作成エンタイトルメントを使用して、組織内でクラスター作成が可能なユーザやグループを定義できます。

Computeパーミッションを用いると、特定のクラスターに対してどのユーザがどの操作を行えるかを指定できます。適切なクラスター分離レベルの使用も考慮すべきであり、可能な限り[共有アクセスモードクラスタ、SQLウェアハウス、サーバーレスコンピュート](#1.12 ユーザ分離をサポートするコンピュートを使用する)を優先すべきです。

1.10 Computeポリシーを使用する

Databricks管理者はComputeポリシーを使用して、起動するクラスターのサイズ、利用可能なインスタンスタイプ、ランタイムバージョン、Spark構成設定などを制御できます。管理者は複数のComputeポリシーを設定し、ユーザグループごとにクラスター作成の制約条件を変えることも可能です。

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

本番ワークロードを特定ユーザアカウントに紐付けることはセキュリティ上好ましくありません。そのため、サービスプリンシパルをDatabricks内で設定することを推奨します。サービスプリンシパルは管理者やユーザのアクションをワークロードから切り離し、ユーザ退社時などにワークロードが影響を受けません。Databricksではジョブや自動化ツールをサービスプリンシパルとして実行することが可能です。

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

顧客は常に共有アクセスモードクラスター、SQLウェアハウス、サーバーレスコンピュートの使用を推奨します。これらはユーザやワークロード間に分離境界を提供します。

No isolation shared clusterを使用する必要がある場合は、管理者保護を有効化して、他のユーザと共有される環境内で管理者資格情報を保護してください。

1.13 シークレットを安全に保存および使用する

異種システムと統合する際には、大量の資格情報を管理し、それらを安全に配布する必要があります。資格情報をノートブック内に直接記述する代わりに、Databricksシークレットを用いて安全に格納し、ノートブックやジョブ内で参照します。Databricksシークレット管理を利用すると、Databricks内で資格情報を安全に使用および共有できます。

1.14 デプロイ後のハードニングステップを検討する

サーバーレスでないワークロードにおいて、Databricksはワークスペースごとに必要最低限の権限を有するサービスアカウントを作成・保有します。ワークスペースデプロイ後、以下の手順でDatabricks環境のさらなるハードニングが可能です。

ワークスペース作成者の権限削減： ここで定義される、ワークスペース作成者に必要な権限は、ワークスペース作成後は不要となります。
Compute Engineデフォルトサービスアカウントの制限： DatabricksはGKEクラスター実行にGoogle Compute Engineデフォルトサービスアカウントを使用します。このサービスアカウントはデフォルトで幅広い権限を持ちますが、GKEハードニングガイドラインに従って必要最低限のロールに絞れます。
ドメイン制限付き共有： 組織がドメイン制限付き共有を有効にしている場合は、DatabricksのGCPカスタマーID (C01p0oudw) と自組織のカスタマーIDの両方が許可リストに含まれていることを確認してください。この設定は組織レベルではなく、プロジェクトレベルで行うことが可能です。
Private Google Access & カスタマーマネージドVPCの強化： ネットワーク流出防止策を包括的に行う方法は後述しますが、まずはGoogle Private Accessを有効化し、VPCのファイアウォールおよびルーティングテーブルを強化することが可能です。詳細はこちらを参照してください。

転送中および保存中のデータを保護する

データの機密性・重要度に応じて分類し、必要に応じて暗号化、トークナイゼーション、アクセス制御などのメカニズムを適用します。

2.1 Unity Catalogによるデータガバナンスの集中管理

Unity Catalogは、Databricks Data Intelligence Platform内でデータとAIの統合ガバナンスレイヤを提供します。Unity Catalogを用いることで、組織は構造化・非構造化データ、機械学習モデル、ノートブック、ダッシュボード、ファイルを、クラウドやプラットフォームを問わずシームレスにガバナンスできます。この統合ガバナンスにより、データおよびAI関連イニシアティブが加速し、規制遵守を簡素化します。

2.2 データ分離モデルの計画

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

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

デフォルトでは、DBFSはワークスペース内のすべてのユーザがアクセス可能で、API経由でもアクセスできます。IPアクセスリストやプライベートネットワークアクセスを用いてDBFS APIやCLIでのアクセスを制限できますが、ワークスペース利用が拡大するとDBFSに保存されたデータは全ユーザにアクセス可能となり、望まれない情報共有が発生する可能性があります。Databricksは本番データをDBFSに保存しないことを推奨します。

2.4 GCSバケットを保護し、パブリックアクセスを防ぐ

GCSバケットは、Databricksデプロイにおいて、ワークスペース作成時に自動生成されるワークスペースストレージバケットと、顧客が独自に管理するデータ格納用バケットという2つの役割で使用されます。デプロイ後、DatabricksはワークスペースのGCSバケットを保護することを推奨します。また、顧客が用いるデータ格納用のGCSバケットについては、暗号化やパブリックアクセス防止などを適用し保護する責任があります。

2.5 VPC Service Controlsを使用する

VPC Service Controlsは、GCPリソースをインターネットや許可されていないネットワーク、および許可されていないGCPリソースから分離することを可能にします。顧客はVPC Service Controlsを用いてコンピュートやGCSバケットを保護するセキュリティ境界を構築できます。

2.6 ソフトデリートによるGCSデータ保護

ソフトデリートは、指定した期間、削除または上書きされたオブジェクトを保持し、偶発的または悪意のある削除からデータを保護します。GCPはObject Versioningよりもソフトデリートを推奨しています。

2.7 デュアルリージョンでGCSデータをバックアップする

GCSデータを定期的にバックアップし、誤削除や破損から復元できるようにします。GCSは組み込みのバックアップ・リストアサービスを提供しませんが、デュアルリージョンを利用することで、リージョン間で非同期的にデータをバックアップできます。

2.8 マネージドサービスに対してカスタマーマネージドキーを設定する

Databricksコントロールプレーンおよびサーバーレスコンピュートプレーン内に格納される以下の範囲のデータに対して、カスタマーマネージドキー (CMK)を設定します。

ノートブック
SQLクエリ
SQLクエリ履歴
シークレット
パーソナルアクセストークン(PAT)やその他の資格情報

Databricksは、継続的なオペレーションのためにこのCloud KMSキーへのアクセスを必要としますが、キーへのアクセスを取り消すことで、コントロールまたはコンピュートプレーン（およびバックアップ）内の暗号化データへのアクセスを遮断できます。
詳細はCustomer-managed keys for encryptionを参照してください。

2.9 ストレージに対してカスタマーマネージドキーを設定する

以下の範囲で計算およびデータプレーンに格納されるデータに対してカスタマーマネージドキー (CMK)を設定します。

カスタマーマネージドコンピュートプレーンのGCE永続ディスク
ワークスペースストレージバケット
データ格納用のGCSバケット

Databricksは、継続的なオペレーションのためにこのCloud KMSキーへのアクセスを必要としますが、CMKを用いることでコンプライアンス要件を満たし、必要に応じてアクセスを取り消すことが可能になります。
詳細はCustomer-managed keys for encryptionを参照してください。

注: サーバーレスコンピュートリソースは、GCEディスク暗号化にカスタマーマネージドキーを使用しません。サーバーレスコンピュートリソースのディスクは短命で、ワークロードのライフサイクルに紐づいており、停止やスケールダウン時に破棄されます。

2.10 Delta Sharingを使用する

Delta Sharingは、データ、アナリティクス、AI間のデータ共有に関する初のオープンソースアプローチです。顧客は、プラットフォーム、クラウド、リージョン間でライブデータをセキュアかつガバナンスされた状態で共有できます。機密データ共有時は、Delta Sharingのセキュリティベストプラクティスに従ってください。

2.11 Delta Sharing受信者トークン有効期間を設定する

メタストアに対してDelta Sharingを有効化する際は、共有される可能性があるデータの機密度に応じて、受信者トークンが秒・分・時・日単位で有効期限が設定されていることを確認してください。

2.12 AESによる追加暗号化

DatabricksはAES暗号化をサポートしており、静止中の機密データ列を追加的に暗号化できます。aes_encryptおよびaes_decryptを用いて平文と暗号文を変換し、[シークレット](#1.13 シークレットを安全に保存および使用する)で暗号鍵を安全に保管します。これにより、基盤となるストレージアカウントや暗号化キー・暗号が侵害された場合に備え、もう一層の保護が加わります。

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

Databricksワークスペース管理者は、各種設定を活用して保護を強化できます。多くの管理者コントロールはシンプルな有効/無効ボタンです。特に重要なものは以下です：

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

ネットワークをセキュアにし、エンドポイントを保護する

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

3.1 カスタマーマネージドVPCを使用する

サーバーレス以外のワークロードでは、Databricksは顧客のGCPアカウント内でVPCを使用します。DatabricksはカスタマーマネージドVPCを使用することを推奨し、クロスアカウント権限を削減し、Databricks VPCを既存のネットワークアーキテクチャに統合します。これにより、ファイアウォールなどのネットワーク強制ポイントでトラフィックを制御し、VPC Service Controlsでデータアクセスをコントロールできます。

注: サーバーレスワークロードの場合、コンピュートプレーンネットワークはDatabricksによって管理・セキュア化されます。これにより顧客が管理すべきセキュリティ構成が1つ減ります。

3.2 IPアクセスリストを設定する

IPアクセスリストは、Databricksへのアクセスを許可するIPアドレス範囲を制限します（VPNやオフィスネットワークなど）。確立済みのユーザセッションは、ユーザがVPN切断などで非許可IPへ移動すると無効になります。Databricksは、Databricksアカウント、ワークスペース、およびDelta Sharing受信者に対してIPアクセスリストを設定することを推奨します。

3.3 GCP Private Service Connectを使用する

GCP Private Service Connect (PSC)を用いると、Databricks Data Intelligence Platformとのエンドツーエンドなプライベートネットワーキングが可能です。PSCは、Databricksユーザとコントロールプレーン間、およびコントロールプレーンとコンピュートプレーン間で設定できます。DatabricksはPSCをGoogle Private AccessおよびVPC Service Controlsと組み合わせて、トラフィックをプライベート化し、データ流出リスクを軽減することを推奨します。

フロントエンドPSC接続では、登録済みVPCエンドポイントを制限することで、厳格なワークスペース間の分離が可能です。
バックエンドPSC設定により、コンピュートは専用のプライベートチャネルでのみ認証可能となります。

詳細はEnable Private Service Connect for your workspaceを参照してください。

注: サーバーレスワークロードでは、コントロールおよびコンピュートプレーン間のネットワーキングはDatabricksによって管理されます。GCP Private Service ConnectまたはGCPネットワーク（相互TLS認証と有効なIP制限ファイアウォール）を使用します。これによりセキュリティコントロールが1つ減ります。

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

デフォルトでは、GCP環境内のコンピュートプレーンホストは特定ポートで無制限のアウトバウンドアクセスを持ちます。[カスタマーマネージドVPCを使用する](#3.1 カスタマーマネージドVPCを使用する)ことでVPC Service Controlsやファイアウォールを用いてアウトバウンドトラフィックを制限できます。Databricksは、VPCファイアウォールによるネットワーク流出対策に関するブログ記事を提供しています。また、GCPはファイアウォールやデータ流出防止コントロールに関する推奨事項も提示しています。

コントロールプレーンとコンピュートプレーン間のTLS接続は分解不可能なため、SSL/TLSインスペクションは使用できません。

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

顧客はカスタマーマネージドVPCを使用することで複数ワークスペースを共有できますが、機密性の高いワークロードでは推奨されません。機密性の高いワークロードは、機密性の高いワークロードを別のワークスペースに分離することで、独立したカスタマーマネージドVPCとワークスペースに分離してください。

3.6 サーバーレスコンピュートアクセス用のファイアウォール設定

サーバーレスワークロードでは、安定したプロジェクトIDをVPC Service Controls内で設定することで、Databricksサーバーレスコンピュートプロジェクトのみがリソースにアクセス可能とすることができます。この機能は現在プレビュー中です。

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

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

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

内部および外部要件により、データの保存場所や処理に制約が生じる場合があります。これらの要件は、システム設計目的、業界規制、国内法、税務上の考慮事項などで異なります。個人情報(PII)のマスキングや削除などが必要になる場合もあります。可能な限り、コンプライアンス対応を自動化してください。

4.1 定期的なコンピュートの再起動

Databricksのコンピュートクラスターはエフェメラルです。起動時には常に最新のベースイメージとコンテナイメージを使用します。ユーザは古いイメージを選択できません。

顧客はクラスターを定期的に再起動して最新イメージやコンテナを取得し、セキュリティ脆弱性がある古いイメージを使い続けないようにする責任があります。

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

Databricksにはワークスペース内での分離をサポートする多数の機能（ACLやUnity Catalogの権限とセキュアラブルオブジェクトなど）がありますが、最も強力な分離手段は機密性の高いワークロードを別のワークスペースに分離することです。
高度にセキュアな環境では、Databricksワークスペースごとに専用のGCPプロジェクトを割り当てることを推奨します。これによりプロジェクト内のすべてのリソースがそのワークスペースに紐づくため、シンプルかつセキュアなモデルとなります。

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

ワークスペースを用いてユーザとデータを分離する場合、カタログ、ストレージクレデンシャル、外部ロケーションなどのUnity Catalogセキュアラブルを特定のワークスペースに割り当てることで、機密データへのアクセスを制限できます。

これらの割り当てはリードオンリーアクセスの付与にも利用でき、たとえばデータサイエンティストが本番データセットを読み取り専用で参照し、探索的データ分析を行うことも可能です。

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

機密データセットに対しては、行フィルタや列マスクによるきめ細やかなアクセス制御を実施してください。

4.5 タグ付けを行う

機密データセットにタグ付けを行い、容易に発見・特定し、適切に扱えるようにします。タグは検索性向上やきめ細やかなアクセス制御（ABACプレビュー中）にも役立ちます。

4.6 ライニージを活用する

ライニージを用いてデータ移動経路を追跡し、データガバナンスを強化し、規制上の要求に正確に対応できるようにします。

4.7 Databricks担当者によるワークスペースアクセス制御と監視

Databricks担当者は、顧客同意なしに顧客ワークスペースやマルチテナント環境にアクセスできません。サポートリクエスト発行時、顧客はDatabricks担当者に一時的なアクセスを付与し、障害やセキュリティイベントの調査、本番環境のサポートを受けることが可能です。

Databricksは、Databricks担当者によるワークスペースアクセスをデフォルトで無効とし、必要時に限定的・時間制約付きで許可すること、そして[システムテーブル](#5.1 システムテーブルを活用する)でのアクセス監視を推奨します。

4.8 災害復旧(DR)戦略の実装およびテスト

DatabricksはDRサービスを提供しませんが、顧客はGCS上のデータに対して独自のDR手順を実装できます。デュアルリージョンでGCSデータをバックアップするやDeltaクローンを用いたり、Delta Live Tablesによるクロスリージョンレジリエンスを実現できます。

完全なDRサイトへのフェイルオーバーが必要な場合、Databricksで別リージョンにコールド（待機）ワークスペースを作成可能です。災害復旧ガイドを参照してください。

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

自動化ツールを用いてアプリケーションおよびインフラを監視します。脆弱性スキャンやセキュリティインシデント検出は、CI/CDパイプラインなどで自動的に実行することが望まれます。

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

システムテーブルは、Delta Lakeでバックエンドされ、Unity Catalogによってガバナンスされた集中運用データストアとして機能します。システムテーブルは、コスト監視から監査ログまで、様々な用途に利用できます。Databricksは、顧客がシステムテーブルを構成し、自動監視・アラート設定を行うことを推奨します。Improve Lakehouse Security Monitoring using System Tables in Databricks Unity Catalogは良い出発点です。

5.2 GCP Cloud Audit Logsでシステムアクティビティを監視する

[システムテーブル](#5.1 システムテーブルを活用する)の監査ログはユーザアクティビティの監視に非常に有用ですが、多くの顧客はDatabricks自体のアクションも外部から監視したいと考えます。

GCP Cloud Audit Logsなどのクラウドプロバイダ監査ログは、Databricks（およびユーザ）のアクションを外部から観察する優れた手段です。
これにより以下が可能となります：

インスタンス作成の監視による不正マイニングや請求管理
アウトバウンドネットワーク接続監視によるデータ流出検出（ネットワークレベル保護導入時はファイアウォールログが有効）
GCPアカウント内APIコール監視によるアカウント/キー侵害検出
Unity Catalogを介したデータアクセス監視

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

高度に規制されたドメインでは、ユーザがシステムで実行したすべてのコマンドを追跡する必要があります。詳細監査ログを有効化すると、クエリやコマンド実行時に[システムテーブル](#5.1 システムテーブルを活用する)にログが記録されます。

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

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

5.5 信頼できるコードリポジトリへ利用を制限する

ワークスペース管理者は、許可リストによってクローンやコミット・プッシュ可能なリモートリポジトリを制限できます。これにより、コードの流出や不正なコードの流入を防止します。

5.6 Infrastructure-as-Codeによるインフラプロビジョニング

Infrastructure-as-Code(IaC)を用いてインフラをプロビジョニングすることで、人的ミス軽減、設定ドリフト防止、自動復旧や高速DR対応、管理者ユーザ数削減など多くの利点が得られます。

Databricksは、顧客がクラウドおよびDatabricksインフラをIaCでプロビジョニングし、サービスプリンシパルを用いて必要時のみ資格情報を付与することを推奨します。

注: Security Reference Architecture (SRA) Terraformテンプレートを利用すると、これらのセキュリティベストプラクティスに従ったDatabricksワークスペースを容易にデプロイできます。

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

成熟した組織は、CI/CDを用いて本番ワークロードを構築・デプロイし、ユーザ権限管理、コードスキャン、リンティングなどを統合します。機密データを扱う場合、CI/CDプロセスでハードコーディングされたシークレット検出などが可能です。

5.8 ライブラリインストールの制御

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

サプライチェーン攻撃を懸念する場合は、Unity Catalogで許可リストを維持したり、独自のアーティファクトリポジトリをホストしてDatabricksをそこに接続することもできます。

5.9 信頼ある/有名なソースからのみモデルやデータを使用する

モデルやデータのサプライチェーン攻撃は増加傾向にあります。そのため、可能な限りDatabricks Marketplaceなど信頼できる/有名なソースからのみモデル、重み、データセットを入手してください。

信頼できないソースから入手したモデルや重みを使用する場合は、DevSecOpsプロセスで脆弱性や悪意あるコンテンツのスキャンを行い、入念にテストしてください。データについても同様に探索的データ分析を行うことを推奨します。

5.10 DevSecOpsプロセスを実装する

データ＆AIコードは企業で最も重要なコードベースであり、他のコードと同等以上の厳格な審査と保証を適用すべきです。コードやモデルに対して、静的・動的解析を実行できます。

5.11 コスト監視や課金戦略にタグを活用する

GCPリソース請求を通じてDatabricks使用状況を追跡するには、タグ付けを行い、請求可能使用量の[システムテーブル](#5.1 システムテーブルを活用する)や予算と組み合わせて、コストを可視化・チャージバック可能とします。

5.12 予算を用いてアカウント支出を監視する

予算を活用すると、アカウント全体の使用量を監視できます。アカウント全体だけでなく、特定のチーム、プロジェクト、ワークスペースにフィルタを適用して費用を追跡することも可能です。

5.13 Organization Policiesを使用する

Organization Policiesは、過剰なリソース消費を防ぐ包括的なコントロールを提供する粗い制御手段です。

付録B - 追加リソース

本ドキュメントで紹介した様々な機能やドキュメントリンクに加え、以下の追加リソースも参照してください。

Security and Trust Centerを確認し、Databricks Data Intelligence Platformがあらゆるレイヤーでセキュリティを組み込み、プラットフォームアーキテクチャや利用可能なセキュリティ機能、共有責任モデルなどを理解してください。
Databricks AI Security Framework (DASF)をダウンロードし、実際の攻撃シナリオに基づくAIセキュリティ脅威の軽減方法を理解してください。
デューディリジェンスパッケージを入手し、DatabricksアカウントチームからEnterprise Security Guideや追加のコンプライアンスレポートを取得してください。
Security Analysis Toolをすべてのワークスペースでセットアップし、継続的にベストプラクティスに対するデプロイ構成の評価を行ってください。
良好なセキュリティの基盤は堅牢なアーキテクチャです。Well Architected Frameworkをご覧ください。
良好なセキュリティのもう1つの柱は強力なデータガバナンスです。Unity Catalogのベストプラクティスもぜひ確認してください。
セキュリティチームによるさらなるコンテンツは、Platform & Security Blogsで確認できます。
ビジュアルがお好みの場合は、Security Best Practices YouTubeシリーズをご覧ください。

以上です。