Microsoft Purview (旧称 Azure Purview) デプロイのベスト プラクティス

  • [アーティクル]

この記事は、Microsoft Purview (旧称 Azure Purview) をデータ資産の運用環境に正常にデプロイするためのガイドです。 これは、調査から運用環境の強化まで、デプロイを戦略化して段階的に行うのに役立つものであり、 デプロイ チェックリストと組み合わせて使用することをお勧めします。

注:

これらのベスト プラクティスでは、 Microsoft Purview 統合データ ガバナンス ソリューションの展開について説明します。 Microsoft Purview のリスクとコンプライアンス ソリューションの詳細については、 こちらを参照してください。 Microsoft Purview 全般の詳細については、 こちらを参照してください。

厳密に技術的なデプロイ ガイドをお探しの場合は、 デプロイ チェックリストを使用してください。

Microsoft Purview を展開する計画を作成していて、デプロイ戦略を策定するときにベスト プラクティスを検討する場合は、以下の記事に従ってください。 このガイドでは、Microsoft Purview の展開プロセスを開発するために、1 か月以上にわたって段階的にタスクを完了できることを概説します。 Microsoft Purview を既に展開している組織でも、このガイドを使用して、投資を最大限に活用できます。

データ ガバナンス プラットフォームの適切に計画されたデプロイには、次の利点があります。

  • データ検出の向上
  • 分析コラボレーションの改善
  • 投資収益率の最大化

このガイドでは、次のステージに従って、初期計画から成熟した環境までの完全なデプロイ ライフサイクルに関する分析情報を提供します。

ステージ 説明
目標と目標を特定する organization全体がデータ ガバナンスに対して何を望み、必要とするかを検討します。
質問の収集 作業を開始する際に、自分とチームにどのような質問があり、その対処を開始する場所を確認できますか?
運用環境に移行するプロセスを作成する organizationに合わせて段階的なデプロイ戦略を作成します。
プラットフォームのセキュリティ強化 デプロイを成熟度に引き続き拡大します。

Microsoft Purview のアプリケーションと機能の多くは、独自のベスト プラクティス ページもあります。 これらは、このデプロイ ガイド全体で頻繁に参照されますが、[ 概念 ] と [ ベスト プラクティスとガイドライン] の目次で見つけることができます。

目標と目標を特定する

多くの組織は、organization全体で分離されたグループとデータ ドメインの特定の要件に対応する個々のソリューションを開発することで、データ ガバナンスの取り組みを開始しています。 エクスペリエンスは業界、製品、文化によって異なる場合がありますが、ほとんどの組織では、これらの種類のソリューションに対して一貫した制御とポリシーを維持することは困難です。

包括的なデータ ガバナンス エクスペリエンスを作成するために、初期フェーズで特定する必要がある一般的なデータ ガバナンスの目標の一部を次に示します。

  • データのビジネス価値を最大化する
  • データ コンシューマーがデータを簡単に見つけ、解釈し、信頼できるデータ カルチャを有効にする
  • 一貫性のあるデータ エクスペリエンスを提供するために、さまざまな部署間のコラボレーションを増やす
  • データ分析を加速し、クラウドのメリットを享受することでイノベーションを促進する
  • さまざまなスキル グループのセルフサービス オプションを使用してデータを検出する時間を短縮する
  • 顧客へのサービスを向上させる分析ソリューションの提供のための市場投入までの時間を短縮する
  • ドメイン固有のツールとサポートされていないテクノロジの使用に起因する運用リスクの軽減

一般的なアプローチは、これらの包括的な目標をさまざまなカテゴリと目標に分割することです。 次に例を示します。

カテゴリ 目標
検出 管理ユーザーは、Azure データ ソースと Azure 以外のデータ ソース (オンプレミス ソースを含む) をスキャンして、データ資産に関する情報を自動的に収集できる必要があります。
分類 プラットフォームでは、データのサンプリングに基づいてデータを自動的に分類し、カスタム分類を使用して手動でオーバーライドできるようにする必要があります。
消費 ビジネス ユーザーは、ビジネス メタデータと技術メタデータの両方の各資産に関する情報を見つけることができる必要があります。
系統 各資産は、元のソースと行われた変更をユーザーが理解できるように、基になるデータセットのグラフィカル ビューを表示する必要があります。
グループ作業 プラットフォームでは、ユーザーが各データ資産に関する追加情報を提供して共同作業できるようにする必要があります。
Reporting ユーザーは、機密データや余分なエンリッチメントが必要なデータなど、データ資産に関するレポートを表示できる必要があります。
データ ガバナンス プラットフォームでは、管理者がアクセス制御のポリシーを定義し、各ユーザーに基づいてデータ アクセスを自動的に適用できるようにする必要があります。
ワークフロー プラットフォームには、プラットフォーム内のさまざまなタスクを簡単にスケールアウトして自動化できるように、ワークフローを作成および変更できる必要があります。
統合 チケット発行やオーケストレーションなどの他のサード パーティのテクノロジは、スクリプトまたは REST API を使用してプラットフォームに統合できる必要があります。

主要なシナリオを特定する

Microsoft Purview ガバナンス サービスを使用すると、クラウド環境とオンプレミス環境にまたがるorganizationのデータ資産全体でデータ ガバナンスを一元的に管理できます。 実装を成功させるには、ビジネスにとって重要な主要なシナリオを特定する必要があります。 これらのシナリオは、ビジネス ユニットの境界を越えたり、アップストリームまたはダウンストリームの複数のユーザー ペルソナに影響を与えたりする可能性があります。

これらのシナリオはさまざまな方法で記述できますが、少なくとも次の 5 つのディメンションを含める必要があります。

  1. ペルソナ – ユーザーは誰ですか?
  2. ソース システム – Azure Data Lake Storage Gen2 や Azure SQL Database などのデータ ソースは何ですか?
  3. 影響領域 – このシナリオのカテゴリは何ですか?
  4. 詳細シナリオ – ユーザーが Microsoft Purview を使用して問題を解決する方法
  5. 期待される結果 – 成功基準は何ですか?

シナリオは、測定可能な結果を含む、特定の実行可能な実行可能なシナリオである必要があります。 使用できるシナリオの例を次に示します。

シナリオ 詳細 ペルソナ
ビジネスクリティカルな資産をカタログ化する 私はそれが何であるかを十分に理解するために、各データセットに関する情報を持っている必要があります。 このシナリオには、カタログ内のデータ セットに関するビジネス メタデータ データと技術メタデータ データの両方が含まれます。 データ ソースには、Azure Data Lake Storage Gen2、Azure Synapse DW、Power BI が含まれます。 このシナリオには、SQL Serverなどのオンプレミス リソースも含まれます。 ビジネス アナリスト、データ科学者、データ エンジニア
ビジネスクリティカルな資産を発見する カタログ内のすべてのメタデータを検索できる検索エンジンが必要です。 技術用語、ビジネス用語、ワイルドカードを使用した単純検索または複雑な検索を使用して検索できる必要があります。 ビジネス アナリスト、データ科学者、データ エンジニア、データ 管理
データを追跡してデータの配信元を把握し、データの問題のトラブルシューティングを行う レポート、予測、またはモデルのデータを元のソースに戻すために、データ系列が必要です。 また、データに加えられた変更と、データライフ サイクルを通じてデータが存在する場所も理解する必要があります。 このシナリオでは、優先順位付けされたデータ パイプラインAzure Data Factoryと Databricks をサポートする必要があります。 データ エンジニア、データ科学者
重要なデータ資産のメタデータを強化する カタログ内のデータ セットを、自動的に生成される技術メタデータで強化する必要があります。 分類とラベル付けは、いくつかの例です。 データ エンジニア、ドメイン/ビジネス所有者
わかりやすいユーザー エクスペリエンスを使用してデータ資産を管理する ビジネス固有のメタデータのビジネス用語集が必要です。 ビジネス ユーザーは、セルフサービス シナリオで Microsoft Purview を使用してデータに注釈を付け、検索を介してデータを簡単に検出できます。 ドメイン/ビジネス所有者、ビジネス アナリスト、データ科学者、データ エンジニア

Microsoft Purview との統合ポイント

成熟したorganizationに既存のデータ カタログが既に存在している可能性があります。 重要な問題は、既存のテクノロジを引き続き使用し、Microsoft Purview データ マップと同期してData Catalogするかどうかです。 Microsoft Purview は、organization内の既存の製品との同期を処理するために、Atlas REST API を提供します。 Atlas API は、プッシュとプルの両方のシナリオを処理する強力で柔軟なメカニズムを提供します。 ブートストラップ用の Atlas API を使用して、または別のシステムから Microsoft Purview に最新の更新プログラムをプッシュするために、Microsoft Purview に情報を公開できます。 Microsoft Purview で利用できる情報は、Atlas API を使用して読み取り、既存の製品と同期することもできます。

チケット作成、カスタム ユーザー インターフェイス、オーケストレーションなどの他の統合シナリオでは、Atlas API と Kafka エンドポイントを使用できます。 一般に、Microsoft Purview との統合ポイントは 4 つあります。

  • データ資産 – これにより、Microsoft Purview はストアの資産をスキャンして、それらの資産が何であるかを列挙し、それらについてすぐに利用可能なメタデータを収集できます。 したがって、SQL の場合、これは、DB、テーブル、ストアド プロシージャ、ビュー、および構成データの一覧であり、 のような sys.tables場所に保持されます。 Azure Data Factory (ADF) のような場合、これはすべてのパイプラインを列挙し、作成時、最後の実行、現在の状態に関するデータを取得する可能性があります。
  • 系列 – これにより、Microsoft Purview は、データの移動方法に関する分析/データ変更システムから情報を収集できます。 Spark のような場合、ノートブックの実行から情報を収集して、ノートブックが取り込んだデータ、変換方法、出力場所を確認できます。 SQL のような場合は、クエリ ログを分析して、実行された変更操作と実行内容をリバース エンジニアリングできます。 私たちは、ニーズに応じてプッシュベースとプルベースの系列の両方をサポートしています。
  • 分類 – これにより、Microsoft Purview はデータ ソースから物理サンプルを取得し、分類システムを介して実行できます。 分類システムは、データのセマンティクスを把握します。 たとえば、ファイルが Parquet ファイルであり、3 つの列があり、3 番目の列が文字列であることがわかります。 ただし、サンプルで実行する分類子は、文字列が名前、住所、または電話番号であることを示します。 この統合ポイントを点灯することは、Microsoft Purview がノートブック、パイプライン、Parquet ファイル、テーブル、コンテナーなどのオブジェクトを開く方法を定義したことを意味します。
  • 埋め込みエクスペリエンス – エクスペリエンス (ADF、Synapse、SQL Studio、PBI、Dynamics など) のような "スタジオ" を持つ製品は、通常、ユーザーが操作するデータを検出したり、データを出力する場所を見つけたりできるようにします。 Microsoft Purview のカタログは、埋め込みエクスペリエンスを提供することで、これらのエクスペリエンスを加速するのに役立ちます。 このエクスペリエンスは、API またはパートナーのオプションの UX レベルで発生する可能性があります。 Microsoft Purview の呼び出しを埋め込むことで、organizationはデータ資産の Microsoft Purview のマップを利用して、データ資産の検索、系列、スキーマのチェック、評価、連絡先の確認などを行うことができます。

質問の収集

organizationが高レベルの目標と目標に同意すると、複数のグループから多くの質問が発生します。 すべての懸念事項に対処する計画を立てるには、これらの質問を収集することが重要です。 これらの質問を収集するときは、 関連するグループを必ず含めます 。 Microsoft のドキュメントを使用して、回答を開始できます。

最初のフェーズで発生する可能性がある質問の例を次に示します。

これらの質問のほとんどにすぐに答えが得られない場合でも、質問を収集すると、organizationがこのプロジェクトを組み立て、すべての "必須" 要件を満たすことができます。

適切な利害関係者を含める

organization全体に Microsoft Purview を実装する成功を確実にするには、適切な利害関係者を巻き込む必要があります。 最初のフェーズに関与している人はごくわずかです。 ただし、範囲が広がると、プロジェクトに貢献し、フィードバックを提供するために、より多くのペルソナが必要になります。

含める必要がある主要な利害関係者:

ペルソナ 役割
最高データ責任者 CDO は、データ管理、データ品質、マスター データ管理、データ サイエンス、ビジネス インテリジェンス、データ戦略の作成など、さまざまな機能を監視します。 Microsoft Purview 実装プロジェクトのスポンサーになる場合があります。
ドメイン/ビジネス所有者 ツールの使用に影響を与え、予算管理を行うビジネスパーソン
データ アナリスト ビジネス上の問題を解決し、リーダーがビジネス上の意思決定を行うのに役立つデータを分析できる
データ アーキテクト ミッション クリティカルな基幹業務アプリのデータベースを設計し、データ セキュリティを設計および実装する
データ エンジニア データ スタックの運用と管理、さまざまなソースからのデータのプル、データの統合と準備、データ パイプラインの設定
データ科学者 分析モデルを構築し、API によってアクセスされるデータ製品を設定する
DB 管理 サービス レベル アグリーメント (SLA) 内でデータベース関連のインシデントと要求を所有、追跡、解決する。データ パイプラインを設定する場合があります
DevOps 基幹業務アプリケーションの開発と実装。スクリプトとオーケストレーション機能の記述が含まれる場合があります
データ セキュリティ スペシャリスト ネットワークとデータの全体的なセキュリティを評価します。これには、Microsoft Purview に出入りするデータが含まれます

運用環境に移行するプロセスを作成する

以下に、各フェーズのタスク、役立つリンク、受け入れ条件を含む、潜在的な 4 つのフェーズ展開計画を提供しました。

  1. フェーズ 1: パイロット
  2. フェーズ 2: 実行可能な最小製品
  3. フェーズ 3: 運用前
  4. フェーズ 4: 運用

フェーズ 1: パイロット

このフェーズでは、Microsoft Purview を作成し、少数のユーザーセット用に構成する必要があります。 通常は、エンド ツー エンドのシナリオを実行するために共同作業を行う 2 人から 3 人のグループにすぎません。 これらは、organizationで Microsoft Purview の支持者と見なされます。 このフェーズのメイン目標は、主要な機能を満たし、適切な利害関係者がプロジェクトを認識できるようにすることです。

完了するタスク

タスク 詳細 期間
要件に関する同意を収集 & する すべての利害関係者と話し合い、要件の完全なセットを収集します。 プロジェクトの各フェーズで完了する要件のサブセットに同意するには、異なるペルソナが参加する必要があります。 1 週間
Microsoft Purview ガバナンス ポータルの移動 ホーム ページから Microsoft Purview を使用する方法について説明します。 1 日
系列の ADF を構成する 主要なパイプラインとデータ資産を特定します。 内部 ADF アカウントに接続するために必要なすべての情報を収集します。 1 日
Azure Data Lake Storage Gen2や SQL サーバーなどのデータ ソースをスキャンします。 データ ソースを追加し、スキャンを設定します。 スキャンによってすべての資産が正常に検出されていることを確認します。 2 日間
検索 と 参照 エンド ユーザーが Microsoft Purview にアクセスし、エンド ツー エンドの検索と参照のシナリオを実行できるようにします。 1 日

受け入れ条件

  • Microsoft Purview アカウントは、organization テナントorganizationサブスクリプションで正常に作成されます。
  • 複数のロールを持つ少数のユーザー グループは、Microsoft Purview にアクセスできます。
  • Microsoft Purview は、少なくとも 1 つのデータ ソースをスキャンするように構成されています。
  • ユーザーは、次のような Microsoft Purview のキー値を抽出できる必要があります。
    • 検索と参照
    • 系統
  • ユーザーは、資産ページで資産の所有権を割り当てることができる必要があります。
  • 主要な利害関係者への認識を高めるためのプレゼンテーションとデモ。
  • MVP フェーズのリソースを増やすために、管理から購入します。

フェーズ 2: 実行可能な最小製品

Microsoft Purview をオンボードするための合意された要件と参加したビジネス ユニットが得られたら、次の手順は、最小実行可能製品 (MVP) リリースに取り組みます。 このフェーズでは、Microsoft Purview の使用量を、水平方向と垂直方向により多くのニーズを持つより多くのユーザーに拡張します。 用語集の用語、検索、参照など、すべてのユーザーに対して水平方向に満たす必要がある重要なシナリオがあります。 また、Azure Data Lake Storageから DW から Power BI への系列など、特定のエンド ツー エンドのシナリオをカバーするために、各ビジネス ユニットまたはグループに対して垂直方向に詳細な要件Azure Synapse必要があります。

完了するタスク

タスク 詳細 期間
Azure Synapse Analytics をスキャンする データベース ソースのオンボードを開始し、それらをスキャンして主要な資産を設定します 2日間
カスタム分類とルールを作成する 資産がスキャンされると、ユーザーは、Microsoft Purview の既定の分類以外に、より多くの分類を行う他のユース ケースがあることに気付く場合があります。 2-4 週間
Power BI のスキャン organizationが Power BI を使用している場合は、Power BI をスキャンして、データ サイエンティストまたはデータ アナリストが使用するすべてのデータ資産を収集できます。ストレージ レイヤーから系列を含める必要があります。 1-2 週間
用語集の用語をインポートする ほとんどの場合、organizationは用語集の用語のコレクションと資産への用語の割り当てを既に開発している可能性があります。 これには、.csv ファイル経由で Microsoft Purview へのインポート プロセスが必要になります。 1 週間
資産に連絡先を追加する 上位の資産の場合は、他のペルソナが連絡先を割り当てるか、REST API 経由でインポートできるようにするプロセスを確立できます。 1 週間
機密性の高いラベルを追加してスキャンする これは、Microsoft 365 からのラベル付けの使用に応じて、一部の組織では省略可能な場合があります。 1-2 週間
分類と機密性の高い分析情報を取得する Microsoft Purview のレポートと分析情報については、この機能にアクセスしてさまざまなレポートを取得し、管理にプレゼンテーションを提供できます。 1 日
Microsoft Purview マネージド ユーザーを使用して、より多くのユーザーをオンボードする この手順では、Microsoft Purview 管理が Azure Active Directory 管理と連携して、Microsoft Purview へのアクセスを許可する新しいセキュリティ グループを確立する必要があります。 1 週間

受け入れ条件

  • 大規模なユーザー グループを Microsoft Purview に正常にオンボードしました (50 以降)
  • ビジネス クリティカルなデータ ソースをスキャンする
  • すべての重要な用語集用語をインポートして割り当てる
  • 重要な資産の重要なラベル付けを正常にテストする
  • 参加しているビジネス ユニットのユーザーの最小シナリオを正常に満たす

フェーズ 3: 運用前

MVP フェーズが終了したら、実稼働前マイルストーンを計画します。 SQL Serverなど、オンプレミスのデータ ソースでのスキャンを含めることができます。 Microsoft Purview でサポートされていないデータ ソースにギャップがある場合は、Atlas API を調べて他のオプションを理解する必要があります。

完了するタスク

タスク 詳細 期間
スキャン ルール セットを使用してスキャンを絞り込む organizationには、運用前のデータ ソースが多数含まれます。 分類とファイル拡張子を一貫して全面的に適用できるように、スキャンの主要な基準を事前に定義することが重要です。 1 日から 2 日
ソース ページを確認して、各ソースのスキャンのリージョンの可用性を評価する データ ソースのリージョンと、コンプライアンスとセキュリティに関する組織の要件に応じて、スキャンに使用できるリージョンを検討する必要がある場合があります。 1 日
スキャン時のファイアウォールの概念を理解する この手順では、organizationがファイアウォールを構成する方法と、スキャン用のデータ ソースにアクセスするために Microsoft Purview が自身を認証する方法を確認する必要があります。 1 日
スキャン時Private Link概念を理解する organizationでPrivate Linkを使用する場合は、要件の一部としてPrivate Linkを含めるために、ネットワーク セキュリティの基盤をレイアウトする必要があります。 1 日
オンプレミスのSQL Serverをスキャンする これは、オンプレミスのSQL Serverがある場合は省略可能です。 スキャンでは、セルフホステッド Integration Runtimeを設定し、データ ソースとしてSQL Serverを追加する必要があります。 1-2 週間
統合シナリオで Microsoft Purview REST API を使用する Microsoft Purview をオーケストレーションやチケット作成システムなどの他のサード パーティのテクノロジと統合するための要件がある場合は、REST API 領域を調べることができます。 1 から 4 週間
Microsoft Purview の価格について この手順では、意思決定を行うためにorganization重要な財務情報を提供します。 1 日から 5 日

受け入れ条件

  • すべてのユーザーに少なくとも 1 つの部署を正常にオンボードする
  • SQL Serverなどのオンプレミス データ ソースをスキャンする
  • REST API を使用した少なくとも 1 つの統合シナリオ
  • 運用環境に移行する計画を完了します。これには、インフラストラクチャとセキュリティに関する重要な領域が含まれている必要があります

フェーズ 4: 運用

上記のフェーズに従って、効果的なデータ ライフサイクル管理を作成する必要があります。これは、ガバナンス プログラムを改善するための基礎です。 データ ガバナンスは、AI、Hadoop、IoT、ブロックチェーンなどの成長傾向に備えるorganizationに役立ちます。 データと分析の多くが始まりに過ぎず、さらに詳しく説明できます。 このソリューションの結果は、次のようになります。

  • ビジネスに重点を置く - 技術的な要件に対するビジネス要件とシナリオに合わせたソリューション。
  • Future Ready - ソリューションはプラットフォームの既定の機能を最大化し、プラットフォームの進歩/進化をサポートするために、構成またはスクリプトアクティビティに標準化された業界プラクティスを使用します。

完了するタスク

タスク 詳細 期間
ファイアウォールが有効になっている運用データ ソースをスキャンする ファイアウォールが配置されているときにこれが省略可能な場合は、インフラストラクチャを強化するためのオプションを調べる必要があります。 1 日から 5 日
Private Linkを有効にする Private Linkが使用されている場合、これは省略可能です。 それ以外の場合は、プライベートが有効になっているときに必須の条件であるため、これをスキップできます。 1 日から 5 日
自動化されたワークフローを作成する ワークフローは、承認、エスカレーション、レビュー、問題管理などのプロセスを自動化するために重要です。 2-3 週間
操作に関するドキュメントを作成する データ ガバナンスは、1 回限りのプロジェクトではありません。 これは、データ駆動型の意思決定を促進し、ビジネスの機会を生み出す継続的なプログラムです。 重要な手順とビジネス標準を文書化することが重要です。 1 週間

受け入れ条件

  • すべての部署とそのユーザーを正常にオンボードする
  • 運用環境のインフラストラクチャとセキュリティの要件を正常に満たす
  • ユーザーが必要とするすべてのユース ケースを正常に満たす

プラットフォームのセキュリティ強化

より多くの強化手順を実行できます。

  • ファイアウォール リソースでスキャンを有効にするか、Private Linkを使用してセキュリティ体制を強化する
  • スキャンのパフォーマンスを向上させるためにスコープ スキャンを微調整する
  • REST API を使用して 、バックアップと回復の重要なメタデータとプロパティをエクスポートする
  • ワークフローを使用して チケットとイベントを自動化し、人的エラーを回避する
  • ポリシーを使用して、 Microsoft Purview ガバナンス ポータルを使用してデータ資産へのアクセスを管理します。

ライフサイクルに関する考慮事項

生産プロセスに含めるもう 1 つの重要な側面は、分類とラベルを移行する方法です。 Microsoft Purview には、90 を超えるシステム分類子があります。 ファイル、テーブル、または列の資産にシステム分類またはカスタム分類を適用できます。 分類はサブジェクト タグに似ていますが、スキャン中にデータ資産内で見つかった特定の種類のコンテンツをマークして識別するために使用されます。 秘密度ラベルは、組織のデータ内の分類タイプのカテゴリを識別し、各カテゴリに適用するポリシーをグループ化するために使用されます。 Microsoft 365 と同じ機密情報の種類を使用するため、コンテンツとデータ資産全体にわたって既存のセキュリティ ポリシーと保護を拡張できます。 ドキュメントをスキャンして自動的に分類できます。 たとえば、multiple.docx という名前のファイルがあり、そのコンテンツに国民 ID 番号がある場合、Microsoft Purview は [資産の詳細] ページに EU 国民識別番号などの分類を追加します。

Microsoft Purview データ マップには、カタログ管理者がライフサイクルの一貫性とメンテナンスのベスト プラクティスを確保する必要がある領域がいくつかあります。

  • データ資産 – データ ソースは、環境間で再スキャンする必要があります。 開発中にのみスキャンし、運用環境の API を使用して再生成することはお勧めしません。 メイン理由は、Microsoft Purview スキャナーがデータ資産の背後でより多くの "配線" を行うことです。これは、別の Microsoft Purview インスタンスに移動するのが複雑になる可能性があります。 運用環境に同じデータ ソースを追加し、ソースをもう一度スキャンする方がはるかに簡単です。 一般的なベスト プラクティスは、使用されているすべてのスキャン、接続、認証メカニズムのドキュメントを用意することです。
  • スキャン ルール セット – これは、検出するファイルの種類や分類など、特定のスキャンに割り当てられたルールのコレクションです。 スキャン ルール セットがあまりない場合は、運用環境から手動で再作成できます。 これには、内部プロセスと適切なドキュメントが必要です。 ただし、ルール セットが日単位または週単位で変更される場合は、REST API ルートを調くことで対処できます。
  • カスタム分類 – 分類が定期的に変更されない場合もあります。 デプロイの初期段階では、カスタム分類を考え出すためにさまざまな要件を理解するのに時間がかかる場合があります。 ただし、一度解決すると、これはほとんど変更を必要とします。 そのため、ここでは、カスタム分類を REST API 経由で手動で移行するか、REST API を使用することをお勧めします。
  • 用語集 – UX を使用して用語集の用語をエクスポートおよびインポートできます。 自動化シナリオでは、REST API を使用することもできます。
  • リソース セット パターン ポリシー – この機能は、一般的な組織が適用するために高度です。 場合によっては、Azure Data Lake Storageにフォルダーの名前付け規則と特定の構造があり、Microsoft Purview がリソース セットを生成する際に問題が発生する可能性があります。 また、ビジネス ユニットでは、ビジネス ニーズに合わせてカスタマイズを増やしてリソース セットの構築を変更することもできます。 このシナリオでは、REST API を介してすべての変更を追跡し、外部バージョン管理プラットフォームを通じて変更を文書化することをお勧めします。
  • ロールの割り当て – これは、Microsoft Purview にアクセスできるユーザーと、ユーザーが持つアクセス許可を制御する場所です。 Microsoft Purview には、ユーザーとロールのエクスポートとインポートをサポートする REST API も用意されていますが、これは Atlas API と互換性がありません。 Azure セキュリティ グループを割り当て、代わりにグループ メンバーシップを管理することをお勧めします。

テナントの移動

テナントの移動は現在、Microsoft Purview ではサポートされていません。

次の手順