Microsoft Purview Data Mapでスキャンを安定運用するには、データソースごとの接続情報を場当たり的に入力するのではなく、Azure Key Vaultと資格情報オブジェクトを使って再利用できる形で管理することが重要です。特に、SQL認証、サービスプリンシパル、アカウントキー、Basic認証などを使うスキャンでは、シークレットの保管場所、Key Vaultのアクセス許可、ネットワーク制限、スキャン設定のひも付けを事前に確認しておかないと、認証エラーやスキャン停止につながります。
結論から言うと、Microsoft Purview Data Mapのスキャン資格情報は、可能な限りマネージドIDを優先し、シークレットが必要な認証方式ではAzure Key Vaultに保管したうえでPurviewから参照させるのが基本です。公式ドキュメントでも、資格情報は登録済みの認証情報をデータソーススキャンに再利用するための仕組みとして説明されています。(Microsoft Learn)
Microsoft Purview Data Mapのスキャン資格情報とは
Microsoft Purview Data Mapのスキャン資格情報とは、登録済みデータソースに対してMicrosoft Purviewが認証するための情報です。たとえば、Azure SQL Databaseをスキャンする場合のSQL認証、外部システムに接続するためのサービスプリンシパル、ストレージアカウントのアカウントキーなどが該当します。
ただし、Purviewの資格情報オブジェクトにパスワードやキーを直接ベタ書きする考え方ではありません。センシティブな値はAzure Key Vaultのシークレットとして管理し、Microsoft Purview側ではそのKey Vault接続とシークレットを参照してスキャンに利用します。公式手順でも、資格情報の作成前にAzure Key Vaultを用意し、既存のKey Vaultシークレットを使って機密性の高い認証情報を取得する流れが示されています。(Microsoft Learn)
スキャン資格情報でよく使われる認証方式は、次のとおりです。
| 認証方式 | 主な用途 | 管理上のポイント |
|---|---|---|
| Microsoft Purviewのシステム割り当てマネージドID | Azure Blob Storage、ADLS Gen2、Azure SQL Databaseなど | 対応データソースでは優先候補。Key Vaultに資格情報を保存せずに済む場合がある |
| ユーザー割り当てマネージドID | 特定のIDを複数リソースや運用単位で使い分けたい場合 | 公式情報ではプレビュー扱いのため、対象データソースと運用ルールを確認する |
| サービスプリンシパル | アプリケーションIDで認証したい場合 | クライアントシークレットの期限、ローテーション、Key Vault権限の管理が必要 |
| SQL認証 | Azure SQL DatabaseやSQL系データソース | パスワード更新時にKey VaultシークレットとPurview資格情報の参照を確認する |
| Windows認証 / Basic認証 | オンプレミス系、レガシー系の接続 | Self-hosted integration runtimeやネットワーク経路もあわせて確認する |
| アカウントキー | ストレージ系の接続 | キーのローテーション時にスキャン停止が起きやすい |
| Role ARN | Amazon S3など | AWS側のロール、信頼関係、Purview側の設定をセットで確認する |
| Consumer Key | Salesforceなど | パスワードとコンシューマーシークレットの両方をKey Vaultで管理するケースがある |
2026年6月時点で管理者が確認すべき変更点と実務影響
今回の公式情報で実務上重要なのは、「新しい機能を有効化するかどうか」よりも、スキャン用の資格情報を安全に作成・保守できる状態になっているかを見直すことです。Microsoft Purview Data Mapは、データ検出、分類、メタデータ収集の入口になるため、認証設定の不備はデータガバナンス全体の鮮度に直結します。
| 確認ポイント | 影響を受ける範囲 | 管理者が取るべき対応 |
|---|---|---|
| 資格情報作成前にAzure Key Vault接続が必要 | SQL認証、サービスプリンシパル、アカウントキーなどを使うスキャン | Key Vaultの有無、接続先、命名規則、管理者を確認する |
| マネージドID利用時は資格情報作成が不要な場合がある | Azure系データソースのスキャン | まずマネージドIDで接続できないか確認する |
| 新しいMicrosoft Purviewポータルとクラシックポータルで導線が異なる | 管理手順書、運用マニュアル、教育資料 | 画面手順を最新ポータル前提で更新する |
| Key Vaultのネットワーク制限がスキャン認証に影響する | パブリックネットワークアクセスを無効化しているKey Vault | 信頼されたMicrosoftサービスまたはPrivate Endpointの設計を確認する |
| Key Vaultの権限モデルが2種類ある | Access Policy方式、Azure RBAC方式のKey Vault | Purviewのシステム割り当てマネージドIDに適切な権限を付与する |
| ユーザー割り当てマネージドIDはプレビュー扱い | UAMIでスキャンを設計する環境 | 本番展開前に対象データソース、制限、削除時の手順を確認する |
Microsoftのスキャン関連ドキュメントでも、可能な限りマネージドIDを利用することが推奨されています。マネージドIDを使うと、データソースごとの資格情報を個別に保存・管理する負担を減らせるためです。(Microsoft Learn)
影響範囲は「Purview管理者」だけではない
スキャン資格情報の管理は、Microsoft Purviewの管理画面だけで完結しません。Azure Key Vault、Microsoft Entra ID、Azure RBAC、ネットワーク、データソース側のアクセス許可が関係します。
| 担当者 | 確認すべきこと |
|---|---|
| Microsoft Purview管理者 | Data Mapのデータソース登録、資格情報、スキャン設定、コレクション権限 |
| Azure管理者 | Key Vault、RBAC、マネージドID、サブスクリプションやリソースグループのReader権限 |
| セキュリティ管理者 | シークレット管理、最小権限、ローテーション、監査ログ、ネットワーク制限 |
| データ基盤担当者 | スキャン対象の範囲、スキャン頻度、データソース側の読み取り権限 |
| 開発者 / DevOps担当者 | IaC、環境分離、シークレットのハードコード防止、CI/CDでの権限付与 |
特に見落とされやすいのは、Purview側で資格情報を作成できても、データソース側やKey Vault側の権限が不足しているケースです。トラブルシューティング手順でも、マネージドIDやサービスプリンシパルを使う場合は、それらのIDにデータソースへのアクセス許可を与える必要があるとされています。(Microsoft Learn)
まず決めるべきは「どの認証方式でスキャンするか」
スキャン資格情報の作成に入る前に、データソースごとに認証方式を決めます。ここを曖昧にしたまま作業すると、Key Vaultの準備、権限付与、ネットワーク設定が後戻りになりやすくなります。
判断基準はシンプルです。
| 判断基準 | 推奨される考え方 |
|---|---|
| Microsoft PurviewのマネージドIDで接続できるか | 対応しているなら最優先で検討する |
| シークレットを持つ必要があるか | 必要な場合のみKey Vaultシークレットとして管理する |
| データソースがAzure同一テナント内にあるか | AzureリソースはPurviewアカウントと同一テナントが基本。ただし個別ページの例外を確認する |
| ネットワークが閉域化されているか | Private Endpoint、Self-hosted integration runtime、Key Vaultファイアウォールをセットで設計する |
| ローテーション頻度が高いか | シークレット名、バージョン、更新手順を運用ルール化する |
| 本番・検証・開発で分離が必要か | 環境ごとにKey Vault、資格情報名、スキャン設定を分ける |
Microsoft Purview Data Mapでサポートされるデータソースや認証方式はデータソースごとに異なります。公式ドキュメントでも、スキャン作成前にデータソース、ネットワーク要件、利用する資格情報を確認する流れが示されています。(Microsoft Learn)
Azure Key Vault側で必ず確認する設定
スキャン資格情報の失敗原因として多いのが、Microsoft PurviewではなくAzure Key Vault側の設定不足です。次の3点は、資格情報を作成する前に確認しておきましょう。
Key Vaultのネットワーク制限
Key Vaultでパブリックネットワークアクセスを無効化している場合、Microsoft Purviewからシークレットを参照できる経路が必要です。公式手順では、Key Vault側で信頼されたMicrosoftサービスのバイパスを許可する方法、またはPrivate Endpointを使う方法が説明されています。(Microsoft Learn)
ただし、Private Endpointを使う場合も構成によって注意が必要です。公式情報では、Azure integration runtimeをマネージド仮想ネットワークで使う場合はPrivate Endpoint接続がサポートされ、Self-hosted integration runtimeを使う場合は信頼されたMicrosoftサービスを有効化する必要があるとされています。(Microsoft Learn)
実務では、次のように判断すると迷いにくくなります。
| 構成 | 確認ポイント |
|---|---|
| Key Vaultのパブリックアクセスを許可している | 最小権限と監査ログを確認する |
| Key Vaultのパブリックアクセスを無効化している | Purviewから到達できる例外設定またはPrivate Endpointを確認する |
| Self-hosted integration runtimeを使う | ランタイムのネットワーク経路だけでなく、Key Vaultの例外設定も確認する |
| Azure側の閉域構成を厳格にしている | DNS、Private Endpoint、ファイアウォール、RBACを一体で検証する |
Key Vaultの権限モデル
Azure Key Vaultには、主に「Vault access policy」と「Azure role-based access control」の2種類の権限モデルがあります。どちらのモデルを使っているかにより、Microsoft Purviewに付与する権限が変わります。
| Key Vaultの権限モデル | Purviewに必要な代表的な権限 |
|---|---|
| Vault access policy | SecretsのGet、List |
| Azure RBAC | Key Vault Secrets Userロール |
公式手順でも、Key Vaultの権限モデルを確認したうえで、Access Policy方式ならSecrets permissionsのGetとList、Azure RBAC方式ならKey Vault Secrets UserロールをMicrosoft Purviewアカウントに付与する流れが示されています。(Microsoft Learn)
ありがちなミスは、Key VaultがAzure RBAC方式なのにAccess Policyを追加しようとする、またはその逆です。画面上で権限を追加したつもりでも、実際の権限モデルと合っていないとPurviewからシークレットを取得できません。
シークレット名とバージョン
Key Vaultに保存するシークレットは、名前とバージョンを明確に管理します。スキャンが突然失敗する場合、パスワードやキーのローテーション後にPurview側が古いシークレットバージョンを参照していることがあります。
運用では、次の項目を台帳化しておくとトラブル対応が速くなります。
| 管理項目 | 記録例 |
|---|---|
| Purview資格情報名 | cred-prod-sql-sales-readonly |
| Key Vault名 | kv-prod-datagov-001 |
| シークレット名 | sql-sales-reader-password |
| 認証方式 | SQL Authentication |
| 利用スキャン | scan-prod-sales-weekly |
| 所有者 | データ基盤チーム |
| ローテーション頻度 | 90日ごと |
| 最終更新日 | 2026-06-02 |
| 影響確認方法 | 接続テスト、次回スキャン結果、監査ログ |
Microsoft Purviewで資格情報を作成する手順
Microsoft Purview Data Mapで資格情報を作成する流れは、次の順序で進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | データソースの認証方式を決める | マネージドIDで代替できないか確認する |
| 2 | Azure Key Vaultにシークレットを保存する | パスワード、キー、クライアントシークレットを正しい名前で登録する |
| 3 | PurviewのマネージドIDにKey Vault権限を付与する | Access Policy方式ならGet/List、Azure RBAC方式ならKey Vault Secrets User |
| 4 | PurviewにKey Vault接続を作成する | 対象Key VaultがPurviewから参照できるか確認する |
| 5 | Purviewで資格情報を作成する | 認証方式、Key Vault接続、シークレットを選択する |
| 6 | スキャン設定で資格情報を選択する | 接続テストを実行し、対象範囲とスケジュールを確認する |
| 7 | ローテーション手順を残す | 次回更新時に誰が何を変更するか明確にする |
新しいMicrosoft Purviewポータルでは、Data Mapを開き、Source managementからCredentialsに進みます。クラシックポータルでは、Management CenterからCredentialsへ移動します。公式手順では、資格情報を作成する前に、既存のAzure Key VaultインスタンスをMicrosoft Purviewアカウントに関連付ける必要があると説明されています。(Microsoft Learn)
マネージドIDを使う場合は資格情報を作らない選択もある
Microsoft Purviewのシステム割り当てマネージドIDを使ってスキャンを構成できる場合、Key Vault接続や資格情報オブジェクトの作成が不要になるケースがあります。公式情報でも、SAMIを使う場合は資格情報を作成してKey Vaultにリンクする必要がないと説明されています。(Microsoft Learn)
これはセキュリティ面でも運用面でも大きなメリットです。パスワードやキーを保管しないため、漏えいリスクやローテーション作業を減らせます。
ただし、マネージドIDを使えば自動的にアクセスできるわけではありません。データソース側で、PurviewのマネージドIDに読み取り権限を付与する必要があります。たとえばストレージであれば必要なデータ読み取り権限、SQL系であれば接続やメタデータ参照に必要な権限を確認します。
スキャン設定で確認すべき項目
資格情報を作成しただけでは、スキャンは実行されません。データソース登録、スキャン作成、資格情報の選択、接続テスト、スキャン範囲、ルールセット、スケジュールまで確認して初めて運用できます。
Microsoft Purview Data Mapのスキャン作成手順では、データソースを登録し、統合ランタイム構成を検討し、データソースへの接続に使う資格情報を確認する流れが示されています。スキャン作成時にはCredentialで認証方式を選択し、接続テストを実行します。(Microsoft Learn)
特に重要なのは、資格情報とスキャンルールセットは、登録したドメインに関連付いたものしか選択できない点です。公式手順でも、登録元ドメインに関連付いた資格情報とスキャンルールセットのみ選択できるとされています。(Microsoft Learn)
これにより、次のようなトラブルが起きます。
| 症状 | よくある原因 | 対応 |
|---|---|---|
| 作成した資格情報がスキャン画面に出てこない | データソースの登録ドメインと資格情報の関連範囲が合っていない | ドメイン、コレクション、登録先を確認する |
| 接続テストに失敗する | Key Vault権限、データソース権限、ネットワークのいずれかが不足 | Key Vault、RBAC、ファイアウォール、IRを順に確認する |
| 以前は成功していたスキャンが失敗する | シークレットやパスワードの変更、Key Vault設定変更 | シークレットのバージョンと参照先を確認する |
| 閉域環境のデータソースに接続できない | Private LinkやSelf-hosted integration runtimeの構成不足 | ネットワーク経路とランタイム更新状況を確認する |
ユーザー割り当てマネージドIDを使う場合の注意点
ユーザー割り当てマネージドIDは、システム割り当てマネージドIDと異なり、独立したAzureリソースとして作成されます。複数のスキャンやリソースでIDを使い分けたい場合に便利ですが、公式情報ではプレビューとして扱われているため、本番利用では対象データソースや制限を確認したうえで段階的に導入するのが安全です。(Microsoft Learn)
公式手順では、ユーザー割り当てマネージドIDの対象データソースとして、Azure Data Lake Gen1、Azure Data Lake Gen2、Azure SQL Database、Azure SQL Managed Instance、Azure SQL Dedicated SQL pools、Azure Blob Storageが挙げられています。(Microsoft Learn)
導入時は、次のように使い分けるとよいでしょう。
| 使い方 | 向いているケース |
|---|---|
| システム割り当てマネージドID | Purviewアカウント単位でシンプルに権限管理したい |
| ユーザー割り当てマネージドID | 本番・検証、部門、データドメインごとにIDを分けたい |
| サービスプリンシパル | 外部アプリや既存自動化との整合性が必要 |
| SQL認証などのシークレット方式 | マネージドIDに対応していない、または既存接続方式を維持する必要がある |
注意したいのは、ユーザー割り当てマネージドIDをAzureポータル側で削除しただけでは、Purview側の資格情報管理も整理が必要になる点です。公式情報では、Azureポータルでユーザー割り当てマネージドIDを削除した場合、Microsoft Purviewポータルで元のIDを削除し、新しく作成する必要があると説明されています。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Microsoft Purview Data Mapの資格情報管理では、初回構築よりも、移行・展開・ローテーション時のミスが問題になりやすくなります。
既存スキャンの認証方式を棚卸ししていない
まず、どのスキャンがどの資格情報を使っているかを一覧化します。資格情報名だけでは中身が分からないことが多いため、データソース名、環境、本番/検証、認証方式、Key Vault名、シークレット名をセットで管理します。
例として、次のような命名規則にすると運用しやすくなります。
| 種類 | 命名例 |
|---|---|
| Purview資格情報 | cred-prod-sql-sales-readonly |
| Key Vaultシークレット | sql-sales-reader-password |
| スキャン名 | scan-prod-sales-weekly |
| ユーザー割り当てマネージドID | uami-prod-purview-sales |
ポイントは、資格情報名に環境、データソース、用途を含めることです。credential1やtest-sqlのような名前は、半年後の運用でほぼ確実に混乱します。
シークレットをローテーションしてもPurview側の参照を確認していない
Key Vaultのシークレットを更新しても、Purviewの資格情報が期待どおり新しい値を参照しているかは確認が必要です。トラブルシューティング手順でも、スキャンが以前は成功していたのに失敗する場合、資格情報が変更またはローテーションされていないか確認するよう案内されています。(Microsoft Learn)
ローテーション後は、少なくとも次の3つを実施しましょう。
| 作業 | 理由 |
|---|---|
| Key Vaultで新しいシークレット値を確認する | 登録ミスや対象シークレットの取り違えを防ぐ |
| Purviewの資格情報設定を確認する | 古いシークレット名やバージョンを参照していないか確認する |
| 接続テストまたは手動スキャンを実行する | 次回定期スキャンまで失敗に気づけないリスクを減らす |
Key Vaultの権限はあるが、データソース側の権限がない
Key Vaultからパスワードを読めても、データソースに入れるとは限りません。Purviewがデータソースをスキャンするには、データソース側で必要な読み取り権限が必要です。
たとえば、サービスプリンシパルを使う場合は、そのサービスプリンシパルがKey Vaultにアクセスできるだけでは不十分です。スキャン対象のストレージ、SQL、SaaS、AWSリソースなどに対して、スキャンに必要な権限を持っている必要があります。
新旧ポータルの手順が混在している
公式手順では、新しいMicrosoft Purviewポータルとクラシックポータルの導線が併記されています。新しいポータルではData MapからSource management、Credentialsへ進み、クラシックポータルではManagement CenterからCredentialsへ進みます。(Microsoft Learn)
社内マニュアルに古い画面キャプチャが残っていると、担当者が正しい場所にたどり着けないことがあります。特に運用引き継ぎ資料では、ポータル名、メニュー名、対象環境を明記しておきましょう。
大量スキャン時のコストと容量を見落としている
資格情報の更新そのものは認証の話ですが、スキャンが再開・増加するとData Map側のメタデータ量や操作量にも影響します。Microsoft Purview Data Mapは、メタデータストレージと操作スループットを容量ユニットで扱い、既定では1容量ユニットから開始し、利用状況に応じてスケールします。(Microsoft Learn)
大量のデータソースを新しい資格情報で一斉にスキャンする場合は、次の点を確認します。
| 確認項目 | 理由 |
|---|---|
| スキャン対象範囲 | 不要なフォルダーやテーブルまでスキャンすると時間とコストが増える |
| スキャン頻度 | 毎日必要なデータと週次で十分なデータを分ける |
| スキャンルールセット | すべての分類を常に実行する必要があるか検討する |
| Data Map Capacity Units | メタデータ量や操作量の増加を監視する |
| 実行時間帯 | 業務時間帯やデータ更新処理との競合を避ける |
管理者向けチェックリスト
Microsoft Purview Data Mapの資格情報を見直す場合は、次の順で確認すると効率的です。
| チェック項目 | 確認内容 |
|---|---|
| 認証方式 | マネージドIDで代替できるスキャンがないか |
| Key Vault接続 | Purviewアカウントに正しいKey Vaultが関連付いているか |
| Key Vault権限 | PurviewのマネージドIDにSecretsのGet/ListまたはKey Vault Secrets Userが付与されているか |
| ネットワーク | Key Vaultやデータソースのファイアウォール、Private Endpoint、IR構成に矛盾がないか |
| データソース権限 | スキャンに使うIDがデータソース側で読み取り権限を持っているか |
| スキャン設定 | 資格情報、スキャン範囲、ルールセット、スケジュールが正しいか |
| ローテーション | パスワードやキーの更新時にPurview側の参照確認を行う手順があるか |
| 監査 | Key Vaultアクセス、スキャン失敗、権限変更を追跡できるか |
| 命名規則 | 資格情報名から環境、用途、対象データソースが分かるか |
| 削除手順 | 使っていない資格情報やKey Vault接続を削除する前に影響範囲を確認しているか |
開発者・DevOps担当者が意識すべき展開ポイント
開発者やDevOps担当者は、Microsoft Purviewの画面操作だけでなく、環境構築やCI/CDの観点で資格情報管理を整備する必要があります。
まず避けるべきなのは、スキャン用のパスワード、クライアントシークレット、アカウントキーをスクリプト、テンプレート、Gitリポジトリ、チケット本文に直接書くことです。シークレット値はKey Vaultに集約し、Purview側ではKey Vault参照を使う構成に寄せます。
展開時は、次のような順序で自動化すると失敗を減らせます。
| フェーズ | 自動化・標準化したい内容 |
|---|---|
| 環境作成 | Key Vault、Purviewアカウント、必要なマネージドIDの作成 |
| 権限付与 | Key Vault、データソース、サブスクリプション、リソースグループのRBAC設定 |
| シークレット登録 | 環境ごとのシークレット名、期限、所有者の登録 |
| Purview設定 | Key Vault接続、資格情報、データソース登録、スキャン設定 |
| 検証 | 接続テスト、手動スキャン、スキャン結果確認 |
| 運用 | ローテーション、不要資格情報の棚卸し、失敗アラート確認 |
本番・検証・開発を分ける場合は、Key VaultとPurview資格情報も分離するのが基本です。検証環境の資格情報で本番データソースをスキャンできる状態は、セキュリティレビューで問題になりやすい構成です。
まず実施すべき対応
Microsoft Purview Data Mapのスキャン資格情報について、最初にやるべきことは新機能の有効化ではありません。現在のスキャンが、どの認証方式で、どのKey Vaultシークレットを使い、どの権限で動いているかを把握することです。
次の順番で対応すると、短期間でリスクを下げられます。
- 既存スキャンと資格情報の一覧を作る
- マネージドIDに移行できるデータソースを洗い出す
- Key Vaultの権限モデルとPurviewへの権限付与を確認する
- Key Vaultのネットワーク制限とPrivate Endpoint構成を確認する
- ローテーション済み・期限切れ間近のシークレットを確認する
- 代表的なスキャンで接続テストを実行する
- 社内手順書を新しいMicrosoft Purviewポータルの導線に合わせて更新する
Microsoft Purview Data Mapは、データ資産を可視化し、分類し、ガバナンスにつなげるための土台です。スキャン資格情報の管理が不安定だと、カタログの情報が古くなり、データ利用者や管理者が誤った判断をしやすくなります。
まずは、よく使われている本番スキャンから、認証方式、Key Vault、権限、ローテーション手順を確認してください。可能なものはマネージドIDへ寄せ、シークレットが必要なものはKey VaultとPurview資格情報の対応関係を明確にしておくことが、安定したMicrosoft Purview運用の第一歩です。
コメント