Microsoft Purviewで実現する包括的データガバナンス戦略

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Microsoft Purviewで実現する包括的データガバナンス戦略

アーキテクチャ

Microsoft Purviewは、オンプレミス、マルチクラウド、SaaSにおけるデータ資産全体を可視化し、管理するための統合データガバナンスソリューションです。その中心にあるのは、メタデータを自動的に収集、分類、カタログ化するPurview Data Mapです。このデータマップを基盤として、以下の主要コンポーネントが連携します。

  • Purview Data Map: データ資産のメタデータ、リネージ、分類を一元管理する基盤。自動スキャンにより多様なデータソースから情報を取得します。

  • Purview Data Catalog: データマップに格納されたメタデータを検索、発見、理解するためのユーザーインターフェース。ビジネス用語集やカスタム分類を提供します。

  • Purview Data Estate Insights: データマップの情報を分析し、データ資産の現状、感度、ガバナンスギャップを可視化するダッシュボード。

  • Purview Data Policy: Azure、SaaS、オンプレミスのデータソースに対して、アクセス制御やデータ利用ポリシーを適用するための機能。

  • Purview Data Sharing: 組織内外でのセキュアなデータ共有を可能にする機能。

  • Purview Workflows: データガバナンスに関連するプロセス（データ変更申請、承認など）を自動化するワークフロー機能。

これらのコンポーネントが連携することで、データの検出から、分類、アクセス制御、運用、コンプライアンス遵守まで、包括的なデータガバナンスライフサイクルをサポートします。

flowchart TD
    A["データソース"]|メタデータ/リネージ取得|-->B("Purview スキャナー")
    B|データマップへ格納|-->C{"Purview Data Map"}
    C-->D["Purview Data Catalog"]|検索/発見/キュレーション|
    C-->E["Purview Data Estate Insights"]|分析/可視化/レポーティング|
    C-->F["Purview Data Policy"]|ガバナンスルール適用|
    D-->G["データ利用者"]|データ利用|
    E-->H["データガバナンス管理者"]|ガバナンス状態監視|
    F-->A|ポリシー適用/アクセス制御|
    H-->F|ポリシー作成/調整|

設定手順

Microsoft Purviewアカウントのデプロイからデータソースのスキャン、基本的な設定までをAzure CLIを例に示します。

1. Purviewアカウントのデプロイ

# 変数の設定

RESOURCE_GROUP_NAME="rg-purview-governance"
PURVIEW_ACCOUNT_NAME="pv-corp-prod-001"
LOCATION="japaneast"

# リソースグループの作成

az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Purviewアカウントの作成

az purview account create \
  --name $PURVIEW_ACCOUNT_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --location $LOCATION \
  --identity-type SystemAssigned \
  --public-network-access Enabled # 必要に応じてDisabled/PrivateEndpoint接続

2. データソース（例: Azure Data Lake Storage Gen2）の登録とスキャン

Purviewアカウントが作成されたら、データソースを登録し、メタデータをスキャンします。ここではCLIでADLS Gen2を登録する例を示しますが、スキャン自体の詳細設定は通常Purviewガバナンスポータルで行います。

# Azure Data Lake Storage Gen2アカウントの情報を取得（事前に作成されているものとする）

ADLS_ACCOUNT_NAME="adlsgen2corporate"
ADLS_ID=$(az storage account show --name $ADLS_ACCOUNT_NAME --query id --output tsv)

# Purviewの管理対象IDにデータソースへのReader権限を付与 (スキャンのため)


# PurviewアカウントのManaged Identity IDを取得

PURVIEW_MSI_ID=$(az purview account show --name $PURVIEW_ACCOUNT_NAME --resource-group $RESOURCE_GROUP_NAME --query identity.principalId --output tsv)

# ADLS Gen2に対するストレージBlobデータ閲覧者ロールの割り当て

az role assignment create \
  --assignee $PURVIEW_MSI_ID \
  --role "Storage Blob Data Reader" \
  --scope $ADLS_ID

# データソースの登録 (CLIで直接スキャンをトリガーする機能は限定的、基本はポータルで設定)


# CLI/SDKでのデータソース登録は、特定の接続情報や資格情報を要するため、


# ここでは概念的な登録を示し、スキャンはPurviewポータルから行うのが一般的です。


# 例: az purview data-source create ... (具体的なCLIコマンドは複雑なため、ポータル推奨)

echo "データソースの登録とスキャン設定は、Purviewガバナンスポータル (https://web.purview.azure.com/) から行ってください。"
echo "登録するデータソース: $ADLS_ACCOUNT_NAME"

3. カスタム分類と用語集の定義

Purviewガバナンスポータル (https://web.purview.azure.com/) を使用して、ビジネス用語集 (Glossary) やカスタム分類 (Custom Classifications) を定義し、特定のデータに適用することで、より精度の高いガバナンスを実現します。これにより、「個人情報」や「機密データ」などのビジネスコンテキストに応じたタグ付けが可能になります。

運用監視

可観測性

Microsoft Purviewの運用状況はAzure Monitorを通じて監視できます。

  • 診断設定: Purviewアカウントから監査ログ、スキャンログ、メトリクスをAzure Monitor Logs (Log Analytics Workspace) やAzure Storage、Event Hubsに転送することで、詳細な分析やアラート設定が可能です。

  • Purview Data Estate Insights: スキャン状況、分類されたデータの概要、データリネージ、所有者情報など、ガバナンスの状態をグラフィカルに可視化します。

ログ

Log Analytics Workspaceに転送されたPurviewのログ（AzureDiagnosticsテーブル）はKQL (Kusto Query Language) を使用してクエリ可能です。

# Purviewのスキャンログを検索する例

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.PURVIEW"
| where Category == "ScanLogs"
| project TimeGenerated, OperationName, ResultType, Properties_s
| order by TimeGenerated desc

# Purviewの監査ログを検索する例 (Purviewポータルでの操作ログなど)

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.PURVIEW"
| where Category == "Audit"
| project TimeGenerated, OperationName, Identity_s, Properties_s
| order by TimeGenerated desc

SLA/バックアップ/DR

  • SLA: Microsoft PurviewのSLAは、通常99.9%の可用性が提供されます。詳細なSLAは公式ドキュメントを参照してください。

  • バックアップ/DR: Purviewアカウント自体はAzureのマネージドサービスであり、Microsoftがバックアップとディザスタリカバリを管理します。ユーザーがデータマップを直接バックアップする機能は提供されていません。重要な設定（カスタム分類、用語集、スキャンルールなど）は、可能な限りIaC（Infrastructure as Code）として管理し、Gitなどのバージョン管理システムで管理することを推奨します。

コスト最適化

Purviewのコストは主にData Map Unit (DMU) とスキャン時間によって決まります。

  • DMU: メタデータ取り込み、保存、検索のコア機能を提供します。利用状況に応じて適切なDMU数（通常は1DMUから）を選択し、大規模環境ではPurview Data Map Unitのリザーブドキャパシティ (Reserved Capacity) を購入することで、最大35%のコスト削減が可能です。

  • スキャン頻度: 全てのデータソースを頻繁にスキャンする必要はありません。データの変更頻度に応じてスキャン頻度を調整し、必要な情報のみをスキャン対象とすることでコストを最適化できます。

  • データソースの選定: ガバナンス対象外のデータソースはスキャン対象から除外することで、不要なスキャンコストを削減します。

セキュリティ

アイデンティティと権限境界

  • Azure Entra ID (旧 Azure AD): Purviewへのアクセス制御の基盤となります。ユーザー、グループ、サービスプリンシパルがPurviewリソースにアクセスするために認証されます。

  • ロールベースアクセス制御 (RBAC): Purviewには、きめ細かいアクセス制御のための組み込みロールが用意されています。

    • Purview Data Reader: メタデータの読み取りのみ可能。

    • Purview Data Curator: メタデータの読み書き、カスタム分類や用語集の管理が可能。

    • Purview Data Source Administrator: データソースの登録とスキャン管理が可能。

    • Purview Collection Admin: コレクションの作成と管理が可能。

    • Purview Policy Author: データポリシーの作成と管理が可能。 これらのロールをEntra IDのセキュリティグループに割り当て、最小権限の原則を適用します。

  • マネージドID (Managed Identities): PurviewスキャナーがAzureデータソース（Storage Account, SQL Databaseなど）に安全にアクセスするために利用されます。スキャナーにシステム割り当てマネージドIDを付与し、データソースに対する適切なロール（例: 「ストレージBlobデータ閲覧者」）を割り当てることで、資格情報の管理が不要になります。

  • 条件付きアクセス (Conditional Access: CA): Purviewガバナンスポータルへのアクセスに対し、多要素認証 (MFA) の強制、信頼済みデバイスからのアクセス制限、特定IPアドレスからのアクセス制限などを適用することで、セキュリティを強化します。

  • Microsoft Defender for Cloud: Purviewアカウントに関連する異常なアクセスパターンや脅威を検出し、セキュリティ体制を強化します。

ネットワークセキュリティ

  • プライベートエンドポイント (Private Endpoints): Purviewガバナンスポータル、スキャナー、およびデータソースへの接続を、Azure Private Linkを介してプライベートなVNet内で行うことができます。これにより、データはパブリックインターネットを経由せず、セキュリティが向上します。

  • サービスエンドポイント: 特定のAzureサービスへのアクセスをVNetから直接行うことができ、データ流出のリスクを低減します。

データ暗号化

Purviewに保存されるすべてのデータ（メタデータ、分類結果など）は、保存時および転送時に暗号化されます。保存時にはMicrosoftマネージドキーによる暗号化がデフォルトで有効であり、顧客はカスタマーマネージドキー (CMK/BYOK) を利用して、Purviewに保存されるデータを自身のAzure Key Vaultのキーで暗号化することも可能です。

コスト

Microsoft Purviewのコストは、主に以下のコンポーネントに基づきます。

  • Purview Data Map Unit (DMU): Purviewのコア機能を提供する単位で、メタデータの保存、検索、アクセスに使用されます。最小1 DMUから始まり、大規模なデータ資産や高頻度なアクセス要件には複数のDMUが必要です。DMUは時間単位で課金されます。

  • スキャン時間: データソースをスキャンしてメタデータを抽出するのにかかった時間に基づいて課金されます。

  • Purviewワークフロー、データ共有、データポリシー: これらの機能には、それぞれ独自の課金モデルが適用される場合があります。

コスト最適化のポイント:

  • DMUのサイジング: 初期は最小DMUで開始し、データ資産の増加や利用状況に応じて段階的に拡張することを検討します。

  • リザーブドキャパシティ: 安定した大規模なデータマップ利用が予測される場合は、1年または3年のリザーブドキャパシティを購入することで、従量課金よりも大幅な割引が適用されます。

  • スキャン頻度と範囲の最適化: データの変更頻度や重要性に基づいてスキャン頻度を調整し、変更のないデータソースの不必要なスキャンを避けます。また、必要なデータセットのみをスキャン対象とします。

落とし穴

  1. データソースの網羅性不足: Purviewを導入しても、全ての関連データソースがスキャン対象になっていないと、ガバナンスの盲点が生じます。初期段階でデータ資産全体を正確に把握することが重要です。

  2. カスタム分類/用語集の不統一: 組織内で共通のビジネス用語や分類が定義されていないと、Purview上のメタデータが inconsistent になり、データの発見性や理解度が低下します。ガバナンス担当者間の連携が不可欠です。

  3. 権限管理の複雑化: きめ細かいロール設計はセキュリティを強化しますが、過度に複雑にすると運用が困難になります。シンプルかつ効率的なRBACモデルを設計し、定期的に見直す必要があります。

  4. スキャンコストの考慮不足: 大規模なデータセットや高頻度なスキャンは、予期せぬ高額なコストにつながる可能性があります。スキャンポリシーの設計とコストシミュレーションを事前に行うべきです。

  5. 既存のガバナンスフレームワークとの統合: Purviewは強力なツールですが、既存の組織プロセスやポリシーとの連携が不十分だと、導入効果が半減します。技術導入だけでなく、組織横断的なプロセス変更も視野に入れる必要があります。

  6. Purview Data Mapの復元性: Purviewアカウント自体はDRに対応していますが、Data Map内のカスタムなメタデータや分類はユーザー側で直接バックアップ・復元する機能がありません。重要な設定はIaCで管理し、バージョン管理することが望ましいです。

まとめ

Microsoft Purviewは、現代の複雑なデータ環境において不可欠なデータガバナンスを実現するための包括的なプラットフォームです。Purview Data Mapを核として、データの検出、分類、カタログ化、ガバナンスルールの適用、さらにはセキュリティとコスト管理までを一元的に行うことができます。アーキテクチャの理解、適切な設定、堅牢なセキュリティ対策、そして継続的な運用監視とコスト最適化の取り組みを通じて、企業はデータ資産の価値を最大限に引き出し、コンプライアンス要件を満たしながらビジネス成長を加速させることが可能になります。導入においては、技術的な側面だけでなく、組織内のデータ文化やガバナンス体制の整備も同時に推進することが成功の鍵となります。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました