この記事のポイント
- 台帳は hostname だけでなく管理責任者、evidence、first seen、last seen を持たせます
- 棚卸し結果と月次レビューを接続しない台帳は、すぐ陳腐化します
- ASM診断 PRO の結果を起点に更新する運用にすると、手作業の抜け漏れが減ります
まず無料で確認する
無料でASM診断を開始
外部公開資産 台帳で触れている論点は、自社ドメインを実際に診断すると優先順位が掴みやすくなります。まずは外部公開資産を無料で可視化してください。
外部公開資産台帳テンプレートが必要な理由
台帳は資産の一覧ではなく、判断と改善を進めるための管理表です。
外部公開資産は、攻撃者から見える資産の集合です。CISA は 資産台帳を基礎要件に置き、known, unknown, unmanaged assets の把握を求めています。つまり台帳は監査用の紙ではなく、外部から見える現実を継続管理するための運用基盤 です。
ただし、hostname 一覧だけの台帳では足りません。目的は『何があるか』だけでなく、『誰の責任か』『いつ確認したか』『どの証拠で存在を確認したか』を残すことです。ここがないと、見つかった資産が本番なのか残骸なのか判別できず、修正も進みません。
台帳の素材を集める段階では、サブドメイン棚卸し と DNS 棚卸し を合わせて進めると、asset 名と根拠を揃えやすくなります。
外部公開資産台帳テンプレートの最低限項目
管理責任者を空欄のままにしない
修正依頼先と月次レビューの戻し先が曖昧だと、見つけても改善が止まります。
first seen / last seen で発見履歴を残す
新規資産と残骸候補を切り分け、棚卸し結果を月次レビューへつなげやすくします。
| 項目 | 意味 | 実務上の使い方 |
|---|---|---|
| hostname / URL | 公開面の識別子 | 同名資産の取り違えを防ぐ |
| 管理責任者 | 責任者または責任部門 | 修正依頼とレビュー先を固定する |
| environment | prod / stg / test など | 露出時の優先度判断に使う |
| first seen / last seen | 最初に見えた日 / 最後に確認した日 | 新規資産と残骸の切り分けに使う |
| evidence | DNS、CT、HTTP、TLS などの確認根拠 | 存在確認の再現性を残す |
| 状態 | active / archived / unknown など | レビュー対象を絞る |
このうち特に重要なのは管理責任者と evidence です。管理責任者がなければ改善が止まり、evidence がなければ確認作業がやり直しになります。棚卸し結果を人に渡すときも、判断理由が見える台帳の方が合意形成が早くなります。
運用が安定する追加列
最低限の列に加えて、「business impact」、「change ticket」、「見直し頻度」、「linked service」、「decommission date」があると運用が安定します。とくに「change ticket」と「decommission date」は、廃止漏れや引き継ぎ漏れの抑止に効きます。
兼任体制の組織では、列が多すぎると止まりやすいので、まずは「管理責任者/ evidence /状態/ last seen」を優先し、次に追加列を増やす方が現実的です。詳細なレビュー設計は ISMS運用の記事 がつながります。
first seen / last seen /管理責任者/ evidence の考え方
first seen は新規資産の発見日、last seen は最後に外から見えた日として扱います。last seen が古いのに状態が active のままなら、台帳更新が止まっているサインです。逆に first seen が最近なのに管理責任者が空欄なら、新規露出への統治が効いていません。
evidence には、DNS レコード、証明書情報、HTTP 応答、スクリーンショットなど、再確認できる根拠を残します。感覚的なメモではなく、誰が見ても追える根拠を残すのが重要です。これにより、月次レビューで『本当に存在するか』を再調査する無駄を減らせます。
テンプレートを動かす
台帳は入力ルールと更新ルールがセットでないと止まります
サブドメイン棚卸しや DNS 棚卸しの結果を同じ型で受けるようにしておくと、運用の属人化を防ぎやすくなります。
更新ルールと月次レビュー
台帳更新は、追加・変更・削除のフローへ埋め込む必要があります。おすすめは、新規発見を weekly で反映し、月次レビューで unknown / archived 候補 / high risk を精査する形です。レビューでは『新規』『再発』『未対応』の3軸で見せると、意思決定者にも伝わりやすくなります。
また、台帳は単独で完結させず、チケット運用とレポート配布へ接続してください。高優先度の露出は即時対応、用途不明は管理責任者特定、残骸候補は削除確認と、次アクションをセットにすることで初めて生きた台帳になります。
記入例で見る外部公開資産台帳テンプレート
| asset | 状態 | 管理責任者 | evidence | 補足 |
|---|---|---|---|---|
| app.example.com | active | 情シス/プロダクト運用 | DNS + HTTP 応答 | 本番アプリ、本番監視対象 |
| stg.example.com | unknown | 空欄 | TLS 証明書 + ログイン画面 | 見直し で管理責任者特定が必要 |
| campaign.example.jp | archived候補 | マーケ/委託先 | CNAME + CT | 終了済みLP、削除確認待ち |
よくある質問（FAQ）
台帳は Excel でも運用できますか
できます。ただし、更新ルールと管理責任者がない Excel はすぐ陳腐化します。形式より、どのイベントで更新するかを決める方が重要です。
管理責任者不明の資産はどう扱うべきですか
「unknown」として残し、月次レビューで管理責任者特定を最優先にしてください。放置すると未管理資産へ移行します。
台帳とレポートは別管理にすべきですか
別ファイルでも構いませんが、同じ asset を同じ識別子で追えるようにしてください。台帳、チケット、レポートの往復ができることが重要です。
最初に必須で入れる項目は何ですか
最低でも asset 名、URL / hostname、管理責任者、用途、environment、状態、first seen、last seen は入れたいです。完璧な項目設計を待つより、「誰の何の公開面か説明できる」最低限の欄を先に揃える方が、運用へ乗りやすくなります。
台帳は誰が更新責任を持つべきですか
セキュリティ部門だけに寄せず、asset管理責任者が更新責任を持ち、中央運用側が見直しで差分を追う形が現実的です。台帳が中央管理の資料で終わると、現場の変更とすぐに乖離します。
まとめ
台帳テンプレートは記入項目の数より、『発見した公開面を owner・優先度・是正状況へつなげられるか』を優先すると使いやすくなります。
外部公開資産台帳は、公開面を一覧化するための書類ではなく、誰が何を引き取るかを決める運用の土台です。asset 名、管理責任者、用途、状態 を揃え、更新イベントと月次見直しを固定すると、未管理資産を減らしやすくなります。
まずは主要ドメインから始め、「unknown」を放置しない運用へ寄せてください。台帳、ticket、report を同じ識別子で往復できるようにすると、発見から是正までの流れが止まりにくくなります。
ASM診断 PRO を台帳更新に使う方法
ASM診断 PRO は外部観点の発見結果を起点にできるため、初回の台帳整備だけでなく、月次の更新にも向いています。Public 診断で公開面を棚卸しし、Verified を含む継続監視で last seen を更新し、report で evidence を残すという流れを作ると、台帳が手作業だけに依存しにくくなります。
最初から完璧な台帳を目指す必要はありません。まずは重要ドメインから動かし、管理責任者と evidence が揃う運用を一つ作り、その型を広げる方が現実的です。台帳は文書ではなく、改善を継続するための作業台 として扱ってください。
次のアクション
読み終えたら、無料でASM診断を開始
外部公開資産の現状を無料で確認し、管理漏れや優先して見るべきリスクを洗い出してください。記事で読んだ内容を、そのまま自社の判断へつなげやすくなります。
参考にした一次ソース
重要論点の根拠として参照した一次ソースだけを掲載しています。
入口単位で公開面を整理する考え方の基礎です。
継続発見と統一ビューの考え方を台帳運用へ接続しました。
資産台帳と unmanaged assets 管理の基礎要件を参照しました。