Zero Trust Networking on Azureを理解するための前提
Zero Trustは「社内VNetだからtrusted」とする境界モデルではなく、identity・device・application・network signalを使って継続的に明示検証する考え方。 networkではVNet/subnet segmentation、NSG/ASG、central Firewall/WAF、Private Link等を使いblast radiusとpublic exposureを減らす。
MicrosoftのAzure segmentation guidanceはsingle VNet内segmentation、VNet peering、hub-spoke境界を段階的に扱う。 NSGやFirewallはidentity/authorizationの代替ではない。Entra ID/RBAC、managed identity、application auth、secret/certificate controlと併用する。
egressもimplicit trustにせず、explicit outbound、FQDN/app policy、DNS、loggingで「どこへ出られるか」をcontract化する。 Assume breachではeast-west visibility、least privilege rule、private endpoint、central logging、incident isolationを平常時から用意する。
Control plane と data plane
仕組み
user/workload identityがapplication accessを開始する。
DNS/private endpoint/public endpoint selectionでdestination pathを決める。
subnet/NIC NSG・Firewall/WAFがleast-privilege network policyを適用する。
destination serviceがEntra/RBAC/app auth等でidentityを明示検証する。
logs/signalsをcentralizeし、anomaly/incident時にsegment isolationやcredential revocationを実行する。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- network trust zoneをdiagramとtraffic matrixで明示する。
- public IPをinventoryし、不要なpublic endpointをPrivate Link/service private accessへ移す。
- east-westもASG/NSG/Firewallで必要serviceだけ許可する。
- egress allowlistとDNS pathを定義し、unknown destinationを観測/denyする。
- security evidenceをSIEMへ集約し、rule/policy driftを継続監査する。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Verify explicitly | network locationだけでなくidentity/application signalでauthorization。 | VNet内=trustedをやめる。 |
| Least privilege | source role→destination role→service port/FQDNを最小化。 | compromise後のlateral movementを制限。 |
| Assume breach | segment、telemetry、isolation runbookを先に作る。 | 侵入後のblast radiusとMTTRを下げる。 |
| Private access | Private Endpoint等でpublic exposureを減らす。 | ただしDNS/authorization/policyを別途維持。 |
確認手順
Azure Portal / Network Watcher
- Architecture diagramでInternet/on-prem/global Azure/hub/spoke/PaaS boundaryを確認。
- NSG Effective security rulesとFirewall Policyでleast-privilegeが実効化されているか確認。
- Public IP / Public Network Access / Private Endpoint inventoryを定期監査。
- SIEM/Log Analyticsでeast-west/egress/deny eventを確認。
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 vnet list -o table
az network nsg list -o table
az network firewall list -o table
az network private-endpoint list -o table
az network public-ip list -o tableGet-AzVirtualNetwork
Get-AzNetworkSecurityGroup
Get-AzFirewall
Get-AzPrivateEndpoint
Get-AzPublicIpAddress障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| VNet内は全部Allow | perimeter trust model | NSG default/effective rules | tier/role単位segmentationを導入 |
| Private Endpoint化したのにdata leak懸念 | public access残存/identity auth不足/DNS誤設定 | service public network access + DNS + RBAC | private pathとauthorizationを両方確認 |
| central Firewallを迂回 | route/peering/Internet direct path | effective routes + public IP inventory | egress pathをexplicit化 |
| policyは厳しいが運用不能 | owner/exception/telemetry不足 | deny logsとticket history | 期限付きexceptionとobservabilityを整備 |
変更時の確認と rollback
- Zero Trust強化のrollbackで広いtrustへ戻す場合はtemporary exceptionとしてowner/expiryを必須にする。
- segmentation changeはpositive/negative testをセットにし、rollback後も公開範囲が意図以上に広がっていないか確認する。