Microsoft PurviewでAzure SQL Databaseを検出・管理する際の結論は、単に「スキャンを有効化する」だけでは足りません。管理者は、Data Mapへの登録、認証方式、ファイアウォールまたはIntegration Runtime、スキャン範囲、アクセス ポリシー、リネージ抽出の制約をセットで確認する必要があります。
本稿では、2026年6月2日付の確認対象として指定されたMicrosoft Learnの公式情報をもとに、Azure SQL DatabaseをMicrosoft Purviewに登録し、認証し、スキャンして統制する際の変更点・影響範囲・展開時の注意点を整理します。なお、指定ソースのMicrosoft Learnページ上では、確認時点で最終更新日が2025年10月13日と表示されています。公開日や更新日だけで判断せず、対象URL、テナントの画面差分、リージョン対応をあわせて確認してください。(Microsoft Learn)
Microsoft PurviewでAzure SQL Databaseを管理する目的
Microsoft PurviewにAzure SQL Databaseを登録すると、データベース内のメタデータを検出し、分類、秘密度ラベル、アクセス ポリシー、リネージ確認などのデータガバナンス施策につなげられます。
公式情報では、Azure SQL DatabaseソースをMicrosoft Purviewに登録し、SQL Databaseに対して認証・操作する手順が説明されています。つまり今回のポイントは、単なる接続手順ではなく、「Azure SQL Databaseを組織のデータカタログと統制対象に入れるための運用設計」です。(Microsoft Learn)
特に次のような環境では、早めに確認する価値があります。
| 対象環境 | 確認すべき理由 |
|---|---|
| 本番のAzure SQL Databaseを複数チームで利用している | 誰がどのデータにアクセスできるかをPurview側で整理しやすくなる |
| 個人情報、顧客情報、財務データを含むDBがある | 分類や秘密度ラベル、保護ポリシーの対象になり得る |
| ストアドプロシージャやビューでデータ加工している | リネージ抽出の対応範囲と制約を事前に確認する必要がある |
| プライベートエンドポイントや閉域ネットワークを使っている | スキャン方式やリネージ抽出に制限が出やすい |
| Azure SQL Databaseの移行やリソース移動を予定している | PurviewポリシーがARMパスに依存するため、再登録が必要になる場合がある |
今回確認すべき変更点と影響範囲
Microsoft PurviewのAzure SQL Database対応では、スキャン対象としてサーバー、データベース、スキーマ、テーブル、ビュー、列に加え、リネージ抽出を有効にした場合のストアドプロシージャやストアドプロシージャ実行情報も扱えます。スキャン機能としては、メタデータ抽出、フルスキャン、増分スキャン、スコープ指定スキャンがサポート対象です。(Microsoft Learn)
また、Microsoft Purview Data Mapの対応表では、Azure SQL Databaseについて自動分類、秘密度ラベル、ポリシー、リネージ、ライブビューがサポート対象として示されています。リネージはプレビュー扱いのため、本番利用では「取得できる前提」ではなく「対象パターンで検証してから使う」姿勢が重要です。(Microsoft Learn)
管理者や開発者への主な影響は、次の3点です。
| 影響範囲 | 内容 | 実務上の対応 |
|---|---|---|
| 管理者 | Purviewのロール、Azure RBAC、SQL Database側の権限設定が必要 | Data Source Administrator、Data Reader、Reader、db_datareaderなどを棚卸しする |
| セキュリティ担当 | アクセス ポリシー、保護ポリシー、秘密度ラベルの設計に関係する | リージョン、ロール分離、削除防止ロックを確認する |
| 開発者・DBA | ビューやストアドプロシージャのリネージ取得範囲に影響する | 対象SQL、実行タイミング、サポート外の構文を事前に確認する |
事前に確認すべき前提条件
Azure SQL DatabaseをMicrosoft Purviewに登録・スキャンするには、Azureの有効なサブスクリプション、Microsoft Purviewアカウント、Purviewガバナンスポータルでソースを登録・管理するためのData Source AdministratorとData Reader権限が必要です。(Microsoft Learn)
ここで見落としやすいのは、「Azure側の権限」と「Microsoft Purview側の権限」は別物だという点です。AzureポータルでSQL Databaseを操作できても、Purviewのコレクションに対して登録権限がなければソース管理は進みません。逆にPurview側の権限があっても、SQL Database側で認証や読み取り権限が不足していればスキャンに失敗します。
登録前チェックリスト
| 確認項目 | 判断基準 |
|---|---|
| Microsoft Purviewアカウント | 対象テナント内で利用可能か |
| コレクション設計 | 部門別、システム別、機密度別のどこに登録するか |
| Azure SQL Database | 対象サーバー、DB名、サブスクリプションを特定済みか |
| ネットワーク | パブリック接続、Self-hosted Integration Runtime、Managed VNETのどれを使うか |
| 認証方式 | マネージドID、サービスプリンシパル、SQL認証のどれを使うか |
| Key Vault | SQL認証やサービスプリンシパルのシークレット管理に使うか |
| 運用責任者 | スキャン失敗時にAzure側、SQL側、Purview側の誰が対応するか |
Azure SQL DatabaseをMicrosoft Purviewに登録する流れ
登録作業は、Microsoft PurviewガバナンスポータルのData Mapから行います。大まかな流れは、コレクション階層を作成し、対象コレクション配下でAzure SQL Databaseをデータソースとして登録し、サブスクリプション、サーバー名、コレクションを指定するというものです。(Microsoft Learn)
実務では、登録名の付け方が後々の運用に効きます。たとえば「sql-prod-001」のような技術名だけでは、データ利用者が何のデータか判断しづらくなります。おすすめは、環境、業務領域、用途が分かる命名です。
| 命名例 | 向いているケース |
|---|---|
prod-sales-sqldb | 本番の営業系データベース |
dev-customer-sqldb | 開発環境の顧客データベース |
prod-finance-ledger-sqldb | 会計・台帳系の重要データベース |
登録時点では「見つけやすさ」だけでなく、「誰に管理権限を渡すか」も決めておくべきです。コレクション設計が曖昧なまま登録すると、後から権限継承やポリシー管理が複雑になります。
ネットワーク設定で失敗しやすいポイント
Azure SQL Database側でファイアウォールが有効な場合、Microsoft Purviewから接続できるようにネットワーク設定を調整する必要があります。公式情報では、Azure接続を許可する方法、Self-hosted Integration Runtimeを使う方法、Managed VNETを使う方法が示されています。(Microsoft Learn)
選び方の目安は次のとおりです。
| 接続方式 | 向いている環境 | 注意点 |
|---|---|---|
| Azureサービスからの接続を許可 | 構成をシンプルにしたい検証環境や標準的なAzure構成 | 許可範囲が広くなるため、組織のセキュリティ基準に合うか確認する |
| Self-hosted Integration Runtime | 閉域ネットワークや既存ネットワーク制御を重視する環境 | マネージドID認証が使えず、SQL認証またはサービスプリンシパルが必要 |
| Managed VNET | Purview側で閉域接続を設計したい環境 | リネージ抽出など一部機能との組み合わせに制約がある |
特に注意したいのは、Self-hosted Integration Runtimeを使う場合、Azure SQL Databaseに対するシステム割り当てマネージドIDとユーザー割り当てマネージドIDが使えない点です。この構成では、SQL認証またはサービスプリンシパル認証を選ぶ必要があります。(Microsoft Learn)
認証方式の選び方
Microsoft PurviewからAzure SQL Databaseをスキャンする認証方式には、システム割り当てマネージドID、ユーザー割り当てマネージドID、サービスプリンシパル、SQL認証があります。公式情報では、システム割り当てマネージドIDが推奨として説明されていますが、ネットワーク構成によって選択肢が変わります。(Microsoft Learn)
| 認証方式 | 推奨される場面 | 注意点 |
|---|---|---|
| システム割り当てマネージドID | Azure上で標準的に構成し、資格情報管理を減らしたい場合 | Self-hosted Integration RuntimeではAzure SQL向けに使えない |
| ユーザー割り当てマネージドID | IDをPurviewアカウントとは別に管理したい場合 | プレビュー扱いの記載があるため、本番採用前に社内基準を確認する |
| サービスプリンシパル | 自動化、期間限定プロジェクト、閉域構成で使いたい場合 | シークレット期限切れとKey Vault連携を運用に組み込む |
| SQL認証 | 既存SQLログインを使う、または閉域構成で簡単に始めたい場合 | パスワード管理、権限最小化、ローテーションが重要 |
マネージドIDやサービスプリンシパルを使う場合、SQL Database側でMicrosoft Entra認証を構成し、対象IDにメタデータ取得と分類サンプル取得に必要な権限を付与します。公式例では、少なくともdb_datareader相当の権限が必要とされています。(Microsoft Learn)
本番環境では、最初から広い権限を与えるのではなく、検証用DBでスキャンが通る最小権限を確認し、その後に対象DBへ横展開するのが安全です。
スキャンの作成とスコープ設計
スキャンは、登録済みのAzure SQL DatabaseソースからNew Scanを作成し、認証方式を選択し、接続テストを行ってから実行します。スキャン対象は、必要に応じて特定のデータベースオブジェクトに絞り込めます。スキャンルールセットは既定のものを使うだけでなく、既存のカスタムルールセットを選ぶか、新規作成することもできます。(Microsoft Learn)
スキャン設計で重要なのは、「最初から全DBをフルスキャンしない」ことです。特に本番DBでは、次の順序で進めると失敗時の切り分けがしやすくなります。
| フェーズ | 実施内容 | 目的 |
|---|---|---|
| 検証 | 小さなテーブル、代表的なビューを対象にスコープ指定スキャン | 認証、ネットワーク、権限の問題を切り分ける |
| 初回展開 | 対象DB全体のフルスキャン | カタログ化と分類の初期状態を作る |
| 運用 | 増分スキャンまたはスケジュール実行 | 日々の変更を追跡する |
| 見直し | スキャン履歴、分類件数、失敗オブジェクトを確認 | ルールセットや権限の改善につなげる |
スキャン状態は、データソースの詳細画面から確認できます。Last run statusは実行中から完了へ変わり、スキャン済み資産数や分類数も確認できます。再実行時には、Full scanとIncremental scanを選べます。(Microsoft Learn)
アクセス ポリシーを使う場合の注意点
Azure SQL Databaseでは、Microsoft PurviewのData owner policies、Self-service policies、Protection policies、DevOps policiesがサポート対象として示されています。これにより、データ所有者によるアクセス付与、利用者のセルフサービスアクセス申請、秘密度ラベルに基づく保護、監査・運用担当向けのメタデータアクセスなどを設計できます。(Microsoft Learn)
ただし、アクセス ポリシーは「Purviewに登録すればすぐ全リージョンで同じように効く」と考えると危険です。公式情報では、Microsoft Purviewの全リージョンがサポート対象とされる一方、Azure SQL Databaseに対するポリシー適用は特定リージョンに限定されています。公開クラウドの一覧にはEast Asiaは含まれますが、Japan EastやJapan Westは表示されていません。日本リージョンのAzure SQL Databaseにポリシー適用を計画している場合は、必ず最新の公式リージョン一覧と自社テナントでの利用可否を確認してください。(Microsoft Learn)
アクセス ポリシーを有効化するには、Azure SQL Databaseの論理サーバーでMicrosoft Entra管理者を設定し、論理サーバーのシステム割り当てマネージドIDを有効にする必要があります。さらに、データポリシー適用を有効化するには、対象リソースまたは親スコープでIAM Owner、またはIAM ContributorとIAM User Access Administratorの組み合わせが必要です。Purview側ではData source adminやPolicy authorなどのロール設計も必要になります。(Microsoft Learn)
移行・リソース移動で見落としやすい点
Azure SQL Databaseを別のリソースグループやサブスクリプションへ移動する場合は、Microsoft Purview側の登録状態も見直しが必要です。公式情報では、PurviewポリシーはデータリソースのARMパスに依存するため、リソースが新しいリソースグループやサブスクリプションへ移動された場合、Microsoft Purviewで登録解除して再登録する必要があるとされています。(Microsoft Learn)
移行時は、次の順序で確認すると安全です。
| タイミング | 確認内容 |
|---|---|
| 移行前 | 登録済みソース、関連ポリシー、スキャンスケジュール、コレクション権限をエクスポートまたは記録する |
| 移行中 | Azure SQL DatabaseのARMパス、論理サーバー、Microsoft Entra管理者、ネットワーク設定の変更有無を確認する |
| 移行後 | Purviewで再登録し、接続テスト、スコープ指定スキャン、ポリシー状態確認を行う |
| 本番再開前 | Azureポータル側でMicrosoft Purview Governance Statusが意図した状態になっているか確認する |
また、既存のPurviewアカウントから別のPurviewアカウントへデータポリシー適用を移す場合は、対象データソースのGovernance StatusがNot Governedになっていることを確認してから、新しいPurviewアカウントで有効化する必要があります。(Microsoft Learn)
リネージ抽出を使う場合の制約
Microsoft Purviewは、Azure SQL Databaseのビューとストアドプロシージャのリネージに対応しています。ビューのリネージはメタデータスキャンに含まれますが、ストアドプロシージャのリネージを抽出するには、スキャン設定時にLineage extractionを有効にする必要があります。(Microsoft Learn)
ただし、リネージ抽出は制約が多い領域です。公式情報では、Self-hosted Integration RuntimeまたはManaged VNET RuntimeとAzure SQL private endpointの組み合わせではリネージがサポートされないとされています。この場合、Azure SQL Database側でAzureサービスからのアクセスを許可し、Microsoft Purviewアカウント側でもパブリックアクセスを許可する必要があります。(Microsoft Learn)
ストアドプロシージャのリネージ抽出では、Microsoft PurviewのマネージドIDにdb_owner権限が必要とされています。これは、リネージがXEventセッションに基づくため、SQL側でXEventセッションを管理する権限が必要になるためです。(Microsoft Learn)
さらに、リネージ抽出は過去に実行されたストアドプロシージャをさかのぼって捕捉するものではありません。成功したスキャン設定後に実行されたストアドプロシージャが対象です。重いワークロードでは直近の実行だけが抽出対象になる場合があり、特定のCREATE、DROP、INSERTなどを含む処理や一部パターンでは取得できない可能性があります。(Microsoft Learn)
リネージ検証で実施したいこと
| 検証項目 | 具体的な確認方法 |
|---|---|
| ビューのリネージ | 新規スキャン後、代表的なビューのLineageタブを確認する |
| ストアドプロシージャ実行 | Lineage extraction有効化後に代表的なSPを実行する |
| 権限 | PurviewマネージドIDに必要なSQL権限があるか確認する |
| ネットワーク | プライベートエンドポイント構成でリネージ要件を満たせるか確認する |
| SQL構文 | 対象SPにサポート外になり得る処理が含まれていないか棚卸しする |
管理者が展開前に確認すべき実務ポイント
本番展開では、機能を有効にする前に「誰が管理し、誰が変更でき、何が失敗したら誰が対応するか」を明確にしておく必要があります。
特に注意したいのは、Purview側の強いロールです。公式情報では、root Collection admin、Collection admin、Data source admin、Policy authorなどのロール保有者を最小化し、慎重に精査することが推奨されています。また、公開済みポリシーを持つPurviewアカウントが削除されると、ポリシー適用が停止し、セキュリティとデータアクセス可用性に影響する可能性があります。削除防止にはResource Manager locksの利用も検討できます。(Microsoft Learn)
展開チェックリスト
| 分類 | チェック項目 |
|---|---|
| 権限 | Azure RBAC、Purviewロール、SQL権限が最小権限になっているか |
| ネットワーク | ファイアウォール、Azureサービス許可、Integration Runtimeの選択が妥当か |
| 認証 | マネージドID、サービスプリンシパル、SQL認証の選択理由が説明できるか |
| Key Vault | シークレットの保管、更新、期限切れ通知の運用があるか |
| スキャン | 初回フルスキャン、増分スキャン、スキャン対象除外ルールを決めているか |
| 分類 | 既定ルールだけで十分か、カスタム分類ルールが必要か |
| ポリシー | 対象リージョン、Governed状態、ロール分離を確認したか |
| リネージ | 対象ビュー・SPで実際に取得できるか検証したか |
| 移行 | リソース移動時の再登録手順を運用手順書に入れたか |
| 監査 | スキャン履歴、失敗履歴、ポリシー変更者を定期確認できるか |
よくある失敗と対策
接続テストに失敗する
まず確認すべきは、ネットワークと認証です。Azure SQL Databaseのファイアウォール、Azureサービスからのアクセス許可、Integration Runtimeの到達性、資格情報の種類を順に確認します。Self-hosted Integration Runtimeを使っているのにマネージドID認証を選んでいる場合は、構成上のミスマッチが原因になり得ます。(Microsoft Learn)
スキャンは成功するが分類が期待どおりでない
スキャンルールセットが対象データに合っていない可能性があります。既定ルールで検出できない業務固有データ、たとえば会員番号、契約番号、社内コードなどは、カスタム分類ルールの検討が必要です。最初から全テーブルを評価するのではなく、代表テーブルで分類結果を確認してから横展開しましょう。
ポリシーを有効にしたのに反映されない
Azure SQL Server側でMicrosoft Purview Governance Statusを確認します。データポリシー適用を有効化した直後は反映に時間がかかる場合があります。また、無効化した場合も、対象データソースごとにCheck for Microsoft Purview Governanceを実行し、Not Governedへ更新されることを確認する必要があります。(Microsoft Learn)
リネージが表示されない
リネージは、設定前の過去実行をさかのぼって取得しません。Lineage extractionを有効化し、スキャン設定が成功した後にストアドプロシージャを実行し、その後にLineageタブを確認してください。プライベートエンドポイント構成やサポート外のSQLパターンも原因になります。(Microsoft Learn)
まず実施すべき次のアクション
Microsoft PurviewでAzure SQL Databaseを管理する場合、最初にやるべきことは全社展開ではありません。まずは対象を1つの非本番または影響の小さいAzure SQL Databaseに絞り、登録、接続テスト、スコープ指定スキャン、分類結果確認までを一通り実施します。
そのうえで、次の順番で本番展開へ進めるのが現実的です。
| 順序 | 実施内容 |
|---|---|
| 1 | 対象DB、責任者、コレクション、命名規則を決める |
| 2 | ネットワーク方式と認証方式を決める |
| 3 | 最小権限で接続テストを実施する |
| 4 | 小さな範囲でスキャンし、分類結果を確認する |
| 5 | 必要に応じてスキャンルールセットを調整する |
| 6 | アクセス ポリシーやリネージ抽出を検証する |
| 7 | 本番DBへ段階的に展開する |
| 8 | スキャン履歴、ポリシー変更、権限を定期レビューする |
Microsoft Purviewは、Azure SQL Databaseを「見える化」するだけのツールではありません。データの所在、分類、アクセス制御、リネージをつなげて、組織として安全にデータを使うための基盤です。まずは小さく検証し、ネットワーク、認証、ポリシー、リネージの制約を洗い出してから、本番のデータガバナンスに組み込んでください。
コメント