Go to Qiita Advent Calendar 2024 Top
LoginSignup
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

DatabricksAdvent Calendar 2024

Day 14
@nakazax(Hiroyuki Nakazato)inデータブリックス・ジャパン株式会社

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

Last updated at Posted at 2024-12-14

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

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

1. イントロダクション

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

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

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

2. Azure Databricksアーキテクチャ

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

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

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

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

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

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

ほとんどのデプロイ

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

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

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

4. Azure Databricksの脅威モデル

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

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

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

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

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

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

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

保護策

検知

対応

データ流出

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

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

保護策

検知

対応

内部脅威

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

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

保護策

検知

対応

サプライチェーン攻撃

リスク説明
従来、サプライチェーン攻撃は、悪意のあるコードをソフトウェアライブラリに注入することに依存していました。そのコードは、標的が気付かないうちに実行されます。しかし最近では、AIモデルとデータのサプライチェーン攻撃が出現し始めており、モデル自体、その重み、またはデータそのものが悪意を持って改変されるケースが見られます。

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

保護策

検知

対応

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

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

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

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

保護策

検知

対応

ランサムウェア攻撃

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

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

保護策

検知

対応

リソース悪用

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

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

保護策

検知

対応

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

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

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

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

1.1 多要素認証を活用する

Azure Databricksは、Microsoft Entra IDの条件付きアクセスをサポートしており、管理者がAzureリソースへのサインイン条件（信頼できるネットワークからのみ、MFA必須など）を制御できます。

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

なお、Microsoft Entra IDの条件付きアクセスはEntra IDで認証する時点でのみ適用されます。すでに認証済みのユーザーがネットワークを変更したり、個人用アクセストークン(PAT)などの他の認証手段を使用する場合には適用されません。したがって、包括的なネットワークアクセス制御を行うには、IPアクセスリストやAzure Private Linkとの併用を推奨します。

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

SCIM(System for Cross-domain Identity Management)により、Microsoft Entra IDとAzure Databricks間でユーザーとグループを同期できます。このアプローチには3つの大きな利点があります。

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

Azure Databricksは、Microsoft Entra IDからAzure Databricksアカウントへのユーザー・グループ同期、アイデンティティフェデレーションの有効化、およびSCIMプロビジョニングによるすべてのユーザーとグループの管理を推奨します。

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

ほとんどのシステムと同様に、Databricks内の管理者は拡張された権限を持つため、信頼できる少数の人に限定すべきです。可能であれば、サービスプリンシパルとInfrastructure-as-Code(IaC)を用いて管理タスクを自動化します。この推奨事項は、すべてのAzure Databricks管理者ロールに適用されます。

また、Azure RBACモデル上、Resource GroupにContributor以上の権限を付与されたユーザーまたはサービスプリンシパルは、Azure Databricksワークスペースにログインすると自動的に管理者になります。同じ考慮事項をAzureポータルユーザー、サービスプリンシパル、マネージドIDにも適用してください。

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

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

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

可能な限り、サービスプリンシパルとIaCを用いてすべての管理タスクを実行します。この推奨はすべてのDatabricks管理者ロールに適用されます。

なお、Azure RBAC上、リソースグループに共同作成者（Contributor）以上の権限があるユーザーやSPは自動的に管理者となる点にも留意してください。

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

デフォルトでは、ワークスペース管理者は、任意のサービスプリンシパルのジョブ所有者や「run as」設定を変更し、代理トークンを生成できます。restrict workspace admins設定を有効化してこれを防止することをお勧めします。

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

Azure Databricksにはさまざまなアクセス制御システムが存在します。ACLは最小権限の原則に基づいて付与し、ユーザーよりもグループに付与することを推奨します。Unity Catalogのセキュラブルオブジェクトには継承モデルに従って、一番下位レベルから権限を付与します。こちらの提案は、ペルソナベースのアクセス制御を始めるのに役立ちます。

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

可能な限り、OAuth（U2MまたはM2M）またはAzure Entra ID認証のみを使用してください。OAuthでは、U2M認証でUIと同様の認証が必要になり、M2Mでは短命なアクセストークンが使われるためリスクが低減します。Azure Entra ID認証も同様にリスクを低減します。

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

トークン管理APIやUIで、PATの有効/無効化、使用可能なユーザーの限定、新規トークンの最大存続期間の設定、既存トークンの管理が可能です。可能であればAzure Entra IDまたはOAuthトークン認証を利用し、困難な場合はトークン有効期限を短く設定します。
こちらで提供されているノートブックにより、Azure Databricksアカウント内のPAT使用状況を評価できます。

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

コンピュートポリシーまたはクラスター作成権限を用いて、どのユーザーまたはグループがクラスターを作成できるかを定義します。また、コンピュート権限で特定のクラスターに対するアクションを制御できます。
共有アクセスモードクラスター、SQLウェアハウス、サーバーレスコンピュートを可能な限り利用することをお勧めします。

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

コンピュートポリシーを用いて、クラスターサイズ、利用可能なインスタンスタイプ、ランタイムバージョン、Spark設定などを制御できます。複数のコンピュートポリシーを設定し、特定グループには小規模クラスターのみ、別グループには大規模クラスターも許可、など柔軟に制御可能です。

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

本番ワークロードを特定ユーザーアカウントに紐づけることはセキュリティ上推奨されません。サービスプリンシパルを設定して、管理者・ユーザーの操作とワークロードを分離し、ユーザーの離脱による影響を防ぎます。ジョブや自動化ツールをサービスプリンシパルとして実行可能です。

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

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

常に共有または割り当て済みアクセスモードクラスター、SQLウェアハウス、サーバーレスコンピュートを使用します。特に共有アクセスモード、SQLウェアハウス、サーバーレスが望ましいです。これらのコンピュートタイプはユーザー＆ワークロード間に分離境界を設けます。

もし「No isolation shared」クラスターを使用せざるを得ない場合は、管理者保護を有効化し、管理者資格情報が他ユーザーと共有環境で保護されるようにします。

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

さまざまなシステムとの統合には多くの資格情報管理が必要です。ノートブックに直接資格情報を記述せず、Azure Databricksの秘密管理を使用して資格情報を安全に保存し、ノートブックやジョブで参照してください。秘密情報はAzure DatabricksまたはAzure Key Vaultに保存可能で、ACLでアクセスを制御します。

Azure Key Vaultを使用する場合でも、同一のサービスIDがすべてのユーザーに対して秘密情報取得を行うため、Azure Databricks内でアクセス制御を定義する必要があります。

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

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

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

Unity Catalogは、Azure Databricks Data Intelligence Platform上で、構造化・非構造化データ、機械学習モデル、ノートブック、ダッシュボード、ファイルなどを単一のガバナンスレイヤーで統合管理します。これにより、データ＆AIイニシアチブが加速し、規制遵守が容易になります。

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

Azure Databricksは、Unity CatalogでのAzure Managed Identities利用を推奨しています。この設定後、ストレージファイアウォールで信頼できないネットワークからのアクセスをブロックすることも推奨します。（コンピュートプレーンは信頼できるネットワークとしてプライベートエンドポイント経由でアクセス可能）。詳細は、(推奨) Managed Identityに基づく信頼されたAzure Storageアクセスの構成やサーバーレスコンピュートアクセス用のファイアウォール構成を参照してください。

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

Unity Catalogにより、集中型または分散型ガバナンスモデルの選択や、データセット間で異なる分離レベルを適用可能です。ベストプラクティスに従い、事前にデータ分離モデルを計画することを推奨します。

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

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

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

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

機密データを保存するストレージアカウントには、ストレージファイアウォールを構成し、仮想ネットワークやサーバーレスコンピュートとマネージドIDからのアクセスのみ許可します。

ワークスペースに関連付けられたマネージドストレージアカウントはDeny Assignmentで保護され、Azure Databricksワークスペース経由でのみアクセス可能です。高セキュリティなデプロイの場合は、ワークスペースストレージアカウントに対するファイアウォールサポートの有効化も推奨します。

SQLステートメント実行APIで外部リンクを用いて大規模データセットを取得する場合は、ストレージアカウント上でネットワーク制限を構成してください。セキュリティベストプラクティスを参照。

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

管理するストレージアカウントをAzure Storageのセキュリティベースラインに照らして点検します。特に、匿名読み取りアクセスは許可しないようにし、必要に応じて顧客管理キーの使用など追加の保護も検討します。

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

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

詳しくは、Azure Storageデータ保護、バックアップ、復旧のベストプラクティスを参照してください。

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

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

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

顧客管理キー(CMK)を用いて、Azure Databricksコントロールプレーンやサーバーレスコンピュートプレーンに保存されたデータ（ノートブック、SQLクエリ、SQLクエリ履歴、秘密情報、PAT、その他の資格情報、ベクターサーチインデックスやメタデータ）を暗号化します。

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

詳細は、顧客管理キーによる暗号化を参照してください。

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

計算およびデータプレーンに保存されたデータ（顧客管理のコンピュートプレーンでアタッチされたAzure Managed Disks、Databricksワークスペース関連のAzureストレージアカウント、Unity Catalogが管理・アクセスするAzureストレージアカウントなど）に顧客管理キー(CMK)を適用します。

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

詳細は、顧客管理キーによる暗号化を参照してください。

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

2.11 Delta Sharingを使用する

Delta Sharingは、データ、アナリティクス、AI間でのデータ共有に対応する初のオープンソースアプローチです。強固なセキュリティとガバナンスを確保しながら、異なるプラットフォーム、クラウド、リージョン間でライブデータを共有できます。Delta Sharingのセキュリティベストプラクティスに従って機密データを共有してください。

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

メタストアに対してDelta Sharingを有効化する際、共有されるデータの機密性に比例した期間（秒、分、時間、日）で受信者トークンの有効期限を設定してください。

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

Azure DatabricksはAES(Advanced Encryption Standard)による保存時の機密データ列の追加暗号化をサポートします。aes_encryptやaes_decrypt関数を用いて、秘密情報で管理する暗号鍵を使い平文と暗号文を相互変換します。これにより、基盤となるストレージアカウントや暗号鍵が侵害された場合でも、追加の防護層を提供します。

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

Azure Databricksワークスペース管理者は、さまざまな設定を用いて環境を保護できます。ほとんどは有効/無効を切り替えるシンプルな操作です。重要なものとしては：

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

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

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

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

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

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

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

Secure Cluster Connectivityを有効化すると、顧客VNetは外部ネットワークからのインバウンドポート開放が不要になり、DatabricksクラスターのノードはパブリックIPを持ちません。この構成は攻撃面を大幅に削減し、セキュリティを強化するため、すべてのAzure Databricksワークスペースで推奨されます。

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

サーバーレス以外のワークロードでは、Azure Databricksには顧客サブスクリプション内の仮想ネットワークが必要です。Databricksを独自VNetにデプロイし、既存のネットワークアーキテクチャ（ファイアウォールなど）と統合することを推奨します。

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

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

IPアクセスリストは、Azure Databricksへのアクセス元IPアドレスを制限します（VPNやオフィスネットワークなど信頼できる範囲）。VPN切断などで信頼できないIPアドレスに接続が変わった場合、確立済みセッションも動作しません。Azure Databricksは、アカウント、ワークスペース、Delta Sharingの受信者にIPアクセスリストを設定することを推奨します。

3.4 Azure PrivateLinkを使用する

Azure Private Linkは、Azure Databricks Data Intelligence Platformに対してエンドツーエンドのプライベートネットワーキングを可能にします。Private LinkはAzure Databricksユーザーとコントロールプレーン間、コントロールプレーンとコンピュートプレーン間、コンピュートプレーンとAzureサービス間に設定可能です。

バックエンドおよびフロントエンド接続用のAzure Private Linkを設定すると、Databricksワークスペースは専用のプライベートチャネル経由でのみアクセス可能になります。

サーバーレスでないワークロードの場合は、プライベートエンドポイントを用いて仮想ネットワークからストレージアカウントに接続できます。

サーバーレスワークロードでは、ネットワーク接続構成(NCC)を作成し、専用プライベートエンドポイントでストレージアカウントに接続します。

詳細は、Enable Azure Private Link back-end and front-end connectionsおよびConfigure private connectivity from serverless computeを参照してください。

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

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

デフォルトでは、Azure環境内のコンピュートプレーンホストは特定サービスやポートへのアウトバウンドアクセスに制限がありません。独自の仮想ネットワークにデプロイすれば、ファイアウォールでアウトバウンドトラフィックを制限可能です。Azure Firewallを用いた例はこちらのブログ参照。Azure Databricksドキュメントで記載のドメインとIPを利用して他のネットワークセキュリティツールにも応用可能です。

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

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

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

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

VNet内やピアリングされたネットワークに他のリソースがある場合は、同一VNetまたはピア先VNetの他ネットワーク・サブネットに接続されたNSG（ネットワークセキュリティグループ）に「Deny」ルールを追加し、インバウンドおよびアウトバウンド両方の接続を制限します。クラスターがネットワークリソースにアクセスする必要がある場合は、必要最小限の許可ルールのみ追加してください。共有リソースとピアリングおよびNSGルールを参照。

サーバーレスコンピュートでは、NCC(Network Connectivity Configurations)を使って論理的に関連するネットワークを管理します。サーバーレスデータプレーンの論理的な分離を目的にNCCを作成しますが、ドキュメント化された制限事項も考慮してください。

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

サーバーレスワークロードでは、NCCを作成し、安定した特定のサブネットIDセットや専用プライベートリンクエンドポイントを使用します。これにより、それらのリソースへのアクセスをこれらの接続に限定し、信頼されたネットワークからのみアクセス可能にできます。

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

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

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

Azure Virtual Network暗号化により、Azure VM間のトラフィックをDTLSトンネルで暗号化・復号できます。これにより、内部ネットワーク上のトラフィックは常に暗号化され、パフォーマンス影響は最小限に抑えられます。

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

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

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

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

Automatic cluster restartは、compliance security profile有効時に自動で有効化されます。セキュリティ対策1つ減！サーバーレスコンピュートは最大7日で再利用不可となり、バックグラウンドで自動的にリサイクルされます。考慮すべきセキュリティコントロールが1つ減ります！

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

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

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

ワークスペースを用いてユーザーやデータを分離している場合、Unity Catalogのセキュラブルオブジェクトへのアクセスを特定ワークスペースに限定したい場合があります。これらの割り当て（バインディング）を用いて、カタログ、ストレージクレデンシャル、外部ロケーションを特定ワークスペースに割り当て、機密データアクセスを制限できます。

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

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

機密データセットには、行フィルターや列マスクによるきめ細かなアクセス制御を実装します。

4.5 タグを適用する

タグ付けを用いて機密データセットを特定・識別し、適切な処理を行いやすくします。タグはLakehouse Monitoringで自動的に適用可能で、きめ細かなアクセス制御（ABAC含む）にも利用できます。

4.6 ライネージを使用する

Unity Catalogのライネージを用いて機密データの動きを追跡し、データガバナンスを改善し、規制上要求されるデータ主体要求にも正確に対応できます。

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

Enhanced Security Monitoring(ESM)とCompliance Security Profile(CSP)は、Azure Databricksデプロイに最も安全なベースラインを提供します。

Enhanced Security Monitoringは以下を提供します：

  1. CIS Level 1で強化されたVM
  2. 行動ベースのマルウェア監視およびファイル整合性監視（Capsule8）
  3. マルウェア・ウイルス検出（ClamAV）
  4. 代表的ホストOSからのQualys脆弱性レポート

Compliance Security Profileは上記に加え、コンプライアンス要件に必要な追加のセキュリティコントロールを提供します：

  1. 自動クラスター更新
  2. HIPAAおよびPCI-DSS準拠機能・コントロール

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

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

Azure Databricksは、Azure Databricks担当者へのワークスペースアクセスをデフォルトで無効にし、必要時・時間制限付きで有効化することを推奨します。また、システムテーブルでそのようなアクセスを監視してください。

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

Azure Databricks自体はDRサービスを提供しませんが、お客様はAzureに保存したデータに対して独自のDR手順（クラウドネイティブなバックアップサービスやDeltaクローン使用）を実装できます。また、Delta Live Tablesによるクロスリージョン冗長性を実現可能です。

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

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

高度に機密なワークロード（個人データの非特定化など）では、Azure Confidential Computeを用いて使用中データを保護することを検討してください。

詳細はAzure confidential computing VMsを参照。

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

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

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

システムテーブルは、Delta Lakeでバックアップされ、Unity Catalogでガバナンスされた集中型運用データストアです。コスト監視から監査ログまで様々な目的で利用できます。Databricksはシステムテーブルを設定し、自動モニタリングやアラートを行うことを推奨します。こちらのブログが参考になります。

Enhanced Security MonitoringまたはCompliance Security Profileを使用中の顧客は、行動ベースのマルウェアおよびファイル整合性監視エージェントが検出した不審な活動に対してモニタリングおよびアラート設定が可能です。

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

「システムが侵害されたことは、システム自身にはわからない。外部から観察できなければならない」というセキュリティ格言があります。システムテーブルの監査ログはユーザー行動監視に非常に有用ですが、Azure Databricks自体に問題がないか外部から監視するために、Azureログも役立ちます。

リソースログ、アクティビティログ、Entra IDログ、VNet/NSGフローログは、Azure Databricks（およびユーザー）がコンピュートプレーンとデータプレーンで行うアクションを把握するのに役立ちます。これらは以下の可視性を提供します：

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

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

Azureドキュメントを参照してください。

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

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

高度に規制されたドメインでは、ユーザーがシステム上で実行したすべてのコマンドを追跡することが必要な場合があります。Azure Databricksでは詳細な監査ログ(verbose audit logging)を有効化することでこれが可能になり、クエリやコマンドが実行されるたびにシステムテーブルに記録されます。

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

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

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

ワークスペース管理者は、ユーザーがクローン＆コミット＆プッシュできるリモートリポジトリを許可リスト化できます。これにより、コードの流出や不正なコードの流入を防ぎます。

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

Infrastructure-as-Code(IaC)を用いてインフラを構築すると、多くの利点があります。

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

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

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

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

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

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

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

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

一部のデプロイでは独自のアーティファクトリポジトリをホストし、Databricksがそれらを使用するよう構成できます。サーバーレスワークロード（モデルサービングなど）では、独自リポジトリからビルドした依存関係をプリパッケージ可能です。

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

モデル・データサプライチェーン攻撃が増加しているため、可能な限りAzure Databricks foundation modelsやAzure Databricks Marketplaceなど信頼できるソースからモデルやデータセットを利用してください。

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

5.10 DevSecOpsプロセスを実装する

データ＆AIコードは、社内でも最重要なコードベースの一つでしょう。他と同等以上の厳格な保証が必要です。顧客はコードやモデルに対し静的・動的分析を実施可能です。

5.11 Lakehouse Monitoringを使用する

データ＆AIで成功するには、分析データ品質やモデル予測への信頼性が必要です。Lakehouse Monitoringで、データやモデルの品質、整合性、ドリフトなどを自動的に監視・アラート可能です。Lakehouse Monitoringは以下も可能：

5.12 Inferenceテーブルを使用する

Inferenceテーブルは、モデルサービングエンドポイントへのリクエスト・レスポンスを自動的にキャプチャし、Unity Catalogテーブルにログします。このデータでモデルを監視、デバッグ、改善可能です。Azure Databricksはプレビュー段階でLLMモデルのInferenceテーブルをサポートしています。Inferenceテーブルはプロンプトインジェクション、モデルインバージョン、ジェイルブレイクといったモデル推論攻撃検出にも役立ちます。

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

タグをコンピュートやプールに設定し、Azure Cost ManagementまでDatabricks利用状況をトレースできます。タグは請求可能使用量(billable usage)システムテーブルや予算と組み合わせることで、コストを360度把握し、チャージバック戦略をサポートします。

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

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

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

Azure Policyは粗めの制御手段ですが、過剰なリソース消費を防ぐ包括的なコントロールを提供します。

付録B - 追加リソース

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

  1. Security and Trust Centerで、Azure Databricks Data Intelligence Platformのあらゆるレイヤーに組み込まれたセキュリティ、プラットフォームアーキテクチャ、利用可能なセキュリティ機能、および運用している責任共有モデルを理解してください。
  2. Databricks AI Security Framework (DASF)をダウンロードして、実際の攻撃シナリオに基づくAIセキュリティ脅威への対策方法を理解してください。
  3. デューディリジェンスパッケージをダウンロードし、Azure DatabricksアカウントチームからEnterprise Security Guideや追加のコンプライアンスレポートを入手してください。
  4. Azure Databricksアカウントチームに問い合わせて、Azure Databricks Serverless Isolation技術ガイドやサーバーレスペンテスト結果を要求してください。
  5. すべてのワークスペースに対してSecurity Analysis Toolを設定し、デプロイ構成がベストプラクティスに継続的に準拠しているかレビューしてください。（詳細）
  6. 良いセキュリティの基礎は堅牢なアーキテクチャです。Well Architected Frameworkを確認してください。
  7. セキュリティ強化のもう1つの柱は強力なデータガバナンスです。Unity Catalog Best Practicesを参照してください。
  8. セキュリティチームによる追加コンテンツはPlatform & Security Blogsで確認できます。
  9. ビジュアル学習派の方は、Security Best Practices YouTubeシリーズをご覧ください。

以上です。

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?