Azure Firewall PremiumのTLS検査・IDPSは誰が運用責任を持つのか
- 山崎行政書士事務所
- 7月8日
- 読了時間: 20分
検知しただけで終わらせない、対応者・例外・記録を明確にするセキュリティ運用体制
確認日：2026年7月8日対象読者：情シス担当者、クラウド運用担当者、ネットワーク担当者、SOC／CSIRT担当者、経営層、監査対応担当者対象領域：Azure Firewall Premium、TLS検査、IDPS、Microsoft Sentinel、Azure Monitor、例外管理、セキュリティ運用規程
結論
Azure Firewall PremiumのTLS検査・IDPSは、有効化しただけでは不十分です。本番環境では、誰が検知を見るのか、誰がブロック判断をするのか、誰が例外を承認するのか、誰が記録を残すのかを文書化しなければなりません。
技術責任は主にクラウド基盤・ネットワークチーム、検知・初動責任はSOC／CSIRT、業務影響判断はシステムオーナー、例外承認は情報セキュリティ責任者、最終的なリスク受容は経営層が持つ形が現実的です。
Microsoft公式情報では、Azure Firewall PremiumのTLS検査は送信トラフィックを復号化・検査・再暗号化する機能であり、IDPSはネットワーク上の悪意ある活動を監視し、ログ記録・報告・必要に応じたブロックを行う機能として説明されています。確認日：2026年7月8日、Microsoft Learn最終更新：2025年9月18日。
理由
TLS検査とIDPSは、セキュリティ運用の「入口」です。検知後に誰も見ない、アラートが多すぎて放置される、正当な通信がブロックされても例外承認がない、という状態では、むしろ運用リスクになります。
Microsoft公式情報では、IDPSのシグネチャはレイヤー3から7のアプリケーション／ネットワークレベルのトラフィックに適用され、完全管理・継続更新され、受信、スポーク間、送信トラフィックに適用できると説明されています。一方で、暗号化されたHTTPSトラフィックを検査するにはTLS検査により復号してからIDPSで検出する必要があります。
つまり、Azure Firewall Premiumは「検知・遮断の能力」を提供します。しかし、検知後の判断、業務影響確認、例外承認、インシデント記録、再発防止は利用企業側の運用責任です。
数字で見る：最低限文書化すべき12項目
No. | 文書化項目 | 内容 |
1 | 運用責任者 | Firewall Policy、TLS検査、IDPSの管理責任者 |
2 | 監視担当者 | IDPSアラートを見るSOC／情シス担当 |
3 | 初動対応者 | アラート発生時に調査を開始する担当 |
4 | ブロック判断者 | AlertからAlert and Denyへ変更する承認者 |
5 | 例外承認者 | TLS検査除外、IDPSバイパス、署名無効化の承認者 |
6 | 業務影響確認者 | 対象システムのオーナー、業務部門責任者 |
7 | 証明書管理者 | TLS検査用CA証明書、Key Vault、期限管理 |
8 | ログ保存責任者 | Azure Monitor、Log Analytics、Sentinel、Storage |
9 | インシデント管理者 | チケット、Sentinel Incident、対応記録 |
10 | 変更管理者 | Firewall Policy変更、承認、リリース管理 |
11 | レビュー周期 | 週次、月次、四半期レビュー |
12 | 経営報告基準 | 重大インシデント、業務停止、外部影響時の報告基準 |
1. Azure Firewall PremiumのTLS検査・IDPSとは
Azure Firewall Premiumは、Standardの機能に加えて、TLS検査、IDPS、URLフィルタリング、Webカテゴリなどの高度な脅威保護機能を提供します。Microsoft公式情報では、TLS検査はHTTPS等の暗号化通信を復号・検査・再暗号化し、IDPSは悪意ある活動を監視・記録・報告し、必要に応じてブロックする機能と説明されています。
図1：TLS検査とIDPSの位置付け
利用者・ワークロード
│
│ HTTPS通信
▼
┌──────────────────────┐
│ Azure Firewall Premium │
│ │
│ 1. TLS検査 │
│ 復号・検査・再暗号化│
│ │
│ 2. IDPS │
│ シグネチャ検知 │
│ Alert / Deny │
└─────────┬────────────┘
│
▼
インターネット / 他VNet / オンプレミス2. TLS検査は「通信を見られるようにする」機能である
TLS検査がない場合、Azure Firewallは暗号化されたTLSトンネル内のデータを確認できず、保護機能が制限されます。Azure Firewall PremiumはTLS接続を終端して検査し、HTTPS上の悪意ある活動を検出・アラート・軽減するために、Webサーバー側とクライアント側の2つのTLS接続を作成します。
図2：TLS検査なし
Client ───────────── HTTPS暗号化トンネル ───────────── Server
Azure Firewall
│
└─ SNIや宛先情報など限定的な情報のみ確認
暗号化ペイロードの詳細検査は困難図3：TLS検査あり
Client
│
│ TLS接続①
▼
Azure Firewall Premium
│
│ 復号
│ IDPS / URL Filtering / Web Category
│ 再暗号化
▼
│ TLS接続②
Server3. TLS検査の対象範囲を誤解しない
Microsoft公式情報では、Azure FirewallがサポートするTLS検査のユースケースとして、Azure内部クライアントからインターネットへの送信TLS検査、Azure内やオンプレミスとの間のEast-West TLS検査が示されています。一方、インターネット等の外部からAzure内アプリへの受信TLS検査については、Application GatewayのAzure Web Application Firewallがサポートするユースケースとして説明されています。
表1：TLS検査の主な用途整理
通信方向 | Azure Firewall Premiumでの扱い | 実務上の注意 |
Azure内クライアント → インターネット | 送信TLS検査の対象 | 端末・ワークロードがCA証明書を信頼する必要 |
Azure VNet間 / Hub-Spoke間 | East-West TLS検査の対象 | 業務システム間通信への影響確認が必要 |
オンプレミス ↔ Azure | East-West用途として検討 | ルーティング、証明書配布、例外管理が重要 |
インターネット → Azure公開Web | Azure Firewall単体の受信TLS検査とは分けて設計 | Application Gateway WAF等との役割分担が必要 |
4. TLS検査用証明書の責任者を決める
TLS検査では、Firewallがオンザフライで証明書を生成するため、組織のCA証明書管理が重要です。Microsoft公式情報では、Azure Firewall Premium TLS検査を構成するには、有効な中間CA証明書をKey Vaultに格納する必要があり、エンドユーザーのブラウザーやクライアントアプリケーションは、組織のRoot CAまたは中間CAを信頼する必要があると説明されています。確認日：2026年7月8日、Microsoft Learn最終更新：2026年3月24日。
また、同公式ページでは、本番環境では企業PKIを使って中間CA証明書を作成することが推奨され、Root CA秘密鍵は安全なオフライン場所に保存すべきと説明されています。
表2：TLS検査証明書の運用責任
領域 | 主担当 | 承認者 | 記録すべき証跡 |
Root CA管理 | PKI担当 / 情シス | 情報セキュリティ責任者 | CA管理規程、保管場所、更新履歴 |
中間CA発行 | PKI担当 | 情報セキュリティ責任者 | 発行申請、証明書期限、用途 |
Key Vault登録 | クラウド基盤担当 | クラウド責任者 | 登録日時、証明書名、アクセス権 |
Firewall Policy紐付け | ネットワーク担当 | 変更管理責任者 | Firewall Policy変更履歴 |
クライアント信頼設定 | 端末管理担当 | 情シス責任者 | Intune/GPO配布記録 |
期限監視 | SOC / 運用担当 | 情シス責任者 | 期限アラート、更新台帳 |
5. Key Vaultの権限設計に注意する
Azure Firewall PremiumのTLS検査証明書について、Microsoft公式ページでは、Azure FirewallはKey Vault Certificateオブジェクトだけを直接参照するのではなく、対応するSecretを使って証明書へアクセスするため、FirewallのマネージドIDにSecretのGet/List権限が必要と説明されています。また、同ページでは、現時点でこの認可にAzure RBACはサポートされず、アクセスポリシーモデルを使用すると記載されています。
これはKey Vault全体のRBAC標準化を進めている企業では、特に注意すべき点です。Key Vault全体方針はRBACでも、Azure Firewall Premium TLS検査用証明書については公式仕様に合わせた例外設計が必要になる可能性があります。
図4：Key VaultとAzure Firewallの関係
Azure Firewall Premium
│
│ Managed Identity
▼
Azure Key Vault
│
├─ Secret: 中間CA PFX
│
└─ Certificate: 管理・期限通知用6. IDPSは「検知」と「遮断」の責任分界を分ける
IDPSには、検知だけでなく、遮断も関係します。Microsoft公式情報では、IDPSシグネチャのモードとして「無効」「アラート」「アラートと拒否」があり、疑わしいトラフィックに対してアラートのみ出すか、アラートとブロックを行うかを設定できます。
さらに、IDPSがAlertモードの場合はルール処理ロジックと並行してアラートを生成し、Alert and Denyモードではルール処理後にインラインで動作して一致フローをブロックし得ると説明されています。IDPSによるセッションドロップはTCPレベルでRSTを送らないサイレントドロップである点も、障害切り分け上重要です。確認日：2026年7月8日、Microsoft Learn最終更新：2026年4月2日。
表3：IDPSモードと運用責任
IDPSモード | 技術動作 | 運用上の責任 |
無効 | 検知しない | 無効にする理由、リスク受容、承認記録が必要 |
Alert | 検知・ログ記録 | SOCが見て、調査し、対応判断する責任 |
Alert and Deny | 検知・遮断 | 業務影響、誤検知、緊急例外、切戻し責任が発生 |
7. IDPSシグネチャはMicrosoft管理、運用判断は利用企業側
Azure Firewall PremiumのIDPSはシグネチャベースです。Microsoft公式情報では、IDPSシグネチャは完全管理・継続更新され、67,000を超えるルール、50を超えるカテゴリ、毎日20〜40以上の新しいルールがリリースされると説明されています。
ただし、これは「自社で何もしなくてよい」という意味ではありません。Microsoftはシグネチャを管理しますが、どのモードで運用するか、どの通信を除外するか、誤検知時にどう対応するか、業務影響を誰が判断するかは利用企業側の責任です。
図5：責任分界
Microsoft側
────────────────────
IDPSシグネチャ提供
シグネチャ更新
Azure Firewallサービス運用
利用企業側
────────────────────
IDPSモード選定
TLS検査対象選定
証明書管理
ログ監視
アラート対応
例外承認
業務影響判断
監査証跡保存8. 誰が運用責任を持つべきか
結論：単独部署ではなくRACIで分ける
Azure Firewall PremiumのTLS検査・IDPSは、ネットワーク、セキュリティ、PKI、業務システム、監査、経営判断が交差します。したがって「ネットワーク担当だけ」「SOCだけ」では足りません。
NIST SP 800-61 Rev.3は、インシデント対応がサイバーリスク管理の重要部分であり、組織運用全体に統合すべきものと説明しています。また、インシデント対応に関するすべての役割と責任は組織のポリシーに文書化すべきとしています。確認日：2026年7月8日、NIST SP 800-61 Rev.3公開：2025年4月。
表4：RACI表
業務 | 経営層 | CISO/情報セキュリティ責任者 | クラウド基盤 | ネットワーク | SOC/CSIRT | システムオーナー | 監査/法務・規程 |
TLS検査方針決定 | A | R | C | C | C | C | C |
TLS検査対象設計 | I | A | R | R | C | C | C |
CA証明書管理 | I | A | R | C | C | I | C |
IDPSモード選定 | I | A | C | R | R | C | C |
Alert監視 | I | C | C | C | R | I | I |
Alert and Deny切替 | I | A | C | R | R | C | C |
誤検知対応 | I | A | C | R | R | R | C |
例外承認 | I | A | C | C | R | C | C |
インシデント対応 | I/A | A | C | C | R | R | C |
監査証跡保管 | I | A | C | C | R | I | R |
経営報告 | A | R | I | I | C | C | C |
R：実行責任、A：説明責任、C：相談先、I：共有先
9. 「検知しただけ」で終わる典型的な失敗
表5：失敗パターンと対策
失敗パターン | 状態 | 対策 |
IDPS Alertだけ有効 | アラートは出るが誰も見ない | SOC担当、確認頻度、チケット化を規程化 |
Alert and Denyを急に有効 | 正常通信が止まる | 検証、例外、切戻し、業務承認を必須化 |
TLS検査対象が曖昧 | 復号対象が説明できない | 対象カテゴリ、通信方向、除外理由を台帳化 |
証明書期限管理なし | TLS検査停止、通信障害 | CA期限監視、更新手順、Key Vault台帳 |
例外が口頭承認 | 監査で説明不能 | 例外申請、期限、承認者、再評価日を記録 |
ログ未保存 | 事故後に調査不能 | 診断設定、Log Analytics、Sentinel連携 |
業務部門不在 | ブロック影響を判断できない | システムオーナーをRACIに入れる |
10. TLS検査の例外管理
TLS検査は強力ですが、すべての通信を機械的に復号すべきではありません。Microsoft公式情報では、従業員の健康データなど特定のWebトラフィックについて、プライバシーとコンプライアンス上の理由によりTLS終端を使用して復号できない場合があると説明され、Education、Finance、Government、Health and MedicineのカテゴリではTLS終端がサポートされないと記載されています。
個別の法的評価は、対象業務、利用者、国・地域、社内規程、契約条件によって異なるため、本記事だけでは確認できません。実務上は、TLS検査対象と除外対象を明文化し、例外理由・期限・承認者・再評価日を残す必要があります。
表6：TLS検査例外台帳
項目 | 記入例 |
例外番号 | TLS-EX-2026-001 |
対象FQDN/URL | |
通信方向 | Outbound |
例外理由 | 個人の健康関連情報を含む可能性があるため |
業務影響 | 復号すると業務・プライバシー上の問題が生じ得る |
代替策 | DNSログ、Threat Intelligence、Endpoint側監視 |
承認者 | 情報セキュリティ責任者 |
期限 | 2026-12-31 |
再評価日 | 2026-10-01 |
証跡 | 申請書、Firewall Policy変更履歴、承認ログ |
11. IDPS例外管理
IDPSでは、誤検知や業務影響への対応が必要です。Microsoft公式情報では、IDPSバイパスリストにより特定のIPアドレス、範囲、サブネットをフィルター処理から除外でき、シグネチャ規則についても最大10,000個までカスタマイズし、無効、アラート、アラートと拒否へ変更できます。
図6：IDPS例外判断フロー
IDPSアラート発生
│
▼
真陽性か誤検知か一次判定
│
├─ 真陽性
│ ├─ 通信遮断
│ ├─ 端末・サーバ調査
│ ├─ Sentinel Incident化
│ └─ 再発防止
│
└─ 誤検知の可能性
├─ 業務影響確認
├─ シグネチャID確認
├─ 一時例外申請
├─ 承認
└─ 期限付き見直し表7：IDPS例外台帳
項目 | 記入例 |
例外番号 | IDPS-EX-2026-003 |
Signature ID | 123456 |
Severity | High / Medium / Low |
対象通信 | AppSubnet → DBSubnet |
例外種別 | Signature override / Bypass list |
理由 | 業務アプリの正当通信が誤検知されるため |
影響 | Alert and Denyでは業務停止 |
代替策 | Appログ監視、EDR監視、通信先固定化 |
承認者 | CISO、システムオーナー |
期限 | 30日 |
再評価 | ベンダー修正版適用後 |
証跡 | KQL結果、チケット、承認記録 |
12. ログを取らなければ、検知は運用にならない
Azure Firewallのリソースログは自動生成されますが、保存・クエリするには診断設定でAzure Monitorログ等へルーティングする必要があります。Microsoft公式情報では、リソースログは診断設定を作成して1つ以上の場所へルーティングするまで収集・保存されないと説明されています。
また、Azure Firewallの構造化ログは、送信元・宛先IP、プロトコル、ポート、Firewallのアクション、イベント時刻、Firewallインスタンス名など、分析しやすい形式のログを提供します。構造化ログを有効にするにはLog Analyticsワークスペースを構成し、診断設定でリソース固有テーブルを選択します。
表8：保存すべきログ
ログ | 用途 | 保存先例 |
AZFWApplicationRule | アプリケーションルール許可・拒否 | Log Analytics |
AZFWNetworkRule | ネットワークルール許可・拒否 | Log Analytics |
AZFWIdpsSignature | IDPSシグネチャ一致 | Log Analytics / Sentinel |
AZFWThreatIntel | Threat Intelligence検知 | Log Analytics / Sentinel |
AZFWDnsQuery | DNS Proxy確認 | Log Analytics |
AzureActivity | Firewall Policy変更、設定変更 | Log Analytics / Storage |
AzureMetrics | Firewall正常性、SNAT、処理量等 | Azure Monitor |
Azure Firewall監視データリファレンスでは、関連するLog Analyticsテーブルとして、AZFWNetworkRule、AZFWApplicationRule、AZFWThreatIntel、AZFWIdpsSignature、AZFWDnsQuery、AzureActivity、AzureMetrics、AzureDiagnostics等が示されています。確認日：2026年7月8日、Microsoft Learn最終更新：2026年6月16日。
13. Sentinelで「担当者」と「記録」を持たせる
Microsoft Sentinelは、脅威の検出、調査、対応、プロアクティブハンティングを支援するクラウドネイティブSIEMとして説明されています。また、Microsoft Sentinelは分析ルールによりアラートをインシデントへグループ化し、プレイブックにより対応を自動化・調整できます。確認日：2026年7月8日、Microsoft Learn最終更新：2026年4月23日。
Microsoft Sentinelのインシデントは、特定の調査に関連する証拠を集約したファイルであり、重大度、状態、MITRE ATT&CKの戦術・手法等のプロパティを持つと説明されています。さらに、インシデントには所有者を割り当て、タスクやアクティビティログ、コメントで対応記録を残せます。
図7：Azure FirewallからSentinelまでの流れ
Azure Firewall Premium
│
├─ TLS検査
├─ IDPS検知
└─ Firewall Logs
│
▼
Log Analytics
│
▼
Microsoft Sentinel
│
├─ Analytics Rule
├─ Incident作成
├─ Owner割当
├─ Task管理
├─ Comment記録
└─ Playbook実行14. KQL例：IDPS検知状況の確認
Azure Monitor LogsのAZFWIdpsSignatureテーブルは、1つ以上のIDPSシグネチャに一致したデータプレーンパケットを含むテーブルです。列にはAction、Category、Description、DestinationIp、DestinationPort、Protocol、Severity、SignatureId、SourceIp、SourcePort、TimeGenerated等があります。確認日：2026年7月8日、Microsoft Learn最終更新：2026年3月11日。
AZFWIdpsSignature
| where TimeGenerated > ago(24h)
| summarize
Hits = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by Severity, Action, SignatureId, Description, SourceIp, DestinationIp, DestinationPort, Protocol
| order by Severity asc, Hits descKQL例：重大度別の推移
AZFWIdpsSignature
| where TimeGenerated > ago(7d)
| summarize Hits = count() by Severity, bin(TimeGenerated, 1h)
| order by TimeGenerated descKQL例：特定システムから外部へのIDPS検知
AZFWIdpsSignature
| where TimeGenerated > ago(24h)
| where SourceIp startswith "10.10."
| project TimeGenerated, Severity, Action, SignatureId, Description,
SourceIp, SourcePort, DestinationIp, DestinationPort, Protocol
| order by TimeGenerated desc15. アラート重大度と初動SLA
表9：初動SLA例
条件 | 初動目標 | 担当 | 初動内容 |
Severity High + Action Deny | 15分以内 | SOC/CSIRT | 通信元特定、業務影響確認 |
Severity High + Action Alert | 30分以内 | SOC/CSIRT | 真陽性判定、遮断要否判断 |
Mediumの同一Signature多発 | 2時間以内 | SOC | 傾向分析、誤検知確認 |
Low大量発生 | 翌営業日 | SOC | チューニング候補化 |
業務停止を伴うDeny | 即時 | ネットワーク＋システムオーナー | 切戻し、例外、報告 |
外部通信先がIOC疑い | 30分以内 | CSIRT | 端末隔離、EDR確認、Sentinel Incident化 |
Microsoft公式のAzure FirewallとSentinel連携例では、Firewallログ中の既知IOCに関連する通信検出時に、セキュリティチームがSentinelアラートを受信でき、真陽性はIOCとして扱い、インシデント対応チームが応答を開始して修復アクションを実装できると説明されています。
16. 変更管理：Firewall Policyは誰が変えるのか
Azure Firewall Policyは、Azure Firewallの推奨構成方法であり、複数のFirewallインスタンスに関連付け可能なグローバルリソースです。Microsoft公式情報では、Firewall PolicyにはNAT、Network、Applicationルール、Threat Intelligence、IDPS、TLS Inspection、Web Categories、URL Filtering等を含められると説明されています。確認日：2026年7月8日、Microsoft Learn最終更新：2025年7月9日。
表10：Firewall Policy変更管理台帳
項目 | 記入例 |
変更番号 | FW-CHG-2026-001 |
対象Policy | fwpol-prod-hub |
変更種別 | TLS検査対象追加 / IDPSモード変更 / 例外追加 |
変更理由 | 新規業務通信の保護強化 |
影響範囲 | AppSubnet、VDI、業務API |
旧設定 | IDPS Alert |
新設定 | IDPS Alert and Deny |
検証結果 | 検証環境で通信確認済み |
切戻し方法 | 旧Policyバージョンへ戻す |
承認者 | CISO、ネットワーク責任者、システムオーナー |
実施者 | ネットワーク担当 |
実施日時 | 2026-07-15 22:00 |
証跡 | PR、Activity Log、KQL、チケット |
17. セキュリティ運用体制の全体図
図8：運用体制モデル
経営層
│
│ リスク受容・重大判断
▼
┌────────────────────────┐
│ 情報セキュリティ責任者 / CISO │
│ 方針・例外承認・経営報告 │
└───────────┬────────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
SOC / CSIRT クラウド基盤 ネットワーク
検知・初動 Key Vault等 Firewall Policy
Sentinel 証明書管理 TLS/IDPS設定
│ │ │
└───────────┼───────────┘
▼
システムオーナー
業務影響判断
切戻し判断
│
▼
監査・規程担当
証跡・規程・台帳18. セキュリティ運用規程に入れるべき項目
表11：規程項目
規程項目 | 記載内容 |
目的 | Azure Firewall Premiumによる通信保護、検知、対応、証跡管理 |
適用範囲 | Hub VNet、Spoke VNet、オンプレミス接続、送信通信、East-West通信 |
TLS検査方針 | 対象、除外、証明書、プライバシー配慮、例外 |
IDPS方針 | Alert / Alert and Denyの基準、署名オーバーライド |
監視体制 | SOC、当番、確認頻度、重大度別初動SLA |
インシデント対応 | Sentinel Incident、チケット、連絡経路 |
例外管理 | TLS除外、IDPSバイパス、署名無効化、期限 |
変更管理 | Firewall Policy変更、承認、PR、切戻し |
証跡管理 | Azure Monitor、Log Analytics、Sentinel、Storage保存 |
定期レビュー | 月次アラート分析、四半期例外棚卸し、年次規程見直し |
教育 | 運用担当、システムオーナー、経営層向け説明 |
外部委託 | MSSP、SOC委託先、責任分界、報告様式 |
規程文サンプル
第○条（Azure Firewall Premium TLS検査およびIDPSの運用）
1. 本番環境におけるAzure Firewall PremiumのTLS検査およびIDPSは、
情報セキュリティ責任者の承認に基づき有効化する。
2. TLS検査の対象通信、除外通信、証明書管理、クライアント信頼設定、
Key Vault管理、期限管理については、別途定めるTLS検査運用台帳に記録する。
3. IDPSは、検証環境での確認後、本番環境においてAlertまたはAlert and Denyの
いずれかのモードで運用する。Alert and Denyへ変更する場合は、
業務影響、誤検知、切戻し手順を確認し、変更管理手続を経る。
4. IDPSアラートは、SOCまたは指定された運用担当者が確認し、重大度、通信元、
通信先、Signature ID、Action、業務影響を確認したうえで、必要に応じて
Microsoft Sentinelインシデントまたはチケットとして管理する。
5. TLS検査除外、IDPSバイパス、署名無効化等の例外は、理由、対象、期限、
代替策、承認者、再評価日を明記し、期限付きで管理する。
6. すべてのFirewall Policy変更、例外承認、インシデント対応、切戻し、
事後レビューは証跡として保存し、監査時に提示できる状態を維持する。19. 初動対応Runbook
図9：IDPSアラート初動フロー
IDPSアラート発生
│
▼
重大度・Action確認
│
▼
通信元・通信先・Signature ID確認
│
▼
業務システム特定
│
▼
真陽性 / 誤検知 / 保留を判定
│
├─ 真陽性
│ ├─ Sentinel Incident化
│ ├─ 端末・サーバ調査
│ ├─ 通信遮断確認
│ ├─ 経営/関係者報告
│ └─ 再発防止
│
├─ 誤検知
│ ├─ 業務影響確認
│ ├─ 一時例外申請
│ ├─ 承認
│ └─ 期限付き再評価
│
└─ 保留
├─ 追加ログ収集
├─ EDR/Sentinel相関
└─ 再判定20. 月次レビューで見るべき指標
表12：月次セキュリティ運用レビュー
指標 | 見る理由 | 主担当 |
IDPSアラート件数 | 攻撃傾向・誤検知傾向確認 | SOC |
Alert and Deny件数 | 遮断実績・業務影響確認 | SOC/ネットワーク |
Signature ID上位 | チューニング対象特定 | SOC |
Source IP上位 | 感染端末・不審サーバ特定 | CSIRT |
Destination上位 | C2、マルウェア通信疑い確認 | SOC |
例外件数 | 例外肥大化の防止 | CISO |
期限切れ例外 | 放置リスクの防止 | 監査/情シス |
TLS検査失敗 | 証明書・クライアント設定確認 | クラウド基盤 |
Firewall Policy変更件数 | 変更統制確認 | ネットワーク |
Sentinel Incident未処理 | 対応遅延確認 | SOC責任者 |
21. 監査で問われる質問
表13：監査質問と準備資料
監査質問 | 準備資料 |
TLS検査の対象は何ですか | TLS検査対象台帳 |
TLS検査の除外理由は何ですか | 例外台帳、承認記録 |
IDPSはAlertですか、Alert and Denyですか | Firewall Policy設定、設計書 |
誰がアラートを見ていますか | 監視体制表、当番表 |
検知後の対応記録はありますか | Sentinel Incident、チケット |
誤検知時の承認手順はありますか | IDPS例外管理規程 |
Firewall Policy変更は承認されていますか | PR、変更申請、Activity Log |
証明書期限切れ対策はありますか | CA証明書台帳、期限通知 |
ログ保存期間は何日ですか | Log Analytics / Storage保存設定 |
経営層へ報告する基準はありますか | 重大インシデント報告基準 |
NIST SP 800-92は、組織全体で有効なログ管理を開発・実装・維持するための実務的ガイダンスを提供する文書であり、ログ管理インフラ、ログ管理プロセス、監査・説明の重要性を扱っています。確認日：2026年7月8日、公開：2006年9月。
22. 経営層向け説明
図10：経営層向けの説明図
Azure Firewall Premium
│
├─ TLS検査
│ 暗号化通信の中に潜む脅威を見える化
│
└─ IDPS
攻撃パターンを検知・必要に応じて遮断
│
▼
ただし、検知後の判断は人と規程が必要
│
▼
担当者・例外・記録・報告基準を文書化経営層に伝えるべき要点
要点 | 説明 |
TLS検査は強力だが慎重な運用が必要 | 暗号化通信を復号して検査するため、対象・除外・社内説明が重要 |
IDPSは検知だけでは意味がない | 対応者、初動SLA、ブロック判断、記録が必要 |
自動遮断は業務停止リスクもある | Alert and Denyは検証と切戻し手順が前提 |
例外は放置してはいけない | 期限、承認者、代替策、再評価が必要 |
証跡が監査と事故対応を支える | Sentinel、Log Analytics、Activity Log、変更申請を紐付ける |
23. 山崎行政書士事務所としての支援領域
Azure Firewall PremiumのTLS検査・IDPSは、単なるネットワーク機能ではありません。企業のセキュリティ運用、監査対応、変更管理、例外管理、規程整備、経営説明に直結するクラウドガバナンス領域です。
山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。
表14：支援できる内容
領域 | 支援内容 |
Azure技術支援 | Azure Firewall Premium、TLS検査、IDPS、Firewall Policy設計 |
証明書管理 | Key Vault、Managed Identity、CA証明書台帳、期限管理 |
監視設計 | Azure Monitor、Log Analytics、Microsoft Sentinel連携 |
SOC運用設計 | アラート分類、初動SLA、Runbook、チケット連携 |
例外管理 | TLS検査除外、IDPSバイパス、署名オーバーライド台帳 |
変更管理 | Firewall Policy変更申請、承認証跡、切戻し手順 |
規程整備 | セキュリティ運用規程、ログ管理規程、例外管理規程 |
監査対応 | 証跡一覧、責任分界、経営層向け説明資料 |
契約・委託管理 | SOC委託、MSSP、責任分界、報告様式整理 |
行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。
まとめ
Azure Firewall PremiumのTLS検査・IDPSは、企業のクラウド防御を強化する重要機能です。しかし、検知しただけでは意味がありません。
重要なのは、次の状態を作ることです。
必要な状態 | 内容 |
誰が見るか | SOC、情シス、CSIRTの役割明確化 |
誰が止めるか | Alert and Deny、遮断判断者の明確化 |
誰が例外を認めるか | CISO、システムオーナー、監査担当の承認 |
誰が記録するか | Sentinel、チケット、Activity Log、変更申請 |
誰が経営へ説明するか | 情報セキュリティ責任者、経営層報告基準 |
TLS検査・IDPSは、技術設定だけでは完成しません。対応者、例外、記録、承認、経営報告まで含めて、初めてセキュリティ運用になります。
Azure Firewall PremiumのTLS検査・IDPS設計、セキュリティ運用体制、例外管理、監査対応資料、運用規程整備は、山崎行政書士事務所へご相談ください。
出典・確認日
確認日：2026年7月8日
出典 | 確認した主な内容 | 最終更新・公開日 |
Microsoft Learn：Azure Firewall Premium機能の実装ガイド | TLS検査、IDPS、URLフィルタリング、Webカテゴリ、IDPSシグネチャ、TLS検査対象 | 2025年9月18日 |
Microsoft Learn：Azure Firewall Premium certificates | TLS検査用中間CA証明書、Key Vault、Managed Identity、証明書要件 | 2026年3月24日 |
Microsoft Learn：Azure Firewall rule processing logic | IDPS Alert / Alert and Denyの動作、サイレントドロップ、TLS検査有効時の処理 | 2026年4月2日 |
Microsoft Learn：Azure Firewallの監視 | リソースログ、診断設定、構造化ログ、Azure Monitor連携 | 2026年3月28日 |
Microsoft Learn：Azure Firewall monitoring data reference | AZFWIdpsSignature等のLog Analyticsテーブル | 2026年6月16日 |
Microsoft Learn：AZFWIdpsSignature table | IDPSシグネチャ一致ログの列情報 | 2026年3月11日 |
Microsoft Learn：Microsoft Sentinel概要 | SIEM、検出、調査、対応、プレイブック | 2026年4月23日 |
Microsoft Learn：Microsoft Sentinelインシデント調査 | インシデント、所有者、タスク、アクティビティログ、コメント | 2026年4月23日 |
NIST SP 800-61 Rev.3 | インシデント対応、役割・責任の文書化、CSF 2.0に基づく対応 | 2025年4月 |
NIST SP 800-92 | セキュリティログ管理、ログ管理体制、ログ管理プロセス | 2006年9月 |
コメント