Azure DDoS Protection

運用前提: Portal上のresource stateだけでなく、対象5-tupleのeffective state・route・security logs・new connectionを組み合わせてdata planeを確認します。SKU/limit/preview statusは変更されるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

Azure DDoS Protectionを理解するための前提

Azure DDoS ProtectionはLayer 3/4のnetwork attackを対象とし、Layer 7 Web attackはWAF等のapplication-layer controlが別途必要。 DDoS Network ProtectionはVNet単位、DDoS IP Protectionはprotected public IP単位の課金/適用モデル。

両tierともalways-on monitoring、adaptive real-time tuning、attack metrics/analytics等のcore engineering protectionを提供する。 Network ProtectionにはDDoS Rapid Response、cost protection、WAF discount等の付加serviceがあり、IP Protectionとの差になる。

protection enableだけで可用性設計は完了しない。autoscale、zone/region resiliency、origin capacity、WAF/rate limiting、DNS failoverを組み合わせる。 attack時に見るmetrics/log/alert、連絡先、DRR利用条件、post-attack analysisを事前runbook化する。

通信や判断の流れを追う

SourceRouteNSG / PolicyWorkloadResponse

Control plane と data plane

Control planecontrol planeではDDoS protection plan/VNet associationまたはIP Protection、diagnostic settings/alerts、public IP inventoryを管理する。

Data planedata planeではAzure edgeが常時traffic profileを観測し、resourceごとのthresholdを超えたattack trafficへmitigationを適用する。application正常性は別レイヤーで監視する。

仕組み

Internet trafficがAzure public IP endpointへ到達する。

Azure DDoS platformがtraffic profile/thresholdを常時評価する。

attack検出時にL3/L4 mitigationを自動適用する。

clean trafficがprotected resourceへforwardされる。

WAF/LB/App/Firewallが後段でL7/policy処理し、Azure Monitorへattack telemetryを出す。

Packet / decision path

障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。

全public IP inventoryを作り「保護対象/例外/owner」を明示する。
少数IPならIP Protection、多数VNet/public endpointsとDRR/cost protection要件ならNetwork Protectionを比較する。
Internet-facing WebはWAFと組み合わせてL3/4 + L7を分担する。
attack metrics/alertsをSOC/NOCへ接続し、runbook drillを行う。
originのautoscale/quota/capacityをDDoS protectionとは別に検証する。

設計判断

判断点	推奨	理由
Tier	protected IP数とvalue-added serviceでNetwork/IP Protectionを比較。	単純な単価だけでなくDRR/cost protectionを含める。
Layering	DDoS L3/L4 + WAF L7 + application rate control。	攻撃レイヤーごとにcontrolが異なる。
Telemetry	attack start/stop/mitigation metricsをalert化。	自動mitigation中もavailability判断が必要。
Runbook	contact/escalation/evidence collectionを事前定義。	攻撃中に手順を考えない。

確認手順

Azure Portal / Network Watcher

DDoS protection plan/VNetまたはPublic IPのDDoS protection設定を確認。
Azure Monitor Metricsでattack detection/mitigation metricsを確認。
Diagnostic settingsでmitigation flow/report logsの保存先を確認。
Internet endpoint health/WAF/application telemetryを同じtimelineで確認。

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で判定する。

Azure CLI — read-only first

az network ddos-protection list -o table
az network public-ip list -o table
az monitor diagnostic-settings list --resource <public-ip-resource-id> -o jsonc

PowerShell — read-only first

Get-AzDdosProtectionPlan
Get-AzPublicIpAddress

障害切り分け

症状	疑う点	証拠	次の確認
DDoS保護済みなのにHTTP 5xx	L7/origin capacity/application bottleneck	DDoS metrics + WAF/backend health	attack layerを分離
一部Public IPだけ未保護	VNet/IP association漏れ	public IP inventory	IaC/policyでcoverageをenforce
attack alertが来ない	metric alert/diagnostic routing未設定	Monitor alert rules	SOC通知経路を設定
mitigation中もresource枯渇	backend quota/autoscale不足	capacity metrics	application scaling/resiliencyを改善

変更時の確認と rollback

Protection disableはattack exposureを増やすため通常のrollback扱いにしない。設定変更を戻す場合もcoverage gapを作らない。
alert/log変更は旧通知経路を維持したまま新経路を検証して切替える。