重要
Microsoft Purview 統合カタログと従来の Microsoft Purview データ ガバナンス機能 (旧称 Azure Purview) は廃止されます。 Microsoft は、Microsoft Fabric のデータ ガバナンス機能を統合しています。 新しいアカウントは作成できなくなり、既存の機能は 2027 年 11 月 12 日までメンテナンス モードのままになります。 廃止のタイムライン、移行ガイダンス、推奨される次の手順については、 Microsoft Purview データ ガバナンスの廃止のお知らせを参照してください。
注:
Microsoft Purview データ カタログ (クラシック)、データ正常性分析情報 (クラシック)、Purview ワークフロー (クラシック) は新規顧客の受け入れを終了し、これらのサービス (以前の Azure Purview) はカスタマー サポート モードになりました。
この記事では、Microsoft Purview ガバナンス ポータルを使用して、データ資産内のデータ ソースへのアクセスを管理する方法について説明します。 DevOps ポリシーの基本的な概念に焦点を当てています。 つまり、他の記事に従って構成手順を取得する前に知っておくべき DevOps ポリシーに関する背景情報を提供します。
注:
この機能は、 Microsoft Purview ガバナンス ポータルの内部アクセス制御とは異なります。
システム メタデータへのアクセスは、IT および DevOps 担当者にとって、重要なデータベース システムが正常であり、期待どおりに動作し、安全であることを確認するために非常に重要です。 Microsoft Purview DevOps ポリシーを使用して、そのアクセス権を効率的かつ大規模に付与および取り消すことができます。
Microsoft Purview のルート コレクション レベルでポリシー作成者ロールを保持しているユーザーは、DevOps ポリシーを作成、更新、削除できます。 DevOps ポリシーを保存すると、自動的に発行されます。
アクセス ポリシーと DevOps ポリシー
Microsoft Purview アクセス ポリシーを使用すると、お客様はクラウドの中央の場所から、データ資産全体にわたるデータ システムへのアクセスを管理できます。 これらのポリシーは、Microsoft Purview Studio を通じて作成できるアクセス許可と考えることができ、コードの必要性を回避できます。 これらの命令は、ユーザーやグループなどの Microsoft Entra プリンシパルの一覧に対して、データ ソースまたはその中の資産への特定の種類のアクセスを許可または拒否するかどうかを規定します。 Microsoft Purview は、これらのポリシーをデータ ソースに伝達し、そこでネイティブに適用されます。
DevOps ポリシーは、Microsoft Purview アクセス ポリシーの特別な種類です。 ユーザー データではなくデータベース システム メタデータへのアクセスを許可します。 これにより、IT 運用およびセキュリティ監査担当者のアクセス プロビジョニングが簡素化されます。 DevOps ポリシーはアクセスのみを許可します。 彼らはアクセスを拒否しません。
DevOps ポリシーの要素
DevOps ポリシーを定義する要素は 3 つあります。
件名
これは、アクセスが許可されている Microsoft Entra ユーザー、グループ、またはサービス プリンシパルの一覧です。
データ リソース
これは、ポリシーが適用されるスコープです。 データ リソース パスは、サブスクリプション > リソース グループ > データ ソースの構成です。
Microsoft Purview DevOps ポリシーでは現在、SQL タイプのデータ ソースがサポートされています。 これらは、個々のデータ ソースに対して、およびリソース グループとサブスクリプション全体で構成できます。 DevOps ポリシーを作成することができるのは、[ データ ポリシーの適用 ] オプションをオンにして Microsoft Purview にデータ リソースを登録した後のみです。
役割
ロールは、ポリシーがデータ リソースで許可する一連のアクションにマップされます。 DevOps ポリシーは、SQL パフォーマンス モニター ロールと SQL セキュリティ監査役をサポートします。 これらの役割は両方とも、SQL システム メタデータ、より具体的には動的管理ビュー (DMV) と動的管理機能 (DMF) へのアクセスを提供します。 ただし、これらの役割が付与する DMV と DMF のセットは異なります。 この記事 の後半で、いくつかの一般的な例を示します。
Microsoft Purview DevOps ポリシーの作成、一覧表示、更新、削除に関する記事では、各データ ソースの種類のロール定義について詳しく説明します。 つまり、Microsoft Purview 内の役割を、その種類のデータ ソースで許可されているアクションにマッピングします。 例えば、SQL パフォーマンス モニター と SQL Security Auditor の役割定義には、データ・ソース側のサーバー・レベルおよびデータベース・レベルでの 接続 アクションが含まれています。
本質的に、DevOps ポリシーは、ロールの関連するアクセス許可をサブジェクトに割り当て、データ リソースのパスのスコープ内に適用されます。
ポリシーの階層的適用
データ リソースに対する DevOps ポリシーは、データ リソース自体と、それに含まれるすべての子リソースに適用されます。 たとえば、Azure サブスクリプションの DevOps ポリシーは、すべてのリソース グループ、各リソース グループ内のすべてのポリシーが有効なデータ ソース、および各データ ソース内のすべてのデータベースに適用されます。
コンセプトと利点を示すシナリオ例
Bob と Alice は、彼らの会社の DevOps プロセスに関わっています。 重要な DevOps プロセスが中断されないようにパフォーマンスを監視するために、オンプレミスの数十の SQL Server インスタンスと Azure SQL 論理サーバーにログインする必要があります。 マネージャーの Mateo は、これらすべての SQL データ ソースをリソース グループ 1 に配置します。 次に、Alice と Bob を含む Microsoft Entra グループを作成します。 次に、Microsoft Purview DevOps ポリシー (次の図のポリシー 1) を使用して、論理サーバーをホストするリソース グループ 1 へのアクセス権をこの Microsoft Entra グループに付与します。
利点は次のとおりです。
- Mateo は、各サーバーにローカル ログインを作成する必要はありません。
- Microsoft Purview のポリシーは、ローカルの特権アクセスを制限することでセキュリティを高めます。 彼らは最小権限の原則を支持します。 このシナリオでは、Mateo は Bob と Alice がシステムの正常性とパフォーマンスを監視するタスクを実行するために必要な最小限のアクセスのみを許可します。
- 新しいサーバーがリソース グループに追加された場合、Mateo は、新しいサーバーに適用するために Microsoft Purview のポリシーを更新する必要はありません。
- Alice または Bob が組織を辞め、仕事がバックフィルされた場合、Mateo は Microsoft Entra グループを更新するだけです。 サーバーや Microsoft Purview で作成したポリシーに変更を加える必要はありません。
- Mateo または会社の監査人は、Microsoft Purview Studio で直接付与されたすべてのアクセス許可をいつでも確認できます。
| 原則 | メリット |
|---|---|
| 簡略化 | ロール定義 SQL パフォーマンス モニター と SQL Security Auditor は、一般的な IT および DevOps ペルソナがジョブを実行するために必要なアクセス許可を取得します。 |
| 各データ ソースの種類に関するアクセス許可の専門知識は少なくて済みます。 | |
| 労力を軽減する | グラフィカル インターフェイスにより、データ オブジェクト階層内をすばやく移動できます。 |
| Microsoft Purview では、Azure リソース グループとサブスクリプション全体に関するポリシーがサポートされています。 | |
| セキュリティを強化する | アクセスは一元的に付与され、簡単に確認および取り消すことができます。 |
| 特権アカウントを使用してデータ ソースで直接アクセスを構成する必要性が少なくなります。 | |
| DevOps ポリシーでは、データ リソース スコープとロール定義を通じて、最小限の特権の原則がサポートされます。 | |
DevOps ポリシー API
多くの洗練されたお客様は、UI ではなくスクリプトを使用して Microsoft Purview を操作することを好みます。 Microsoft Purview DevOps ポリシーでは、完全な作成、読み取り、更新、削除 (CRUD) 機能を提供する REST API がサポートされるようになりました。 この機能には、一覧、SQL パフォーマンス モニターのポリシー、および SQL セキュリティ監査のポリシーが含まれます。 詳細については、 API の仕様を参照してください。
![[Azure REST API] メニューで DevOps API を検索する場所を示すスクリーンショット。](../media/concept-policies-devops/devops-policy-api.png)
一般的な DMV と DMF のマッピング
SQL 動的メタデータには、700 を超える DMV および DMF のリストが含まれています。 次の表は、最も一般的なもののいくつかを示しています。 この表は、DMV と DMF を Microsoft Purview DevOps ポリシーのロール定義にマップしています。 また、参照コンテンツへのリンクも提供します。
| DevOps ロール | カテゴリ | 例: DMV または DMF |
|---|---|---|
| SQL パフォーマンス モニター | システム パラメーターを照会してシステムを把握する | sys.configurations |
| sys.dm_os_sys_info | ||
| パフォーマンスのボトルネックを特定する | sys.dm_os_wait_stats | |
| 現在実行されているクエリを分析する | sys.dm_exec_query_stats | |
| ブロックの問題を分析する | sys.dm_tran_locks | |
| sys.dm_exec_requests | ||
| sys.dm_os_waiting_tasks | ||
| メモリ使用量を分析する | sys.dm_os_memory_clerks | |
| ファイルの使用状況とパフォーマンスを分析する | sys.master_files | |
| sys.dm_io_virtual_file_stats | ||
| インデックスの使用状況と断片化を分析する | sys.indexes | |
| sys.dm_db_index_usage_stats | ||
| sys.dm_db_index_physical_stats | ||
| アクティブなユーザーの接続と内部タスクを管理する | sys.dm_exec_sessions | |
| プロシージャ実行統計を取得する | sys.dm_exec_procedure_stats | |
| クエリ ストアの使用 | sys.query_store_plan | |
| sys.query_store_query | ||
| sys.query_store_query_text | ||
| エラー ログを取得する (まだサポートされていません) | sys.sp_readerrorlog | |
| SQL Security Auditor | 監査の詳細を取得 | sys.dm_server_audit_status |
| SQL パフォーマンス モニターと SQL セキュリティ監査者の両方 | sys.dm_audit_actions | |
| sys.dm_audit_class_type_map | ||
Microsoft Purview ロールを介してアクセス権を付与した場合に IT サポート担当者が実行できる操作の詳細については、次のリソースを参照してください。
- SQL パフォーマンス モニター: Microsoft Purview を使用して、Azure SQL および SQL Server のパフォーマンス データへの大規模なアクセスを提供する
- SQL Security Auditor: セキュリティ関連の動的管理ビューと機能
次の手順
DevOps ポリシーを開始するには、次のリソースを参照してください。
- Azure SQL Database の DevOps ポリシーを試す: クイックスタート ガイド。
- 他のビデオ、ブログ、記事を参照してください。