本記事は GitHub Copilot を活用して作成しています。
Azure Monitor は Azure のリソースやアプリケーションを監視するための中心的なサービスです。
しかし、監視データには機密情報が含まれる可能性があり、適切なネットワークセキュリティの設定が重要です。
2025 年 8 月に Network Security Perimeter (NSP) が GA となり、Azure Monitor でも利用できるようになりました。
今回は Network Security Perimeter を使用して Azure Monitor のセキュリティを強化する方法を検証します。
引用元を記載しているので、最新の情報は元のリンクを確認してください
想定する読者
この記事は以下のような方を対象としています:
- Azure Monitor を使用して監視を行っている方
- Azure のネットワークセキュリティ設定に関心がある方
- ゼロトラストアーキテクチャの実装を検討している方
- Azure Monitor へのアクセスを特定のネットワークに制限したい方
Network Security Perimeter とは
Network Security Perimeter (NSP) は、Azure のリソースに対するネットワークベースのアクセス制御を一元管理するための機能です。
従来、Azure のリソースごとにファイアウォール設定やプライベートエンドポイントを個別に設定する必要がありましたが、NSP を使用することで、複数のリソースに対してネットワークポリシーを統一的に適用できます。
architecture-beta
group nsp_group[Network Security Perimeter]
service law(azure:log-analytics-workspaces)[Log Analytics Workspace] in nsp_group
service dce(azure:monitor)[Data Collection Endpoint] in nsp_group
group vnet(azure:virtual-networks)[Virtual Network]
service vm(azure:virtual-machine)[Virtual Machine] in vnet
vm:R --> L:dce
dce:T --> B:law
vm:T --> L:law
Data Collection Endpoint (DCE) にはいくつかのシナリオで利用します
例えば Windows から Windows Firewall のログを取得する場合に必要です
今回はその特性を活かして、NSP の検証に使用します
すなわち、以下の2種類のログの取得で NSP の動作を確認してみます
- DCE を経由する Windows Firewall のログ
- DCE を経由しない Log Analytics ワークスペース への直接アクセス (Heartbeat など)
NSP の主な特徴
- 一元管理: 複数の Azure リソースに対してネットワークポリシーを統一的に管理
- 柔軟なアクセス制御: IP アドレス範囲、仮想ネットワーク、プライベートエンドポイントなど、複数の方法でアクセスを制御
- 監査機能: NSP の境界を越えたアクセス試行をログとして記録
- 段階的な適用: 移行モードを使用して既存の通信を分析し、段階的にポリシーを適用可能
Network Security Perimeter がなかったときに困ること
NSP が登場する前は、Azure の様々な PaaS サービスにおいて以下のような課題がありました:
1. 個別のリソース設定が必要
Azure の各 PaaS サービス(Storage Account、Key Vault、SQL Database、Cosmos DB、Log Analytics ワークスペース、Application Insights など)に対して、個別にネットワーク設定を行う必要がありました。
例えば、以下のようなリソースすべてに個別の設定が必要でした:
flowchart TD
A[管理者] --> B[Storage Account]
A --> C[Key Vault]
A --> D[SQL Database]
A --> E[Cosmos DB]
A --> F[Log Analytics]
A --> G[App Insights]
B --> H[ファイアウォール設定]
C --> I[ファイアウォール設定]
D --> J[ファイアウォール設定]
E --> K[ファイアウォール設定]
F --> L[ファイアウォール設定]
G --> M[ファイアウォール設定]
style H fill:#f96,color:#fff
style I fill:#f96,color:#fff
style J fill:#f96,color:#fff
style K fill:#f96,color:#fff
style L fill:#f96,color:#fff
style M fill:#f96,color:#fff
また、サービスによってはネットワーク設定が提供されていない場合もあり、セキュリティ要件を満たすのが困難でした。
2. 設定の一貫性を保つのが困難
複数のリソースに対して同じネットワークポリシーを適用する場合、手動で設定を繰り返す必要があり、設定ミスや一貫性の欠如が発生しやすい状況でした。
3. Private Link の複雑な管理
Azure Monitor Private Link Scope (AMPLS) を使用する場合、以下のような複雑な設定が必要でした:
- 各リソースを AMPLS に関連付け
- プライベートエンドポイントの作成と管理
- DNS の構成
- ネットワーク分離モードの設定
4. アクセス拒否の監査が困難
どのアクセスがブロックされたのかを追跡するには、各リソースのリソースログを個別に確認する必要がありました。
5. 送信設定の制御不可
PaaS リソースの受信設定は管理できましたが、送信設定を管理することはできないケースがほとんどでした
Network Security Perimeter で実現できること
NSP を使用することで、以下のようなことが実現できます:
1. 統一的なネットワークポリシーの適用
複数の Azure リソースを NSP に関連付けることで、一つのポリシー設定ですべてのリソースのアクセス制御を管理できます。
flowchart TD
A[管理者] --> B[Network Security Perimeter]
B --> C[アクセスルール設定]
C --> D[Log Analytics Workspace]
C --> E[Data Collection Endpoint]
C --> F[Storage Account]
C --> G[SQL Database]
style B fill:#0078d4,color:#fff
style C fill:#0078d4,color:#fff
2. 柔軟なアクセス制御
以下の複数の方法を組み合わせてアクセスを制御できます:
- パブリック ネットワークアクセスの制御: パブリックネットワークからのアクセスを制限(従来の方法)
- IP アドレスベースのアクセス制御: 特定の IP アドレス範囲からのアクセスを許可
- サブスクリプションベースのアクセス: 特定の Azure サブスクリプションからのアクセスを許可
- プライベートエンドポイント: プライベート IP アドレスを使用した安全な接続
3. 移行モードによる段階的な適用
既存の環境に NSP を適用する際、移行モード(Migration Mode)を使用して、現在の通信パターンを分析できます。
sequenceDiagram
participant Admin as 管理者
participant NSP as Network Security Perimeter
participant Logs as リソースログ
Admin->>NSP: 移行モードを有効化
Note over NSP: すべてのアクセスを許可し、ログを記録
NSP->>Logs: アクセスパターンを記録
Admin->>Logs: ログを分析
Note over Admin: 必要なアクセスルールを特定
Admin->>NSP: アクセスルールを適用
Admin->>NSP: 強制モードに切り替え
Note over NSP: ルールに基づいてアクセスを制御
Network Security Perimeter のモード(移行、強制)と各リソースのパブリック ネットワークアクセスの組み合わせは以下に記載があります
Azure のネットワーク セキュリティ境界への移行 - Azure Private Link | Microsoft Learn
端的に言うと、強制モードが有効な場合 Network Security Perimeter によってアクセスが制御されます
それ以外の場合は各リソースのパブリック ネットワーク アクセス設定に従いますが、新しく導入された Secured By Perimeter オプションを使用すると強制モードと同様の効果になります
4. 包括的な監査とコンプライアンス
NSP はすべてのアクセス試行をログに記録するため、セキュリティ監査やコンプライアンス要件への対応が容易になります。
5. 送信設定の制御
NSP を使用することで、PaaS リソースからの送信設定も管理できるようになります
ざっくり手順
今回は以下の手順で Network Security Perimeter を Azure Monitor で検証します:
- Azure Monitor リソースの準備
- Network Security Perimeter の作成
- NSP への Azure Monitor リソースの関連付け
- アクセスルールの設定
- 移行モードでの動作確認
- 強制モードでの動作確認
- リソースログの確認
今回作成する環境はこちらです
flowchart TD
%% Azure Monitor + NSP 全体像
%% - NSP: Log Analytics / DCE を保護
%% - VNet 内の VM から DCE 経由で送信
%% - VM から Log Analytics へ直接も送信される
%% Network Security Perimeter グループ
subgraph NSP[Network Security Perimeter]
direction TB
subgraph profile1[Profile:defaultprofile]
LAW[Log Analytics Workspace<br/>law-nsp-demo]
end
subgraph profile2[Profile:block]
DCE[Data Collection Endpoint<br/>dce-nsp-demo]
end
end
%% Virtual Network グループ
subgraph VNET[Virtual Network<br/>vnet-nsp-demo]
direction TB
VM[Virtual Machine<br/>vm-nsp-demo]
end
%% 通信フロー
VM -->|Windows Firewall Log| DCE
DCE -->|データ収集| LAW
VM -->|Heartbeat など<br/>直接送信| LAW
%% 色付け
%% ネットワーク系: 緑 (#9f6)
%% PaaS 系: オレンジ (#f96)
%% データベース/ログ系: 青 (#9cf)
%% セキュリティ関連(NSP として強調): 赤寄り (#f88)
style NSP fill:#f8aaaa,stroke:#cc0000,color:#000000
style VNET fill:#99ff66,stroke:#007700,color:#000000
style VM fill:#99ff66,stroke:#007700,color:#000000
style DCE fill:#ff9966,stroke:#cc6600,color:#000000
style LAW fill:#99ccff,stroke:#0066cc,color:#000000
1. Azure Monitor リソースの準備
検証のために、以下のリソースを作成します:
- Log Analytics ワークスペース
- Data Collection Endpoint (DCE)
リソースグループの作成
- Azure Portal にサインインします
- 検索バーで「リソースグループ」を検索し、選択します
- 「+ 作成」をクリックします
- 以下の情報を入力します:
- サブスクリプション: 該当のサブスクリプションを選択
- リソースグループ名:
rg-nsp-monitor-demo - リージョン:
Japan East
- 「確認および作成」→「作成」をクリックします
Log Analytics ワークスペースの作成
- 検索バーで「Log Analytics ワークスペース」を検索し、選択します
- 「+ 作成」をクリックします
- 以下の情報を入力します:
- サブスクリプション: 該当のサブスクリプションを選択
- リソースグループ:
rg-nsp-monitor-demo - 名前:
law-nsp-demo - リージョン:
Japan East
- 「確認および作成」→「作成」をクリックします
Data Collection Endpoint の作成
- 検索バーで「データ収集エンドポイント」を検索し、選択します
- 「+ 作成」をクリックします
- 以下の情報を入力します:
- サブスクリプション: 該当のサブスクリプションを選択
- リソースグループ:
rg-nsp-monitor-demo - 名前:
dce-nsp-demo - リージョン:
Japan East
- 「確認および作成」→「作成」をクリックします
仮想マシンの作成
仮想マシンを作成し、ログの収集設定をしておきます
Windows Firewall のログを収集する設定は以下の記事を参考にしてください
Azure Monitor エージェントを使用してファイアウォール ログを収集する - Azure Monitor | Microsoft Learn
2. Network Security Perimeter の作成
次に、Network Security Perimeter を作成します。
- Azure Portal の検索バーで「Network Security Perimeter」を検索し、選択します
- 「+ 作成」をクリックします
- 以下の情報を入力します:
- サブスクリプション: 該当のサブスクリプションを選択
- リソースグループ:
rg-nsp-monitor-demo - 名前:
nsp-monitor-demo - リージョン:
Japan East - プロファイル: デフォルトのまま(
defaultprofile)
- 「確認および作成」→「作成」をクリックします
NSP の診断設定
作成した NSP に対して診断設定を有効化します:
- 作成した Network Security Perimeter
nsp-monitor-demoを開きます - 左側のメニューから「診断設定」を選択します
- 「+ 診断設定を追加する」をクリックします
- 以下の情報を入力します:
- 診断設定の名前:
nsp-diagnostics - ログ:
allLogsをチェック - 宛先の詳細: 「Log Analytics ワークスペースに送信する」をチェック
- サブスクリプション: 該当のサブスクリプションを選択
- Log Analytics ワークスペース:
law-nsp-demoを選択
- 診断設定の名前:
- 「保存」をクリックします
3. NSP への Azure Monitor リソースの関連付け
作成した NSP に Azure Monitor リソースを関連付けます。
Log Analytics ワークスペースの関連付け
- 作成した Network Security Perimeter
nsp-monitor-demoを開きます - 左側のメニューから「関連付けられているリソース」を選択します
- 「+ 追加」> 「リソースを既存のプロファイルに関連付ける」をクリックします
- Log Analytics ワークスペース
law-nsp-demoを検索して選択します - 「追加」をクリックします
Data Collection Endpoint の関連付け
Data Collection Endpoint も NSP に関連付けますが、動作を確認するため異なるプロファイルに関連付けます:
- 作成した Network Security Perimeter
nsp-monitor-demoを開きます - 左側のメニューから「プロファイル」を選択し、
defaultprofileとは別のプロファイルを作成します:- 「+ プロファイルの追加」をクリックします
- プロファイル名:
block - リソース タブで Data Collection Endpoint
dce-nsp-demoを選択します - 「選択」をクリックします
- 「確認および作成」をクリックします
関連付けが完了すると、「リソース」画面に追加されたリソースが表示されます。
4. アクセスルールの設定
NSP のアクセスルールを設定します。まずは移行モードで開始します。
アクセスルールの追加(IP アドレス範囲)
特定の IP アドレス範囲からのアクセスを許可するルールを追加します:
- プロファイル
defaultprofileを選択します - 左側のメニューから「受信アクセス規則」を選択します
- 「+ 追加」をクリックします
- 以下の情報を入力します:
- ルール名:
AllowOfficeIP - 送信元の種類:
IP アドレス範囲 - IP アドレス範囲: (自組織のオフィス IP アドレス)
- ルール名:
- 続けて VM からのアクセスを許可するルールを追加します:
- ルール名:
AllowVM - 送信元の種類:
IP アドレス範囲 - IP アドレス範囲: (仮想マシンが利用するパブリック IP アドレス)
- ルール名:
- 「追加」をクリックします
6. 移行モードでの動作確認
最初は移行モードで NSP を運用し、どのようなアクセスが発生しているかを確認します。
移行モードの有効化
- Network Security Perimeter
nsp-monitor-demoの画面で、関連付けられているリソースを選択します - Log Analytics ワークスペースと Data Collection Endpoint のアクセスモード が「移行」になっていることを確認します(デフォルトは移行モード)
- もし「強制」になっている場合は、「設定」から「移行」に変更します
移行モードでは、すべてのアクセスが許可されますが、NSP のルールに一致しないアクセスがログに記録されます。
動作確認
Log Analytics ワークスペースにアクセスして動作を確認します:
- Azure Portal で Log Analytics ワークスペース
law-nsp-demoを開きます - 左側のメニューから「ログ」を選択します
- 以下のクエリを実行します:
Heartbeat | take 10 - クエリが正常に実行されることを確認します
このアクセスがログに記録されているか、後ほど確認します。
7. 強制モードでの動作確認
移行モードで十分なデータが収集できたら、強制モードに切り替えます。
強制モードへの切り替え
- Network Security Perimeter
nsp-monitor-demoの画面で、関連付けられているリソースを選択します - Log Analytics ワークスペースと Data Collection Endpoint のアクセスモード を確認します
- 適用モード を「移行」から「強制」に変更します
- 「保存」をクリックします
強制モードでは、NSP のルールに一致しないアクセスがブロックされます。
アクセス制御の確認
許可された IP アドレスまたはネットワークから Log Analytics ワークスペースにアクセスできることを確認します:
- 許可された環境(設定した IP アドレス範囲または仮想ネットワーク内)から Azure Portal にアクセスします
- Log Analytics ワークスペース
law-nsp-demoを開きます - 「ログ」画面でクエリを実行します
- 正常にクエリが実行されることを確認します
許可されていない IP アドレスからアクセスすると、以下のようなエラーが発生します:
8. リソースログの確認
NSP の動作を監視するために、リソースログを確認します。
ログの確認
Log Analytics ワークスペースで NSP のアクセスログを確認します:
- Log Analytics ワークスペース
law-nsp-demoを開きます - 左側のメニューから「ログ」を選択します
- 以下のクエリを実行して、NSP によってブロックされたアクセスを確認します:
// NSP によってブロックされたアクセスを確認
NSPAccessLogs
| where ResultAction == "Denied"
| project TimeGenerated, OperationName, Profile, ResultAction, SourceIpAddress
- 以下のクエリを実行して、NSP を通過したすべてのアクセスを確認します:
// NSP を通過したすべてのアクセスを確認
NSPAccessLogs
| where ResultAction == "Allowed"
| project TimeGenerated, OperationName, Profile, ResultAction, SourceIpAddress
実際に Windows Firewall のログを見てみると、とある時刻から取り込みが止まっていることがわかります
すなわち、下記のように NSP で制御できています
flowchart TD
%% Azure Monitor + NSP 全体像
%% - NSP: Log Analytics / DCE を保護
%% - VNet 内の VM から DCE 経由で送信
%% - VM から Log Analytics へ直接も送信される
%% Network Security Perimeter グループ
subgraph NSP[Network Security Perimeter]
direction TB
subgraph profile1[Profile:defaultprofile]
LAW[Log Analytics Workspace<br/>law-nsp-demo]
end
subgraph profile2[Profile:block]
DCE[Data Collection Endpoint<br/>dce-nsp-demo]
end
end
%% Virtual Network グループ
subgraph VNET[Virtual Network<br/>vnet-nsp-demo]
direction TB
VM[Virtual Machine<br/>vm-nsp-demo]
end
%% 通信フロー
VM -.-x |Windows Firewall Log| DCE
DCE x-.-x |データ収集| LAW
VM -->|Heartbeat など<br/>直接送信| LAW
%% 色付け
%% ネットワーク系: 緑 (#9f6)
%% PaaS 系: オレンジ (#f96)
%% データベース/ログ系: 青 (#9cf)
%% セキュリティ関連(NSP として強調): 赤寄り (#f88)
style NSP fill:#f8aaaa,stroke:#cc0000,color:#000000
style VNET fill:#99ff66,stroke:#007700,color:#000000
style VM fill:#99ff66,stroke:#007700,color:#000000
style DCE fill:#ff9966,stroke:#cc6600,color:#000000
style LAW fill:#99ccff,stroke:#0066cc,color:#000000
まとめ
Network Security Perimeter を使用することで、Azure Monitor のリソースに対するネットワークアクセスを統一的に管理できるようになりました。
NSP の主なメリット
- 一元管理: 複数のリソースに対して統一的なネットワークポリシーを適用
- 柔軟性: IP アドレス、仮想ネットワーク、プライベートエンドポイントなど、複数の方法でアクセス制御
- 段階的適用: 移行モードを使用して既存の通信を分析し、影響を最小限に抑えながらポリシーを適用
- 監査機能: すべてのアクセス試行をログに記録し、セキュリティ監査を容易に
- 送信設定の管理: PaaS リソースからの送信設定も管理可能
今後の展開
NSP は Azure Monitor だけでなく、他の Azure サービスでも利用可能です。組織全体のネットワークセキュリティポリシーを統一的に管理するために、NSP の活用を検討してみてください。
また、NSP と Azure Private Link、Azure Firewall などの他のネットワークセキュリティ機能を組み合わせることで、より強固なゼロトラストアーキテクチャを実現できます。
今回は検証しませんでしたが、NSP は送信設定の管理も可能にするため、今後はその部分も検証してみたいと思います。
参考リンク
- ネットワーク セキュリティ境界を使用した Azure Monitor のシナリオ - Azure Monitor | Microsoft Learn
- General Availability of Azure Monitor Network Security Perimeter Features | Microsoft Community Hub
- Azure Network Security Perimeter とは - Azure Private Link | Microsoft Learn
- Azure Monitor Private Link Scope の概要 - Azure Monitor | Microsoft Learn
- Log Analytics ワークスペースのネットワーク分離 - Azure Monitor | Microsoft Learn