次の方法で共有


Microsoft Purview コレクションのアーキテクチャとベスト プラクティス

Microsoft Purview 統合データ ガバナンス ソリューションの中核となるデータ マップは、サービスとしてのプラットフォーム (PaaS) コンポーネントであり、データ資産全体にわたって資産とそのメタデータの最新のマップを保持します。 データ マップをハイドレートするには、データ ソースを登録してスキャンする必要があります。 organizationでは、一元化されたチームまたは分散型チームによって管理および管理される何千ものデータ ソースが存在する可能性があります。

Microsoft Purview のコレクションでは、メタデータの組織マッピングがサポートされています。 コレクションを使用すると、フラット構造ではなく、階層内のデータ ソース、スキャン、資産を管理および管理できます。 コレクションを使用すると、organizationが Microsoft Purview を使用してランドスケープを管理する方法に基づいて、データランドスケープのカスタム階層モデルを構築できます。

コレクションは、データ マップ内のメタデータのセキュリティ境界も提供します。 コレクション、データ ソース、メタデータへのアクセスは、最小特権モデルに従って、Microsoft Purview のコレクション階層に基づいて設定および管理されます。

  • ユーザーは、ジョブを実行するために必要な最小限のアクセス権を持っています。
  • ユーザーは、必要のない機密データにアクセスできません。

Microsoft Purview アカウントのコレクションと承認モデルを定義する必要があるのはなぜですか?

次の要件を満たすために、Microsoft Purview にコレクションを展開することを検討してください。

  • ビジネス要件、データの地理的分布、データ管理チーム、部門、またはビジネス機能に基づいて、データ ソースを整理し、資産を分散し、スキャンを実行します。

  • 対応するコレクションにロールを割り当てることで、対応するチームにデータ ソースと資産の所有権を委任します。

  • コレクションで資産を検索およびフィルター処理します。

コレクション階層を定義する

設計に関する推奨事項

  • organizationのセキュリティ要件とデータ管理とガバナンス構造に基づいてコレクション アーキテクチャを設計することをお勧めします。 この記事で推奨 されるコレクションのアーキタイプを 確認してください。

  • 将来のスケーラビリティを確保するために、ルート コレクションの下にorganizationの最上位のコレクションを作成することをお勧めします。 ルート コレクションではなく、最上位のコレクションで関連するロールを割り当てます。

  • Microsoft Purview でコレクションを構築する場合は、設計の意思決定プロセスの一環として、セキュリティとアクセス管理を検討してください。

  • 各コレクションには、name 属性とフレンドリ名属性があります。 Microsoft Purview ガバナンス ポータルを使用してコレクションを展開する場合、重複を回避するために、システムによってコレクションにランダムな 6 文字の名前が自動的に割り当てられます。 複雑さを軽減するには、特に同じレベルで、コレクション全体で重複したフレンドリ名を使用しないようにします。

  • 現在、コレクション名には最大 36 文字を含め、コレクションフレンドリ名には最大 100 文字を含めることができます。

  • 可能な場合は、組織構造を深く入れ子になったコレクション階層に複製しないようにします。 これを回避できない場合は、コレクションを区別しやすくするために、階層内のすべてのコレクションに異なる名前を使用してください。

  • コレクションとロールの割り当てを一括でデプロイする場合は、API を使用してコレクションのデプロイを自動化します。

  • 専用サービス プリンシパル名 (SPN) を使用して、API を使用してコレクションとロールの割り当てに対する操作を実行します。 SPN を使用すると、権限を昇格したユーザーの数が減り、最小特権のガイドラインに従います。

設計上の考慮事項

  • 各 Microsoft Purview アカウントは、既定の ルート コレクションで作成されます。 ルート コレクション名は、Microsoft Purview アカウント名と同じです。 ルート コレクションは削除できません。 ルート コレクションのフレンドリ名を変更するには、Microsoft Purview 管理センターから Microsoft Purview アカウントのフレンドリ名を変更できます。

  • コレクションには、データ ソース、スキャン、資産、ロールの割り当てを保持できます。

  • コレクションには、必要な数の子コレクションを含めることができます。 ただし、各コレクションに含めることができる親コレクションは 1 つだけです。 ルート コレクションの上にコレクションを展開することはできません。

  • データ ソース、スキャン、および資産は、1 つのコレクションにのみ属できます。

  • Microsoft Purview のコレクション階層では、最大 8 レベルの深度で、最大 256 個のコレクションをサポートできます。 これにはルート コレクションは含まれません。

  • 設計上、1 つの Microsoft Purview アカウントにデータ ソースを複数回登録することはできません。 このアーキテクチャは、1 つのデータ ソースにさまざまなレベルのアクセス制御を割り当てるリスクを回避するのに役立ちます。 複数のチームが 1 つのデータ ソースのメタデータを使用する場合は、親コレクション内のデータ ソースを登録して管理できます。 その後、各サブコレクションの下に対応するスキャンを作成して、関連する資産が各子コレクションの下に表示されるようにすることができます。

  • 系列の接続と成果物は、データ ソースが下位レベルのコレクションに登録されている場合でも、ルート コレクションにアタッチされます。

  • 新しいスキャンを実行すると、既定では、スキャンはデータ ソースと同じコレクションにデプロイされます。 必要に応じて、別のサブコレクションを選択してスキャンを実行できます。 その結果、資産はサブコレクションの下に属します。

  • アセット、関連付けられたスキャン、データ ソース、または子コレクションがない場合は、コレクションを削除できます。

  • データ ソース、スキャン、資産が Microsoft Purview データ マップに存在する場合は、コレクションに属している必要があります。

  • ユーザーにソースコレクションとコピー先コレクションのデータ ソース 管理ロールが付与されている場合、コレクション間でのデータ ソースの移動が許可されます。

  • ソース コレクションとコピー先コレクションのデータ キュレーター ロールがユーザーに付与されている場合、コレクション間での資産の移動が許可されます。

  • コレクションに対して移動操作と名前変更操作を実行するには、次の推奨事項と考慮事項を確認します。

    1. コレクションの名前を変更するには、コレクション管理者ロールのメンバーである必要があります。

    2. コレクションを移動するには、ソース コレクションとコピー先コレクションのコレクション管理者ロールのメンバーである必要があります。

承認モデルを定義する

Microsoft Purview データ プレーンロールは、Microsoft Purview で管理されます。 Microsoft Purview アカウントをデプロイすると、Microsoft Purview アカウントの作成者には、ルート コレクションで次のロールが自動的に割り当てられます。 Microsoft Purview ガバナンス ポータルまたはプログラムによる方法を使用して、Microsoft Purview でロールを直接割り当てて管理できます。

  • コレクション管理者は 、Microsoft Purview コレクションとその詳細を編集し、サブコレクションを追加できます。 また、管理者がコレクション上の他の Microsoft Purview ロールにユーザーを追加することもできます。
  • データ ソース管理者は 、データ ソースとデータ スキャンを管理できます。
  • データ キュレーターは 、カタログ データ資産を作成、読み取り、変更、削除し、資産間のリレーションシップを確立できます。
  • データ 閲覧者 はカタログ データ資産にアクセスできますが、変更することはできません。

設計に関する推奨事項

  • Microsoft Purview アカウント レベルのロックアウトを回避するために、Microsoft Purview ルート コレクション レベルで Collection 管理 ロールに緊急アクセスまたは重大な戦略を実装することを検討してください。 緊急アカウントを使用するプロセスを文書化します。

    注:

    特定のシナリオでは、緊急アカウントを使用して Microsoft Purview にサインインすることが必要になる場合があります。 Microsoft Purview に他のユーザーがサインインできない場合や、企業認証の問題のために他の管理者が特定の操作を実行できない場合に、この種類のアカウントを使用して、organization レベルのアクセスの問題を解決することが必要になる場合があります。 クラウド専用ユーザーを使用した 緊急アクセス アカウント の実装に関する Microsoft のベスト プラクティスに従うことを強くお勧めします。

    以前のコレクション 管理が使用できない場合は、この記事の手順に従って Microsoft Purview ルート コレクションへのアクセスを回復します。

  • ルートコレクション管理者の数を最小限に抑えます。 ルート コレクションで最大 3 つの Collection 管理 ユーザーを割り当てます。これには SPN アカウントと break-glass アカウントが含まれます。 代わりに、コレクション 管理 ロールを最上位のコレクションまたはサブコレクションに割り当てます。

  • 個々のユーザーではなくグループにロールを割り当てて、個々のロールを管理する際の管理オーバーヘッドとエラーを減らします。

  • 自動化のために、ルート コレクションでサービス プリンシパルを割り当てます。

  • セキュリティを強化するには、少なくともコレクション管理者、データ ソース管理者、データ キュレーターに対して多要素認証を使用して Azure AD 条件付きアクセスを有効にします。 緊急アカウントが条件付きアクセス ポリシーから除外されていることを確認します。

設計上の考慮事項

  • Microsoft Purview アクセス管理がデータ プレーンに移行しました。 Azure Resource Manager ロールは使用されなくなったため、Microsoft Purview を使用してロールを割り当てる必要があります。

  • Microsoft Purview では、Microsoft Purview アカウントがデプロイされているのと同じ Azure AD テナント上の Azure Active Directory (Azure AD) から、ユーザー、セキュリティ グループ、サービス プリンシパル (マネージド ID を含む) にロールを割り当てることができます。

  • 外部ユーザーに Microsoft Purview ロールを割り当てるには、まずゲスト アカウントを B2B ユーザーとして Azure AD テナントに追加する必要があります。

  • 既定では、コレクション管理者はアセットの読み取りまたは変更にアクセスできません。 しかし、アクセス権を昇格させ、より多くのロールに自分自身を追加することができます。

  • 既定では、すべてのロールの割り当ては、すべての子コレクションによって自動的に継承されます。 ただし、ルート コレクションを除く任意のコレクションで [継承されたアクセス許可を制限 する]を有効にできます。 継承されたアクセス許可を制限すると、コレクション 管理 ロールを除くすべての親コレクションから継承されたロールが削除されます。

  • Azure Data Factory接続の場合: Azure Data Factoryに接続するには、ルート コレクションのコレクション 管理である必要があります。

  • 系列のAzure Data Factoryに接続する必要がある場合は、Microsoft Purview ルート コレクション レベルでデータ ファクトリのマネージド ID に Data Curator ロールを付与します。 作成 UI で Data Factory を Microsoft Purview に接続すると、Data Factory はこれらのロールの割り当てを自動的に追加しようとします。 Microsoft Purview ルート コレクションに対する Collection 管理 ロールがある場合、この操作は機能します。

コレクションのアーキタイプ

Microsoft Purview コレクションは、一元化された、分散型、またはハイブリッドのデータ管理とガバナンス モデルに基づいて展開できます。 この決定は、ビジネス要件とセキュリティ要件に基づいて行います。

例 1: 単一リージョンのorganization

この構造は、次の組織に適しています。

  • 主に 1 つの地理的な場所に基づいています。
  • 次のレベルのデータ管理が部門、チーム、またはプロジェクトに分類される、一元化されたデータ管理とガバナンス チームを用意します。

コレクション階層は、次の縦線で構成されます。

  • ルート コレクション (既定値)
  • Contoso (最上位のコレクション)
  • 部署 (各部門の委任されたコレクション)
  • Teams またはプロジェクト (プロジェクトに基づくさらに分離)

各データ ソースは、対応するコレクションに登録され、スキャンされます。 そのため、資産も同じコレクションに表示されます。

組織レベルの共有データ ソースは、Hub-Shared コレクションに登録され、スキャンされます。

部署レベルの共有データ ソースは、部署コレクションに登録され、スキャンされます。

最初の Microsoft Purview コレクションの例を示すスクリーンショット。

例 2: マルチリージョン organization

このシナリオは、組織に役立ちます。

  • これは複数のリージョンに存在します。
  • データ ガバナンス チームが各リージョンで一元化または分散化されている場所。
  • データ管理チームが各地理的な場所に分散される場所。

コレクション階層は、次の縦線で構成されます。

  • ルート コレクション (既定値)
  • FourthCoffee (最上位のコレクション)
  • 地理的な場所 (データ ソースとデータ所有者が配置されている地理的な場所に基づく中間レベルのコレクション)
  • 部署 (各部門の委任されたコレクション)
  • Teams またはプロジェクト (チームまたはプロジェクトに基づくさらに分離)

このシナリオでは、各リージョンには、Microsoft Purview アカウントの最上位コレクションの下に独自のサブコレクションがあります。 データ ソースは、独自の地理的な場所にある対応するサブコレクションに登録され、スキャンされます。 そのため、資産はリージョンのサブコレクション階層にも表示されます。

データ管理チームとガバナンス チームを一元化している場合は、最上位のコレクションからアクセス権を付与できます。 そうすると、データ マップ内のデータ資産全体が監視されます。 必要に応じて、一元化されたチームは、共有データ ソースを登録してスキャンできます。

リージョンベースのデータ管理チームとガバナンス チームは、対応するコレクションからより低いレベルでアクセスできます。

部署レベルの共有データ ソースは、部署コレクションに登録され、スキャンされます。

2 番目の Microsoft Purview コレクションの例を示すスクリーンショット。

例 3: マルチリージョン、データ変換

このシナリオは、地理的な場所とデータ変換の状態に基づいてメタデータ アクセス管理を分散する場合に役立ちます。 データをより意味のあるものにするためにデータを変換できるデータ サイエンティストとデータ エンジニアは、Raw ゾーンと Refine ゾーンを管理できます。 その後、データを Produce または Curated ゾーンに移動できます。

コレクション階層は、次の縦線で構成されます。

  • ルート コレクション (既定値)
  • Fabrikam (最上位のコレクション)
  • 地理的な場所 (データ ソースとデータ所有者が配置されている地理的な場所に基づく中間レベルのコレクション)
  • データ変換ステージ (Raw、Refine、Produce/Curated)

データ サイエンティストとデータ エンジニアは、メタデータをキュレーションできるように、対応するゾーンでデータ キュレーターの役割を持つことができます。 キュレーションされたゾーンへのデータ リーダー アクセスは、データ ペルソナ全体とビジネス ユーザーに付与できます。

3 番目の Microsoft Purview コレクションの例を示すスクリーンショット。

例 4: マルチリージョン、ビジネス関数

このオプションは、ビジネス機能に基づいてメタデータとアクセス管理を整理する必要がある組織で使用できます。

コレクション階層は、次の縦線で構成されます。

  • ルート コレクション (既定値)
  • AdventureWorks (最上位のコレクション)
  • 地理的な場所 (データ ソースとデータ所有者が配置されている地理的な場所に基づく中間レベルのコレクション)
  • 主要なビジネス機能またはクライアント (機能またはクライアントに基づくさらに分離)

各リージョンには、Microsoft Purview アカウントの最上位コレクションの下に、独自のサブコレクションがあります。 データ ソースは、独自の地理的な場所にある対応するサブコレクションに登録され、スキャンされます。 そのため、資産はリージョンのサブコレクション階層に追加されます。

データ管理チームとガバナンス チームを一元化している場合は、最上位のコレクションからアクセス権を付与できます。 そうすると、データ マップ内のデータ資産全体が監視されます。 必要に応じて、一元化されたチームは、共有データ ソースを登録してスキャンできます。

リージョンベースのデータ管理チームとガバナンス チームは、対応するコレクションからより低いレベルでアクセスできます。 各部署には、独自のサブコレクションがあります。

4 番目の Microsoft Purview コレクションの例を示すスクリーンショット。

アクセス管理オプション

organization全体でデータの民主化を実装する場合は、最上位レベルのコレクションのデータ閲覧者ロールをデータ管理、ガバナンス、ビジネス ユーザーに割り当てます。 サブコレクション レベルのデータ ソース 管理ロールとデータ キュレーター ロールを、対応するデータ管理およびガバナンス チームに割り当てます。

organizationでメタデータの検索と検出へのアクセスを制限する必要がある場合は、特定のコレクション レベルでデータ閲覧者ロールとデータ キュレーター ロールを割り当てます。 たとえば、米国の従業員を制限して、LATAM コレクションではなく米国のコレクション レベルでのみデータを読み取ることができるようにすることができます。

一部のコレクションに対していくつかの例外を除き、データの民主化の合計が必要な場合は、これらの 2 つのシナリオの組み合わせを Microsoft Purview データ マップに適用できます。 最上位のコレクションで Microsoft Purview ロールを割り当て、特定の子コレクションに継承を制限できます。

コレクション 管理 ロールを最上位のコレクションの一元化されたデータ セキュリティと管理チームに割り当てます。 下位レベルのコレクションのコレクション管理をさらに対応するチームに委任します。

次の手順