クラウドの侵害調査で「このグローバルIPは、当時うちのAzure環境に割り当てられていたのか？」を確認できないと、露出範囲の見積もり、インシデント対応、フォレンジックの精度が一気に落ちます。結論から言うと、Azure Public IPは削除後に実IPアドレスをAPIで取り戻せない前提で、削除前からResource IDとIPアドレスの対応表を保存しておく必要があります。Microsoftは2026年4月17日付のTech Community記事で、Azure Activity Logs、Log Analyticsアラート、Azure Automation、永続キャッシュを組み合わせて、削除済みPublic IPの証跡を保持する実装パターンを紹介しました。(TECHCOMMUNITY.MICROSOFT.COM)
Azure Activity Logs / Azure Public IPの最新動向：削除済みPublic IPの対応関係を残す理由
Azure Public IPは、VM、Load Balancer、Application Gateway、Azure Firewall、VPN Gatewayなど、インターネット到達性に関わるリソースで使われます。Microsoft Learnでは、Public IPはAzureリソースへのインバウンド通信や、予測可能なアウトバウンド通信を可能にするものとして説明されています。(Microsoft Learn)
問題は、Public IPリソースを削除した後です。
Azure Activity Logsには、Public IPの作成や削除といったライフサイクル操作が記録されます。しかし、Microsoftが2026年4月17日に公開した記事によると、Microsoft.Network/publicIPAddresses/delete の削除イベントには対象リソースのResource IDは含まれるものの、実際に割り当てられていたIPアドレスは含まれません。さらに削除完了後はPublic IPリソース自体が存在しないため、Resource IDを解決してIPアドレスを取得することもできません。(TECHCOMMUNITY.MICROSOFT.COM)
つまり、削除後にActivity Logsだけを見ても、次のような問いに答えられない可能性があります。
- このPublic IPはどのサブスクリプション、リソースグループ、ワークロードに紐づいていたのか
- このIPアドレスは、特定の攻撃通信が観測された時刻に自社管理下だったのか
- 脆弱なサービスが外部公開されていた期間はいつからいつまでか
- 脅威インテリジェンスで検知されたIPは、すでに解放済みで別テナントに再利用されていないか
このギャップを埋めるのが、削除前にPublic IPの最終状態を保存する仕組みです。
なぜ削除済みPublic IPの証跡がセキュリティ調査で重要なのか
削除済みPublic IPの対応関係は、単なる資産管理の補助情報ではありません。クラウドセキュリティの現場では、調査結果の正確性を左右する証拠になります。
露出調査では「過去に外部公開されていた対象」を特定する必要がある
脆弱性対応や外部露出レビューでは、現在のAzure Portalに表示されるPublic IP一覧だけでは不十分です。
たとえば、次のようなケースです。
| 調査シーン | Public IP対応表がない場合の問題 | 残すべき情報 |
|---|---|---|
| 脆弱な管理画面が公開されていた | 削除済みリソースが一覧に出ず、露出期間を過小評価する | IPアドレス、Resource ID、作成・削除時刻、関連リソース |
| WAFやNSG設定漏れを調べる | すでに削除された検証環境を見落とす | Public IP名、リソースグループ、タグ、所有チーム |
| 外部スキャン結果とAzure資産を照合する | スキャン時点の所有関係を説明できない | スキャン時刻に有効だったIPマッピング |
| 監査で公開範囲を提示する | 「今は存在しないため不明」という説明になる | 変更履歴と保持された証跡 |
特にCI/CD、検証環境、自動スケール、機械学習基盤のように、短時間でリソースが作成・削除される環境では、手動の棚卸しでは追いつきません。Microsoftの記事でも、Azure Machine Learning、CI/CDパイプライン、オートスケール構成のような高頻度に変化するワークロードでは、手動でPublic IPライフサイクルを追跡するのは現実的ではないと説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
インシデント対応では「そのIPは当時、自社のものだったか」が最初の分岐になる
インシデント対応では、IPアドレスの所有関係を誤ると調査全体がずれます。
たとえば、脅威インテリジェンスやSIEMで「あるPublic IPが不審通信元として検知された」とします。このとき確認すべきなのは、現在そのIPが自社環境に存在するかだけではありません。
重要なのは、検知時刻にそのIPが自社のAzureリソースに割り当てられていたかです。
AzureのPublic IPは、削除や解放後に再利用される可能性があります。Microsoftの記事では、削除済みIPを社内所有として記録し続けると、後に別テナントへ割り当てられたIPに対して誤った内部調査を行うリスクがあると述べています。(TECHCOMMUNITY.MICROSOFT.COM)
このリスクは、現場では次のような形で現れます。
| 判断ミス | 起こり得る影響 |
|---|---|
| 解放済みIPを自社所有と誤認する | 関係ない通信に対して調査工数を使う |
| 過去に所有していたIPを見落とす | 本来調べるべき侵害経路を除外してしまう |
| 所有期間を曖昧に扱う | 顧客・監査人・法務への説明が弱くなる |
| Resource IDだけを保存する | 削除後に実IPへ戻せず、証跡として使いにくい |
IPアドレスはセキュリティ調査の出発点になりやすい一方で、クラウドでは永続的な所有物とは限りません。だからこそ、IPアドレス、Resource ID、時刻、操作主体をセットで保存することが重要です。
クラウドフォレンジックでは「削除されたもの」を前提に証拠を残す
クラウドフォレンジックで難しいのは、調査対象のリソースが調査開始時点で残っているとは限らないことです。
攻撃者がリソースを削除する場合もあれば、通常の自動化処理で検証環境が消える場合もあります。削除済みPublic IPの対応表がないと、ログ上に残った通信先・通信元IPをAzure上のワークロードに結び付けられません。
Azure Activity Log自体はサブスクリプションレベルのイベントを記録しますが、既定では90日保持であり、より長期の保持や分析には診断設定でLog Analyticsなどへ送信する設計が必要です。(Microsoft Learn)
フォレンジック観点では、少なくとも次の情報を保持対象に含めるべきです。
| 項目 | 用途 |
|---|---|
| Public IPアドレス | 外部ログ、脅威インテリジェンス、通信記録との照合 |
| Resource ID | Azure上のリソース履歴との紐付け |
| サブスクリプションID | 組織・環境単位での責任範囲特定 |
| リソースグループ | アプリケーションやチーム単位の分類 |
| Public IP名 | 運用チームが認識しやすい識別子 |
| 作成・更新・削除イベント時刻 | 所有期間と露出期間の推定 |
| Caller | 誰が、またはどの自動化が操作したかの確認 |
| Allocation method | Static/Dynamicの違いによる再利用・変更リスクの評価 |
| 関連リソース | VM、NIC、Load Balancerなど実ワークロードへの接続 |
ここでのポイントは、IPアドレス単体ではなく、時点つきの対応関係として保存することです。
Microsoftが示した実装パターンの要点
Microsoftの2026年4月17日付記事では、削除イベントが発生した後にAzure APIからIPアドレスを取り戻すのではなく、Public IPが存在している間にResource IDとIPアドレスの対応を永続キャッシュへ保存しておくという考え方が示されています。実装構成は、Azure Activity Logs、Log Analyticsアラート、Azure Automation Runbook、永続的なResource ID → IPアドレスのマッピングキャッシュです。(TECHCOMMUNITY.MICROSOFT.COM)
全体像は次のとおりです。
| 構成要素 | 役割 | 実務上のポイント |
|---|---|---|
| Azure Activity Logs | Public IPの作成・削除などの操作イベントを検出 | AdministrativeカテゴリをLog Analyticsへ送る |
| Log Analytics | Activity LogをKQLで検索・アラート化 | Public IPのwrite/delete、NICやLBの関連変更を検出対象にする |
| Azure Monitor Alert | 対象イベント発生時にAction Groupを起動 | 評価間隔と検索範囲を短すぎず長すぎず設定する |
| Action Group | WebhookでRunbookを呼び出す | Common Alert Schemaを使うと後続処理を標準化しやすい |
| Azure Automation Runbook | Public IP情報を取得し、キャッシュを更新 | Managed Identityで最小権限にする |
| 永続キャッシュ | Resource IDと最終IPアドレスを保持 | Automation変数だけでなく、規模に応じて外部ストアも検討する |
Microsoftのサンプルでは、既存Public IPを初期取り込みする CacheSeedingRunbook と、ライフサイクルイベントを処理する MainLifecycleRunbook の2種類のRunbookが紹介されています。前者は現在存在するPublic IPを列挙してキャッシュを作り、後者はActivity Logアラートを受けてPublic IP作成・削除イベントを処理します。(TECHCOMMUNITY.MICROSOFT.COM)
実装前に理解すべきAzure Public IP削除時の落とし穴
削除イベントだけ見てもIPアドレスは分からない
Public IP削除時のActivity Logには、対象Public IPリソースのResource IDは残ります。しかし、Microsoftの記事で説明されているとおり、削除イベント自体には割り当て済みの実IPアドレスが含まれません。削除後はリソースが存在しないため、Resource IDを使ってARM APIからIPアドレスを引き直すこともできません。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、削除後の調査で次のような流れを期待している場合は見直しが必要です。
Activity Logで削除イベントを発見
↓
Resource IDを取得
↓
Azure APIでPublic IPリソースを参照
↓
割り当てられていたIPアドレスを取得この流れは、削除が完了していると成立しない可能性があります。正しい設計は次の形です。
Public IPが存在している間にResource IDとIPアドレスを保存
↓
削除イベントをActivity Logで検知
↓
削除イベントのResource IDをキーにキャッシュを参照
↓
削除済みPublic IPの実IPアドレスを復元的に確認ここでいう「復元」は、Azureから削除済みリソースを戻すという意味ではありません。事前に保存していた最終既知情報を参照するという意味です。
StaticでもDynamicでも「削除後に証跡が必要」な点は変わらない
Public IPにはStaticとDynamicの割り当てがあります。Microsoft Learnでは、Dynamic Public IPは関連リソースの状態によってアドレスが変わる可能性があり、Static Public IPはPublic IPリソースが削除されるまで解放されないと説明されています。(Microsoft Learn)
ただし、証跡管理の観点では、Staticだから安全とは言い切れません。Microsoft LearnのPublic IP削除手順では、Public IPアドレスは削除後に復旧できないと明記されています。(Microsoft Learn)
整理すると、次のように考えると実務で迷いにくくなります。
| 種別 | 注意点 | 証跡保持の考え方 |
|---|---|---|
| Static Public IP | リソース削除まではIPが維持されるが、削除後は復旧できない | 削除前のResource ID → IP対応を必ず保存する |
| Dynamic Public IP | 関連リソースの停止・解放などで変更され得る | 作成時だけでなく更新・関連付け変更も追跡する |
| Public IP Prefix由来 | Prefix内で再利用しやすいが、個別IPの利用履歴は別途必要 | Prefix単位と個別Public IP単位の両方で管理する |
| 一時的な検証用IP | 削除頻度が高く、手動棚卸しから漏れやすい | 自動収集を前提にする |
Public IPの割り当て方法だけでなく、いつ、どのリソースに、どのIPが割り当てられていたかを履歴として残すことが重要です。
推奨アーキテクチャ：Activity Logsから削除済みPublic IP証跡を残す
ここでは、Microsoftが示した考え方をベースに、実務で導入しやすい構成として整理します。
最小構成
まずは、次の構成を最小構成として考えます。
Azure Activity Logs
↓ 診断設定
Log Analytics Workspace
↓ KQLアラート
Azure Monitor Alert Rule
↓ Action Group / Webhook
Azure Automation Runbook
↓ 更新
Resource ID → Public IP の永続キャッシュAzure Activity Logは自動的に収集されますが、長期保持やKQLでの継続的な検出を行うには、診断設定でLog Analytics Workspaceなどへ送信する構成が必要です。Microsoft Learnでも、診断設定によってActivity Logをさまざまな宛先へ送信できると説明されています。(Microsoft Learn)
保存先はAutomation変数だけに限定しない
Microsoftの記事では、Automation Accountの変数 PipLastKnownIps を使って、Resource IDからIPアドレスへの対応を保持する例が紹介されています。サンプルRunbookでも、Automation変数からキャッシュを読み込み、Resource IDを正規化して保存・参照する処理が実装されています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、本番環境では規模や監査要件によって保存先を選ぶべきです。
| 保存先 | 向いているケース | 注意点 |
|---|---|---|
| Azure Automation変数 | 小規模、検証、すばやい導入 | 大量データ、検索性、変更履歴管理には不向き |
| Log Analyticsカスタムログ | SIEM連携、KQL分析、監査検索 | 取り込み形式と保持期間の設計が必要 |
| Azure Table Storage / Cosmos DB | 高頻度更新、大量Public IP、時系列履歴 | スキーマ設計とアクセス制御が必要 |
| CMDB / ITSM | 所有者、アプリ、環境情報と結び付けたい | Azureイベントとの同期遅延に注意 |
| SIEM | インシデント対応で即座に照合したい | ノイズ抑制とフィールド正規化が重要 |
小規模ならAutomation変数で始めても構いません。ただし、エンタープライズ環境では「最終値だけ」では足りないことが多いため、履歴型のストアを検討してください。
おすすめは、最終既知値を高速参照するキャッシュと、監査用の履歴ログを分ける設計です。
高速参照用：Resource ID → 最新IP
監査用 ：Resource ID、IP、操作、時刻、Caller、関連リソースを追記保存この分離により、削除イベント発生時の照合速度と、後日の説明責任を両立できます。
実装手順：削除済みPublic IPの対応表を残す流れ
Activity LogsをLog Analyticsへ送信する
最初に、Azure Activity LogsをLog Analytics Workspaceへ送信します。Microsoftの記事では、Public IPライフサイクルイベントはActivity LogのAdministrativeカテゴリで発行されるため、Azure MonitorのActivity Logから診断設定を追加し、AdministrativeカテゴリをLog Analyticsへ送る流れが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
設定の要点は次のとおりです。
| 設定項目 | 推奨内容 |
|---|---|
| 対象 | サブスクリプションのActivity Log |
| カテゴリ | Administrative |
| 宛先 | Log Analytics Workspace |
| 保持期間 | 調査・監査要件に合わせて設計 |
| 対象範囲 | 本番だけでなく検証・共有基盤サブスクリプションも含める |
Public IPは本番環境だけで使われるとは限りません。検証用サブスクリプションや一時的なPoC環境ほど、外部公開設定が緩くなりがちです。対象範囲を本番に限定しすぎると、実際の露出調査で抜けが出ます。
既存Public IPの初期キャッシュを作る
次に、すでに存在しているPublic IPを棚卸しし、Resource IDとIPアドレスの対応表を作ります。Microsoftのサンプルでは CacheSeedingRunbook がこの役割を担い、現在存在するPublic IPを列挙して PipLastKnownIps に保存する流れになっています。(TECHCOMMUNITY.MICROSOFT.COM)
初期キャッシュに含めたい項目は次のとおりです。
ResourceId
PublicIpAddress
PublicIpName
SubscriptionId
ResourceGroup
Location
AllocationMethod
Sku
AssociatedResource
Tags
CapturedAt最低限は ResourceId と PublicIpAddress ですが、実務ではこれだけだと所有者やシステム名までたどるのに時間がかかります。タグや関連リソース情報も保存しておくと、インシデント対応時の初動が速くなります。
Public IPの作成・更新・削除イベントを検出する
Log AnalyticsにActivity Logsが入ったら、KQLでPublic IP関連イベントを検出します。MicrosoftのサンプルKQLでは、Public IPのwrite/deleteに加えて、NICのIP構成変更やLoad Balancerの変更も検出対象に含めています。これは、Public IP単体の作成・削除だけでなく、関連付け変更も追跡するためです。(GitHub)
考え方としては、次の操作を監視対象にします。
| 操作 | 監視理由 |
|---|---|
| Public IP作成 | 新しい外部到達点の発生を検知する |
| Public IP更新 | IP、SKU、タグ、DNSラベルなどの変化を追跡する |
| Public IP削除 | 削除直前・削除後の証跡を確定する |
| NIC IP構成変更 | VMへのPublic IP関連付けを把握する |
| Load Balancer変更 | フロントエンドIPの変更を把握する |
| Application Gateway / Firewall関連変更 | 外部公開経路の変更を補足する |
本番導入では、Microsoftのサンプルクエリをそのまま使う前に、自社のログ形式、運用対象、関連サービスに合わせて検証してください。特に、Azureサービスの操作ログはリソース種別やAPIバージョン、操作経路によってプロパティの出方が異なる場合があります。
RunbookでIPアドレスを取得し、キャッシュを更新する
Azure Monitor AlertからAction Groupを通じてAzure Automation Runbookを呼び出し、対象Resource IDのPublic IP情報を取得します。Microsoftの MainLifecycleRunbook サンプルでは、ARMからPublic IPのスナップショット取得を試み、削除などで取得できない場合はAutomation変数に保存されたキャッシュへフォールバックする処理が含まれています。(GitHub)
Runbookの処理は、次の順序にすると分かりやすくなります。
| ステップ | 処理内容 |
|---|---|
| 1 | AlertペイロードからResource ID、操作名、時刻、Callerを取り出す |
| 2 | Resource IDを小文字化・トリムしてキーを正規化する |
| 3 | Public IPリソースがまだ存在する場合はARM APIで現在値を取得する |
| 4 | IPアドレスを取得できたらキャッシュを更新する |
| 5 | 削除イベントで現在値が取れない場合はキャッシュを参照する |
| 6 | 結果をJSON、CSV、SIEM向け形式などで出力する |
| 7 | 必要に応じてCMDB、チケット、通知へ連携する |
Resource IDの正規化は地味ですが重要です。サブスクリプションIDやリソースグループ名の大文字・小文字、余分な空白でキーがずれると、削除時にキャッシュを引けなくなります。MicrosoftのサンプルRunbookでも、Resource IDを小文字化・トリムしてキャッシュ参照する処理が含まれています。(GitHub)
KQLアラート設計で失敗しやすいポイント
検索範囲と評価間隔が噛み合っていない
アラートの評価間隔が5分なのに検索範囲が5分未満だと、ログ取り込み遅延の影響でイベントを取り逃がす可能性があります。逆に検索範囲を広げすぎると、同じイベントでRunbookが何度も動くことがあります。
最初は次のように設計すると現実的です。
| 項目 | 初期値の考え方 |
|---|---|
| 評価間隔 | 5〜10分程度から検証 |
| 検索範囲 | 評価間隔より少し長めに設定 |
| 重複排除 | Resource ID、OperationName、EventTimeで実装 |
| Runbook側の冪等性 | 同じイベントが複数回来ても同じ結果になるようにする |
MicrosoftのサンプルKQLでは recent = 10m として直近イベントを検索する例が示されています。実環境では、ログ取り込み遅延、リージョン、サブスクリプション数、アラート頻度に応じて調整してください。(GitHub)
deleteのSucceededだけを見ている
削除完了後にはPublic IPリソースが消えているため、Succeeded のタイミングだけで処理するとIPアドレスをARMから取得できないことがあります。
そのため、削除操作については、開始・受付・成功など複数フェーズを考慮し、できるだけ早い段階でキャッシュ更新またはキャッシュ参照ができるようにします。MicrosoftのサンプルKQLにも、削除フェーズの優先に関するコメントが含まれています。(GitHub)
実務では、次の方針が安全です。
作成・更新イベント：ARMから現在のIPを取得してキャッシュ更新
削除イベント ：ARM取得を試し、失敗したらキャッシュ参照
関連付け変更 ：関連リソース情報を更新Public IPリソース単体だけを見ている
外部公開の実態を把握するには、Public IPそのものだけでなく、どのリソースに関連付いていたかが重要です。
たとえば、同じPublic IPでも、次のようにリスクは変わります。
| 関連先 | 調査で見るべきポイント |
|---|---|
| VMのNIC | SSH/RDP、管理ポート、NSG設定 |
| Load Balancer | バックエンドプール、ヘルスプローブ、受信規則 |
| Application Gateway | 公開FQDN、WAFモード、リスナー |
| Azure Firewall | DNAT規則、アプリケーション規則 |
| NAT Gateway | アウトバウンド通信元としての利用 |
Public IPの対応表に関連リソースを含めると、「IPがあった」だけでなく「何が外部に出ていたか」まで追いやすくなります。
保存すべきデータモデル例
削除済みPublic IPの証跡を実務で使うなら、最終値だけではなく履歴として保存するのが理想です。次のようなデータモデルを検討してください。
| フィールド | 例 | 説明 |
|---|---|---|
resourceId | /subscriptions/.../publicIPAddresses/pip-prod-01 | 正規化したResource ID |
publicIpAddress | 203.0.113.10 | 割り当てられていたIP |
publicIpName | pip-prod-01 | Public IPリソース名 |
subscriptionId | xxxxxxxx-xxxx-... | サブスクリプション |
resourceGroup | rg-prod-network | リソースグループ |
operation | WRITE / DELETE / UPDATE | 検出した操作 |
eventTime | 2026-04-17T10:30:00Z | Activity Log上の時刻 |
capturedAt | 2026-04-17T10:31:20Z | キャッシュ保存時刻 |
caller | [email protected] / spn-... | 操作主体 |
allocationMethod | Static / Dynamic | IP割り当て方式 |
sku | Standard | Public IP SKU |
associatedResourceId | NICやLBなど | 関連リソース |
tags | owner=platform | 所有者・システム情報 |
source | ActivityLog / Runbook | 取得元 |
特に eventTime と capturedAt は分けて保存してください。eventTime はAzureでイベントが発生した時刻、capturedAt は自社の証跡基盤が記録した時刻です。フォレンジックや監査では、この違いが重要になります。
インシデント対応での使い方
削除済みPublic IP対応表は、導入して終わりではありません。インシデント対応手順に組み込むことで価値が出ます。
初動調査の確認項目
不審なIPアドレスが検知されたら、次の順に確認します。
| 確認項目 | 判断 |
|---|---|
| 現在のAzure Public IP一覧に存在するか | 現在も自社管理下かを確認 |
| 削除済みPublic IP対応表に存在するか | 過去の所有履歴を確認 |
| 検知時刻が所有期間内か | 自社調査対象か、誤検知候補かを分ける |
| 関連リソースは何か | 影響を受けたワークロードを特定 |
| Callerは誰か | 正常な自動化か、不審な操作かを確認 |
| NSG・Firewall・WAFログと一致するか | 通信実態を裏取りする |
この対応表があると、「このIPは見覚えがないが、過去に自社が使っていたかもしれない」という曖昧な状態を減らせます。
タイムライン作成に使う
フォレンジックでは、タイムラインを作る際にPublic IPの履歴が役立ちます。
09:10 Public IP作成
09:12 VM NICに関連付け
09:20 外部スキャンで管理ポート検出
09:35 不審ログイン試行
10:05 Public IP削除
10:08 Runbookが削除イベントを検知し、最終IPをキャッシュから出力このように並べると、攻撃者がリソースを削除したのか、通常のIaCパイプラインが削除したのか、どの期間に外部公開されていたのかを説明しやすくなります。
運用設計：誰が使える証跡にするか
証跡基盤は、保存するだけでは不十分です。Cloud security engineers、incident responders、Azure platform teamsがそれぞれ使える形にする必要があります。
| 利用者 | 必要な見方 | 提供方法 |
|---|---|---|
| クラウドセキュリティ担当 | 外部公開資産の履歴、所有者、リスク | ダッシュボード、定期レポート |
| インシデント対応担当 | IPアドレスから過去所有関係を即検索 | SIEM検索、IR Runbook |
| Azure基盤チーム | どの自動化がPublic IPを作成・削除したか | Activity Log連携、変更管理 |
| 監査・コンプライアンス | 証跡の保持期間、改ざん耐性、説明可能性 | エクスポート、長期保存、アクセス制御 |
重要なのは、IPアドレスをキーにして検索できることです。インシデント対応の入口は、Resource IDではなくIPアドレスであることが多いためです。
セキュリティと権限設計の注意点
Managed Identityは読み取り中心の最小権限にする
Microsoftの記事では、Automation AccountのSystem-assigned Managed Identityを有効化し、Public IPメタデータを取得するためにReader権限を割り当てる構成が紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次の原則で権限を設計します。
| 対象 | 推奨 |
|---|---|
| Public IP情報の取得 | Reader相当の読み取り権限 |
| Log Analytics参照 | 必要なWorkspaceへの読み取り権限 |
| キャッシュ更新 | 保存先に対する書き込み権限 |
| サブスクリプション範囲 | 必要最小限。ただし対象漏れに注意 |
| 人間のアクセス | セキュリティ担当・基盤担当に限定 |
RunbookがPublic IPを作成・削除できる権限を持つ必要はありません。証跡保持の仕組みに過剰な変更権限を与えると、侵害時の影響が大きくなります。
Webhook URLはシークレットとして扱う
Action GroupからRunbookを呼び出すWebhook URLは、実質的にRunbook起動用の秘密情報です。コードリポジトリ、チケット、Wikiに平文で貼らないようにしてください。
運用上は次を徹底します。
- Webhook URLをKey Vaultや安全なシークレット管理に格納する
- 有効期限を設定し、定期的にローテーションする
- Runbook側で想定外のペイロードを処理しない
- 実行ログを監視し、不自然な起動回数を検知する
証跡を守る仕組み自体が攻撃経路にならないようにすることが重要です。
よくある設計ミスと対策
| よくあるミス | 何が起きるか | 対策 |
|---|---|---|
| 削除イベントだけを保存する | IPアドレスが分からない | 作成・更新時にResource ID → IPを保存する |
| 現在のPublic IP一覧だけを棚卸しする | 削除済み資産を見落とす | 履歴テーブルを持つ |
| Resource IDの大文字小文字をそのまま扱う | キャッシュ参照に失敗する | 正規化して保存・検索する |
| 所有者タグを保存しない | インシデント時に担当チームが分からない | タグ、関連リソース、CMDB情報を結合する |
| Automation変数だけに大量履歴を詰める | 検索性・拡張性が不足する | 履歴はLog AnalyticsやDBへ保存する |
| 保持期間をActivity Log既定に任せる | 長期調査でログが足りない | 診断設定と保持ポリシーを設計する |
| アラートの重複実行を考慮しない | 同じイベントが何度も記録される | イベントIDやResource IDで冪等化する |
| 検証環境を対象外にする | 実際の露出源を見落とす | 全サブスクリプションを分類して対象化する |
既存のクラウド資産管理とどうつなぐべきか
削除済みPublic IP対応表は、単独のログとして置いておくより、既存のクラウド資産管理と連携させると効果が高まります。
Defender for CloudやCSPMとの関係
CSPMは現在の設定リスクを見つけるのに強い一方で、削除済みリソースの過去状態をどこまで保持・検索できるかは設計次第です。Public IP証跡は、CSPMの検出結果に「その外部公開がいつ存在したか」を補う役割を持ちます。
たとえば、CSPMで「NSGが広く開いていた」と検出された場合、Public IP履歴と組み合わせることで、外部から到達可能だった期間をより具体的に説明できます。
CMDBとの関係
CMDBにPublic IPの現在値だけを持たせている場合、削除後の追跡に弱くなります。CMDBには、少なくとも次の情報を同期すると実務で使いやすくなります。
- Public IPアドレス
- Resource ID
- 所有チーム
- アプリケーション名
- 環境区分
- 作成・削除時刻
- 最終確認時刻
特にグローバル企業では、サブスクリプション、リージョン、事業部、管理チームが分かれていることが多いため、IPアドレスから責任範囲へすばやく到達できる設計が必要です。
SIEMとの関係
SIEMには、Public IP対応表をルックアップテーブルとして取り込むと効果的です。
通信ログのsrc_ip / dest_ip
↓
Public IP履歴テーブルと照合
↓
検知時刻に自社所有だったか判定
↓
関連するサブスクリプション・ワークロード・所有者を付与これにより、アラートの優先度付けがしやすくなります。現在は存在しないPublic IPでも、検知時刻に自社所有だったなら調査対象です。逆に、すでに解放済みで検知時刻に所有していなかったなら、誤検知や外部要因として切り分けられます。
導入チェックリスト
実装に着手する前に、次のチェックリストで準備状況を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 対象サブスクリプションを洗い出した | 本番、検証、共有、サンドボックスを含めたか |
| Activity LogsをLog Analyticsへ送信している | Administrativeカテゴリが含まれているか |
| 既存Public IPを初期キャッシュした | 現在存在するPublic IPを取り込んだか |
| Public IPの作成・更新・削除を検出できる | KQLアラートを検証したか |
| 関連リソース変更も追跡している | NIC、Load Balancerなどを含めたか |
| Runbookの権限が最小化されている | Managed Identityに過剰権限がないか |
| Resource IDを正規化している | 大文字小文字や空白差異で失敗しないか |
| 保存先の保持期間を決めた | 監査・IR要件に合っているか |
| SIEMまたはCMDBで検索できる | IPアドレスから逆引きできるか |
| 削除テストを実施した | 実際にPublic IP作成→削除でIPが残るか |
特に最後の削除テストは必須です。設計上は正しく見えても、アラート遅延、権限不足、Runbookエラー、キャッシュ保存失敗で、実際にはIPアドレスが残っていないことがあります。
まず何から始めるべきか
最初から大規模な証跡基盤を作る必要はありません。まずは、1つのサブスクリプションで次の順に始めるのが現実的です。
1. Activity LogsをLog Analyticsへ送信する
2. 現在存在するPublic IPを一覧化する
3. Resource ID → IPアドレスの初期キャッシュを作る
4. Public IPの作成・削除アラートを設定する
5. Runbookでキャッシュ更新と削除時参照を行う
6. 作成→削除テストで証跡が残ることを確認する
7. SIEM、CMDB、運用手順へ展開する削除済みPublic IPの証跡は、平時には地味な仕組みです。しかし、侵害調査や外部露出レビューでは「当時そのIPは誰のものだったのか」を答えるための重要な根拠になります。
Azure Activity Logsには削除操作の履歴は残りますが、削除済みPublic IPの実IPアドレスまで後から取得できるとは限りません。だからこそ、Public IPが存在している間にResource IDとIPアドレスの対応を保存し、削除イベント発生時にその対応表を参照できるようにしておくことが重要です。
まずはPublic IPの現在棚卸しとActivity LogsのLog Analytics送信を確認し、次に削除イベントでIPアドレスが残るかを小さく検証してください。その結果をもとに、SIEM連携、CMDB連携、長期保持へ広げるのが、無理のない実装順序です。
コメント