データ ガバナンスの概要

この記事では、データ ガバナンスの必要性について説明し、組織全体でこれらの手法を実装するために使用できるベスト プラクティスと戦略を共有します。

データ ガバナンスはなぜ重要なのか。

データ ガバナンスとは、確実にデータを有用に活用し、価値をもたらし、ビジネス戦略をサポートするための監視です。 データ ガバナンスには、組織内のデータ資産を安全に管理するために実装されるポリシーとプラクティスが含まれています。 データの量と複雑さが増すにつれ、中核となるビジネス成果を確保するために、データ ガバナンスに注目する組織がますます増えています。

  • 分析と機械学習の基盤としての一貫した高品質のデータ。
  • 分析情報を得る時間の短縮。
  • データの民主化 (つまり、組織内の全員がデータドリブンの意思決定を行えるようにすること)。
  • HIPPA、FedRAMP、GDPR、CCPA などの業界規制に対するリスクとコンプライアンスのサポート。
  • コストの最適化。たとえば、ユーザーが大規模なクラスターを起動できないようにすることや、高コストの GPU インスタンスを使う場合のガード レールを作成することなどです。

優れたデータ ガバナンス ソリューションとは

通常、データドリブン型の会社は、分析のためのデータ アーキテクチャをレイクハウス上に構築します。 データ レイクハウスとは、効率的かつ安全な Data Engineering、機械学習、データ ウェアハウス、ビジネス インテリジェンスを、データ レイクに格納された膨大な量のデータに対して直接可能にするアーキテクチャです。 データ レイクハウスのデータ ガバナンスの主要な機能は次のとおりです。

  • 統合カタログ: 統合カタログには、各データ オブジェクトのメタデータに加え、すべてのデータ、ML モデル、分析の成果物が格納されます。 統合カタログには、既存の Hive メタストアなど、他のカタログのデータも組み込まれています。
  • 統合データ アクセス制御: すべてのデータ資産とすべてのクラウドにわたる 1 つの統合されたアクセス許可モデル。 これには、個人を特定できる情報 (PII) に対する属性ベース アクセス制御 (ABAC) が含まれます。
  • データ監査: データ アクセスは、アカウンタビリティを促進するアラートと監視の機能を使って一元的に監査されます。
  • データ品質管理: 品質管理、テスト、監視、適用が組み込まれた堅牢なデータ品質管理により、ダウンストリームの BI、分析、機械学習ワークロードに正確かつ有用なデータを使用できるようにします。
  • データ系列: レイクハウスのソースから消費までのデータ フローをエンドツーエンドで視覚化するデータ系列。
  • データ検出: データ サイエンティスト、データ アナリスト、データ エンジニアが関連データを迅速に検出して参照し、価値を実現するまでの時間を短縮できるようにする簡単なデータ検出。
  • データ共有: クラウドとプラットフォーム間でデータを共有できます。

データ ガバナンスと Azure Databricks

Azure Databricks は、Unity Catalog と Delta Sharing を使って、データと AI の一元的なガバナンスを実現しています。

  • Unity Catalog は、Databricks Lakehouse 上のデータと AI に対する粒度の細かいガバナンス ソリューションです。 データ アクセスの管理や監査を行い、データ系列を追跡する一元的な場所を提供することで、データのセキュリティとガバナンスを簡素化するのに役立ちます。
  • Delta Sharing は、使用するコンピューティング プラットフォームに関係なく、他の組織や、自組織内の他のチームと安全にデータを共有するために Databricks によって開発されたオープン プロトコルです。

このドキュメントでは、お客様のデータ ガバナンスのニーズを満たすために Azure Databricks Unity Catalog と Delta Sharing を導入する最適な方法について、独自の観点で説明します。

ユーザー、サービス プリンシパル、グループを構成する

すべての優れたデータ ガバナンスのストーリーは、強力な ID ソリューションから始まります。 Unity Catalog は、Databricks のアカウント レベルの ID システムを使ってユーザー、サービス プリンシパル、グループを解決し、アクセス許可を適用します。

以下の 3 種類の Azure Databricks ID があります。

  • ユーザー: Azure Databricks で認識され、メール アドレスで表されるユーザー ID。
  • サービス プリンシパル: ジョブ、自動化ツール、システム (スクリプト、アプリ、CI/CD プラットフォームなど) での使用を目的に作成された ID。 Databricks では、運用ジョブを実行する、または運用データを変更するサービス プリンシパルを作成することを推奨しています。 サービス プリンシパルは、運用テーブルへの書き込みまたは運用コンテナーの使用を実行できる唯一の ID の種類にするようにします。 運用データに作用するすべてのプロセスがサービス プリンシパルを使って実行される場合、対話型ユーザーには運用環境での書き込み、削除、または変更の特権が必要ありません。 こうすることで、ユーザーが誤って運用データを上書きするリスクがなくなります。
  • グループ: グループを使用すると、ID 管理が簡素化され、ワークスペース、データ、およびその他のセキュリティ保護可能なオブジェクトへのアクセスを簡単に割り当てることができます。 Unity Catalog 内のワークスペースとアクセス制御ポリシーへのアクセスは、ユーザーに個別に割り当てるのではなく、グループに一度割り当ててから、メンバーをグループに追加するのがベスト プラクティスです。 すべての Databricks ID はグループのメンバーとして割り当てることができます。また、メンバーはそのグループに割り当てられているアクセス許可を継承します。

Unity Catalog は、Databricks のアカウント レベルの ID システムを使用して、ユーザーとグループを解決し、アクセス許可を適用します。 すべての既存のワークスペース ユーザーとサービス プリンシパルと、ワークスペースレベルで作成された新規のユーザーとサービス プリンシパルは、アカウントレベルのユーザーとサービス プリンシパルとして自分のアカウントに自動的に同期されます。 ただし、ワークスペース レベルで作成された新規と既存のグループは、どちらもアカウントに同期されません。 この代わりに、Azure Databricks には "アカウント グループ" と "ワークスペースローカル グループ" の概念があります。 Unity Catalog でアカウント グループにアクセス制御ポリシーを割り当てることはできますが、Unity Catalog でワークスペースローカル グループを使うことはできません。 そのため、Azure Databricks では、アカウント グループではなくワークスペース ローカル グループを使用することをお勧めしません。 ワークスペースローカル グループがある場合、アカウント グループに移行することができます。 「グループの管理」を参照してください

Azure Active Directory から Azure Databricks アカウントにユーザーとグループを同期する

Databricks では、SCIM プロビジョニングを使って、ユーザーとグループを Azure Active Directory から Azure Databricks アカウントに自動的に同期することをお勧めします。 Azure Active Directory を使って Azure Databricks にユーザーとグループを作成し、適切なレベルのアクセス権を付与することで、SCIM によって新しい従業員またはチームのオンボードを効率化することができます。 ユーザーが組織を離れた場合、または Azure Databricks へのアクセスが不要になった場合、管理者は Azure Active Directory でそのユーザーを終了することができます。そのユーザーのアカウントは Azure Databricks からも削除されます。 こうすることで、一貫したオフボード プロセスを実現し、権限のないユーザーによる機密データへのアクセスを防ぎます。

Azure Databricks を使う予定があるすべてのユーザーとグループを、個々のワークスペースではなく、アカウント コンソールに同期することを目指してください。 このようにすると、1 つの SCIM プロビジョニング アプリケーションを構成するだけで、アカウント内のすべてのワークスペースですべての ID の一貫性を保つことができます。

ワークスペース用にワークスペースレベルの SCIM プロビジョニングを既に設定している場合は、アカウントレベルの SCIM プロビジョニングを設定し、ワークスペースレベルの SCIM プロビジョナーをオフにする必要があります。

そうすると、特定のユーザー、グループ、サービス プリンシパルを、アカウントから Azure Databricks 内の特定のワークスペースに割り当てることができます。

管理者を構成する

Unity Catalog を管理するための管理者ロールは次のとおりです。

  • アカウント管理者は、ID、課金、クラウド リソース、ワークスペースと Unity Catalog メタストアの作成など、Azure Databricks のアカウントレベルの構成を管理することができます。 アカウント管理者は、Unity Catalog のワークスペースを有効にすることができます。 また、ワークスペースとメタストアの両方の管理者アクセス許可を付与することができます。 1 つのアカウント内のアカウント管理者は少人数に抑えるようにしてください。
  • メタストア管理者は、メタストア内のセキュリティ保護可能なすべてのオブジェクトの権限を管理できます。たとえば、誰がカタログを作成できるか、誰がテーブルにクエリを実行できるかなどです。 Unity Catalog メタストアを作成したアカウント管理者が最初のメタストア管理者になります。Databricks では、この管理者がメタストア管理者ロールをグループに譲渡することをお勧めします。 「(推奨) メタストアの所有権をグループに譲渡する」を参照してください
  • ワークスペース管理者は、Azure Databricks ワークスペースにユーザーを追加し、ワークスペース管理者ロールを割り当て、ワークスペースのオブジェクトや機能へのアクセス (クラスターの作成やジョブ所有権の変更を行う能力など) を管理することができます。 各ワークスペース内のワークスペース管理者は少人数に抑えるようにしてください。

Unity Catalog メタストアを構成する

次の図に、Unity Catalog のセキュリティ保護可能な主要なオブジェクトを示します。

Unity カタログ オブジェクト モデルの図

Note

外部の場所やストレージの資格情報など、一部のオブジェクトは図に示されていません。 これらのオブジェクトは、カタログと同じレベルのメタストアに存在します。

メタストアは、Unity Catalog 内のオブジェクトの最上位レベルのコンテナーです。 このコンテナーにデータ資産 (テーブルおよびビュー) と、それらへのアクセスを制御するアクセス許可を保存します。 Databricks アカウント管理者はメタストアを作成し、Databricks ワークスペースに割り当てて、各メタストアを使用するワークロードを制御できます。 運用するリージョンごとに 1 つのメタストアを作成し、そのリージョン内のすべてのワークスペースにリンクします。 そのため、Databricks を使うリージョンが複数ある場合は、メタストアが複数になります。 メタストア間でデータを共有するには、Delta Sharing に関する記事を参照してください。

各メタストアは、マネージド テーブルに使われるルート ストレージの場所で構成されます。 このストレージの場所に直接アクセスできるユーザーがいないことを確認する必要があります。 このようなことがあると、ユーザーが Unity Catalog メタストアのアクセス制御をバイパスし、監査可能性を損なう可能性があります。 こうした理由があるので、現在の DBFS ルート ファイル システムである、または以前に DBFS ルート ファイル システムだったコンテナーを Unity Catalog メタストアのルート ストレージの場所に再利用しないでください。

Unity Catalog メタストアを作成する」を参照してください。

外部の場所とストレージの資格情報

外部の場所とストレージの資格情報を使用すると、ユーザーに代わって、Unity Catalog でクラウド テナントのデータの読み取りと書き込みを行うことができます。

"ストレージの資格情報" を使って、クラウド ストレージへのアクセスを提供する長期的なクラウドの資格情報をカプセル化します。 Azure マネージド ID (強くお勧めします) またはサービス プリンシパルのいずれかにすることができます。 Azure マネージド ID の使用は、次の点でサービス プリンシパルの使用よりも優れています。

  • ストレージ ファイアウォールによって保護されている Azure Data Lake Storage Gen2 アカウントに接続できます。
  • マネージド ID では、資格情報を維持したり、シークレットをローテーションしたりする必要がありません。

"外部の場所" は、クラウド ストレージ パスと、クラウド ストレージ パスへのアクセスを認可するためのストレージの資格情報を組み合わせたオブジェクトです。

Databricks では、ストレージの資格情報を直接使用するのではなく外部の場所を使用することをお勧めします。 外部の場所として使われているコンテナーに直接アクセスできるユーザーは、少人数に抑えるようにしてください。 この目的は、ユーザーが Unity Catalog メタストアのアクセス制御をバイパスし、監査可能性を損なうことを制限するためです。 このような理由から、外部の場所として使われている DBFS にストレージ アカウントをマウントしないでください。

Databricks では、Data Explorer を使って、クラウド ストレージの場所に対するマウントを Unity Catalog 内の外部の場所に移行することをお勧めします。

外部の場所とストレージの資格情報を管理する」を参照してください。

データを整理する

Databricks では、カタログを使って組織の情報アーキテクチャ全体で分離を実現することをお勧めします。 多くの場合、これは、ソフトウェア開発環境のスコープ、チーム、またはビジネス ユニットに対応したカタログを使用できることを意味します。

Unity Catalog のカタログ

スキーマ (データベースとも呼ばれる) は、Unity Catalog の 3 レベルの名前空間の 2 番目のレイヤーであり、テーブルとビューを編成します。 テーブルは、"マネージド" か "外部" にすることができます。

マネージド テーブルは、Unity Catalog にテーブルを作成する際の既定の方法です。 これらのテーブルは、メタストア作成時に構成した Unity Catalog のルート ストレージの場所に格納されます。 Databricks では、Unity Catalog の機能を確実にサポートするために、マネージド テーブルを使うことをお勧めします。 すべてのマネージド テーブルは Delta Lake を使います。

外部テーブルは、データがマネージド ストレージの場所の外部に格納されており、Unity Catalog の完全な管理下にはないテーブルです。 外部テーブルは、Delta Lake と他の多くのデータ形式 (Parquet、JSON、CSV など) をサポートします。 外部テーブルは、生データへの直接アクセスを提供する優れたオプションとして利用できます。

テーブルの作成」を参照してください。

アクセスの制御の構成

Unity Catalog 内のセキュリティ保護が可能なオブジェクトのそれぞれに所有者が存在します。 オブジェクトを作成するプリンシパルが、その最初の所有者になります。 オブジェクトの所有者は、オブジェクトに対するすべての特権 (テーブルに対する SELECT や MODIFY など) と、セキュリティ保護可能なオブジェクトに対する特権を他のプリンシパルに付与するアクセス許可を持っています。 セキュリティ保護可能なオブジェクトの所有者のみが、そのオブジェクトに対する特権を他のプリンシパルに付与するアクセス許可を持っています。 そのため、すべてのオブジェクトに対する所有権を、そのオブジェクトに対する許可の管理を担当するグループに構成することがベスト プラクティスです。 所有者とメタストア管理者の両方が、セキュリティ保護可能なオブジェクトの所有権をグループに譲渡することができます。 さらに、オブジェクトがカタログ内に含まれている場合 (テーブルやビューなど)、そのカタログとスキーマの所有者はオブジェクトの所有権を変更できます。

テーブルまたはビューからデータを読み取るには、ユーザーが次の特権を持っている必要があります。

  • テーブルまたはビューに対する SELECT
  • テーブルを所有するスキーマに対する USAGE
  • スキーマを所有するカタログに対する USAGE

USAGE により、被付与者は、子オブジェクトにアクセスするためにセキュリティ保護可能なリソースをトラバースできるようになります。 たとえば、テーブルからデータを選ぶには、そのテーブルに対する SELECT 特権と、親スキーマと親カタログに対する USAGE 特権が必要です。 このため、この権限を使用して、データの名前空間のセクションへのアクセスを特定のグループに制限できます。 よくあるシナリオは、チームごとにスキーマを設定し、そのチームだけがスキーマに対して USAGECREATE を持つようにすることです。 つまり、チーム メンバーが作成したテーブルは、チーム内でのみ共有できます。

テーブルへのアクセスは、次の SQL 構文を使ってセキュリティで保護できます。

GRANT USAGE ON CATALOG < catalog_name > TO `<group_name>`;
GRANT USAGE ON SCHEMA < catalog_name >.< schema_name >
TO `<group_name>`;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO `<group_name>`;

列へのアクセスをセキュリティで保護するには、次の SQL 構文に示すように、セカンダリ スキーマで動的ビューを使います。

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_member('<group_name>') THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USAGE ON CATALOG < catalog_name > TO `<group_name>`;
GRANT USAGE ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO `<group_name>`;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO `<group_name>`;

行へのアクセスをセキュリティで保護するには、次の SQL 構文に示すように、セカンダリ スキーマで動的ビューを使います。

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_member('managers') THEN TRUE ELSE total <= 1000000 END;
GRANT USAGE ON CATALOG < catalog_name > TO `<group_name>`;
GRANT USAGE ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO `<group_name>`;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO `<group_name>`;

Unity Catalog の特権の管理」を参照してください。

クラスター構成を管理する

Databricks では、クラスター ポリシーを使って、一連のルールに基づいてクラスターを構成する能力を制限することをお勧めします。 クラスター ポリシーを使うと、Unity Catalog が有効なクラスターのみを作成するようにアクセスを制限できます。 クラスター ポリシーを使うと、使用できる選択肢が少なくなるので、ユーザーのクラスター作成プロセスが大幅に簡略化され、データにシームレスにアクセスできるようになります。 また、クラスター ポリシーを使ってクラスターごとの最大コストを制限して、コストを制御することもできます。

アクセス制御の整合性を確保し、強力な分離を保証するために、Unity Catalog ではコンピューティング リソースにセキュリティ要件を課しています。 このため、Unity Catalog には、クラスターのアクセス モードの概念が導入されています。 Unity Catalog は、既定ではセキュリティで保護されています。クラスターが適切なアクセス モードで構成されていない場合、クラスターは Unity Catalog のデータにアクセスできません。 Unity Catalog のクラスター アクセス モードに関する記事を参照してください。

Databricks では、クラスターを共有する場合はユーザー分離アクセス モードを、自動ジョブには単一ユーザー アクセス モードを使うことをお勧めします。

次の JSON は、ユーザー分離セキュリティ モードを使った共有クラスターのポリシー定義を示しています。

{
  "spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
  },
  "access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
  }
}

次の JSON は、単一ユーザー セキュリティ モードを使った自動ジョブ クラスターのポリシー定義を示します。

{
  "spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
  },
  "access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
  },
  "single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
  }
}

アクセスを監査する

完全なデータ ガバナンス ソリューションを実現するには、データへのアクセスを監査し、アラートと監視の機能を提供する必要があります。 Unity Catalog によって、メタストアに対して実行されたアクションの監査ログがキャプチャされます。これらのログは、Azure Databricks 監査ログの一部として配信されます。

必ず Azure Databricks ワークスペースで監査ログを構成してください。 アカウントでログを有効にすると、指定した配信場所への診断ログの送信が Azure Databricks によって自動的に開始されます。

Databricks Lakehouse Platform に関連する重要なイベントを完全に視覚化する方法の詳細については、「Monitoring Your Databricks Lakehouse Platform with Audit Logs (監査ログを使った Databricks Lakehouse Platform の監視)」を参照してください。

Delta Sharing

Delta Sharing は、使用するコンピューティング プラットフォームに関係なく、他の組織や、自組織内の他の部門と安全にデータを共有するために Databricks によって開発されたオープン プロトコルです。 メタストアで Delta Sharing が有効になっている場合、Unity Catalog は Delta Sharing サーバーを実行します。

メタストア間でデータを共有するには、Azure Databricks マネージド Delta Sharing を利用できます。 これにより、さまざまなリージョンのメタストアからテーブルを登録できます。 これらのテーブルは、使用しているメタストア内で読み取り専用オブジェクトと表示されます。 Unity Catalog 内の他のオブジェクトと同様に、これらのテーブルにはアクセス権を付与することができます。

詳細情報

組織のニーズを満たす包括的なデータ ガバナンス ソリューションを構築するのに役立ついくつかのリソースを以下に示します。