Azure Firewall Premium TLS Inspectionを理解するための前提
TLS inspectionはAzure Firewall Premiumがoutbound/east-west TLS connectionを終端し、inspection後に再暗号化する機能。 Firewallはclient側とserver側の2つのTLS connectionを作るため、clientはFirewallが動的に生成するcertificate chainをtrustする必要がある。
productionではcorporate PKIのintermediate CAを用意し、current Microsoft Learnのcertificate requirementsに従ってAzure Key Vaultへ格納する。 FirewallがKey Vault secretへaccessするmanaged identity/permissionと、certificate rotation手順を運用contractにする。
certificate pinning、mutual TLS、独自trust storeを使うapplicationはinspectionでbreakし得るため、事前inventoryとexception設計が必要。 TLS inspectionによりPremium IDPS、URL filtering、Web Categories等がencrypted trafficへより深いvisibilityを持てる。
Control plane と data plane
仕組み
clientがHTTPS destinationへ接続し、trafficがFirewallへrouteされる。
FirewallがserverとTLSを確立しserver certificateを検証する。
Firewallがclient側TLSをenterprise intermediate CAで動的署名したcertificateで終端する。
plaintextをApplication rule/URL filtering/IDPSでinspectionする。
許可trafficをserver側TLSへ再暗号化し、logsへinspection evidenceを残す。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- CA private key lifecycleをsecurity team ownershipにする。
- Root/intermediate trustをmanaged endpointへ先行配布してからinspectionを有効化する。
- pinning/mTLS/non-browser clientをinventoryし、必要最小限のexceptionを設計する。
- Key Vault access/rotationを定期testする。
- 性能testはTLS+IDPS production modeで実施する。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| PKI | corporate PKI intermediate CA + Key Vaultをproduction標準にする。 | self-signed auto-generationはtest用途へ限定。 |
| Trust rollout | client trust配布をfeature enableより先に行う。 | certificate warning/全HTTPS停止を防ぐ。 |
| Exceptions | application ownerとexpiryを持つ。 | permanent broad bypassを防ぐ。 |
| Rotation | 新certificate import後にPolicy TLS setting更新まで検証。 | Key Vault更新だけで自動切替と仮定しない。 |
確認手順
Azure Portal / Network Watcher
- Firewall Policy → TLS inspectionでEnabled/CA certificateを確認。
- Key Vaultで対応secretとmanaged identity accessを確認。
- test clientでcertificate issuer/chainを確認し、Firewall logs/IDPS logsと相関。
- pinning/mTLS applicationを別test setで確認。
Verification discipline
- subscription / resource group / resource ID / NIC / direction / 5-tupleを記録する。
- 同じ条件でbefore/afterを比較し、既存sessionとnew connectionを区別する。
- configuration、effective state、logs、application resultを別々の証拠として残す。
- 変更成功はcontrol-plane Succeededではなくobservable data-plane behaviorで判定する。
az network firewall policy show -g <rg> -n <policy> -o jsonc
az keyvault secret show --vault-name <kv> -n <ca-secret> --query "{id:id,attributes:attributes}" -o jsoncGet-AzFirewallPolicy -ResourceGroupName <rg> -Name <policy>
Get-AzKeyVaultSecret -VaultName <kv> -Name <ca-secret>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 全HTTPSでcertificate error | client trust未配布/誤CA | client certificate chain + Policy CA | trust chain/Policy referenceを修正 |
| 一部appだけ失敗 | certificate pinning/mTLS/custom trust store | app logs/TLS handshake | 対象をexceptionまたはapp側対応 |
| certificate rotation後に失敗 | Policyが旧Key Vault secret/version参照 | Policy TLS settingとsecret ID | 新certificateを明示反映 |
| 性能低下 | TLS+IDPS負荷 | Firewall metrics/performance test | capacity/SKU/rule scopeを見直す |
変更時の確認と rollback
- 旧CA secret/versionとPolicy referenceを保持し、rotation rollback pathを事前に作る。
- emergency exceptionはscope/expiryを限定し、TLS inspection全停止を最終手段にする。
- rollback後にclient chainとreal HTTPS journeyを再試験する。