Best practices: Data governance | Databricks on AWS [2021/6/11時点]の翻訳です。
警告
こちらの内容は古くなっています。Databricksのデータガバナンスベストプラクティスをご覧ください。
本書では、データガバナンスの必要性と、組織内でこれらのテクニックを実装する際に使用できるベストプラクティスとストラテジーを共有します。Databricksとクラウドネイティブのソリューションを用いて、アプリケーションレイヤーからストレージレイヤーまでをセキュアにし、モニタリングするためにDatabricksを活用した典型的なデプロイメントワークフローを説明します。
なぜデータガバナンスが重要なのか？
データガバナンスは、企業におけるデータ資産をセキュアに管理するために実装するポリシー、プラクティスの総称です。データガバナンスを成功させる鍵となる信条の一つとして、データセキュリティが多くの大企業において最優先事項となります。データセキュリティのキーとなるのが、データチームが企業におけるユーザーのアクセスパターンに対して、優れた可視性と監査可能性を持てるかどうかです。効果的なデータガバナンスソリューションの実装によって、認証されないデータアクセスを防ぎ、規制の要件に準拠するためのルールを確実に適用できるようになります。
ガバナンスにおける課題
スタートアップ企業であろうが大企業であろうが、データを管理する際にセキュリティチームとプラットフォームオーナーは、企業の内部ルールに沿ってデータがセキュアに管理されていることを確実にする際に同じ課題に直面します。世界中の規制機関は、どのようにデータを収集し、蓄積するのかに関する考え方を変化させ続けています。これらのコンプライアンスリスクは、すでに複雑な問題に対してさらなる複雑性をもたらすことになります。それでは、将来的なユースケースをドライブする人たちに対して、どのようにデータを公開すればいいのでしょうか？最終的には、あなたは常に増加し続ける膨大な量のデータを蓄積し、それを活用する意味のあるアプリケーションを通じてビジネスが価値を生み出せるようなデータポリシーとデータプラクティスを導入しなくてはなりません。大量かつ散在しているデータにデータチームがアクセスする際に直面する困難な問題を解決するためのソリューションを我々は提供しています。
クラウド上のデータのセキュリティ、可用性を考えた際の典型的な課題には以下のようなものがあります：
- 現状のデータと分析ツールはクラウド上のデータに対するアクセスコントロールをサポートしていますか？使っているツールを用いてデータを移動した際のアクションに対して頑健性のあるログ機能を提供していますか？
- データレイクの規模が拡大した際、使用しているセキュリティ、モニタリングソリューションはスケールしますか？小規模ユーザーのデータアクセスのモニタリングは容易であることもあります。数百、数千のユーザーに対してデータを公開したときにどうなりますか？
- データアクセスポリシーが遵守されていることを確実にするためにプロアクティブにできることはありますか？単にモニタリングするだけでは、データが増えるだけであり不十分です。データセキュリティの課題がデータの可用性であるのであれば、企業情報へのアクセスをアクティブにモニタリング、トラッキングするためのソリューションを持つべきです。
- 既存のデータガバナンスソリューションのギャップを特定するためにどのようなステップを踏みますか？
Databricksはどのようにこれらの課題に取り組んでいるのか
- アクセスコントロール: ストレージレイヤーまで波及するアクセスコントロールスイート。Databricksはプラットフォーム上で最先端のAWSセキュリティサービスを使用して、クラウドバックボーンを活用します。ユーザーとデータレイクに対するセキュアなアクセス管理をシンプルにするために、SSOを介してお使いのIDプロバイダーを用い、既存のAWSデータアクセスロールを統合します。
- クラスターポリシー: 管理者が計算リソースに対するアクセス権を管理できるようにします。
- APIファースト: Databricks REST APIを用いてアクセス権管理を自動化します。
- 監査ログ: 使用しているワークスペースにおけるオペレーションやアクションを頑健性を持ってロギングします。
- AWSクラウドネイティブ: Databricksは、デプロイメントアカウントとその他のアセットに対するデータアクセス情報を提供するために、AWS CloudTrailとCloudWatchのパワーを活用します。潜在的な問題を知らせるためにアラートを送信することができます。
以下の章では、ガバナンスソリューションを実装するために、どのようにこれらのDatabricksの機能を活用するのかを説明します。
アクセスコントロールの設定
アクセスコントロールを有効化するためには、ストレージへのアクセスをセキュアなものにし、個々のテーブルに対してきめ細かいアクセスコントロールを実装する必要があります。
インスタンスプロファイルを用いたS3へのセキュアなアクセス
Databricksクラスターからのデータアクセスをセキュアにする方法の一つは、インスタンスプロファイルを使用する方法です。前提条件として、お使いのIAMロールがS3バケットにアクセスするのに必要なアクセス権を有していること、Databricksワークスペースにインスタンスプロファイルを追加する必要があります。クラスターを起動する際にインスタンスプロファイルを選択します。
クラスターが作成された後は、許可されたユーザーがノートブックをアタッチできるアクセス権を持っていること、作成したクラスターを使用していること、許可されないアクセスが拒否されることを確認してください。
このクラスターにアクセスできる全てのユーザーは、クラスターにアタッチされたインスタンスプロファイルを通じてS3バケットにもアクセスできるようになります。
これはセンシティブなデータへのアクセスをセキュアに管理し、頑健性のあるアクセスコントロールをセットアップするには、非常にシンプルかつ便利な方法です。ユーザー数の増加に合わせてスケールできる方法を好むのであれば、Instance Profiles APIを用いてワークフローを自動化することができます。
テーブルアクセスコントロールの実装
DatabricksでSpark SQL APIからのデータアクセスをプログラム上から許可、拒否、無効化できるようにするために、テーブルアクセスコントロールを有効化することができます。データベース、テーブル、ビュー、ファンクションのようなセキュリティ保護可能なオブジェクトに対するアクセスをコントロールすることができます。企業の財務データをデータベースに格納しているシナリオを考えてみます。分析者にこのデータを使って財務レポートを作らせたいとします。しかし、データベースの別のテーブルには、分析者がアクセスすべきではないセンシティブな情報が含まれているかもしれません。ユーザー、グループに対して一つのテーブルに対する読み取り権限を与え、二つ目のテーブルへのアクセスを拒否することができます。
以下の例では、AliceはFinanceデータベースのshared_dataとprivate_dataを所有している管理者です。Aliceは分析者であるOscarにshared_dataに対する読み取り権限を与え、private_dataに対するアクセスを拒否します。
Aliceは、Oscarがshared_dataからの読み取りができるようにSELECT権限を許可します。
Aliceはprivate_dataに対するOscarのアクセス権を拒否します。
テーブルのサブセットやテーブルから派生したビューに対するアクセス権を設定することで、きめ細かいアクセス権を定義することで、このステップをさらに推し進めることができます。
IAMクレディンシャルパススルー
Team AnalystsがS3バケットanalyst_project_dataに対して読み書きを行う必要があるという別のシナリオを見てみましょう。この環境はわかりやすいものです：ハイコンカレンシークラスターを設定し、S3バケットに読み書きできる権限を持つインスタンスプロファイルをアタッチします。そして、Team Analystsにこのクラスターを使用する権限を与えます。では、このバケットに対してさらに厳しいアクセス権を課したい場合、例えば、SarahとAliceはanalyst_project_dataに書き込みアクセス権を持ちますが、他のユーザーは読み取り権限のみを許可します。この場合、2つのクラスターが必要になります：バケットに対する読み取りアクセス権を与えるインスタンスプロファイルがアタッチされたクラスター、そして、S3バケットへの書き込みアクセス権を持つ別のインスタンスプロファイルがアタッチされSarahとAliceのみがアクセスできるクラスターです。データボリュームが増え、企業のアクセスポリシーがさらに複雑になり、それぞれ異なるアクセスコントロールを持つより多くのクラスターとIAMロールを管理することは苦痛となります。時に企業は、データセキュリティ要件に応えつつも、シンプルさとガバナンスのバランスを選択する必要に迫られます。
この問題を解決するために、DatabricksはIAMクレディンシャルパススルーを提供します。これによって、Databricksにログインする際に使ったIDを用いて、自動的にDatabricksのクラスターからS3バケットに対する認証を行うことができます。新たなクラスターを作成するに際にクレディンシャルパススルーを有効化するかどうかを選択できます。以下の画像では、ハイコンカレンシークラスターでクレディンシャルパススルーを有効化するためのオプションを示しています。
このオプションはスタンダードクラスターでは異なり、パススルーは単一のユーザーに限定されます。
Databricks SCIMあるいは、SAML 2.0によるAWSアイデンティティフェデレーションによって、Databricksがストレージレイヤーにクレディンシャルを引き渡すIAMクレディンシャルパススルーを用いて、S3バケットへのアクセスをセキュアなものにできます。
クラスター設定の管理
クラスターポリシーを用いることで、Databricks管理者はクラスターで許可される、インスタンスタイプ、ノード数、カスタムタグなどのクラスターの属性を定義することができます。管理者がクラスターポリシーを作成し、ユーザーあるいはグループに割り当てると、それらのユーザーはアクセスできるポリシーに準拠するクラスターのみを作成できます。これによって、管理者は作成できるクラスターをコントロールできるようになります。
JSON形式でポリシーを定義し、クラスターポリシーUIあるいはクラスターポリシーAPIでクラスタポリシーを作成することができます。create_clusterアクセス権を持っているか、少なくとも一つのクラスターポリシーにアクセスできるユーザーだけがクラスターを作成できます。上で述べたように分析プロジェクトチームに対する要件を拡張するために、管理者はクラスターポリシーを作成し、クラスターポリシーの範囲内でクラスターをプロジェクトチームのための作成するユーザーにクラスターポリシーを割り当てます。以下の画像は、ポリシー定義に基づいてクラスターを作成できるProject Team Cluster Policyにアクセスできるユーザーの例を示すものです。
クラスターの自動プロビジョンおよびアクセス権の設定
クラスターとアクセス権両方に対するエンドポイントに加えて、DatabricksのREST API 2.0を用いることで、大規模なユーザー、グループに対するクラスターリソースのアクセス権の設定が容易になります。
さらに、対応するストレージに対する直接アクセスするクラスターにインスタンスプロファイルをアタッチすることができます。
クラスターに対するアクセス権を適用するためにパーミッションAPIを使用することができます。
以下の設定例は、新たな分析プロジェクトチームに適したものになるかもしれません。
要件は以下の通りです:
- 多くがSQL、Pythonユーザーである、このチームのインタラクティブなワークロードをサポートします。
- ロールに紐づけられたデータに対するチームのアクセスを許可するクレディンシャルでオブジェクトストレージ上のデータソースを配備します。
- ユーザーは均等にクラスターのリソースを共有します。
- より大規模なメモリが最適化されたインスタンスタイプを配備します。
- 新たなプロジェクトチームのみがアクセスできるクラスターにアクセスを許可します。
- 発生した計算コストを適切に課金できるようにクラスターにタグをつけます。
デプロイメントスクリプト
クラスターAPI、パーミッションAPIのAPIエンドポイントを用いて、この設定を有効化します。
クラスターのプロビジョン
エンドポイント - https://<databricks-instance>/api/2.0/clusters/create
注意
スポットインスタンスを用いることでコストコントロールが有効化されます。
{
"autoscale": {
"min_workers": 2,
"max_workers": 50
},
"cluster_name": "project team interactive cluster",
"spark_version": "latest-stable-scala2.11",
"spark_conf": {
"spark.databricks.cluster.profile": "serverless",
"spark.databricks.repl.allowedLanguages": "sql,python,r"
},
"aws_attributes": {
"first_on_demand": 1,
"availability": "SPOT_WITH_FALLBACK",
"zone_id": "us-youst-2a",
"instance_profile_arn": "arn:aws:iam::826763667205:instance-profile/test-iam-role",
"spot_bid_price_percent": 100,
"ebs_volume_type": "GENERAL_PURPOSE_SSD",
"ebs_volume_count": 1,
"ebs_volume_size": 100
},
"node_type_id": "r4.2xlarge",
"ssh_public_keys": [],
"custom_tags": {
"ResourceClass": "Serverless",
"team": "new-project-team"
},
"spark_env_vars": {
"PYSPARK_PYTHON": "/databricks/python3/bin/python3"
},
"autotermination_minutes": 60,
"enable_elastic_disk": "true",
"init_scripts": []
}
クラスターアクセス権の許可
エンドポイント - https://<databricks-instance>/api/2.0/permissions/clusters/<cluster_id>
{
"access_control_list": [
{
"group_name": "project team",
"permission_level": "CAN_MANAGE"
}
]
}
これによって、データレイクの重要なデータに対するアクセスをセキュアな状態でクラスターを配備し、対応するチームのみのアクセスを許可し、課金のためのタグをつけ、プロジェクトの要件に応えるように設定を行います。このソリューションを実装するために、ホストしているクラウドプロバイダーアカウントでの追加の設定が必要となりますが、大規模な環境でも対応できるように自動化することができます。
アクセスの監査
Databricksにおけるアクセスコントロールの設定と、ストレージにおけるデータアクセスの制御は効率的データガバナンスソリューションの第一歩です。しかし、ソリューションを完全なものにするには、データアクセスの監査、アラート、モニタリングの機能が必要となります。企業がプラットフォームにおける詳細な利用パターンをモニタリングできるように、Databricksはユーザーの活動を記録できる包括的な監査イベントを提供します。ユーザーがプラットフォームで何をしているのか、どのデータにアクセスしているのかに関する完全な理解をするためには、Databricksネイティブの監査機能と、クラウドプロバイダーの監査機能の両方を使用する必要があります。
監査ログの設定を必ず行ってください。これには、あなたが提供するS3バケットにDatabricksが監査ログを格納できるように、適切なアクセスポリシーの設定が含まれます。監査ログは定期的にS3バケットに送信され、終日72時間以内の監査ログデリバリーを保証します。
Databricksの監査ログをどのように分析するのかの例を示します。全てのユーザーがどこからワークスペースにログインしたのかを検索します。これらのログはあなたのS3バケットで利用でき、日付でパーティション分けされています。Databricksで監査ログをデータフレームにロードし、一時テーブルに登録します。そして、適切なserviceName とactionNameで検索を行います。
アウトプットは以下のようになります。
これ以外のイベントを監査することができます。監査ログを設定することで、完全な監査イベント、パラメータ、監査ログスキーマを提供します。
ストレージレイヤーのモニタリング
CloudTrailとCloudWatchのようなAWSネイティブのサービスを実装することで、この監査機能をストレージレイヤーまで拡張することができます。これによって、以下のような質問に答えることが可能になります：
- データレイクでどのデータがアクセスされているのか？
- ユーザーが許可されないシンクに書き込みを行っていないか？データを削除していないか？
- アプリケーションレイヤーで適切なデータアクセスコントロールがなされているか？
- 除外、統合すべきデータソースはないか？
いくつかのステップで、CloudWatchのログストリームを生成するようにCloudTrailを設定でき、リアルタイムのアラートを作成できます。これらのアラートによって、ユーザー、それ以外の人物によるアクションをデータチームに通知することができ、様々な条件でカスタマイズすることができます。このようにして、データレイクのS3バケットで行われるアクションを厳密にモニター、管理することが可能となります。これらのアラートプロセスが有効化されることで、テーブル、データベースのアクセスコントロールにおけるギャップを特定することが容易になります。同様に、DatabricksでCloudTrailログを取り込み変換することも可能であり、Delta Lakeテーブルを用いて、最新のストリーミングログの分析を行うこともできます。
より詳細を学ぶには
こちらは、あなたの企業の要件に答えられる包括的なデータガバナンスソリューションを構築する際に助けになるリソースとなります。
- Use AWS Glue Data Catalog as the metastore for Databricks Runtime
- Access control on Databricks
- Databricksにおけるデータベースおよびテーブル - Qiita
- Databricksにおけるシークレットの管理 - Qiita
Immutaを使っているのでしたら、統合データ分析とデータガバナンスにおけるネイティブな製品統合を提供するDatabricksとのビジネスパートナーシップの恩恵を受けることができます。End-to-end Data Governance with Databricks and Immutaを参照してください。