Security Best Practices for Delta Sharing - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
お使いのレイクハウスに対するDelta Sharingのリクエストを強化するために活用できるベストプラクティス
データレイクハウスは、サイロを排除することで我々のデータ管理アーキテクチャを統合し、すべてのユースケースに共通した一つのプラットフォームを活用します。一つのプラットフォーム上でデータウェアハウスとAIユースケースを統合することは、企業にとっての大きな一歩ですが、このステップを踏み出した後の次の質問は、「データの受信者recipientが使用しているクライアント、ツールに関係なくシンプルかつセキュアにデータを共有shareするにはどうしたらいいのでしょうか？」というものになります。幸運なことに、レイクハウスはこの質問に対する答えも持っています。Delta Sharingによるデータ共有です。
Delta Sharing
Delta Sharingは、データが存在しているプラットフォームとは独立した、企業内外でリアルタイムにデータをセキュアに共有するための世界初のオープンプロトコルです。これは、レイクハウスアーキテクチャのオープン性のキーコンポーネントであり、データチームとこれまで不可能だったデータメッシュのようなアクセスパターンをまとめ上げるためのキーのイネーブラとなっています。
設計によるセキュリティ
Delta Sharingは最初からセキュリティを念頭に開発されており、オープンソース版であろうがマネージド版であろうが、すぐに以下の機能を活用することができます。
- クライアントからサーバー、ストレージアカウントに至るエンドツーエンドのTLS暗号化
- データアクセスに使用される事前サイン済みURLのような短期間有効な認証情報
- Unity Catalogによる教諭データセットに対する容易な統治、追跡、監査アクセス
このブログの一部として共有するベストプラクティスは加算的なものであり、お客様は自身のリスクプロファイル、取扱データの機密性に対して、適切なセキュリティコントロールを割り当てることができます。
セキュリティのベストプラクティス
機密データをDelta Sharingを用いて共有する際のおすすめのベストプラクティスは以下の通りとなります。
- 皆様の要件に基づいてオープンソース版かマネージド版かを評価する
- 全てのメタストアにおいて適切な受信者トークンの寿命を設定する
- 認証情報のローテーションサイクルを確立する
- 共有、受信者、パーティションに対する適切なレベルの粒度を検討する
- IPアクセスリストを設定する
- Databricks監査ログを設定する
- ストレージアカウントのネットワーク制限を設定する
- ストレージアカウントのログを設定する
1. 皆様の要件に基づいてオープンソース版かマネージド版かを評価する
上で説明した通り、Delta Sharingはセキュリティを最優先に設計されています。しかし、マネージド版を使うことのメリットがいくつかあります。
- Databricks上で提供されるDelta Sharingは、異なるグループのユーザー間のデータアクセスに対してきめ細かいアクセス管理を一つの場所から提供するUnity Catalogと統合されています。オープンソース版を使用する際は、複数の共有サーバー間でさまざまなデータアクセス権限を持つデータセットを分離する必要があり、また、それらのサーバーや背後のストレージアカウントに対してアクセス制限を課す必要があるかもしれません。デプロイメントを容易にするために、オープンソース版ではdockerイメージが提供されていますが、大企業においてデプロイメントをスケールさせるためには、これらを管理するチームにおいて無視できないオーバーヘッドが生じることに注意することが重要です。
- Databricksレイクハウスプラットフォームの他の部分同様、Unity Catalogはマネージドサービスとして提供されます。我々がすべて面倒を見るので、可用性や、稼働時間、メンテナンスなどを心配する必要はありません。
- Unity Catalogを用いることで、すぐに包括的な監査ログ機能を設定することができます。
- データの所有者はSQL構文を用いて共有を管理することができます。さらに、共有を管理するためのREST APIを利用することができます。馴染みのあるSQL構文を用いることで、データ共有をシンプルなものとし、管理の負荷を削減します。
- オープンソース版を用いる際には、あなたが設定やインフラストラクチャ、データ共有の管理に責任を持つことになりますが、マネージド版ではすべての機能をすぐに利用することができます。
以上のことを踏まえ、ご自身の要件に基づいて両方のバージョンを評価し、意思決定をすることをお勧めします。セットアップの容易性、利用しやすさ、すぐに利用できるガバナンスや監査機能、そしてアウトソーシングされたサービス管理が重要なのであれば、マネージド版が適切な選択肢と言えるでしょう。
2. 全てのメタストアにおいて適切な受信者トークンの寿命を設定する
Delta Sharingを有効化すると、受信者の認証情報のトークンの寿命を設定します。トークンの寿命を0にすると、受信者のトークンは有効期限切れしなくなります。
規制、コンプライアンス、評判の観点から適切なトークン寿命の設定は非常に重要と言えます。有効期限が切れないトークンを持つことは大きなリスクとなります。このため、ベストプラクティスとしては短期間のトークンを用いることをお勧めします。寿命が不適切なトークン使用の調査よりも、有効期限が切れたトークンを持つ受信者に新規トークンを許可する方がはるかに楽です。
適切な秒数、時間、日数を経過した後に無効化されるトークンの設定方法についてはドキュメント(AWS、Azure)を参照ください。
3. 認証情報のローテーションサイクルを確立する
既存トークンの有効期限切れ、認証情報が漏洩しているかもしれないという懸念、あるいは単にトークンの寿命を変更したので、新たな寿命に従う新たな認証情報を発行したいといったことから認証情報をローテーションするなど、ローテーションの理由は数多く存在します。
予測可能かつ迅速な方法でこのようなリクエストを確実に充足するためには、プロセス、そして望ましくはSLAを確立することが重要です。これは、特定のデータ所有者、データスチュワード、当該メタストアのDBAによって完了される適切なアクションを伴う、ITサービスの管理プロセスに組み込むことが可能です。
認証情報をローテーションする方法についてはドキュメント(AWS、Azure)を参照ください。特に、以下のことに注意してください。
- 即座に認証情報をローテーションする必要がある場合には、
--existing-token-expire-in-secondsを0に設定することで既存のトークンを即座に無効化します。 - 認証情報が漏洩した恐れがある場合には、以下のアクションを取ることをお勧めします。
- 共有に対する受信者のアクセス権を剥奪します。
- 受信者をローテーションし、既存のトークンが即座に無効化されるように
--existing-token-expire-in-secondsを0に設定します。 - セキュアな連絡手段を通じて、意図している受信者に新たなアクティベーションリンクを共有します。
- アクティベーションURLにアクセスがあった後に、共有への受信者のアクセスを再度許可します。
4. 共有、受信者、パーティションに対する適切なレベルの粒度を検討する
マネージド版では、共有には1つ以上のテーブルを格納することができ、誰がどのように複数のデータセットのアクセスできるのかを管理するために、きめ細かいコントロールを用いて1人以上の受信者に共有を紐づけることができます。これによって、オープンソース版単体では実現が非常に困難な方法で、複数のデータセットに対するきめ細かいアクセス権管理が可能となります。さらに、パーティションの指定を行うことで、テーブルの一部のみを共有することも可能となっています(AWS、Azureのドキュメントをご覧ください)。
最小権限の原理に従って共有や受信者を実装することで、もし受信者の認証情報が漏洩したとしても、限定的なデータセット、あるいは最小限のデータのサブセットに関連づけられることになり、これらの機能のメリットを享受することができます。
5. IPアクセスリストを設定する
デフォルトでは、あなたの共有にアクセするのに必要なのはDelta Sharingの認証情報ファイルですので、どこから使用できるのかを限定するネットワークレベルの制限を実装することで、認証情報の漏洩の可能性を最小化することが重要となります。
受信者がアクセスできるのを信頼されたIPアドレス、例えば、皆様の企業のVPNのパブリックIPなどに限定するためにDelta SharingのIPアクセスリスト(AWSとAzureのドキュメントをご覧下さい)を設定します。
アクセストークンとIPアクセスリストを組み合わせることで、許可されないアクセスのリスクを劇的に削減することができます。誰かが許可されない方法でアクセスするには、トークンのコピーを所有することに加え、許可されたネットワークからアクセスする必要があるので、トークン自身を取得するよりもはるかに困難になります。
6. Databricks監査ログを設定する
監査ログはDelta Sharingに関連するすべてのアクティビティを含む、Databricks Lakehouse Platformで起きた出来事の監査記録となります。このため、それぞれのクラウドでDatabricks監査ログを設定(AWS、Azureのドキュメントをご覧ください)し、重要なイベントに対するモニタリング、アラートを処理する自動化パイプラインを構築することをお勧めします。
Delta Live Tablesパイプラインのセットアップ、Databricks SQLアラートの設定、以下のような重要な疑問に答えるためのSQLクエリーを含む、このテーマのディープダイブを行なっている関連記事Monitoring Your Databricks Lakehouse Platform with Audit Logsもご覧ください。
- どのDelta Shareが最も人気があるのか？
- どの国から私のDelta Shareへのアクセスが最も多いのか？
- IPアクセスリストの制限が適用されずにDelta Sharingの受信者が作成されていないか？
- 私が信頼するIPアドレス範囲外のIPアクセスリスト制限を用いてDelta Sharingの受信者が作成されていないか？
- IPアクセスリストに許可されないDelta共有へのアクセス試行があるか？
- 繰り返し認証に失敗しているDelta共有へのアクセス試行があるか？
7. ストレージアカウントのネットワーク制限を設定する
共有サーバーによってDelta Sharingへのリクエストが承認されると、単寿命の認証情報の配列が生成され、クライアントに返却されます。クラウドプロバイダーから直接適切なファイルをリクエストするために、クライアントはこれらのURLを使用します。このデザインは、結果がサーバーを通過することなしに、十分な帯域を使って並列に転送が行われることを意味します。また、セキュリティ観点ではDelta Sharingの受信者自身に対して、ストレージアカウントにおいて同様のネットワーク制限を実装したいと考えるかもしれません。誰でもどこからでもアクセスできるストレージアカウントにデータがホスティングされている場合、受信者レベルで共有をガードする方法は存在しません。
Azure
Azureでは、Unity Catalogの代わりに背後のストレージアカウントにアクセするためにマネージドアイデンティティ(現在パブリックプレビュー)を使用することをお勧めします。そして、データにアクセスする際にDelta Sharingのクライアントが使用するであろうパブリックIP範囲や信頼されるプライベートエンドポイント、仮想ネットワークにアクセスを制限するためにストレージファイアウォールを設定します。詳細に関してはDatabricks担当者にお問い合わせください。
重要！
繰り返しになりますが、適用するネットワークレベルの制限を決定するには、可能性のあるすべてのユースケースを検討することが重要です。例えば、Delta Sharing経由でデータにアクセすることに加え、1つ以上のDatabricksワークスペースも当該のデータにアクセスする必要がある場合には、これらのワークスペースで使用されている適切な信頼プライベートエンドポイント、仮想ネットワーク、パブリックIPレンジも許可しなくてはなりません。
AWS
AWSではS3へのアクセスを制限するために、S3バケットポリシーを使用することをお勧めします。例えば、信頼するIPアドレスとVPCにアクセスを制限するために、以下のDeny文を使用することができます。
重要！
適用するネットワークレベルの制限を決定するには、可能性のあるすべてのユースケースを検討する必要があります。例えば、
- マネージド版を使用している場合、Unity Catalogによって事前サイン済みURLが生成され、お使いのリージョンのDatabricksコントロールプレーンのNAT IPからのアクセスを許可する必要があります。
- 1つ以上のDatabricksワークスペースもデータにアクセスする必要があり、同じリージョンにS3バケットがあり、S3に接続するためにVPCエンドポイントを使用している、あるいは、データプレーンのトラフィックを解決するパブリックIPアドレス(例えば、NATゲートウェイ経由)を使用している場合には、適切なVPC IDからのアクセスを許可する必要があります。
- 皆様の企業ネットワーク内からの接続できなくなることを防ぐために、例えば企業のVPNのパブリックIPなど、少なくとも既知の信頼IPアドレスからのアクセスを常に許可しておくことをお勧めします。これはDeny条件がAWSコンソール内でも適用されるためです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAccessFromUntrustedNetworks",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::",
"arn:aws:s3:::/*"
],
"Condition": {
"NotIpAddressIfExists": {
"aws:SourceIp": ["", "", ""]
},
"StringNotEqualsIfExists": {
"aws:SourceVpc": ["", ""]
}
}
}
]
}
ネットワークレベルの制限に加え、背後のS3バケットへのアクセスをUnity Catalogで使用されるIAMロールに限定することもお勧めします。この理由は、上で見てきたようにUnity CatalogはAWSのIAM/S3で提供される粗い粒度のアクセス権では実現不可能な方法で、きめ細かいアクセス制御を提供するためです。このため、直接S3バケットにアクセスすることができる誰かは、これらのきめ細かいアクセス権管理をバイパスし、あなたが意図した以上にデータにアクセスできることになってしまいます。
重要！
上述したとおり、Deny条件はAWSコンソール内にも適用されるので、少人数の許可されたユーザーがAWSのUI/APIを使用できるように管理者ロールのアクセスを許可するようにしておくことをお勧めします。
{
"Sid": "DenyActionsFromUntrustedPrincipals",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::",
"arn:aws:s3:::/*"
],
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalArn": [
"",
""
]
}
}
}
8. ストレージアカウントのログを設定する
背後のストレージアカウントに対するネットワークレベルの制限を課することに加えて、誰かがこれらをバイパスしようとしていないかを監視したいと考えるかもしれません。このためには以下のことをお勧めします。
- AWSでS3サーバーアクセスロギングをセットアップし、適切なモニタリングとアラートを行うようにします。
- Azureで診断ロギングをセットアップし、適切なモニタリングとアラートを行うようにします。
まとめ
分断されたデータアーキテクチャ、アクセスパターンを必要とし、企業がデータから価値を生み出すのに要する時間を遅延させていたデータ管理の問題の多くをレイクハウスが解決してきました。今では、データチームはこれらの問題から解放されており、オープンかつセキュアなデータ共有が次のフロンティアとなっています。
Delta Sharingは、データが存在しているプラットフォームとは独立した、企業内外でリアルタイムにデータをセキュアに共有するための世界初のオープンプロトコルです。Delta Sharingと上述のベストプラクティスを組み合わせることで、企業は容易かつ安全にユーザー、パートナー、顧客とデータを交換することができます。
既存のデータマーケットプレースは、データ提供者とデータ消費者にとってのビジネス価値を最大化することの失敗していますが、Databricks Marketplaceを用いることで、より多くの顧客にリーチするためにDatabrikcsレイクハウスプラットフォームを活用し、コストを削減し、皆様のデータプロダクトからより多くの価値を提供することができるようになります。
もし、データ提供者パートナーになることに興味があるのであれば、ぜひお話を伺えればと思います！