Delta Sharing のセキュリティベストプラクティス

 

データレイクハウスにより、データ管理アーキテクチャを統合し、サイロを排除して、すべてのユースケースで共通のプラットフォームを活用できるようになりました。データウェアハウジングと AI のユースケースを単一のプラットフォームで統合することは、組織にとって大きな前進ですが、その一歩を踏み出した後、次に考慮すべき質問は「受信者がアクセスに使用しているクライアント、ツール、プラットフォームに関係なく、どのようにデータをシンプルかつ安全に共有できるか？」ということです。幸いなことに、レイクハウスにもこの質問に対する答えがあります。それが Delta Sharing によるデータ共有です。

Delta Sharing

Delta Sharing は、データが存在するプラットフォームに依存せずに、リアルタイムで組織内外のデータを安全に共有するための、世界初のオープンプロトコルです。レイクハウスアーキテクチャのオープン性の重要なコンポーネントであり、これまで不可能だった方法でデータチームやアクセスパターンを整理するための重要なイネーブラーです。例えば、データメッシュなどです。

設計によるセキュリティ

Delta Sharing は、セキュリティを念頭に置いてゼロから構築されており、オープンソース版またはそのマネージド版のいずれを使用する場合でも、以下の機能をすぐに利用できることに注意することが重要です。

• クライアントからサーバー、ストレージアカウントまでのエンドツーエンド TLS 暗号化
• データにアクセスするために使用される事前署名付き URL などの短期的な認証情報
• Unity Catalog を介した共有データセットへのアクセスを簡単に管理、追跡、監査できます

このブログで共有するベストプラクティスは追加的なものであり、お客様はリスクプロファイルとデータの機密性に合わせて適切なセキュリティ管理を調整できます。

セキュリティのベストプラクティス

機密データを共有するために Delta Sharing を使用するためのベストプラクティスのおすすめは次のとおりです。

1. 要件に基づいてオープンソース版とマネージド版を評価する
2. すべてのメタストアに対して適切な受信者トークンの有効期間を設定する
3. 認証情報のローテーションプロセスを確立する
4. 共有、受信者、パーティションの適切な粒度レベルを検討する
5. IP アクセスリストを設定する
6. Databricks 監査ログを設定する
7. ストレージアカウントのネットワーク制限を設定する
8. ストレージアカウントのログを設定する

1. 要件に基づいて オープンソース版と マネージド版を評価する

前述のように、Delta Sharing はセキュリティを最優先にゼロから構築されています。しかし、マネージド版を使用することには利点があります。

• Databricks 上の Delta Sharing は Unity Catalog によって提供されており、これにより、さまざまなユーザーセット間で任意のデータセットへのきめ細かなアクセスを、1か所から一元的に提供できます。オープンソース版では、さまざまなデータアクセス権を持つデータセットを複数の共有サーバーに分離する必要があり、これらのサーバーおよび基盤となるストレージアカウントにアクセス制限を課す必要もあります。デプロイの容易さのために、オープンソース版にはDocker イメージが提供されていますが、大規模エンタープライズ全体にデプロイをスケーリングすることは、管理を担当するチームにかなりのオーバーヘッドをもたらす可能性があることに注意することが重要です。
• Databricks Lakehouse Platform の他のすべての機能と同様に、Unity Catalog もマネージドサービスとして提供されています。サービスの可用性、稼働時間、メンテナンスなどについて心配する必要はありません。私たちがその心配をします。
• Unity Catalog を使用すると、包括的な監査ログ機能をすぐに設定できます。
• データオーナーは SQL 構文を使用して共有を管理できるようになります。さらに、共有を管理するための REST API も利用できます。使い慣れた SQL 構文を使用することで、データの共有方法が簡素化され、管理の負担が軽減されます。
• オープンソース版を使用する場合、データ共有の構成、インフラストラクチャ、管理はすべてお客様の責任となりますが、マネージド版ではこれらの機能がすべてすぐに利用できます。

これらの理由から、両方のバージョンを評価し、要件に基づいて決定することをお勧めします。セットアップと使用の容易さ、すぐに利用できるガバナンスと監査、アウトソースされたサービス管理がお客様にとって重要である場合、マネージド版が適切な選択となる可能性が高いです。

2. すべてのメタストアに対して適切な受信者トークンの有効期間を設定する

Delta Sharing を有効にすると、受信者認証情報のトークン有効期間が構成されます。トークン有効期間を 0 に設定すると、受信者トークンは期限切れになりません。

適切なトークン有効期間の設定は、規制、コンプライアンス、評判の観点から非常に重要です。期限切れのないトークンは大きなリスクとなるため、ベストプラクティスとして短期のトークンを使用することが推奨されます。トークンの有効期間が不適切に設定されたトークンの使用を調査するよりも、有効期限が切れた受信者に新しいトークンを付与する方がはるかに簡単です。

トークンを適切な秒数、分、時間、または日数で期限切れにするための構成については、ドキュメント (AWS、Azure) を参照してください。

3. 認証情報のローテーションプロセスを確立する

既存のトークンの有効期限が切れた場合、認証情報が侵害された可能性があるという懸念、またはトークンの有効期間を変更してその有効期限を尊重する新しい認証情報を発行したい場合など、認証情報をローテーションしたい理由はいくつかあります。

このようなリクエストが予測可能かつタイムリーに満たされるようにするには、確立された SLA を持つプロセスを確立することが重要です。これは、IT サービス管理プロセスにうまく統合でき、指定されたデータオーナー、データスチュワード、またはそのメタストアの DBA によって適切なアクションが完了されます。

認証情報をローテーションする方法については、ドキュメント (AWS、Azure) を参照してください。特に:

• 認証情報をすぐにローテーションする必要がある場合は、--existing-token-expire-in-seconds を 0 に設定すると、既存のトークンはすぐに期限切れになります。
• 認証情報が侵害された可能性があるという懸念がある場合、Databricks は次のアクションを推奨しています。:
  1. 受信者の共有へのアクセスを失効させます。
  2. 受信者をローテーションし、--existing-token-expire-in-seconds を 0 に設定して、既存のトークンをすぐに期限切れにします。
  3. 安全なチャネル経由で、新規アクティベーションリンクを対象の受信者に共有します。
  4. アクティベーションURLにアクセスした後、受信者に共有へのアクセスを再度付与します。

4. Share、Recipient、およびPartitionの適切な粒度を検討する

Databricksのマネージドバージョンでは、各Shareは1つ以上のテーブルを含み、複数のRecipientに関連付けることができます。これにより、複数のデータセットへのアクセスを細かく制御できます。これは、オープンソースだけでは達成が難しい方法です。さらに、パーティション指定を提供することで、テーブルの一部のみをShareに追加することも可能です（AWS、Azureのドキュメントを参照してください）。

これらの機能を活用し、ShareとRecipientを最小権限の原則に従って実装することをお勧めします。これにより、Recipientの認証情報が侵害された場合でも、関連付けられるデータセットの数やデータサブセットを最小限に抑えることができます。

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

デフォルトでは、Shareにアクセスするために必要なのは有効なDelta Sharing Credential Fileのみです。そのため、ネットワークレベルでのアクセス元制限を実装することで、認証情報が侵害される可能性を最小限に抑えることが重要です。

Delta Sharing IPアクセスリスト（AWS、Azureのドキュメントを参照）を設定して、Recipientのアクセスを信頼できるIPアドレス（例：企業のVPNのパブリックIP）に制限してください。

IPアクセスリストとアクセストークンを組み合わせることで、不正アクセスリスクを大幅に軽減できます。不正にデータにアクセスするには、トークンのコピーを入手し、かつ同じ承認済みネットワーク上にいる必要があるため、トークンを入手するだけよりもはるかに困難になります。

6. Databricks監査ログを設定する

監査ログは、Delta Sharingに関連するすべての活動を含む、Databricks Lakehouse Platformで発生していることを記録する権威ある記録です。そのため、各クラウドでDatabricks監査ログを設定し（AWS、Azureのドキュメントを参照）、それらのログを処理し、重要なイベントを監視/アラートするための自動パイプラインを設定することを強くお勧めします。

このトピックの詳細については、姉妹ブログ記事「Monitoring Your Databricks Lakehouse Platform with Audit Logs」をご覧ください。これには、Delta Live Tablesパイプラインの設定、Databricks SQLアラートの設定、および以下のようないくつかの重要な質問に答えるためのSQLクエリの実行に必要なすべてのコードが含まれています。

• どのDelta Shareが最も人気がありますか？
• どの国からDelta Shareにアクセスされていますか？
• IPアクセスリスト制限が適用されずにDelta Sharing Recipientが作成されていますか？
• 信頼できるIPアドレス範囲外のIPアクセスリスト制限を適用してDelta Sharing Recipientが作成されていますか？
• Delta Shareへのアクセス試行がIPアクセスリスト制限により失敗していますか？
• Delta Shareへのアクセス試行が認証に繰り返し失敗していますか？

7. ストレージアカウントのネットワーク制限を設定する

共有サーバーによってDelta Sharingリクエストが正常に認証されると、短命な認証情報の配列が生成され、クライアントに返されます。クライアントはこれらのURLを使用して、クラウドプロバイダーから直接関連ファイルを取得します。この設計により、結果をサーバー経由でストリーミングすることなく、大規模な帯域幅で並列に転送できます。また、セキュリティの観点からは、ShareがRecipientレベルで保護されていても、データ自体が誰でもどこからでもアクセスできるストレージアカウントにホストされている場合、意味がありません。そのため、ストレージアカウントにもDelta Sharing Recipientと同様のネットワーク制限を実装することが望ましいでしょう。

Azure

Azureでは、DatabricksはマネージドID（現在パブリックプレビュー中）を使用して、Unity Catalogに代わって基盤となるストレージアカウントにアクセスすることを推奨しています。その後、お客様はストレージファイアウォールを設定して、信頼できるプライベートエンドポイント、仮想ネットワーク、またはDelta Sharingクライアントがデータにアクセスするために使用する可能性のあるパブリックIP範囲へのその他のすべてのアクセスを制限できます。詳細については、Databricksの担当者にお問い合わせください。

重要事項：ここでも、適用するネットワークレベルの制限を決定する際には、潜在的なすべてのユースケースを考慮することが重要です。たとえば、Delta Sharingを介したデータアクセスに加えて、1つ以上のDatabricksワークスペースもデータにアクセスする必要がある可能性が高いため、それらのワークスペースが使用する関連する信頼できるプライベートエンドポイント、仮想ネットワーク、またはパブリックIP範囲からのアクセスを許可する必要があります。

AWS

AWSでは、DatabricksはS3バケットポリシーを使用してS3バケットへのアクセスを制限することを推奨しています。たとえば、次のDenyステートメントは、信頼できるIPアドレスとVPCへのアクセスを制限するために使用できます。

重要事項：ここでも、適用するネットワークレベルの制限を決定する際には、潜在的なすべてのユースケースを考慮することが重要です。たとえば：

• マネージドバージョンを使用する場合、プリサインされたURLはUnity Catalogによって生成されるため、リージョンごとのDatabricks Control Plane NAT IPからのアクセスを許可する必要があります。
• 1つ以上のDatabricksワークスペースもデータにアクセスする必要がある可能性が高いため、基盤となるS3バケットが同じリージョンにあり、S3への接続にVPCエンドポイントを使用している場合、またはデータプレーンのトラフィックが解決されるパブリックIPアドレス（NATゲートウェイ経由など）からのアクセスを許可する必要があります。
• 企業のネットワーク内からの接続を失わないように、Databricksは常に、企業のVPNのパブリックIPなど、少なくとも1つの既知の信頼できるIPアドレスからのアクセスを許可することを推奨しています。これは、Deny条件がAWSコンソール内でも適用されるためです。

ネットワークレベルの制限に加えて、Unity Catalogが使用するIAMロールに、基盤となるS3バケットへのアクセスを制限することも推奨されます。その理由は、これまで見てきたように、Unity Catalogは、AWS IAM/S3が提供する粗い粒度の権限では不可能な方法で、データへのきめ細かなアクセスを提供するためです。したがって、誰かがS3バケットに直接アクセスできた場合、それらのきめ細かな権限をバイパスして、意図したよりも多くのデータにアクセスできる可能性があります。

重要なお知らせ：上記と同様に、拒否条件はAWSコンソール内でも適用されるため、少数の特権ユーザーがAWS UI/APIにアクセスするために使用できる管理者ロールへのアクセスも許可することが推奨されます。

8. ストレージアカウントのロギングを設定する

基盤となるストレージアカウントにネットワークレベルの制限を適用することに加えて、誰かがそれらをバイパスしようとしていないか監視したいと思うでしょう。そのため、Databricksは次のように推奨しています。

• AWSでS3サーバーアクセスロギングを設定し、それに関連する適切な監視とアラートを設定する
• Azureで診断ロギングを設定し、それに関連する適切な監視とアラートを設定する

結論

レイクハウスは、データアーキテクチャの断片化やアクセスパターンにつながったデータ管理の問題のほとんどを解決し、組織がデータから価値を得るまでの時間を大幅に短縮しました。データチームがこれらの問題から解放された今、オープンでありながら安全なデータ共有が次のフロンティアとなっています。

Delta Sharingは、データが存在するプラットフォームに関係なく、リアルタイムでデータを安全に共有するための世界初のオープンプロトコルです。そして、上記のベストプラクティスと組み合わせてDelta Sharingを使用することで、組織はユーザー、パートナー、顧客とエンタープライズ規模で簡単に、かつ安全にデータを交換できます。

既存のデータマーケットプレイスは、データプロバイダーとデータコンシューマーのビジネス価値を最大化できませんでしたが、Databricks Marketplaceを使用すると、Databricks Lakehouse Platformを活用して、より多くの顧客にリーチし、コストを削減し、すべてのデータ製品にさらなる価値を提供できます。

データプロバイダーパートナーになることに興味がある場合は、ぜひお問い合わせください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事